Re: Ikev2 Traffic Selector payload

["Valery Smyslov" <svan@trustworks.com>]

On 13 May 02, at 23:04, Radia Perlman - Boston Center wrote:

> 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

Actually, I suggested that we do require initiator to always put a 
traffic selector, that selector of SA being negotiated must 
encompass. If SA negotiation is triggered by outgoing packet, this  
selector will be taken from the packet and will contain a single 
source/destination/address/port. Otherwise, if SA is setting up on 
being configured to do so, this selector can be taken from SPD.

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

I don't see much harm here. Anyway, even if SA is created in this 
case, but narrowed by responder, it might appear not to be usable for 
initiator when real packet appears. In any case, when real packet 
appears, new SA will be created. 

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

Actually, not always. SPD entry may contain single address/port or 
list of single values. But this small problem is easy to solve: just 
require initiator in this case to put dummy range (represent single 
address as a range of length 1) into the first selector.


To summarize:

My suggestion.
1. First TSi and TSr of initiator's TS payloads always contain
    traffic description (address(es)/port(s)) that SA being created
    must satisfy. This information is taken by initiator:
    a) from the packet that triggered that SA negotiation (in this
        case those TSi and TSr contain only single address/port)
    b) from SPD in case that SA is setting up because initiator is
        configured to do so (in this case those TSi and TSr may
        contain anything, including range/subnet).
2. Responder always consider the first TSi and TSr as those, that
    must be encompassed in resulting SA selector. If this can't be
    satisfied, SA is not created.

Your suggestion (as I understand it).
1. If SA negotiation is triggered by the packet, initiator may (or
    must) put specifics of this packet into first TSi and TSr. In
    this case the first TSi and TSr must contain single values
    (address/port).
2. If SA negotiation is performed because initiator is configured to
    do so, put information from SPD into the first TSi and TSr. If
    this SPD entry contain single address/port or a list of single
    addresses/ports, put dummy range into the first TSi and TSr
    (represent single address as a range of length 1).
3. If responder sees single address and port in the first TSi and
    TSr, he/she must keep this values encompassed in SA selector
     while its (possible) narrowing, or SA must not be created.
4. If responder sees anything but single address/port in the first
     TSi and TSr, he/she may narow SA selector as he/she wish.

Actually, I can live with your suggestion too.

> Radia

Regards,
Valery Smyslov.