Re: [IPsec] Closing the IKEv2bis open issues

Yoav Nir <ynir@checkpoint.com> Wed, 21 October 2009 07:46 UTC

Return-Path: <ynir@checkpoint.com>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F05F3A67AB for <ipsec@core3.amsl.com>; Wed, 21 Oct 2009 00:46:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JWMinlihQv2 for <ipsec@core3.amsl.com>; Wed, 21 Oct 2009 00:46:43 -0700 (PDT)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 017863A683D for <ipsec@ietf.org>; Wed, 21 Oct 2009 00:46:28 -0700 (PDT)
X-CheckPoint: {4ADEBA1D-1-14201DC2-FFFF}
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 6868C29C00A; Wed, 21 Oct 2009 09:46:32 +0200 (IST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 4B48029C002; Wed, 21 Oct 2009 09:46:32 +0200 (IST)
X-CheckPoint: {4ADEBA19-0-14201DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n9L7kVhu021133; Wed, 21 Oct 2009 09:46:31 +0200 (IST)
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 21 Oct 2009 09:46:34 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Date: Wed, 21 Oct 2009 09:46:27 +0200
Thread-Topic: [IPsec] Closing the IKEv2bis open issues
Thread-Index: AcpSIpvyBE5/xFaNTsGzXCEQTI/0pQ==
Message-ID: <349076FF-487D-4B6C-91EB-1E845B2303F6@checkpoint.com>
References: <p06240849c7039304f1d1@[10.20.30.158]>
In-Reply-To: <p06240849c7039304f1d1@[10.20.30.158]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/signed; micalg="sha1"; boundary="Apple-Mail-15-778597419"; protocol="application/pkcs7-signature"
MIME-Version: 1.0
Cc: IPsecme WG <ipsec@ietf.org>
Subject: Re: [IPsec] Closing the IKEv2bis open issues
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Oct 2009 07:46:43 -0000

A few lines above this section it already says "If the responder's  
policy allows it to accept the first selector of TSi and TSr, then the  
responder MUST narrow the traffic selectors to a subset that includes  
the initiator's first choices."

So there is a MUST requirement to select the initiator's first choice  
(if possible), so I don't think the SHOULD and MAY are appropriate  
here. The way I read this section, it only clarifies what to do if the  
initiator traffic selector (first or not) is too broad. In that case,  
we shouldn't mention the initiator's choices.

On Oct 20, 2009, at 6:19 PM, Paul Hoffman wrote:

> Issue #25, Choice of the right TS when narrowing
<snip/>
> Proposed change:
>   When narrowing is done, there may be several subsets that are
>   acceptable but their union is not.  In this case, the responder
>   SHOULD select the initiator's first choice (to be interoperable
>   with RFC 4306), but MAY arbitrarily select any of them,
>   and MAY include an
>   ADDITIONAL_TS_POSSIBLE notification in the response.