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 large variety of possible multicast groups.

6.1.  RFC 3740, The Multicast Group Security Architecture
      (I, March 2004)

   [RFC3740] defines the multicast security architecture, which is used
   to provide security for packets exchanged by large multicast groups.
   It defines the components of the architectural framework; discusses
   Group Security Associations (GSAs), key management, data handling,
   and security policies.  Several existing protocols, including Group
   DOI (GDOI) [RFC3547], Group Secure Association Key Management
   Protocol (GSAKMP) [RFC4535],  and Multimedia Internet KEYing (MIKEY)
   [RFC3830], satisfy the group key management requirements defined in
   this document.  Both the architecture and the components for
   Multicast Group Security differ from IPsec.

6.2.  RFC 5374, Multicast Extensions to the Security Architecture for
      the Internet Protocol (S, November 2008)

   [RFC5374] extends the security architecture defined in [RFC4301] to
   apply to multicast traffic.  It defines a new class of SAs (GSAs -
   Group Security Associations) and additional databases used to apply
   IPsec protection to multicast traffic.  It also describes revisions
   and additions to the processing algorithms in [RFC4301].

6.3.  RFC 3547, The Group Domain of Interpretation (S, July 2003)

   GDOI [RFC3547] extends IKEv1 so that it can be used to establish SAs
   to protect multicast traffic.  This document defines additional
   exchanges and payloads to be used for that purpose.

6.4.  RFC 4046, Multicast Security (MSEC) Group Key Management
      Architecture (I, April 2005)

   [RFC4046] sets out the general requirements and design principles for
   protocols that are used for multicast key management.  It does not go
   into the specifics of an individual protocol that can be used for
   that purpose.

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

   [RFC4359] describes the use of the RSA digital signature algorithm to
   provide integrity protection for multicast traffic within ESP and AH.
   The algorithms used for integrity protection for unicast traffic
   (e.g., HMAC) are not suitable for this purpose when used with
   multicast traffic.

7.  Outgrowths of IPsec/IKE

   Operational experience with IPsec revealed additional capabilities
   that could make IPsec more useful in real-world scenarios.  These
   include support for IPsec policy mechanisms, IPsec MIBs, payload
   compression (IPComp), extensions to facilitate additional peer
   authentication methods (Better-Than-Nothing Security (BTNS),
   Kerberized Internet Negotiation of Keys (KINK), and IPSECKEY), and
   additional capabilities for VPN clients (IPSRA).

7.1.  IPsec Policy

   The IPsec Policy (ipsp) Working Group originally planned an RFC that
   would allow entities with no common Trust Anchor and no prior
   knowledge of each other's 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.

7.1.1.  RFC 3586, IP Security Policy (IPSP) Requirements
        (S, August 2003)

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

7.1.2.  RFC 3585, IPsec Configuration Policy Information Model
        (S, August 2003)

   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.

   This RFC has not been widely adopted.

7.2.  IPsec MIBs

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

7.2.1.  RFC 4807, IPsec Security Policy Database Configuration MIB
        (S, March 2007)

   [RFC4807] defines a MIB module that can be used to configure the SPD
   of an IPsec device.  This RFC has not been widely adopted.

7.3.  IPComp (Compression)

   The IP Payload Compression Protocol (IPComp) is a protocol that
   provides lossless compression for IP datagrams.  Although IKE can be
   used to negotiate the use of IPComp in conjunction with IPsec, IPComp
   can also be used when IPsec is not applied.

   The IPComp protocol allows the compression of IP datagrams by
   supporting different compression algorithms.  Three of these
   algorithms are: DEFLATE [RFC2394], LZS [RFC2395], and the ITU-T V.44
   Packet Method [RFC3051], which is based on the LZJH algorithm.

7.3.1.  RFC 3173, IP Payload Compression Protocol (IPComp)
        (S, September 2001)

   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.

7.4.  Better-Than-Nothing Security (BTNS)

   One of the major obstacles to widespread implementation of IPsec is
   the lack of pre-existing credentials that can be used for peer
   authentication.  Better-Than-Nothing Security (BTNS) is an attempt to
   sidestep this problem by allowing IKE to negotiate unauthenticated
   (anonymous) IPsec SAs, using credentials such as self-signed
   certificates or "bare" public keys (public keys that are not
   connected to a public key certificate) for peer authentication.  This
   ensures that subsequent traffic protected by the SA is conducted with

   the same peer, and protects the communications from passive attack.
   These SAs can then be cryptographically bound to a higher-level
   application protocol, which performs its own peer authentication.

7.4.1.  RFC 5660, IPsec Channels: Connection Latching (S, October 2009)

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

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

   [RFC5386] specifies how to use IKEv2 to set up 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).

7.4.3.  RFC 5387, Problem and Applicability Statement for Better-Than-
        Nothing Security (BTNS) (I, November 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.

7.5.  Kerberized Internet Negotiation of Keys (KINK)

   Kerberized Internet Negotiation of Keys (KINK) is an attempt to
   provide an alternative to IKE for IPsec peer authentication.  It uses
   Kerberos, instead of IKE, to establish IPsec SAs.  For enterprises
   that already deploy the Kerberos centralized key management system,
   IPsec can then be implemented without the need for additional peer
   credentials.  Some vendors have implemented proprietary extensions
   for using Kerberos in IKEv1, as an alternative to the use of KINK.
   These extensions, as well as the KINK protocol, apply only to IKEv1,
   and not to IKEv2.

7.5.1.  RFC 3129, Requirements for Kerberized Internet Negotiation of
        Keys (I, June 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 that can establish
   and maintain IPsec security associations ([RFC2401]).

7.5.2.  RFC 4430, Kerberized Internet Negotiation of Keys (KINK)
        (S, March 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.  This RFC
   has not been widely adopted.

7.6.  IPsec Secure Remote Access (IPSRA)

   IPsec Secure Remote Access (IPSRA) was an attempt to extend IPsec
   protection to "road warriors", allowing IKE to authenticate not only
   the user's device but also the user, without changing IKEv1.  The
   working group defined generic requirements of different IPsec remote
   access scenarios.  An attempt was made to define an IKE-like protocol
   that would use legacy authentication mechanisms to create a temporary
   or short-lived user credential that could be used for peer
   authentication within IKE.  This protocol proved to be more
   cumbersome than standard Public Key protocols, and was abandoned.
   This led to the development of IKEv2, which incorporates the use of
   EAP for user authentication.

7.6.1.  RFC 3457, Requirements for IPsec Remote Access Scenarios
        (I, January 2003)

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

7.6.2.  RFC 3456, Dynamic Host Configuration Protocol (DHCPv4)
        Configuration of IPsec Tunnel Mode (S, January 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.  This RFC has not been widely adopted.

7.7.  IPsec Keying Information Resource Record (IPSECKEY)

   The IPsec Keying Information Resource Record (IPSECKEY) enables the
   storage of public keys and other information that can be used to
   facilitate opportunistic IPsec in a new type of DNS resource record.

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

   [RFC4025] describes a method of storing IPsec keying material in the
   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.
   This RFC has not been widely adopted.

8.  Other Protocols That Use IPsec/IKE

   IPsec and IKE were designed to provide IP-layer security protection
   to other Internet protocols' traffic as well as generic
   communications.  Since IPsec is a general-purpose protocol, in some
   cases, its features do not provide the granularity or distinctive
   features required by another protocol; in some cases, its overhead or
   prerequisites do not match another protocol's requirements.  However,
   a number of other protocols do use IKE and/or IPsec to protect some
   or all of their communications.

8.1.  Mobile IP (MIPv4 and MIPv6)

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

   [RFC4093] describes the issues with deploying Mobile IPv4 across
   virtual private networks (VPNs).  IPsec is one of the VPN
   technologies covered by this document.  It identifies and describes
   practical deployment scenarios for Mobile IPv4 running alongside
   IPsec in enterprise and operator environments.  It also specifies a
   set of framework guidelines to evaluate proposed solutions for
   supporting multi-vendor seamless IPv4 mobility across IPsec-based VPN
   gateways.

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

   [RFC5265] describes a basic solution that uses Mobile IPv4 and IPsec
   to provide session mobility between enterprise intranets and external
   networks.  The proposed solution minimizes changes to existing
   firewall/VPN/DMZ deployments and does not require any changes to
   IPsec or key exchange protocols.  It also proposes a mechanism to
   minimize IPsec renegotiation when the mobile node moves.

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

   This document specifies the use of IPsec in securing Mobile IPv6
   traffic between mobile nodes and home agents.  It specifies the
   required wire formats for the protected packets and illustrates
   examples of Security Policy Database and Security Association
   Database entries that can be used to protect Mobile IPv6 signaling
   messages.  It also describes how to configure either manually keyed
   IPsec security associations or IKEv1 to establish the SAs
   automatically.  Mobile IPv6 requires considering the home address
   destination option and Routing Header in IPsec processing.  Also,
   IPsec and IKE security association addresses can be updated by Mobile
   IPv6 signaling messages.

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

   This document updates [RFC3776] in order to work with the revised
   IPsec architecture [RFC4301].  Since the revised IPsec architecture
   expands the list of selectors to include the Mobility Header message
   type, it becomes much easier to differentiate between different
   mobility header messages.  Since the ICMP message type and code are
   also newly added as selectors, this document uses them to protect
   Mobile Prefix Discovery messages.  This document also specifies the
   use of IKEv2 configuration payloads for dynamic home address
   configuration.  Finally, this document describes the use of IKEv2 in
   order to set up the SAs for Mobile IPv6.

8.1.5.  RFC 5026, Mobile IPv6 Bootstrapping in Split Scenario
        (S, October 2007)

   [RFC5026] extends [RFC4877] to support dynamic discovery of home
   agents and the home network prefix; for the latter purpose, it
   specifies a new IKEv2 configuration attribute and notification.  It
   describes how a Mobile IPv6 node can obtain the address of its home
   agent, its home address, and create IPsec security associations with
   its home agent using DNS lookups and security credentials
   preconfigured on the Mobile Node.  It defines how a mobile node (MN)
   can request its home address and home prefixes through the
   Configuration Payload in the IKE_AUTH exchange and what attributes
   need to be present in the CFG_REQUEST messages in order to do this.
   It also specifies how the home agent can authorize the credentials
   used for IKEv2 exchange.

8.1.6.  RFC 5213, Proxy Mobile IPv6 (S, August 2008)

   [RFC5213] describes a network-based mobility management protocol that
   is used to provide mobility services to hosts without requiring their
   participation in any mobility-related signaling.  It uses IPsec to
   protect the mobility signaling messages between the two network
   entities called the mobile access gateway (MAG) and the local
   mobility anchor (LMA).  It also uses IKEv2 in order to set up the
   security associations between the MAG and the LMA.

8.1.7.  RFC 5568, Mobile IPv6 Fast Handovers (S, July 2009)

   When Mobile IPv6 is used for a handover, there is a period during
   which the Mobile Node is unable to send or receive packets because of
   link switching delay and IP protocol operations.  [RFC5568] specifies
   a protocol between the Previous Access Router (PAR) and the New
   Access Router (NAR) to improve handover latency due to Mobile IPv6
   procedures.  It uses IPsec ESP in transport mode with integrity
   protection for protecting the signaling messages between the PAR and
   the NAR.  It also describes the SPD entries and the PAD entries when
   IKEv2 is used for setting up the required SAs.

8.1.8.  RFC 5380, Hierarchical Mobile IPv6 (HMIPv6) Mobility Management
        (S, October 2008)

   [RFC5380] describes extensions to Mobile IPv6 and IPv6 Neighbor
   Discovery to allow for local mobility handling in order to reduce the
   amount of signaling between the mobile node, its correspondent nodes,
   and its home agent.  It also improves handover speed of Mobile IPv6.
   It uses IPsec for protecting the signaling between the mobile node
   and a local mobility management entity called the Mobility Anchor
   Point (MAP).  The MAP also uses IPsec Peer Authorization Database
   (PAD) entries and configuration payloads described in [RFC4877] in
   order to allocate a Regional Care-of Address (RCoA) for mobile nodes.

8.2.  Open Shortest Path First (OSPF)

8.2.1.  RFC 4552, Authentication/Confidentiality for OSPFv3
        (S, June 2006)

   OSPF is a link-state routing protocol that is designed to be run
   inside a single Autonomous System.  OSPFv2 provided its own
   authentication mechanisms using the AuType and Authentication
   protocol header fields but OSPFv3 removed these fields and uses IPsec
   instead.  [RFC4552] describes how to use IPsec ESP and AH in order to
   protect OSPFv3 signaling between two routers.  It also enumerates the
   IPsec capabilities the routers require in order to support this
   specification.  Finally, it also describes the operation of OSPFv3

   with IPsec over virtual links where the other endpoint is not known
   at configuration time.  Since OSPFv3 exchanges multicast packets as
   well as unicast ones, the use of IKE within OSPFv3 is not
   appropriate.  Therefore, this document mandates the use of manual
   keys.

8.3.  Host Identity Protocol (HIP)

8.3.1.  RFC 5201, Host Identity Protocol (E, April 2008)

   IP addresses perform two distinct functions: host identifier and
   locator.  This document specifies a protocol that allows consenting
   hosts to securely establish and maintain shared IP-layer state,
   allowing separation of the identifier and locator roles of IP
   addresses.  This enables continuity of communications across IP
   address (locator) changes.  It uses public key identifiers from a new
   Host Identity (HI) namespace for peer authentication.  It uses the
   HMAC-SHA-1-96 and the AES-CBC algorithms with IPsec ESP and AH for
   protecting its signaling messages.

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

   The HIP base exchange specification [RFC5201] does not describe any
   transport formats or methods for describing how ESP is used to
   protect user data to be used during the actual communication.
   [RFC5202] specifies a set of HIP extensions for creating a pair of
   ESP Security Associations (SAs) between the hosts during the base
   exchange.  After the HIP association and required ESP SAs have been
   established between the hosts, the user data communication is
   protected using ESP.  In addition, this document specifies how the
   ESP Security Parameter Index (SPI) is used to indicate the right host
   context (host identity) and methods to update an existing ESP
   Security Association.

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

   When a host uses HIP, the overlying protocol sublayers (e.g.,
   transport layer sockets) and Encapsulating Security Payload (ESP)
   Security Associations (SAs) are bound to representations of these
   host identities, and the IP addresses are only used for packet
   forwarding.  [RFC5206] defines a generalized LOCATOR parameter for
   use in HIP messages that allows a HIP host to notify a peer about
   alternate addresses at which it is reachable.  It also specifies how
   a host can change its IP address and continue to send packets to its
   peers without necessarily rekeying.

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

   [RFC5207] discusses the problems associated with HIP communication
   across network paths that include network address translators and
   firewalls.  It analyzes the impact of NATs and firewalls on the HIP
   base exchange and the ESP data exchange.  It discusses possible
   changes to HIP that attempt to improve NAT and firewall traversal and
   proposes a rendezvous point for letting HIP nodes behind a NAT be
   reachable.  It also suggests mechanisms for NATs to be more aware of
   the HIP messages.

8.4.  Stream Control Transmission Protocol (SCTP)

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

   The Stream Control Transmission Protocol (SCTP) is a reliable
   transport protocol operating on top of a connection-less packet
   network such as IP.  [RFC3554] describes functional requirements for
   IPsec and IKE to be used in securing SCTP traffic.  It adds support
   for SCTP in the form of a new ID type in IKE [RFC2409] and
   implementation choices in the IPsec processing to account for the
   multiple source and destination addresses associated with a single
   SCTP association.  This document applies only to IKEv1 and IPsec-v2;
   it does not apply to IKEv2 AND IPsec-v3.

8.5.  Robust Header Compression (ROHC)

8.5.1.  RFC 3095, RObust Header Compression (ROHC): Framework and four
        profiles: RTP, UDP, ESP, and uncompressed (S, July 2001)

   ROHC is a framework for header compression, intended to be used in
   resource-constrained environments. [RFC3095] applies this framework
   to four protocols, including ESP.

8.5.2.  RFC 5225, RObust Header Compression Version 2 (ROHCv2): Profiles
        for RTP, UDP, IP, ESP, and UDP-Lite (S, April 2008)

   [RFC5225] defines an updated ESP/IP profile for use with ROHC version
   2.  It analyzes the ESP header and classifies the fields into several
   classes like static, well-known, irregular, etc., in order to
   efficiently compress the headers.

8.5.3.  RFC 5856, Integration of Robust Header Compression over IPsec
        Security Associations (I, May 2010)

   [RFC5856] describes a mechanism to compress inner IP headers at the
   ingress point of IPsec tunnels and to decompress them at the egress
   point.  Since the Robust Header Compression (ROHC) specifications
   only describe operations on a per-hop basis, this document also
   specifies extensions to enable ROHC over multiple hops.  This
   document applies only to tunnel mode SAs and does not support
   transport mode SAs.

8.5.4.  RFC 5857, IKEv2 Extensions to Support Robust Header Compression
        over IPsec (S, May 2010)

   ROHC requires initial configuration at the compressor and
   decompressor ends.  Since ROHC usually operates on a per-hop basis,
   this configuration information is carried over link-layer protocols
   such as PPP.  Since [RFC5856] operates over multiple hops, a
   different signaling mechanism is required.  [RFC5857] describes how
   to use IKEv2 in order to dynamically communicate the configuration
   parameters between the compressor and decompressor.

8.5.5.  RFC 5858, IPsec Extensions to Support Robust Header Compression
        over IPsec (S, May 2010)

   [RFC5856] describes how to use ROHC with IPsec.  This is not possible
   without extensions to IPsec.  [RFC5858] describes the extensions
   needed to IPsec in order to support ROHC.  Specifically, it describes
   extensions needed to the IPsec SPD, SAD, and IPsec processing
   including ICV computation and integrity verification.

8.6.  Border Gateway Protocol (BGP)

8.6.1.  RFC 5566, BGP IPsec Tunnel Encapsulation Attribute
        (S, June 2009)

   [RFC5566] adds an additional BGP Encapsulation Subsequent Address
   Family Identifier (SAFI), allowing the use of IPsec and, optionally,
   IKE to protect BGP tunnels.  It defines the use of AH and ESP in
   tunnel mode and the use of AH and ESP in transport mode to protect IP
   in IP and MPLS-in-IP tunnels.  It also defines how public key
   fingerprints (hashes) are distributed via BGP and used later to
   authenticate IKEv2 exchange between the tunnel endpoints.

8.7.  IPsec Benchmarking

   The Benchmarking Methodology WG in the IETF is working on documents
   that relate to benchmarking IPsec [BMWG-1] [BMWG-2].

8.7.1.  Methodology for Benchmarking IPsec Devices (Work in Progress)

   [BMWG-1] defines a set of tests that can be used to measure and
   report the performance characteristics of IPsec devices.  It extends
   the methodology defined for benchmarking network interconnecting
   devices to include IPsec gateways and adds further tests that can be
   used to measure IPsec performance of end-hosts.  The document focuses
   on establishing a performance testing methodology for IPsec devices
   that support manual keying and IKEv1, but does not cover IKEv2.

8.7.2.  Terminology for Benchmarking IPsec Devices (Work in Progress)

   [BMWG-2] defines the standardized performance testing terminology for
   IPsec devices that support manual keying and IKEv1.  It also
   describes the benchmark tests that would be used to test the
   performance of the IPsec devices.

8.8.  Network Address Translators (NAT)

8.8.1.  RFC 2709, Security Model with Tunnel-mode IPsec for NAT domains
        (I, October 1999)

   NAT devices provide transparent routing to end-hosts trying to
   communicate from disparate address realms, by modifying IP and
   transport headers en route.  This makes it difficult for applications
   to pursue end-to-end application-level security.  [RFC2709] describes
   a security model by which tunnel mode IPsec security can be
   architected on NAT devices.  It defines how NATs administer security
   policies and SA attributes based on private realm addressing.  It
   also specifies how to operate IKE in such scenarios by specifying an
   IKE-ALG (Application Level Gateway) that translates policies from
   private realm addressing into public addressing.  Although the model
   presented here uses terminology from IKEv1, it can be deployed within
   IKEv1, IKEv2, IPsec-v2, and IPsec-v3.  This security model has not
   been widely adopted

8.9.  Session Initiation Protocol (SIP)

8.9.1.  RFC 3329, Security Mechanism Agreement for the Session
        Initiation Protocol (SIP) (S, January 2003)

   [RFC3329] describes how a SIP client can select one of the various
   available SIP security mechanisms.  In particular, the method allows
   secure negotiation to prevent bidding down attacks.  It also
   describes a security mechanism called ipsec-3gpp and its associated
   parameters (algorithms, protocols, mode, SPIs and ports) as they are
   used in the 3GPP IP Multimedia Subsystem.

8.10.  Explicit Packet Sensitivity Labels

8.10.1.  RFC 5570, Common Architecture Label IPv6 Security Option
        (CALIPSO) (I, July 2009)

   [RFC5570] describes a mechanism used to encode explicit packet
   Sensitivity Labels on IPv6 packets in Multi-Level Secure (MLS)
   networks.  The method is implemented using an IPv6 hop-by-hop option.
   This document uses the IPsec Authentication Header (AH) in order to
   detect any malicious modification of the Sensitivity Label in a
   packet.