From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5374.txt | 2131 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2131 insertions(+) create mode 100644 doc/rfc/rfc5374.txt (limited to 'doc/rfc/rfc5374.txt') diff --git a/doc/rfc/rfc5374.txt b/doc/rfc/rfc5374.txt new file mode 100644 index 0000000..c93fc98 --- /dev/null +++ b/doc/rfc/rfc5374.txt @@ -0,0 +1,2131 @@ + + + + + + +Network Working Group B. Weis +Request for Comments: 5374 Cisco Systems +Category: Standards Track G. Gross + Secure Multicast Networks LLC + D. Ignjatic + Polycom + November 2008 + + + Multicast Extensions to the + Security Architecture for the Internet Protocol + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright 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. + +Abstract + + The Security Architecture for the Internet Protocol describes + security services for traffic at the IP layer. That architecture + primarily defines services for Internet Protocol (IP) unicast + packets. This document describes how the IPsec security services are + applied to IP multicast packets. These extensions are relevant only + for an IPsec implementation that supports multicast. + + + + + + + + + + + + +Weis, et al. Standards Track [Page 1] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Scope ......................................................3 + 1.2. Terminology ................................................4 + 2. Overview of IP Multicast Operation ..............................6 + 3. Security Association Modes ......................................7 + 3.1. Tunnel Mode with Address Preservation ......................7 + 4. Security Association ............................................8 + 4.1. Major IPsec Databases ......................................8 + 4.1.1. Group Security Policy Database (GSPD) ...............8 + 4.1.2. Security Association Database (SAD) ................12 + 4.1.3. Group Peer Authorization Database (GPAD) ...........12 + 4.2. Group Security Association (GSA) ..........................14 + 4.2.1. Concurrent IPsec SA Life Spans and Re-key Rollover .15 + 4.3. Data Origin Authentication ................................17 + 4.4. Group SA and Key Management ...............................18 + 4.4.1. Co-Existence of Multiple Key Management Protocols ..18 + 5. IP Traffic Processing ..........................................18 + 5.1. Outbound IP Traffic Processing ............................18 + 5.2. Inbound IP Traffic Processing .............................19 + 6. Security Considerations ........................................22 + 6.1. Security Issues Solved by IPsec Multicast Extensions ......22 + 6.2. Security Issues Not Solved by IPsec Multicast Extensions ..23 + 6.2.1. Outsider Attacks ...................................23 + 6.2.2. Insider Attacks ....................................23 + 6.3. Implementation or Deployment Issues that Impact Security ..24 + 6.3.1. Homogeneous Group Cryptographic Algorithm + Capabilities .......................................24 + 6.3.2. Groups that Span Two or More Security + Policy Domains .....................................24 + 6.3.3. Source-Specific Multicast Group Sender + Transient Locators .................................25 + 7. Acknowledgements ...............................................25 + 8. References .....................................................25 + 8.1. Normative References ......................................25 + 8.2. Informative References ....................................26 + Appendix A - Multicast Application Service Models .................28 + A.1 Unidirectional Multicast Applications ......................28 + A.2 Bi-directional Reliable Multicast Applications .............28 + A.3 Any-To-Any Multicast Applications ..........................30 + Appendix B - ASN.1 for a GSPD Entry ...............................30 + B.1 Fields Specific to a GSPD Entry ............................30 + B.2 SPDModule ..................................................31 + + + + + + + +Weis, et al. Standards Track [Page 2] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + +1. Introduction + + The Security Architecture for the Internet Protocol [RFC4301] + provides security services for traffic at the IP layer. It describes + an architecture for IPsec-compliant systems and a set of security + services for the IP layer. These security services primarily + describe services and semantics for IPsec Security Associations (SAs) + shared between two IPsec devices. Typically, this includes SAs with + traffic selectors that include a unicast address in the IP + destination field, and results in an IPsec packet with a unicast + address in the IP destination field. The security services defined + in RFC 4301 can also be used to tunnel IP multicast packets, where + the tunnel is a pairwise association between two IPsec devices. RFC + 4301 defined manually keyed transport mode IPsec SA support for IP + packets with a multicast address in the IP destination address field. + However, RFC 4301 did not define the interaction of an IPsec + subsystem with a Group Key Management protocol or the semantics of a + tunnel mode IPsec SA with an IP multicast address in the outer IP + header. + + This document describes OPTIONAL extensions to RFC 4301 that further + define the IPsec security architecture in order for groups of IPsec + devices to share SAs. In particular, it supports SAs with traffic + selectors that include a multicast address in the IP destination + field and that result in an IPsec packet with an IP multicast address + in the IP destination field. It also describes additional semantics + for IPsec Group Key Management (GKM) subsystems. Note that this + document uses the term "GKM protocol" generically and therefore does + not assume a particular GKM protocol. + + An IPsec implementation that does not support multicast is not + required to support these extensions. + + Throughout this document, RFC 4301 semantics remain unchanged by the + presence of these multicast extensions unless specifically noted to + the contrary. + +1.1. Scope + + The IPsec extensions described in this document support IPsec + Security Associations that result in IPsec packets with IPv4 or IPv6 + multicast group addresses as the destination address. Both + Any-Source Multicast (ASM) and Source-Specific Multicast (SSM) + [RFC3569] group addresses are supported. These extensions are used + when management policy requires that IP multicast packets protected + by IPsec remain IP multicast packets. When management policy + + + + + +Weis, et al. Standards Track [Page 3] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + + requires that the IP multicast packets be encapsulated as IP unicast + packets (e.g., because the network connected to the unprotected + interface does not support IP multicast), the extensions in this + document are not used. + + These extensions also support Security Associations with IPv4 + Broadcast addresses that result in an IPv4 link-level Broadcast + packet, and IPv6 Anycast addresses [RFC2526] that result in an IPv6 + Anycast packet. These destination address types share many of the + same characteristics of multicast addresses because there may be + multiple candidate receivers of a packet protected by IPsec. + + The IPsec architecture does not make requirements upon entities not + participating in IPsec (e.g., network devices between IPsec + endpoints). As such, these multicast extensions do not require + intermediate systems in a multicast-enabled network to participate in + IPsec. In particular, no requirements are placed on the use of + multicast routing protocols (e.g., Protocol Independent Multicast - + Sparse Mode (PIM-SM) [RFC4601]) or multicast admission protocols + (e.g., Internet Group Management Protocol (IGMP) [RFC3376]). + + All implementation models of IPsec (e.g., "bump-in-the-stack", + "bump-in-the-wire") are supported. + + This version of the multicast IPsec extension specification requires + that all IPsec devices participating in a Security Association be + homogeneous. They MUST share a common set of cryptographic transform + and protocol-handling capabilities. The semantics of an "IPsec + composite group" [COMPGRP], a heterogeneous IPsec cryptographic group + formed from the union of two or more sub-groups, is an area for + future standardization. + +1.2. Terminology + + 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 RFC 2119 [RFC2119]. + + The following key terms are used throughout this document. + + Any-Source Multicast (ASM) + The Internet Protocol (IP) multicast service model as defined in + RFC 1112 [RFC1112]. In this model, one or more senders source + packets to a single IP multicast address. When receivers join the + group, they receive all packets sent to that IP multicast address. + This is known as a (*,G) group. + + + + + +Weis, et al. Standards Track [Page 4] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + + Group + A set of devices that work together to protect group + communications. + + Group Controller Key Server (GCKS) + A Group Key Management (GKM) protocol server that manages IPsec + state for a group. A GCKS authenticates and provides the IPsec SA + policy and keying material to GKM Group Members. + + Group Key Management (GKM) Protocol + A key management protocol used by a GCKS to distribute IPsec + Security Association policy and keying material. A GKM protocol + is used when a group of IPsec devices require the same SAs. For + example, when an IPsec SA describes an IP multicast destination, + the sender and all receivers need to have the group SA. + + Group Key Management Subsystem + A subsystem in an IPsec device implementing a Group Key Management + protocol. The GKM subsystem provides IPsec SAs to the IPsec + subsystem on the IPsec device. Refer to RFC 3547 [RFC3547] and + RFC 4535 [RFC4535] for additional information. + + Group Member + An IPsec device that belongs to a group. A Group Member is + authorized to be a Group Sender and/or a Group Receiver. + + Group Owner + An administrative entity that chooses the policy for a group. + + Group Security Association (GSA) + A collection of IPsec Security Associations (SAs) and GKM + subsystem SAs necessary for a Group Member to receive key updates. + A GSA describes the working policy for a group. Refer to RFC 4046 + [RFC4046] for additional information. + + Group Security Policy Database (GSPD) + The GSPD is a multicast-capable security policy database, as + mentioned in RFC 3740 and Section 4.4.1.1. of RFC 4301. Its + semantics are a superset of the unicast Security Policy Database + (SPD) defined by Section 4.4.1 of RFC 4301. Unlike a unicast + SPD-S, in which point-to-point traffic selectors are inherently + bi-directional, multicast security traffic selectors in the GSPD-S + include a "sender only", "receiver only", or "symmetric" + directional attribute. Refer to Section 4.1.1 for more details. + + GSPD-S, GSPD-I, GSPD-O + Group Security Policy Database (secure traffic), (inbound), and + (outbound), respectively. See Section 4.4.1 of RFC 4301. + + + +Weis, et al. Standards Track [Page 5] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + + Group Receiver + A Group Member that is authorized to receive packets sent to a + group by a Group Sender. + + Group Sender + A Group Member that is authorized to send packets to a group. + + Source-Specific Multicast (SSM) + The Internet Protocol (IP) multicast service model as defined in + RFC 3569 [RFC3569]. In this model, each combination of a sender + and an IP multicast address is considered a group. This is known + as an (S,G) group. + + Tunnel Mode with Address Preservation + A type of IPsec tunnel mode used by security gateway + implementations when encapsulating IP multicast packets such that + they remain IP multicast packets. This mode is necessary for IP + multicast routing to correctly route IP multicast packets + protected by IPsec. + +2. Overview of IP Multicast Operation + + IP multicasting is a means of sending a single packet to a "host + group", a set of zero or more hosts identified by a single IP + destination address. IP multicast packets are delivered to all + members of the group either with "best-efforts" reliability [RFC1112] + or as part of a reliable stream (e.g., NACK-Oriented Reliable + Multicast (NORM) [RFC3940]). + + A sender to an IP multicast group sets the destination of the packet + to an IP address that has been allocated for IP multicast. Allocated + IP multicast addresses are defined in [RFC3171], [RFC3306], and + [RFC3307]. Potential receivers of the packet "join" the IP multicast + group by registering with a network routing device ([RFC3376], + [RFC3810]), signaling its intent to receive packets sent to a + particular IP multicast group. + + Network routing devices configured to pass IP multicast packets + participate in multicast routing protocols (e.g., PIM-SM) [RFC4601]. + Multicast routing protocols maintain state regarding which devices + have registered to receive packets for a particular IP multicast + group. When a router receives an IP multicast packet, it forwards a + copy of the packet out of each interface for which there are known + receivers. + + + + + + + +Weis, et al. Standards Track [Page 6] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + +3. Security Association Modes + + IPsec supports two modes of use: transport mode and tunnel mode. In + transport mode, IP Authentication Header (AH) [RFC4302] and IP + Encapsulating Security Payload (ESP) [RFC4303] provide protection + primarily for next layer protocols; in tunnel mode, AH and ESP are + applied to tunneled IP packets. + + A host implementation of IPsec using the multicast extensions MAY use + either transport mode or tunnel mode to encapsulate an IP multicast + packet. These processing rules are identical to the rules described + in Section 4.1 of [RFC4301]. However, the destination address for + the IPsec packet is an IP multicast address, rather than a unicast + host address. + + A security gateway implementation of IPsec MUST use a tunnel mode SA, + for the reasons described in Section 4.1 of [RFC4301]. In + particular, the security gateway needs to use tunnel mode to + encapsulate incoming fragments, since IPsec cannot directly operate + on fragments. + +3.1. Tunnel Mode with Address Preservation + + New (tunnel) header construction semantics are required when tunnel + mode is used to encapsulate IP multicast packets that are to remain + IP multicast packets. These semantics are due to the following + unique requirements of IP multicast routing protocols (e.g., PIM-SM + [RFC4601]). This document describes these new header construction + semantics as "tunnel mode with address preservation", which is + described as follows. + + - When an IP multicast packet is received by a host or router, the + destination address of the packet is compared to the local IP + multicast state. If the (outer) destination IP address of an IP + multicast packet is set to another IP address, the host or router + receiving the IP multicast packet will not process it properly. + Therefore, an IPsec security gateway needs to populate the + multicast IP destination address in the outer header using the + destination address from the inner header after IPsec tunnel + encapsulation. + + - IP multicast routing protocols typically create multicast + distribution trees based on the source address as well as the group + address. If an IPsec security gateway populates the (outer) source + address of an IP multicast packet (with its own IP address, as + called for in RFC 4301), the resulting IPsec-protected packet may + fail Reverse Path Forwarding (RPF) checks performed by other + routers. A failed RPF check may result in the packet being + + + +Weis, et al. Standards Track [Page 7] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + + dropped. To accommodate routing protocol RPF checks, the security + gateway implementing the IPsec multicast extensions SHOULD populate + the outer IP address from the original packet IP source address. + However, it should be noted that a security gateway performing + source address preservation will not receive ICMP Path MTU (PMTU) + or other messages intended for the security gateway (triggered by + packets that have had the outer IP source address set to that of + the inner header). Security gateway applications not requiring + source address preservation will be able to receive ICMP PMTU + messages and process them as described in Section 6.1 of RFC 4301. + + Because some applications of address preservation may require that + only the destination address be preserved, specification of + destination address preservation and source address preservation are + separated in the above description. Destination address preservation + and source address preservation attributes are described in the Group + Security Policy Database (GSPD) (defined later in this document), and + are copied into corresponding Security Association Database (SAD) + entries. + + Address preservation is applicable only for tunnel mode IPsec SAs + that specify the IP version of the encapsulating header to be the + same version as that of the inner header. When the IP versions are + different, IP multicast packets can be encapsulated using a tunnel + interface, for example as described in [RFC4891], where the tunnel is + also treated as an interface by IP multicast routing protocols. + + In summary, propagating both the IP source and destination addresses + of the inner IP header into the outer (tunnel) header allows IP + multicast routing protocols to route a packet properly when the + packet is protected by IPsec. This result is necessary in order for + the multicast extensions to allow a host or security gateway to + provide IPsec services for IP multicast packets. This method of RFC + 4301 tunnel mode is known as "tunnel mode with address preservation". + +4. Security Association + +4.1. Major IPsec Databases + + The following sections describe the GKM subsystem and IPsec extension + interactions with the IPsec databases. The major IPsec databases + need expanded semantics to fully support multicast. + +4.1.1. Group Security Policy Database (GSPD) + + The Group Security Policy Database is a security policy database + capable of supporting both unicast Security Associations as defined + by RFC 4301 and the multicast extensions defined by this + + + +Weis, et al. Standards Track [Page 8] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + + specification. The GSPD is considered to be the SPD, with the + addition of the semantics relating to the multicast extensions + described in this section. Appendix B provides an example of an + ASN.1 definition of a GSPD entry. + + This document describes a new "address preservation" (AP) flag + indicating that tunnel mode with address preservation is to be + applied to a GSPD entry. The AP flag has two attributes: AP-L, used + in the processing of the local tunnel address, and AP-R, used in the + processing of the remote tunnel process. This flag is added to the + GSPD "Processing info" field of the GSPD. The following text + reproduced from Section 4.4.1.2 of RFC 4301 is amended to include + this additional processing. (Note: for brevity, only the "Processing + info" text related to tunnel processing has been reproduced.) + + o Processing info -- which action is required -- PROTECT, + BYPASS, or DISCARD. There is just one action that goes with + all the selector sets, not a separate action for each set. + If the required processing is PROTECT, the entry contains the + following information. + - IPsec mode -- tunnel or transport + - (if tunnel mode) local tunnel address -- For a non-mobile + host, if there is just one interface, this is + straightforward; if there are multiple interfaces, this + must be statically configured. For a mobile host, the + specification of the local address is handled externally to + IPsec. If tunnel mode with address preservation is + specified for the local tunnel address, the AP-L attribute + is set to TRUE for the local tunnel address and the local + tunnel address is unspecified. The presence of the AP-L + attribute indicates that the inner IP header source address + will be copied to the outer IP header source address during + IP header construction for tunnel mode. + - (if tunnel mode) remote tunnel address -- There is no + standard way to determine this. See Section 4.5.3 of RFC + 4301, "Locating a Security Gateway". If tunnel mode with + address preservation is specified for the remote tunnel + address, the AP-R attribute is set to TRUE for the remote + tunnel address and the remote tunnel address is + unspecified. The presence of the AP-R attribute indicates + that the inner IP header destination address will be copied + to the outer IP header destination address during IP header + construction for tunnel mode. + + This document describes unique directionality processing for GSPD + entries with a remote IP multicast address. Since an IP multicast + address must not be sent as the source address of an IP packet + + + + +Weis, et al. Standards Track [Page 9] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + + [RFC1112], directionality of Local and Remote addresses and ports is + maintained during incoming SPD-S and SPD-I checks rather than being + swapped. Section 4.4.1 of RFC 4301 is amended as follows: + + Representing Directionality in an SPD Entry + + For traffic protected by IPsec, the Local and Remote address + and ports in an SPD entry are swapped to represent + directionality, consistent with IKE conventions. In general, + the protocols that IPsec deals with have the property of + requiring symmetric SAs with flipped Local/Remote IP + addresses. However, SPD entries with a remote IP multicast + address do not have their Local and Remote addresses and + ports in an SPD entry swapped during incoming SPD-S and SPD-I + checks. + + A new Group Security Policy Database (GSPD) attribute is introduced: + GSPD entry directionality. The following text is added to the bullet + list of SPD fields described in Section 4.4.1.2 of RFC 4301. + + o Directionality -- can be one of three types: "symmetric", + "sender only", or "receiver only". "Symmetric" indicates + that a pair of SAs are to be created (one in each direction, + as specified by RFC 4301). GSPD entries marked as "sender + only" indicate that one SA is to be created in the outbound + direction. GSPD entries marked as "receiver only" indicate + that one SA is to be created in the inbound direction. GSPD + entries marked as "sender only" or "receiver only" SHOULD + support multicast IP addresses in their destination address + selectors. If the processing requested is BYPASS or DISCARD + and a "sender only" type is configured, the entry MUST be put + in GSPD-O only. Reciprocally, if the type is "receiver + only", the entry MUST go to GSPD-I only. + + GSPD entries created by a GCKS may be assigned identical Security + Parameter Indexes (SPIs) to SAD entries created by IKEv2 [RFC4306]. + This is not a problem for the inbound traffic as the appropriate SAs + can be matched using the algorithm described in Section 4.1 of RFC + 4301. However, the outbound traffic needs to be matched against the + GSPD selectors so that the appropriate SA can be created. + + To facilitate dynamic group keying, the outbound GSPD MUST implement + a policy action capability that triggers a GKM protocol registration + exchange (as per Section 5.1 of [RFC4301]). For example, the Group + Sender GSPD policy might trigger on a match with a specified + multicast application packet that is entering the implementation via + the protected interface or that is emitted by the implementation on + the protected side of the boundary and directed toward the + + + +Weis, et al. Standards Track [Page 10] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + + unprotected interface. The ensuing Group Sender registration + exchange would set up the Group Sender's outbound SAD entry that + encrypts the multicast application's data stream. In the inverse + direction, group policy may also set up an inbound IPsec SA. + + At the Group Receiver endpoint(s), the IPsec subsystem MAY use GSPD + policy mechanisms that initiate a GKM protocol registration exchange. + One such policy mechanism might be on the detection of a device in + the protected network joining a multicast group matching GSPD policy + (e.g., by receiving a IGMP/MLD (Multicast Listener Discovery) join + group message on a protected interface). The ensuing Group Receiver + registration exchange would set up the Group Receiver's inbound SAD + entry that decrypts the multicast application's data stream. In the + inverse direction, the group policy may also set up an outbound IPsec + SA (e.g., when supporting an ASM service model). + + Note: A security gateway triggering on the receipt of unauthenticated + messages arriving on a protected interface may result in early Group + Receiver registration if the message is not the result of a device on + the protected network actually wishing to join a multicast group. + The unauthenticated messages will only cause the Group Receiver to + register once; subsequent messages will have no effect on the Group + Receiver. + + The IPsec subsystem MAY provide GSPD policy mechanisms that + automatically initiate a GKM protocol de-registration exchange. + De-registration allows a GCKS to minimize exposure of the group's + secret key by re-keying a group on a group membership change event. + It also minimizes cost on a GCKS for those groups that maintain + member state. One such policy mechanism could be the detection of + IGMP/MLD leave group exchange. However, a security gateway Group + Member would not initiate a GKM protocol de-registration exchange + until it detects that there are no more receivers behind a protected + interface. + + Additionally, the GKM subsystem MAY set up the GSPD/SAD state + information independent of the multicast application's state. In + this scenario, the Group Owner issues management directives that tell + the GKM subsystem when it should start GKM registration and + de-registration protocol exchanges. Typically, the registration + policy strives to make sure that the group's IPsec subsystem state is + "always ready" in anticipation of the multicast application starting + its execution. + + + + + + + + +Weis, et al. Standards Track [Page 11] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + +4.1.2. Security Association Database (SAD) + + The SAD contains an item describing whether tunnel or transport mode + is applied to traffic on this SA. The text in RFC 4301 Section + 4.4.2.1 is amended to describe address preservation. + + o IPsec protocol mode: tunnel or transport. Indicates which + mode of AH or ESP is applied to traffic on this SA. When + tunnel mode is specified, the data item also indicates + whether or not address preservation is applied to the outer + IP header. Address preservation MUST NOT be specified when + the IP version of the encapsulating header and IP version of + the inner header do not match. The local address, remote + address, or both addresses MAY be marked as being preserved + during tunnel encapsulation. + +4.1.3. Group Peer Authorization Database (GPAD) + + The multicast IPsec extensions introduce a new data structure called + the Group Peer Authorization Database (GPAD). The GPAD is analogous + to the PAD defined in RFC 4301. It provides a link between the GSPD + and a Group Key Management (GKM) Subsystem. The GPAD embodies the + following critical functions: + + o identifies a GCKS (or group of GCKS devices) that is + authorized to communicate with this IPsec entity + + o specifies the protocol and method used to authenticate each + GCKS + + o provides the authentication data for each GKCS + + o constrains the traffic selectors that can be asserted by a + GCKS with regard to SA creation + + o constrains the types and values of Group Identifiers for + which a GCKS is authorized to provide group policy + + The GPAD provides these functions for a Group Key Management + subsystem. The GPAD is not consulted by IKE or other authentication + protocols that do not act as GKM protocols. + + To provide these functions, the GPAD contains an entry for each GCKS + that the IPsec entity is configured to contact. An entry contains + one or more GCKS Identifiers, the authentication protocol (e.g., + Group Domain of Interpretation (GDOI) or Group Secure Association Key + Management Protocol (GSAKMP)), the authentication method used (e.g., + certificates or pre-shared secrets), and the authentication data + + + +Weis, et al. Standards Track [Page 12] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + + (e.g., the pre-shared secret or trust anchor relative to which the + peer's certificate will be validated). For certificate-based + authentication, the entry also may provide information to assist in + verifying the revocation status of the peer, e.g., a pointer to a + Certificate Revocation List (CRL) repository or the name of an Online + Certificate Status Protocol (OCSP) server associated with either the + peer or the trust anchor associated with the peer. The entry also + contains constraints a Group Member applies to the policy received + from the GKCS. + +4.1.3.1. GCKS Identifiers + + GCKS Identifiers are used to identify one or more devices that are + authorized to act as a GCKS for this group. GCKS Identifiers are + specified as PAD entry IDs in Section 4.4.3.1 of RFC 4301 and follow + the matching rules described therein. + +4.1.3.2. GCKS Peer Authentication Data + + Once a GPAD entry is located, it is necessary to verify the asserted + identity, i.e., to authenticate the asserted GCKS Identifier. PAD + authentication data types and semantics specified in Section 4.4.3.2 + of RFC 4301 are used to authenticate a GCKS. + + See GDOI [RFC3547] and GSAKMP [RFC4535] for details of how a GKM + protocol performs peer authentication using certificates and + pre-shared secrets. + +4.1.3.3. Group Identifier Authorization Data + + A Group Identifier is used by a GKM protocol to identify a particular + group to a GCKS. A GPAD entry includes a Group Identifier to + indicate that the GKCS Identifiers in the GPAD entry are authorized + to act as a GCKS for the group. + + The Group Identifier is an opaque byte string of IKE ID type Key ID + that identifies a secure multicast group. The Group Identifier byte + string MUST be at least four bytes long and less than 256 bytes long. + + IKE ID types other than Key ID MAY be supported. + +4.1.3.4. IPsec SA Traffic Selector Authorization Data + + Once a GCKS is authenticated, the GCKS delivers IPsec SA policy to + the Group Member. Before the Group Member accepts the IPsec SA + Policy, the source and destination traffic selectors of the SA are + compared to a set of authorized data flows. Each data flow includes + a set of authorized source traffic selectors and a set of authorized + + + +Weis, et al. Standards Track [Page 13] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + + destination traffic selectors. Traffic selectors are represented as + a set of IPv4 and/or IPv6 address ranges. (A peer may be authorized + for both address types, so there MUST be provision for both v4 and v6 + address ranges.) + +4.1.3.5. How the GPAD Is Used + + When a GKM protocol registration exchange is triggered, the Group + Member and GCKS each assert their identity as a part of the exchange. + Each GKM protocol registration exchange MUST use the asserted ID to + locate an identity in the GPAD. The GPAD entry specifies the + authentication method to be employed for the identified GCKS. The + entry also specifies the authentication data that will be used to + verify the asserted identity. This data is employed in conjunction + with the specified method to authenticate the GCKS before accepting + any group policy from the GCKS. + + During the GKM protocol registration, a Group Member includes a Group + Identifier. Before presenting that Group Identifier to the GCKS, a + Group Member verifies that the GPAD entry for authenticated GCKS GPAD + entry includes the Group Identifier. This ensures that the GCKS is + authorized to provide policy for the Group. + + When IPsec SA policy is received, each data flow is compared to the + data flows in the GPAD entry. The Group Member accepts policy + matching a data flow. Policy not matching a data flow is discarded, + and the reason SHOULD be recorded in the audit log. + + A GKM protocol may distribute IPsec SA policy to IPsec devices that + have previously registered with it. The method of distribution is + part of the GKM protocol and is outside the scope of this memo. When + the IPsec device receives this new policy, it compares the policy to + the data flows in the GPAD entry as described above. + +4.2. Group Security Association (GSA) + + An IPsec implementation supporting these extensions will support a + number of Security Associations: one or more IPsec SAs plus one or + more GKM SAs used to download the parameters that are used to create + IPsec SAs. These SAs are collectively referred to as a Group + Security Association (GSA) [RFC3740]. + +4.2.1. Concurrent IPsec SA Life Spans and Re-key Rollover + + During a secure multicast group's lifetime, multiple IPsec Group + Security Associations can exist concurrently. This occurs + principally due to two reasons: + + + + +Weis, et al. Standards Track [Page 14] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + + - There are multiple Group Senders authorized in the group, each with + its own IPsec SA, which maintains anti-replay state. A group that + does not rely on IP security anti-replay services can share one + IPsec SA for all of its Group Senders. + + - The life spans of a Group Sender's two (or more) IPsec SAs are + allowed to overlap in time so that there is continuity in the + multicast data stream across group re-key events. This capability + is referred to as "re-key rollover continuity". + + The re-key continuity rollover algorithm depends on an IPsec SA + management interface between the GKM subsystem and the IPsec + subsystem. The IPsec subsystem MUST provide management interface + mechanisms for the GKM subsystem to add IPsec SAs and to delete IPsec + SAs. For illustrative purposes, this text defines the re-key + rollover continuity algorithm in terms of two timer parameters that + govern IPsec SA life spans relative to the start of a group re-key + event. However, it should be emphasized that the GKM subsystem + interprets the group's security policy to direct the correct timing + of IPsec SA activation and deactivation. A given group policy may + choose timer values that differ from those recommended by this text. + The two re-key rollover continuity timer parameters are: + + 1. Activation Time Delay (ATD) - The ATD defines how long after the + start of a re-key event to activate new IPsec SAs. The ATD + parameter is expressed in units of seconds. Typically, the ATD + parameter is set to the maximum time it takes to deliver a + multicast message from the GCKS to all of the group's members. + For a GCKS that relies on a Reliable Multicast Transport Protocol + (RMTP), the ATD parameter could be set equal to the RTMP's maximum + error recovery time. When an RMTP is not present, the ATD + parameter might be set equal to the network's maximum multicast + message delivery latency across all of the group's endpoints. The + ATD is a GKM group policy parameter. This value SHOULD be + configurable at the Group Owner management interface on a per + group basis. + + 2. Deactivation Time Delay (DTD) - The DTD defines how long after the + start of a re-key event to deactivate those IPsec SAs that are + destroyed by the re-key event. The purpose of the DTD parameter + is to minimize the residual exposure of a group's keying material + after a re-key event has retired that keying material. The DTD is + independent of, and should not to be confused with, the IPsec SA + soft lifetime attribute. The DTD parameter is expressed in units + of seconds. Typically, the DTD parameter would be set to the ADT + plus the maximum time it takes to deliver a multicast message from + the Group Sender to all of the group's members. For a Group + Sender that relies on an RMTP, the DTD parameter could be set + + + +Weis, et al. Standards Track [Page 15] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + + equal to ADT plus the RMTP's maximum error recovery time. When an + RMTP is not present, the DTD parameter might be set equal to ADT + plus the network's maximum multicast message delivery latency + across all of the group's endpoints. A GKM subsystem MAY + implement the DTD as a group security policy parameter. If a GKM + subsystem does not implement the DTD parameter, then other group + security policy mechanisms MUST determine when to deactivate an + IPsec SA. + + Each group re-key multicast message sent by a GCKS signals the start + of a new Group Sender IPsec SA time epoch, with each such epoch + having an associated set of two IPsec SAs. Note that this document + refers to re-key mechanisms as being multicast because of the + inherent scalability of IP multicast distribution. However, there is + no particular reason that re-keying mechanisms must be multicast. + For example, [ZLLY03] describes a method of re-key employing both + unicast and multicast messages. + + The group membership interacts with these IPsec SAs as follows: + + - As a precursor to the Group Sender beginning its re-key rollover + continuity processing, the GCKS periodically multicasts a Re-Key + Event (RKE) message to the group. The RKE multicast MAY contain + group policy directives, new IPsec SA policy, and group keying + material. In the absence of an RMTP, the GCKS may re-transmit the + RKE a policy-defined number of times to improve the availability of + re-key information. The GKM subsystem starts the ATD and DTD + timers after it receives the last RKE re-transmission. + + - The GKM subsystem interprets the RKE multicast to configure the + group's GSPD/SAD with the new IPsec SAs. Each IPsec SA that + replaces an existing SA is called a "leading edge" IPsec SA. The + leading edge IPsec SA has a new Security Parameter Index (SPI) and + its associated keying material, which keys it. For a time period + of ATD seconds after the GCKS multicasts the RKE, a Group Sender + does not yet transmit data using the leading edge IPsec SA. + Meanwhile, other Group Members prepare to use this IPsec SA by + installing the leading edge IPsec SAs to their respective GSPD/SAD. + + - After waiting for the ATD period, such that all of the Group + Members have received and processed the RKE message, the GKM + subsystem directs the Group Sender to begin to transmit using the + leading edge IPsec SA with its data encrypted by the new keying + material. Only authorized Group Members can decrypt these IPsec SA + multicast transmissions. + + + + + + +Weis, et al. Standards Track [Page 16] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + + - The Group Sender's "trailing edge" SA is the oldest Security + Association in use by the group for that sender. All authorized + Group Members can receive and decrypt data for this SA, but the + Group Sender does not transmit new data using the trailing edge + IPsec SA after it has transitioned to the leading edge IPsec SA. + The trailing edge IPsec SA is deleted by the group's GKM subsystems + after the DTD time period has elapsed since the RKE transmission. + + This re-key rollover strategy allows the group to drain its + in-transit datagrams from the network while transitioning to the + leading edge IPsec SA. Staggering the roles of each respective IPsec + SA as described above improves the group's synchronization even when + there are high network propagation delays. Note that due to group + membership joins and leaves, each Group Sender IPsec SA time epoch + may have a different group membership set. + + It is a group policy decision whether the re-key event transition + between epochs provides forward and backward secrecy. The group's + re-key protocol keying material and algorithm (e.g., Logical Key + Hierarchy; refer to [RFC2627] and Appendix A of [RFC4535]) enforces + this policy. Implementations MAY offer a Group Owner management + interface option to enable/disable re-key rollover continuity for a + particular group. This specification requires that a GKM/IPsec + implementation MUST support at least two concurrent IPsec SAs per + Group Sender as well as this re-key rollover continuity algorithm. + +4.3. Data Origin Authentication + + As defined in [RFC4301], data origin authentication is a security + service that verifies the identity of the claimed source of data. A + Message Authentication Code (MAC) is often used to achieve data + origin authentication for connections shared between two parties. + However, typical MAC authentication methods using a single shared + secret are not sufficient to provide data origin authentication for + groups with more than two parties. With a MAC algorithm, every Group + Member can use the MAC key to create a valid MAC tag, whether or not + they are the authentic originator of the group application's data. + + When the property of data origin authentication is required for an + IPsec SA shared by more than two parties, an authentication transform + where the receiver is assured that the sender generated that message + should be used. Two possible algorithms are Timed Efficient Stream + Loss-Tolerant Authentication (TESLA) [RFC4082] or RSA digital + signature [RFC4359]. + + In some cases (e.g., digital signature authentication transforms), + the processing cost of the algorithm is significantly greater than a + Hashed Message Authentication Code (HMAC) authentication method. To + + + +Weis, et al. Standards Track [Page 17] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + + protect against denial-of-service attacks from a device that is not + authorized to join the group, the IPsec SA using this algorithm may + be encapsulated with an IPsec SA using a MAC authentication + algorithm. However, doing so requires the packet to be sent across + the IPsec boundary a second time for additional outbound processing + on the Group Sender (see Section 5.1 of [RFC4301]) and a second time + for inbound processing on Group Receivers (see Section 5.2 of + [RFC4301]). This use of AH or ESP encapsulated within AH or ESP + accommodates the constraint that AH and ESP define an Integrity Check + Value (ICV) for only a single authenticator transform. + +4.4. Group SA and Key Management + +4.4.1. Co-Existence of Multiple Key Management Protocols + + Often, the GKM subsystem will be introduced to an existent IPsec + subsystem as a companion key management protocol to IKEv2 [RFC4306]. + A fundamental GKM protocol IP security subsystem requirement is that + both the GKM protocol and IKEv2 can simultaneously share access to a + common Group Security Policy Database and Security Association + Database. The mechanisms that provide mutually exclusive access to + the common GSPD/SAD data structures are a local matter. This + includes the GSPD-O cache and the GSPD-I cache. However, + implementers should note that IKEv2 SPI allocation is entirely + independent from GKM SPI allocation because Group Security + Associations are qualified by a destination multicast IP address and + may optionally have a source IP address qualifier. See Section 2.1 + of [RFC4303] for further explanation. + + The Peer Authorization Database does require explicit coordination + between the GKM protocol and IKEv2. Section 4.1.3 describes these + interactions. + +5. IP Traffic Processing + + Processing of traffic follows Section 5 of [RFC4301], with the + additions described below when these IP multicast extensions are + supported. + +5.1. Outbound IP Traffic Processing + + If an IPsec SA is marked as supporting tunnel mode with address + preservation (as described in Section 3.1), either or both of the + outer header source or destination addresses are marked as being + preserved. + + Header construction for tunnel mode is described in Section 5.1.2 of + RFC 4301. The first bullet of that section is amended as follows: + + + +Weis, et al. Standards Track [Page 18] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + + o If address preservation is not marked in the SAD entry for + either the outer IP header Source Address or Destination + Address, the outer IP header Source Address and Destination + Address identify the "endpoints" of the tunnel (the + encapsulator and decapsulator). If address preservation is + marked for the IP header Source Address, it is copied from + the inner IP header Source Address. If address preservation + is marked for the IP header Destination Address, it is copied + from the inner IP header Destination Address. The inner IP + header Source Address and Destination Addresses identify the + original sender and recipient of the datagram (from the + perspective of this tunnel), respectively. Address + preservation MUST NOT be marked when the IP version of the + encapsulating header and IP version of the inner header do + not match. + + Note (3), regarding construction of tunnel addresses in Section + 5.1.2.1 of RFC 4301, is amended as follows. (Note: for brevity, Note + (3) of RFC 4301 is not reproduced in its entirety.) + + (3) Unless marked for address preservation, Local and Remote + addresses depend on the SA, which is used to determine the + Remote address, which in turn determines which Local + address (net interface) is used to forward the packet. If + address preservation is marked for the Local address, it is + copied from the inner IP header. If address preservation + is marked for the Remote address, that address is copied + from the inner IP header. + +5.2. Inbound IP Traffic Processing + + IPsec-protected packets generated by an IPsec device supporting these + multicast extensions may (depending on its GSPD policy) populate an + outer tunnel header with a destination address such that it is not + addressed to an IPsec device. This requires an IPsec device + supporting these multicast extensions to accept and process IP + traffic that is not addressed to the IPsec device itself. The + following additions to IPsec inbound IP traffic processing are + necessary. + + For compatibility with RFC 4301, the phrase "addressed to this + device" is taken to mean packets with a unicast destination address + belonging to the system itself, and also multicast packets that are + received by the system itself. However, multicast packets not + received by the IPsec device are not considered addressed to this + device. + + + + + +Weis, et al. Standards Track [Page 19] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + + The discussion of processing inbound IP Traffic described in Section + 5.2 of RFC 4301 is amended as follows. + + The first dash in item 2 is amended as follows: + + - If the packet appears to be IPsec protected and it is + addressed to this device, or appears to be IPsec protected + and is addressed to a multicast group, an attempt is made to + map it to an active SA via the SAD. Note that the device may + have multiple IP addresses that may be used in the SAD + lookup, e.g., in the case of protocols such as SCTP. + + A new item is added to the list between items 3a and 3b to describe + processing of IPsec packets with destination address preservation + applied: + + 3aa. If the packet is addressed to a multicast group and AH or + ESP is specified as the protocol, the packet is looked up + in the SAD. Use the SPI plus the destination or SPI plus + destination and source addresses, as specified in Section + 4.1. If there is no match, the packet is directed to + SPD-I lookup. Note that if the IPsec device is a security + gateway, and the SPD-I policy is to BYPASS the packet, a + subsequent security gateway along the routed path of the + multicast packet may decrypt the packet. + + Figure 3 in RFC 4301 is updated to show the new processing path + defined in item 3aa. + + + + + + + + + + + + + + + + + + + + + + + +Weis, et al. Standards Track [Page 20] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + + Unprotected Interface + | + V + +-----+ IPsec protected + ------------------->|Demux|--------------------+ + | +-----+ | + | | | + | Not IPsec | | + | | IPsec protected, not | + | V addressed to device, | + | +-------+ +---------+ and not in SAD | + | |DISCARD|<---|SPD-I (*)|<------------+ | + | +-------+ +---------+ | | + | | | | + | |-----+ | | + | | | | | + | | V | | + | | +------+ | | + | | | ICMP | | | + | | +------+ | | + | | | V + +---------+ | +-----------+ + ....|SPD-O (*)|............|...................|PROCESS(**)|...IPsec + +---------+ | | (AH/ESP) | Boundary + ^ | +-----------+ + | | +---+ | + | BYPASS | +-->|IKE| | + | | | +---+ | + | V | V + | +----------+ +---------+ +----+ + |--------<------|Forwarding|<---------|SAD Check|-->|ICMP| + nested SAs +----------+ | (***) | +----+ + | +---------+ + V + Protected Interface + + Figure 1. Processing Model for Inbound Traffic + (amending Figure 3 of RFC 4301) + + + + + + + + + + + + + +Weis, et al. Standards Track [Page 21] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + + The discussion of processing inbound IP traffic in Section 5.2 of RFC + 4301 is amended to insert a new item 6 as follows. + + 6. If an IPsec SA is marked as supporting tunnel mode with + address preservation (as described in Section 3.1), the + marked address(es) (i.e., source and/or destination + address(es)) in the outer IP header MUST be verified to be + the same value(s) as in the inner IP header. If the + addresses are not consistent, the IPsec system MUST discard + the packet and treat the inconsistency as an auditable + event. + +6. Security Considerations + + The IP security multicast extensions defined by this specification + build on the unicast-oriented IP security architecture [RFC4301]. + Consequently, this specification inherits many of RFC 4301's security + considerations, and the reader is advised to review it as companion + guidance. + +6.1. Security Issues Solved by IPsec Multicast Extensions + + The IP security multicast extension service provides the following + network layer mechanisms for secure group communications: + + - Confidentiality using a group shared encryption key. + + - Group source authentication and integrity protection using a group + shared authentication key. + + - Group Sender data origin authentication using a digital signature, + TESLA, or other mechanism. + + - Anti-replay protection for a limited number of Group Senders using + the ESP (or AH) sequence number facility. + + - Filtering of multicast transmissions identified with a source + address of systems that are not authorized by group policy to be + Group Senders. This feature leverages the IPsec stateless firewall + service (i.e., SPD-I and/or SDP-O entries with a packet disposition + specified as DISCARD). + + In support of the above services, this specification enhances the + definition of the SPD, PAD, and SAD databases to facilitate the + automated group key management of large-scale cryptographic groups. + + + + + + +Weis, et al. Standards Track [Page 22] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + +6.2. Security Issues Not Solved by IPsec Multicast Extensions + + As noted in Section 2.2. of RFC 4301, it is out of the scope of this + architecture to defend the group's keys or its application data + against attacks targeting vulnerabilities of the operating + environment in which the IPsec implementation executes. However, it + should be noted that the risk of attacks originating by an adversary + in the network is magnified to the extent that the group keys are + shared across a large number of systems. + + The security issues that are left unsolved by the IPsec multicast + extension service divide into two broad categories: outsider attacks + and insider attacks. + +6.2.1. Outsider Attacks + + The IPsec multicast extension service does not defend against an + adversary outside of the group who has: + + - the capability to launch a multicast, flooding denial-of-service + attack against the group, originating from a system whose IPsec + subsystem does not filter the unauthorized multicast transmissions. + + - compromised a multicast router, allowing the adversary to corrupt + or delete all multicast packets destined for the group endpoints + downstream from that router. + + - captured a copy of an earlier multicast packet transmission and + then replayed it to a group that does not have the anti-replay + service enabled. Note that for a large-scale, any-source multicast + group, it is impractical for the Group Receivers to maintain an + anti-replay state for every potential Group Sender. Group policies + that require anti-replay protection for a large-scale, any-source + multicast group should consider an application layer multicast + protocol that can detect and reject replays. + +6.2.2. Insider Attacks + + For large-scale groups, the IP security multicast extensions are + dependent on an automated Group Key Management protocol to correctly + authenticate and authorize trustworthy members in compliance to the + group's policies. Inherent in the concept of a cryptographic group + is a set of one or more shared secrets entrusted to all of the Group + Members. Consequently, the service's security guarantees are no + stronger than the weakest member admitted to the group by the GKM + system. The GKM system is responsible for responding to compromised + Group Member detection by executing a re-key procedure. The GKM + re-keying protocol will expel the compromised Group Members and + + + +Weis, et al. Standards Track [Page 23] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + + distribute new group keying material to the trusted members. + Alternatively, the group policy may require the GKM system to + terminate the group. + + In the event that an adversary has been admitted into the group by + the GKM system, the following attacks are possible and can not be + solved by the IPsec multicast extension service: + + - The adversary can disclose the secret group key or group data to an + unauthorized party outside of the group. After a group key or data + compromise, cryptographic methods such as traitor tracing or + watermarking can assist in the forensics process. However, these + methods are outside the scope of this specification. + + - The insider adversary can forge packet transmissions that appear to + be from a peer Group Member. To defend against this attack, for + those Group Sender transmissions that merit the overhead, the group + policy can require the Group Sender to multicast packets using the + data origin authentication service. + + - If the group's data origin authentication service uses digital + signatures, then the insider adversary can launch a computational + resource denial-of-service attack by multicasting bogus signed + packets. + +6.3. Implementation or Deployment Issues that Impact Security + +6.3.1. Homogeneous Group Cryptographic Algorithm Capabilities + + The IP security multicast extensions service can not defend against a + poorly considered group security policy that allows a weaker + cryptographic algorithm simply because all of the group's endpoints + are known to support it. Unfortunately, large-scale groups can be + difficult to upgrade to the current best-in-class cryptographic + algorithms. One possible approach to solving many of these problems + is the deployment of composite groups that can straddle heterogeneous + groups [COMPGRP]. A standard solution for heterogeneous groups is an + activity for future standardization. In the interim, synchronization + of a group's cryptographic capabilities could be achieved using a + secure and scalable software distribution management tool. + +6.3.2. Groups that Span Two or More Security Policy Domains + + Large-scale groups may span multiple legal jurisdictions (e.g., + countries) that enforce limits on cryptographic algorithms or key + strengths. As currently defined, the IPsec multicast extension + service requires a single group policy per group. As noted above, + this problem remains an area for future standardization. + + + +Weis, et al. Standards Track [Page 24] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + +6.3.3. Source-Specific Multicast Group Sender Transient Locators + + A Source Specific Multicast (SSM) Group Sender's source IP address + can dynamically change during a secure multicast group's lifetime. + Examples of the events that can cause the Group Sender's source + address to change include but are not limited to NAT, a mobility- + induced change in the care-of-address, and a multi-homed host using a + new IP interface. The change in the Group Sender's source IP address + will cause GSPD entries related to that multicast group to become out + of date with respect to the group's multicast routing state. In the + worst case, there is a risk that the Group Sender's data originating + from a new source address will be BYPASS processed by a security + gateway. If this scenario was not anticipated, then it could leak + the group's data. Consequently, it is recommended that SSM secure + multicast groups have a default DISCARD policy for all unauthorized + Group Sender source IP addresses for the SSM group's destination IP + address. + +7. Acknowledgements + + The authors wish to thank Steven Kent, Russ Housley, Pasi Eronen, and + Tero Kivinen for their helpful comments. + + The "Guidelines for Writing RFC Text on Security Considerations" + [RFC3552] was consulted to develop the Security Considerations + section of this memo. + +8. References + +8.1. Normative References + + [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, + RFC 1112, August 1989. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [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. + + + + + + +Weis, et al. Standards Track [Page 25] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + +8.2. Informative References + + [COMPGRP] Gross G. and H. Cruickshank, "Multicast IP Security + Composite Cryptographic Groups", Work in Progress, February + 2007. + + [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast + Addresses", RFC 2526, March 1999. + + [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for + Multicast: Issues and Architectures", RFC 2627, June 1999. + + [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC + 2914, September 2000. + + [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, + "IANA Guidelines for IPv4 Multicast Address Assignments", + BCP 51, RFC 3171, August 2001. + + [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 + Multicast Addresses", RFC 3306, August 2002. + + [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast + Addresses", RFC 3307, August 2002. + + [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. + Thyagarajan, "Internet Group Management Protocol, Version + 3", RFC 3376, October 2002. + + [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The + Group Domain of Interpretation", RFC 3547, July 2003. + + [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC + Text on Security Considerations", BCP 72, RFC 3552, July + 2003. + + [RFC3569] Bhattacharyya, S., Ed., "An Overview of Source-Specific + Multicast (SSM)", RFC 3569, July 2003. + + [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security + Architecture", RFC 3740, March 2004. + + [RFC3810] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener + Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. + + [RFC3940] Adamson, B., Bormann, C., Handley, M., and J. Macker, + "Negative-acknowledgment (NACK)-Oriented Reliable Multicast + (NORM) Protocol", RFC 3940, November 2004. + + + +Weis, et al. Standards Track [Page 26] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + + [RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, + "Multicast Security (MSEC) Group Key Management + Architecture", RFC 4046, April 2005. + + [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. + Briscoe, "Timed Efficient Stream Loss-Tolerant + Authentication (TESLA): Multicast Source Authentication + Transform Introduction", RFC 4082, June 2005. + + [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", + RFC 4306, 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. + + [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: + Group Secure Association Key Management Protocol", RFC + 4535, June 2006. + + [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, + "Protocol Independent Multicast - Sparse Mode (PIM-SM): + Protocol Specification (Revised)", RFC 4601, August 2006. + + [RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. + Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", + RFC 4891, May 2007. + + [ZLLY03] Zhang, X., et al., "Protocol Design for Scalable and + Reliable Group Rekeying", IEEE/ACM Transactions on + Networking (TON), Volume 11, Issue 6, December 2003. + + + + + + + + + + + + + + + + + + + + +Weis, et al. Standards Track [Page 27] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + +Appendix A. Multicast Application Service Models + + The vast majority of secure multicast applications can be catalogued + by their service model and accompanying intra-group communication + patterns. Both the Group Key Management (GKM) subsystem and the + IPsec subsystem MUST be able to configure the GSPD/SAD security + policies to match these dominant usage scenarios. The GSPD/SAD + policies MUST include the ability to configure both Any-Source + Multicast groups and Source-Specific Multicast groups for each of + these service models. The GKM subsystem management interface MAY + include mechanisms to configure the security policies for service + models not identified by this standard. + +A.1. Unidirectional Multicast Applications + + Multimedia content-delivery multicast applications that do not have + congestion notification or re-transmission error-recovery mechanisms + are inherently unidirectional. RFC 4301 only defines bi-directional + unicast traffic selectors (as per RFC 4301, Sections 4.4.1 and 5.1 + with respect to traffic selector directionality). The GKM subsystem + requires that the IPsec subsystem MUST support unidirectional SPD + entries, which cause a Group Security Association (GSA) to be + installed in only one direction. Multicast applications that have + only one Group Member authorized to transmit can use this type of + Group Security Association to enforce that group policy. In the + inverse direction, the GSA does not have an SAD entry, and the GSPD + configuration is optionally set up to discard unauthorized attempts + to transmit unicast or multicast packets to the group. + + The GKM subsystem's management interface MUST have the ability to set + up a GKM subsystem group having a unidirectional GSA security policy. + +A.2. Bi-Directional Reliable Multicast Applications + + Some secure multicast applications are characterized as one Group + Sender to many receivers but have inverse data flows required by a + reliable multicast transport protocol (e.g., NORM). In such + applications, the data flow from the sender is multicast and the + inverse flow from the Group's Receivers is unicast to the sender. + Typically, the inverse data flows carry error repair requests and + congestion control status. + + For such applications, it is advantageous to use the same IPsec SA + for protection of both unicast and multicast data flows. This does + introduce one risk: the IKEv2 application may choose the same SPI for + receiving unicast traffic as the GCKS chooses for a group IPsec SA + covering unicast traffic. If both SAs are installed in the SAD, the + SA lookup may return the wrong SPI as the result of an SA lookup. To + + + +Weis, et al. Standards Track [Page 28] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + + avoid this problem, IPsec SAs installed by the GKM SHOULD use the 2- + tuple {destination IP address, SPI} to identify each IPsec SA. In + addition, the GKM SHOULD use a unicast destination IP address that + does not match any destination IP address in use by an IKEv2 unicast + IPsec SA. For example, suppose a Group Member is using both IKEv2 + and a GKM protocol, and the group security policy requires protecting + the NORM inverse data flows as described above. In this case, group + policy SHOULD allocate and use a unique unicast destination IP + address representing the NORM Group Sender. This address would be + configured in parallel to the Group Sender's existing IP addresses. + The GKM subsystems at both the NORM Group Sender and Group Receiver + endpoints would install the IPsec SA, protecting the NORM unicast + messages such that the SA lookup uses the unicast destination address + as well as the SPI. + + The GSA SHOULD use IPsec anti-replay protection service for the + sender's multicast data flow to the group's Receivers. Because of + the scalability problem described in the next section, it is not + practical to use the IPsec anti-replay service for the unicast + inverse flows. Consequently, in the inverse direction, the IPsec + anti-replay protection MUST be disabled. However, the unicast + inverse flows can use the group's IPsec group authentication + mechanism. The Group Receiver's GSPD entry for this GSA SHOULD be + configured to only allow a unicast transmission to the sender node + rather than a multicast transmission to the whole group. + + If an ESP digital signature authentication is available (e.g., RFC + 4359), source authentication MAY be used to authenticate a receiver + node's transmission to the sender. The GKM protocol MUST define a + key management mechanism for the Group Sender to validate the + asserted signature public key of any receiver node without requiring + that the sender maintain state about every Group Receiver. + + This multicast application service model is RECOMMENDED because it + includes congestion control feedback capabilities. Refer to + [RFC2914] for additional background information. + + The GKM subsystem's Group Owner management interface MUST have the + ability to set up a symmetric GSPD entry and one Group Sender. The + management interface SHOULD be able to configure a group to have at + least 16 concurrent authorized senders, each with their own GSA + anti-replay state. + + + + + + + + + +Weis, et al. Standards Track [Page 29] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + +A.3. Any-To-Many Multicast Applications + + Another family of secure multicast applications exhibits an "any-to- + many" communications pattern. A representative example of such an + application is a videoconference combined with an electronic + whiteboard. + + For such applications, all (or a large subset) of the Group Members + are authorized multicast senders. In such service models, creating a + distinct IPsec SA with anti-replay state for every potential sender + does not scale to large groups. The group SHOULD share one IPsec SA + for all of its senders. The IPsec SA SHOULD NOT use the IPsec anti- + replay protection service for the sender's multicast data flow to the + Group Receivers. + + The GKM subsystem's management interface MUST have the ability to set + up a group having an Any-To-Many Multicast GSA security policy. + +Appendix B. ASN.1 for a GSPD Entry + + This appendix describes an additional way to describe GSPD entries, + as defined in Section 4.1.1. It uses ASN.1 syntax that has been + successfully compiled. This syntax is merely illustrative and need + not be employed in an implementation to achieve compliance. The GSPD + description in Section 4.1.1 is normative. As shown in Section + 4.1.1, the GSPD updates the SPD and thus this appendix updates the + SPD object identifier. + +B.1. Fields Specific to a GSPD Entry + + The following fields summarize the fields of the GSPD that are not + present in the SPD. + + - direction (in IPsecEntry) + - DirectionFlags + - noswap (in SelectorList) + - ap-l, ap-r (in TunnelOptions) + + + + + + + + + + + + + + +Weis, et al. Standards Track [Page 30] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + +B.2. SPDModule + + SPDModule + + {iso(1) org (3) dod (6) internet (1) security (5) mechanisms (5) + ipsec (8) asn1-modules (3) spd-module (1) } + + DEFINITIONS IMPLICIT TAGS ::= + + BEGIN + + IMPORTS + RDNSequence FROM PKIX1Explicit88 + { iso(1) identified-organization(3) + dod(6) internet(1) security(5) mechanisms(5) pkix(7) + id-mod(0) id-pkix1-explicit(18) } ; + + -- An SPD is a list of policies in decreasing order of preference + SPD ::= SEQUENCE OF SPDEntry + + SPDEntry ::= CHOICE { + iPsecEntry IPsecEntry, -- PROTECT traffic + bypassOrDiscard [0] BypassOrDiscardEntry } -- DISCARD/BYPASS + + IPsecEntry ::= SEQUENCE { -- Each entry consists of + name NameSets OPTIONAL, + pFPs PacketFlags, -- Populate from packet flags + -- Applies to ALL of the corresponding + -- traffic selectors in the SelectorLists + direction DirectionFlags, -- SA directionality + condition SelectorLists, -- Policy "condition" + processing Processing -- Policy "action" + } + + BypassOrDiscardEntry ::= SEQUENCE { + bypass BOOLEAN, -- TRUE BYPASS, FALSE DISCARD + condition InOutBound } + + InOutBound ::= CHOICE { + outbound [0] SelectorLists, + inbound [1] SelectorLists, + bothways [2] BothWays } + + + + + + + + + +Weis, et al. Standards Track [Page 31] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + + BothWays ::= SEQUENCE { + inbound SelectorLists, + outbound SelectorLists } + + NameSets ::= SEQUENCE { + passed SET OF Names-R, -- Matched to IKE ID by + -- responder + local SET OF Names-I } -- Used internally by IKE + -- initiator + + Names-R ::= CHOICE { -- IKEv2 IDs + dName RDNSequence, -- ID_DER_ASN1_DN + fqdn FQDN, -- ID_FQDN + rfc822 [0] RFC822Name, -- ID_RFC822_ADDR + keyID OCTET STRING } -- KEY_ID + + Names-I ::= OCTET STRING -- Used internally by IKE + -- initiator + + FQDN ::= IA5String + + RFC822Name ::= IA5String + + PacketFlags ::= BIT STRING { + -- if set, take selector value from packet + -- establishing SA + -- else use value in SPD entry + localAddr (0), + remoteAddr (1), + protocol (2), + localPort (3), + remotePort (4) } + + DirectionFlags ::= BIT STRING { + -- if set, install SA in the specified + -- direction. symmetric policy is + -- represented by setting both bits + inbound (0), + outbound (1) } + + SelectorLists ::= SET OF SelectorList + + SelectorList ::= SEQUENCE { + localAddr AddrList, + remoteAddr AddrList, + protocol ProtocolChoice, + noswap BOOLEAN } -- Do not swap local and remote + -- addresses and ports on incoming + + + +Weis, et al. Standards Track [Page 32] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + + -- SPD-S and SPD-I checks + + Processing ::= SEQUENCE { + extSeqNum BOOLEAN, -- TRUE 64 bit counter, FALSE 32 bit + seqOverflow BOOLEAN, -- TRUE rekey, FALSE terminate & audit + fragCheck BOOLEAN, -- TRUE stateful fragment checking, + -- FALSE no stateful fragment checking + lifetime SALifetime, + spi ManualSPI, + algorithms ProcessingAlgs, + tunnel TunnelOptions OPTIONAL } -- if absent, use + -- transport mode + + SALifetime ::= SEQUENCE { + seconds [0] INTEGER OPTIONAL, + bytes [1] INTEGER OPTIONAL } + + ManualSPI ::= SEQUENCE { + spi INTEGER, + keys KeyIDs } + + KeyIDs ::= SEQUENCE OF OCTET STRING + + ProcessingAlgs ::= CHOICE { + ah [0] IntegrityAlgs, -- AH + esp [1] ESPAlgs} -- ESP + + ESPAlgs ::= CHOICE { + integrity [0] IntegrityAlgs, -- integrity only + confidentiality [1] ConfidentialityAlgs, -- confidentiality + -- only + both [2] IntegrityConfidentialityAlgs, + combined [3] CombinedModeAlgs } + + IntegrityConfidentialityAlgs ::= SEQUENCE { + integrity IntegrityAlgs, + confidentiality ConfidentialityAlgs } + + -- Integrity Algorithms, ordered by decreasing preference + IntegrityAlgs ::= SEQUENCE OF IntegrityAlg + + -- Confidentiality Algorithms, ordered by decreasing preference + ConfidentialityAlgs ::= SEQUENCE OF ConfidentialityAlg + + + + + + + + +Weis, et al. Standards Track [Page 33] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + + -- Integrity Algorithms + IntegrityAlg ::= SEQUENCE { + algorithm IntegrityAlgType, + parameters ANY -- DEFINED BY algorithm -- OPTIONAL } + + IntegrityAlgType ::= INTEGER { + none (0), + auth-HMAC-MD5-96 (1), + auth-HMAC-SHA1-96 (2), + auth-DES-MAC (3), + auth-KPDK-MD5 (4), + auth-AES-XCBC-96 (5) + -- tbd (6..65535) + } + + -- Confidentiality Algorithms + ConfidentialityAlg ::= SEQUENCE { + algorithm ConfidentialityAlgType, + parameters ANY -- DEFINED BY algorithm -- OPTIONAL } + + ConfidentialityAlgType ::= INTEGER { + encr-DES-IV64 (1), + encr-DES (2), + encr-3DES (3), + encr-RC5 (4), + encr-IDEA (5), + encr-CAST (6), + encr-BLOWFISH (7), + encr-3IDEA (8), + encr-DES-IV32 (9), + encr-RC4 (10), + encr-NULL (11), + encr-AES-CBC (12), + encr-AES-CTR (13) + -- tbd (14..65535) + } + + CombinedModeAlgs ::= SEQUENCE OF CombinedModeAlg + + CombinedModeAlg ::= SEQUENCE { + algorithm CombinedModeType, + parameters ANY -- DEFINED BY algorithm -- } + -- defined outside + -- of this document for AES modes. + + + + + + + +Weis, et al. Standards Track [Page 34] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + + CombinedModeType ::= INTEGER { + comb-AES-CCM (1), + comb-AES-GCM (2) + -- tbd (3..65535) + } + + TunnelOptions ::= SEQUENCE { + dscp DSCP, + ecn BOOLEAN, -- TRUE Copy CE to inner header + ap-l BOOLEAN, -- TRUE Copy inner IP header + -- source address to outer + -- IP header source address + ap-r BOOLEAN, -- TRUE Copy inner IP header + -- destination address to outer + -- IP header destination address + df DF, + addresses TunnelAddresses } + + TunnelAddresses ::= CHOICE { + ipv4 IPv4Pair, + ipv6 [0] IPv6Pair } + + IPv4Pair ::= SEQUENCE { + local OCTET STRING (SIZE(4)), + remote OCTET STRING (SIZE(4)) } + + IPv6Pair ::= SEQUENCE { + local OCTET STRING (SIZE(16)), + remote OCTET STRING (SIZE(16)) } + + DSCP ::= SEQUENCE { + copy BOOLEAN, -- TRUE copy from inner header + -- FALSE do not copy + mapping OCTET STRING OPTIONAL} -- points to table + -- if no copy + + DF ::= INTEGER { + clear (0), + set (1), + copy (2) } + + ProtocolChoice::= CHOICE { + anyProt AnyProtocol, -- for ANY protocol + noNext [0] NoNextLayerProtocol, -- has no next layer + -- items + oneNext [1] OneNextLayerProtocol, -- has one next layer + -- item + + + + +Weis, et al. Standards Track [Page 35] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + + twoNext [2] TwoNextLayerProtocol, -- has two next layer + -- items + fragment FragmentNoNext } -- has no next layer + -- info + + AnyProtocol ::= SEQUENCE { + id INTEGER (0), -- ANY protocol + nextLayer AnyNextLayers } + + AnyNextLayers ::= SEQUENCE { -- with either + first AnyNextLayer, -- ANY next layer selector + second AnyNextLayer } -- ANY next layer selector + + NoNextLayerProtocol ::= INTEGER (2..254) + + FragmentNoNext ::= INTEGER (44) -- Fragment identifier + + OneNextLayerProtocol ::= SEQUENCE { + id INTEGER (1..254), -- ICMP, MH, ICMPv6 + nextLayer NextLayerChoice } -- ICMP Type*256+Code + -- MH Type*256 + + TwoNextLayerProtocol ::= SEQUENCE { + id INTEGER (2..254), -- Protocol + local NextLayerChoice, -- Local and + remote NextLayerChoice } -- Remote ports + + NextLayerChoice ::= CHOICE { + any AnyNextLayer, + opaque [0] OpaqueNextLayer, + range [1] NextLayerRange } + + -- Representation of ANY in next layer field + AnyNextLayer ::= SEQUENCE { + start INTEGER (0), + end INTEGER (65535) } + + -- Representation of OPAQUE in next layer field. + -- Matches IKE convention + OpaqueNextLayer ::= SEQUENCE { + start INTEGER (65535), + end INTEGER (0) } + + -- Range for a next layer field + NextLayerRange ::= SEQUENCE { + start INTEGER (0..65535), + end INTEGER (0..65535) } + + + + +Weis, et al. Standards Track [Page 36] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + + -- List of IP addresses + AddrList ::= SEQUENCE { + v4List IPv4List OPTIONAL, + v6List [0] IPv6List OPTIONAL } + + -- IPv4 address representations + IPv4List ::= SEQUENCE OF IPv4Range + + IPv4Range ::= SEQUENCE { -- close, but not quite right ... + ipv4Start OCTET STRING (SIZE (4)), + ipv4End OCTET STRING (SIZE (4)) } + + -- IPv6 address representations + IPv6List ::= SEQUENCE OF IPv6Range + + IPv6Range ::= SEQUENCE { -- close, but not quite right ... + ipv6Start OCTET STRING (SIZE (16)), + ipv6End OCTET STRING (SIZE (16)) } + + END + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Weis, et al. Standards Track [Page 37] + +RFC 5374 Multicast Extensions to RFC 4301 November 2008 + + +Authors' Addresses + + Brian Weis + Cisco Systems + 170 W. Tasman Drive, + San Jose, CA 95134-1706 + USA + + Phone: +1-408-526-4796 + EMail: bew@cisco.com + + + George Gross + Secure Multicast Networks LLC + 977 Bates Road + Shoreham, VT 05770 + USA + + Phone: +1-802-897-5339 + EMail: gmgross@securemulticast.net + + + Dragan Ignjatic + Polycom + Suite 200 + 3605 Gilmore Way + Burnaby, BC V5G 4X5 + Canada + + Phone: +1-604-453-9424 + EMail: dignjatic@polycom.com + + + + + + + + + + + + + + + + + + + + +Weis, et al. Standards Track [Page 38] + -- cgit v1.2.3