Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-10.txt

"V Jyothi-B22245" <B22245@freescale.com> Thu, 22 April 2010 12:42 UTC

Return-Path: <B22245@freescale.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 8C99F3A69EC for <ipsec@core3.amsl.com>; Thu, 22 Apr 2010 05:42:57 -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 os4M2SLzWq+m for <ipsec@core3.amsl.com>; Thu, 22 Apr 2010 05:42:56 -0700 (PDT)
Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) by core3.amsl.com (Postfix) with ESMTP id BA4D43A6807 for <ipsec@ietf.org>; Thu, 22 Apr 2010 05:42:56 -0700 (PDT)
Received: from de01smr02.am.mot.com (de01smr02.freescale.net [10.208.0.151]) by az33egw02.freescale.net (8.14.3/az33egw02) with ESMTP id o3MCgV3g008450 for <ipsec@ietf.org>; Thu, 22 Apr 2010 05:42:36 -0700 (MST)
Received: from zin33exm29.fsl.freescale.net (zin33exm29.ap.freescale.net [10.232.192.28]) by de01smr02.am.mot.com (8.13.1/8.13.0) with ESMTP id o3MCqPUb015926 for <ipsec@ietf.org>; Thu, 22 Apr 2010 07:52:26 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 22 Apr 2010 18:12:27 +0530
Message-ID: <402621A7D69DDA458D0E12F070D1E55F7D4883@zin33exm29.fsl.freescale.net>
In-Reply-To: <19408.11864.296682.634981@fireball.kivinen.iki.fi>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-10.txt
Thread-Index: AcriDEZyKUZFMXEIQ3KJvXagvXDaHgACqTDQ
References: <20100414221506.0E8D23A6ABA@core3.amsl.com><402621A7D69DDA458D0E12F070D1E55F7D4853@zin33exm29.fsl.freescale.net> <19408.11864.296682.634981@fireball.kivinen.iki.fi>
From: V Jyothi-B22245 <B22245@freescale.com>
To: Tero Kivinen <kivinen@iki.fi>
Cc: ipsec@ietf.org
Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-10.txt
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: Thu, 22 Apr 2010 12:42:57 -0000

Hi,

I find an issue in case of minimal implementations.
Minimal implementations may not support CREATE_CHILD_SA exchanges, CHILD
SA gets created as part of AUTH exchange.

In this case, if the responder sends SINGLE_PAIR_REQUIRED, minimal
implementations cannot start CREATE_CHILD_SA exchange and minimal
implementation should not establish IKE SA because CHILD SA is not yet
established and it may not be right solution to maintain the
SINGLE_PAIR_REQUIRED notify reception information to use it in new IKEv2
exchange.
Instead initiator can try sending AUTH request with single traffic
selectors.

Thanks
Jyothi


-----Original Message-----
From: Tero Kivinen [mailto:kivinen@iki.fi] 
Sent: Thursday, April 22, 2010 4:39 PM
To: V Jyothi-B22245
Cc: ipsec@ietf.org
Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-ikev2bis-10.txt

V Jyothi-B22245 writes:
> Hi,
> 
> In section 2.9.  Traffic Selector Negotiation,
> 
> The SINGLE_PAIR_REQUIRED error indicates that a CREATE_CHILD_SA
>    request is unacceptable because its sender is only willing to
accept
>    traffic selectors specifying a single pair of addresses.  The
>    requestor is expected to respond by requesting an SA for only the
>    specific traffic it is trying to forward.
> 
> Above paragraph gives the clarity of what action to take when 
> SINGLE_PAIR_REQUIRED notify type received in case of CREATE_CHILD_SA 
> exchanges.
> 
> Suppose if the SINGLE_PAIR_REQUIRED notify type is received in AUTH 
> response, how initiator should act upon it?
> Can initiator resend AUTH request with different TSi and TSr payloads 
> or it should establish IKE SA and then start CREATE_CHILD_SA exchange?

It will establish IKE SA even when the Child SA creation failed.

What it does next depends on the implementation. Normal implementation
will simply do CREATE_CHILD_SA with better traffic selectors, and create
Child SA that way. Some implementation might simply mark the specific
rule so that it requires exact traffic selectors, and wait for next
packet hitting that rule before starting CREATE_CHILD_SA (this is needed
if the first Child SA creation in the IKE_AUTH was done because of
auto-start rule, i.e. there is no traffic yet, thus the initiator does
not know the exact traffic selectors).
--
kivinen@iki.fi