[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: QoS selectors (was LAST CALL: IKE)
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 negotiate
this in IKE. What I meant to say is closer to what David referred to
in his message, i.e., I would anticipate a sender using the 6-bit DS
field as an additional selector value (not the ECN bits). I don't
think this is affected by the question of whether the interpretatioon
of these bits is uniform across ISPs. The concern is that if these
bits really do have an affect on the order of delivery of traffic,
then putting different classes of traffic into the same SA has the
potential to cause a non-trivial percentage of the (lower priority)
traffic to be rejected due to receiver window mismatches. Now this is
not a problem if the bits are inside a tunnel and NOT propagated to
the outer header, but then they are not helping out during transit
across unprotected nets. I admit to not being familiar with PHIBs, so
I'm not sure what the issues are there. I'm also open to suggestions
from IPv6 experts about what to do there, for flows.
Mark & Radia suggest that we don't need this facility to be
negotiated. I didn;'t understand the arguments until I worked my way
through the cases. Now I think I understand the arguments, and
basically agree. Let me try to examine the relevant cases:
1. traffic with varying DiffServ bits mapped to one tunnel mode SA,
but not copied to the outer header
- because the network between the IPsec devices will not see
per-packet markings, there would be no addition reordering influence
and thus no motivation for separate SAs, hence no need for using
these bist as selectors
2. traffic with varying DiffServ bits mapped to one tunnel mode SA
and copied to the outer header
- this is the obvious case where more significant reordering
by the net between the IPsec devices might cause problems
(undesirable receiver discards due to receive window mismatches) and
what motivated the suggestion to create different SAs for each class
of traffic.
3. traffic with varying DiffServ bits mapped to tunnel mode SAs using
these bits as selector values, and the bits are copied to the outer
header
even if the nets between the IPsec devices modify the values in the
outer header, this would not affect the inner header values and so I
think would work as desired. however, it is correct that this could
be done unilaterally by the sender using selectors but not telling
the reeciver, and still have this work for an SA, unidirectionally.
What we would loose is the ability to tell the receiver what we are
doing, or not doing, and thus trigger the reciprocal behavior by the
responder, if appropriate.
4. traffic with varying DiffServ bits mapped to one transport mode SA
- as in case 2, the traffic has an increased opportunity to
be delivered out of order, causing problems at the receiver. again,
this motivates using these bits to select different SAs at the sender.
5. traffic with varying DiffServ bits mapped to transport mode SAs
using these bits as selector values if the nets between the IPsec
devices modifies the bits, we would have a problem when we tried to
match the bits against the selectors at the receiver. if the sender
maps the traffic to different SAs, using selectors, but does not tell
the receiver, then there would be no problems with mismatches in the
SPD checks at the receiver. so, I guess I would agree there here too
this could be done by the sender unilaterally and the effect would be
OK.
So, what this seems to suggest is that there is a good use for
DiffServ bits (or PHIBs, or whatever) as selectors, but that if one
uses them, one need not tell the receiver. Is that right?
Steve