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

["Yoav Nir" <ynir@CheckPoint.com>]

If you remove the "should be closed" part you lose the way to delete tunnels
which are truely redundant.  It is entirely possible to have peer A require
several tunnels, while peer B does not.  Without a uniquifier, peer A will
open several tunnels, and peer B will close all but the last.  A uniquifier
will allow peer B to know that peer A opened several different tunnels on
purpose, rather than by mistake.

-----Original Message-----
From: owner-ipsec@lists.tislabs.com
[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Markku Savela
Sent: Tuesday, March 11, 2003 3:08 PM
To: jalpert@CheckPoint.com
Cc: radia.perlman@sun.com; ipsec@lists.tislabs.com
Subject: Re: IKEv2 and multiple tunnels. (Was: QoS and IKEv2)


Just stirring the soup, food for thought...

> From: "Jesse Alpert" <jalpert@CheckPoint.com>
>
> In this scenario the "uniquifier" will help, since it will indicate that
> these tunnels are not redundant - they are used by the peer for some
> (unknown) purpose.

SPI itself is already "uniquifier". Maybe the problem is not here, but
instead in the definition of what is "redundant"?

Perhaps it should be changed, remove the following from spec:

> ... is that IKEv2 says that two child-SAs with the same traffic
> selectors are redundant, and extra ones should be closed.

..especially the "should be closed part". The same thing that would
decide whether to include "uniquifier", could also decide whether to
issue DELETE's for the "redundant SA" or not.