[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: QoS selectors (was LAST CALL: IKE)



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