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

Tero Kivinen <kivinen@iki.fi> Thu, 22 April 2010 11:09 UTC

Return-Path: <kivinen@iki.fi>
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 03B0A3A6A42 for <ipsec@core3.amsl.com>; Thu, 22 Apr 2010 04:09:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Level:
X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[AWL=0.592, 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 CKvofppDMl-U for <ipsec@core3.amsl.com>; Thu, 22 Apr 2010 04:09:28 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id B943C3A6A3C for <ipsec@ietf.org>; Thu, 22 Apr 2010 04:09:27 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id o3MB9CF1002585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Apr 2010 14:09:12 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o3MB9C0D023988; Thu, 22 Apr 2010 14:09:12 +0300 (EEST)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <19408.11864.296682.634981@fireball.kivinen.iki.fi>
Date: Thu, 22 Apr 2010 14:09:12 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: V Jyothi-B22245 <B22245@freescale.com>
In-Reply-To: <402621A7D69DDA458D0E12F070D1E55F7D4853@zin33exm29.fsl.freescale.net>
References: <20100414221506.0E8D23A6ABA@core3.amsl.com> <402621A7D69DDA458D0E12F070D1E55F7D4853@zin33exm29.fsl.freescale.net>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 3 min
X-Total-Time: 3 min
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 11:09:29 -0000

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