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

Re: Increased sequence number in ESP/AH

  While we're on the subject of sequence numbers and IKE negotiation
I'd like to make use of them negotiable. Right now the sender must always
send them even if the recipient is not using them. Parallelization of
IPsec processing is much easier if both sides can agree to forgo the
benefits of the anti-replay check.

  There's a REPLAY-STATUS notify message which I will wager has never
been implemented by anyone but it still does not relieve the sender of
his obligation to send the counter, it just allows the recipient to say
it will be ignored. 

  This would require new verbage on REPLAY-STATUS usage in the combined
IKE draft and also changes to RFC2401 which I understand is already being
considered for change.

  Dan.

P.S. for those of you with long memories yes I was the one that stood up
in Munich and told Steve Kent it was "just plain stupid" to negotiate
this. Mmmmmm, crow.

On Mon, 22 Jan 2001 15:13:42 EST Stephen Kent <kent@bbn.com> wrote
> Avi,
> 
> >I would like to ask about the proposal to increase the size of the sequence
> >number field in ESP and AH headers to 64 or 128 bits. This was discussed in
> >the last IETF conference in San Diego.
> >
> >  * Is there any specific definition for updated ESP/AH structure?
> >  * ESP and AH headers currently does not include version number.
> >	-  Does the preceding header will have new values for the headers?
> >Or how this can be solved (specific SPIs?)
> 
> My proposal calls for the extended sequence numbers to NOT occupy any 
> more space in the ESP or AH headers. Instead, use of these numbers 
> would be negotiated by IKE, so that interoperability would be 
> maintained with systems that do not support the extended fields.  No 
> change would occur in the "on the wire" format, which avoids 
> increasing overhead. Sender and receiver maintain larger (e.g., 64 
> bit) counters, but transmit only the low order 32 bits. A new 
> receiver window algorithm is needed to deal with the transition that 
> occurs every 2**32 packets, but there is no security ambiguity here, 
> i.e., any packet that is < 2**32-1 by more than the receive window is 
> treated like a packet from the next chunk of sequence space.
> 
> Steve
> 
> P.S.  Since sequence numbers are not used for anti-replay for 
> manually keyed SAs, not being able to negotiate this for non-IKE 
> contexts does not seem to be a problem. Any other protocol that is 
> used to negotiate SAs should be able to support this sort of 
> negotiation.
>
Follow-Ups: References: