A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA)
RFC 6023

Document Type RFC - Experimental (October 2010; No errata)
Last updated 2015-10-14
Stream ISE
Formats plain text pdf html
Stream ISE state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 6023 (Experimental)
Telechat date
Responsible AD spt
Send notices to rsj@cisco.com, rfc-ise@rfc-editor.org
Independent Submission                                            Y. Nir
Request for Comments: 6023                                   Check Point
Category: Experimental                                     H. Tschofenig
ISSN: 2070-1721                                                      NSN
                                                                 H. Deng
                                                            China Mobile
                                                                R. Singh
                                                            October 2010

                       A Childless Initiation of
 the Internet Key Exchange Version 2 (IKEv2) Security Association (SA)


   This document describes an extension to the Internet Key Exchange
   version 2 (IKEv2) protocol that allows an IKEv2 Security Association
   (SA) to be created and authenticated without generating a Child SA.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and

   This document defines an Experimental Protocol for the Internet
   community.  This is a contribution to the RFC Series, independently
   of any other RFC stream.  The RFC Editor has chosen to publish this
   document at its discretion and makes no statement about its value for
   implementation or deployment.  Documents approved for publication by
   the RFC Editor are not a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at

Nir, et al.                   Experimental                      [Page 1]
RFC 6023               Childless IKEv2 Initiation           October 2010

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

1.  Introduction

   IKEv2, as specified in [RFC5996], requires that the IKE_AUTH exchange
   try to create a Child SA along with the IKEv2 SA.  This requirement
   is sometimes inconvenient or superfluous, as some implementations
   need to use IKEv2 for authentication only, while others would like to
   set up the IKEv2 SA before there is any actual traffic to protect.
   The extension described in this document allows the creation of an
   IKEv2 SA without also attempting to create a Child SA.  The terms
   IKEv2, IKEv2 SA, and Child SA and the various IKEv2 exchanges are
   defined in [RFC5996]

   An IKEv2 SA without any Child SA is not a fruitless endeavor.  Even
   without Child SAs, an IKEv2 SA allows:

   o  Checking the liveness status of the peer via liveness checks.

   o  Quickly setting up Child SAs without public key operations and
      without user interaction.

   o  Authentication of the peer.

   o  Detection of NAT boxes between two hosts on the Internet.

1.1.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

Nir, et al.                   Experimental                      [Page 2]
RFC 6023               Childless IKEv2 Initiation           October 2010

2.  Usage Scenarios

   Several scenarios motivated this proposal:

   o  Interactive remote access VPN: the user tells the client to
      "connect", which may involve interactive authentication.  There is
      still no traffic, but some may come later.  Since there is no
      traffic, it is impossible for the gateway to know what selectors
      to use (how to narrow down the client's proposal).

   o  Location-aware security, as in [SecureBeacon].  The user is
      roaming between trusted and untrusted networks.  While in an
      untrusted network, all traffic should be encrypted, but on the
      trusted network, only the IKEv2 SA needs to be maintained.

   o  An IKEv2 SA may be needed between peers even when there is not
      IPsec traffic.  Such IKEv2 peers use liveness checks, and report
      to the administrator the status of the "VPN links".
Show full document text