RE: QoS and IKEv2

[Stephen Kent <kent@bbn.com>]

At 11:31 PM -0500 3/9/03, Radia Perlman - Boston Center for Networking wrote:
>"Jesse Alpert" <jalpert@checkpoint.com> 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,

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