Re: Ikev2 Traffic Selector payload

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

On 11 May 02, at 20:37, Radia Perlman - Boston Center wrote:

Radia,

> I too agree with Valery Smyslov's suggestion: Have the initiator specify
> the specifics of the packet that caused it to want to create
> the child-SA. However, there are a bunch of ways this
> could be done. Any opinions?

Actually, the suggestion could be generalized a bit: let initiator 
put into the first TSi and the first TSr selector of the proposed SA 
that, from initiator's point of view, is absolutely required for SA 
to be useful for him/her. In most cases those TSi and TSr will be 
taken from the packet that triggered the negotiation. The following 
TSi and TSr (if any) in initiator's proposal reflect what additional 
addresses/ports this SA, according to initiator's SPD, should 
encompass. In other words, the first TSi and TSr show the minimal SA 
"width" that will satisfy initiator, while all TSs (both the first 
and the following) - an optimal SA "width" (according to his/her 
SPD).

The generalization is that now the first TSi and first TSr can 
contain anything, not only a single address and a single port. For 
example, they may contain range or subnet. However, if they are 
filled from actual packet, they still will contain single values.

> For example, we could say that the first selector of TSi MAY be the
> specifics of the source of
> the packet that's causing the initiator to create the child-SA,
> and the first selector of TSr MAY be the specifics of the destination
> of the packet.
>
> The responder will choose the largest ranges of addresses and ports
> it can accomodate.
> 
> So far, no changes to the spec.

Except that the special role of the first TSi and TSr must be 
documented.

> But here's the change that incorporates Valery's suggestion, I think:
> 
>    If the responder has multiple ranges, and can't choose, then he
>    MUST choose the largest set that encompasses the first TSi and first TSr.

I'd rather to rephrase this in more general way, for example (taking 
as a base 3-rd para from section 2.9):

    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.

> Also, if the initiator didn't put the specifics of the first packet into
> the first TSi and first TSr, then should we:

I'm a bit confused here. TS payloads are mandatory and contain at 
least one TS substructure (according to the spec). So, "the first" 
TSi and TSr are always exist. How responder could know whether 
initiator put specifics of the packet into the first TSi and TS or 
something else? I'd suggest he/she just always choose his TS so, 
that:
1. initiator's the first TSi and TSr MUST be encompassed
2. initiator's the rest TSi and TSr MAY be encompassed (or partly 
encompassed)

>   a) generalize the "SINGLE-PAIR-REQUIRED" to instead mean "you have to
>      be more specific, or

This notification is unnecessary with my original suggestion, but is 
still useful with generalized one, because in latter case the first 
TSi and TSr may contain ranges or subnets (and port ranges too).

>   b) (I think I prefer this one), have a new error type for "more specific
>      ranges required". After receiving such an error, the initiator can
>      guarantee success next time by putting in the specifics of the
>      packet into the first TSi and first TSr.

I'm confused, please see above.

> By the way, it's 12 bytes for
> each one, so it's 24 bytes of overhead to include
> this information.
> 
> I'm confused about what a firewall is supposed to do if it's just
> configured that when it comes up it creates a set of SAs, and there
> is no specific packet that is triggering the SA creation. I suppose
> that's just a misconfiguration between the policies of the two sides?

With generalized suggestion it's easy to achieve: initiator just put 
the desirable SA selector into the first TSi and TSr.

> Radia

Regards,
Valery Smyslov.