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

Re: QoS selectors (was LAST CALL: IKE)

Re: multiple "redundant" SAs:
In order to support simultaneous rekey tie-breaking as currently 
defined, one needs to be able to be able to determine
if the attempt to create a child is a rekey and if so, which SA is being 
rekeyed. The only way to do this per current
version is to examine the traffic selectors which presumes no redundant 

- Jeff

Mark Duffy wrote:

> Steve,
> I would say that your analysis is basically correct, by my understanding.
> I would argue that in tunnel mode it is basically a local matter for 
> the sender how it wants to initialize the DiffServ bits in the outer 
> header.  It might be "set to k" or "copy from inner" but could also be 
> anything else.  So the cases to be considered might be a somewhat 
> different set than you have below but the important points are the same.
> I do not see a need however for the receiver to know exactly what the 
> sender is doing or to know which DiffServ bits to expect on a given 
> SA.  I also think there might be significant difficulties in trying to 
> negotiate DiffServ whatevers (DSCPs or PHB-IDs) as selectors in the 
> traditional sense (described in my earlier email in this thread).  So 
> I would opt for letting the sender make a local choice which SA to 
> send on, and all the receiver needs to do is support multiple 
> "redundant" SAs.
> I added 3 comments in the message below.
> --Mark
> At 07:42 PM 6/25/2003 -0400, Stephen Kent wrote:
>> 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.
> I don't think any reciprocal behavior is needed.  Each sender can do 
> its own thing with regard to making sure the desired number of SAa are 
> present, and deciding which packets to send on which SAs.  This may 
> offend some by its lack of symmetry but then the set of DiffServ 
> values flowing in the two directions may not even be symmetrical in 
> the first place.
>> 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.
> These mismatches in SPD checks at the reciever could be prevented by 
> negotiating PHB-IDs (globally meaningful) instead of DiffServ 
> codepoints, but then that would break case 3  :-)
>> 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?
> I think that is right (but I wouldn't call them selectors then).
> I would just say that to avoid sequence number problems with packets 
> reordered by the DiffServ network "the sender SHOULD use separate SAs 
> to send packets whose DiffServ codepoints (in the outermost IP header) 
> place them in different  Ordered Aggregates [RFC 3260]"
> Keep it simple!
>> Steve