Subject: [Ipsec] About extended sequence numbers

From: Markku Savela <[email-masked]>
Date: Tue, 22 Feb 2005 10:18:39 +0200

Is my understanding correct in following:

With old 32 bit sequence number logic, if you got and "old" packet
below replay window, it was dropped without running the authentication
algorithm.

With new 64 bit sequence number logic, you don't know if the packet is
old, until you have tried to authenticate it with the new higher
"sequence subspace number".

 ---

As far as I see, this is *not* new attack potential, as sequece
numbers could always be adjusted so that algorithm must be run.

It is just that a connection using ESN behaves a little bit
differently from not using ESN. Just a curious observation, probably
nothing to be concerned with?

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Stephen Kent <[email-masked]>
Date: Mon, 28 Feb 2005 16:10:06 -0500

>below replay window, it was dropped without running the authentication

right.

>"sequence subspace number".

well, you can do it in two phases. First, look to see if the sequence 
number looks "good" based on only the low order 32 bits. if so, then 
proceed to authentication. this is just the way non-ESN processing 
proceeds. The added complexity arises when the window spans two 
sequence number subspaces, i.e., two 2**32 bit chunks. The appendix 
in AH and ESP (it's the same text in both) provides a discussion on 
how to deal with this, which works easily so long as there is no 
ambiguity caused by a very extensive packet sequence loss. 
Specifically, if you miss 2**32 packets in a row on one SA, then we 
have no quick way to detect and recover, a problem we discussed 2 
about years ago.

>nothing to be concerned with?

Here is the note I plan to add to AH (section 3.3.2) and ESP (section 3.3.3)

Note: If a receiver chooses to not enable anti-replay for an SA, then 
the receiver SHOULD NOT negotiate ESN in an SA management protocol. 
Use of ESN creates a need for the receiver to manage the anti-replay 
window (in order to determine the correct value for the high order 
bits of the ESN, which are employed in the ICV computation), which is 
generally contrary to the notion of disabling anti-replay for an SA.