Best Regards,
Joseph D.
Harwood
jharwood@vesta-corp.com
www.vesta-corp.com
-----Original Message-----
From: Joseph D. Harwood [mailto:jharwood@vesta-corp.com]
Sent: Wednesday, January 31, 2001 12:52 PM
To: sankar ramamoorthi; Stephen Kent
Cc: ipsec@lists.tislabs.com
Subject: RE: ipsec error protocolSankar,The authentication value would include the upper 32-bits of the expanded sequence number, even though it isn't sent on the wire. A replay of an earlier packet would thus fail.Best Regards,
Joseph D. Harwood
jharwood@vesta-corp.com
www.vesta-corp.com-----Original Message-----
From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of sankar ramamoorthi
Sent: Wednesday, January 31, 2001 10:15 AM
To: Stephen Kent
Cc: ipsec@lists.tislabs.com
Subject: RE: ipsec error protocol>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 withvalid 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?Thanks,-- sankar -->
>Steve
BEGIN:VCARD VERSION:2.1 N:Harwood;Joseph;D. FN:Joseph D. Harwood ORG:Vesta Corporation ADR;WORK:;(408) 838-9434;5201 Great America Parkway, Suite 320;Santa Clara;CA;95054 LABEL;WORK;ENCODING=QUOTED-PRINTABLE:(408) 838-9434=0D=0A5201 Great America Parkway, Suite 320=0D=0ASanta Clara, = CA 95054 URL: URL:http://www.vesta-corp.com EMAIL;PREF;INTERNET:jharwood@vesta-corp.com REV:20001011T162328Z END:VCARD