RE: IKEv2 and multiple tunnels. (Was: QoS and IKEv2)

["Jesse Alpert" <jalpert@CheckPoint.com>]

Hi,

> I don't think it would work the way you describe - i.e. both
> hosts are unaware and so created SAs with "uniquifier" 0...

I didn't mean to say that the "uniquifier" will solve the problem of the
concurrent rekeying. Just that the "uniquifier" can help distinguish between
redundant SAs created by accident (e.g. because of concurrent rekeying) and
identical SAs created on purpose by one of the peers.

A peer which means to create an additional tunnel on purpose would use
different "uniquifiers".

Jesse

-----Original Message-----
From: Uri Blumenthal [mailto:uri@bell-labs.com]
Sent: Tuesday, March 11, 2003 4:52 PM
To: Jesse Alpert
Cc: 'Markku Savela'; ipsec@lists.tislabs.com
Subject: Re: IKEv2 and multiple tunnels. (Was: QoS and IKEv2)


Jesse Alpert wrote:
>>SPI itself is already "uniquifier". Maybe the problem is not here, but
>>instead in the definition of what is "redundant"?
>
> You are right, and that will probably work as well.

Then why multiply the entities? Occham's Razor...


> However:
> If I understood correctly, IKEv2 draft was referring to the case where
both
> peers initiate a CHILD-SA exchange almost at once, resulting in two
> identical IPsec SAs one of which IS redundant. In such a case you would
want
> to close one of the SAs to save on resources. The "uniquifier" can be used
> to indicate this is not the case.

I don't think it would work the way you describe - i.e. both
hosts are unaware and so created SAs with "uniquifier" 0...

I don't know how to deal with the described problem efficiently.