RE: same SPI/different exchange

["Awan Kumar" <awank@future.futsoft.com>]

Hi,
  The RFC says that the tuple <SPI, destn. addr, protocol> has to be unique.
If an SA has already been negotiated with a peer, and IKE gets a proposal
from a different peer with the same SPI, there should not be any problem as
the tuple is still unique. I do not think that there should be any problem
in accepting the same SPI from a different peer. If the same peer sends a
same proposal again, then the peer implementation is buggy. I think there
should not be any problem even if a same peer proposes same SPI, but for
different protocols (i.e one for AH and the other for ESP).

> Bill Sommerfeld writes:
>  > > What is the intended behavior of IKE if you
>  > > receive a proposal for a SPI which already exists?
>  >
>  > If this happens, the peer is probably buggy ..
>
>    Really? Doesn't this happen as a natural consequence of
>    retransmissions?

>I'd hope that replay detection would prevent that case ..

REPLAY DETECTION BY IKE !!!


>  > This sounds like the robust thing to do; I'd want to be careful to
>  > ensure that the old and new instances were treated as "different"
>  > (from the point of view any caching which might be going on..)
>
>    Right. They could change proposals, etc too.

different proposals, different keys, reset sequence number space,
etc.,


Regards,
Awan

---

References:

• Re: same SPI/different exchange
• From: Bill Sommerfeld <sommerfeld@East.Sun.COM>

---

• Prev by Date: IPSec performance statistics
• Next by Date: IPsec Bakeoff in Finland
• Next by thread: AH length field, and derivation of name "SKEYID"
• Index(es):
  • Main
  • Thread