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