[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Increased sequence number in ESP/AH
Steve,
How does this address freshness (anti-replay)?
Is this intended only as a useful feature for high-speed devices that may
need additional SA lifetime?
--- Andrea Colegrove
Stephen Kent 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: