[IPsec] ikev2bis issue #185: What do to if you don't ignore INITIAL_CONTACT

Tero Kivinen <kivinen@iki.fi> Thu, 01 April 2010 12:54 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 6A42F3A6D50 for <ipsec@core3.amsl.com>; Thu, 1 Apr 2010 05:54:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.23
X-Spam-Level:
X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13]
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 Tes+pBUynC70 for <ipsec@core3.amsl.com>; Thu, 1 Apr 2010 05:54:24 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 52B5E3A6B4B for <ipsec@ietf.org>; Thu, 1 Apr 2010 05:43:54 -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 o31CiMBn004080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Apr 2010 15:44:22 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o31CiLpg015496; Thu, 1 Apr 2010 15:44:21 +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: <19380.38181.281545.884988@fireball.kivinen.iki.fi>
Date: Thu, 01 Apr 2010 15:44:21 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <p0624080bc7d840022266@[10.20.30.158]>
References: <p0624080bc7d840022266@[10.20.30.158]>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 5 min
X-Total-Time: 4 min
Cc: IPsecme WG <ipsec@ietf.org>
Subject: [IPsec] ikev2bis issue #185: What do to if you don't ignore INITIAL_CONTACT
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, 01 Apr 2010 12:54:25 -0000

Paul Hoffman writes:
> s2.4, para 2, says "The INITIAL_CONTACT notification, if sent, MUST
> be in the first IKE_AUTH request or response, not as a separate
> exchange afterwards; receiving parties MAY ignore it in other
> messages." 
> 
> What should receiving parties do if they *do* receive it and *don't*
> ignore it? Since it 'MUST be sent in the first IKE_AUTH' receiving
> at any other time is a protocol error and should cause some response
> (like dropping the IKE_SA perhaps). 

They either need to process is it or ignore it. The reason why we say
it MUST be sent on first IKE_AUTH request or response, but MAY be
ignored in other messages is because the original RFC4306 didn't have
any restrictions where the INITIAL_CONTACT notification can be sent,
thus to maintain backward compatiblity we still do allow it to be sent
on other messages too, but implementations MAY ignore it there (the
other option is to act based on it). Failing the IKE SA because the
INITIAL_CONTACT notification was sent with other message would be
incorrect, as we do not say INITIAL_CONTACT MUST NOT be sent anywhere
else.

I.e. even when we say it MUST be somewhere, that does not directly
mean it would be protocol error to include it in some where else,
especially when we indicate that it can be ignored on other messages. 
-- 
kivinen@iki.fi