diff --git a/src/pluto/PLUTO-CONVENTIONS b/src/pluto/PLUTO-CONVENTIONS deleted file mode 100644 index 16febc4aa..000000000 --- a/src/pluto/PLUTO-CONVENTIONS +++ /dev/null @@ -1,125 +0,0 @@ -Notes on Pluto Conventions -========================== - -Pluto has its own stylistic conventions. They are fairly easily -inferred by reading the code. - -- sample formatting: - -void -fun(char *s) -{ - if (s == NULL) - { - return ""; - } - else - { - switch (*s) - { - default: - s++; - /* fall through */ - case '\0': - return s; - } - } -} - -- a function definition has its function identifier at the margin - -- indentation is in steps of 4 columns (tabstops are every 8 columns) - -- try to keep lines shorter than 80 columns - -- space should be canonical: - + no line should have trailing whitespace - + leading whitespace should use tabs where possible - + indentation should be precise - + there should be no empty lines at the end of a file. - -- braces go on their own line, indented the same as the start of what they are part of - -- switch labels are indented the same as the enclosing braces - -- if a case falls through, say so explicitly - -- spaces follow control flow reserved words (but not function names) - -- the operand of return need not be parenthesized - -- be careful with types. For example, use size_t and ssize_t. - Use const wherever possible. - -- we pretend that C has a strong boolean type. - We actually define bool with constants TRUE and FALSE. - Other types cannot be used as the complete expression in a test. - Hence: - if (s == NULL) - One exception: lset_t values can be treated as booleans - (technically they are, in the original sense of the word) - - -- memsetting a pointer to binary zero is not guaranteed to make it NULL - -- side-effects of expressions are to be avoided. - BAD: if (i++ == 9) - OK: i++; - -- variables are to have as small a scope as is possible. - Move definitions into inner blocks whenever possible. - Often initializing definitions become possible and are clearer. - -- within a block that has declarations, separate the declarations from - the other statements with a blank line. - -- "magic numbers" are suspect. Most integers in code stand for something. - They should be given a name, and that name used consistently. - -- don't use malloc/free -- use the wrappers (see defs.h) - -- it is good to put comments on #else and #endif to show what - they match with. I use ! to indicate the sense of the test: - #ifdef CRUD - #else /* !CRUD */ - #endif /* !CRUD */ - - #ifndef CRUD - #else /* CRUD */ - #endif /* CRUD */ - -- all functions and variables that are exported from a .c file should - be declared in that file's header file. Because the .c includes the - header, the declaration and the definition will be checked by the - compiler. There is almost no excuse for the "extern" keyword - in a .c file. - -- when lines are too long and expressions are to be broken, try to - break just before a binary operator. The outermost binary operator - is preferred. This is perhaps the most unconventional convention. - It allows the structure of code to be evident from a scan of the - left margin. Example: - if (next_step == vos_his_client - && sameaddr(&c->spd.that.host_addr, &his_client)) - next_step = vos_done; - and - p = oppo_instantiate(p, &c->spd.that.host_addr, &c->spd.that.id - , NULL, &our_client, &his_client); - Note the different indentation of the continuations. The continuation - of a control flow statement is not indented but other continuations are. - -- Never put two statements on one line. - REALLY BAD: if (cat); - Exception: some macro definitions. - -- C preprocessor macros are implemented by a kind of textual substitution. - Be sure to put parentheses around references to macro arguments and - around the whole macro body. If the body is meant to be a statement, - put braces around it instead. - - #define RETURN_STF_FAILURE(f) \ - { int r = (f); if (r != NOTHING_WRONG) return STF_FAIL + r; } - -- adding #include statements adds dependencies. The Makefile should be - changed to reflect them. Target "makedepend" will try to list dependencies - in a way suitable for pasting into Makefile diff --git a/src/pluto/TODO b/src/pluto/TODO deleted file mode 100644 index 445a6e214..000000000 --- a/src/pluto/TODO +++ /dev/null @@ -1,128 +0,0 @@ -Pluto TODO list -=============== - -- should all log entries that are for errors say ERROR? - -- Add a "plug-in" facility so that others can add features without - changing the mainline code. This is how X509/LDAP/biometric stuff - might be added. - -- (internal change only) routines for outputting payloads should plug - "np" into the previous payload so that a payload generating routine - need not know what the next payload will be. This may be more bother - than it is worth. - -- notifications, in and out - + delete - + first contact - + last contact? (not part of drafts, but would be nice) - -- Make DNS usage for asynchronous (non-blocking) - + looking up KEY and TXT records during negotiation - + perhaps not for whack command arguments and ipsec.secrets since the - library code uses gethostbyname - -- check that ipsec auto and whack to agree on what is worth reporting - -- Should Pluto (rather than ipsec manual) install %passthrough conns? - That way Pluto would know of them. - -- For responding to Road Warriors, how can we decide if the RW has - gone away? The rekeying event is perhaps too imprecise. Even if - rekeying event is good enough, how do we know if the route should be - torn down? Perhaps limiting a Phase 1 ID to one IP address would - help (limiting a client subnet to one peer already helps). Perhaps - (in some rate-limited way) we can take an ICMP host unreachable - as a hint to do some authenticated and reliable probe. - -- it is annoying that Pluto and auto have different models for public keys. - + auto specifies one per connection - + Pluto allows one to be specified per id - Two connections with the same id are going to use the same key: - the one of the last conn to be added! - - I think auto ought to be fixed. It is hard for Pluto to warn when - there is a conflict since the deletion of a connection doesn't - prompt auto to tell pluto to delete the public key. - -- different connections with the same host IP addresses are randomly - interchangeable until the ID payload is received. At least for the - Responder case (and eventually for the opportunistic Initiator). - Worse, all Road Warriors must be considered to have the - indistinguishable IP addresses. This affects ISAKMP SA negotiation. - Currently, there is little flexibility in this negotiation, so the - problem is limited to the specification of acceptable authentication - method(s). Correct, but more work than seems worthwhile, would be - to select the conn based on what is proposed. - - Warning about such confusion at connection definition time isn't great - because there is no confusion when explicitly initiated (a particular - conn is specified). Warning for a Road Warrior conn is possible - since it cannot be initiated (and has been implemented). - -- characterize and ameliorate DOS attacks. Lots of rate limiting. - -- look at John Denker's wish list: http://www.quintillion.com/moat/wish.list - -- use of random numbers needs to be audited. - -- unknown (not just unimplemented) transforms cause a negotiation to - fail. Only the transform should be rejected. - -- we need better policy control. Our present flags need to be - modulated (forbid, allow, offer, require) - -- HS will specify how --copyright and --version should behave - -- HS will initiate project-wide terminology replacing ISAKMP SA, IPSEC - SA, Protection Suite, Phase 1, Main Mode, Phase 2, Quick Mode, ... - Simplicity and clarity will be a goal. - -- interface discovery ought to match what is specified in ipsec.conf. - This probably means grokking /proc/net/ipsec_tncfg. Documented in - ipsec_tncfg(5). This won't do for Hugh's debugging setup. - - -Protocol Issues -=============== - -Notification and delete payloads seem to be "escape hatches" for the -protocols. As such, anything implemented using them seems to be -kludged without being well designed or well situated or well -constrained in the protocols. Often the precise meaning (if any) or -usage is under specified. An implementation is allowed to ignore -them, so they cannot really matter (but they too often do). Their -specification ought to be scrutinized by a protocol guru. - -Any extra payload in last main mode message is not protected (not -authenticated by hash). - -Should notification payloads be interpreted before or after the normal -payloads (i.e. understood in the context of, executed in the context of). - -What is the precise result of an INITIAL_CONNECTION? What is a -"system" (eg. does Phase 1 Identity count)? What is "earlier" or -"before" (simultaneous negotiation is possible, with time being only a -partial order)? Could it be used for FINAL_CONTACT (needed too)? - -Blasting out a pile of UDP messages, especially to a particular -destination, is likely to provoke message loss. The exchanges are -just that, so they individually are self-throttling. But what about -multiple exchanges simultaneously? What about notifications (example: -when shutting down, a flurry of delete notifications are likely). -Should the RFCs be designed to protect against this problem? - -draft-jenkins-ipsec-rekeying-03.txt rekeying is way too complicated. -Our solution looks sound and simple (we have the Responder install the -incoming IPSEC SA before sending its first reply). In "2.2.1.4 -Responder Pre-Set-up Security Hole", the draft claims that setting up -the IPSEC SA early leaves the Responder open to replay attacks. I -think that this is wrong: the Message Id, since it must not be reused, -serves to prove that this isn't a replay. - -The details for notification messages suggested by -draft-ietf-ipsec-notifymsg-02.txt are over-complicated, just to make -them machine-comprehensible. I think this is over-engineering, -justified only if another level of negotiation is contemplated (ugh!). -Plain text is probably sufficient for informing humans (I admit that -there is a problem with I18N). diff --git a/src/pluto/pluto-style.el b/src/pluto/pluto-style.el deleted file mode 100644 index 0de474e44..000000000 --- a/src/pluto/pluto-style.el +++ /dev/null @@ -1,4 +0,0 @@ -(c-add-style "pluto" '("bsd" - (c-basic-offset . 4) - (c-offsets-alias . ((substatement-open . 0))))) -