[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A few observations about the replay issue
--- On Thu, 28 Aug 97 22:07:09 EDT Charles Lynn <clynn@bbn.com> wrote:
[I'm quite deliberately sidestepping the anti-replay part of this thread. rja]
> When we say "rekey" do we mean that a SA with a new SPI is
> created?
Yes. This has _always_ been the meaning. In some sense, the term is unfortunate
because some have heard that term and misunderstood that one could simply change
the key with an existing SA. The "use the same SA and same SPI but change the
crypto key only" approach does not work because IP datagrams can be (and routinely
are) delivered out of order.
> To make rollover work, it seems like one would either
> need two SAs, with different SPIs, or else a single SA with two
> keys and an anti-replay counter associated with each key.
One needs two SAs ("old" and "new"), each with a different SPI
at the time of rollover. To handle rollover, there will need to be some
(non-zero) time period where both SAs are valid on the receiver (necessary
to handle the IP packets delivered slightly out of order case).
> Is this an implementor's choice, or does the architecture doc
> need to mandate which way must be implemented?
I'm not sure what the question above is asking...
Things that are NOT implementer's choice are:
1) "rekey" means to establish a replacement IPsec SA with its own (different)
SPI value.
2) To implement rollover, the implementation must possess 2 separate
IPsec SAs (each with its own different SPI) at the moment of
rollover.
Ran
rja@inet.org
References: