removed some ancient files
This commit is contained in:
Andreas Steffen
parent
89699b7660
commit
540061b59a
|
|
@ -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
|
||||
128
src/pluto/TODO
128
src/pluto/TODO
|
|
@ -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).
|
||||
|
|
@ -1,4 +0,0 @@
|
|||
(c-add-style "pluto" '("bsd"
|
||||
(c-basic-offset . 4)
|
||||
(c-offsets-alias . ((substatement-open . 0)))))
|
||||
|
||||
Loading…
Reference in New Issue