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

From: Stephen Kent <[email-masked]>
Date: Wed, 25 Jun 2003 19:42:07 -0400

Several folks have asked for the ability to place traffic with 
different TOS values on different SAs, which requires that the TOS 
field (IPv4) and the flow spec field (IPv6) be useable as selectors. 
If we agree to add this feature, we need the ability to negotiate 
this in IKE. What I meant to say is closer to what David referred to 
in his message, i.e., I would anticipate a sender using the 6-bit DS 
field as an additional selector value (not the ECN bits). I don't 
think this is affected by the question of whether the interpretatioon 
of these bits is uniform across ISPs. The concern is that if these 
bits really do have an affect on the order of delivery of traffic, 
then putting different classes of traffic into the same SA has the 
potential to cause a non-trivial percentage of the (lower priority) 
traffic to be rejected due to receiver window mismatches. Now this is 
not a problem if the bits are inside a tunnel and NOT propagated to 
the outer header, but then they are not helping out during transit 
across unprotected nets. I admit to not being familiar with PHIBs, so 
I'm not sure what the issues are there. I'm also open to suggestions 
from IPv6 experts about what to do there, for flows.

Mark & Radia suggest that we don't need this facility to be 
negotiated. I didn;'t understand the arguments until I worked my way 
through the cases. Now I think I understand the arguments, and 
basically agree.  Let me try to examine the relevant cases:

1. traffic with varying DiffServ bits mapped to one tunnel mode SA, 
but not copied to the outer header
	- because the network between the IPsec devices will not see 
per-packet markings, there would be no addition reordering influence 
and thus no motivation for separate SAs, hence no need for using 
these bist as selectors

2. traffic with varying DiffServ bits mapped to one tunnel mode SA 
and copied to the outer header
	- this is the obvious case where more significant reordering 
by the net between the IPsec devices might cause problems 
(undesirable receiver discards due to receive window mismatches) and 
what motivated the suggestion to create different SAs for each class 
of traffic.

3. traffic with varying DiffServ bits mapped to tunnel mode SAs using 
these bits as selector values, and the bits are copied to the outer 
header
even if the nets between the IPsec devices modify the values in the 
outer header, this would not affect the inner header values and so I 
think would work as desired. however, it is correct that this could 
be done unilaterally by the sender using selectors but not telling 
the reeciver, and still have this work for an SA, unidirectionally. 
What we would loose is the ability to tell the receiver what we are 
doing, or not doing, and thus trigger the reciprocal behavior by the 
responder, if appropriate.

4. traffic with varying DiffServ bits mapped to one transport mode SA
	- as in case 2, the traffic has an increased opportunity to 
be delivered out of order, causing problems at the receiver. again, 
this motivates using these bits to select different SAs at the sender.

5. traffic with varying DiffServ bits mapped to transport mode SAs 
using these bits as selector values if the nets between the IPsec 
devices modifies the bits, we would have a problem when we tried to 
match the bits against the selectors at the receiver. if the sender 
maps the traffic to different SAs, using selectors, but does not tell 
the receiver, then there would be no problems with mismatches in the 
SPD checks at the receiver. so, I guess I would agree there here too 
this could be done by the sender unilaterally and the effect would be 
OK.

So, what this seems to suggest is that there is a good use for 
DiffServ bits (or PHIBs, or whatever) as selectors, but that if one 
uses them, one need not tell the receiver. Is that right?

Steve

---

From: Charles Lynn <[email-masked]>
Date: Thu, 26 Jun 2003 09:41:08 -0400 (EDT)

Steve and IKEv2 folks,

> DiffServ bits (or PHIBs, or whatever) as selectors,

Yes, I agree.

> but that if one uses them, one need not tell the receiver. Is that right?

I am not sure.  Consider the receiver.  If the receiver has the same
"policy" as the sender, then it will also want to have multiple SAs.
Since, to its knowledge, none of the existing SAs from the initiator
have DiffServ markings, and it wants to use them, then it will setup
its own SAs back to the original initiator.  Now there are 2 * N SAs
half of which will never be used by each endpoint. We can do better.

Can the responder even setup its own SAs? Do the duplicate detection
rules need to be expanded?

What about detection of unused or half-dead SAs?  Do they need to be
more complicated to achieve the desired results?

Recent text says half open connections should be audited.  The false
positives would lead to reduced confidence in auditing: "ignore it".

Are there other ramifications that we need to consider?

Charlie

---

From: Mark Duffy <[email-masked]>
Date: Thu, 26 Jun 2003 11:04:57 -0400

Steve,

I would say that your analysis is basically correct, by my understanding.

I would argue that in tunnel mode it is basically a local matter for the 
sender how it wants to initialize the DiffServ bits in the outer 
header.  It might be "set to k" or "copy from inner" but could also be 
anything else.  So the cases to be considered might be a somewhat different 
set than you have below but the important points are the same.

I do not see a need however for the receiver to know exactly what the 
sender is doing or to know which DiffServ bits to expect on a given SA.  I 
also think there might be significant difficulties in trying to negotiate 
DiffServ whatevers (DSCPs or PHB-IDs) as selectors in the traditional sense 
(described in my earlier email in this thread).  So I would opt for letting 
the sender make a local choice which SA to send on, and all the receiver 
needs to do is support multiple "redundant" SAs.

I added 3 comments in the message below.

--Mark

At 07:42 PM 6/25/2003 -0400, Stephen Kent wrote:
>Several folks have asked for the ability to place traffic with different 
>TOS values on different SAs, which requires that the TOS field (IPv4) and 
>the flow spec field (IPv6) be useable as selectors. If we agree to add 
>this feature, we need the ability to negotiate this in IKE. What I meant 
>to say is closer to what David referred to in his message, i.e., I would 
>anticipate a sender using the 6-bit DS field as an additional selector 
>value (not the ECN bits). I don't think this is affected by the question 
>of whether the interpretatioon of these bits is uniform across ISPs. The 
>concern is that if these bits really do have an affect on the order of 
>delivery of traffic, then putting different classes of traffic into the 
>same SA has the potential to cause a non-trivial percentage of the (lower 
>priority) traffic to be rejected due to receiver window mismatches. Now 
>this is not a problem if the bits are inside a tunnel and NOT propagated 
>to the outer header, but then they are not helping out during transit 
>across unprotected nets. I admit to not being familiar with PHIBs, so I'm 
>not sure what the issues are there. I'm also open to suggestions from IPv6 
>experts about what to do there, for flows.
>
>Mark & Radia suggest that we don't need this facility to be negotiated. I 
>didn;'t understand the arguments until I worked my way through the cases. 
>Now I think I understand the arguments, and basically agree.  Let me try 
>to examine the relevant cases:
>
>1. traffic with varying DiffServ bits mapped to one tunnel mode SA, but 
>not copied to the outer header
> per-packet markings, there would be no addition reordering influence and 
> thus no motivation for separate SAs, hence no need for using these bist 
> as selectors
>
>2. traffic with varying DiffServ bits mapped to one tunnel mode SA and 
>copied to the outer header
>         - this is the obvious case where more significant reordering by 
> the net between the IPsec devices might cause problems (undesirable 
> receiver discards due to receive window mismatches) and what motivated 
> the suggestion to create different SAs for each class of traffic.
>
>these bits as selector values, and the bits are copied to the outer header
>even if the nets between the IPsec devices modify the values in the outer 
>header, this would not affect the inner header values and so I think would 
>work as desired. however, it is correct that this could be done 
>unilaterally by the sender using selectors but not telling the reeciver, 
>and still have this work for an SA, unidirectionally. What we would loose 
>is the ability to tell the receiver what we are doing, or not doing, and 
>thus trigger the reciprocal behavior by the responder, if appropriate.

I don't think any reciprocal behavior is needed.  Each sender can do its 
own thing with regard to making sure the desired number of SAa are present, 
and deciding which packets to send on which SAs.  This may offend some by 
its lack of symmetry but then the set of DiffServ values flowing in the two 
directions may not even be symmetrical in the first place.

>         - as in case 2, the traffic has an increased opportunity to be 
> delivered out of order, causing problems at the receiver. again, this 
> motivates using these bits to select different SAs at the sender.
>
>5. traffic with varying DiffServ bits mapped to transport mode SAs using 
>these bits as selector values if the nets between the IPsec devices 
>modifies the bits, we would have a problem when we tried to match the bits 
>against the selectors at the receiver. if the sender maps the traffic to 
>different SAs, using selectors, but does not tell the receiver, then there 
>would be no problems with mismatches in the SPD checks at the receiver. 
>so, I guess I would agree there here too this could be done by the sender 
>unilaterally and the effect would be OK.

These mismatches in SPD checks at the reciever could be prevented by 
negotiating PHB-IDs (globally meaningful) instead of DiffServ codepoints, 
but then that would break case 3  :-)

>So, what this seems to suggest is that there is a good use for DiffServ 
>bits (or PHIBs, or whatever) as selectors, but that if one uses them, one 
>need not tell the receiver. Is that right?

I think that is right (but I wouldn't call them selectors then).

I would just say that to avoid sequence number problems with packets 
reordered by the DiffServ network "the sender SHOULD use separate SAs to 
send packets whose DiffServ codepoints (in the outermost IP header) place 
them in different  Ordered Aggregates [RFC 3260]"

Keep it simple!

---

From: Francis Dupont <[email-masked]>
Date: Mon, 30 Jun 2003 14:38:12 +0200

In your previous mail you wrote:

   I'm also open to suggestions from IPv6 experts about what to do
   there, for flows.
   
=> IPv6 traffic class are DiffServ bits and should be handled exactly
as in IPv4.
 The IPv6 Flow Label is very different: it is clearly designed as
an alternative to traditional 5-tuple filters, so IMHO IPsec/IKE should
include it as a possible selector.
 BTW RFC 2460 (IPv6 specs) doesn't really define Flow Labels, the
document to read is draft-ietf-ipv6-flow-label-07.txt,
here is the beginning of its introduction:
 
   A flow is a sequence of packets sent from a particular source to a
   particular unicast, anycast or multicast destination that the source
   desires to label as a flow. A flow could consist of all packets in a
   specific transport connection or a media stream. However, a flow is
   not necessarily 1:1 mapped to a transport connection.

   Traditionally, flow classifiers have been based on the 5-tuple of the
   source and destination addresses, ports and the transport protocol
   type. However, some of these fields may be unavailable due to either
   fragmentation or encryption, or locating them past a chain of IPv6
   option headers may be inefficient. Additionally, if classifiers
   depend only on IP layer headers, later introduction of alternative
   transport layer protocols will be easier.

   The usage of the 3-tuple of the Flow Label and the Source and
   Destination Address fields enables efficient IPv6 flow
   classification, where only IPv6 main header fields in fixed positions
   are used.

Regards

[email-masked]

PS: (re)read Mike's messages too.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 30 Jun 2003 10:55:20 -0400

>[email-masked]

Francis,

Thanks for the clarification.

It looks like it makes sense to use the IPv6 traffic class as the 
equivalent of the DiffServ bits, if the WG agrees that we ought to 
use these are a new selector type.

What do other folks think about this suggestion to offer the Flow 
Label as another selector type, for the reasons cited above by 
Francis?

Steve

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 30 Jun 2003 11:08:26 -0400

Re: multiple "redundant" SAs:
In order to support simultaneous rekey tie-breaking as currently 
defined, one needs to be able to be able to determine
if the attempt to create a child is a rekey and if so, which SA is being 
rekeyed. The only way to do this per current
version is to examine the traffic selectors which presumes no redundant 
SAs.

- Jeff

Mark Duffy wrote:

> I would argue that in tunnel mode it is basically a local matter for 
> the sender how it wants to initialize the DiffServ bits in the outer 
> anything else.  So the cases to be considered might be a somewhat 
> different set than you have below but the important points are the same.
> 
> sender is doing or to know which DiffServ bits to expect on a given 
> SA.  I also think there might be significant difficulties in trying to 
> negotiate DiffServ whatevers (DSCPs or PHB-IDs) as selectors in the 
> traditional sense (described in my earlier email in this thread).  So 
> I would opt for letting the sender make a local choice which SA to 
> send on, and all the receiver needs to do is support multiple 
> "redundant" SAs.
> 
> I don't think any reciprocal behavior is needed.  Each sender can do 
> its own thing with regard to making sure the desired number of SAa are 
> present, and deciding which packets to send on which SAs.  This may 
> offend some by its lack of symmetry but then the set of DiffServ 
> values flowing in the two directions may not even be symmetrical in 
> the first place.
> 
> 
> negotiating PHB-IDs (globally meaningful) instead of DiffServ 
> codepoints, but then that would break case 3  :-)
> 
> 
> reordered by the DiffServ network "the sender SHOULD use separate SAs 
> to send packets whose DiffServ codepoints (in the outermost IP header) 
> place them in different  Ordered Aggregates [RFC 3260]"
> 
> Keep it simple!
> 
> 
>> Steve
> 
> 
> 
> 
>

---

From: Stephen Kent <[email-masked]>
Date: Mon, 30 Jun 2003 17:39:09 -0400

At 11:08 AM -0400 6/30/03, [email-masked] wrote:
>if the attempt to create a child is a rekey and if so, which SA is 
>being rekeyed. The only way to do this per current
>version is to examine the traffic selectors which presumes no redundant SAs.
>
>- Jeff
>

Whoops!

Any suggestions on how to avoid messing up the rekey heuristic and 
not negotiating the DiffServ values for SAs?

Steve