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

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."

	I think perhaps the origin of the WG's confusion is the use of
	the term "rekey".  The process of rekey does not retain an SA
	and merely change the keys.  Rather, the rekey process creates
	an entire new SA to replace the original SA.  Now it might commonly
	be the case that the new SA has nearly all of its attributes 
	(not including SPI or crypto keys) the same as the original SA,
	but it is still a new SA.

	In general, SPIs are just 32-bit opaque numbers used in conjunction
	with the Destination Address to identify an SA.  SPIs do not have
	sequence numbers, keys, or other stuff.  By contrast, an SA does
	contain an SPI, identities, keys, sequence numbers, and other stuff.

	I hope this helps.

	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.

Ran
rja@inet.org
References: