Subject: RE: QoS selectors (was LAST CALL: IKE)

From: Mark Duffy <[email-masked]>
Date: Thu, 26 Jun 2003 17:08:30 -0400

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.

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?)

--Mark

---

From: Stephen Kent <[email-masked]>
Date: Fri, 27 Jun 2003 15:19:52 -0400

At 5:08 PM -0400 6/26/03, Mark Duffy wrote:
>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.
>
>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.

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

Steve

---

From: Mark Duffy <[email-masked]>
Date: Fri, 27 Jun 2003 16:20:03 -0400

At 03:19 PM 6/27/2003 -0400, Stephen Kent wrote:
>>packets, and used at the IPsec receiver to decide whether to accept packets.
>>
>>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.

>>standardize it at all.  Let's just say you are allowed to have 
>>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