[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: QoS selectors (was LAST CALL: IKE)
At 03:19 PM 6/27/2003 -0400, Stephen Kent wrote:
>At 5:08 PM -0400 6/26/03, Mark Duffy wrote:
>>In my understanding, everything that we today call "selectors" are
>>negotiated in IKE, used at the IPsec sender to decide how to send
>>packets, and used at the IPsec receiver to decide whether to accept packets.
>>If we agree that it is a local matter for the sender to decide which
>>packets to send on which of n "redundant" SAs (whether this decision is
>>based on DiffServ codepoint/PHB or whatever) then I would propose we
>>don't call whatever rules govern that selectors. I think to do so would
>>create confusion vs the exisiting concept of selectors.
>I disagree. Selectors are fields and values used to map outbound traffic
>to an SA. Generally we need to communicate these values to the receiver,
>so that that receiver can verify receiver traffic is consistent with what
>is negotiated, and because we want to make sure that the receiver's policy
>is consistent with that the the transmitter. In the case of the DiffServ
>bits, we have an example where the receiver may not need to know, for
>security purposes, what the values are for traffic mapped to one SA vs.
>another, but that does not change the basic role of selectors as the
>fields/values used to map traffic to an SA.
OK. You are much more in tune with the nomenclature than I am.
>>Moreover, if it is a local matter at the sender I don't see any need to
>>standardize it at all. Let's just say you are allowed to have
>>"redundant" SAs (with the same properties) and the sender can use
>>whichever of those SAs it wants to to send any given packet. For the
>>current discussion that decision would be to send packets of different
>>Ordered Aggregates [RFC 3260] on different SAs but it could be for any
>>other reason as well. (Load balancing across encryption hardware units,
>I like to see the DiffServ bits defined as part of the standard, not for
>interop purposes, but for uniform feature purposes. I'd like to be able to
>characterize what IPsec implementation can do, to address questions of the
>sort that motivate this discussion, rather than saying: "well, IPsec may
>discard lots of packets if you map multiple classes of traffic to one SA
>and if you pass through the DiffServ bits, unless your vendor happens to
>have made special provisions to do something ..."
OK. I don't have any particular problem with that, I was just trying to
save work :-)
I do hope it will anyway be permissible for the sender to send on multiple
SAs for other purposes, that the receiver isn't necessarily privy to.