[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
Mark Duffy wrote:
> 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.
> 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
>> 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
> 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!