RE: QoS selectors (was LAST CALL: IKE)

[Mark Duffy <mduffy@quarrytech.com>]

At 03:19 PM 6/27/2003 -0400, Stephen Kent wrote:
>At 5:08 PM -0400 6/26/03, Mark Duffy wrote:
>>In my understanding, everything that we today call "selectors" are 
>>negotiated in IKE, used at the IPsec sender to decide how to send 
>>packets, and used at the IPsec receiver to decide whether to accept packets.
>>
>>If we agree that it is a local matter for the sender to decide which 
>>packets to send on which of n "redundant" SAs (whether this decision is 
>>based on DiffServ codepoint/PHB or whatever) then I would propose we 
>>don't call whatever rules govern that selectors.  I think to do so would 
>>create confusion vs the exisiting concept of selectors.
>
>I disagree. Selectors are fields and values used to map outbound traffic 
>to an SA. Generally we need to communicate these values to the receiver, 
>so that that receiver can verify receiver traffic is consistent with what 
>is negotiated, and because we want to make sure that the receiver's policy 
>is consistent with that the the transmitter. In the case of the DiffServ 
>bits, we have an example where the receiver may not need to know, for 
>security purposes, what the values are for traffic mapped to one SA vs. 
>another, but that does not change the basic role of selectors as the 
>fields/values used to map traffic to an SA.

OK.  You are much more in tune with the nomenclature than I am.


>>Moreover, if it is a local matter at the sender I don't see any need to 
>>standardize it at all.  Let's just say you are allowed to have 
>>"redundant" SAs (with the same properties) and the sender can use 
>>whichever of those SAs it wants to to send any given packet.  For the 
>>current discussion that decision would be to send packets of different 
>>Ordered Aggregates [RFC 3260] on different SAs but it could be for any 
>>other reason as well.  (Load balancing across encryption hardware units, 
>>perhaps?)
>
>I like to see the DiffServ bits defined as part of the standard, not for 
>interop purposes, but for uniform feature purposes. I'd like to be able to 
>characterize what IPsec implementation can do, to address questions of the 
>sort that motivate this discussion, rather than saying: "well, IPsec may 
>discard lots of packets if you map multiple classes of traffic to one SA 
>and if you pass through the DiffServ bits, unless your vendor happens to 
>have made special provisions to do something ..."

OK.  I don't have any particular problem with that, I was just trying to 
save work :-)
I do hope it will anyway be permissible for the sender to send on multiple 
SAs for other purposes, that the receiver isn't necessarily privy to.

--Mark



>Steve