[IPsec] Is IKEv2 mandatory to implement?

Tero Kivinen <kivinen@iki.fi> Fri, 30 April 2010 08:48 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 626E03A68A9 for <ipsec@core3.amsl.com>; Fri, 30 Apr 2010 01:48:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.884
X-Spam-Level:
X-Spam-Status: No, score=-0.884 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_40=-0.185]
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 24LJied8xSzn for <ipsec@core3.amsl.com>; Fri, 30 Apr 2010 01:47:59 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 162EF3A69C8 for <ipsec@ietf.org>; Fri, 30 Apr 2010 01:47:58 -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 o3U8leEM006810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Apr 2010 11:47:40 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id o3U8ldBX021424; Fri, 30 Apr 2010 11:47:39 +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: <19418.39211.806428.816790@fireball.kivinen.iki.fi>
Date: Fri, 30 Apr 2010 11:47:39 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Thomas Narten <narten@us.ibm.com>
In-Reply-To: <201004291853.o3TIrpe6014408@cichlid.raleigh.ibm.com>
References: <201004291853.o3TIrpe6014408@cichlid.raleigh.ibm.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 6 min
X-Total-Time: 5 min
Cc: ipsec@ietf.org
Subject: [IPsec] Is IKEv2 mandatory to implement?
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: Fri, 30 Apr 2010 08:48:00 -0000

Thomas Narten writes:
> Is there more specific wording in 4301 on this point? Is it viewed as
> an absolute MUST requirement to implement IKEv2 in order to claim
> compliance with RFC4301?

RFC4301 says in section 4.5:
----------------------------------------------------------------------
4.5.  SA and Key Management

   All IPsec implementations MUST support both manual and automated SA
   and cryptographic key management.  ...
...

4.5.2.  Automated SA and Key Management

   Widespread deployment and use of IPsec requires an Internet-standard,
   scalable, automated, SA management protocol.  Such support is
   required to facilitate use of the anti-replay features of AH and ESP,
   and to accommodate on-demand creation of SAs, e.g., for user- and
   session-oriented keying.  (Note that the notion of "rekeying" an SA
   actually implies creation of a new SA with a new SPI, a process that
   generally implies use of an automated SA/key management protocol.)

   The default automated key management protocol selected for use with
   IPsec is IKEv2 [Kau05].  This document assumes the availability of
   certain functions from the key management protocol that are not
   supported by IKEv1.  Other automated SA management protocols MAY be
   employed.
...
----------------------------------------------------------------------

I.e. automated key management is mandatory, but the automated key
management protocol can also be something else than IKEv2, but for
example IKEv1 is NOT enough, as certain functions required by RFC4301
are missing.

I do not think there currently exists any other automated key
management protocol that could be used for RFC4301 than IKEv2. 
-- 
kivinen@iki.fi