RFC 5374
Multicast Extensions to the Security Architecture for the Internet Protocol
RFC 5374: Multicast Extensions to the Security Architecture for the Internet Protocol 🎀
okay bestie, let's start with the basics 💅 This is RFC 5374, a Standards Track doc from November 2008. It's by B. Weis (Cisco Systems), G. Gross (Secure Multicast Networks LLC), and D. Ignjatic (Polycom), and it lives in the Network Working Group world. The title block doesn't list anything it obsoletes or updates, so there's nothing to report there 🌸
Status of This Memo ✨
so this one is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions to make it better 🫶 If you want to know where it stands and what its official status is, check the current edition of "Internet Official Protocol Standards" (STD 1). Also, distribution of this memo is unlimited, so share away 💜
Copyright Notice 🦋
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved. This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect when it was published. Read those carefully, bestie, because they spell out your rights and restrictions for this document 📜
Abstract 🌈
okay so the Security Architecture for the Internet Protocol is all about security services for traffic at the IP layer 🔐 The catch is that it mostly focuses on IP unicast packets, which means one sender and one receiver. This doc picks up the slack and explains how IPsec security services get applied to IP multicast packets 🧚 Heads up though: these extensions only matter for an IPsec implementation that supports multicast. Otherwise, you can skip them 🙈
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 ..................................................311. Introduction ✨
okay so the Security Architecture for the Internet Protocol [RFC4301] gives us security services for traffic at the IP layer 💖 It describes an architecture for IPsec-compliant systems and a set of IP-layer security services. Those services mainly describe the semantics for IPsec Security Associations (SAs) shared between two IPsec devices. Usually that means SAs with traffic selectors that have a unicast address in the IP destination field, which leads to an IPsec packet with a unicast address in that same field 🎀
Here's the plot twist: the security services defined in RFC 4301 can also tunnel IP multicast packets, as long as the tunnel is a pairwise association between two IPsec devices 🦋 RFC 4301 also defined manually keyed transport mode IPsec SA support for IP packets with a multicast address in the IP destination address field. But it didn't define how an IPsec subsystem interacts with a Group Key Management protocol, and it didn't define the semantics of a tunnel mode IPsec SA with an IP multicast address in the outer IP header. Those gaps are the whole reason this doc exists 🔥
This document describes OPTIONAL extensions to RFC 4301 that further define the IPsec security architecture so that groups of IPsec devices can share SAs 🌸 Specifically, it supports SAs with traffic selectors that include a multicast address in the IP destination field, and those SAs result in an IPsec packet with an IP multicast address in the IP destination field. It also adds semantics for IPsec Group Key Management (GKM) subsystems. Quick note: this doc uses the term "GKM protocol" generically, so it doesn't assume any particular GKM protocol 🧚
An IPsec implementation that doesn't support multicast is not required to support these extensions. Totally fine, no pressure 🫶
Throughout this document, the RFC 4301 semantics stay unchanged by these multicast extensions, unless it specifically says otherwise. So if you're confused about something, RFC 4301 is probably still in charge 💅
1.1. Scope 🌈
The IPsec extensions 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, iykyk 🍓 These extensions get used when management policy says IP multicast packets protected by IPsec have to stay IP multicast packets. But if management policy says those multicast packets should be encapsulated as IP unicast packets (for example, because the network on the unprotected interface doesn't support IP multicast), then these extensions don't get used 🙈
These extensions also support Security Associations with IPv4 Broadcast addresses that result in an IPv4 link-level Broadcast packet, plus IPv6 Anycast addresses [RFC2526] that result in an IPv6 Anycast packet. These destination address types share a lot of the same vibes as multicast addresses, because there may be multiple candidate receivers for a packet protected by IPsec 🦋
The IPsec architecture doesn't put requirements on entities that aren't participating in IPsec (like network devices sitting between IPsec endpoints) ✨ So these multicast extensions don't require intermediate systems in a multicast-enabled network to participate in IPsec. No requirements are placed on the use of multicast routing protocols (like Protocol Independent Multicast - Sparse Mode (PIM-SM) [RFC4601]) or multicast admission protocols (like Internet Group Management Protocol (IGMP) [RFC3376]) either, so the network stays chill 🧚
All implementation models of IPsec (like "bump-in-the-stack" and "bump-in-the-wire") are supported 💖
This version of the multicast IPsec extension specification is strict about one thing: all IPsec devices participating in a Security Association have to be homogeneous. They MUST share a common set of cryptographic transform and protocol-handling capabilities. No mixing and matching, bestie 🔐
The semantics of an "IPsec composite group" [COMPGRP], which is a heterogeneous IPsec cryptographic group formed from the union of two or more sub-groups, are an area for future standardization 👑
to be continued, bestie 🎀 part 2 is coming next with Terminology and the IP Multicast overview ✨
1.2. Terminology ✨
okay so first, 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]. bestie, these are the official words that carry the weight 💅
here are the key terms we'll be using all throughout the doc 🦋
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. 🌸
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. 🌈
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 🌈
okay, so 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. 🚀
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 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 💅
okay so 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) ✨
okay so the Group Security Policy Database (GSPD) is a security policy database that can handle regular unicast Security Associations (the ones from RFC 4301) AND the multicast extensions in this spec 🦋 It's basically the SPD with extra multicast semantics layered on top, and this section explains them. Appendix B has an ASN.1 example of a GSPD entry if you want to see one in the wild 🤓
this doc adds an "address preservation" (AP) flag that says tunnel mode with address preservation is to be applied to a GSPD entry 💖 the flag has two attributes, AP-L and AP-R. AP-L is used when processing the local tunnel address, and AP-R is used when processing the remote tunnel process. the flag goes into the GSPD "Processing info" field, and the RFC 4301 Section 4.4.1.2 text gets amended to include this extra processing. (only the tunnel-related "Processing info" text is reproduced here, for brevity 🙈)
so the "Processing info" field says which action is required: PROTECT, BYPASS, or DISCARD. there's just ONE action for all the selector sets, not a separate action per set 💅 when the action is PROTECT, the entry holds:
- the IPsec mode, which is tunnel or transport
- if tunnel mode, the local tunnel address. on a non-mobile host with one interface this is straightforward. with multiple interfaces it has to be statically configured. on a mobile host, specifying the local address is handled outside of IPsec. if tunnel mode with address preservation is specified for the local tunnel address, the AP-L attribute is set to TRUE for it and the local tunnel address is unspecified. the AP-L attribute means the inner IP header source address gets copied to the outer IP header source address when the IP header is built for tunnel mode 🫶
- if tunnel mode, the remote tunnel address. there's no standard way to figure this one out (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 it and the remote tunnel address is unspecified. the AP-R attribute means the inner IP header destination address gets copied to the outer IP header destination address when the IP header is built for tunnel mode 🌸
next up, unique directionality for GSPD entries with a remote IP multicast address 🔥 an IP multicast address can't be used as the source address of an IP packet ([RFC1112]), so the Local and Remote addresses and ports keep their directionality during incoming SPD-S and SPD-I checks instead of getting swapped. Section 4.4.1 of RFC 4301 gets amended like this: normally, for traffic protected by IPsec, the Local and Remote addresses and ports in an SPD entry get swapped to show directionality, matching IKE conventions. the protocols IPsec deals with generally need symmetric SAs with flipped Local/Remote IP addresses. BUT SPD entries with a remote IP multicast address don't get their Local and Remote addresses and ports swapped during incoming SPD-S and SPD-I checks ✨
there's also a brand new GSPD attribute called GSPD entry directionality 🎀 it gets added to the bullet list of SPD fields in Section 4.4.1.2 of RFC 4301. directionality can be one of three types: "symmetric", "sender only", or "receiver only". "symmetric" means a PAIR of SAs gets created, one in each direction, as RFC 4301 specifies. "sender only" entries mean ONE SA gets created in the outbound direction, and "receiver only" entries mean ONE SA gets created in the inbound direction. "sender only" and "receiver only" entries SHOULD support multicast IP addresses in their destination address selectors. if the requested processing is BYPASS or DISCARD and a "sender only" type is configured, the entry MUST be put in GSPD-O only. and the reverse: if the type is "receiver only", the entry MUST go to GSPD-I only 🙌
GSPD entries created by a GCKS can get the same SPIs as SAD entries created by IKEv2 [RFC4306], and that's fine for inbound traffic because the right SAs can be matched with the algorithm in Section 4.1 of RFC 4301 😌 outbound traffic is different though, it has to be matched against the GSPD selectors so the right SA can be created 💀
to make dynamic group keying work, the outbound GSPD MUST implement a policy action capability that triggers a GKM protocol registration exchange (per Section 5.1 of [RFC4301]) 🔑 for example, the Group Sender GSPD policy might trigger when a specific multicast application packet enters through the protected interface, or when the implementation emits one on the protected side and it's headed to the unprotected interface. the Group Sender registration exchange that follows sets up the Group Sender's outbound SAD entry, which encrypts the multicast application's data stream. in the other direction, group policy may also set up an inbound IPsec SA, lowercase but iconic 🧚
at the Group Receiver endpoints, the IPsec subsystem MAY use GSPD policy mechanisms that kick off a GKM protocol registration exchange. one example is detecting a device on the protected network joining a multicast group that matches GSPD policy, like receiving an IGMP/MLD (Multicast Listener Discovery) join group message on a protected interface 🍓 the Group Receiver registration exchange that follows sets up the Group Receiver's inbound SAD entry, which decrypts the multicast stream. in the inverse direction, group policy may also set up an outbound IPsec SA (for example, when supporting an ASM service model) 💜
Note: a security gateway that triggers on unauthenticated messages arriving on a protected interface might register the Group Receiver early, if the message isn't from a device on the protected network that actually wants to join a multicast group 😭 the unauthenticated messages only make the Group Receiver register ONCE. after that, later messages have no effect on it.
the IPsec subsystem MAY provide GSPD policy mechanisms that automatically start a GKM protocol de-registration exchange 🌈 de-registration lets a GCKS minimize exposure of the group's secret key by re-keying the group when membership changes, and it also cuts down the GCKS's cost for groups that keep track of member state. one example is detecting an IGMP/MLD leave group exchange. a security gateway Group Member, though, won't start a GKM protocol de-registration exchange until it detects that there are no more receivers behind a protected interface 🙈
also, the GKM subsystem MAY set up GSPD/SAD state information independently of the multicast application's state ✨ in this case the Group Owner issues management directives that tell the GKM subsystem when to start its registration and de-registration exchanges. usually the registration policy aims to keep the group's IPsec subsystem state "always ready" in anticipation of the multicast application starting up 👑
4.1.2. Security Association Database (SAD) 🎀
the SAD holds an item that says whether tunnel or transport mode is applied to traffic on this SA 💅 Section 4.4.2.1 of RFC 4301 gets amended to describe address preservation.
the IPsec protocol mode is tunnel or transport, and it says which mode of AH or ESP is applied to traffic on this SA. when tunnel mode is specified, the data item also says whether address preservation is applied to the outer IP header. address preservation MUST NOT be specified when the IP version of the encapsulating header and the IP version of the inner header don't match 🙅♀️ the local address, the remote address, or both addresses MAY be marked as preserved during tunnel encapsulation 🦋
4.1.3. Group Peer Authorization Database (GPAD) 🧚
the multicast IPsec extensions bring in a brand new data structure called the Group Peer Authorization Database (GPAD) 🌸 it's analogous to the PAD from RFC 4301, and it links the GSPD to a Group Key Management (GKM) Subsystem. the GPAD has five critical jobs:
- it identifies a GCKS (or a group of GCKS devices) that's authorized to communicate with this IPsec entity
- it specifies the protocol and method used to authenticate each GCKS
- it provides the authentication data for each GKCS
- it constrains the traffic selectors a GCKS can assert when it comes to SA creation
- it constrains the types and values of Group Identifiers a GCKS is authorized to provide group policy for
the GPAD does these things for a Group Key Management subsystem. IKE and other authentication protocols that DON'T act as GKM protocols don't consult the GPAD, so it's not their business 😌
to do all this, the GPAD has an entry for every GCKS the IPsec entity is configured to contact. each entry has one or more GCKS Identifiers, the authentication protocol (like Group Domain of Interpretation (GDOI) or Group Secure Association Key Management Protocol (GSAKMP)), the authentication method used (like certificates or pre-shared secrets), and the authentication data (like the pre-shared secret, or the trust anchor the peer's certificate gets validated against) 🔥 for certificate-based authentication, the entry can also include info for checking the peer's revocation status, like a pointer to a Certificate Revocation List (CRL) repository, or the name of an Online Certificate Status Protocol (OCSP) server tied to the peer or to its trust anchor. the entry also holds the constraints a Group Member applies to the policy it gets 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 🍓 they're specified as PAD entry IDs in Section 4.4.3.1 of RFC 4301, and they follow the matching rules described there ✨
4.1.3.2. GCKS Peer Authentication Data
okay so once we've found the GPAD entry, we still gotta check that the GCKS is who it says it is 🕵️♀️. That means authenticating the asserted GCKS Identifier, and it's giving detective energy. The PAD authentication data types and semantics from Section 4.4.3.2 of RFC 4301 are what we use to authenticate a GCKS 💅.
For the deets on how a GKM protocol does peer authentication with certificates and pre-shared secrets, check out GDOI [RFC3547] and GSAKMP [RFC4535] 📚🫶.
4.1.3.3. Group Identifier Authorization Data
a Group Identifier is how a GKM protocol says "this is the group we mean" to a GCKS 🎀. A GPAD entry carries a Group Identifier so we know the GCKS Identifiers in that entry are allowed to act as a GCKS for that group. main character permissions 👑.
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, it hands the Group Member its IPsec SA policy 📦. But wait, before the Group Member accepts that policy, it checks the source and destination traffic selectors of the SA against a set of authorized data flows 🧐. Each data flow has a set of authorized source traffic selectors and a set of authorized destination traffic selectors. Traffic selectors are written 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. two families, one vibe ✨.)
4.1.3.5. How the GPAD Is Used
when a GKM protocol registration exchange gets triggered, the Group Member and the GCKS each assert their identity as part of the exchange 🗣️. Every GKM protocol registration exchange MUST use the asserted ID to locate an identity in the GPAD. The GPAD entry tells you which authentication method to use for the identified GCKS, plus the authentication data used to verify the asserted identity. That data gets used together with the method to authenticate the GCKS before any group policy gets accepted from it 🔒.
During the GKM protocol registration, a Group Member includes a Group Identifier. Before it presents that Group Identifier to the GCKS, the Group Member verifies that the GPAD entry for the authenticated GCKS includes the Group Identifier. This makes sure the GCKS is actually authorized to provide policy for the Group 🫡.
When IPsec SA policy is received, each data flow gets compared to the data flows in the GPAD entry. The Group Member accepts policy that matches a data flow. Policy that doesn't match a data flow gets 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, same as we just covered 🔁.
4.2. Group Security Association (GSA)
an IPsec implementation that supports these extensions will handle a bunch of Security Associations at once: one or more IPsec SAs, plus one or more GKM SAs used to download the parameters that get used to create the IPsec SAs 🍓. Together, these 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 at the same time 🦋. This mostly happens for two reasons:
- There are multiple Group Senders authorized in the group, and each one has 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 the multicast data stream stays continuous 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:
- 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 ⏰.
- 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 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, and each such epoch has 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 transmitting 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 🔐.
- 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 lets the group drain its in-transit datagrams from the network while it transitions 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 ✨
okay so data origin authentication is the vibe check for WHO actually sent the message 🕵️♀️. [RFC4301] defines it as a security service that verifies the identity of the claimed source of data. A Message Authentication Code (MAC) is the usual move for connections shared between two parties 🔐, but typical MAC methods with one shared secret are NOT enough for groups with more than two parties. Every Group Member can use the MAC key to make a valid tag, even if they're not the real originator of the group application's data 🙈. not it, bestie.
When an IPsec SA is shared by more than two parties and you need data origin authentication, you want an authentication transform where the receiver can be sure the sender generated that exact message. Two options are Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [RFC4082] or RSA digital signature [RFC4359] 💖.
The catch is that some algorithms (like digital signature transforms) cost way more to process than a Hashed Message Authentication Code (HMAC) method 💀. To guard against denial-of-service attacks from a device that isn't authorized to join the group, the IPsec SA using this algorithm may be wrapped inside an IPsec SA that uses a MAC authentication algorithm 🛡️. The downside is that the packet has to cross the IPsec boundary a second time for extra outbound processing on the Group Sender (see Section 5.1 of [RFC4301]), and again for inbound processing on Group Receivers (see Section 5.2 of [RFC4301]). This "AH or ESP inside AH or ESP" setup exists because AH and ESP each only define an Integrity Check Value (ICV) for a single authenticator transform 🧚.
4.4. Group SA and Key Management 🌸
4.4.1. Co-Existence of Multiple Key Management Protocols
okay so the GKM subsystem is often added to an existing IPsec subsystem as a companion key management protocol to IKEv2 [RFC4306] 🎀. A core requirement for the IP security subsystem is that the GKM protocol and IKEv2 can BOTH access the same Group Security Policy Database and Security Association Database at the same time 💅. How they keep access mutually exclusive to those GSPD/SAD structures is a local matter, and that includes the GSPD-O cache and the GSPD-I cache 🍓.
Implementers should note that IKEv2 SPI allocation is totally independent from GKM SPI allocation. That's because Group Security Associations are identified by a destination multicast IP address and may optionally have a source IP address qualifier 🦋. See Section 2.1 of [RFC4303] for the full tea ☕.
The Peer Authorization Database DOES need explicit coordination between the GKM protocol and IKEv2 🫶. Section 4.1.3 breaks down these interactions.
5. IP Traffic Processing ✨
Processing of traffic follows Section 5 of [RFC4301], with the extra stuff below applied 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), then either or both of the outer header source or destination addresses are marked as preserved 🌈.
Header construction for tunnel mode is described in Section 5.1.2 of RFC 4301. The first bullet of that section gets amended like this:
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), about constructing tunnel addresses in Section 5.1.2.1 of RFC 4301, also gets amended. (Quick heads-up: for brevity, Note (3) of RFC 4301 isn't reproduced in full here 🙈.)
(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 from an IPsec device that supports these multicast extensions may (depending on its GSPD policy) carry an outer tunnel header whose destination address is NOT an IPsec device 🦩. So an IPsec device supporting these extensions has to accept and process IP traffic that isn't addressed to itself. The IPsec inbound processing additions below are necessary for that 💅.
For compatibility with RFC 4301, "addressed to this device" means packets with a unicast destination address belonging to the system itself, plus multicast packets that the system itself receives. Multicast packets the IPsec device doesn't receive are NOT considered addressed to this device 🙅♀️.
Here's how the inbound processing in Section 5.2 of RFC 4301 gets amended. The first dash in item 2 changes to:
- 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 brand-new item goes between items 3a and 3b, covering 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 gets an update to show this new 3aa processing path 🗺️:
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)The discussion of inbound IP traffic in Section 5.2 of RFC 4301 also gets a new item 6, like so:
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 🔥
Okay, this part is SERIOUS, so please read it 🥺. The IP security multicast extensions in this spec build on the unicast-oriented IP security architecture [RFC4301]. That means this spec inherits a lot of RFC 4301's security considerations, and the reader is advised to review that one as companion guidance 📚.
6.1. Security Issues Solved by IPsec Multicast Extensions
The IP security multicast extension service gives you these 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 some other mechanism ✍️.
- Anti-replay protection for a limited number of Group Senders, using the ESP (or AH) sequence number facility 🔁.
- Filtering of multicast transmissions whose source address belongs to systems that group policy does NOT authorize to be Group Senders 🚫. This leverages the IPsec stateless firewall service (i.e.,
SPD-Iand/orSDP-Oentries with a packet disposition specified asDISCARD).
In support of all of the above, this spec upgrades the definitions of the SPD, PAD, and SAD databases so large-scale cryptographic groups can get automated group key management 👑✨.
6.2. Security Issues Not Solved by IPsec Multicast Extensions ✨
Okay bestie, so RFC 4301 already said (in its Section 2.2) that this architecture is NOT in charge of protecting the group's keys or app data from attacks on the operating environment where IPsec runs 🙅♀️ That's not the job here. Still, the more systems that share the group keys, the bigger the risk from someone on the network, so it's a real concern 😭
Also, there are two big buckets of stuff this extension just can't fix: outsider attacks and insider attacks 🕵️♀️
6.2.1. Outsider Attacks
Okay, so the IPsec multicast extension service doesn't protect you from an outsider (someone NOT in the group) who has any of these powers 💀
- They can launch a flooding denial-of-service attack at the group using multicast traffic, coming from a system whose IPsec subsystem doesn't filter out unauthorized multicast transmissions 🌊
- They've compromised a multicast router, so they can corrupt or delete every multicast packet headed for the group endpoints downstream of that router 💔
- They captured an earlier multicast packet and replayed it to a group that doesn't have anti-replay turned on 🔁 Also, for a huge any-source multicast group, it's wildly impractical for the Group Receivers to keep anti-replay state for every possible Group Sender 😵 So if your group policy needs anti-replay protection for a big any-source group, you should look at an application layer multicast protocol that can spot and reject replays 🧠
6.2.2. Insider Attacks
For big groups, the IP security multicast extensions rely on an automated Group Key Management protocol to correctly authenticate and authorize trustworthy members that follow the group's policies 🫶 The thing is, a cryptographic group is built on one or more shared secrets that every Group Member holds, so the group's security is only as strong as the weakest member the GKM system let in 😬 When the GKM system detects a compromised Group Member, it's supposed to run a re-key procedure. The GKM re-keying protocol kicks out the compromised Group Members and hands new group keying material to the trusted ones 🔑 Or, if the group policy says so, the GKM system can just terminate the group 🪦
Now, if an adversary got admitted into the group by the GKM system, these attacks are possible, and the IPsec multicast extension service can NOT solve them 🙈
- The adversary can leak the secret group key or group data to someone outside the group 📤 After a key or data compromise, things like traitor tracing or watermarking can help with the forensics 🕵️ But those methods are outside the scope of this specification, so that's a different story 🙃
- The insider adversary can forge packets that look like they came from a peer Group Member 👻 To guard against this for the Group Sender transmissions that are worth the extra 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, the insider adversary can run 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't save you from a sloppy group security policy that allows a weaker cryptographic algorithm just because every endpoint in the group supports it 🙅♀️ Honestly, big groups are hard to upgrade to the current best-in-class cryptographic algorithms 😩 One possible fix for a lot of these problems is deploying composite groups that can straddle heterogeneous groups [COMPGRP] ✨ A standard solution for heterogeneous groups is still future work and is not finished yet 🚧 In the meantime, you could keep a group's cryptographic capabilities in sync using a secure and scalable software distribution management tool 🧰
6.3.2. Groups that Span Two or More Security Policy Domains
Large-scale groups can span multiple legal jurisdictions (e.g., countries) that put limits on cryptographic algorithms or key strengths 🌍 As it's currently defined, the IPsec multicast extension service needs a single group policy per group 📜 Like we said above, this problem is still something for future standardization 🔮
6.3.3. Source-Specific Multicast Group Sender Transient Locators
A Source Specific Multicast (SSM) Group Sender's source IP address can change dynamically during a secure multicast group's lifetime 🦋 Things that can make the Group Sender's source address change include, but aren't limited to, NAT, a mobility-induced change in the care-of-address, and a multi-homed host using a new IP interface 📡 When the Group Sender's source IP address changes, the GSPD entries for that multicast group can go out of date compared to the group's multicast routing state 😵💫 The worst case is that the Group Sender's data, coming from a new source address, gets BYPASS processed by a security gateway 😱 If nobody planned for this scenario, it could leak the group's data 💔 So, 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 wanted 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 when the Security Considerations section of this memo was developed 📝
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.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.
[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.Appendix A. Multicast Application Service Models 🧚
The vast majority of secure multicast applications can be sorted by their service model and their 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 so they 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 security policies for service models that this standard doesn't identify 🦋
A.1. Unidirectional Multicast Applications ✨
Okay so multimedia content-delivery multicast apps that don't have congestion notification or retransmission 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 apps with only one Group Member authorized to transmit can use this type of GSA to enforce that group policy 🎀. In the inverse direction, the GSA doesn't 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 apps are one Group Sender talking to many receivers, but they need inverse data flows for a reliable multicast transport protocol (e.g., NORM) 🌸. In these apps, the data from the sender is multicast, and the inverse flow from the Group's Receivers is unicast back to the sender. Usually those inverse flows carry error repair requests and congestion control status 🧚.
For these apps, it's really handy to use the same IPsec SA to protect both the unicast and the multicast data flows 💅. Here's the catch, though: the IKEv2 application might pick the same SPI for receiving unicast traffic that the GCKS picks for a group IPsec SA covering unicast traffic. If both SAs end up in the SAD, the SA lookup might return the wrong SPI 😭. To dodge this, IPsec SAs installed by the GKM SHOULD use the 2-tuple {destination IP address, SPI} to identify each IPsec SA. The GKM SHOULD also use a unicast destination IP address that doesn't match any destination IP address in use by an IKEv2 unicast IPsec SA 🫶.
Here's an example. Say 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 🔥. That 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, so the SA lookup uses the unicast destination address as well as the SPI ✨.
The GSA SHOULD use the 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 isn't practical to use the IPsec anti-replay service for the unicast inverse flows 🌈. So, in the inverse direction, the IPsec anti-replay protection MUST be disabled 🙅♀️. However, the unicast inverse flows can still 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 keep 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 🎀.
A.3. Any-To-Many Multicast Applications 💫
Another family of secure multicast apps has an "any-to-many" communications pattern 🌟. A classic example is a videoconference combined with an electronic whiteboard 📹.
For these apps, all (or a large subset) of the Group Members are authorized multicast senders 🙌. In these service models, making a distinct IPsec SA with anti-replay state for every potential sender doesn't scale to large groups 😩. So 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 an implementation doesn't need to use it 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, so 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)DirectionFlagsnoswap (in SelectorList)ap-l, ap-r (in TunnelOptions)
B.2. SPDModule 🎀
Okay bestie, this is the ASN.1 module for the whole SPD structure, and it's giving organized. Every policy entry, selector, and algorithm list lives in here, so here's the full thing, exactly as written:
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 }
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
-- 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
-- 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.
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
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) }
-- 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)) }
ENDAuthors' 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.comThat's the whole document, bestie! 🦋✨
📦 where this page comes from
- ietf: rfc5374 2008-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms