Multicast Extensions to the Security Architecture for the Internet Protocol
Extracted elements (27)
GSPD entries with a remote IP multicast destination address do not have their Local and Remote addresses swapped during incoming SPD-S and SPD-I checks (unlike unicast SPD entries). This is because an IP multicast address must never appear as a source address, making the normal IKE convention of swapping bidirectional selectors inapplicable.
MAC-based authentication using a single shared secret is insufficient for data origin authentication in groups with more than two parties because every Group Member holds the MAC key and can forge valid MAC tags. Digital signatures (e.g., RSA/SHA-1) or TESLA are required when per-sender authentication is needed.
Source address preservation is optional rather than mandatory because a security gateway performing source address preservation cannot receive ICMP Path MTU or other ICMP messages triggered by those packets, since the outer source address is set to the inner header's source address rather than the gateway's own address.
For bi-directional reliable multicast applications (e.g., NORM), GKM SHOULD use the 2-tuple {destination IP address, SPI} to identify each IPsec SA and SHOULD allocate a unique unicast destination address for inverse (unicast) data flows to avoid SPI collisions with IKEv2-installed SAs.
GKM protocols (e.g., GDOI, GSAKMP) and IKEv2 can share access to a common GSPD/SAD concurrently. GKM SPI allocation is independent of IKEv2 SPI allocation because Group SAs are qualified by a multicast destination IP address; however, the GPAD requires explicit coordination between the two protocols.
A Group Identifier used to identify a secure multicast group MUST be at least four bytes long and less than 256 bytes long; it is an opaque byte string of IKE ID type Key ID.
A security gateway implementation of IPsec MUST use a tunnel mode SA when applying multicast IPsec extensions, because it needs to encapsulate incoming fragments that IPsec cannot directly process.
Address preservation MUST NOT be specified in an SAD entry when the IP version of the encapsulating header and IP version of the inner header do not match.
All IPsec devices participating in a multicast Security Association MUST share a common set of cryptographic transform and protocol-handling capabilities (homogeneous group). Support for heterogeneous composite groups is deferred to future standardization.
During inbound processing, if an IPsec SA is marked for tunnel mode with address preservation, the marked addresses in the outer IP header MUST be verified to match the corresponding addresses in the inner IP header; a mismatch MUST cause the packet to be discarded and treated as an auditable event.
Each GKM protocol registration exchange MUST use the asserted GCKS identity to locate a GPAD entry, authenticate the GCKS using the method specified in that entry, and verify the Group Identifier before accepting any group policy.
For any-to-many multicast applications where all Group Members may be senders, the group SHOULD share one IPsec SA for all senders, and the IPsec SA SHOULD NOT use the anti-replay protection service because maintaining per-sender anti-replay state does not scale to large groups.
GSPD entries marked as 'sender only' MUST be placed in GSPD-O only; entries marked as 'receiver only' MUST go to GSPD-I only. This directionality prevents creation of bidirectional SAs where only one direction is authorized.
The GKM subsystem and IPsec subsystem MUST be able to configure GSPD/SAD policies for both Any-Source Multicast (ASM) and Source-Specific Multicast (SSM) groups, covering unidirectional, bidirectional reliable, and any-to-many service models.
The IPsec subsystem MUST provide a management interface allowing the GKM subsystem to add and delete IPsec SAs. A GKM/IPsec implementation MUST support at least two concurrent IPsec SAs per Group Sender to enable re-key rollover continuity.
The outbound GSPD MUST implement a policy action capability that triggers a GKM protocol registration exchange so that Group Sender SAD entries are established dynamically when multicast application traffic matches GSPD policy.
When IPsec SA policy is received from a GCKS, each data flow MUST be compared to authorized data flows in the GPAD entry. Policy not matching a data flow is discarded and the reason SHOULD be recorded in the audit log.
When using tunnel mode with address preservation, the security gateway SHOULD populate the outer IP source address from the original packet's inner IP source address to pass Reverse Path Forwarding (RPF) checks performed by intermediate routers.
A Group Security Association (GSA) is a collection of one or more IPsec SAs plus one or more GKM SAs required for a Group Member to receive key updates. It represents the working policy for a group and may include concurrent SAs to support re-key rollover continuity.
Inbound IPsec multicast processing extends RFC 4301 by accepting packets addressed to a multicast group (not just unicast addresses of the device itself). A new processing step (3aa) performs SAD lookup using SPI plus destination address (or SPI plus destination and source) for multicast-destined AH/ESP packets.
The Group Peer Authorization Database (GPAD) is a new database analogous to RFC 4301's PAD. It identifies authorized GCKS devices, specifies their authentication protocols and data, constrains traffic selectors a GCKS may assert, and constrains Group Identifiers a GCKS is authorized to serve.
The Group Security Policy Database (GSPD) extends the RFC 4301 SPD with multicast-specific semantics: it adds an address preservation (AP) flag with AP-L and AP-R attributes for local and remote tunnel addresses, and a directionality attribute (symmetric, sender only, or receiver only) to GSPD entries.
Tunnel mode with address preservation copies the inner IP header source and/or destination addresses into the outer (tunnel) header. This preserves multicast routing semantics so PIM-SM and other multicast routing protocols can correctly route IPsec-protected multicast packets.
SSM Group Sender source addresses can dynamically change (due to NAT, mobility, or multi-homing), causing GSPD entries to become stale. To prevent data leakage through BYPASS processing, SSM groups SHOULD maintain a default DISCARD policy for all unauthorized Group Sender source addresses for the SSM group's destination address.
The multicast IPsec extensions do not defend against outsider denial-of-service attacks (flooding from unauthenticated systems), compromised multicast routers that can corrupt or drop packets, or replay attacks against groups that do not enable the anti-replay service. Large-scale any-source multicast groups cannot practically maintain per-sender anti-replay state.
The security of a multicast group is bounded by its weakest admitted member because all members share group secrets. An insider adversary can disclose keys, forge packet transmissions attributed to legitimate senders, or launch computational DoS attacks by multicasting bogus digitally-signed packets. The GKM system must detect compromised members and execute re-keying to expel them.
Re-key rollover uses two timer parameters: Activation Time Delay (ATD) delays activation of new 'leading edge' SAs until all members have received the Re-Key Event, and Deactivation Time Delay (DTD) governs when the old 'trailing edge' SA is deleted. States are: pending (new SA distributed, not yet active), active (leading edge transmitting), and expired (trailing edge deleted after DTD).