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

RE: ipsec error protocol

Title: RE: ipsec error protocol
At 10:14 AM -0800 1/31/01, sankar ramamoorthi wrote:
>From: Stephen Kent [kent@bbn.com]
>Sent: Monday, January 29, 2001 12:24 PM
>To: sankar ramamoorthi
>Cc: ipsec@lists.tislabs.com
>Subject: Re: ipsec error protocol
>
>Sankar,
>
>><snip>
>>
>>  >
>>  >Question: what if every ESP (for instance) packet would piggy back an
>>acknowledgement field (in both direction) ? That would solve quite a few
>>issues, no ? And would also be much more efficient.
>>  >
>>
>>I do not understand what you have in mind for the semantic of
>>acknowledgement field.
>>
>>Yes, it would be nice to have an 'RECEIPT-NEEDED' and 'RECEIPT' type of
>>flags
>>in the ESP. It would also be nice to have versioning in ESP.
>>Any reason why versioning was left out of the initial ESP design?
>
>Good question. I think we envisioned an IKE negotiation for this, but
>it could have been done better. No place for a small version number
>up front, given alignment considerations, and if we assume a general
>need for a negotiation for an SA prior to its establishment, then
>that's the right time to find out what your peer can support, e.g.,
>re versions.  For now, I see no need to create a new version of ESP.
>For example, we're planning to accommodate bigger sequence numbers
>via a negotiation but NO change in the on the wire format. Thus I
 

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.

Steve
Follow-Ups: References: