[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 6071

Network Working Group                                         S. Frankel
Internet Draft                                                      NIST
Obsoletes 2411 (if approved)                                 S. Krishnan
Intended Status: Informational                                  Ericsson
Expires: June 2009                                     December 22, 2008

  IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap
                  <draft-ietf-ipsecme-roadmap-00.txt>

Status of this Memo

   Distribution of this memo is unlimited.

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 25, 2009.

Copyright and License Notice

   Copyright (c) 2008 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.






Frankel & Krishnan         Expires June 2009                    [Page 1]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


Abstract

   Over the past few years, the number of RFCs that define and use IPsec
   and IKE has greatly proliferated.  This is complicated by the fact
   that these RFCs originate from numerous IETF working groups: the
   original IPsec WG, its various spin-offs, and other WGs that use
   IPsec and/or IKE to protect their protocols' traffic.

   This document is a snapshot of IPsec- and IKE-related RFCs.  It
   includes a brief description of each RFC, along with background
   information explaining the motivation and context of IPsec's
   outgrowths and extensions.  It obsoletes the previous IPsec Document
   Roadmap [RFC2411].

                             Table of Contents

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  IPsec/IKE Background Information . . . . . . . . . . . . . . . .   4
   2.1.  Interrelationship of IPsec/IKE Documents  . . . . . . . . .   4
   2.2.  Versions of IPsec . . . . . . . . . . . . . . . . . . . . .   5
   2.2.1.     Differences between "old" IPsec (IPsec-v2) and
              "new" IPsec (IPsec-v3) . . . . . . . . . . . . . . . .   5
   2.3.  Versions of IKE . . . . . . . . . . . . . . . . . . . . . .   6
   2.3.1.     Differences between IKEv1 and IKEv2  . . . . . . . . .   6
   2.4.  IPsec and IKE IANA Registries . . . . . . . . . . . . . . .   7
3.  IPsec Documents  . . . . . . . . . . . . . . . . . . . . . . . .   8
   3.1.  Base Documents  . . . . . . . . . . . . . . . . . . . . . .   8
     3.1.1.  "Old" IPsec . . . . . . . . . . . . . . . . . . . . . .   8
     3.1.2.  "New" IPsec . . . . . . . . . . . . . . . . . . . . . .  10
   3.2.  Policy  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   3.3.  MIBs  . . . . . . . . . . . . . . . . . . . . . . . . . . .  11
   3.4.  Additions to IPsec  . . . . . . . . . . . . . . . . . . . .  11
   3.5.  General Considerations  . . . . . . . . . . . . . . . . . .  12
4.  IKE Documents  . . . . . . . . . . . . . . . . . . . . . . . . .  12
   4.1.  Base Documents  . . . . . . . . . . . . . . . . . . . . . .  12
     4.1.1.  IKEv1 . . . . . . . . . . . . . . . . . . . . . . . . .  12
     4.1.2.  IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . .  13
   4.2.  Additions and Extensions  . . . . . . . . . . . . . . . . .  14
     4.2.1.  Peer Authentication Methods . . . . . . . . . . . . . .  14
     4.2.2.  Certificate Contents and Management . . . . . . . . . .  14
     4.2.3.  Dead Peer Detection . . . . . . . . . . . . . . . . . .  15
     4.2.4.  Remote Access . . . . . . . . . . . . . . . . . . . . .  15
5.  Cryptographic Algorithms and Suites  . . . . . . . . . . . . . .  16
   5.1.  Algorithm Requirements  . . . . . . . . . . . . . . . . . .  16
   5.2.  Encryption Algorithms . . . . . . . . . . . . . . . . . . .  17
   5.3.  Integrity-Protection (Authentication) Algorithms  . . . . .  19
     5.3.1.  General Considerations  . . . . . . . . . . . . . . . .  22
   5.4.  Combined Algorithms . . . . . . . . . . . . . . . . . . . .  22



Frankel & Krishnan         Expires June 2009                    [Page 2]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


     5.4.1.  General Considerations  . . . . . . . . . . . . . . . .  23
   5.5.  Pseudo-Random Functions (PRFs)  . . . . . . . . . . . . . .  23
   5.6.  Cryptographic Suites  . . . . . . . . . . . . . . . . . . .  24
   5.7.  Diffie-Hellman Algorithms . . . . . . . . . . . . . . . . .  24
6.  IPsec/IKE for Multicast  . . . . . . . . . . . . . . . . . . . .  26
7.  Outgrowths of IPsec/IKE  . . . . . . . . . . . . . . . . . . . .  27
   7.1.  IPComp (Compression)  . . . . . . . . . . . . . . . . . . .  27
   7.2.  IKEv2 Mobility and Multihoming (MobIKE) . . . . . . . . . .  27
   7.3.  Better-than-Nothing Security (Btns) . . . . . . . . . . . .  28
   7.4.  Kerberized Internet Negotiation of Keys (Kink)  . . . . . .  29
   7.5.  IPsec Secure Remote Access (IPSRA)  . . . . . . . . . . . .  29
   7.6.  IPsec Keying Information Resource Record (IPsecKEY) . . . .  29
8.  Other Protocols that use IPsec/IKE . . . . . . . . . . . . . . .  30
   8.1.  Mobile IP (MIPv4 and MIPv6) . . . . . . . . . . . . . . . .  30
   8.2.  Open Shortest Path First (OSPF) . . . . . . . . . . . . . .  30
   8.3.  Host Identity Protocol (HIP)  . . . . . . . . . . . . . . .  30
   8.4.  Extensible Authentication Protocol (EAP) Method Update
         (EMU) . . . . . . . . . . . . . . . . . . . . . . . . . . .  31
   8.5.  Stream Control Transmission Protocol (SCTP) . . . . . . . .  31
   8.6.  Fibre Channel . . . . . . . . . . . . . . . . . . . . . . .  31
   8.7.  Protocol for Carrying Authentication for Network Access
         (PANA)  . . . . . . . . . . . . . . . . . . . . . . . . . .  31
9.  Security Considerations  . . . . . . . . . . . . . . . . . . . .  31
10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . .  31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . .  31
   11.1. Normative References  . . . . . . . . . . . . . . . . . . .  31
   11.2. Informative References  . . . . . . . . . . . . . . . . . .  31

1.  Introduction

   IPsec is a suite of protocols that provides security to Internet
   communications at the IP layer.  The most common current use of IPsec
   is to provide a Virtual Private Network (VPN), either between two
   locations (gateway-to-gateway) or between a remote user and an
   enterprise network (host-to-gateway); it can also provide end-to-end,
   or host-to-host, security.  IPsec is also used by other Internet
   protocols (e.g. MIPv6) to protect some or all of their traffic.

   In addition to the base documents for IPsec and IKE, there are
   numerous RFCs that reference, extend, and in some cases alter the
   core specifications.  This document is an attempt to list and briefly
   describe those RFCs, providing context and rationale where indicated.
   The title of each RFC is followed by a letter that indicates its
   category in the RFC series [RFC2026], as follows:

      o S: Standards Track (Proposed Standard, Draft Standard, or
           Standard)




Frankel & Krishnan         Expires June 2009                    [Page 3]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


      o E: Experimental

      o B: Best Current Practice

      o I: Informational

   For each RFC, the publication date is also given.

   The usage of terms in this document conforms to definitions in
   [RFC4949].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  IPsec/IKE Background Information

2.1.  Interrelationship of IPsec/IKE Documents

   The main documents describing the set of IPsec protocols are divided
   into seven groups.  This is illustrated in Figure 1.  There is a main
   Architecture document which broadly covers the general concepts,
   security requirements, definitions, and mechanisms defining IPsec
   technology.

   There are an ESP Protocol document and an AH Protocol document which
   cover the packet format and general issues regarding the respective
   protocols.  The "Encryption Algorithm" document set, shown on the
   left, is the set of documents describing how various encryption
   algorithms are used for ESP.  The "Combined Algorithm" document set,
   shown in the middle, is the set of documents describing how various
   combined algorithms are used to provide both encryption and
   integrity-protection for ESP.  The "Integ-Protection Algorithm"
   document set, shown on the right, is the set of documents describing
   how various integrity-protection algorithms are used for both ESP and
   AH.

   The "IKE Documents", shown at the bottom, are the documents
   describing the IETF standards-track key management schemes.












Frankel & Krishnan         Expires June 2009                    [Page 4]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


                               +--------------+
                               | Architecture |
                               +--------------+
                                  v         v
                 +<-<-<-<-<-<-<-<-+         +->->->->->->->->+
                 v                                           v
        +----------+                                      +----------+
        |   ESP    |                                      |    AH    |
        | Protocol |                                      | Protocol |
        +----------+                                      +----------+
          v      v                                          v       v
          v      +->->->->->->->->+->->->->->->->->+        v       v
          v      v                v                v        v       v
          v      v                v                v        v       v
          v  +------------+   +-----------+    +----------------+   v
          v  | +------------+ | +------------+ | +----------------+ v
          v  | | Encryption | | | Combined   | | |Integ-Protection| v
          v  +-| Algorithm  | +-| Algorithm  | +-| Algorithm      | v
          v    +------------+   +------------+   +----------------+ v
          v        v                  v                   v         v
          v        v                  v                   v         v
          +>->->->-+->->->->->->->->->--<-<-<-<-<-<-<-<-<-+-<-<-<-<-+
                                      ^
                                      ^
                                +------------+
                                |    IKE     |
                                |  Protocol  |
                                +------------+

2.2.  Versions of IPsec

   Two versions of IPsec can currently be found in implementations.  The
   "new" IPsec (referred to as IPsec-v3 in this document) obsoleted the
   "old" IPsec (referred to as IPsec-v2 in this document); however,
   IPsec-v2 is still commonly found in operational use.  In this
   document, when the unqualified term IPsec is used, it pertains to
   both versions of IPsec.  An earlier version of IPsec, obsoleted by
   IPsec-v2, is not covered in this document.

2.2.1.  Differences between "old" IPsec (IPsec-v2) and "new" IPsec
   (IPsec-v3)

   IPsec-v3 incorporates "lessons learned" from implementation and
   operational experience with IPsec-v2 and its predecessor, IPsec-v1.
   Knowledge was gained about the barriers to IPsec deployment, the
   scenarios in which IPsec is most effective, and requirements that
   needed to be added to IPsec to facilitate its use in other protocols.
   In addition, the documentation for IPsec-v3 clarifies and expands



Frankel & Krishnan         Expires June 2009                    [Page 5]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


   details that were underspecified or ambiguous in IPsec-v2.

   Changes to the architecture document [RFC4301] include:

      o More detailed descriptions of IPsec processing, both unicast and
        multicast, and the interactions among the various IPsec
        databases

      o In IPsec-v2, an SA (Security Association) is uniquely identified
        by a combination of the SPI (Security Parameters Index),
        protocol (ESP or AH), and destination address. In IPsec-v3, a
        unicast SA is uniquely identified by the SPI and, optionally, by
        the protocol; a multicast SA is identified by a combination of
        the SPI and the destination address and, optionally, the source
        address.

      o More flexible SPD (Security Policy Database) selectors,
        including ranges of values and ICMP message types as selectors

      o Decorrelated (order-independent) SAD (Security Association
        Database) replaced the former ordered SAD

      o Added extended sequence numbers (ESNs)

      o Mandatory algorithms defined in standalone document

      o AH [RFC4302] is mandatory-to-implement (MUST) in IPsec-v2,
        optional (MAY) in IPsec-v3

   Changes to ESP [RFC4303] include:

      o Added combined mode algorithms, necessitating changes to packet
        format and processing

      o NULL authentication, mandatory (MUST) in ESP-v2, is optional
        (MAY) in ESP-v3

2.3.  Versions of IKE

   Two versions of IKE can currently be found in implementations.  The
   "new" IKE (generally referred to as IKEv2) obsoleted the "old" IKE
   (generally referred to as IKEv1); however, IKEv1 is still commonly
   found in operational use.  In this document, when the unqualified
   term IKE is used, it pertains to both versions of IKE.

2.3.1.  Differences between IKEv1 and IKEv2

   As with IPsec-v3, IKEv2 incorporates "lessons learned" from



Frankel & Krishnan         Expires June 2009                    [Page 6]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


   implementation and operational experience with IKEv1.  Knowledge was
   gained about the barriers to IKE deployment, the scenarios in which
   IKE is most effective, and requirements that needed to be added to
   IKE to facilitate its use in other protocols as well as in
   general-purpose use.  The documentation for IKEv2 replaces multiple,
   at time contradictory documents, with a single document; it also
   clarifies and expands details that were underspecified or ambiguous
   in IKEv1.

   Once an IKE negotiation is successfully completed, the peers have
   established two pairs of one-way (inbound and outbound) SAs.  The
   first SA, the IKE SA, is used to protect IKE traffic.  The second SA,
   called the IPsec SA in IKEv1 and the child SA in IKEv2, provides
   IPsec protection to data traffic between the peers.  This document
   uses the term "IPsec SA".

   Changes to IKE include:

      o Multiple alternate exchange types replaced by a single, shorter
        exchange

      o Streamlined negotiation format to avoid combinatorial bloat for
        multiple proposals

      o Protects responder from committing significant resources to the
        exchange until the initiator's existence and identity are
        confirmed

      o Reliable exchanges: Every request expects a response

      o Protection of IKE messages based on ESP, rather than a method
        unique to IKE

      o Add traffic selectors: distinct from peer IDs and more flexible

2.4.  IPsec and IKE IANA Registries

   Numerous IANA registries contain values that are used in IPsec, IKE
   and related protocols.  They include:

      o  IKE Attributes
        (http://www.iana.org/assignments/ipsec-registry): values used
        during IKEv1 Phase 1 exchanges, defined in [RFC2409]

      o "Magic Numbers" for ISAKMP Protocol
        (http://www.iana.org/assignments/isakmp-registry): values used
        during IKEv1 Phase 2 exchanges, defined in [RFC2407], [RFC2408]
        and numerous other cryptographic algorithm RFCs



Frankel & Krishnan         Expires June 2009                    [Page 7]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


      o IKEv2 Parameters
        (http://www.iana.org/assignments/ikev2-parameters): values used
        in IKEv2 exchanges, defined in [RFC4306] and numerous other
        cryptographic algorithm RFCs

      o Cryptographic Suites for IKEv1, IKEv2, and IPsec
        (http://www.iana.org/assignments/crypto-suites): names of
        cryptographic suites in [RFC4308] and [RFC4869]

      o Multimedia Internet KEYing (Mikey) Payload Name Spaces
        (http://www.iana.org/assignments/mikey-payloads): values used in
        MIKEY negotiations, defined in [RFC3830] and other multicast
        IPsec/IKE RFCs

      o IPseckey Resource Record Parameters
        (http://www.iana.org/assignments/ipseckey-rr-parameters): values
        used in IPsecKEY resource records, defined in [RFC4025]

      o Extensible Authentication Protocol-Internet Key Exchange Version
        2 (EAP-IKEv2) Payloads
        (http://www.iana.org/assignments/eap-ikev2-payloads): payload
        types used in EAP-IKEv2 [RFC5106]

3.  IPsec Documents

3.1.  Base Documents

   IPsec protections are provided by two extension headers: the
   Encapsulating Security Payload (ESP) Header and the Authentication
   Header (AH).  There are 3 base documents: one that describes the IP
   security architecture, and one for each of the IPsec headers.


3.1.1.  "Old" IPsec

      o RFC 2401, Security Architecture for the Internet Protocol (S,
        Nov. 1998)

   [RFC2401] specifies the the mechanisms, procedures and components
   required to provide security services at the IP layer.  It also
   describes their interrelationship, and the general processing
   required to inject IPsec protections into the network architecture.

   The components include:

         - SA (Security Association): a one-way (inbound or outbound)
   agreement between two communicating peers that specifies the IPsec
   protections to be provided to their communications.  This includes



Frankel & Krishnan         Expires June 2009                    [Page 8]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


   the specific security protections, cryptographic algorithms, and
   secret keys to be applied, as well as the specific types of traffic
   to be protected.

         - SPI (Security Parameters Index): a value that, together with
   the Destination Address and security protocol (AH or ESP), uniquely
   identifies a single SA

         - SAD (Security Association Database): each peer's SA
   repository.  The RFC describes how this database functions (SA
   lookup, etc.) and the types of information it must contain to
   factilitate SA processing; it does not dictate the format or layout
   of the database.  SAs can be established in either transport mode or
   tunnel mode (see below).

         - SPD (Security Policy Database): an ordered database that
   expresses the security protections to be afforded to different types
   and classes of traffic.  The 3 general classes of traffic are:
   traffic to be discarded, traffic that is allowed without IPsec
   protection, and traffic that requires IPsec protection.

   The RFC describes general inbound and outbound IPsec processing; it
   also includes details on several special cases: packet fragments,
   ICMP messages, and multicast traffic.

      o RFC 2402, IP Authentication Header (S, Nov. 1998)

   [RFC2402] defines the Authentication Header (AH), which provides
   integrity protection; it also provides data origin authentication,
   access control, and, optionally, replay protection.  A transport mode
   AH SA, used to protect peer-to-peer communications, protects
   upper-layer data, as well as those portions of the IP header that do
   not vary unpredictably during packet delivery.  A tunnel mode AH SA
   can be used to protect gateway-to-gateway or host-to-gateway traffic;
   it can optionally be used for host-to-host traffic.  This class of AH
   SA protects the inner (original) header and upper-layer data, as well
   as those portions of the outer (tunnel) header that do not vary
   unpredictably during packet delivery.  Because portions of the IP
   header are not included in the AH calculations, AH processing is more
   complex than ESP processing.  AH also does not work in the presence
   of Network Address Translation (NAT).  Unlike IPsec-v3, IPsec-v2
   classifies AH as mandatory-to-implement.

      o RFC 2406, IP Encapsulating Security Payload (ESP) (S, Nov. 1998)

   [RFC2406] defines the IP Encapsulating Security Payload (ESP), which
   provides confidentiality (encryption) and/or integrity protection; it
   also provides data origin authentication, access control, and,



Frankel & Krishnan         Expires June 2009                    [Page 9]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


   optionally, replay and/or traffic analysis protection.  A transport
   mode ESP SA protects the upper-layer data, but not the IP header.  A
   tunnel mode ESP SA protects the upper-layer data and the inner
   header, but not the outer header.

3.1.2.  "New" IPsec

      o RFC 4301, Security Architecture for the Internet Protocol (S,
        Dec. 2005)

   [RFC4301] updates [RFC2401], including a more complete and detailed
   processing model.  The most notable changes are detailed above in
   Section 2.2.1.  IPsec-v3 processing incorporates an additional
   database:

         - PAD (Peer Authorization Database): contains information
   necessary to conduct peer authentication, providing a link between
   IPsec and the key management procotol (e.g. IKE)

      o RFC 4302, IP Authentication Header (S, Dec. 2005)

   [RFC4302] updates [RFC2402].  Unlike IPsec-v2, IPsec-v3 classifies AH
   as optional.

      o RFC 4303, IP Encapsulating Security Payload (ESP) (S, Dec. 2005)

   [RFC4303] updates [RFC2406].  The most notable changes are detailed
   above in Section 2.2.1.


3.2.  Policy

   The IPsec Policy Working Group (ipsp) originally planned an RFC that
   would allow entities with no common Trust Anchor and no prior
   knowledge of each others' security policies to establish an
   IPsec-protected connection.  The solutions that were proposed for
   gateway discovery and security policy negotiation proved to be overly
   complex and fragile, in the absence of prior knowledge or compatible
   configuration policies.

      o RFC 3586, IP Security Policy (IPSP) Requirements (S, Aug. 2003)

   [RFC3586] describes the functional requirements of a generalized
   IPsec policy framework, that could be used to discover, negotiate and
   manage IPsec policies.

      o RFC 3585, IPsec Configuration Policy Information Model (S, Aug.
        2003)



Frankel & Krishnan         Expires June 2009                   [Page 10]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


   As stated in [RFC3585], "This document presents an object-oriented
   information model of IP Security (IPsec) policy designed to
   facilitate agreement about the content and semantics of IPsec policy,
   and enable derivations of task-specific representations of IPsec
   policy such as storage schema, distribution representations, and
   policy specification languages used to configure IPsec-enabled
   endpoints."


3.3.  MIBs

   Over the years, several MIB-related Internet Drafts were proposed for
   IPsec and IKE, but only one progressed to RFC status.

      o RFC 4807, IPsec Security Policy Database Configuration MIB (S,
        Mar. 2007)

   [RFC4807] defines a MIB module that can be used to configure the SPD
   of an IPsec device.


3.4.  Additions to IPsec

      o RFC 3947, Negotiation of NAT-Traversal in the IKE (S, Jan. 2005)

   [RFC3947] enables IKEv1 to detect whether there are any NATs between
   the negotiating peers, and whether both peers support NAT traversal.
   It also describes how IKEv1 can be used to negotiate the use of UDP
   encapsulation of ESP packets for the IPsec SA.  For IKEv2, this
   capability is described in [RFC4306].

      o RFC 4304, Extended Sequence Number (ESN) Addendum to IPsec
        Domain of Interpretation (DOI) for Internet Security Association
        and Key Management Protocol (ISAKMP) (S, Dec. 2005)

   The use of ESNs allows IPsec to use 64-bit sequence numbers for
   replay protection, but to send only 32 bits of the sequence number in
   the packet, enabling shorter packets and avoiding a re-design of the
   packet format.  The larger sequence numbers allow an existing IPsec
   SA to be used for larger volumes of data.  [RFC4304] describes an
   extension to IKEv1 to negotiate the use of ESNs for IPsec-v3 SAs.
   For IKEv2, this capability is described in [RFC4306].

      o RFC 3948, UDP Encapsulation of IPsec ESP Packets (S, Jan. 2005)

   [RFC3948] defines how to encapsulate ESP packets in UDP packets to
   enable the traversal of NATs that discard packets with protocols
   other than UDP or TCP.  This makes it possible for ESP packets to



Frankel & Krishnan         Expires June 2009                   [Page 11]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


   pass through the NAT device without requiring any change to the NAT
   device itself.  The use of this solution is negotiated by IKE, as
   described in [RFC3947] for IKEv1 and [RFC4306] for IKEv2.

      o RFC 4891, Using IPsec to Secure IPv6-in-IPv4 Tunnels (I, May
        2007)

   [RFC4891] describes how to use IKE and transport-mode IPsec to
   provide security protection to manually-configured IPv6-in-IPv4
   tunnels.  This document uses standard IKE and IPsec, without any new
   extensions.  It does not apply to tunnels that are initiated in an
   automated manner (e.g., 6to4 tunnels [RFC3056]).

      o RFC 3884, Use of IPsec Transport Mode for Dynamic Routing (I,
        Sep. 2004)

   [RFC3884] describes the use of transport-mode IPsec to secure
   IP-in-IP tunnels, which constitute the links of a multi-hop,
   distributed virtual network (VN).  This allows the traffic to be
   dynamically routed via the VN's trusted routers, rather than routing
   all traffic through a statically-routed IPsec tunnel.


      o draft-ietf-ipsecme-traffic-visibility-00.txt, Wrapped ESP for
        Traffic Visibility  (S)

3.5.  General Considerations

      o RFC 3715, IPsec-Network Address Translation (NAT) Compatibility
        Requirements (I, Mar. 2004)

   [RFC3715] "describes known incompatibilities between NAT and IPsec,
   and describes the requirements for addressing them." This is a
   critical issue, since IPsec is frequently used to provide VPN access
   to the corporate network for telecommuters, and NATs are widely
   deployed in home gateways, hotels, and other access networks
   typically used for remote access.


4.  IKE Documents

4.1.  Base Documents

4.1.1.  IKEv1

      o RFC 2409, The Internet Key Exchange (IKE) (S, Nov. 1998)

   This document defines a key exchange protocol that can be used to



Frankel & Krishnan         Expires June 2009                   [Page 12]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


   negotiate authenticated keying material for SAs.  This document
   implements a subset of the Oakley protocol in conjunction with ISAKMP
   to obtain authenticated keying material for use with ISAKMP, and for
   other security associations such as AH and ESP for the IETF IPsec
   DOI.

      o RFC 2408, Internet Security Association and Key Management
        Protocol (ISAKMP) (S, Nov. 1998)

   This document defines procedures and packet formats to establish,
   negotiate, modify and delete Security Associations (SAs).  It is
   intended to support the negotiation of SAs for security protocols at
   all layers of the network stack.  ISAKMP can work with many different
   key exchange protocols, each with different security properties.

      o RFC 2407, The Internet IP Security Domain of Interpretation for
        ISAKMP (S, Nov. 1998)

   Within ISAKMP, a Domain of Interpretation is used to group related
   protocols using ISAKMP to negotiate security associations.  Security
   protocols sharing a DOI choose security protocol and cryptographic
   transforms from a common namespace and share key exchange protocol
   identifiers.  This document defines the Internet IP Security DOI
   (IPSEC DOI), which instantiates ISAKMP for use with IP when IP uses
   ISAKMP to negotiate security associations.

      o RFC 2412, The OAKLEY Key Determination Protocol (I, Nov. 1998)

   [RFC2412] describes a key establishment protocol using which two
   authenticated parties can agree on secure and secret keying material.
   The Oakley protocol describes a series of key exchanges-- called
   "modes"-- and details the services provided by each (e.g. perfect
   forward secrecy for keys, identity protection, and authentication).


4.1.2.  IKEv2

      o RFC 4306, Internet Key Exchange (IKEv2) Protocol (S, Dec. 2005)

   This document describes version 2 of the Internet Key Exchange (IKE)
   protocol.  It covers what was covered previously by separate
   documents: ISAKMP, IKE and DOI.It also addresses NAT traversal,
   legacy authentication and remote address acquisition.  IKEv2 is not
   interoperable with IKEv1.

      o RFC 4718, IKEv2 Clarifications and Implementation Guidelines (I,
        Oct. 2006)




Frankel & Krishnan         Expires June 2009                   [Page 13]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


   [RFC4718] clarifies many areas of the IKEv2 specification that may be
   difficult to understand for developers who are not intimately
   familiar with the specification and its history.  It does not
   introduce any changes to the protocol, but rather provides
   descriptions that are less prone to ambiguous interpretations.  The
   goal of this document is to encourage the development of
   interoperable implementations.

      o draft-ietf-ipsecme-ikev2bis-xx.txt, Internet Key Exchange
        Protocol: IKEv2 (S)

4.2.  Additions and Extensions

4.2.1.  Peer Authentication Methods

      o RFC 4478, Repeated Authentication in Internet Key Exchange
        (IKEv2) Protocol (E, Apr. 2006)

      o RFC 4739, Multiple Authentication Exchanges in the Internet Key
        Exchange (IKEv2) Protocol (E, Nov. 2006)

   IKEv2 supports several mechanisms for authenticating the parties but
   each endpoint uses only one of these mechanisms to authenticate
   itself.  [RFC4739] specifies an extension to IKEv2 that allows the
   use of multiple authentication exchanges, using either different
   mechanisms or the same mechanism.  This extension allows, for
   instance, performing certificate-based authentication of the client
   host followed by an EAP authentication of the user.  This also allows
   for authentication by multiple administrative domains, if needed.

      o RFC 4754, IKE and IKEv2 Authentication Using the Elliptic Curve
        Digital Signature Algorithm (ECDSA) (S, Jan. 2007)

   [RFC4754] describes how the Elliptic Curve Digital Signature
   Algorithm (ECDSA) may be used as the authentication method within the
   IKEv1 and IKEv2 protocols.  ECDSA provides many benefits including
   computational efficiency, small signature sizes, and minimal
   bandwidth compared to other available digital signature methods like
   RSA and DSA.


4.2.2.  Certificate Contents and Management (PKI4IPsec)

      o RFC 4809, Requirements for an IPsec Certificate Management
        Profile (I, Feb. 2007)

   [RFC4809] enumerates requirements for Public Key Certificate (PKC)
   lifecycle transactions between different VPN System and PKI System



Frankel & Krishnan         Expires June 2009                   [Page 14]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


   products in order to better enable large scale, PKI-enabled IPsec
   deployments with a common set of transactions.  This document
   discusses requirements for both the IPsec and the PKI products.

      o RFC 4945, The Internet IP Security PKI Profile of IKEv1/ISAKMP,
        IKEv2, and PKIX (S, Aug. 2007)

   [RFC4945] defines a profile of the IKE and PKIX frameworks in order
   to provide an agreed-upon standard for using PKI technology in the
   context of IPsec.  It also documents the contents of the relevant IKE
   payloads and further specifies their semantics.  It also summarizes
   the current state of implementations and deployment and provides
   advice to avoid common interoperability issues.

      o RFC 4806, Online Certificate Status Protocol (OCSP) Extensions
        to IKEv2 (S, Feb. 2007)

   When certificates are used with IKEv2, the communicating peers need a
   mechanism to determine the revocation status of the peer's
   certificate.  OCSP is one such mechanism.  [RFC4806] defines the
   "OCSP Content" extension to IKEv2.  This document is applicable when
   OCSP is desired and security policy (e.g. firewall) prevents one of
   the IKEv2 peers from accessing the relevant OCSP responder directly.


4.2.3.  Dead Peer Detection

      o RFC 3706, A Traffic-Based Method of Detecting Dead Internet Key
        Exchange (IKE) Peers (I, Feb. 2004)

   When two peers communicate using IKE and IPsec, it is possible for
   the connectivity between the two peers to drop unexpectedly.  But the
   SAs can still remain until their lifetimes expire, resulting in the
   packets getting tunneled into a "black hole".  [RFC3706] describes an
   approach to detect peer liveliness without needing to send messages
   at regular intervals.


4.2.3.  Remote Access

      o draft-ietf-ipsecme-ikev2-resumption-00.txt, IKEv2 Session
        Resumption (S)

      o draft-ietf-ipsecme-ikev2-redirect-02.txt, Re-direct Mechanism
        for IKEv2 (S)

      o draft-ietf-ipsecme-ikev2-ipv6-config-00.txt, IPv6 Configuration
        in IKEv2 (S)



Frankel & Krishnan         Expires June 2009                   [Page 15]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


5.  Cryptographic Algorithms and Suites

   Two basic requirements must be met for an algorithm to be used within
   IKE and/or IPsec: assignment of one or more IANA values and an RFC
   that describes how to use the algorithm within the relevant protocol,
   packet formats, special considerations, etc.  For each RFC that
   describes a cryptographic algorithm, this document will classify its
   Requirements Level for each protocol, as either MUST, SHALL or MAY
   [RFC2119]; optional; not defined; or N/A (not applicable).  Optional
   means that the algorithm meets the two basic requirements, but its
   use is not specifically recommended for that protocol.  Not defined
   means that one of the basic requirements is not met: either there is
   no relevant IANA number for the algorithm, or there is no RFC
   specifying how it should be used within that specific protocol.  N/A
   means that use of the algorithm is inappropriate in the context
   (e.g., NULL encryption for IKE, which always requires encryption; or
   combined mode algorithms, a new feature in IPsec-v3, for use with
   IPsec-v2).

   This document categorizes the requirements level of each algorithm
   for IKEv1, IKEv2, IPsec-v2 and IPsec-v3.  If an algorithm is
   recommended for use within IKEv1 or IKEv2, it is used either to
   protect the IKE SA's traffic (encryption and integrity-protection
   algorithms) or to generate keying material (Diffie-Hellman or DH
   groups, Pseudo-Random Functions or PRFs).  If an algorithm is
   recommended for use within IPsec, it is used to protect the
   IPsec/child SA}s traffic, and IKE is capable of negotiating its use
   for that purpose.


5.1.  Algorithm Requirements

   Specifying a core set of mandatory algorithms for each protocol
   facilitates interoperability.  Defining those algorithms in an RFC
   separate from the base protocol RFC enhances algorithm agility.
   IPsec-v3 and IKEv2 each have an RFC that specifies their
   mandatory-to-implement (MUST), recommended (SHOULD), optional (MAY),
   and deprecated (SHOULD NOT) algorithms.  For IPsec-v2, this is
   included in the base protocol RFC.  That was originally the case for
   IKEv1, but IKEv1's algorithm requirements were updated in [RFC4109].

      o RFC 4835, Cryptographic Algorithm Implementation Requirements
        for Encapsulating Security Payload (ESP) and Authentication
        Header (AH) (S, Apr. 2007)

   [RFC4835] specifies the encryption and integrity-protection
   algorithms for IPsec (both versions).  Combined algorithms are
   mentioned, but not assigned a requirement level.



Frankel & Krishnan         Expires June 2009                   [Page 16]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


   NOTE: Algorithms for IPsec-v2 were originally defined in [RFC2402]
   and [RFC2406].  [RFC4305] obsoleted those requirements, and was in
   turn obsoleted by [RFC4835].  Therefore, by inference [RFC4835]
   applies to IPsec-v2 as well as IPsec-v3.

      o RFC 4307, Cryptographic Algorithms for Use in the Internet Key
        Exchange Version 2 (IKEv2) (S, Dec. 2005)

   [RFC4307] specifies the encryption and integrity-protection
   algorithms used by IKEv2 to protect its own traffic; the
   Diffie-Hellman (DH) groups used within IKEv2; and the pseudo-random
   functions used by IKEv2 to generate keys, nonces and other random
   values.  It also specifies the encryption and integrity-protection
   algorithms that IKEv2 negotiates for use within IPsec.

      o RFC 4109, Algorithms for Internet Key Exchange version 1 (IKEv1)
        (S, May 2005)

   [RFC4109] updates IKEv1's algorithm specifications, which were
   originally defined in [RFC2409].  It specifies the encryption and
   integrity-protection algorithms used by IKEv1 to protect its own
   traffic; the Diffie-Hellman (DH) groups used within IKEv1; the hash
   and pseudo-random functions used by IKEv1 to generate keys, nonces
   and other random values; and the authentication methods and
   algorithms used by IKEv1 for peer authentication.


5.2.  Encryption Algorithms

   The encryption algorithm RFCs describe how to use these algorithms to
   encrypt IKE and/or ESP traffic, providing confidentiality protection
   to the traffic.  They describe any special constraints, requirements,
   or changes to packet format appropriate for the specific algorithm.
   In general, they do not describe the detailed algorithmic
   computations; the reference section of each RFC includes pointers to
   documents that define the inner workings of the algorithm.  Some of
   the RFCs include sample test data, to enable implementors to compare
   their results with standardized output.

   Some of the encryption algorithms are stream ciphers, which must be
   used in conjunction with an integrity-protection algorithm.  Even
   when using other types of encryption algorithms, the use of
   integrity-protection is strongly recommended.

   DES, as described in [RFC2405], was originally a required algorithm
   for IKEv1 and ESP-v2.  Since the use of DES is now deprecated, this
   roadmap does not include [RFC2405].




Frankel & Krishnan         Expires June 2009                   [Page 17]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


      o RFC 2410, The NULL Encryption Algorithm and Its Use With IPsec
        (S, Nov. 1998)

   [RFC2410] is a tongue-in-cheek description of the no-op encryption
   algorithm (i.e. using ESP without encryption).  In order for IKE to
   negotiate the selection of the NULL encryption algorithm for use in
   an ESP SA, an identifying IANA number is needed.  This number (the
   value 11 for ESP_NULL) is found on the IANA registries for both IKEv1
   and IKEv2, but it is not mentioned in this RFC.

   Requirements levels for ESP-NULL: IKEv1 - N/A; IKEv2 - N/A; ESP-v2 -
   MUST [RFC4835]; ESP-v3 - MUST [RFC4835]

   NOTE: [RFC4307] lists ESP-NULL as MAY for ESP-v3, which conflicts
   with the MUST in [RFC4835].

      o RFC 2451, The ESP CBC-Mode Cipher Algorithms (S, Nov. 1998)

   [RFC2451] describes how to use encryption algorithms in cipher block
   chaining (CBC) mode to encrypt IKE and ESP traffic.  It specifically
   mentions Blowfish, CAST-128, Triple DES (3DES), IDEA and RC5, but it
   is applicable to any block cipher algorithm used in CBC mode.  The
   algorithms mentioned in the RFC all have a 64-bit blocksize and a
   64-bit random IV that is sent in the packet along with the encrypted
   data.

   Requirements levels for 3DES-CBC: IKEv1 - MUST [RFC4109]; IKEv2 -
   MUST- [RFC4307]; ESP-v2 - MUST [RFC4835]; ESP-v3 - MUST- [RFC4835]

   Requirements levels for other CBC algorithms (Blowfish, CAST, IDEA,
   RC5): IKEv1 - optional; IKEv2 - optional; ESP-v2 - optional; ESP-v3 -
   optional

      o RFC 3602, The AES-CBC Cipher Algorithm and Its Use with IPsec
        (S, Sep. 2003)

   [RFC3602] describes how to use AES in cipher block chaining (CBC)
   mode to encrypt IKE and ESP traffic.  AES is the successor to DES.
   AES-CBC is a block-mode cipher with a 128-bit blocksize; a random IV
   that is sent in the packet along with the encrypted data; and
   keysizes of 128, 192 and 256 bits.  128-bit keys are MUST; the other
   sizes are MAY.  [RFC3602] includes IANA values for use in IKEv1 and
   ESP-v2.  A single IANA value is defined for AES-CBC, so IKE
   negotiations need to specify the keysize.

   Requirements levels for AES-CBC with 128-bit keys: IKEv1 - SHOULD
   [RFC4109]; IKEv2 - SHOULD+ [RFC4307]; ESP-v2 - MUST [RFC4835]; ESP-v3
   - MUST [RFC4835]



Frankel & Krishnan         Expires June 2009                   [Page 18]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


   Requirements levels for AES-CBC with 192- or 256-bit keys: IKEv1 -
   optional; IKEv2 - optional; ESP-v2 - optional; ESP-v3 - optional

      o RFC 3686, Using Advanced Encryption Standard (AES) Counter Mode
        With IPsec Encapsulating Security Payload (ESP) (S, Jan. 2004)

   [RFC3686] describes how to use AES in counter (CTR) mode to encrypt
   ESP traffic.  AES-CTR is a stream cipher with a 32-bit random nonce
   (1/SA) and a 64-bit IV, both of which are sent in the packet along
   with the encrypted data.  128-bit keys are MUST; 192- and 256-byte
   keys are MAY.  Reuse of the IV with the same key and nonce
   compromises the data's security; thus, AES-CTR should not be used
   with manual keying.  When AES-CTR is used as the encryption
   algorithm, integrity-protection must also be used.  AES-CTR can be
   pipelined and parallelized; it uses only the AES encryption
   operations for both encryption and decryption.

   Requirements levels for AES-CTR: IKEv1 - not defined (no IANA #);
   IKEv2 - optional or not defined (see NOTE); ESP-v2 - SHOULD
   [RFC4835]; ESP-v3 - SHOULD [RFC4835]

   NOTE: AES-CTR does not have an IANA number for IKEv1; since the same
   IANA numbers are used for IKEv2 and IPsec-v3, does [RFC3686] suffice
   to define the use of AES-CTR within IKEv2?

      o RFC 4312, The Camellia Cipher Algorithm and Its Use with IPsec
        (S, Dec. 2005)

   [RFC4312] describes how to use Camellia in cipher block chaining
   (CBC) mode to encrypt IKE and ESP traffic.  Camellia-CBC is a
   block-mode cipher with a 128-bit blocksize; a random IV that is sent
   in the packet along with the encrypted data; and keysizes of 128, 192
   and 256 bits.  128-bit keys are MUST; the other sizes are MAY.
   [RFC4312] includes IANA values for use in IKEv1 and IPsec-v2.  A
   single IANA value is defined for Camellia-CBC, so IKEv1 negotiations
   need to specify the keysize.

   Requirements levels for Camellia-CBC: IKEv1 - optional; IKEv2 - not
   defined (no IANA #); ESP-v2 - optional; ESP-v3 - not defined (no IANA
   #)


5.3.  Integrity-Protection (Authentication) Algorithms

   The integrity-protection algorithm RFCs describe how to use these
   algorithms to authenticate IKE and/or IPsec traffic, providing
   integrity protection to the traffic. This protection is provided by
   computing an Integrity Check Value (ICV), which is sent in the



Frankel & Krishnan         Expires June 2009                   [Page 19]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


   packet.  The RFCs describe any special constraints, requirements, or
   changes to packet format appropriate for the specific algorithm.  In
   general, they do not describe the detailed algorithmic computations;
   the reference section of each RFC includes pointers to documents that
   define the inner workings of the algorithm.  Some of the RFCs include
   sample test data, to enable implementors to compare their results
   with standardized output.

   HMAC-MD5, as described in [RFC2403], was originally a required
   algorithm for IKEv1 and IPsec-v2.  Since the use of MD5 and HMAC-MD5
   is now deprecated, this roadmap does not include [RFC2403].

      o RFC 2404, The Use of HMAC-SHA-1-96 within ESP and AH (S, Nov.
        1998)

   [RFC2404] describes HMAC-SHA-1, an integrity-protection algorithm
   with a 512-bit blocksize, and a 160-bit key and Integrity Check Value
   (ICV).  For use within IPsec, the ICV is truncated to 96 bits.  This
   is currently the most commonly-used integrity-protection algorithm.

   Requirements levels for HMAC-SHA-1: IKEv1 - MUST [RFC4109]; IKEv2 -
   MUST [RFC4307]; IPsec-v2 - MUST [RFC4835]; IPsec-v3 - MUST [RFC4835]

      o RFC 3566, The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec
        (S, Sep. 2003)

   [RFC3566] describes AES-XCBC-MAC, a variant of CBC-MAC which is
   secure for messages of varying lengths (unlike classic CBC-MAC).  It
   is an integrity-protection algorithm with a 128-bit blocksize, and a
   128-bit key and ICV.  For use within IPsec, the ICV is truncated to
   96 bits.  [RFC3566] includes test data.

   Requirements levels for AES-XCBC-MAC: IKEv1 - SHOULD [RFC4109]; IKEv2
   - optional; IPsec-v2 - SHOULD+ [RFC4835]; IPsec-v3 - SHOULD+
   [RFC4835]

      o RFC 4868, Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512
        with IPsec (S, May 2007)

   [RFC4868] describes a family of algorithms, successors to HMAC-SHA-1.
   HMAC-SHA-256 has a 512-bit blocksize, and a 256-bit key and ICV.
   HMAC-SHA-384 has a 1024-bit blocksize, and a 384-bit key and ICV.
   HMAC-SHA-512 has a 1024-bit blocksize, and a 512-bit key and ICV.
   For use within IKE and IPsec, the ICV is truncated to half its
   original size (128 bits, 192 bits, or 256 bits).  Each of the three
   algorithms has its own IANA value, so IKE does not have to negotiate
   the keysize.




Frankel & Krishnan         Expires June 2009                   [Page 20]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


   Requirements levels for HMAC-SHA-256, HMAC-SHA-384, HMC-SHA-512:
   IKEv1 - optional; IKEv2 - optional; IPsec-v2 - optional; IPsec-v3 -
   optional

      o RFC 4543, The Use of Galois Message Authentication Code (GMAC)
        in IPsec ESP and AH (S, May 2006)

   [RFC4543] is the variant of AES-GCM [RFC4106] that provides
   integrity-protection without encryption.  It has two versions: an
   integrity-protection algorithm for use within AH-v3, and a
   combined-mode algorithm with null encryption for use within ESP-v3.
   It can use a key of 128-, 192-, or 256-bits; the ICV is always 128
   bits, and is not truncated.  AES-GMAC uses a nonce, consisting of a
   64-bit IV and a 32-bit salt (1/SA).  The salt value is generated by
   IKEv2 during the key generation process.  Reuse of the salt value
   with the same key compromises the data's security; thus, AES-GMAC
   should not be used with manual keying.  For use within AH-v3, each
   keysize has its own IANA value, so IKE does not have to negotiate the
   keysize.  For use within ESP-v3, there is only one IANA value, so IKE
   negotiations must specify the keysize.

   Requirements levels for AES-GMAC: IKEv1 - N/A; IKEv2 - optional;
   IPsec-v2 - not defined (no IANA #); IPsec-v3 - optional

      o RFC 4494, The AES-CMAC-96 Algorithm and Its Use with IPsec (S,
        Jun. 2006)

   [RFC4494] describes AES-CMAC, another variant of CBC-MAC which is
   secure for messages of varying lengths.  It is an
   integrity-protection algorithm with a 128-bit blocksize, and 128-bit
   key and ICV.  For use within IPsec, the ICV is truncated to 96 bits.
   [RFC4494] includes test data.

   Requirements levels for AES-CMAC: IKEv1 - not defined (no IANA #);
   IKEv2 - optional; IPsec-v2 - not defined (no IANA #); IPsec-v3 -
   optional

      o RFC 2857, The Use of HMAC-RIPEMD-160-96 within ESP and AH (S,
        Jun. 2000)

   [RFC2857] describes HMAC-RIPEMD, an integrity-protection algorithm
   with a 512-bit blocksize, and a 160-bit key and ICV.  For use within
   IPsec, the ICV is truncated to 96 bits.

   Requirements levels for HMAC-RIPEMD: IKEv1 - not defined (no IANA #);
   IKEv2 - not defined (no IANA #); IPsec-v2 - optional; IPsec-v3 - not
   defined (no IANA #)




Frankel & Krishnan         Expires June 2009                   [Page 21]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


5.3.1.  General Considerations

      o RFC 4894, Use of Hash Algorithms in Internet Key Exchange (IKE)
        and IPsec (I, May 2007)

   In light of recent attacks on MD5 and SHA-1, [RFC4894] examines
   whether it is necessary to replace the hash functions currently used
   by IKE and IPsec for key generation, integrity-protection, digital
   signatures, or PKIX certificates.  It concludes that the algorithms
   recommended for IKEv2 [RFC4307] and IPsec-v3 [RFC4305] are not
   currently susceptible to any known attacks.  Nonetheless, it suggests
   that implementors add support for AES-XCBC-MAC-96 [RFC3566],
   AES-XCBC-PRF-128 [RFC4434] and HMAC-SHA-256, -384, and -512 [RFC4868]
   for future use.  It also suggests that IKEv2 implementors add support
   for PKIX certificates signed with HMAC-SHA-256, -384, and -512.


5.4.  Combined Algorithms

      o RFC 4309, Using Advanced Encryption Standard (AES) CCM Mode with
        IPsec Encapsulating Security Payload (ESP) (S, Dec. 2005)

   [RFC4309] describes how to use AES in Counter with CBC-MAC (CCM)
   mode, a combined alorithm, to encrypt and integrity-protect ESP-v3
   traffic.  AES-CCM is a block-mode cipher with a 128-bit blocksize; a
   random IV that is sent in the packet along with the encrypted data; a
   24-bit salt value (1/SA); keysizes of 128, 192 and 256 bits, and ICV
   sizes of 64, 96 and 128 bits.  128-bit keys are MUST; the other sizes
   are MAY.  ICV sizes of 64 and 128 bit are MUST; 96 bits is MAY.  The
   salt value is generated by IKEv2 during the key generation process.
   Reuse of the IV with the same key compromises the data's security;
   thus, AES-CCM should not be used with manual keying.  [RFC4309]
   includes IANA values for use in ESP-v3.  Each of the three ICV
   lengths has its own IANA value, but IKEv2 negotiations need to
   specify the keysize.  [RFC4309] includes test data.  [RFC4309]
   describes how IKEv2 can negotiate the use of AES-CCM to use in an
   ESP-v3 SA.  [RFC5282] extends this to the use of AES-CCM to protect
   an IKEv2 SA.

   Requirements levels for AES-CCM: IKEv1 - N/A; IKEv2 - optional;
   ESP-v2 - N/A; ESP-v3 - optional [RFC4835]

   NOTE: The IPsec-v2 IANA registry includes values for AES-CCM, but
   combined-mode algorithms are not a feature of IPsec-v2.

      o RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec
        Encapsulating Security Payload (ESP) (S, Jun. 2005)




Frankel & Krishnan         Expires June 2009                   [Page 22]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


   [RFC4106] describes how to use AES in Galois/Counter (GCM) mode, a
   combined alorithm, to encrypt and integrity-protect ESP-v3 traffic.
   AES-GCM is a block-mode cipher with a 128-bit blocksize; a random IV
   that is sent in the packet along with the encrypted data; a 32-bit
   salt value (1/SA); keysizes of 128, 192 and 256 bits; and ICV sizes
   of 64, 96 and 128 bits.  128-bit keys are MUST; the other sizes are
   MAY.  An ICV size of 128 bits is a MUST; 64 and 96 bits are MAY.  The
   salt value is generated by IKEv2 during the key generation process.
   Reuse of the IV with the same key compromises the data's security;
   thus, AES-GCM should not be used with manual keying.  [RFC4106]
   includes IANA values for use in ESP-v3.  Each of the three ICV
   lengths has its own IANA value, but IKEv2 negotiations need to
   specify the keysize.  [RFC4106] includes test data.  [RFC4106]
   describes how IKEv2 can negotiate the use of AES-GCM to use in an
   ESP-v3 SA.  [RFC5282] extends this to the use of AES-GCM to protect
   an IKEv2 SA.

   Requirements levels for AES-GCM: IKEv1 - N/A; IKEv2 - optional;
   ESP-v2 - N/A; ESP-v3 - optional [RFC4835]

   NOTE: The IPsec-v2 IANA registry includes values for AES-GCM, but
   combined-mode algorithms are not a feature of IPsec-v2.


5.4.1.  General Considerations

      o RFC 5282,  Using Authenticated Encryption Algorithms with the
        Encrypted Payload of the Internet Key Exchange version 2 (IKEv2)
        Protocol (S, Aug. 2008)

   [RFC5282] extends [RFC4309] and [RFC4106] to enable the use of
   AES-CCM and AES-GCM to provide encryption and integrity-protection
   for IKEv2 messages.

5.5.  Pseudo-Random Functions (PRFs)

      o RFC 4434, The AES-XCBC-PRF-128 Algorithm for the Internet Key
        Exchange Protocol (IKE) (S, Feb. 2006)

   [RFC3566] defines AES-XCBC-MAC-96, which is used for integrity
   protection within IKE and IPsec.  [RFC4434] enables the use of
   AES-XCBC-MAC as a PRF within IKE.  The PRF differs from the
   integrity-protection algorithm in two ways: its 128-bit output is not
   truncated to 96 bits; and it accepts a variable-length key, which is
   modified (lengthened via padding or shortened through application of
   AES-XCBC) to a 128-bit key.  [RFC4434] includes test data.

   Requirements levels for AES-XCBC-PRF: IKEv1 - SHOULD [RFC4109]; IKEv2



Frankel & Krishnan         Expires June 2009                   [Page 23]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


   - SHOULD+ [RFC4307]

      o RFC 4615, The Advanced Encryption Standard-Cipher-based Message
        Authentication Code-Pseudo-Random Function-128
        (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange
        Protocol (IKE) (S, Aug. 2006)

   [RFC4615] extends [RFC4494] to enable the use of AES-CMAC as a PRF
   within IKEv2, in a manner analogous to that used by [RFC4434] for
   AES-XCBC.

   Requirements levels for AES-CMAC-PRF: IKEv1 - not defined (no IANA
   #); IKEv2 - optional


5.6.  Cryptographic Suites

      o RFC 4308, Cryptographic Suites for IPsec (S, Dec. 2005)

   An IKE negotiation consists of multiple cryptographic attributes,
   both for the IKE SA and for the IPsec SA.  The infinite number of
   possible combinations can pose a challenge to peers trying to find a
   common policy.  To enhance interoperability, [RFC4308] defines two
   pre-defined suites, consisting of combinations of algorithms that
   comprise typical security policies.  IKE/ESP suite "VPN-A" includes
   use of 3DES, HMAC-SHA-1, and 1024-bit MODP Diffie-Hellman (DH);
   IKE/ESP suite "VPN-B" includes AES-CBC, AES-XCBC-MAC, and 2048-bit
   MODP DH.  These suites are intended to be named "single-button"
   choices in the administrative interface, but do not prevent the use
   of alternative combinations.

      o RFC 4869, Suite B Cryptographic Suites for IPsec (I, May 2007)

   [RFC4869] adds 4 pre-defined suites, based upon "Suite B" algorithms,
   to those specified in [RFC4308].  IKE/ESP-v3 suites "Suite-B-GCM-128"
   and "Suite-B-GCM-256" include use of AES-CBC, AES-GCM, HMAC-SHA-256
   or HMAC-SHA-384, and 256-bit or 384-bit elliptic curve (EC) DH
   groups.  IKE/AH-v3 suites "Suite-B-GMAC-128" and "Suite-B-GMAC-256"
   include use of AES-CBC, AES-GMAC, HMAC-SHA-256 or HMAC-SHA-384, and
   256-bit or 384-bit EC DH groups.


5.7.  Diffie-Hellman Algorithms

   IKE negotiations include a Diffie-Hellman exchange, which establishes
   a shared secret, to which both parties contributed.  This value is
   used to generate keying material to protect both the IKE SA and the
   IPsec SA.



Frankel & Krishnan         Expires June 2009                   [Page 24]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


   IKEv1 [RFC2409] contains definitions of 2 DH MODP groups and 2
   elliptic curve (EC) groups; IKEv2 [RFC4306] only references the MODP
   groups.  The requirements levels of these groups are:

   Requirements levels for DH MODP group 1: IKEv1 - MAY [RFC4109]; IKEv2
   - optional

   Requirements levels for DH MODP group 2: IKEv1 - MUST [RFC4109];
   IKEv2 - MUST- [RFC4307]

   Requirements levels for EC groups 3-4: IKEv1 - MAY [RFC4109]; IKEv2 -
   not defined (no IANA #)

      o RFC 3526, More Modular Exponential (MODP) Diffie-Hellman groups
        for Internet Key Exchange (IKE) (S, May 2003)

   [RFC2409] and [RFC4306] define 2 MODP DH groups (groups 1 and 2) for
   use within IKE.  [RFC3526] adds six more groups (groups 5 and 14-18).
   Group 14 is a 2048-bit group that is strongly recommended for use in
   IKE.

   Requirements levels for DH MODP group 14: IKEv1 - SHOULD [RFC4109];
   IKEv2 - SHOULD+ [RFC4307]

   Requirements levels for DH MODP groups 5, 15-18: IKEv1 - optional
   [RFC4109]; IKEv2 - optional

      o RFC 4753, ECP Groups For IKE and IKEv2 (I, Jan. 2007)

   [RFC4753] defines 3 EC DH groups (groups 19-21) for use within IKE.
   The document includes test data.

   Requirements levels for DH EC groups  19-21: IKEv1 - optional
   [RFC4109]; IKEv2 - optional

      o RFC 5114, Additional Diffie-Hellman Groups for Use with IETF
        Standards (I, Jan. 2008)

   [RFC5114] defines 5 additional DH groups (MODP groups 22-24 and EC
   groups 25-26) for use in IKE.  It also includes 3 EC DH groups
   (groups 19-21) that were previously defined in [RFC4753].  The IANA
   group numbers are specific to IKE, but the DH groups are intended for
   use in multiple IETF protocols, including TLS/SSH, SMIME, and X.509
   Certificates.

   Requirements levels for DH MODP groups 22-24, EC groups 25-26: IKEv1
   - optional; IKEv2 - optional




Frankel & Krishnan         Expires June 2009                   [Page 25]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


6.  IPsec/IKE for Multicast

   [RFC4301] describes IPsec processing for unicast and multicast
   traffic.  However, classical IPsec SAs provide point-to-point
   protection; the security afforded by IPsec's cryptographic algorithms
   is not applicable when the SA is one-to-many or many-to-many, the
   case for multicast.  The Multicast Security (msec) Working Group has
   defined alternatives to IKE and extensions to IPsec for use with
   multicast traffic.  Different multicast groups have differing
   characteristics and requirements: number of senders (one-to-many or
   many-to-many), number of members (few, moderate, very large),
   volatility of membership, real-time delivery, etc.  Their security
   requirements vary as well.  Each solution defined by msec applies to
   a subset of the infinite variety of possible multicast groups.

      o RFC 3740, The Multicast Group Security Architecture (I, Mar.
        2004)

      o RFC 3547, The Group Domain of Interpretation (S, Jul. 2003)

      o RFC 4046, Multicast Security (MSEC) Group Key Management
        Architecture (I, Apr. 2005)

      o RFC 4535, GSAKMP: Group Secure Association Key Management
        Protocol (S, Jun. 2006)

      o RFC 4534, Group Security Policy Token v1 (S, Jun. 2006)

      o RFC 3830, MIKEY: Multimedia Internet KEYing (S, Aug. 2004)

      o RFC 4738, MIKEY-RSA-R: An Additional Mode of Key Distribution in
        Multimedia Internet KEYing (MIKEY) (S, Nov. 2006)

      o RFC 5197, On the Applicability of Various Multimedia Internet
        KEYing (MIKEY) Modes and Extensions (I, Jun. 2008)

      o RFC 4563, The Key ID Information Type for the General Extension
        Payload in Multimedia Internet KEYing (MIKEY) (S, Jun. 2006)

      o RFC 4359, The Use of RSA/SHA-1 Signatures within Encapsulating
        Security Payload (ESP) and Authentication Header (AH) (S, Jan.
        2006)

      o RFC 4650, HMAC-Authenticated Diffie-Hellman for Multimedia
        Internet KEYing (MIKEY) (S, Sep. 2006)

      o RFC 4082, Timed Efficient Stream Loss-Tolerant Authentication
        (TESLA): Multicast Source Authentication Transform Introduction



Frankel & Krishnan         Expires June 2009                   [Page 26]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


        (I, Jun. 2005)

      o RFC 4442, Bootstrapping Timed Efficient Stream Loss-Tolerant
        Authentication (TESLA) (S, Mar. 2006)

      o RFC 4383, The Use of Timed Efficient Stream Loss-Tolerant
        Authentication (TESLA) in the Secure Real-time Transport
        Protocol (SRTP) (S, Feb. 2006)

7.  Outgrowths of IPsec/IKE


7.1.  IPComp (Compression)

      o RFC 3173, IP Payload Compression Protocol (IPComp) (S, Sep.
        2001)

   IPComp is a protocol that provides lossless compression for IP
   datagrams.  IP payload compression is especially useful when IPsec
   based encryption is applied to IP datagrams.  Encrypting the IP
   datagram causes the data to be random in nature, rendering
   compression at lower protocol layers ineffective.  If IKE is used to
   negotiate compression in conjunction with IPsec, compression can be
   performed prior to encryption.  [RFC3173] defines the payload
   compression protocol, the IPComp packet structure, the IPComp
   Association (IPCA), and several methods to negotiate the IPCA.

      o RFC 2394, IP Payload Compression Using DEFLATE (I, Dec. 1998)

   The IPComp protocol allows the compression of IP datagrams by
   supporting different compression algorithms.  [RFC2394] defines the
   application of the DEFLATE algorithm as a compression method to
   IPComp.

      o RFC 2395, IP Payload Compression Using LZS (I, Dec. 1998)

   The IPComp protocol allows the compression of IP datagrams by
   supporting different compression algorithms.  [RFC2395] defines the
   application of the LZS algorithm as a compression method to IPComp.

7.2.  IKEv2 Mobility and Multihoming (MobIKE)

      o RFC 4621, Design of the IKEv2 Mobility and Multihoming (MOBIKE)
        Protocol (I, Aug. 2006)

   [RFC4621] discusses the involved network entities and the
   relationship between IKEv2 signaling and information provided by
   other protocols.  It also records design decisions for the MOBIKE



Frankel & Krishnan         Expires June 2009                   [Page 27]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


   protocol, background information, and records discussions within the
   working group.

      o RFC 4555, IKEv2 Mobility and Multihoming Protocol (MOBIKE) (S,
        Jun. 2006)

   IKEv2 assumes that an IKE SA is created implicitly between the IP
   address pair that is used during the protocol execution when
   establishing the IKEv2 SA.  IPsec related documents had no provision
   to change this pair after an IKE SA was created.  [RFC4555] defines
   extensions to IKEv2 that enable an efficient management of IKE and
   IPsec Security Associations when a host possesses multiple IP
   addresses and/or where IP addresses of an IPsec host change over
   time.

      o RFC 5266, Secure Connectivity and Mobility Using Mobile IPv4 and
        IKEv2 Mobility and Multihoming (MOBIKE) (B, Jun. 2008)

   [RFC5266] describes a solution using Mobile IPv4 (MIPv4) and mobility
   extensions to IKEv2 (MOBIKE) to provide secure connectivity and
   mobility to enterprise users when they roam into untrusted networks.


7.3.  Better-than-Nothing Security (Btns)

      o draft-ietf-btns-connection-latching-xx.txt, IPsec Channels:
        Connection Latching

   This document specifies, abstractly, how to interface applications
   and transport protocols with IPsec so as to create channels by
   latching connections (packet flows) to certain IPsec Security
   Association (SA) parameters for the lifetime of the connections.
   Connection latching is layered on top of IPsec and does not modify
   the underlying IPsec architecture.

      o RFC 5386, Better-Than-Nothing-Security: An Unauthenticated Mode
        of IPsec (S, Nov. 2008)

   [RFC5386] specifies how to use the Internet Key Exchange (IKE)
   protocols, such as IKEv1 and IKEv2, to setup unauthenticated security
   associations (SAs) for use with the IPsec Encapsulating Security
   Payload (ESP) and the IPsec Authentication Header (AH).  This
   document does not require any changes to the bits on the wire, but
   specifies extensions to the Peer Authorization Database (PAD) and
   Security Policy Database (SPD).

      o RFC 5387, Problem and Applicability Statement for
        Better-Than-Nothing Security (BTNS) (I, Nov. 2008)



Frankel & Krishnan         Expires June 2009                   [Page 28]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


   [RFC5387] considers that the need to deploy authentication
   information and its associated identities is a significant obstacle
   to the use of IPsec.  This document explains the rationale for
   extending the Internet network security protocol suite to enable use
   of IPsec security services without authentication.

      o RFC 5056, On the Use of Channel Bindings to Secure Channels (S,
        Nov. 2007)

7.4.  Kerberized Internet Negotiation of Keys (Kink)

      o RFC 3129, Requirements for Kerberized Internet Negotiation of
        Keys (I, Jun. 2001)

   [RFC3129] considers that peer to peer authentication and keying
   mechanisms have inherent drawbacks such as computational complexity
   and difficulty in enforcing security policies.  This document
   specifies the requirements for using basic features of Kerberos and
   uses them to its advantage to create a protocol which can establish
   and maintain IPsec security associations ([RFC2401]).

      o RFC 4430, Kerberized Internet Negotiation of Keys (KINK) (S,
        Mar. 2006)

   [RFC4430] defines a low-latency, computationally inexpensive, easily
   managed, and cryptographically sound protocol to establish and
   maintain security associations using the Kerberos authentication
   system.  This document reuses the Quick Mode payloads of IKEv1 in
   order to foster substantial reuse of IKEv1 implementations.

7.5.  IPsec Secure Remote Access (IPSRA)

      o RFC 3457, Requirements for IPsec Remote Access Scenarios (I,
        Jan. 2003)

   [RFC3457] explores and enumerates the requirements of various IPsec
   remote access scenarios, without suggesting particular solutions for
   them.

      o RFC 3456, Dynamic Host Configuration Protocol (DHCPv4)
        Configuration of IPsec Tunnel Mode (S, Jan. 2003)

   [RFC3456] explores the requirements for host configuration in IPsec
   tunnel mode, and describes how the Dynamic Host Configuration
   Protocol (DHCPv4) may be used for providing such configuration
   information.

7.6.  IPsec Keying Information Resource Record (IPsecKEY)



Frankel & Krishnan         Expires June 2009                   [Page 29]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


      o RFC 4025, A method for storing IPsec keying material in DNS (S,
        Feb. 2005)

   This document describes a method of storing IPsec keying material in
   DNS using a new type of resource record.  This document describes how
   to store the public key of the target node in this resource record.

8.  Other Protocols that use IPsec/IKE

8.1.  Mobile IP (MIPv4 and MIPv6)

      o RFC 4093, Problem Statement: Mobile IPv4 Traversal of Virtual
        Private Network (VPN) Gateways (I, Aug. 2005)

      o RFC 5265, Mobile IPv4 Traversal across IPsec-Based VPN Gateways
        (S, Jun. 2008)

      o RFC 4877, Mobile IPv6 Operation with IKEv2 and the Revised IPsec
        Architecture (S, Apr. 2007)

      o RFC 3776, Using IPsec to Protect Mobile IPv6 Signaling Between
        Mobile Nodes and Home Agents (S, Jun. 2004)

      o draft-ietf-mip6-cn-ipsec-xx.txt, Using IPsec between Mobile and
        Correspondent IPv6 Nodes

      o RFC 5213, Proxy Mobile IPv6 (S, Aug. 2008)

      o RFC 5268, Mobile IPv6 Fast Handovers (S, Jun. 2008)

      o RFC 5380, Hierarchical Mobile IPv6 (HMIPv6) Mobility Management
        (S, Oct. 2008)

8.2.  Open Shortest Path First (OSPF)

      o RFC 4552, Authentication/Confidentiality for OSPFv3 (S, Jun.
        2006)

8.3.  Host Identity Protocol (HIP)

      o RFC 5201, Host Identity Protocol (E, Apr. 2008)

      o RFC 5202, Using the Encapsulating Security Payload (ESP)
        Transport Format with the Host Identity Protocol (HIP) (E, Apr.
        2008)

      o RFC 5206, End-Host Mobility and Multihoming with the Host
        Identity (E, Apr. 2008)



Frankel & Krishnan         Expires June 2009                   [Page 30]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


      o RFC 5207, NAT and Firewall Traversal Issues of Host Identity
        Protocol (HIP) (I, Apr. 2008)

8.4.  Extensible Authentication Protocol (EAP) Method Update (EMU)

      o RFC 5106, The Extensible Authentication Protocol-Internet Key
        Exchange Protocol version 2 (EAP-IKEv2) Method (E, Feb. 2008)

8.5.  Stream Control Transmission Protocol (SCTP)

      o RFC 3554, On the Use of Stream Control Transmission Protocol
        (SCTP) with IPsec (S, Jul. 2003)

8.6.  Fibre Channel

      o  RFC 4595, Use of IKEv2 in the Fibre Channel Security
        Association Management Protocol (I, Jul. 2006)

8.7.  Protocol for Carrying Authentication for Network Access (PANA)

      o  RFC 5191, Protocol for Carrying Authentication for Network
        Access (PANA) (S, May 2008)

9.  Security Considerations

   There are no security considerations relevant to this document.

10. IANA Considerations

   No actions are required from IANA as result of the publication of
   this document.


11. References

11.1. Normative References

11.2. Informative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", RFC 2026, October 1996.

   [btns-1]  Williams, N., "IPsec Channels: Connection Latching",
              draft-ietf-btns-connection-latching-xx.txt,  Work in
              Progress.



Frankel & Krishnan         Expires June 2009                   [Page 31]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


   [ipsecme-1]  Kaufman, C., P. Hoffman, Y. Nir and P. Eronen, "Internet
              Key Exchange Protocol: IKEv2",
              draft-ietf-ipsecme-ikev2bis-xx.txt,  Work in Progress.

   [ipsecme-2]  Eronen, P., J. Laganier and C. Madson,
              draft-ietf-ipsecme-ikev2-ipv6-config-00.txt, IPv6
              Configuration in IKEv2, Work in Progress.

   [ipsecme-3]  Devarapalli, V and K. Weniger,
              draft-ietf-ipsecme-ikev2-redirect-02.txt, Re-direct
              Mechanism for IKEv2, Work in Progress.

   [ipsecme-4]  Sheffer, Y., H. Tschofenig, L. Dondeti and V. Narayanan,
              draft-ietf-ipsecme-ikev2-resumption-00.txt, IKEv2 Session
              Resumption, Work in Progress.

   [ipsecme-5]  Grewal, K. and G. Montenegro,
              draft-ietf-ipsecme-traffic-visibility-00.txt, Wrapped ESP
              for Traffic Visibility, Work in Progress.

   [mip6-1]  Dupong, F. and J-M. Combes, "Using IPsec between Mobile and
              Correspondent IPv6 Nodes",
              draft-ietf-mip6-cn-ipsec-xx.txt,  Work in Progress.

   [RFC2394]  Pereira, R., "IP Payload Compression Using DEFLATE", RFC
              2394, December 1998.

   [RFC2395]  Friend, R. and R. Monsour, "IP Payload Compression Using
              LZS", RFC 2395, December 1998.

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998 (obsolete).

   [RFC2402]  Kent, S. and R. Atkinson, "IP Authentication Header", RFC
              2402, November 1998 (obsolete).

   [RFC2403]  Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
              ESP and AH", RFC 2403, November 1998.

   [RFC2404]  Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
              ESP and AH", RFC 2404, November 1998.

   [RFC2405]  Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
              Algorithm With Explicit IV", RFC 2405, November 1998.

   [RFC2406]  Kent, S. and R. Atkinson, "IP Encapsulating Security
              Payload (ESP)", RFC 2406, November 1998 (obsolete).




Frankel & Krishnan         Expires June 2009                   [Page 32]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


   [RFC2407]  Piper, D., "The Internet IP Security Domain of
              Interpretation for ISAKMP", RFC 2407, November 1998
              (obsolete).

   [RFC2408]  Maughan, D. M. Schertler, M. Schneider and J. Turner,
              "Internet Security Association and Key Management Protocol
              (ISAKMP)", RFC 2408, November 1998 (obsolete).

   [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
              (IKE)", RFC 2409, November 1998 (obsolete).

   [RFC2410]  Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
              Its Use With IPsec", RFC 2410, November 1998.

   [RFC2411]  Thayer, R., N. Doraswamy and R. Glenn, "IP Security
              Document Roadmap", RFC 2411, November 1998.

   [RFC2412]  Orman, H., "The OAKLEY Key Determination Protocol", RFC
              2412, November 1998.

   [RFC2451]  Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
              Algorithms", RFC 2451, November 1998.

   [RFC2857]  Keromytis, A. and N. Provos, "The Use of
              HMAC-RIPEMD-160-96 within ESP and AH", RFC 2857, June
              2000.

   [RFC3056]  Carpenter, B., "Connection of IPv6 Domains via IPv4
              Clouds", RFC 3056, February 2001.

   [RFC3129]  Thomas, M., "Requirements for Kerberized Internet
              Negotiation of Keys", RFC 3129, June 2001.

   [RFC3173]  Shacham, A. B. Monsour, R. Pereira and M. Thomas, "IP
              Payload Compression Protocol (IPComp)", RFC 3173,
              September 2001.

   [RFC3456]  Patel, B. B. Aboba, S. Kelly and V. Gupta, "Dynamic Host
              Configuration Protocol (DHCPv4) Configuration of IPsec
              Tunnel Mode", RFC 3456, January 2003.

   [RFC3457]  Kelly, S. and S. Ramamoorthi, "Requirements for IPsec
              Remote Access Scenarios", RFC 3457, January 2003.

   [RFC3526]  Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
              Diffie-Hellman groups for Internet Key Exchange (IKE)",
              RFC 3526, May 2003.




Frankel & Krishnan         Expires June 2009                   [Page 33]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


   [RFC3547]  Baugher, M. B. Weis, T. Hardjono and H. Harney, "The Group
              Domain of Interpretation", RFC 3547, July 2003.

   [RFC3554]  Bellovin, S. J. Ioannidis, A. Keromytis and R. Stewart,
              "On the Use of Stream Control Transmission Protocol (SCTP)
              with IPsec", RFC 3554, July 2003.

   [RFC3566]  Frankel, S. and H. Herbert, "The AES-XCBC-MAC-96 Algorithm
              and Its Use With IPsec", RFC 3566, September 2003.

   [RFC3585]  Jason, J. L. Rafalow, and E. Vyncke, "IPsec Configuration
              Policy Information Model", RFC 3585, August 2003.

   [RFC3586]  Blaze, M. A. Keromytis, M. Richardson and L. Sanchez, "IP
              Security Policy (IPSP) Requirements", RFC 3586, August
              2003.

   [RFC3602]  Frankel, S. R. Glenn and S. Kelly, "The AES-CBC Cipher
              Algorithm and Its Use with IPsec", RFC 3602, September
              2003.

   [RFC3686]  Housley, R., "Using Advanced Encryption Standard (AES)
              Counter Mode With IPsec Encapsulating Security Payload
              (ESP)", RFC 3686, January 2004.

   [RFC3706]  Huang, G., S. Beaulieu and D. Rochefort, "A Traffic-Based
              Method of Detecting Dead Internet Key Exchange (IKE)
              Peers", RFC 3706, February 2004.

   [RFC3715]  Aboba, B. and W. Dixon, "IPsec-Network Address Translation
              (NAT) Compatibility Requirements", RFC 3715, March 2004.

   [RFC3740]  Hardjono, T. and B. Weis, "The Multicast Group Security
              Architecture", RFC 3740, March 2004.

   [RFC3776]  Arkko, J., V. Devarapalli and F. Dupont, "Using IPsec to
              Protect Mobile IPv6 Signaling Between Mobile Nodes and
              Home Agents", RFC 3776, June 2004.

   [RFC3830]  Arkko, J., E. Carrara, F. Lindholm, M. Naslund and K.
              Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
              August 2004.

   [RFC3884]  Touch, J., L. Eggert and Y. Wang, "Use of IPsec Transport
              Mode for Dynamic Routing", RFC 3884, September 2004.

   [RFC3947]  Kivinen, T., B. Swander, A. Huttunen and V. Volpe,
              "Negotiation of NAT-Traversal in the IKE", RFC 3947,



Frankel & Krishnan         Expires June 2009                   [Page 34]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


              January 2005.

   [RFC3948]  Huttunen, A., B. Swander, V. Volpe, L. DiBurro and M.
              Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC
              3948, January 2005.

   [RFC4025]  Richardson, M., "A method for storing IPsec keying
              material in DNS", RFC 4025, February 2005.

   [RFC4046]  Baugher, M., R. Canetti, L. Dondeti and F. Lindholm,
              "Multicast Security (MSEC) Group Key Management
              Architecture", RFC 4046, April 2005.

   [RFC4082]  Perrig, A., D. Song, R. Canetti, J. D. Tygar and B.
              Briscoe, "Timed Efficient Stream Loss-Tolerant
              Authentication (TESLA): Multicast Source Authentication
              Transform Introduction", RFC 4082, June 2005.

   [RFC4093]  Adrandi, F., Ed. and H. Levkowetz, Ed., "Problem
              Statement: Mobile IPv4 Traversal of Virtual Private
              Network (VPN) Gateways", RFC 4093, August 2005.

   [RFC4106]  Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
              (GCM) in IPsec Encapsulating Security Payload (ESP)", RFC
              4106, June 2005.

   [RFC4109]  Hoffman, P., "Algorithms for Internet Key Exchange version
              1 (IKEv1)", RFC 4109, May 2005.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302, December
              2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
              4303, December 2005.

   [RFC4304]  Kent, S., "Extended Sequence Number (ESN) Addendum to
              IPsec Domain of Interpretation (DOI) for Internet Security
              Association and Key Management Protocol (ISAKMP)", RFC
              4304, December 2005.

   [RFC4305]  Eastlake, D. 3rd, "Cryptographic Algorithm Implementation
              Requirements for Encapsulating Security Payload (ESP) and
              Authentication Header (AH)", RFC 4305, December 2005
              (obsolete).




Frankel & Krishnan         Expires June 2009                   [Page 35]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


   [RFC4306]  Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
              Protocol", RFC 4306, December 2005.

   [RFC4307]  Schiller, J., "Cryptographic Algorithms for Use in the
              Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
              December 2005.

   [RFC4308]  Hoffman, P., "Cryptographic Suites for IPsec", RFC 4308,
              December 2005.

   [RFC4309]  Housley, R., "Using Advanced Encryption Standard (AES) CCM
              Mode with IPsec Encapsulating Security Payload (ESP)", RFC
              4309, December 2005.

   [RFC4312]  Kato, A., S. Moriai and M. Kanda, "The Camellia Cipher
              Algorithm and Its Use with IPsec", RFC 4312, December
              2005.

   [RFC4359]  Weis, B., "The Use of RSA/SHA-1 Signatures within
              Encapsulating Security Payload (ESP) and Authentication
              Header (AH)", RFC 4359, January 2006.

   [RFC4383]  Baugher, M. and E. Carrara, "The Use of Timed Efficient
              Stream Loss-Tolerant Authentication (TESLA) in the Secure
              Real-time Transport Protocol (SRTP)", RFC 4383, February
              2006.

   [RFC4430]  Sakane, S., K. Kamada, M. Thomas, and J. Vilhuber,
              "Kerberized Internet Negotiation of Keys (KINK)", RFC
              4430, March 2006.

   [RFC4434]  Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
              Internet Key Exchange Protocol (IKE)", RFC 4434, February
              2006.

   [RFC4442]  Fries, S. and H. Tschofenig, "Bootstrapping Timed
              Efficient Stream Loss-Tolerant Authentication (TESLA)",
              RFC 4442, March 2006.

   [RFC4478]  Nir, Y., "Repeated Authentication in Internet Key Exchange
              (IKEv2) Protocol", RFC 4478, April 2006.

   [RFC4494]  Song, JH., R. Poovendran and J. Lee, "The AES-CMAC-96
              Algorithm and Its Use with IPsec", RFC 4494, June 2006.

   [RFC4534]  Colegrove, A. and H. Harney, "Group Security Policy Token
              v1", RFC 4534, June 2006.




Frankel & Krishnan         Expires June 2009                   [Page 36]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


   [RFC4535]  Harney, H., U. Meth, A. Colegrove and G. Gross, "GSAKMP:
              Group Secure Association Key Management Protocol", RFC
              4535, June 2006.

   [RFC4543]  McGrew, D. and J. Viega, "The Use of Galois Message
              Authentication Code (GMAC) in IPsec ESP and AH", RFC 4543,
              May 2006.

   [RFC4552]  Gupta, M. and N. Melam, "Authentication/Confidentiality
              for OSPFv3", RFC 4552, June 2006.

   [RFC4555]  Eronen, P., "IKEv2 Mobility and Multihoming Protocol
              (MOBIKE)", RFC 4555, June 2006.

   [RFC4563]  Carrara, E., V. Lehtovirta and K. Norrman, "The Key ID
              Information Type for the General Extension Payload in
              Multimedia Internet KEYing (MIKEY)", RFC 4563, June 2006.

   [RFC4595]  Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel
              Security Association Management Protocol", RFC 4595, July
              2006.

   [RFC4615]  Song, J., R. Poovendran, J. Lee and T. Iwata, "The
              Advanced Encryption Standard-Cipher-based Message
              Authentication Code-Pseudo-Random Function-128
              (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange
              Protocol (IKE)", RFC 4615, August 2006.

   [RFC4621]  Kivinen, T. and H. Tschofenig, "Design of the IKEv2
              Mobility and Multihoming (MOBIKE) Protocol", RFC 4621,
              August 2006.

   [RFC4650]  Euchner, M., "HMAC-Authenticated Diffie-Hellman for
              Multimedia Internet KEYing (MIKEY)", RFC 4650, September
              2006.

   [RFC4718]  Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
              Implementation Guidelines", RFC 4718, October 2006.

   [RFC4738]  Ignjatic, D., L. Dondeti, F. Audet and P. Lin,
              "MIKEY-RSA-R: An Additional Mode of Key Distribution in
              Multimedia Internet KEYing (MIKEY)", RFC 4738, November
              2006.

   [RFC4739]  Eronen P. and J. Korhonen, "Multiple Authentication
              Exchanges in the Internet Key Exchange (IKEv2) Protocol",
              RFC 4739, November 2006.




Frankel & Krishnan         Expires June 2009                   [Page 37]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


   [RFC4753]  Fu, D. and J. Solinas, "ECP Groups For IKE and IKEv2", RFC
              4753, January 2007.

   [RFC4754]  Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using
              the Elliptic Curve Digital Signature Algorithm (ECDSA)",
              RFC 4754, January 2007.

   [RFC4806]  Myers, M. and H. Tschofenig, "Online Certificate Status
              Protocol (OCSP) Extensions to IKEv2", RFC 4806, February
              2007.

   [RFC4807]  Baer, M., R. Charlet, W. Hardaker, R. Story and C. Wang,
              "IPsec Security Policy Database Configuration MIB", RFC
              4807, March 2007.

   [RFC4809]  Bonatti, C., Ed., and S. Turner, Ed., "Requirements for an
              IPsec Certificate Management Profile", RFC 4809, February
              2007.

   [RFC4835]  Manral, V., "Cryptographic Algorithm Implementation
              Requirements for Encapsulating Security Payload (ESP) and
              Authentication Header (AH)", RFC 4835, April 2007.

   [RFC4868]  Kelly, S. and S. Frankel, "Using HMAC-SHA-256,
              HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, May
              2007.

   [RFC4869]  Law, L. and J. Solinas, "Suite B Cryptographic Suites for
              IPsec", RFC 4869, May 2007.

   [RFC4877]  Devarapalli, V. and R. Dupont, "Mobile IPv6 Operation with
              IKEv2 and the Revised IPsec Architecture", RFC 4877, April
              2007.

   [RFC4891]  Graveman, R., M. Parthasarathy, P. Savola and H.
              Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels",
              RFC 4891, May 2007.

   [RFC4894]  Hoffman, P., "Use of Hash Algorithms in Internet Key
              Exchange (IKE) and IPsec", RFC 4894, May 2007.

   [RFC4945]  Korver, B., "The Internet IP Security PKI Profile of
              IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007.

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2", RFC
              4949, August 2007.

   [RFC5056]  Williams, N., "On the Use of Channel Bindings to Secure



Frankel & Krishnan         Expires June 2009                   [Page 38]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


              Channels", RFC 5056, November 2007.

   [RFC5106]  Tschofenig, H., D. Kroeselberg, A. Pashalidis, Y. Ohba and
              F. Bersani, "The Extensible Authentication
              Protocol-Internet Key Exchange Protocol version 2
              (EAP-IKEv2) Method", RFC 5106, February 2008.

   [RFC5114]  Lepinski, M. and S. Kent, "Additional Diffie-Hellman
              Groups for Use with IETF Standards", RFC 5114, January
              2008.

   [RFC 5191]  Forsberg, D., Y. Ohba, Ed., B. Patil, H. Tschofenig and
              A. Yegin, Protocol for Carrying Authentication for Network
              Access (PANA), RFC 5191, May 2008.

   [RFC5197]  Fries, S. and D. Ignjatic, "On the Applicability of
              Various Multimedia Internet KEYing (MIKEY) Modes and
              Extensions", RFC 5197, June 2008.

   [RFC5201]  Moskowitz, R., P. Nikander, P. Jokela, Ed., and T.
              Henderson, "Host Identity Protocol", RFC 5201, April 2008.

   [RFC5202]  Jokela, P., R. Moskowitz and P. Nikander, "Using the
              Encapsulating Security Payload (ESP) Transport Format with
              the Host Identity Protocol (HIP)", RFC 5202, April 2008.

   [RFC5206]  Nikander, P., T. Henderson, Ed., C. Vogt, and J. Arkko,
              "End-Host Mobility and Multihoming with the Host
              Identity", RFC 5206, April 2008.

   [RFC5207]  Stiemerling, M., J. Quittek and L. Eggert, "NAT and
              Firewall Traversal Issues of Host Identity Protocol
              (HIP)", RFC 5207, April 2008.

   [RFC5213]  Gundavelli, Ed., K. Leung, V. Devarapali, K. Chowdhury and
              B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

   [RFC5265]  Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal across
              IPsec-Based VPN Gateways", RFC 5265, June 2008.

   [RFC5266]   Devarapalli, V. and P. Eronen, "Secure Connectivity and
              Mobility Using Mobile IPv4 and IKEv2 Mobility and
              Multihoming (MOBIKE)", RFC 5266, June 2008.

   [RFC5268]  Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268,
              June 2008.

   [RFC5282]  Black, D. and D. McGrew, " Using Authenticated Encryption



Frankel & Krishnan         Expires June 2009                   [Page 39]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


              Algorithms with the Encrypted Payload of the Internet Key
              Exchange version 2 (IKEv2) Protocol", RFC 5282, August
              2008.

   [RFC5380]  Soliman, H., C. Castelluccia, K. ElMalki and L. Bellier,
              "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management",
              RFC 5380, October 2008.

   [RFC5386]  Williams, N. and M. Richardson,
              "Better-Than-Nothing-Security: An Unauthenticated Mode of
              IPsec", RFC 5386, November 2008.

   [RFC5387]  Touch, J., D. Black and Y. Wang, "Problem and
              Applicability Statement for Better-Than-Nothing Security
              (BTNS)", RFC 5387, November 2008.

Authors' Addresses

   Sheila Frankel
   NIST Bldg. 223 Rm. B366
   Gaithersburg, MD 20899

   Phone: 1-301-975-3297
   Email: sheila.frankel@nist.gov

   Suresh Krishnan
   Ericsson
   8400 Decarie Blvd.
   Town of Mount Royal, QC
   Canada

   Phone: 1-514-345-7900 x42871
   Email: suresh.krishnan@ericsson.com

Intellectual Property

   All IETF Documents and the information contained herein are provided
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
   WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
   RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
   PARTICULAR PURPOSE.

   The IETF Trust takes no position regarding the validity or scope of
   any Intellectual Property Rights or other rights that might be
   claimed to pertain to the implementation or use of the technology



Frankel & Krishnan         Expires June 2009                   [Page 40]

Internet Draft              IPsec/IKE Roadmap         December 22, 2008


   described in any IETF Document or the extent to which any license
   under such rights might or might not be available; nor does it
   represent that it has made any independent effort to identify any
   such rights.

   Copies of Intellectual Property disclosures made to the IETF
   Secretariat and any assurances of licenses to be made available, or
   the result of an attempt made to obtain a general license or
   permission for the use of such proprietary rights by implementers or
   users of this specification can be obtained from the IETF on-line IPR
   repository at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   any standard or specification contained in an IETF Document.  Please
   address the information to the IETF at ietf-ipr@ietf.org.

   The definitive version of an IETF Document is that published by, or
   under the auspices of, the IETF.  Versions of IETF Documents that are
   published by third parties, including those that are translated into
   other languages, should not be considered to be definitive versions
   of IETF Documents.  The definitive version of these Legal Provisions
   is that published by, or under the auspices, of the IETF.  Versions
   of these Legal Provisions that are published by third parties,
   including those that are translated into other languages, should not
   be considered to be definitive versions of these Legal Provisions.

   For the avoidance of doubt, each Contributor to the IETF Standards
   Process licenses each Contribution that he or she makes as part of
   the IETF Standards Process to the IETF Trust pursuant to the
   provisions of RFC 5378.  No language to the contrary, or terms,
   conditions or rights that differ from or are inconsistent with the
   rights and licenses granted under RFC 5378, shall have any effect and
   shall be null and void, whether published or posted by such
   Contributor, or included with or in such Contribution.















Frankel & Krishnan         Expires June 2009                   [Page 41]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/