[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Sequence Number
-----Original Message-----
From: Ran Atkinson [SMTP:rja@inet.org]
Sent: Friday, July 11, 1997 12:25 PM
To: ipsec@tis.com
Subject: RE: Sequence Number
> > 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.
> I'd propose a more precise version of the above, perhaps something like:
>
> "A replacement IPsec Security Association MUST be established before
> the original IPsec Security Association rolls over its sequence
> number space or otherwise expires. More than 2**32 IP datagrams
> MUST NOT be sent using the same IPsec SA when anti-replay protection
> is in use. The replacement IPsec Security Association will, of
> course, have a different SPI than the original IPsec Security
> Association."
Well put. very well put.
> On an unrelated note, I've been reading the bits about covert channels.
> My own take on this would be:
> - The specifications ought not preclude an implementation
> from providing covert channel protections.
> - The specifications ought not require that all implementations
> provide such protections.
Again, very well put. I agree with this completely. Unfortunately, the above
statement could lead to the perception that we need to negotiate a pad value.
I am strongly opposed to negotiating a pad value. That's added complexity
we do not need. In the absence of a negotiated pad value, the only reasonable
way to achieve the above is with a pad value of zero.
Zero protects against covert channels. It is easy to set for senders who care and
who don't. It is easy to test for receivers that care about covert channels, and just
as easy to ignore as anything else for those receivers that don't.
Requiring a pad value of zero fits Ran's statements above as well, with the only
tiny caveat that senders who don't care about covert channels have to zero their
pads.
So, unless we find any cryptographic reasons for not using zero for the pad, I would
suggest we require the pad MBZ. The pads length must be between zero and 255
octets to bring the packets length including the two required octets to a block
ciphers block size.
-Rob
Follow-Ups: