Re: Ikev2 Traffic Selector payload

["David Faucher" <dfaucher@lucent.com>]

I agree with this, 12 bytes is a small price to pay
for better interoperability.


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


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