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