Re: Ikev2 Traffic Selector payload

[Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>]

whoops..sorry about that...I'm working remotely with tiny bandwidth and
accidentally clicked on "send" before I was ready to send. Let
me finish my message...

Valery Smyslov said:

>>    The Responder is allowed to narrow the choices by selecting a
>>    subset of the traffic, for instance by eliminating one or more
>>    members of  the set of traffic selectors provided the set does
>>    not become the NULL set. However, the result of the narrowing
>>    MUST encompass the first TSi and first TSr from initiator's
>>    proposal. Otherwise SA MUST NOT be established.

I don't think adding the last 2 sentences work. The part about how the
narrowing MUST encompass...

The reason is that unless we *require* the initiator to put a single 
source/destination/port into the first selector, your suggested
wording wouldn't work. I don't think we can require it to do that, because
it might be just setting up the SA based on being configured to do so
when it comes up, rather than being triggered by a specific packet.
If Alice (the initiator) has a wider range configured than Bob, then
your wording would cause them not to be able to talk.

We could require Alice, if the SA is being triggered by a specific packet,
to specify the specifics in the first TSi and TSr (my original reply
said that Alice MAY do that, but didn't require her to).

However, if Alice is just bringing up the IKE-SA because she's configured
to do so...not as the result of a specific packet...then all the TSi's and
TSr's would be ranges, and Bob should just do the best he can. He should
certainly be allowed to narrow the range if the first of each TS is a range
rather than a specific address/port.

Radia