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

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Thu, 19 Jun 2003 18:49:51 -0400 (EDT)

Hmm. Actually, I think there is no reason to negotiate which
TOS values go on which SA. The reason for different SAs for
different TOS values is so that the sequence numbers don't get
too far off (assuming that different TOS's go at different speeds).

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.

If A and B have n SAs already, then if A has k different TOS's, A
can use the other half of the n SAs (and doesn't need to open more
of them) if k < n.

I *think* the current IKEv2 spec supports this. The previous draft
said something about having to close redundant SAs. This one at
least implies that the only time you'd close a redundant SA is if
it happened as a result of a rekeying collision.

A few of us had worked out language in the hallway at the last IETF,
explicitly saying things like that only the creator of an SA could
delete a redundant SA, but I think it was declared too late to make
design decisions like that that might have other implications.

Radia

	From: [email-masked]
	To: [email-masked], [email-masked]
	Subject: QoS selectors (was  LAST CALL: IKE)
	MIME-Version: 1.0
	
	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: Michael Richardson <[email-masked]>
Date: Thu, 19 Jun 2003 21:44:44 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Radia" == Radia Perlman <- Boston Center for Networking <[email-masked]>> writes:
    Radia> Hmm. Actually, I think there is no reason to negotiate which
    Radia> TOS values go on which SA. The reason for different SAs for
    Radia> different TOS values is so that the sequence numbers don't get
    Radia> too far off (assuming that different TOS's go at different speeds).

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

  Sounds good in theory.
  It is not clear to me that everyone agrees that they can negotiate multiple
SAs with IKEvX that do not apparently differ in terms of negotiated
selectors.

  Further, the *responding* system doesn't know what the initiator wanted,
so even if the initiator knows how to demux, it needs a way to tell the
responder. 

    Radia> A few of us had worked out language in the hallway at the last IETF,
    Radia> explicitly saying things like that only the creator of an SA could
    Radia> delete a redundant SA, but I think it was declared too late to make
    Radia> design decisions like that that might have other implications.

  That sounds okay, but still isn't perfect.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Mark Duffy <[email-masked]>
Date: Tue, 24 Jun 2003 16:07:38 -0400

I like Radia's proposal, mainly because I think trying to bind the SAs to 
DSCPs or PHBIDs is likely to become a bit of a rathole and really doesn't 
gain much.

I don't see why the receiver should care which packets arrive on which SA, 
so long as they match all the (other) selectors.

Some complications I see with negotiating DSCP or PHBID as a selector:

.  I agree with David that PHBID would be the correct beast to negotiate, 
from the Diffserv perspective.  But since PHBIDs require a (locally unique) 
mapping to be translated to the actual bits (DSCP) in the packet, it is a 
bit of a leap for IPsec compared to the other selectors where the literal 
selector bits to be seen on the wire are negotiated.  Moreover, the mapping 
from PHBID to DSCP may be 1:n, imposing perhaps a significant burden on an 
implementation to evaluate for any of multiple possible DSCP values.

.  For transport mode, the DSCP that the selectors are evaluated against is 
that in the outer (only) IP header.  This is mutable and hence may be 
remapped at a Diffserv domain boundary while still representing the same 
semantics as represented by the corresponding negotiated PHBID.  But for 
tunnel mode the selectors are evaluated against the inner IP header and 
this DSCP would *not* be mapped at a Diffserv domain boundary.  This packet 
might fail at the receiver to match the negotiated PHBID.  IF we negotiated 
DSCP instead of PHBID we'd just have the opposite problem instead.

--Mark

At 06:49 PM 6/19/2003 -0400, Radia Perlman - Boston Center for Networking

---

From: Stephen Kent <[email-masked]>
Date: Wed, 25 Jun 2003 14:29:28 -0400

At 4:07 PM -0400 6/24/03, Mark Duffy wrote:
>I like Radia's proposal, mainly because I think trying to bind the 
>SAs to DSCPs or PHBIDs is likely to become a bit of a rathole and 
>really doesn't gain much.
>
>I don't see why the receiver should care which packets arrive on 
>which SA, so long as they match all the (other) selectors.
>
>.  I agree with David that PHBID would be the correct beast to 
>negotiate, from the Diffserv perspective.  But since PHBIDs require 
>a (locally unique) mapping to be translated to the actual bits 
>(DSCP) in the packet, it is a bit of a leap for IPsec compared to 
>the other selectors where the literal selector bits to be seen on 
>the wire are negotiated.  Moreover, the mapping from PHBID to DSCP 
>may be 1:n, imposing perhaps a significant burden on an 
>.  For transport mode, the DSCP that the selectors are evaluated 
>against is that in the outer (only) IP header.  This is mutable and 
>hence may be remapped at a Diffserv domain boundary while still 
>representing the same semantics as represented by the corresponding 
>negotiated PHBID.  But for tunnel mode the selectors are evaluated 
>against the inner IP header and this DSCP would *not* be mapped at a 
>Diffserv domain boundary.  This packet might fail at the receiver to 
>match the negotiated PHBID.  IF we negotiated DSCP instead of PHBID 
>we'd just have the opposite problem instead.
>
>--Mark

The motivation that other had raised, and that I was merely 
responding to, is that if one puts traffic with different service 
characteristics on one SA, then it is likely that the traffic will 
arrive very much out of order and as a result the receiver sequence 
window will reject more traffic than under better circumstances. I 
don't understand how the comments above address this concern. Could 
you clarify?

Thanks,

Steve