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

Tero Kivinen <kivinen@iki.fi> Thu, 22 April 2010 13:16 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 6E1943A69F3 for <ipsec@core3.amsl.com>; Thu, 22 Apr 2010 06:16:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.073
X-Spam-Level:
X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.526, 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 XHCt2OZRWxE4 for <ipsec@core3.amsl.com>; Thu, 22 Apr 2010 06:16:21 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 47D1828C136 for <ipsec@ietf.org>; Thu, 22 Apr 2010 06:15:40 -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 o3MDFK7l015670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Apr 2010 16:15:20 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o3MDFJLr011426; Thu, 22 Apr 2010 16:15:19 +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.19431.354722.531641@fireball.kivinen.iki.fi>
Date: Thu, 22 Apr 2010 16:15:19 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: V Jyothi-B22245 <B22245@freescale.com>
In-Reply-To: <402621A7D69DDA458D0E12F070D1E55F7D4883@zin33exm29.fsl.freescale.net>
References: <20100414221506.0E8D23A6ABA@core3.amsl.com> <402621A7D69DDA458D0E12F070D1E55F7D4853@zin33exm29.fsl.freescale.net> <19408.11864.296682.634981@fireball.kivinen.iki.fi> <402621A7D69DDA458D0E12F070D1E55F7D4883@zin33exm29.fsl.freescale.net>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 10 min
X-Total-Time: 20 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 13:16:22 -0000

V Jyothi-B22245 writes:
> 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.

Minimal implementation most likely do not understand
SINGLE_PAIR_REQUIRED either, so it will most likely simply get the IKE
SA up, and then delete it as it does not have any useful things to do
with it. 

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

Even the minimal implementation is required to set up the IKE SA even
when the Child SA exchange in the IKE_AUTH failed:
----------------------------------------------------------------------
1.2.  The Initial Exchanges
...
   If creating the Child SA during the IKE_AUTH exchange fails for some
   reason, the IKE SA is still created as usual.  
----------------------------------------------------------------------

So the IKE SA is up, but the next question is what the minimal
implementation can do next. If it does not support CREATE_CHILD_SA and
it does not have Child SA up, it will most likely tear down the IKE SA
by sending delete notification. If it is really minimal
implementation, then it most likely does not have any special handling
for SINGLE_PAIR_REQUIRED, and it might not even support such traffic
selectors (or they might not be allowed by policy), so most likely
some kind of policy change is required before it can connect to the
server.

In this case the IKEv2 does not always fix mismatched policy
situations automatically, and policy needs to be changed manually. I
do not consider this a problem. 

> Instead initiator can try sending AUTH request with single traffic
> selectors.

If it does that, it needs to start from the beginning i.e. from
IKE_SA_INIT as the previous IKE SA is already up and running, and it
cannot have any more IKE_AUTH exchanges, as one of them is already
finished. 
-- 
kivinen@iki.fi