Subject: RE: QoS and IKEv2

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Sun, 9 Mar 2003 23:31:38 -0500

"Jesse Alpert" <[email-masked]> wrote:

>Again, it seems to me it might be easier to explicitly include this (PHB)
>information in the TS payload. This requires modifications to the IKEv2
>draft.
>
>Thanks again,
>Jesse
>
>

Thank you for noticing that, Jesse. The problem (to summarize
without diffserv acronyms) is that IKEv2 says that two
child-SAs with the same traffic selectors are redundant,
and extra ones should be closed. But it also says that
you might want several between the same endpoints with
the same traffic selectors for different QOS.

I'd propose that there should be some way to create
multiple SAs with the same traffic selectors, and
that it's not necessary to negotiate what QOS things
go over which ones. It's up to the sender to
decide that. And there might in the future be
other reasons to create multiple SAs and
we wouldn't be able to tell the difference
based solely on the fields in the traffic
selector (protocol type, address, and port).

So I'd propose one more field in the traffic
selector for "uniquifier". Alice can create
multiple child-SAs to Bob with the same
traffic selectors, as long as they have different
uniquifiers.

The only function of the uniquifier is so that
the multiple SAs won't look redundant to Bob.
Which traffic gets sent over which SA is up
to the sender.

Radia

---

From: "Jesse Alpert" <[email-masked]>
Date: Tue, 11 Mar 2003 13:20:31 +0200

Hi again,

> selector for "uniquifier". Alice can create

I like this "uniquifier" idea. Indeed there may be more reasons for creating
apparently redundant IPsec SAs to avoid problems caused by the IPsec replay
counter.

For instance if one of the peers is a cluster of machines performing load
sharing. It may want to establish multiple IPsec SAs with the peer, one for
each machine belonging to the cluster. Each 'cluster member' will have its
own SA which it can use for outbound traffic. This way the IPsec replay
counter does not have to be synchronized between the cluster members. To the
non-cluster peer however, these SAs may seem redundant as they share the
exact same traffic selectors (The cluster has a single external IP address
and the cluster members are not exposed).

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.

Jesse

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Radia Perlman -
Boston Center for Networking
Sent: Monday, March 10, 2003 6:32 AM
To: [email-masked]
Subject: RE: QoS and IKEv2

Radia

---

From: Markku Savela <[email-masked]>
Date: Tue, 11 Mar 2003 15:08:28 +0200

Just stirring the soup, food for thought...

> From: "Jesse Alpert" <[email-masked]>
> 

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.

---

From: "Yoav Nir" <[email-masked]>
Date: Tue, 11 Mar 2003 16:13:36 +0200

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: [email-masked]
[mailto:[email-masked]]On Behalf Of Markku Savela
Sent: Tuesday, March 11, 2003 3:08 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: IKEv2 and multiple tunnels. (Was: QoS and IKEv2)

---

From: "Jesse Alpert" <[email-masked]>
Date: Tue, 11 Mar 2003 16:15:42 +0200

Hi Markku,

> instead in the definition of what is "redundant"?

You are right, and that will probably work as well.

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. For example, if you are simply creating a
new tunnel (or rekeying an existing one) specify 0 for the "uniquifier"
value. If, on the other hand, you are opening a 'special' tunnel (identical
to one which already exists) to be used for some 'special' purpose (e.g.
different QoS level) or rekeying for such a tunnel, then use some non-zero
"uniquifier" value.

The "uniquifier" is nice since it explicitly states that these apparently
identical tunnels are used for different purposes. Another option would be
to ignore the (rare?) case of both peers initiating an exchange at once
(maybe add some text about using a random jitter) and stating that peers
should not assume that two identical tunnels are redundant.

Jesse

---

From: Stephen Kent <[email-masked]>
Date: Tue, 11 Mar 2003 09:51:28 -0500

>Which traffic gets sent over which SA is up

Radia,

Traffic selectors are values used to map outbound traffic to SAs, 
based on IP and transport layer header fields. So the notion of a new 
selector that does not correspond to any header field is not really 
consistent with the terminology as it has been defined in 2401.

I don't disagree with the possible utility of having some way to 
distinguish among multiple SAs with identical selectors, but first 
one needs to describe how traffic will be mapped to each one, given 
that the selector mapping would not otherwise distinguish among them. 
For inbound traffic, as someone already noted, the SPIs provide the 
necessary demuxing capability.

One possible solution is to use the virtual interface ID (VID) that I 
proposed adding to 2401bis, to separate route selection from SA 
selection. I don't recall whether messages on this topic circulated 
on the list, or if they were just exchanged among a set of folks who 
were looking at how to better accommodate overlay nets and PPVPN 
applications.  The short description is that we plan to augment the 
current processing model to include an explicit routing/forwarding 
lookup, which returns a VID and the VID is used to select the SPD for 
outbound processing. The VID is kept with the packet after 
processing, to allow selection of a physical interface or for use in 
a ciphertext-side lookup table for outer header selection.  In a 
trivial case, where there is just one virtual interface (on the 
ciphertext side) the VID is constant.

Steve

---

From: "Jesse Alpert" <[email-masked]>
Date: Tue, 11 Mar 2003 17:33:49 +0200

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:[email-masked]]
Sent: Tuesday, March 11, 2003 4:52 PM
To: Jesse Alpert
Cc: 'Markku Savela'; [email-masked]
Subject: Re: IKEv2 and multiple tunnels. (Was: QoS and IKEv2)

> You are right, and that will probably work as well.

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

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

---

From: Uri Blumenthal <[email-masked]>
Date: Tue, 11 Mar 2003 09:51:53 -0500