Re: Ikev2 Traffic Selector payload

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

----- Original Message -----
From: "Radia Perlman - Boston Center for Networking" <Radia.Perlman@sun.com>
To: <ipsec@lists.tislabs.com>; <dfaucher@lucent.com>
Sent: Saturday, May 04, 2002 4:28 AM
Subject: Re: Ikev2 Traffic Selector payload


> From my reading of the policy database, this wouldn't happen. Bob might
> narrow the choices in one of two cases:
> a) his policy excludes the range of the original packet, in which
> case Alice can't forward this packet to Bob no matter what she does, or

What if initiator's proposal consists of one range, while responder's
SPD requires this range to be splitted into two (or more) each protected
by separate SA? For example:

Initiator's SPD:         1.1.1.1-1.1.1.100
Responder's SPD:    1.1.1.1-1.1.1.50 & 1.1.1.51-1.1.1.100

In this case responder cannot narrow initiator's proposal
because he/she doesn't know actual packet selector.

> b) his policy says only a single source/destination pair allowed on any
SA,
> in which case he responds with notification #34-single-pair-required

I think this is not very efficient way to require new negotiation (possibly
including
new DH computation) for this case.

I think the better way would be to require for initiator to always include
actual packet selector in his/her proposal. The simplest way to do it
(without any changes in the protocol format) would be to simply state in the
document,
that the very first TS in initiator's TS payload MUST be selector of the
packet that triggered this negotiation. This TS either MUST be encompassed
in the (possibly narrowed) responder's TS payload or responder MUST
return an error notification NO-PROPOSAL-CHOSEN.

This actual packet TS will help responder to correctly choose (narrow) its
TS.
The cost is that initiator's message will be greater by 12 bytes (one
TS with single address). I think it is tolerable.

Regards,
Valery Smyslov.


> Radia
> ****************
> From: "David W. Faucher" <dfaucher@lucent.com>
>
> Regarding draft-ietf-ipsec-ikev2-02.txt section 2.9:
>
>     "The Responder is allowed to narrow the choices
>      by selecting a subset of the traffic..."
>
> How do we avoid the situation where the reduced set
> does not encompass the selectors of the original packet
> on the initiator which started the negotiation?
>
> David
>
>
>