[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Sequence Number
Here we go on the sequence number again... This is a particular hot button
of mine because of the number of times we've gone over this... Anyway....
>-----Original Message-----
>From: William Allen Simpson [SMTP:wsimpson@greendragon.com]
>Sent: Friday, July 11, 1997 5:29 AM
>To: ipsec@tis.com
>Subject: Sequence Number
>
>2.2. Sequence Number
>
> When configured manually, the first value sent SHOULD be a random
> number. The limited anti-replay security of the sequence of data-
> grams depends upon the unpredictability of the values.
>
> When configured via an automated Security Association management pro-
> tocol, the first value sent is 1, unless otherwise negotiated.
When configured manually the value MUST start at 1 the same as it MUST start
at 1 if a KMP is used. It's in the clear, it is monotonically increasing.. It is in a
fixed spot in the packet... A random starting point adds no benefit and only
complicates policy management and implementations.
The statement about the limited value of the anti-replay security depending on the
unpredictability adds no value to the document and can certainly be disputed.
> Thereafter, the value is monotonically increased for each datagram
> sent. A replacement SPI SHOULD be established before the value
> repeats. That is, no more than 2**32 datagrams SHOULD be sent with
> any single key.
A replace SPI MUST be established before roll over. More than 2**32 datagrams
MUST not be sent under a single key. We've always defined 0 as a replay
condition. This goes back the 64 bit sequence number ... event ... Even
if the receiver isn't checking the replay field, senders will know when they are
going to send more than 2**32 and force a re-key.
Follow-Ups: