Subject: QoS selectors (was LAST CALL: IKE)

From: [email-masked]
Date: Thu, 19 Jun 2003 14:01:43 -0400

Steve,

> 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 negootiate 
> this in IKE.

That would be the 6 bit DS Field, as defined in RFC 2780.  The other
two bits in the same header octets are used for ECN and should not be
used as selectors.  There are some subtle issues in QoS specification
across administrative domain boundaries - in full generality, the
DiffServ Code Point (DSCP) values used in the DS Field do not have
global validity or meaning.

It's ok to use DSCPs when the values are only expected to be
meaningful to one end of the connection (e.g., receiver tells
sender to set DSCP to <x> in inner IP header for tunnel mode
SA), or something in the middle can be expected to do the
translation if necessary - the latter does not apply to IKE
for obvious reasons.  For more general negotiation, where both
ends are expected to understand what is being negotiated,
PHBIDs (RFC 3140) are appropriate.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: "Andrew Krywaniuk" <[email-masked]>
Date: Tue, 24 Jun 2003 04:13:31 -0400

>So it seems like the sender, which knows it wants to send n different
>TOSs for which speeds will vary, can open n SAs, and choose which
>of the TOSs to send on which of them.

I don't see why we would want to do it that way. The problem isn't so much 
on the initiator side. We negotiate SAs in pairs, so if the initiator sets 
up 5 SAs, the responder now has to monitor the traffic on the inbound SAs in 
order to figure out what QoS applies to the outbound SA. This, of course, 
assumes that we want to match the selectors on the inbound and outbound SAs, 
which I would prefer. Sure we could do this heuristically, but why would we 
want to?

Andrew
--------------------------------------
Lead something-or-other at Fortinet Technologies
"Always post from the address that already
receives the most spam." -- Sun Tzu

_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

---

From: [email-masked]
Date: Thu, 26 Jun 2003 15:02:38 -0400

Mark,

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

Yes, RFC 2983 contains more on this topic.

> 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 agree, and in particular this is the basic response to Charles Lynn's
concern:

	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.

The DiffServ marking policy can be different in each direction, even
across a common set of paired SAs.  There's nothing wrong with
CREATE_CHILD_SA setting up an SA that is used to carry routing
traffic (e.g., Class Selector/IP Precedence 6) in one direction
and best effort traffic in the reverse as long as the routing
traffic in the reverse direction doesn't get mixed with the best
effort traffic on the same 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 completely agree.  IKEv2 has enough challenges; there's no need
to add QoS negotiation.

Thanks,
--David

---

From: [email-masked]
Date: Mon, 30 Jun 2003 19:57:57 -0400

Steve,

> At 11:08 AM -0400 6/30/03, [email-masked] wrote:
> >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.
> 
> Whoops!
> 
> Any suggestions on how to avoid messing up the rekey heuristic and 
> not negotiating the DiffServ values for SAs?

We've already concluded that the DiffServ values are functionally
opaque to the other side from a traffic classification standpoint.
OTOH, I'm concerned that if we pass them across IKE, someone's going
to try to use them in a way that s/he shouldn't.  So, let's go back
to an old proposal from Radia:

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

The uniquifier could be some sort of internal index or pointer;
even a simple counter works.

Another possibility if rekeying is really the only problem,
would be to pass the other side's SPI as the "uniquifier" indicating
exactly which SA is being rekeyed.  If this is always done, the
rekeying "heuristic" turns into a rule - when the "old SPI"
is passed, this is a rekey of that SPI, otherwise it's a new
SA creation.  A minor downside is that if one fails to pass the
"old SPI" on rekey, SAs that are no longer useful may accumulate
on the peer, but the peer is already free to garbage collect SAs,
and these will be good candidates as they will carry no further
traffic.

Thanks,
--David