RE: ipsec error protocol

>RE: ipsec error protocolFrom: Stephen Kent [kent@bbn.com]
>Sent: Wednesday, January 31, 2001 1:01 PM
>To: sankar ramamoorthi
>Cc: ipsec@lists.tislabs.com
>Subject: RE: ipsec error protocol
>
> Some questions on this topic.
>
> As per RFC 2401, if an ipsec implementation gets a packet with
> valid authentication and whose sequence number is larger than the
> current replay window, the implementation should accept the packet
> and set its sequnce window to the larger size.
>
> At 10 million packets/sec(10^7) it takes approximately 400 seconds for
> a 32 bit sequence to overflow.
>
> That means if someone were to replay a valid authenticated packet every
> 400 seconds it is likely to accepted as a valid packet.
>
> How will changing the sequence number space to a bigger value
> by just negotiation alone help the above problem? Does'nt on the wire
> sequence number size also has to change?
>
> What am I missing?
>
>
>You are missing a couple of points that have been mentioned in previous messages to the list:
>
>
> - yes, I have proposed an extension of the sequence number space to allow for much larger sequence numbers, e.g., 64 bit sequence numbers, but with transmission of only the low order 32 bits in the AH or ESP header.
>
>
> - the proposal includes the extended sequence number in the integrity calculation, so a replayed packet will not be accepted by ESP (or AH) even though it carries only a 32-bit sequence number in the header, i.e., if a packet arrives with a sequence number that looks like a rollover of the 32-bit sequence number, it will be treated as having a 64-bit number with the low order bit of the high order 32 bits incremented by 1. A replay, when viewed in this fashion, will fail the integrity check, which means the receive sequence number window will not be changed.
>