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