[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Granularity of authentication in swIPe



Perry,

	I don't object to swIPe being a candidate for a standards
track IP security protocol.  I do object to arguments that suggest we
must adopt swIPe as THE standards track protocol because it has the
widest deployment at this point in time or because we need to gain
experience with SOME network layer security protocol.  My observation
is that the latter argument can be addressed by publishing swIPe, or
any other protocols, as Experimental or Informational RFCs, and thus
it is not a good argument in favor of selecting swIPe at this time.

	As for specific concerns about swIPe, yes, I do have several,
based on a cursory reading the protocol.  I think the SAID-like field
should be larger.  It should be emphasized that this field is used to
select previously negotiated security association options: the key(s),
sequence number management rules, optional use of compression
algorithms, security labels, etc.  That argues against a structure for
the field.  I also would like to see the the sequence number field be
made larger, or at least provide for negotiation of a larger field, to
avoid the need to provide for rekeying during an association.  My
motivation for this field is not the same as yours, but rather as a
means of detecting replay attepmts in a denial of service context.  To
that end, if an association elects to invoke this option, I'd like to
see a more explicit and more stringent sequence number management
algorithm spelled out, rather than leaving it to each implementation
to decide.  Upon further analysis, there may be more suggestions I will
be able to put forward.

	My experience with developing several other security protocols
suggests that we should strive to make the steady-state protocol
capable of working with a variety of key management procedures, but
that until we work out all of the details of several such procedures,
we are unlikely to have all of the necessary hooks in the protocol.
So, until we have such details, it may be premature to progress a
network layer security protocol on the standards track, but it might
be appropriate to gain experience with several candidates via the
other routes I mentioned above.


Steve


Follow-Ups: References: