[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