Re: QoS selectors (was LAST CALL: IKE)

[Mark Duffy <mduffy@quarrytech.com>]

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 
wrote:
>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: Black_David@emc.com
>         To: kent@bbn.com, ipsec@lists.tislabs.com
>         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
>         black_david@emc.com        Mobile: +1 (978) 394-7754
>         ----------------------------------------------------