tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 6071

Informational
Pages: 63
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: IPSECME

IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap

Part 1 of 4, p. 1 to 15
None       Next RFC Part

Obsoletes:    2411


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                        S. Frankel
Request for Comments: 6071                                          NIST
Obsoletes: 2411                                              S. Krishnan
Category: Informational                                         Ericsson
ISSN: 2070-1721                                            February 2011


  IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap

Abstract

   Over the past few years, the number of RFCs that define and use IPsec
   and Internet Key Exchange (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 RFC 2411, the previous "IP
   Security Document Roadmap."

   The obsoleted IPsec roadmap (RFC 2411) briefly described the
   interrelationship of the various classes of base IPsec documents.
   The major focus of RFC 2411 was to specify the recommended contents
   of documents specifying additional encryption and authentication
   algorithms.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6071.

Page 2 
Copyright Notice

   Copyright (c) 2011 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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1. Introduction ....................................................4
   2. IPsec/IKE Background Information ................................5
      2.1. Interrelationship of IPsec/IKE Documents ...................5
      2.2. Versions of IPsec ..........................................6
           2.2.1. Differences between "Old" IPsec (IPsec-v2) and
                  "New" IPsec (IPsec-v3) ..............................6
      2.3. Versions of IKE ............................................7
           2.3.1. Differences between IKEv1 and IKEv2 .................8
      2.4. IPsec and IKE IANA Registries ..............................9
   3. IPsec Documents .................................................9
      3.1. Base Documents .............................................9
           3.1.1. "Old" IPsec (IPsec-v2) ..............................9
           3.1.2. "New" IPsec (IPsec-v3) .............................11
      3.2. Additions to IPsec ........................................11
      3.3. General Considerations ....................................14
   4. IKE Documents ..................................................15
      4.1. Base Documents ............................................15
           4.1.1. IKEv1 ..............................................15
           4.1.2. IKEv2 ..............................................16

Top      ToC       Page 3 
      4.2. Additions and Extensions ..................................17
           4.2.1. Peer Authentication Methods ........................17
           4.2.2. Certificate Contents and Management (PKI4IPsec) ....18
           4.2.3. Dead Peer Detection ................................19
           4.2.4. Remote Access ......................................19
   5. Cryptographic Algorithms and Suites ............................21
      5.1. Algorithm Requirements ....................................22
      5.2. Encryption Algorithms .....................................23
      5.3. Integrity-Protection (Authentication) Algorithms ..........27
      5.4. Combined Mode Algorithms ..................................30
      5.5. Pseudo-Random Functions (PRFs) ............................33
      5.6. Cryptographic Suites ......................................34
      5.7. Diffie-Hellman Algorithms .................................35
   6. IPsec/IKE for Multicast ........................................36
   7. Outgrowths of IPsec/IKE ........................................38
      7.1. IPsec Policy ..............................................38
      7.2. IPsec MIBs ................................................39
      7.3. IPComp (Compression) ......................................39
      7.4. Better-Than-Nothing Security (BTNS) .......................39
      7.5. Kerberized Internet Negotiation of Keys (KINK) ............40
      7.6. IPsec Secure Remote Access (IPSRA) ........................41
      7.7. IPsec Keying Information Resource Record (IPSECKEY) .......42
   8. Other Protocols That Use IPsec/IKE .............................42
      8.1. Mobile IP (MIPv4 and MIPv6) ...............................42
      8.2. Open Shortest Path First (OSPF) ...........................44
      8.3. Host Identity Protocol (HIP) ..............................45
      8.4. Stream Control Transmission Protocol (SCTP) ...............46
      8.5. Robust Header Compression (ROHC) ..........................46
      8.6. Border Gateway Protocol (BGP) .............................47
      8.7. IPsec Benchmarking ........................................47
      8.8. Network Address Translators (NAT) .........................48
      8.9. Session Initiation Protocol (SIP) .........................48
      8.10. Explicit Packet Sensitivity Labels .......................49
   9. Other Protocols That Adapt IKE for Non-IPsec Functionality .....49
      9.1. Extensible Authentication Protocol (EAP) ..................49
      9.2. Fibre Channel .............................................49
      9.3. Wireless Security .........................................50
   10. Acknowledgements ..............................................50
   11. Security Considerations .......................................50
   12. References ....................................................50
      12.1. Informative References ...................................50
   Appendix A.  Summary of Algorithm Requirement Levels ..............61

Top      ToC       Page 4 
1.  Introduction

   IPsec (Internet Protocol Security) 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., Mobile IP version 6
   (MIPv6)) to protect some or all of their traffic.  IKE (Internet Key
   Exchange) is the key negotiation and management protocol that is most
   commonly used to provide dynamically negotiated and updated keying
   material for IPsec.  IPsec and IKE can be used in conjunction with
   both IPv4 and IPv6.

   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 obsoletes [RFC2411].  It attempts
   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)

      o E: Experimental

      o B: Best Current Practice

      o I: Informational

   For each RFC, the publication date is also given.

   This document also categorizes the requirements level of each
   cryptographic algorithm for use with IKEv1, IKEv2, IPsec-v2, and
   IPsec-v3.  These requirements are summarized in Appendix A.  These
   levels are current as of February 2011; subsequent RFCs may result in
   altered requirement levels.

   This document does not define requirement levels; it simply restates
   those found in the IKE and IPsec RFCs.  If there is a conflict
   between this document and any other RFC, then the other RFC takes
   precedence.

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

Top      ToC       Page 5 
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 that broadly covers the general concepts,
   security requirements, definitions, and mechanisms defining IPsec
   technology.

   There are an Encapsulating Security Payload (ESP) Protocol document
   and an Authentication Header (AH) Protocol document that 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 mode
   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.

Top      ToC       Page 6 
                             +--------------+
                             | 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  |
                              +------------+

               Figure 1. IPsec/IKE Document Interrelationships

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; see Section
   3.1.1 for the RFC descriptions) obsoleted the "old" IPsec (referred
   to as IPsec-v2 in this document; see Section 3.1.2 for the RFC
   descriptions); 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 (defined in RFCs 1825-1829), 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.

Top      ToC       Page 7 
   Knowledge was gained about the barriers to IPsec deployment, the
   scenarios in which IPsec is most effective, and the requirements that
   needed to be added to IPsec to facilitate its use with other
   protocols.  In addition, the documentation for IPsec-v3 clarifies and
   expands 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 the 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 Extended sequence numbers (ESNs) were added

      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 Combined mode algorithms were added, 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.

Top      ToC       Page 8 
2.3.1.  Differences between IKEv1 and IKEv2

   As with IPsec-v3, IKEv2 incorporates "lessons learned" from
   implementation and operational experience with IKEv1.  Knowledge was
   gained about the barriers to IKE deployment, the scenarios in which
   IKE is most effective, and the requirements that needed to be added
   to IKE to facilitate its use with other protocols as well as in
   general-purpose use.  The documentation for IKEv2 replaces multiple,
   at times 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.  Since
   IKE always negotiates pairs of SAs, the term "SA" is generally used
   to refer to a pair of SAs (e.g., an "IKE SA" or an "IPsec SA" is in
   reality a pair of one-way SAs).  The first SA, the IKE SA, is used to
   protect IKE traffic.  The second SA provides IPsec protection to data
   traffic between the peers and/or other devices for which the peers
   are authorized to negotiate.  It is called the IPsec SA in IKEv1 and,
   in the IKEv2 RFCs, it is referred to variously as a CHILD_SA, a child
   SA, and an IPsec SA.  This document uses the term "IPsec SA".  To
   further complicate the terminology, since IKEv1 consists of two
   sequential negotiations, called phases, the IKE SA is also referred
   to as a Phase 1 SA and the IPsec SA is referred to as a Phase 2 SA.

   Changes to IKE include:

      o Replaced multiple alternate exchange types with a single,
        shorter exchange

      o Streamlined negotiation format to avoid combinatorial bloat for
        multiple proposals

      o Protect 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

      o Support of EAP-based authentication methods and asymmetric
        authentication (i.e., initiator and responder can use different
        authentication methods)

Top      ToC       Page 9 
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 Internet Security Association and Key
         Management Protocol (ISAKMP)
         (http://www.iana.org/assignments/isakmp-registry): values used
         during IKEv1 Phase 2 exchanges, defined in [RFC2407],
         [RFC2408], and numerous other cryptographic algorithm RFCs.

      o  IKEv2 Parameters
         (http://www.iana.org/assignments/ikev2-parameters): values used
         in IKEv2 exchanges, defined in [RFC5996] 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].

3.  IPsec Documents

3.1.  Base Documents

   IPsec protections are provided by two special headers: the
   Encapsulating Security Payload (ESP) Header and the Authentication
   Header (AH).  In IPv4, these headers take the form of protocol
   headers; in IPv6, they are classified as extension headers.  There
   are three base IPsec documents: one that describes the IP security
   architecture, and one for each of the IPsec headers.

3.1.1.  "Old" IPsec (IPsec-v2)

3.1.1.1.  RFC 2401, Security Architecture for the Internet Protocol
          (S, November 1998)

   [RFC2401] specifies 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.

Top      ToC       Page 10 
   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 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 facilitate 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 three general classes of
        traffic are traffic to be discarded, traffic that is allowed
        without IPsec protection, and traffic that requires IPsec
        protection.

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

3.1.1.2.  RFC 2402, IP Authentication Header (S, November 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.

Top      ToC       Page 11 
3.1.1.3.  RFC 2406, IP Encapsulating Security Payload (ESP)
          (S, November 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,
   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 (IPsec-v3)

3.1.2.1.  RFC 4301, Security Architecture for the Internet Protocol
          (S, December 2005)

   [RFC4301] obsoletes [RFC2401], and it includes 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 protocol (e.g., IKE)

3.1.2.2.  RFC 4302, IP Authentication Header (S, December 2005)

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

3.1.2.3.  RFC 4303, IP Encapsulating Security Payload (ESP)
          (S, December 2005)

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

3.2.  Additions to IPsec

   Once the IKEv1 and IPsec-v2 RFCs were finalized, several additions
   were defined in separate documents: negotiation of NAT traversal,
   extended sequence numbers, UDP encapsulation of ESP packets,
   opportunistic encryption, and IPsec-related ICMP messages.
   Additional uses of IPsec transport mode were also described:
   protection of manually configured IPv6-in-IPv4 tunnels and protection
   of IP-in-IP tunnels.  These documents describe atypical uses of IPsec
   transport mode, but do not define any new IPsec features.

Top      ToC       Page 12 
   Once the original IPsec Working Group concluded, additional IPsec-
   related issues were handled by the IPsecME (IPsec Maintenance and
   Extensions) Working Group.  One such problem is the capability of
   middleboxes to distinguish unencrypted ESP packets (ESP-NULL) from
   encrypted ones in a fast and accurate manner.  Two solutions are
   described: a new protocol that requires changes to IKEv2 and IPsec-v3
   and a heuristic method that imposes no new requirements.  Another
   issue that was addressed is the problem of using IKE and IPsec in a
   high-availability environment.

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

   [RFC3947] defines an optional extension to IKEv1.  It 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
   [RFC5996].

3.2.2.  RFC 3948, UDP Encapsulation of IPsec ESP Packets
        (S, January 2005)

   [RFC3948] is an optional extension for IPsec-v2 and IPsec-v3.  It
   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 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 [RFC5996] for IKEv2.

3.2.3.  RFC 4304, Extended Sequence Number (ESN) Addendum to IPsec
        Domain of Interpretation (DOI) for Internet Security Association
        and Key Management Protocol (ISAKMP) (S, December 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 redesign of the
   packet format.  The larger sequence numbers allow an existing IPsec
   SA to be used for larger volumes of data.  [RFC4304] describes an
   optional extension to IKEv1 that enables IKEv1 to negotiate the use
   of ESNs for IPsec SAs.  For IKEv2, this capability is described in
   [RFC5996].

Top      ToC       Page 13 
3.2.4.  RFC 4322, Opportunistic Encryption using the Internet Key
        Exchange (IKE) (I, December 2005)

   Opportunistic encryption allows a pair of end systems to use
   encryption without any specific pre-arrangements.  [RFC4322]
   specifies a mechanism that uses DNS to distribute the public keys of
   each system involved and uses DNS Security (DNSSEC) to secure the
   mechanism against active attackers.  It specifies the changes that
   are needed in existing IPsec and IKE implementations.  The majority
   of the changes are needed in the IKE implementation and these changes
   relate to the handling of key acquisition requests, the lookup of
   public keys and TXT records, and the interactions with firewalls and
   other security facilities that may be co-resident on the same
   gateway.

3.2.5.  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]).

3.2.6.  RFC 3884, Use of IPsec Transport Mode for Dynamic Routing
        (I, September 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.  This RFC has not been
   widely adopted.

3.2.7.  RFC 5840, Wrapped Encapsulating Security Payload (ESP) for
        Traffic Visibility  (S, April 2010)

   ESP, as defined in [RFC4303], does not allow a network device to
   easily determine whether protected traffic that is passing through
   the device is encrypted or only integrity protected (referred to as
   ESP-NULL packets).  [RFC5840] extends ESPv3 to provide explicit
   notification of integrity-protected packets, and extends IKEv2 to
   negotiate this capability between the IPsec peers.

Top      ToC       Page 14 
3.2.8.  RFC 5879, Heuristics for Detecting ESP-NULL packets
        (I, May 2010)

   [RFC5879] offers an alternative approach to differentiating between
   ESP-encrypted and ESP-NULL packets through packet inspection.  This
   method does not require any change to IKE or ESP; it can be used with
   ESP-v2 or ESP-v3.

3.3.  General Considerations

3.3.1.  RFC 3715, IPsec-Network Address Translation (NAT) Compatibility
        Requirements (I, March 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.

3.3.2.  RFC 5406, Guidelines for Specifying the Use of IPsec Version 2
        (B, February 2009)

   [RFC5406] offers guidance to protocol designers on how to ascertain
   whether IPsec is the appropriate security mechanism to provide an
   interoperable security solution for the protocol.  If this is not the
   case, it advises against attempting to define a new security
   protocol; rather, it suggests using another standards-based security
   protocol.  The details in this document apply only to IPsec-v2.

3.3.3.  RFC 2521, ICMP Security Failures Messages (E, March 1999)

   [RFC2521] specifies an ICMP message for indicating failures related
   to the use of IPsec protocols (AH and ESP).  The specified ICMP
   message defines several codes for handling common failure modes for
   IPsec.  The failures that are signaled by this message include
   invalid or expired SPIs, failure of authenticity or integrity checks
   on datagrams, decryption and decompression errors, etc.  These
   messages can be used to trigger automated session-key management or
   to signal to an operator the need to manually reconfigure the SAs.
   This RFC has not been widely adopted.  Furthermore, [RFC4301]
   discusses the pros and cons of relying on unprotected ICMP messages.

3.3.4.  RFC 6027, IPsec Cluster Problem Statement (I, October 2010)

   [RFC6027] describes the problems of using IKE and IPsec in a high
   availability environment, in which one or both of the peers are
   clusters of gateways.  It details the numerous types of stateful

Top      ToC       Page 15 
   information shared by IKE and IPsec peers that would have to be
   available to other members of the cluster in order to provide high-
   availability, load sharing, and/or failover capabilities.



(page 15 continued on part 2)

Next RFC Part