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

Re: the silly bit

Ted,

Your comment :
 
>  Or is what's *really* going on is this bit is saying "this SAID is for
>  SKIP", and what we're *really* doing is reserving one bit for the
>  exclusive use of SKIP?  That seems unacceptable to me.

is, I think, not quite fair. While SKIP is the only in-band keying protocol
being actively proposed for IPSEC and IPv6, other examples have been given
of protocols that use in-band keying, viz., DEC's. One of the litanies we
constantly here about IETF work is that it should be based on actual
implementation experience. SKIP is implemented and working in the field.

The people working on SKIP are not trying to force others to use in-band
keying in general or SKIP in particular. They are saying they would like
a way to do in-band keying in both IPv4 and IPv6 in a standard way. This
is a reasonable request.

>  If you need to do in-line key management, why can't that be done by
>  defining some new, optional transforms that include extra fields which
>  are especially designed for in-line key management, instead of trying to
>  kludge it into the SAID?  Then, the SAID is used as it's originally
>  intended to be used --- as an index into a connection table which will
>  indicate how the rest of the packet needs to be processed --- including
>  any possible in-line key management, if necessary.

When a packet arrives, the only field that is available for indicating that
the header contains in-band information, at least with the ESP proposed
format, is the SAID or the synchronization field. Since the synchronization
field format is dependent on the SAID, this forces designers who want to
do in-band keying to use something about the SAID field to indicate this.
There is no pre-existing SAID value that the receiver will have cached
to determine that the header specifies in-band keying. The SAID value will
be allocated after the packet is processed.

>  I'm not convinced that, as proposed, the reserved bit will actually do
>  any good (besides wasting one half of the SAID space).

I agree with you about taking up a bit in the SAID. I think a special SAID
value should be used to indicate that the next field(s) carry additional
information about the key management protocol. Since there are already
SAID values "reserved for future work," one of these can be chosen. e.g.,
the SAID value consisting of all ones.

Dan