MSEC Working Group B. Weis Internet-Draft Cisco Systems Expires: December, 2006 G. Gross IdentAware Security D. Ignjatic Polycom June, 2006 Multicast Extensions to the Security Architecture for the Internet Protocol draft-ietf-msec-ipsec-extensions-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The Security Architecture for the Internet Protocol [RFC4301] describes security services for traffic at the IP layer. That architecture primarily defines services for Internet Protocol (IP) unicast packets, as well as manually configured IP multicast packets. This document further defines the security services for manually and dynamically keyed IP multicast packets within that Security Architecture. Weis Expires December, 2006 [Page 1] Internet-Draft Multicast Extensions to RFC 4301 June, 2006 Table of Contents 1. Introduction........................................................3 1.1 Scope............................................................4 1.2 Terminology......................................................5 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)........................9 4.1.2 Security Association Database (SAD).........................10 4.1.3 Peer Authorization Database (PAD)...........................10 4.2 Group Security Association (GSA)................................12 4.3 Data Origin Authentication......................................13 4.4 Group SA and Key Management.....................................14 4.4.1 Co-Existence of Multiple Key Management Protocols...........14 4.4.2 New Security Association Attributes.........................14 5. IP Traffic Processing..............................................15 5.1 Outbound IP Multicast Traffic Processing........................15 5.2 Inbound IP Multicast Traffic Processing.........................15 6. IP-v4 Network Address Translation..................................15 6.1 GSPD Losses Synchronization with Internet Layer's State.........16 6.1.1 Mobile Multicast Care-Of Address Route Optimization.........16 6.1.2 NAT Translation Mappings Are Not Predictable................16 6.2 Secondary Problems Created by NAT Traversal.....................17 6.2.1 SSM Routing Dependency on Source IP Address.................17 6.2.2 ESP Cloaks Its Payloads from NAT Gateway....................17 6.2.3 UDP Checksum Dependency on Source IP Address................18 6.2.4 Cannot Use AH with NAT Gateway..............................18 6.3 Avoidance of NAT Using an IPv6 Over IPv4 Network................18 6.4 GKM/IPsec Multi-Realm IPv4 NAT Architecture.....................19 6.4.1 GKM/IPsec IPv4 NAT Architectural Assumptions................20 6.4.2 Multicast Application GSA NAT Traversal.....................21 6.5 ESP Encapsulated by UDP in a Multicast Group....................22 7. Security Considerations............................................22 8. IANA Considerations................................................23 9. Acknowledgements...................................................23 10. References........................................................23 10.1 Normative References...........................................23 10.2 Informative References.........................................23 Appendix A _ Multicast Application Service Models.....................26 A.1 Unidirectional Multicast Applications...........................26 A.2 Bi-directional Reliable Multicast Applications..................26 A.3 Any-To-Any Multicast Applications...............................27 Weis, et al. Expires December, 2006 [Page 2] Internet-Draft Multicast Extensions to RFC 4301 June, 2006 Author's Address......................................................28 Intellectual Property Statement.......................................29 Copyright Statement...................................................29 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. RFC4301 defined manually keyed transport mode IPsec SA support for IP packets with a multicast address in the IP destination address field. However, RFC4301 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 extensions to RFC 4301 that further define the IPsec security architecture 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 results 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 it does not assume a particular GKM protocol. 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] [RFC3376] group addresses are supported. 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 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 Weis, et al. Expires December, 2006 [Page 3] Internet-Draft Multicast Extensions to RFC 4301 June, 2006 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., PIM-SM [RFC2362]) or multicast admission protocols (e.g., 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 are homogeneous. They MUST share a common set of cryptographic transform and protocol handling capabilities. The semantics of an "IPsec composite group", 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. 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 must 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. Weis, et al. Expires December, 2006 [Page 4] Internet-Draft Multicast Extensions to RFC 4301 June, 2006 Group Member An IPsec device that belongs to a group. A Group Member is authorized to be a Group Speaker 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 RFC4046 [RFC4046] for additional information. Group Security Policy Database (GSPD) The GSPD is a multicast-capable security policy database, as mentioned in RFC3740 and RFC4301 section 4.4.1.1. Its semantics are a superset of the unicast SPD defined by RFC4301 section 4.4.1. Unlike a unicast SPD-S in which point-to-point security associations are inherently bi-directional, multicast security associations in the GSPD-S introduce a "sender only" or "receiver only" or "symmetric" SA direction attribute. Refer to section 4.1.1 for more details. Group Receiver A Group Member that is authorized to receive packets sent to a group by a Group Speaker. Group Speaker 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 UDP data packets delivered to all members of the group with either "best-effort" [RFC1112], or reliable delivery (e.g., NORM) [RFC3940]. Weis, et al. Expires December, 2006 [Page 5] Internet-Draft Multicast Extensions to RFC 4301 June, 2006 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 RFC 3171, RFC3306, and RFC3307 [RFC3171] [RFC3306] [RFC3307]. Potential receivers of the packet "join" the IP multicast group by registering with a network routing device [RFC3376] [MLD], 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) [RFC2362]. 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 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 and tunnel mode to encapsulate an IP multicast packet. These processing rules are identical to the rules described in [RFC4301, Section 4.1]. 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 using the multicast extensions MUST use a tunnel mode SA, for the reasons described in [RFC4301, Section 4.1]. In particular, the security gateway must use tunnel mode to encapsulate incoming fragments, since IPsec cannot directly operate on fragments. 3.1 Tunnel Mode with Address Preservation New header construction semantics are required when tunnel mode is used to encapsulate IP multicast packets that are to remain IP multicast packets. This is due to the following unique requirements of IP multicast routing protocols (e.g., PIM-SM [RFC2362]). - IP multicast routing protocols compare the destination address on a packet to the multicast routing state. If the destination of an IP multicast packet is changed it will no longer be properly routed. Therefore, an IPsec security gateway must preserve the multicast IP destination address after IPsec tunnel encapsulation. Weis, et al. Expires December, 2006 [Page 6] Internet-Draft Multicast Extensions to RFC 4301 June, 2006 The GKM Subsystem on a security gateway implementing the IPsec multicast extensions preserves the multicast IP address as follows. Firstly, the GKM Subsystem sets the Remote Address PFP flag in the GSPD-S entry for the traffic selectors. This flag causes the remote address of the packet matching IPsec SA traffic selectors to be propagated to the IPsec tunnel encapsulation. Secondly, the GKM Subsystem needs to signal that destination address preservation is in effect for a particular IPsec SA. The GKM protocol MUST define an attribute that signals destination address preservation to the GKM Subsystem on an IPsec security gateway. - IP multicast routing protocols also typically create multicast distribution trees based on the source address. If an IPsec security gateway changes the source address of an IP multicast packet (e.g., to its own IP address), the resulting IPsec protected packet may fail RPF checks on other routers. A failed RPF check may result in the packet being dropped. To accommodate routing protocol RPF checks, the GKM Subsystem on a security gateway implementation implementing the IPsec multicast extensions must preserve the original packet IP source address as follows. Firstly, the GSPD-S entry for the traffic selectors must have the Source Address PFP flag set. This flag causes the remote address to be propagated to the IPsec SA. Secondly, the GKM Subsystem needs to signal that source address preservation is in effect for a particular IPsec SA. The GKM Subsystem MUST define a protocol attribute that signals source address preservation to the GKM Subsystem on an IPsec security gateway. Some applications of address preservation may only require the destination address to be preserved. For this reason, the specification of destination address preservation and source address preservation are separated in the above description. 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, tunnel processing semantics described in RFC 4301 MUST be followed. In summary, retaining both the IP source and destination addresses of the inner IP header allow IP multicast routing protocols to route the packet irrespective of the packet being IPsec protected. This result is necessary in order for the multicast extensions to allow a security gateway to provide IPsec services for IP multicast packets. This variation of RFC4301 tunnel mode is known as "tunnel mode with address preservation". Weis, et al. Expires December, 2006 [Page 7] Internet-Draft Multicast Extensions to RFC 4301 June, 2006 4. Security Association 4.1 Major IPsec Databases The following sections describe the GKM Subsystem and IPsec extension interactions with the major IPsec databases. The major IPsec databases needed 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 implementing both unicast security associations as defined by RFC4301 and the multicast extensions defined by this specification. A new Group Security Policy Database (GSPD) attribute is introduced: GSPD entry directionality. Directionality can take three types. Each GSPD entry can be marked "symmetric", "sender only" or "receiver only". Symmetric GSPD entries are the common entries as specified by RFC 4301. Symmetric SHOULD be the default directionality unless specified otherwise. 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 SHOULD be put in GSPD-O only. Reciprocally, if the type is receiver only, the entry SHOULD go to GSPD-I only. SSM is supported by the use of unicast IP address selectors as documented in RFC 4301. GSPD entries created by a GCKS may be assigned identical SPIs to SPD 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 RFC 4301 section 4.1. In addition, SAs with identical SPI values but not manually keyed can be differentiated because they contain a link to their parent SPD entries. However, the outbound traffic needs to be matched against the GSPD selectors so that the appropriate SA can be created on packet arrival. IPsec implementations that support multicast MUST use the destination address as the additional selector and match it against the GSPD entries marked "sender only". To facilitate dynamic group keying, the outbound GSPD MUST implement a policy action capability that triggers a GKM protocol registration exchange (as per [RFC4301] section 5.1). For example, the Group Speaker GSPD policy might trigger on a match with a specified multicast application packet. The ensuing Group Speaker registration exchange would setup the Group Speaker's outbound SAD entry that encrypts the multicast application's data stream. In the inverse direction, group policy may also setup an inbound IPsec SA. At the Group Receiver endpoint(s), the GSPD policy might trigger on a match with the multicast application packet sent from the Group Speaker. The ensuing Group Receiver registration exchange would setup the Group Receiver's inbound SAD entry that decrypts the multicast Weis, et al. Expires December, 2006 [Page 8] Internet-Draft Multicast Extensions to RFC 4301 June, 2006 application's data stream. In the inverse direction, the group policy may also setup an outbound IPsec SA (e.g. when supporting an ASM service model). The IPsec subsystem MAY provide GSPD policy mechanisms (e.g. trigger on detection of IGMP/MLD leave group exchange) that automatically initiate a GKM protocol de-registration exchange. De-registration minimizes exposure of the group's secret key. It also minimizes cost for those groups that incur cost on the basis of membership duration. Alternatively, the GKM subsystem MAY setup the GSPD/SAD state information independent of the multicast application's state. In this scenario, the group's Group Owner issues management directives that tells 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. 4.1.2 Security Association Database (SAD) The Security Association Database (SAD) can support multicast SAs, if manually configured. An outbound multicast SA has the same structure as a unicast SA. The source address is that of the Group Speaker and the destination address is the multicast group address. An inbound multicast SA must be configured with the source addresses of each Group Speaker peer authorized to transmit to the multicast SA in question. The SPI value for a multicast SA is provided by a GCKS, not by the receiver as occurs for a unicast SA. Other than the SPI assignment and the inbound packet de-multiplexing described in RFC4301 section 4.1, the SAD behaves identically for unicast and multicast security associations. 4.1.3 Peer Authorization Database (PAD) The Peer Authorization Database (PAD) needs to be extended in order to accommodate peers that may take on specific roles in the group. Such roles can be GCKS, Group Speaker (in case of SSM) or a Group Receiver. A peer can have multiple roles. The PAD may also contain root certificates for PKI used by the group. 4.1.3.1 GKM/IPsec Interactions with the PAD The RFC 4301 section 4.4.3 introduced the PAD. In summary, the PAD manages the IPsec entity authentication mechanism(s) and authorization of each such peer identity to negotiate modifications to the GSPD/SAD. Within the context of the GKM/IPsec subsystem, the PAD defines for each group: Weis, et al. Expires December, 2006 [Page 9] Internet-Draft Multicast Extensions to RFC 4301 June, 2006 . For those groups that authenticate identities using a Public Key Infrastructure, the PAD contains the group's set of one or more trusted root public key certificates. The PAD may also include the PKI configuration data needed to retrieve supporting certificates needed for an end entity's certificate path validation. . A set of one or more group membership authorization rules. The GCKS examines these rules to determine a candidate group member's acceptable authentication mechanism and to decide whether that candidate has the authority to join the group. . A set of one or more GCKS role authorization rules. A group member uses these rules to decide which systems are authorized to act as a GCKS for a given group. These rules also declare the permitted GCKS authentication mechanism(s). . A set of one or more Group Speaker role authorization rules. In some groups the group members allowed to send protected packets is restricted. Some GKM protocols (e.g. GSAKMP [GSAKMP]) distribute their group's PAD configuration in a security policy token [COREPT] signed by the group's policy authority, also known as the Group Owner (GO). Each group member receives the policy token (using a method not described in this memo) and verifies the Group Owner's signature on the policy token. If that GO signature is accepted, then the group member dynamically updates its PAD with the policy token's contents. The PAD MUST provide a management interface capability that allows an administrator to enforce that the scope of a GKM group's policy specified GSPD/SAD modifications are restricted to only those traffic data flows that belong to that group. This authorization MUST be configurable at GKM group granularity. In the inverse direction, the PAD management interface MUST provide a mechanism(s) to enforce that IKEv2 security associations do not negotiate traffic selectors that conflict or override GKM group policies. An implementation SHOULD offer PAD configuration capabilities that authorize the GKM policy configuration mechanism to set security policy for other aspects of an endpoint's GSPD/SAD configuration, not confined to its group security associations. This capability allows the group's policy to inhibit the creation of back channels that might otherwise leak confidential group application data. 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-key mechanisms must be multicast. For example, [ZLLY03] describes a method of re-key employing both unicast and multicast messages. 4.2 Group Security Association (GSA) Weis, et al. Expires December, 2006 [Page 10] Internet-Draft Multicast Extensions to RFC 4301 June, 2006 An IPsec implementation supporting these extensions has a number of security associations: one or more IPsec SAs, and one or more GKM SAs used to download IPsec SAs [RFC3740, Section 4]. These SAs are collectively referred to as a Group Security Association (GSA). 4.2.4.1 Concurrent IPsec SA Life Spans and Re-key Rollover During a cryptographic group's lifetime, multiple IPsec security associations can exist concurrently. This occurs principally due to two reasons: - There are multiple Group Speakers authorized in the group, each with its own IPsec SA that 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 Speakers. - The life spans of a Group Speaker'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". Each group re-key multicast message sent by a GCKS signals the start of a new Group Speaker time epoch, with each such epoch having an associated IPsec SA. The group membership interacts with these IPsec SAs as follows: - As a precursor to the Group Speaker beginning its re-key rollover continuity processing, the GCKS periodically multicasts a Re-Key Event (RKE) message to the group. The RKE multicast contains group policy directives, and new IPsec SA policy and keying material. In the absence of a reliable multicast transport protocol, the GCKS may re-transmit the RKE a policy defined number of times to improve the availability of re-key information. - The RKE multicast configures 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 keys it. For a short period after the GCKS multicasts the RKE, a Group Speaker does not yet transmit data using the leading edge IPsec SA. Meanwhile, other Group Members prepare to use this IPsec SA by installing the new IPsec SAs to their respective GSPD/SAD. - After waiting a sufficiently long enough period such that all of the Group Members have processed the RKE multicast, the Group Speaker begins 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. The time delay that a Group Speaker waits before starting its first leading edge SA transmission is a GKM/IPsec policy parameter. This Weis, et al. Expires December, 2006 [Page 11] Internet-Draft Multicast Extensions to RFC 4301 June, 2006 value SHOULD be configurable at the Group Owner management interface on a per group basis. - The Group Speaker's "trailing edge" SA is the oldest security association in use by the group for that speaker. All authorized Group Members can receive and decrypt data for this SA, but the Group Speaker does not transmit new data using the "trailing edge" SA after it has transitioned to the "leading edge GSA". The trailing edge SA is deleted by the group's endpoints according to group policy (e.g., after a defined period has elapsed)" This re-key rollover strategy allows the group to drain its in transit datagrams from the network while transitioning to the leading edge 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 Speaker 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) 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 SA per Group Speaker and 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. But MAC authentication methods 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 distributed from a GKCS, an authentication transform where the originator keeps a secret should be used. Two possible algorithms are 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 an HMAC authentication method. To protect against denial of service attacks from device that is not authorized to join the group, the IPsec SA using this algorithm may be encapsulated with an IPsec SA Weis, et al. Expires December, 2006 [Page 12] Internet-Draft Multicast Extensions to RFC 4301 June, 2006 using a MAC authentication algorithm. However, doing so requires the packet to be sent across the IPsec boundary for additional inbound processing [RFC4301, Section 5.2]. This use of ESP encapsulated within ESP accommodates the constraint that an ESP trailer defines an Integrity Check Value (ICV) for only a single authenticator transform. Relaxing this constraint on the use of the ICV field is an area for future standardization. 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-outbound cache and the GSPD-inbound 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 [RFC4303, Section 2.1] for further explanation. The Peer Authorization Database does require explicit coordination between the GKM protocol and IKEv2. Section 4.1.3 describes these interactions. 4.4.2 New Security Association Attributes A number of new security association attributes are defined in this document. Each GKM protocol supporting this architecture MUST support the following list of attributes described elsewhere in this document. - Address Preservation (Section 3.1). This attribute describes whether address preservation is to be applied to the SA on the source address, destination address, or both source and destination addresses. - Direction attribute (Section 4.1.1). This attribute describes whether the GSPD direction is to be symmetric, receiver only, or sender only. - Specification of UDP Encapsulation (Section 6.1.4.2). This attribute declares that the UDP encapsulation of IPsec ESP packets [RFC 3948] will be used as part of an ESP SA. Weis, et al. Expires December, 2006 [Page 13] Internet-Draft Multicast Extensions to RFC 4301 June, 2006 - Any of the cryptographic transform-specific parameters and keys that are sent from the GCKS to the Group Members (e.g. data origin authentication parameters as described in section 4.3). 5. IP Traffic Processing Processing of traffic follows [RFC4301, Section 5], with the additions described below when these IP multicast extensions are supported. 5.1 Outbound IP Multicast 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 is marked as being preserved. If the source address is marked as being preserved, during header construction the "src address" header field MUST be "copied from inner hdr" rather than "constructed" as described in [RFC4301]. Similarly, if the destination address is marked as being preserved, during header construction the "dest address" header field MUST be "copied from inner hdr" rather than "constructed". 5.2 Inbound IP Multicast Traffic Processing If an IPsec SA is marked as supporting tunnel mode with address preservation (as described in Section 3.0), the marked address (i.e., source and/or destination address) on the outer IP header MUST be verified to be the same value as the inner IP header. If the addresses are not consistent, the IPsec system MUST treat the error in the same manner as other invalid selectors, as described in [RFC4301, Section 5.2]. In particular the IPsec system MUST discard the packet, as well as treat the inconsistency as an auditable event. 6. IP-v4 Network Address Translation With the advent of NAT and mobile Nodes, IPsec multicast applications must overcome several architectural barriers to their successful deployment. This section surveys those problems and identifies the GSPD/SAD state information that the GKM protocol must synchronize across the group membership. 6.1 GSPD Losses Synchronization with Internet Layer's State The most prominent problem facing GKM protocols supporting IPsec is that the GKM protocol's group security policy mechanism can inadvertently configure the group's GSPD traffic selectors with unreliable transient IP addresses. The IP addresses are transient because of either Node mobility or Network Address Translation (NAT), both of which can unilaterally change a multicast speaker's source IP address without signaling the GKM protocol. The absence of a GSPD Weis, et al. Expires December, 2006 [Page 14] Internet-Draft Multicast Extensions to RFC 4301 June, 2006 synchronization mechanism can cause the group's data traffic to be discarded rather than processed correctly. 6.1.1 Mobile Multicast Care-Of Address Route Optimization Both Mobile IPv4 [RFC3344] and Mobile IPv6 provide transparent unicast communications to a mobile Node. However, comparable support for secure multicast mobility management is not specified by these standards. The goal is the ability to maintain an end-to-end transport mode group SA between a Group Speaker mobile node that has a volatile care-of-address and a Group Receiver membership that also may have mobile endpoints. In particular, there is no secure mechanism for route optimization of the triangular multicast path between the correspondent Group Receiver Nodes, the home agent, and the mobile Node. Any proposed solution must be secure against hostile re-direct and flooding attacks. 6.1.2 NAT Translation Mappings Are Not Predictable The following spontaneous NAT behaviors adversely impact source- specific secure multicast groups. When a NAT gateway is on the path between a Group Speaker residing behind a NAT and a public IPv4 multicast Group Receiver, the NAT gateway alters the private source address to a public IPv4 address. This translation must be coordinated with every Group Receiver's inbound GSPD multicast entries that depend on that source address as a traffic selector. One might mistakenly assume that the GCKS could set up the Group Members with an GSPD entry that anticipates the value(s) that the NAT translates the packet's source address. However, there are known cases where this address translation can spontaneously change without warning: - NAT gateways may re-boot and lose their address translation state information. - The NAT gateway may de-allocate its address translation state after an inactivity timer expires. The address translation used by the NAT gateway after the resumption of data flow may differ than that known to the GSPD selectors at the group endpoints. - The GCKS may not have global consistent knowledge of a group endpoint's current public and private address mappings due to network errors or race conditions. For example, a Group Member's address may change due to a DHCP assigned address lease expiration. - Alternate paths may exist between a given pair of Group Members. If there are parallel NAT gateways along those paths, then the address translation state information at each NAT gateway may produce different translations on a per packet basis. Weis, et al. Expires December, 2006 [Page 15] Internet-Draft Multicast Extensions to RFC 4301 June, 2006 The consequence of this problem is that the GCKS can not be pre- configured with NAT mappings, as the GSPD at the Group Members will lose synchronization as soon as a NAT mapping changes due to any of the above events. In the worst case, Group Members in different sections of the network will see different NAT mappings, because the multicast packet traversed multiple NAT gateways. 6.2 Secondary Problems Created by NAT Traversal 6.2.1 SSM Routing Dependency on Source IP Address Source-Specific Multicast (SSM) routing depends on a multicast packet's source IP address and multicast destination IP address to make a correct forwarding decision. However, a NAT gateway alters that packet's source IP address as its passes from a private network into the public network. Mobility changes a Group Member's point of attachment to the Internet, and this will change the packet's source IP address. Regardless of why it happened, this alteration in the source IP address makes it infeasible for transit multicast routers in the public Internet to know which SSM speaker originated the multicast packet, which in turn selects the correct multicast forwarding policy. 6.2.2 ESP Cloaks Its Payloads from NAT Gateway When traversing NAT, application layer protocols that contain IPv4 addresses in their payload need the intervention of an Application Layer Gateway (ALG) that understands that application layer protocol [RFC3027] [RFC3235]. The ALG massages the payload's private IPv4 addresses into equivalent public IPv4 addresses. However, when encrypted by end-to-end ESP, such payloads are opaque to application layer gateways. When multiple Group Speakers reside behind a NAT with a single public IPv4 address, the NAT gateway can not do UDP or TCP protocol port translation (i.e. NAPT) because the ESP encryption conceals the transport layer protocol headers. The use of UDP encapsulated ESP [RFC3948] avoids this problem. However, this capability must be configured at the GCKS as a group policy, and it must be supported in unison by all of the group endpoints within the group, even those that reside in the public Internet. 6.2.3 UDP Checksum Dependency on Source IP Address An IPsec subsystem using UDP within an ESP payload will encounter NAT induced problems. The original IPv4 source address is an input parameter into a receiver's UDP pseudo-header checksum verification, yet that value is lost after the IP header's address translation by a transit NAT gateway. The UDP header checksum is opaque within the encrypted ESP payload. Consequently, the checksum can not be Weis, et al. Expires December, 2006 [Page 16] Internet-Draft Multicast Extensions to RFC 4301 June, 2006 manipulated by the transit NAT gateways. UDP checksum verification needs a mechanism that recovers the original source IPv4 address at the Group Receiver endpoints. In a transport mode multicast application GSA, the UDP checksum operation requires the origin endpoint's IP address to complete successfully. In IKEv2, this information is exchanged between the endpoints by a NAT-OA payload (NAT original address). See also reference [RFC3947]. A comparable facility must exist in a GKM protocol payload that defines the multicast application GSA attributes for each Group Speaker. 6.2.4 Cannot Use AH with NAT Gateway The presence of a NAT gateway makes it impossible to use an Authentication Header, keyed by a group-wide key, to protect the integrity of the IP header for transmissions between members of the cryptographic group. 6.3 Avoidance of NAT Using an IPv6 Over IPv4 Network A straightforward and standards-based architecture that effectively avoids the GKM protocol interaction with NAT gateways is the IPv6 over IPv4 transition mechanism [RFC2529]. In IPv6 over IPv4 (a.k.a. "6over4"), the underlying IPv4 network is treated as a virtual multicast-capable Local Area Network. The IPv6 traffic tunnels over that IPv4 virtual link layer. Applying GKM/IPsec in a 6over4 architecture leverages the fact that an administrative domain deploying GKM/IPsec would already be planning to deploy IPv4 multicast router(s). The group's IPv6 multicast routing can execute in parallel to IPv4 multicast routing on that same physical router infrastructure. In particular, IPv6 multicast routers operating with 6over4 mode enabled on their network interfaces replaces the NAT gateways at administrative domain public/private boundaries. Within the GKM subsystem, all references to IP addresses are IPv6 addresses for all security association endpoints and these addresses do not change over the group's lifetime. This yields a substantial reduction in complexity and error cases over the NAT-based approaches. This reduction in complexity can translate into better security. Reliable scalable GKM/IPsec based on 6over4 deployment is far more practical than an IPv4 with NAT deployment. In particular, new GKM/IPsec multicast applications SHOULD prefer IPv6 native mode. However, the GKM/IPsec architecture supports either choice. The following factors may weigh against the decision to deploy GKM/IPsec using 6over4: Weis, et al. Expires December, 2006 [Page 17] Internet-Draft Multicast Extensions to RFC 4301 June, 2006 - A drawback of the GKM/IPsec 6over4 approach is that the application layer protocol itself must embed references to IPv6 addresses rather than IPv4 addresses within its payloads. For new applications, this may not be of consequence; it usually only becomes an issue if the application and its protocol has an embedded base. - An embedded base of GKM/IPsec IPv4 multicast applications that are only available in binary form will not be able to migrate to these transitional IPv6 mechanisms. - The secondary drawbacks of GKM/IPsec using 6over4 are that the IP hosts must be upgraded to dual-stack, the attendant overlay IPv6 multicast network operational costs, and the perceived difficulty of deploying commercial wide-area IPv6 multicast services. 6.4 GKM/IPsec Multi-Realm IPv4 NAT Architecture In a multi-realm group, GKM/IPsec security association endpoints may straddle any combination of IPv4 public addresses and private addresses [RFC1918]. In such cases, transport layer endpoint identifiers when resolved to their underlying private or public IPv4 addresses entangle the GKM protocol with NAT gateway behaviors. The NAT translation of IPv4 header addresses impacts the GKM protocol registration SA, the GKM protocol re-key GSA, and the secure multicast application GSA. This section overviews the GKM/IPsec mechanisms that partially mitigate the inherent complexity spawned by IPv4 NAT and Network Address Protocol Translation (NAPT) traversal. However, the attendant Group Owner configuration procedures are labor-intensive, prone to configuration mismatch errors between the GCKS and NAT gateways, and they do not scale well to large groups. Given the large number of documented NAT problems and its erosion of end-to-end security, new GKM/IPsec applications and deployments SHOULD strongly prefer the use of IPv6. 6.4.1 GKM/IPsec IPv4 NAT Architectural Assumptions To make the multi-realm GKM/IPsec IPv4 NAT interaction problem tractable to a solution, this specification profiles the available options with the following simplifying assumptions: - The secure multicast group destination address is a statically allocated public IPv4 multicast address known to all group endpoints. - Wherever they are present in the GKM subsystem, group endpoint addresses are expressed as permanent IP-v6 "6to4" addresses [RFC3056] to assure that the group endpoints that refer to hosts Weis, et al. Expires December, 2006 [Page 18] Internet-Draft Multicast Extensions to RFC 4301 June, 2006 assigned private IPv4 addresses are globally unique. In this context, a "permanent" 6to4 address means that the address is constant for the group's lifetime. - Each private IPv4 address space has one or more NAT gateways directly connected to the IPv4 public Internet, and a packet does not have to traverse multiple private networks to reach the public Internet. This can be thought of as a "spoke and hub" configuration wherein the public Internet is the hub. - A GCKS may reside within one of the private networks, but it also MUST have a permanent public IPv4 address on at least one of its network interfaces. - Since the one or more GCKS are constrained to straddle a public/private network boundary, GKM/IPsec group security associations effectively terminate the GSA at a combined NAT/security gateway [RFC2709]. - The GCKS domain name RR record should point to that public IPv4 address, and it is recommended that it be protected by DNS-SEC. - The inbound NAT gateway will forward a Group Speaker's multicast traffic from the public Internet to the private network so long as at least one Group Receiver within the private network has joined the Group Speaker's multicast group. The Group Receiver(s) use IGMP-v3 to signal their interest in a group's traffic to the administrative domain's multicast routers, at least one of which is an ingress NAT gateway. Alternatively, in simple private networks without multicast routers, the Group Receivers send their IGMP-v3 packets directly to the NAT gateway [BEHAVE] acting in the role of an IGMP-v3 proxy. The NAT gateway redirects the IGMP-v3 packets to a multicast router in the public Internet. - Group Members also use IGMP-v3 to join the GKM protocol's re-key SA multicast group if that group has been assigned a different destination multicast IP address than the multicast application group. - In the outbound direction, NAT gateways generally translate the Group Speaker packet's private source IP address into a dynamically selected public IP address. Exceptions to this policy for source specific multicast are noted in subsequent sections. - Within each administrative domain, a multicast routing protocol domain routes packets based on the group's destination multicast public IPv4 address. The multicast routers will distribute the group's packets to all of the group's Group Receiver endpoints residing in that administrative domain. Weis, et al. Expires December, 2006 [Page 19] Internet-Draft Multicast Extensions to RFC 4301 June, 2006 - The border routers of each of the administrative domains spanned by the group do cross-realm multicast routing and distribution on behalf of the group. The IP-v4 multicast routers that exchange reachability information regarding the group across trust boundaries authenticate that information. 6.4.2 Multicast Application GSA NAT Traversal Unlike the GKM protocol rekey message multicast to the Re-Key GSA, a multicast application message sent to the group may originate from a Group Speaker endpoint located behind a NAT gateway. Since the application's message is encrypted within an ESP payload, the transport layer protocol header port fields are concealed from NAT gateways and they cannot participate in NAPT. The multicast application GSA must be handled differently depending on whether the application requires source-specific multicast. If the application requires source-specific multicast routing, then there must be a separate public IP-v4 address statically reserved at the NAT gateway for each Group Speaker endpoint private/public address mapping. This constraint allows the GCKS to specify at every Group Member the inbound GSPD traffic selector with a pre-determined public source address for each Group Speaker endpoint in the group. The traffic selector's public source address in combination with the group's destination multicast address and SPI selects the inbound SA. Keeping the NAT gateway's source address mapping static rather than dynamic also allows the multicast routers along the packet's path to apply source-specific routing policies. Note that the use of a static source address mapping NAT avoids the need for the group's policy token to specify UDP encapsulated ESP. The drawback of this approach is that the GCKS GSPD/SAD configuration database must be kept synchronized with the group's NAT gateway address mapping configurations. These operational procedures can be labor-intensive and error-prone, making large-scale group deployments difficult. A more sophisticated GKM subsystem may sidestep this problem by dynamically setting the Group Receiver endpoint's GSPD/SAD entry traffic selector rather than relying on static GCKS configuration. If the application requires the any-source multicast service model, then the NAT gateway's source address translation can use dynamically allocated public IPv4 addresses rather than statically allocated IPv4 addresses. However, unless the group uses UDP encapsulated ESP, then the NAT gateway must have a pool of public IPv4 addresses reserved that is at least as large as the number of Group Speaker endpoints within its private network. The public IP address pool allows the NAT gateway to do a one-to-one mapping from every Group Speaker endpoint's private source address to a dynamically allocated public source address. In this case, the use of NAPT rather than NAT is not Weis, et al. Expires December, 2006 [Page 20] Internet-Draft Multicast Extensions to RFC 4301 June, 2006 an option, since the transport layer protocol is within an opaque ESP payload. The GCKS specifies the SPD/SAD traffic selector as the combination of the group's destination multicast address and the SPI. In some deployments, the number of public IPv4 addresses assigned to a NAT gateway is very limited (e.g. only one public IPv4 address). Also, it may be difficult to predict how many Group Speaker endpoints will reside within the private network before the group begins its operation. For these cases, the group MAY use UDP encapsulated ESP. The NAT gateway applies NAPT to the UDP header's source port field, sidestepping the constraint of its limited public IPv4 address pool. The Group Owner modifies the group policy to specify that the outbound GSPD processing must pre-append a UDP header in front of the ESP header. When a Group Speaker endpoint originates a multicast application packet, it inserts a UDP header in front of the ESP header, as per reference [RFC3948]. 6.5 ESP Encapsulated by UDP in a Multicast Group To be supplied. 7. Security Considerations This document describes architecture for securing group network traffic using IPsec. As such, security considerations are found throughout this document. [BEW: Need to expand.] 8. IANA Considerations This document has no actions for IANA. 9. Acknowledgements [TBD] 10. References 10.1 Normative References [RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC 1112, August 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997. [RFC3552] Rescorla, E., et. al., "Guidelines for Writing RFC Text on Security Considerations", RFC 3552, July 2003. Weis, et al. Expires December, 2006 [Page 21] Internet-Draft Multicast Extensions to RFC 4301 June, 2006 [RFC3948] Huttenen, A., et. al., "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005. [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 2004. 10.2 Informative References [COREPT] Colegrove, A., and H. Harney, "Group Security Policy Token v1", (work in progress), draft-ietf-msec-policy-token-sec-06.txt (work in progress), January 2006. [GSAKMP] H. Harney, Colegrove A. , U. Meth, and G. Gross.; "Group Secure Association Key Management Protocol (GSAKMP)", (work in progress), draft-ietf-msec-gsakmp-sec-10.txt, January 2006. [RFC3306] B. Haberman, D. Thaler, " Unicast-Prefix-based IPv6 Multicast Addresses", RFC3306, August 2002. [RFC3307] B. Haberman, " Allocation Guidelines for IPv6 Multicast Addresses", RFC3307, August 2002. [RFC4046] M. Bauger, L. Dondeti, R. Canetti, F. Lindholm, " Multicast Security (MSEC) Group Key Management Architecture", RFC4046, April 2005. [RFC4291] S. Deering, R. Hinden, " IP Version 6 Addressing Architecture", RFC4291, February 2006. [RFC2362] Estrin, D., et. al., "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998. [RFC2526] Johnson, D., and S. Deering., "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999. [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999. [RFC2588] Finlayson, R., "IP Multicast and Firewalls", RFC 2588, May 1999. [RFC2709] Srisuresh, P., "Security Model with Tunnel-mode IPsec for NAT Domains", RFC 2709, October 1999. [RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914, September 2000. Weis, et al. Expires December, 2006 [Page 22] Internet-Draft Multicast Extensions to RFC 4301 June, 2006 [RFC3027] Holdrege, M., and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001. [RFC3171] Albanni, Z., et. al., "IANA Guideli nes for IPv4 Multicast Ad dress Assign ments", RFC 3171, August 2001. [RFC3235]Senie, D., "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, January 2002. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC3376] Cain, B., et. al., "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, December 2002. [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003. [RFC3940] Adamson, B., et. al., "Negative-acknowledgment (NACK)- Oriented Reliable Multicast (NORM) Protocol", RFC 3940, November 2004. [RFC3947] Kivinen, T., et. al., "Negotiation of NAT-Traversal in the IKE", RFC 3947, January 2005. [RFC3948] Huttunen, A., et. al., "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005. [RFC4082] Perrig, A., et. al., "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005. [RFC4306] Kaufman, C., "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. [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. See http://www.cs.utexas.edu/users/lam/Vita/Cpapers/ZLLY01.pdf. Weis, et al. Expires December, 2006 [Page 23] Internet-Draft Multicast Extensions to RFC 4301 June, 2006 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 Multi-media content delivery multicast applications that do not have congestion notification or retransmission error recovery mechanisms are inherently unidirectional. RFC 4301 only defines bi-directional unicast security associations (as per sections 4.4.1 and 5.1 with respect to security association directionality). The GKM Subsystem requires that the IPsec subsystem MUST support unidirectional Group Security Associations (GSA). 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 a SAD entry, and the GSPD configuration is optionally setup to discard unauthorized attempts to transmit unicast or multicast packets to the group. The GKM Subsystem's management interface MUST have the ability to setup 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 speaker to many receivers, but with inverse data flows required by a reliable multicast transport protocol (e.g. NORM). In such applications, the data flow from the speaker is multicast, and the inverse flow from the group's receivers is unicast to the speaker. Typically, the inverse data flows carry error repair requests and congestion control status. For such applications, the GSA SHOULD use IPsec anti-replay protection service for the speaker'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 Weis, et al. Expires December, 2006 [Page 24] Internet-Draft Multicast Extensions to RFC 4301 June, 2006 GSA SHOULD be configured to only allow a unicast transmission to the speaker 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 speaker. The GKM protocol MUST define a key management mechanism for the group speaker to validate the asserted signature public key of any receiver Node without requiring that the speaker 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 setup a GKM Subsystem GSA having a bi-directional GSA security policy and one group speaker. The management interface SHOULD be able to configure a group to have at least 16 concurrent authorized speakers, each with their own GSA anti-replay state. A.3 Any-To-Any Multicast Applications Another family of secure multicast applications exhibits a "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 speakers. In such service models, creating a distinct IPsec SA with anti-replay state for every potential speaker does not scale to large groups. The group SHOULD share one IPsec SA for all of its speakers. The IPsec SA SHOULD NOT use the IPsec anti- replay protection service for the speaker's multicast data flow to the Group Receivers. The GKM Subsystem's management interface MUST have the ability to setup a group having an Any-To-Many Multicast GSA security policy. Weis, et al. Expires December, 2006 [Page 25] Internet-Draft Multicast Extensions to RFC 4301 June, 2006 Author's Address Brian Weis Cisco Systems 170 W. Tasman Drive, San Jose, CA 95134-170 USA Phone: +1-408-526-4796 Email: bew@cisco.com George Gross IdentAware Security 82 Old Mountain Road Lebanon, NJ 08833 USA Phone: +1-908-268-1629 Email: gmgross@identaware.com Dragan Ignjatic Polycom 1000 W. 14th Street North Vancouver, BC V7P 3P3 Canada Phone: +1-604-982-3424 Email: dignjatic@polycom.com Weis, et al. Expires December, 2006 [Page 26] Internet-Draft Multicast Extensions to RFC 4301 June, 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Weis, et al. Expires December, 2006 [Page 27]