[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 RFC 5374

Internet Engineering Task Force                      Brian Weis (Cisco)
INTERNET-DRAFT                                George Gross (IdentAware)
draft-ietf-msec-ipsec-extensions-00.txt       Dragan Ignjatic (Polycom)
Expires: December, 2005                                      June, 2005

    Multicast Extensions to the Security Architecture for the Internet
                                 Protocol

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.

Abstract

   The Security Architecture for the Internet Protocol [RFC2401BIS]
   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                [Page 1]

              The Use of RSA Signatures with ESP and AH    June, 2005


Table of Contents

1.0 Introduction.......................................................2
  1.1 Scope...........................................................3
  1.2 Terminology......................................................3
2.0 Overview of IP Multicast Operation.................................4
3.0 Security Association Modes.........................................4
4.0 Security Association...............................................5
  4.1 Major IPsec Databases............................................5
    4.1.1 SPD..........................................................5
    4.1.2 SAD..........................................................6
    4.1.3 PAD..........................................................6
    4.1.4 GSA..........................................................8
  4.2 Data Origin Authentication.......................................9
  4.3 Group SA and Key Management.....................................10
    4.3.1 Co-Existence of Multiple Key Management Protocols...........10
5.0 IP Traffic Processing.............................................10
  5.1 Outbound IP Multicast Traffic Processing........................10
  5.2 Inbound IP Multicast Traffic Processing.........................11
5.0 Networking Issues.................................................11
  5.1 Network Address Translation.....................................11
    5.1.1 SPD Losses Synchronization with Internet Layer's State......11
    5.1.2 Secondary Problems Created by NAT Traversal.................12
    5.1.3 Avoidance of NAT Using an IP-v6 Over IP-v4 Network..........14
    5.1.4 GKMP/IPsec Multi-Realm IP-v4 NAT Architecture...............14
6.0 Security Considerations...........................................20
7.0 Acknowledgements..................................................20
8.0 Appendix A - Multicast Application Service Models.................20
  8.1 Unidirectional Multicast Applications...........................21
  8.2 Bi-directional Reliable Multicast Applications..................21
  8.3 Any-To-Any Multicast Applications...............................22
9.0 References........................................................22
  9.1 Normative References............................................22
  9.2 Informative References..........................................22
Author's Address......................................................24
Full Copyright Statement..............................................24
Intellectual Property.................................................24

1.0 Introduction

   The Security Architecture for the Internet Protocol [RFC2401BIS]
   provides security services for traffic at the IP layer. It describes
   a base 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 that carry a unicast
   address in the IP destination field. Those security services 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 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.

   This document describes extensions to [RFC2401BIS] that further
   define the IPsec security architecture for packets with a multicast
   address in the IP destination field to remain 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 in
   very large groups. Comments regarding matters of scope are
   solicited.]

1.1  Scope

   The IPsec extensions described in this document support for IPsec
   Security Associations used with both Any-Source Multicast (ASM) and
   Source-Specific Multicast (SSM) [RFC3569, RFC3376] groups.

   They extensions also support Security Associations with IPv4
   Broadcast addresses, and Anycast addresses [RFC2526], since there are
   be multiple receivers defined for a packet sent to those addresses.

   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
   multicast routing protocols (e.g., PIM-SM [RFC2362]) or multicast
   admission protocols (e.g., IGMP [RFC3376] to participate in IPsec.

   All implementation models of IPsec (e.g., "bump-in-the-stack", "bump-
   in-the-wire") are supported.

1.2 Terminology

   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 Protocol (IP) multicast service model as defined in
      RFC 3569 [RFC3569]. In this model each combination of a sender and
      an IP multicast address is considered a group. This is known as an
      (S,G) group.

   Weis                 Expires December, 2005                [Page 3]

              The Use of RSA Signatures with ESP and AH    June, 2005



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 with either a "best-effort" reliability to all members of
   the group [RFC1112], or reliably (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 and ESP 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 both modes to encapsulate an IP multicast packet. These
   processing rules are identical to the rules described in [RFC2401BIS,
   Section 4.1]. However, the destination address for the IPsec packet
   is an IP multicast address rather than a unicast host address.

   A security gateway implementation of IPsec using the multicast
   extensions MUST use a tunnel mode SA, for the reasons described in
   [RFC2401BIS, Section 4.1]. In particular, the security gateway must
   use tunnel mode to encapsulate incoming fragments.

   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 unique requirements of IP multicast
   routing protocols (such as PIM-SM [RFC2362]).

   IP multicast routing protocols use the destination address on a
   packet to decide to where the packet should be routed. If the
   destination of an IP multicast packet is changed it will no longer be
   properly routed. To accommodate this routing requirement, the GKMP
   Subsystem may specify two actions. Firstly, the SPD-S entry for the
   traffic selectors must have the Remote Address PFP flag set. This

   Weis                 Expires December, 2005                [Page 4]

              The Use of RSA Signatures with ESP and AH    June, 2005


   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 to
   copy the remote address in the SA into the tunnel header remote
   address.

   IP multicast routing protocols also typically create multicast
   distribution trees based on the source address. An IPsec security
   gateway that changes the source address of an IP multicast packet may
   cause RPF checks on other routers to return a different result than
   the original plaintext IP multicast packet. As a result, multicast
   routing may drop the packet. To accommodate this routing requirement,
   the GKMP Subsystem may specify two actions. 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 to
   copy the source address in the SA into the tunnel header remote
   address.

   Some applications of address preservation may only require the remote
   address to be preserved. For this reason, the specification of remote
   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

   A new SPD attribute is introduced - SPD entry directionality.
   Directionality can take three types. Each SPD entry can be marked
   symmetric, sender or receiver only. Symmetric SPD entries are the
   common entries as specified by RFC2401bis. Symmetric SHOULD be the
   default directionality unless specified otherwise. SPD entries marked
   as sender or receiver only SHOULD support multicast IP addresses in
   their destination address selectors. If the processing requested is
   bypass or discard and a sender only type is configured the entry

   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.

   SPD entries created by a GCKS may have identical SPIs as some of the
   IKE created ones. This is not a problem for the inbound traffic as
   the appropriate SA's can be matched using the algorithm described in
   RFC2401bis and SA's contain a link to their parent SPD entries if
   such an entry exists (i.e. they are not manually keyed in). 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.

4.1.2 SAD

   The SAD can support multicast SAs, if manually configured. An
   outbound multicast SA has the same structure as a unicast SA. The
   source address is that of the 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, not by the
   receiver, as for a unicast SA. Because an SAD entry may be required
   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. However, SPD needs provisions for accommodating
   multicast entries in order to enable automatic multicast SA creation.

   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 (in
   case of SSM) or just a member. It 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 section 4.4.3 introduced the Peer Authorization
   Database (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 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 the group SPD/SAD.

   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 group
   members receive the GCKS re-key multicast and verify the Group
   Owner's signature on the revised policy token. If that GO signature
   is accepted, then all group members dynamically update their
   respective 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 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

   A IPsec implementation supporting these extensions has a number of
   security associations: one or more IPsec SAs, and one or more group
   key management SAs used to download IPsec SAs [RFC3740, Section 4].
   These SAs are collectively referred to as a GSA.

4.1.4.1 Concurrent GSA 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 that maintains anti-replay state. A group that
       does not rely on IP Security anti-replay services can share one
       GSA for all of its Group Speakers.

     - The life spans of a Group Speaker's two (or more) GSA are allowed
       to overlap in time, so that there is continuity in the multicast
       data stream across group re-key events. This capability is
       referred to as "re-key rollover continuity".

   Each group re-key multicast message sent by a GCKS signals the start
   of a new Group Speaker time epoch, with each such epoch having an
   associated GSA. The group membership interacts with these GSA 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), and for some GKMP the RKE may include a
     revised group policy token. 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
     "leading edge" GSA state information. The leading edge GSA
     allocates a new Security Parameter Index and it is keyed by the
     GTPK distributed by the most recent RKE multicast. 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
     transmit data using the leading edge GSA. Meanwhile, the Group
     Receiver endpoints prepare to use this GSA by installing the RKE
     directed changes to their respective SPD/SAD.

  - After waiting a sufficiently long enough period such that all of
     the Group Receiver endpoints have processed the RKE multicast, the
     Group Speaker begins to transmit using the leading edge GSA with
     its data encrypted by the new GTPK. Only authorized Group Members
     can decrypt these GSA 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 is the oldest group
     security association in use by the group for that speaker. All
     authorized Group Receiver endpoints can receive and decrypt data
     for this GSA, but the Group Speaker does not transmit new data
     using the "trailing edge" GSA after it has transitioned to the
     "leading edge GSA". The trailing edge GSA 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-
   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], data origin authentication is a security
   service that verifies the identity of the claimed source of data.
   While HMAC authentication methods are to 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, an authentication transform where
   the originator keeps a secret should be used. Two possible algorithms
   are TESLA [RFC4082] or RSA [W05].

   In some cases, (e.g., RSA) 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, 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]. A fundamental
   GKMP IP Security subsystem requirement is that both the GKMP and IKE-
   v2 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 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 for further
   explanation.

   The Peer Authorization Database does require explicit coordination
   between the GKMP and IKE-v2. Section X.Y describes these
   interactions. This document discusses the coordination of multiple
   GKMP group owner and endpoint local management systems in section
   4.11.

5.0 IP Traffic Processing

   Processing of traffic follows [RFC2401BIS, 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), 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]. 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, Section 5.2]. In particular the IPsec system MUST
   discard the packet, as well as treat the inconsistency as an
   auditable event.

5.0 Networking Issues

5.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 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 Mobile Multicast Care-Of Address Route Optimization

   Both Mobile IP-v4 [RFC3344] and Mobile IP-v6 [MIPV6] 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 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 multicast Group Receiver, the NAT gateway alters the private
   source address to a public IP-v4 address. This translation must be
   coordinated with every Group Receiver's inbound Security Policy
   Database (SPD) multicast entries that depend on that source address
   as a traffic selector. One might mistakenly assume that the GC/KS
   could set up the group endpoints with a 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 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 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
     address may change due to a DHCP assigned address lease expiration.

  - Alternate paths may exist between a given pair of group endpoints.
     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 can not be pre-
   configured with NAT mappings, as the SPD at the group's endpoints
   will lose synchronization as soon as a NAT mapping changes due to any
   of the above events. In the worst case, group endpoints in different
   sections of the Internet will see different NAT mappings, because the
   multicast packet traversed multiple NAT gateways.

5.1.2 Secondary Problems Created by NAT Traversal

5.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. Mobility changes a Node'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 ESP Cloaks Its Payloads from NAT Gateway

   When traversing NAT, application layer protocols that contain IP-v4
   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
   addresses into equivalent public IP-v4 addresses. However, when
   encrypted by end-to-end ESP, such payloads are opaque to application
   layer gateways.
   When multiple Group Speaker endpoints reside behind a NAT with a
   single public IP-v4 address, the NAT gateway can not do UDP or TCP
   protocol port translation (i.e. NAPT) because the ESP encryption
   conceals the transport layer protocol headers. The use of UDP
   encapsulated ESP [UDPESP] avoids this problem. However, this
   capability must be configured at the GC/KS 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 UDP Checksum Dependency on Source IP Address

   A GKMP/IPsec multicast application that uses UDP within an ESP
   payload will encounter NAT induced problems. The original IP-v4
   source address is an input parameter into a receiver's UDP pseudo-
   header checksum verification, yet that value is lost after the IP
   header's address translation by a transit NAT gateway. The UDP header
   checksum is opaque within the encrypted ESP payload. Consequently,
   the checksum can not be manipulated by the transit NAT gateways. UDP
   checksum verification needs a mechanism that recovers the original
   source IP-4 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], this information is exchanged
   between the endpoints by a NAT-OA payload (NAT original address). See
   also reference [IPSECNAT]. 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 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 Avoidance of NAT Using an IP-v6 Over IP-v4 Network

   A straightforward and standards-based architecture that effectively
   avoids the GKMP interaction with NAT gateways is the IP-v6 over IP-v4
   transition mechanism [RFC2529]. In IP-v6 over IP-v4 (a.k.a.
   "6over4"), the underlying IP-v4 network is treated as a virtual
   multicast-capable Local Area Network. The IP-v6 traffic tunnels over
   that IP-v4 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 multicast router(s). The group's IP-v6
   multicast routing can execute in parallel to IP-v4 multicast routing
   on that same physical router infrastructure. In particular, the NAT
   gateways at administrative domain public/private boundaries are
   replaced by IP-v6 multicast routers operating with 6over4 mode
   enabled on their network interfaces.
   Within the GKMP, all references to IP addresses are IP-v6 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 with NAT deployment. In particular, new
   GKMP/IPsec multicast applications SHOULD prefer IP-v6 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 addresses rather than IP-v4 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 multicast applications that
     are only available in binary form will not be able to migrate to
     these transitional IP-v6 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
     multicast network operational costs, and the perceived difficulty
     of deploying commercial wide-area IP-v6 multicast services.

5.1.4 GKMP/IPsec Multi-Realm IP-v4 NAT Architecture

   In a multi-realm group, GKMP/IPsec security association endpoints may
   straddle any combination of IP-v4 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
   addresses entangle the GKMP protocol with NAT gateway behaviors. The
   NAT translation of IP-v4 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 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 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 to IP-v6 transitional guidance
   in support of that objective.

5.1.4.1 GKMP/IPsec IP-v4 NAT Architectural Assumptions

   To make the multi-realm GKMP/IPsec IP-v4 NAT interaction problem
   tractable to a solution, this specification requires the following
   simplifying assumptions:

  - The secure multicast group destination address is a statically
     allocated public IP-v4 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
     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 address space has one or more NAT gateways
     directly connected to the IP-v4 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 may reside within one of the private networks, but it also
     MUST have a permanent public IP-v4 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 the one or more GC/KS are constrained to
     straddle a public/private network boundary, they 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 domain name RR record should point to that public IP-v4
     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 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
     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 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 rekey SA
       |      |    .     |     |  .    |         |
     +-V------V--+ . +---V-----V-+.+---V---------V-+
     | Group "Z" | . | Group "Z" |.| Group "Z"     |
     | multicast | . | multicast |.| 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 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 Group Speaker
   endpoint(s) through the administrative domain "A" NAT gateway. When
   GM1 multicasts application SA traffic to the group Z public multicast
   address, the Group Z peer members (i.e. GM2, and GM3) receive that
   multicast with the source address translated by NAT gateway "A"
   processing. In the inverse direction, the administrative domain "A"
   NAT gateway/firewall must be configured to allow 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 the administrative domain "B"
   private network. Its interactions with Group Z are very similar to
   those discussed for member GM1. It uses private addresses when
   communicating with the P-GC/KS, as it is in private network "B".

   The group member GM2 is in a public Internet administrative domain
   operated by an ISP. It communicates with the P-GC/KS using public IP-
   v4 addresses without passage through a NAT gateway. When GM2
   multicasts application SA traffic to the group Z public multicast
   address, the Group Z peer members behind NAT gateways receive that
   multicast with the source address unchanged by 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 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 to the GC/KS
   public IP-v4 address and the GKMP reserved port number. The group
   member assigns a unique GKMP UDP source port number for each GKMP
   registration SA that it participates in. The group member SHOULD send
   the GKMP UDP packet without a checksum to avoid NAT alterations to
   that field. The UDP packet's transmission error detection depends on
   the GKMP signature within the payload. A NAT gateway on the path
   leading to the GC/KS translates the private source IP address and
   source UDP port number into a public address and a temporary UDP port
   number (assuming NAPT), then forwards the packet to the GC/KS. The
   NAT gateway creates state information for that public/private address
   mapping so it can do the inverse translation on the GKMP messages
   sent from the GC/KS to that group member.

   The GC/KS must process the GKMP messages that it receives from group
   members originating from any source IP address or source port number,
   even if those two values have changed since the last time that the
   GC/KS had interacted with a given group member. To identify the group
   member, the GC/KS MUST use the GKMP signature payload's identifying
   information and validate the message's digital signature.

   After processing a message from a group member that requires a GC/KS
   response, the GC/KS creates the GKMP UDP message destined for the
   same IP-v4 address and UDP port that the GC/KS found in the candidate
   Group Member message's source IP address and UDP source port.


   Weis                 Expires December, 2005               [Page 18]

              The Use 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 network boundary adjacent to wherever it 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 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 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 to their respective sub-group membership the GTEK (and
   policy token, if any) that it extracts from 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 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
   and error-prone, making large-scale group deployments difficult. A

   Weis                 Expires December, 2005               [Page 19]

              The Use of RSA Signatures with ESP 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 of the group's destination multicast address 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 NAT gateway applies NAPT to the UDP header's source port field,
   sidestepping the constraint of its limited public IP-v4 address pool.
   The Group Owner modifies the group policy token to specify that the
   outbound SPD processing must pre-append a UDP header in front of the
   ESP header. When a Group Speaker endpoint originates a multicast
   application packet, it inserts a UDP header in front of the ESP
   header, as per reference [UDPESP].

6.0 Security Considerations

   [TBD]

7.0 Acknowledgements

   [TBD]

8.0 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 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 only defines 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 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
   SHOULD be configured to only allow a unicast transmission to the
   speaker Node rather than a multicast transmission to the whole group.

   If ESP RSA signature mechanism is available, 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. The GSA SHOULD NOT use IPsec anti-replay
   protection service for the speaker's multicast data flow to the
   group's listeners.

   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., and H. Harney, "The
   Group Domain of Interpretation", RFC 3547, December 2002.

   [RFC3569] S. Bhattacharyya, "An Overview 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 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 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]

              The Use of RSA Signatures with ESP and AH    June, 2005


Author's Address

   Brian Weis
   Cisco Systems
   170 W. Tasman Drive,
   San Jose, CA 95134-1706, USA
   (408) 526-4796
   bew@cisco.com

   George Gross
   IdentAware Security
   82 Old Mountain Road
   Lebanon, NJ 08833
   908-268-1629
   gmgross@identaware.com

   Dragan Ignjatic
   Polycom
   1000 W. 14th Street
   North Vancouver, BC V7P 3P3
   Canada
   tel: +1 604 982 3424
   email: dignjatic@polycom.com


Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   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.

   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.

Intellectual Property

   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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




































   Weis                 Expires December, 2005               [Page 25]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/