summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5374.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5374.txt')
-rw-r--r--doc/rfc/rfc5374.txt2131
1 files changed, 2131 insertions, 0 deletions
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]
+