view Side-By-Side changes

INTERNET-DRAFT                                George 
Internet-Draft                                            Cisco Systems 
Expires: August, 2006                                          G. Gross (IdentAware) 
draft-ietf-msec-ipsec-extensions-00.txt       Dragan 
                                                    IdentAware Security 
                                                            D. Ignjatic (Polycom) 
Expires: December, 2005                                      June, 2005 
                                                                Polycom 
                                                         February, 2006 
 
    Multicast Extensions to the Security Architecture for the Internet 
                                 Protocol  
                  draft-ietf-msec-ipsec-extensions-01.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 [RFC2401BIS] [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 IP multicast 
   packets within that Security Architecture. 





     
Weis                     Expires December, 2005 August, 2006                 [Page 1] 

              The Use of RSA Signatures with ESP and AH 

Internet-Draft     Multicast Extensions to RFC 4301         June, 2005 
    
    
Table of Contents 
    
1.0 Introduction.......................................................2 
  1.1 Scope...........................................................3 Scope............................................................3 
  1.2 Terminology......................................................3 
2.0 Overview of IP Multicast Operation.................................4 Operation.................................5 
3.0 Security Association Modes.........................................4 Modes.........................................5 
  3.1 Tunnel Mode with Address Preservation............................6 
4.0 Security Association...............................................5 Association...............................................7 
  4.1 Major IPsec Databases............................................5 Databases............................................7 
    4.1.1 SPD..........................................................5 Security Policy Database (SPD)...............................7 
    4.1.2 SAD..........................................................6 Security Association Database (SAD)..........................7 
    4.1.3 PAD..........................................................6 Peer Authorization Database (PAD)............................8 
    4.1.4 GSA..........................................................8 Group Security Association (GSA).............................9 
  4.2 Data Origin Authentication.......................................9 Authentication......................................11 
  4.3 Group SA and Key Management.....................................10 Management.....................................11 
    4.3.1 Co-Existence of Multiple Key Management Protocols...........10 Protocols...........11 
    4.3.2 New Security Association Attributes.........................12 
5.0 IP Traffic Processing.............................................10 Processing.............................................12 
  5.1 Outbound IP Multicast Traffic Processing........................10 Processing........................12 
  5.2 Inbound IP Multicast Traffic Processing.........................11 
5.0 Processing.........................12 
6.0 Networking Issues.................................................11 
  5.1 Issues.................................................12 
  6.1 Network Address Translation.....................................11 
    5.1.1 Translation.....................................13 
    6.1.1 SPD Losses Synchronization with Internet Layer's State......11 
    5.1.2 State......13 
    6.1.2 Secondary Problems Created by NAT Traversal.................12 
    5.1.3 Traversal.................14 
    6.1.3 Avoidance of NAT Using an IP-v6 IPv6 Over IP-v4 Network..........14 
    5.1.4 IPv4 Network............15 
    6.1.4 GKMP/IPsec Multi-Realm IP-v4 IPv4 NAT Architecture...............14 
6.0 Security Considerations...........................................20 Architecture................16 
7.0 Acknowledgements..................................................20 Security Considerations...........................................19 
8.0 IANA Considerations...............................................19 
9.0 Acknowledgements..................................................19 
10.0 References.......................................................19 
  10.1 Normative References...........................................19 
  10.2 Informative References.........................................20 
Appendix A - Multicast Application Service Models.................20 
  8.1 Models.....................22 
  A.1 Unidirectional Multicast Applications...........................21 
  8.2 Applications...........................22 
  A.2 Bi-directional Reliable Multicast Applications..................21 
  8.3 Applications..................22 
  A.3 Any-To-Any Multicast Applications...............................22 
9.0 References........................................................22 
  9.1 Normative References............................................22 
  9.2 Informative References..........................................22 Applications...............................23 
Author's Address......................................................24 
Full Copyright Statement..............................................24 
Intellectual Property.................................................24 Property Statement.......................................25 
Copyright Statement...................................................25 
 
1.0 Introduction 
    
   The Security Architecture for the Internet Protocol [RFC2401BIS] [RFC4301] 
   provides security services for traffic at the IP layer. It describes 
   a base 

 
Weis, et al.             Expires August, 2006                 [Page 2] 

Internet-Draft     Multicast Extensions to RFC 4301         June, 2005 
    
    
   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 IP packets IPsec Security Associations (SAs) shared 
   between two IPsec devices. Typically, this includes SAs with traffic 
   selectors that carry include a unicast address in the IP destination field, 
   and results in an IPsec packet with a unicast address in the IP 
   destination field. Those The security services defined in RFC 4301 can also 
   be used to tunnel IP multicast packets, where the tunnel is a 
 
   Weis                 Expires December, 2005                [Page 2] 

              The Use of RSA Signatures with ESP and AH    June, 2005 
   pairwise tunnel association between two IPsec devices. Some support for IP 
   packets with a multicast address in the IP destination field is 
   supported, but only with manual keying. keying, and only between IPsec 
   devices acting as hosts. 
    
   This document describes extensions to [RFC2401BIS] RFC 4301 that further define 
   the IPsec security architecture for packets 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 to remain field, and results 
   in an IPsec packet with an IP multicast packets. 
    
   [NOTE TO THE READER: The scope of the extensions proposed has not 
   been finalized. For example, there are varying opinions as to the 
   extent that this document must accommodate interoperability between 
   different group key management and policy systems, which may occur address in 
   very large groups. Comments regarding matters of scope are 
   solicited.] the IP destination 
   field. It also describes additional semantics for IPsec Group Key 
   Management Protocol (GKMP) Subsystems. 
    
1.1 Scope 
    
   The IPsec extensions described in this document support for IPsec 
   Security Associations used that result in IPsec packets with both Any-Source Multicast (ASM) IPv4 or IPv6 
   multicast group addresses as the destination address. Both Any-Source 
   Multicast (ASM) and Source-Specific Multicast (SSM) [RFC3569, RFC3376] groups.  
    
   They [RFC3569] 
   [RFC3376] group addresses are supported.  
    
   These extensions also support Security Associations with IPv4 
   Broadcast addresses, addresses that result in an IPv4 Broadcast packet, and IPv6 
   Anycast addresses [RFC2526], since [RFC2526]that result in an IPv6 Anycast packet. 
   These destination address types share many of the same 
   characteristics of multicast addresses because there are may be multiple 
   receivers defined for of a packet sent to those addresses. 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., PIM-SM [RFC2362]) or multicast 
   admission protocols (e.g., IGMP [RFC3376] to participate in IPsec. [RFC3376]. 
    
   All implementation models of IPsec (e.g., "bump-in-the-stack", "bump-
   in-the-wire") are supported. 
                              
1.2 Terminology 
    


 
Weis, et al.             Expires August, 2006                 [Page 3] 

Internet-Draft     Multicast Extensions to RFC 4301         June, 2005 
    
    
   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. 
    
   Source-Specific Multicast (SSM) 
    
      The Internet 
       
   Group Controller Key Server (GCKS) 
      A Group Key Management 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 (GKMP) server that manages IPsec 
      state for a group. This is known as an 
      (S,G) group. 
 
   Weis                 Expires December, 2005                [Page 3] 

              The Use of RSA Signatures with ESP A GCKS authenticates and AH    June, 2005 
    
    
    
2.0 Overview of IP Multicast Operation 
    
   IP multicasting is a means of sending a single packet provides the IPsec SA 
      policy and keying material to GKMP group members. 
    
   Group Key Management Protocol (GKMP) 
      A key management protocol used by a "host 
   group", GCKS to distribute IPsec 
      Security Association policy and keying material. A GKMP is used 
      when a set group of zero or more hosts identified by a single IP 
   destination address. IPsec devices require the same SAs. For example, 
      when an IPsec SA describes an IP multicast packets are UDP data packets 
   delivered with either a "best-effort" reliability to destination, the sender 
      and all members of receivers must have the group [RFC1112], or reliably (e.g., NORM) [RFC3940]. SA. 
    
   Group Key Management Protocol Subsystem 
      A sender to subsystem in an IP multicast group sets IPsec device implementing a Group Key Management 
      Protocol. The GKMP Subsystem provides IPsec SAs to the destination of IPsec 
      subsystem on the packet IPsec device. 
       
   Group Member 
      An IPsec device that belongs to an IP address allocated a group. A Group Member is 
      authorized to be used a Group Speaker and/or a Group Receiver. 
       
   Group Owner 
      An administrative entity that chooses the policy for IP multicast. Allocated IP 
   multicast addresses are defined in RFC 3171 [RFC3171]. Potential 
   receivers a group.  
       
   Group Security Association (GSA) 
      A collection of IPsec Security Associations (SAs) and GKMP 
      Subsystem SAs necessary for a Group Member to receive key updates. 
      A GSA describes the packet "join" the IP multicast group by registering 
   with working policy for a network routing device, signaling its intent group. 
       
   Group Receiver 
      A Group Member that is authorized to receive packets sent to a particular IP multicast group. 
    
   Network routing devices configured 
      group by a Group Speaker. 
       
   Group Speaker 
      A Group Member that is authorized to pass IP multicast send 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 
    

 
Weis, et al.             Expires August, 2006                 [Page 4] 

Internet-Draft     Multicast Extensions to RFC 4301         June, 2005 
    
    
   Source-Specific Multicast (SSM) 
      The Internet Protocol (IP) multicast service model as defined in 
      RFC 3569 [RFC3569]. In this model each combination of a router receives sender and 
      an IP multicast packet, it forwards address is considered a 
   copy of the packet out each interface 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.0 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]. 
    
   A sender to an IP multicast group sets the destination of the packet 
   to an IP address allocated to be used for IP multicast. Allocated IP 
   multicast addresses are defined in RFC 3171 [RFC3171]. Potential 
   receivers of the packet "join" the IP multicast group by registering 
   with a network routing device, 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.0 Security Association Modes 
    
   IPsec supports two modes of use: transport mode and tunnel mode.  In 
   transport mode, AH IP Authentication Header (AH) [RFC4302] and ESP 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 
   support use 
   both modes transport mode and tunnel mode to encapsulate an IP multicast 
   packet. These processing rules are identical to the rules described 
   in [RFC2401BIS, [RFC4301, Section 4.1]. However, the destination address for the 
   IPsec packet is an IP multicast address rather than a unicast host 
   address. 
    
 
Weis, et al.             Expires August, 2006                 [Page 5] 

Internet-Draft     Multicast Extensions to RFC 4301         June, 2005 
    
    
   A security gateway implementation of IPsec using the multicast 
   extensions MUST use a tunnel mode SA, for the reasons described in 
   [RFC2401BIS, 
   [RFC4301, Section 4.1]. In particular, the security gateway must use 
   tunnel mode to encapsulate incoming fragments.  
    
   New header 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 (such as (e.g., PIM-SM [RFC2362]). 
    
   - IP multicast routing protocols use compare the destination address on 
     a packet to decide to where the packet should be routed. multicast routing state. If the destination of an 
     IP multicast packet is changed it will no longer be properly 
     routed. To accommodate this routing requirement, Therefore, an IPsec security gateway must preserve the 
     multicast IP destination address after IPsec tunnel encapsulation. 
         
     The GKMP Subsystem may specify two actions. Firstly, on a security gateway implementing the SPD-S entry for IPsec 
     multicast extensions preserves the 
   traffic selectors must have multicast IP address as 
     follows. Firstly, the GKMP Subsystem sets the Remote Address PFP 
     flag set. in the SPD-S entry for the traffic selectors. This 
 
   Weis                 Expires December, 2005                [Page 4] 

              The Use of RSA Signatures with ESP and AH    June, 2005 flag 
     causes the remote address of the packet matching IPsec SA traffic 
     selectors to be propagated to the IPsec SA. tunnel encapsulation. 
     Secondly, a new IPsec SA attribute must be specified by the GKMP Subsystem that causes the tunnel mode header construction process needs to 
   copy the remote signal that destination 
     address preservation is in effect for a particular IPsec SA. The 
     GKMP MUST define an attribute that signals destination address 
     preservation to the SA into the tunnel header remote 
   address. GKMP Subsystem on an IPsec security gateway. 
      
   - IP multicast routing protocols also typically create multicast 
     distribution trees based on the source address. An If an IPsec 
     security gateway that changes the source address of an IP multicast 
     packet (e.g., to its own IP address), the resulting IPsec 
     protected packet may 
   cause fail RPF checks on other routers to return a different result than 
   the original plaintext IP multicast packet. As a result, multicast 
   routing routers. A failed 
     RPF check may drop result in the packet. packet being dropped.  
         
     To accommodate this routing requirement, protocol RPF checks, the GKMP Subsystem may specify two actions. on 
     a security gateway implementation implementing the IPsec multicast 
     extensions must preserve the original packet IP source address as 
     follows. Firstly, the SPD-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, a new IPsec SA attribute must be specified by the GKMP 
     Subsystem that causes the tunnel mode header construction process needs to 
   copy the signal that source address in the SA into the tunnel header remote 
   address. 
    
   Some applications of address preservation may only require is in 
     effect for a particular IPsec SA. The GKMP MUST define an 
     attribute that signals source address preservation to the remote GKMP 
     Subsystem on an IPsec security gateway. 
    
   Some applications of address preservation may only require the 
   destination address to be preserved. For this reason, the 

 
Weis, et al.             Expires August, 2006                 [Page 6] 

Internet-Draft     Multicast Extensions to RFC 4301         June, 2005 
    
    
   specification of remote destination address preservation and source address 
   preservation are separated in the above description. 
 
   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 method of tunnel mode is known as tunnel mode with address 
   preservation. 
 
    
4.0 Security Association 
 
4.1 Major IPsec Databases 
    
   The following sections describe the GKMP Subsystem and IPsec 
   extension interactions with the major IPsec databases. Major IPsec 
   databases need to be expanded in order to fully support multicast. 
    
4.1.1 SPD Security Policy Database (SPD) 
    
   A new SPD Security Policy Database (SPD) attribute is introduced - introduced: SPD 
   entry directionality. Directionality can take three types. Each SPD 
   entry can be marked 
   symmetric, sender "symmetric", "sender only" or receiver only. "receiver only". 
   Symmetric SPD entries are the common entries as specified by RFC2401bis. RFC 
   4301. Symmetric SHOULD be the default directionality unless specified 
   otherwise. SPD entries marked as sender "sender only" or receiver only "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 
 
   Weis                 Expires December, 2005                [Page 5] 

              The Use of RSA Signatures with ESP and AH    June, 2005 SHOULD be put in SPD-O only. 
   Reciprocally, if the type is receiver only, the entry SHOULD go to 
   SPD-I only. SSM is supported by the use of unicast IP address 
   selectors as documented in IPsec RFCs. RFC 4301. 
    
   SPD entries created by a GCKS may have be assigned identical SPIs as some of the 
   IKE to SPD 
   entries created ones. by IKEv2 [RFC4306]. This is not a problem for the 
   inbound traffic as the appropriate SA's SAs can be matched using the 
   algorithm described in 
   RFC2401bis and SA's RFC 4301. In addition, SAs with identical SPI 
   values but not manually keyed can be differentiated because they 
   contain a link to their parent SPD entries if 
   such an entry exists (i.e. they are not manually keyed in). entries. However, the outbound 
   traffic needs to be matched against the SPD selectors so that the 
   appropriate SA can be created on packet arrival. IPsec 
   implementations that support multicast SHOULD use the destination 
   address as the additional selector and match it against the SPD 
   entries marked sender only. "sender only". 
    
4.1.2 SAD Security Association Database (SAD) 
 
   The SAD Security Association Database (SAD) can support multicast SAs, if 
   manually configured. An outbound multicast SA has the same structure 
 
Weis, et al.             Expires August, 2006                 [Page 7] 

Internet-Draft     Multicast Extensions to RFC 4301         June, 2005 
    
    
   as a unicast SA. The source address is that of the sender and the 
   destination address is the multicast group address. An inbound, 
   multicast SA must be configured with the source addresses of each 
   peer authorized to transmit to the multicast SA in question. The SPI 
   value for a multicast SA is provided by a multicast group controller, GCKS, not by the receiver, 
   as for a unicast SA. Because an SAD entry may be required This is similar to accommodate multiple, individual IP source addresses that were 
   part of an SPD entry (for unicast SAs), the required facility for 
   inbound, multicast SAs is a feature already present in an IPsec 
   implementation. unicast case and does not 
   require changes to SAD. 
   However, the SPD needs provisions a mechanism for accommodating 
   multicast entries in order to enable automatic multicast SA 
   creation. 
    
   PAD 
    
    
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, speaker Group Speaker (in case of SSM) or just a member. It Group 
   Receiver. A peer can have multiple roles. The PAD may also contain 
   root certificates for PKI used by the group. 
    
4.1.2.1 Anti-Replay for Multi-Sender SAs 
    
   TBD 
    
4.1.3 PAD 
    
4.1.3.1 GKMP/IPsec Interactions with the PAD 
 
   The RFC2401-bis RFC 4301 section 4.4.3 introduced the Peer Authorization 
   Database (PAD).  PAD. In summary, the PAD 
   manages the IPsec entity authentication mechanism(s) and 
   authorization of each such peer identity to negotiate modifications 
   to the SPD/SAD. Within the context of the GKMP/IPsec subsystem, the 
   PAD defines for each group: 
    

 
   Weis                 Expires December, 2005                [Page 6] 

              The Use of RSA Signatures with ESP and AH    June, 2005 
    
   . 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 GKCS 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. A GCKS 
     uses these rules to authorize candidate group members that request 
     the speaker privilege. For an authorized speaker, the GCKS creates 
     a GSA description, and a subsequent RKE multicast configures that 
     speaker's GSA in In 
     some groups the group SPD/SAD. members allowed to send protected packets is 
     restricted. 

   Some GKMP (e.g. 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). The GCKS re-key 
   multicast includes the current policy token. At each of the group's 
   endpoints, the GKMP subsystem is statically pre-configured with the Group Owner's signature public key certificate or else the 
   information needed to acquire that certificate. All authorized Owner (GO). Each group 
   members receive member 
 
Weis, et al.             Expires August, 2006                 [Page 8] 

Internet-Draft     Multicast Extensions to RFC 4301         June, 2005 
    
    
   receives the GCKS re-key multicast policy token (using a method not described in this memo) 
   and verify verifies the Group Owner's signature on the revised policy token. If that 
   GO signature is accepted, then all the group members member dynamically update their 
   respective updates 
   its PAD with the policy token's contents. 
    
   All compliant IPsec subsystems MUST provide a trusted mechanism for a 
   GKMP subsystem to update the PAD's per group configuration as 
   described in the above list. The details of that trusted mechanism 
   are implementation-specific and they are outside the scope of this 
   standardization. 
    
   The PAD MUST provide a management interface capability that allows an 
   administrator to enforce that the scope of a GKMP group's policy 
   specified SPD/SAD modifications are restricted to only those traffic 
   data flows that belong to that group. This authorization MUST be 
   configurable at GKMP group granularity. In the inverse direction, the 
   PAD management interface MUST provide a mechanism(s) to enforce that 
   IKE-v2 
   IKEv2 security associations do not negotiate traffic selectors that 
   conflict or override GKMP group policies. An implementation SHOULD 
   offer PAD configuration capabilities that authorize the GKMP policy 
   configuration mechanism to set security policy for other aspects of 
   an endpoint's SPD/SAD configuration, not confined to its group 
   security associations. This capability allows the group's policy to 
 
   Weis                 Expires December, 2005                [Page 7] 

              The Use of RSA Signatures with ESP and AH    June, 2005 
   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.1.4 GSA Group Security Association (GSA) 
    
   A IPsec implementation supporting these extensions has a number of 
   security associations: one or more IPsec SAs, and one or more group 
   key management GKMP 
   SAs used to download IPsec SAs [RFC3740, Section 4]. These SAs are 
   collectively referred to as a GSA. Group Security Association (GSA). 
 
4.1.4.1 Concurrent GSA IPsec SA Life Spans and Re-key Rollover 
 
   During a cryptographic group's lifetime, multiple group 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 GSA IPsec SA that maintains anti-replay state. A group 
     that does not rely on IP Security anti-replay services can share 
     one 
       GSA IPsec SA for all of its Group Speakers. 

   - The life spans of a Group Speaker's two (or more) GSA 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". 


 
Weis, et al.             Expires August, 2006                 [Page 9] 

Internet-Draft     Multicast Extensions to RFC 4301         June, 2005 
    
    
   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 GSA. The group membership interacts with these GSA 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 
     membership management directives (e.g. LKH), a new Group Traffic 
     Protection Key (GTPK), 
     policy directives, and for some GKMP the RKE may include a 
     revised group new IPsec SA policy token. 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 SPD/SAD with the new IPsec 
     SAs. Each IPsec SA that replaces an existing SA is called a 
     "leading edge" GSA state information. IPsec SA. The leading edge GSA 
     allocates IPsec SA has a new 
     Security Parameter Index (SPI) and it is keyed by the 
     GTPK distributed by the most recent RKE multicast. its associated 
     keying material. For a short 
 
   Weis                 Expires December, 2005                [Page 8] 

              The Use of RSA Signatures with ESP and AH    June, 2005 period after the GCKS multicasts the 
     RKE, a Group Speaker does not yet transmit data using the leading 
     edge GSA. IPsec SA. Meanwhile, the other Group 
     Receiver endpoints Members prepare to use this GSA 
     IPsec SA by installing the RKE 
     directed changes new IPsec SAs to their respective 
     SPD/SAD. 

  - After waiting a sufficiently long enough period such that all of 
     the Group Receiver endpoints Members have processed the RKE multicast, the Group 
     Speaker begins to transmit using the leading edge GSA IPsec SA with its 
     data encrypted by the new GTPK. keying material. Only authorized Group 
     Members can decrypt these GSA IPsec SA multicast transmissions. The 
     time delay that a Group Speaker waits before starting its first 
     leading edge GSA transmission is a GKMP/IPsec policy parameter. 
     This value SHOULD be configurable at the Group Owner management 
     interface on a per group basis. 

  - The Group Speaker's "trailing edge" GSA SA is the oldest group security 
     association in use by the group for that speaker. All authorized 
     Group Receiver endpoints Members can receive and decrypt data for this GSA, SA, but the 
     Group Speaker does not transmit new data using the "trailing edge" GSA 
     SA after it has transitioned to the "leading edge GSA". The 
     trailing edge GSA 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 GSA. Staggering the roles of each respective GSA 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-
 
Weis, et al.             Expires August, 2006                [Page 10] 

Internet-Draft     Multicast Extensions to RFC 4301         June, 2005 
    
    
   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 
   GKMP/IPsec implementation MUST support at least two concurrent GSA 
   per Group Speaker and this re-key rollover continuity algorithm. 
    
    
4.2 Data Origin Authentication 
    
   As defined in [RFC2401BIS], [RFC3401], data origin authentication is a security 
   service that verifies the identity of the claimed source of data. 
   While HMAC authentication methods are to often used to provide data 
   origin authentication, they are not sufficient to provide data origin 
   authentication for groups. With an HMAC, every group member can use 
   the HMAC key to create a valid authentication tag whether or not they 
   are the authentic origin. 
    
 
   Weis                 Expires December, 2005                [Page 9] 

              The Use of RSA Signatures with ESP and AH    June, 2005 
    
   When the property of data origin authentication is required for an 
   IPsec SA distributed from a GKMP, GKCS, an authentication transform where 
   the originator keeps a secret should be used. Two possible algorithms 
   are TESLA [RFC4082] or RSA [W05]. [RFC4359]. 
    
   In some cases, (e.g., RSA) 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 
   using an HMAC authentication algorithm. However, doing so requires 
   the packet to be sent across the IPsec boundary for additional 
   inbound processing [RFC2401BIS, [RFC4301, Section 5.2]. 
 
4.3 Group SA and Key Management 
    
4.3.1 Co-Existence of Multiple Key Management Protocols 
 
   Often, the GKMP will be introduced to an existent IPsec subsystem as 
   a companion key management protocol to IKE-v2 [IKE-v2]. IKEv2 [RFC4306]. A fundamental 
   GKMP IP Security subsystem requirement is that both the GKMP and IKE-
   v2 
   IKEv2 can simultaneously share access to a common Security Policy 
   Database and Security Association Database. The mechanisms that 
   provide mutually exclusive access to the common SPD/SAD data 
   structures are a local matter. This includes the SPD-outbound cache 
   and the SPD-inbound cache. However, implementers should note that 
   IKE-v2 
   IKEv2 SPI allocation is entirely independent from GKMP SPI allocation 
   because group security associations are qualified by a destination 
   multicast IP address and may optionally have a source IP address 
   qualifier. See [RFC2406-bis] section 2.1 [RFC4303, Section 2.1] for further explanation. 
    


 
Weis, et al.             Expires August, 2006                [Page 11] 

Internet-Draft     Multicast Extensions to RFC 4301         June, 2005 
    
    
   The Peer Authorization Database does require explicit coordination 
   between the GKMP and IKE-v2. IKEv2. Section X.Y 4.1.3 describes these 
   interactions. This document discusses the coordination 
    
4.3.2 New Security Association Attributes 
    
   A number of multiple new security association attributes are defined in this 
   document. Each GKMP group owner and endpoint local management systems supporting this architecture MUST support the 
   following list of attributes described elsewhere in section 
   4.11. 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 SPD direction is to be symmetric, receiver only, or 
   sender only. 
         
5.0 IP Traffic Processing 
    
   Processing of traffic follows [RFC2401BIS, [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.0), 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 
   [RFC2401BIS]. [RFC4301]. 
   Similarly, If the destination address is marked as 
 
   Weis                 Expires December, 2005               [Page 10] 

              The Use of RSA Signatures with ESP and AH    June, 2005 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 
   [RFC2401BIS, 
   [RFC4301, Section 5.2]. In particular the IPsec system MUST discard 
   the packet, as well as treat the inconsistency as an auditable event. 
 
5.0 
 
6.0 Networking Issues 
    
5.1 
    

 
Weis, et al.             Expires August, 2006                [Page 12] 

Internet-Draft     Multicast Extensions to RFC 4301         June, 2005 
    
    
6.1 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 
   SPD/SAD state information that the GKMP must synchronize across the 
   group membership. 
    
5.1.1 
    
6.1.1 SPD Losses Synchronization with Internet Layer's State 
 
   The most prominent problem facing GKMP IPsec is that the GKMP group 
   security policy mechanism can inadvertently configure the group's SPD 
   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 GKMP. The 
   absence of a SPD synchronization mechanism can cause the group's data 
   traffic to be discarded rather than processed correctly. 
    
5.1.1.1 
    
6.1.1.1 Mobile Multicast Care-Of Address Route Optimization 
 
   Both Mobile IP-v4 IPv4 [RFC3344] and Mobile IP-v6 [MIPV6] 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. 
    

 
   Weis                 Expires December, 2005               [Page 11] 

              The Use of RSA Signatures with ESP and AH    June, 2005 
    
    
5.1.1.2 
    
6.1.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 endpoint residing behind a NAT and a public 
   IP-v4 IPv4 
   multicast Group Receiver, the NAT gateway alters the private source 
   address to a public IP-v4 IPv4 address. This translation must be 
   coordinated with every Group Receiver's inbound Security Policy 
   Database (SPD) SPD multicast entries 
   that depend on that source address as a traffic selector. One might 
   mistakenly assume that the GC/KS GCKS could set up the group endpoints Group Members with a 
   an SPD 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 

 
Weis, et al.             Expires August, 2006                [Page 13] 

Internet-Draft     Multicast Extensions to RFC 4301         June, 2005 
    
    
  - 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 SPD selectors at the group endpoints. 

  - The GC/KS 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, an endpoint's 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 endpoints. 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. 

   The consequence of this problem is that the GC/KS GCKS can not be pre-
   configured with NAT mappings, as the SPD at the group's endpoints Group Members will 
   lose synchronization as soon as a NAT mapping changes due to any of 
   the above events. In the worst case, group endpoints Group Members in different 
   sections of the Internet network will see different NAT mappings, because the 
   multicast packet traversed multiple NAT gateways. 
    
5.1.2 
    
6.1.2 Secondary Problems Created by NAT Traversal 
 
5.1.2.1 
 
6.1.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 Internet. network. Mobility changes a Node's 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 
 
   Weis                 Expires December, 2005               [Page 12] 

              The Use of RSA Signatures with ESP and AH    June, 2005 
   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. 
    
5.1.2.2 
    
6.1.2.2 ESP Cloaks Its Payloads from NAT Gateway 
 
   When traversing NAT, application layer protocols that contain IP-v4 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 IP-v4 IPv4 
   addresses into equivalent public IP-v4 IPv4 addresses. However, when 
   encrypted by end-to-end ESP, such payloads are opaque to application 
   layer gateways.  
    
   When multiple Group Speaker endpoints Speakers reside behind a NAT with a single public IP-v4 
   IPv4 address, the NAT gateway can not do UDP or TCP protocol port 
 
Weis, et al.             Expires August, 2006                [Page 14] 

Internet-Draft     Multicast Extensions to RFC 4301         June, 2005 
    
    
   translation (i.e. NAPT) because the ESP encryption conceals the 
   transport layer protocol headers. The use of UDP encapsulated ESP [UDPESP] 
   [RFC3948] avoids this problem. However, this capability must be 
   configured at the GC/KS 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. 
    
5.1.2.3 
    
6.1.2.3 UDP Checksum Dependency on Source IP Address 
 
   A GKMP/IPsec multicast application that uses 
 
   An IPsec subsystem using UDP within an ESP payload will encounter NAT 
   induced problems. The original IP-v4 IPv4 source address is an input 
   parameter into a receiver's UDP pseudo-
   header 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 
   manipulated by the transit NAT gateways. UDP checksum verification 
   needs a mechanism that recovers the original source IP-4 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 IKE-v2 [IKE-v2], IKEv2, this information is exchanged between the 
   endpoints by a NAT-OA payload (NAT original address). See also 
   reference [IPSECNAT]. [RFC3947]. A comparable facility must be exist in a GKMP 
   payload that defines the multicast application GSA attributes for 
   each Group Speaker endpoint. 
    
5.1.2.4 Can Not Speaker. 
    
6.1.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. 
    


 
   Weis                 Expires December, 2005               [Page 13] 

              The Use of RSA Signatures with ESP and AH    June, 2005 
    
    
5.1.3 
    
6.1.3 Avoidance of NAT Using an IP-v6 IPv6 Over IP-v4 IPv4 Network 
 
   A straightforward and standards-based architecture that effectively 
   avoids the GKMP interaction with NAT gateways is the IP-v6 IPv6 over IP-v4 IPv4 
   transition mechanism [RFC2529]. In IP-v6 IPv6 over IP-v4 IPv4 (a.k.a. "6over4"), 
   the underlying IP-v4 IPv4 network is treated as a virtual multicast-capable 
   Local Area Network. The IP-v6 IPv6 traffic tunnels over that IP-v4 IPv4 virtual 
   link layer. 
    
   Applying GKMP/IPsec in a 6over4 architecture leverages the fact that 
   an administrative domain deploying GKMP/IPsec would already be 
   planning to deploy IP-v4 IPv4 multicast router(s). The group's IP-v6 IPv6 
   multicast routing can execute in parallel to IP-v4 IPv4 multicast routing 
   on that same physical router infrastructure. In particular, the NAT 
   gateways at administrative domain public/private boundaries are 
   replaced by IP-v6 IPv6 
   multicast routers operating with 6over4 mode enabled on their network interfaces. 

 
Weis, et al.             Expires August, 2006                [Page 15] 

Internet-Draft     Multicast Extensions to RFC 4301         June, 2005 
    
    
   interfaces replaces the NAT gateways at administrative domain 
   public/private boundaries. 
    
   Within the GKMP, all references to IP addresses are IP-v6 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 GKMP/IPsec based on 6over4 deployment is far more 
   practical than an IP-v4 IPv4 with NAT deployment. In particular, new 
   GKMP/IPsec multicast applications SHOULD prefer IP-v6 IPv6 native mode. 
   However, the GKMP/IPsec architecture supports either choice. The 
   following factors may weigh against the decision to deploy GKMP/IPsec 
   using 6over4: 
    
  - A drawback of the GKMP/IPsec 6over4 approach is that the secure 
     multicast application must be (re-)written to an IP-v6 multicast 
     socket API or equivalent, and it must interact with the Multicast 
     Listener Discovery (MLD) API [RFC3590] [RFC3678] rather than IGMP. 
     In addition, the 
     application layer protocol itself must embed references to IP-v6 IPv6 
     addresses rather than IP-v4 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 GKMP/IPsec IP-v4 IPv4 multicast applications that are 
     only available in binary form will not be able to migrate to these 
     transitional IP-v6 IPv6 mechanisms. 

  - The secondary drawbacks of GKMP/IPsec using 6over4 are that the IP 
     hosts must be upgraded to dual-stack, the attendant overlay IP-v6 IPv6 
     multicast network operational costs, and the perceived difficulty 
     of deploying commercial wide-area IP-v6 IPv6 multicast services. 

5.1.4 

6.1.4 GKMP/IPsec Multi-Realm IP-v4 IPv4 NAT Architecture 
 
   In a multi-realm group, GKMP/IPsec security association endpoints may 
   straddle any combination of IP-v4 IPv4 public addresses and private 
   addresses [RFC1918]. In such cases, transport layer endpoint 
 
   Weis                 Expires December, 2005               [Page 14] 

              The Use of RSA Signatures with ESP and AH    June, 2005 
   identifiers when resolved to their underlying private or public IP-v4 IPv4 
   addresses entangle the GKMP protocol with NAT gateway behaviors. The 
   NAT translation of IP-v4 IPv4 header addresses impacts the GKMP 
   registration SA, the GKMP re-key GSA, and the secure multicast 
   application GSA. 
    
   This section overviews the GKMP/IPsec mechanisms that partially 
   mitigate the inherent complexity spawned by IP-v4 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 GC/KS 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 
   GKMP/IPsec applications and deployments SHOULD strongly prefer the 
   use of IP-v6. Section X.Y offers IP-v4 IPv6. 
 
Weis, et al.             Expires August, 2006                [Page 16] 

Internet-Draft     Multicast Extensions to IP-v6 transitional guidance 
   in support of that objective. 
    
5.1.4.1 RFC 4301         June, 2005 
    
    
    
6.1.4.1 GKMP/IPsec IP-v4 IPv4 NAT Architectural Assumptions 
 
   To make the multi-realm GKMP/IPsec IP-v4 IPv4 NAT interaction problem 
   tractable to a solution, this specification requires suggests the following 
   simplifying assumptions: 
    
  - The secure multicast group destination address is a statically 
     allocated public IP-v4 IPv4 multicast address known to all group 
     endpoints. 

  - Wherever they are present in the GKMP, group endpoint addresses are 
     expressed as permanent IP-v6 "6to4" addresses [RFC3056] to assure 
     that the group endpoints that refer to hosts assigned private IP-v4 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 IP-v4 IPv4 address space has one or more NAT gateways 
     directly connected to the IP-v4 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 GC/KS GCKS may reside within one of the private networks, but it also 
     MUST have a permanent public IP-v4 IPv4 address on at least one of its 
     network interfaces. This requirement applies to both the Primary-
     GC/KS and all of the group's Subordinate-GC/KS.  

  - GKMP/IPsec group security associations are end-to-end transport 
     mode. However, since Since the one or more GC/KS GCKS are constrained to straddle a 
     public/private network boundary, they GKMP/IPsec group security 
     associations effectively terminate the GSA at a combined 
     NAT/security gateway [RFC2709]. 


 
   Weis                 Expires December, 2005               [Page 15] 

              The Use of RSA Signatures with ESP and AH    June, 2005 

  - The GC/KS GCKS domain name RR record should point to that public IP-v4 IPv4 
     address, and it is recommended that it be protected by DNS-SEC. 

  - Each of an administrative domain's NAT gateways are explicitly 
     configured with static private/public address translation mappings 
     for the GC/KS's GCKS's GKMP re-key multicast ESP protected UDP packets 
     inbound from the public Internet [RFC2588]. 

  - The NAT gateways/firewalls are explicitly configured with stateless 
     filter rules that simply pass through without any address 
     translation the group's inbound multicast application packets 
     arriving from the public Internet. The NAT gateway does not 
     translate the multicast application packet's public multicast IP 
     destination address into a private IP multicast address. 

  - In the outbound direction, NAT gateways generally translate the 
     multicast application packet's private source IP address into a 
 
Weis, et al.             Expires August, 2006                [Page 17] 

Internet-Draft     Multicast Extensions to RFC 4301         June, 2005 
    
    
     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 IP-v4 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. 

  - 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. 





















 
   Weis                 Expires December, 2005               [Page 16] 

              The Use of RSA Signatures with ESP and AH    June, 2005 
    
    
    
        "A" Admin  .  ISP Admin   .    "B" Admin        
         Domain    .  Domain      .     Domain          
                   .              .                     
   +---------------.--------------.-------------------+ 
   |               .              .                   | 
   |  P U B L I C  .   I P - v 4  . I N T E R N E T   | 
   |               .              .                   | 
   +------/\-------.-----A-----A--.----/\--------/\---+ 
          || public.     |     |  .    || public ||     
          || IP-v4 .     |     |  .    || IP-v4  ||     
   +------\/------+.     |     |  .+---\/---+ +--\/---+ 
   |Grp.Z |NAT "A"|.     |     |  .|Group Z | |NAT "B"| 
   |S-GCKS|gateway|.     |     |  .|P-GC/KS | |gateway| 
   +---A--+---A---+.     |     |  .+---A----+ +--A----+ 
       |      |    .registratn |  .    |         |      
    regist. SA|    .     SA    |  . regist. SA   |      
       |      |    .     |     |  .    |         |      
     +-V-+    |    .   +-V-+   |  .  +-V-+       |      
     |GM1|    |    .   |GM2|   |  .  |GM3|       |      
     +-A-+    |    .   +-A-+   |  .  +-A-+       |      
       |      |    .     |     |  .    |         |      
     Group data SA . Group data SA.  Group data SA      
       rekey SA    .    rekey SA  .   and 

    
    
6.1.4.2 Multicast Application GSA NAT Traversal 
 
   Unlike the GKMP rekey SA      
       |      |    .     |     |  .    |         |      
     +-V------V--+ . +---V-----V-+.+---V---------V-+    
     | Group "Z" | . | Group "Z" |.| Group "Z"     |    
     | multicast | . | multicast |.| message multicast     |    
     | routing   | . | routing   |.| routing       |    
     | domain    | . | domain    |.| domain        |    
     +-----------+ . +-----------+.+---------------+    
                   .              .                     
   Figure 2 Representative GKMP/NAT architecture 
    
5.1.4.2 Representative GKMP Multi-Realm Configuration 
 
   Figure 2 illustrates a representative group "Z" wherein a GKMP/IPsec 
   group security association spans two private IP-v4 networks and the 
   public IP-v4 Internet. The Group "Z" GC/KS has two network 
   interfaces, one attached to the public Internet and the other 
   interface attached Re-Key GSA, a 
   multicast application message sent to the administrative domain "B" private network. 
    
   The group member GM1 resides within the administrative domain "A" 
   private network. It communicates with the group Z may originate from a 
   Group Speaker 
   endpoint(s) through the administrative domain "A" endpoint located behind a NAT gateway. When 
   GM1 multicasts application SA traffic to Since the group Z public multicast 
   address, 
   application's message is encrypted within an ESP payload, the Group Z peer members (i.e. GM2, 
   transport layer protocol header port fields are concealed from NAT 
   gateways and GM3) receive that they cannot participate in NAPT. The multicast with 
   application GSA must be handled differently depending on whether the source 
   application requires source-specific multicast. 
    
   If the application requires source-specific multicast routing, then 
   there must be a separate public IP-v4 address translated by statically reserved at 
   the NAT gateway "A" 
   processing. In the inverse direction, for each Group Speaker endpoint private/public 
   address mapping. This constraint allows the administrative domain "A" 
   NAT gateway/firewall must be configured GCKS to allow specify at every 
   Group Z multicast 

 
   Weis                 Expires December, 2005               [Page 17] 

              The Use of RSA Signatures with ESP and AH    June, 2005 
    
    
   application GSA traffic to enter the private network "A" from the 
   public Internet (e.g. a multicast originating from GM3). 
    
   The group member GM3 resides within Member the administrative domain "B" 
   private network. Its interactions inbound SPD traffic selector with Group Z are very similar to 
   those discussed a pre-determined 
   public source address for member GM1. It uses private addresses when 
   communicating with the P-GC/KS, as it is each Group Speaker endpoint in private network "B". the group. 
   The group member GM2 is in a traffic selector's public Internet administrative domain 
   operated by an ISP. It communicates source address in combination with the P-GC/KS using public IP-
   v4 addresses without passage through a 
   group's destination multicast address and SPI selects the inbound SA. 
   Keeping the NAT gateway. When GM2 
   multicasts application SA traffic to gateway's source address mapping static rather than 
   dynamic also allows the group Z public multicast 
   address, routers along the Group Z peer members behind NAT gateways receive packet's path to 
   apply source-specific routing policies. Note that 
   multicast with the use of a static 
   source address unchanged by mapping NAT processing. 
    
   Each administrative domain operates an IP-v4 multicast routing domain 
   instance. The multicast routers distribute both GKMP re-key messages 
   and multicast application GSA data traffic. The multicast routing avoids the need for 
   group "Z" peers between these three multicast routing domains. 
    
5.1.4.3 Registration Security Association NAT Traversal 
 
   The GKMP registration protocol's unicast messages are exchanged 
   between a GC/KS in the public IP-v4 Internet and a candidate Group 
   Member that may be in a private network.  
   A group member sends a registration SA GKMP message group's policy 
   token to the GC/KS 
   public IP-v4 address and the GKMP reserved port number. The group 
   member assigns a unique GKMP specify UDP source port number for each GKMP 
   registration SA that it participates in. encapsulated ESP. The group member SHOULD send 
   the GKMP UDP packet without a checksum to avoid NAT alterations to drawback of this approach 
   is that field. The UDP packet's transmission error detection depends on the GKMP signature within GCKS SPD/SAD configuration database must be kept 
   synchronized with the payload. A group's NAT gateway on address mapping 
   configurations. These operational procedures can be labor-intensive 
   and error-prone, making large-scale group deployments difficult. A 
   more sophisticated GKMP may sidestep this problem by dynamically 
   setting the path 
   leading Group Receiver endpoint's SPD/SAD entry traffic selector 
   rather than relying on static GCKS configuration. 
    

 
Weis, et al.             Expires August, 2006                [Page 18] 

Internet-Draft     Multicast Extensions to RFC 4301         June, 2005 
    
    
   If the GC/KS translates application requires the private any-source multicast service model, 
   then the NAT gateway's source IP address and 
   source UDP port number into a translation can use dynamically 
   allocated public address and a temporary IPv4 addresses rather than statically allocated IPv4 
   addresses. However, unless the group uses UDP port 
   number (assuming NAPT), encapsulated ESP, then forwards 
   the packet to the GC/KS. The NAT gateway creates state information for must have a pool of public IPv4 addresses reserved 
   that public/private address 
   mapping so it can do the inverse translation on the GKMP messages 
   sent from is at least as large as the GC/KS to that group member. number of Group Speaker endpoints 
   within its private network. The GC/KS must process public IP address pool allows the GKMP messages that it receives from group 
   members originating NAT 
   gateway to do a one-to-one mapping from any every Group Speaker 
   endpoint's private source IP address or to a dynamically allocated public 
   source port number, 
   even if those two values have changed since address. In this case, the last time that use of NAPT rather than NAT is not 
   an option, since the 
   GC/KS had interacted with a given group member. To identify transport layer protocol is within an opaque ESP 
   payload. The GCKS specifies the group 
   member, SPD/SAD traffic selector as the GC/KS MUST use 
   combination of the GKMP signature payload's identifying 
   information group's destination multicast address and validate the message's digital signature. 
    
   After processing a message from a group member that requires SPI. 
    
   In some deployments, the number of public IPv4 addresses assigned to 
   a GC/KS 
   response, 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 GC/KS creates group begins its 
   operation. For these cases, the GKMP group MAY use UDP message destined for encapsulated ESP. 
   The NAT gateway applies NAPT to the 
   same IP-v4 address and UDP header's source port field, 
   sidestepping the constraint of its limited public IPv4 address pool. 
   The Group Owner modifies the group policy token to specify that the GC/KS found 
   outbound SPD processing must pre-append a UDP header in front of the candidate 
   ESP header. When a Group Member message's source IP address and Speaker endpoint originates a multicast 
   application packet, it inserts a UDP source port. 

 
   Weis                 Expires December, 2005               [Page 18] 

              The Use header in front of RSA Signatures with ESP and AH    June, 2005 
    
    
5.1.4.4 GKMP Re-key GSA NAT Traversal 
 
   The GKMP Re-Key GSA is considerably simplified by the constraint that 
   every Subordinate-GC/KS and Primary-GC/KS MUST straddle a public 
   Internet/private ESP 
   header, as per reference [RFC3948]. 
    
7.0 Security Considerations 
    
   This document describes architecture for securing group network boundary adjacent to wherever it 
   traffic using IPsec. As such, security considerations are found 
   throughout this document. 
    
8.0 IANA Considerations 
    
   This document has Group 
   Members behind a NAT gateway. Consequently, a GC/KS may have Group 
   Members on either side of that boundary, but there is no intervening 
   NAT gateway tampering with the GC/KS transmissions.  
    
   The GC/KS multicasts the GKMP re-key message to the Re-Key GSA actions for IANA. 
    
9.0 Acknowledgements 
    
   [TBD] 
    
10.0 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 an 
   ESP protected UDP|GKMP packet addressed to its (sub-)group's 
   destination public IP-v4 multicast address. The UDP destination port 
   is set RFCs to the GKMP-UDP reserved port number. The group keyed ESP 
   authenticator protects the UDP payload, so a UDP checksum MUST NOT be 
   used. 
    
   A multi-realm IP-v4 GKMP/IPsec group operates in autonomous 
   distributed mode. Therefore, each of the group's Subordinate-GC/KS 
   must relay Indicate 
   Requirement Level", BCP 14, RFC 2119, March 1997. 
    
 
Weis, et al.             Expires August, 2006                [Page 19] 

Internet-Draft     Multicast Extensions to their respective sub-group membership the GTEK (and 
   policy token, if any) that it extracts from RFC 4301         June, 2005 
    
    
   [RFC3552] Rescorla, E., et. al., "Guidelines for Writing RFC Text on 
   Security Considerations", RFC 3552, July 2003. 
    
   [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Primary-GC/KS rekey 
   multicast. The S-GC/KS sends its re-key message to its sub-group 
   membership from its public 
   Internet interface. 
    
5.1.4.5 Multicast Application GSA NAT Traversal 
 
   Unlike the GKMP 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 can not 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 GC/KS to specify at every 
   Group Member the inbound SPD 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 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 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 GC/KS SPD/SAD configuration database must be kept 
   synchronized with the group's NAT gateway address mapping 
   configurations. These operational procedures can be labor-intensive H. Harney, "Group Security Policy Token 
   v1", (work in progress), draft-ietf-msec-policy-token-sec-06.txt 
   (work in progress), January 2006. 
    
   [RFC2362] Estrin, D., et. al., "Protocol Independent Multicast-Sparse 
   Mode (PIM-SM): Protocol  Specification",  RFC 2362, June 1998. 
   [RFC2526] Johnson, D., and error-prone, making large-scale group deployments difficult. A 
 
   Weis                 Expires December, 2005               [Page 19] 

              The Use of RSA Signatures with ESP S. Deering., "Reserved IPv6 Subnet Anycast 
   Addresses", RFC 2526, March 1999. 
    
   [RFC2529] Carpenter, B. and AH    June, 2005 
    
    
   more sophisticated GKMP may sidestep this problem by dynamically 
   setting the Group Receiver endpoint's SPD/SAD entry traffic selector 
   rather than relying on static GC/KS configuration. 
    
   If the application requires the any-source multicast service model, 
   then the NAT gateway's source address translation can use dynamically 
   allocated public IP-v4 addresses rather than statically allocated IP-
   v4 addresses. However, unless the group uses UDP encapsulated ESP, 
   then the NAT gateway must have a pool of public IP-v4 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 an option, since the transport layer protocol is within an 
   opaque ESP payload. The GC/KS specifies the SPD/SAD traffic selector 
   as the combination C. Jung, "Transmission of the group's destination multicast address IPv6 over IPv4 
   Domains without Explicit Tunnels", RFC 2529, March 1999. 
    
   [RFC2588] Finlayson, R., "IP Multicast and 
   the SPI. 
    
   In some deployments, the number of public IP-v4 addresses assigned to 
   a NAT gateway is very limited (e.g. only one public IP-4 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 Firewalls", RFC 2588, May 
   1999. 
    
   [RFC2709] Srisuresh, P., "Security Model with Tunnel-mode IPsec for 
   NAT gateway applies NAPT to the UDP header's source port field, 
   sidestepping Domains", RFC 2709, October 1999. 
    
   [RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914, 
   September 2000. 
    
   [RFC3027] Holdrege, M., and P. Srisuresh, "Protocol Complications 
   with the constraint of its limited public IP-v4 address pool. 
   The IP Network Address Translator", RFC 3027, January 2001. 
    
   [RFC3171] Albanni, Z., et. al., "IANA Guidelines for IPv4 
   Multicast Address Assignments", 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 Owner modifies the group policy token Management Protocol, 
   Version 3", RFC 3376, October 2002. 
    

 
Weis, et al.             Expires August, 2006                [Page 20] 

Internet-Draft     Multicast Extensions to specify that the 
   outbound SPD processing must pre-append a UDP header in front of the 
   ESP header. When a RFC 4301         June, 2005 
    
    
   [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 
   Group Speaker endpoint originates a multicast 
   application packet, it inserts a UDP header in front 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 
   header, as per reference [UDPESP]. 
    
6.0 
   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 Considerations 
    
   [TBD] 
 
7.0 Acknowledgements 
    
   [TBD] 
    
8.0 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 August, 2006                [Page 21] 

Internet-Draft     Multicast Extensions to RFC 4301         June, 2005 
    
    
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 Protocol (GKMP) Subsystem and 
   the IPsec subsystem MUST be able to configure the SPD/SAD security 
   policies to match these dominant usage scenarios. The SPD/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 GKMP Subsystem management interface MAY 
   include mechanisms to configure the security policies for service 
   models not identified by this standard. 
 
   Weis                 Expires December, 2005               [Page 20] 

              The Use of RSA Signatures with ESP and AH    June, 2005 
    
    
    
8.1 
    
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. RFC2401-bis RFC 4301 only defines bi-
   directional bi-directional 
   unicast security associations (as per sections 4.4.1 and 5.1 with 
   respect to security association directionality). The GKMP 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 SPD 
   configuration is optionally setup to discard unauthorized attempts to 
   transmit unicast or multicast packets to the group. 
    
   The GKMP Subsystem's Group Owner management interface MUST have the ability to 
   setup a GKMP Subsystem group having a unidirectional GSA security 
   policy. 
    
8.2 
    
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 SPD entry for this GSA 

 
Weis, et al.             Expires August, 2006                [Page 22] 

Internet-Draft     Multicast Extensions to RFC 4301         June, 2005 
    
    
   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 RSA digital signature mechanism authentication is available, available (E.g., RFC 
   4359), source authentication MAY be used to authenticate a receiver 
   Node's transmission to the 
   speaker. The GKMP 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. 
    
 
   Weis                 Expires December, 2005               [Page 21] 

              The Use of RSA Signatures with ESP and AH    June, 2005 
    
    
   The GKMP Subsystem's Group Owner management interface MUST have the 
   ability to setup a GKMP 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. 
    
8.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's 
   endpoints are authorized multicast speakers. In such service models, 
   creating a distinct GSA with anti-replay state for every potential 
   speaker does not scale to large groups. The group SHOULD share one 
   GSA for all of its speakers. transmission to the speaker. The GSA SHOULD NOT use IPsec anti-replay 
   protection service GKMP MUST define a key 
   management mechanism for the speaker's multicast data flow group speaker to validate the 
   group's listeners. 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 GKMP Subsystem's Group Owner management interface MUST have the 
   ability to setup a group having an Any-To-Many Multicast GSA security 
   policy. 
    
    
9.0 References 
    
9.1 Normative References 
    
   [AH] Kent, S., "IP Authentication Header", draft-ietf-ipsec-
   rfc2402bis-10.txt, December 2004. 
    
   [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", draft-
   ietf-ipsec-esp-v3-09.txt, September 2004. 
    
   [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. 
    
   [RFC2401BIS] Kent, S. and K. Seo, "Security Architecture for the 
   Internet Protocol", draft-ietf-ipsec-rfc2401bis-06.txt, March, 2005. 
    
   [RFC3552] E. Rescorla, et. al., "Guidelines for Writing RFC Text on 
   Security Considerations", RFC 3552, July 2003. 
 
9.2 Informative References 
 
   [IKEV2] C. Kaufman, "Internet Key Exchange (IKEv2) Protocol", draft-
   ietf-ipsec-ikev2-17.txt, September 23, 2004. 
 
   Weis                 Expires December, 2005               [Page 22] 

              The Use of RSA Signatures with ESP and AH    June, 2005 
    
    
    
   [RFC2526] D. Johnson, S. Deering., "Reserved IPv6 Subnet Anycast 
   Addresses", RFC 2526, March, 1999. 
    
   [RFC2914] S.Floyd, "Congestion Control Principles", RFC2914, 
   September 2000. 
    
   [RFC3171] Z. Albanni, et. al., "IANA Guidelines for IPv4 Multicast 
   Address Assignments", RFC 3171, August, 2001. 
 
   [RFC2362] Estrin, D., et. al., "Protocol Independent Multicast-Sparse 
   Mode (PIM-SM): Protocol  Specification",  RFC 2362, June, 1998. 
    
   [RFC3376] B. Cain, et. al., "Internet Group Management Protocol, 
   Version 3", RFC 3376, October, 2002. 
    
   [RFC3547] Baugher, M., Weis, B., Hardjono, T., 
   ability to setup a GKMP Subsystem GSA having a bi-directional GSA 
   security policy and H. Harney, "The 
   Group Domain 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 Interpretation", RFC 3547, December 2002. 
 
   [RFC3569] S. Bhattacharyya, "An Overview secure multicast applications exhibits a "any to 
   many" communications pattern. A representative example of Source-Specific 
   Multicast (SSM)", RFC 3569, July, 2003. 
    
   [RFC3940] B. Adamson, et. al., "Negative-acknowledgment (NACK)-
   Oriented Reliable Multicast (NORM) Protocol", RFC 3940, November, 
   2004. 
    
   [RFC4082] A. Perrig, et. al., "Timed Efficient Stream Loss-Tolerant 
   Authentication (TESLA): Multicast Source Authentication Transform 
   Introduction", RFC 4082, June 2005. 
    
   [W05] B. Weis, "The Use such an 
   application is a videoconference combined with an electronic 
   whiteboard. 
    
   For such applications, all (or a large subset) of RSA/SHA-1 Signatures within ESP and AH", 
   draft-ietf-msec-ipsec-signatures-06.txt, June 2005. 
    
   [ZLLY03] X. Zhang, et. al., "Protocol Design for Scalable and 
   Reliable the 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                 Expires December, 2005               [Page 23] 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 Use group SHOULD share one IPsec SA 
   for all of RSA Signatures with ESP and AH 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 GKMP 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 August, 2006                [Page 23] 

Internet-Draft     Multicast Extensions to RFC 4301         June, 2005 
    
    
Author's Address 
    
   Brian Weis 
   Cisco Systems 
   170 W. Tasman Drive, 
   San Jose, CA 95134-1706, 95134-170 
   USA 
   (408) 526-4796 
    
   Phone: +1-408-526-4796 
   Email: bew@cisco.com 
    
   George Gross 
   IdentAware Security 
   82 Old Mountain Road 
   Lebanon, NJ 08833 
   908-268-1629 
   USA 
    
   Phone: +1-908-268-1629 
   Email: gmgross@identaware.com 
    
   Dragan Ignjatic 
   Polycom 
   1000 W. 14th Street 
   North Vancouver, BC V7P 3P3 
   Canada 
   tel: +1 604 982 3424 
   email: 
    
   Phone: +1-604-982-3424 
   Email: dignjatic@polycom.com 
    
    
Full Copyright Statement 
    
   Copyright (C) The Internet Society (2005). 
    
   This document is subject 
    
 





















 
Weis, et al.             Expires August, 2006                [Page 24] 

Internet-Draft     Multicast Extensions to the rights, licenses and restrictions 
   contained in BCP 78, and except as set forth therein, the authors 
   retain all their rights. 
 
   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. RFC 4301         June, 2005 
    
    
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. 
    
 
   Weis                 Expires December, 2005               [Page 24] 

              The Use of RSA Signatures with ESP and AH    June, 2005 
    
   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 
    
 




 
Weis, et al.             Expires December, 2005 August, 2006                [Page 25] 

----