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

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

MSEC Working Group                                              B. Weis
Internet-Draft                                            Cisco Systems
Expires: August, 2006                                          G. Gross
                                                    IdentAware Security
                                                            D. Ignjatic
                                                         February, 2006

    Multicast Extensions to the Security Architecture for the Internet

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

Copyright Notice

   Copyright (C) The Internet Society (2006).


   The Security Architecture for the Internet Protocol [RFC4301]
   describes security services for traffic at the IP layer. That
   architecture primarily defines services for Internet Protocol (IP)
   unicast packets, as well as manually configured IP multicast packets.
   This document further defines the security services for IP multicast
   packets within that Security Architecture.

Weis                     Expires August, 2006                 [Page 1]

Internet-Draft     Multicast Extensions to RFC 4301         June, 2005

Table of Contents

1.0 Introduction.......................................................2
  1.1 Scope............................................................3
  1.2 Terminology......................................................3
2.0 Overview of IP Multicast Operation.................................5
3.0 Security Association Modes.........................................5
  3.1 Tunnel Mode with Address Preservation............................6
4.0 Security Association...............................................7
  4.1 Major IPsec Databases............................................7
    4.1.1 Security Policy Database (SPD)...............................7
    4.1.2 Security Association Database (SAD)..........................7
    4.1.3 Peer Authorization Database (PAD)............................8
    4.1.4 Group Security Association (GSA).............................9
  4.2 Data Origin Authentication......................................11
  4.3 Group SA and Key Management.....................................11
    4.3.1 Co-Existence of Multiple Key Management Protocols...........11
    4.3.2 New Security Association Attributes.........................12
5.0 IP Traffic Processing.............................................12
  5.1 Outbound IP Multicast Traffic Processing........................12
  5.2 Inbound IP Multicast Traffic Processing.........................12
6.0 Networking Issues.................................................12
  6.1 Network Address Translation.....................................13
    6.1.1 SPD Losses Synchronization with Internet Layer's State......13
    6.1.2 Secondary Problems Created by NAT Traversal.................14
    6.1.3 Avoidance of NAT Using an IPv6 Over IPv4 Network............15
    6.1.4 GKMP/IPsec Multi-Realm IPv4 NAT Architecture................16
7.0 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.....................22
  A.1 Unidirectional Multicast Applications...........................22
  A.2 Bi-directional Reliable Multicast Applications..................22
  A.3 Any-To-Any Multicast Applications...............................23
Author's Address......................................................24
Intellectual Property Statement.......................................25
Copyright Statement...................................................25

1.0 Introduction

   The Security Architecture for the Internet Protocol [RFC4301]
   provides security services for traffic at the IP layer. It describes

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 IPsec Security Associations (SAs) shared
   between two IPsec devices. Typically, this includes SAs with traffic
   selectors that include a unicast address in the IP destination field,
   and results in an IPsec packet with a unicast address in the IP
   destination field. The security services defined in RFC 4301 can also
   be used to tunnel IP multicast packets, where the tunnel is a
   pairwise association between two IPsec devices. Some support for IP
   packets with a multicast address in the IP destination field is
   supported, but only with manual keying, and only between IPsec
   devices acting as hosts.

   This document describes extensions to RFC 4301 that further define
   the IPsec security architecture for groups of IPsec devices to share
   SAs. In particular, it supports SAs with traffic selectors that
   include a multicast address in the IP destination field, and results
   in an IPsec packet with an IP multicast address in the IP destination
   field. It also describes additional semantics for IPsec Group Key
   Management Protocol (GKMP) Subsystems.

1.1 Scope

   The IPsec extensions described in this document support IPsec
   Security Associations that result in IPsec packets with IPv4 or IPv6
   multicast group addresses as the destination address. Both Any-Source
   Multicast (ASM) and Source-Specific Multicast (SSM) [RFC3569]
   [RFC3376] group addresses are supported.

   These extensions also support Security Associations with IPv4
   Broadcast addresses that result in an IPv4 Broadcast packet, and IPv6
   Anycast addresses [RFC2526]that result in an IPv6 Anycast packet.
   These destination address types share many of the same
   characteristics of multicast addresses because there may be multiple
   receivers of a packet protected by IPsec.

   The IPsec Architecture does not make requirements upon entities not
   participating in IPsec (e.g., network devices between IPsec
   endpoints). As such, these multicast extensions do not require
   intermediate systems in a multicast enabled network to participate in
   IPsec. In particular, no requirements are placed on the use of
   multicast routing protocols (e.g., PIM-SM [RFC2362]) or multicast
   admission protocols (e.g., IGMP [RFC3376].

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

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",
   document are to be interpreted as described in RFC 2119 [RFC2119].

   The following key terms are used throughout this document.

   Any-Source Multicast (ASM)
      The Internet Protocol (IP) multicast service model as defined in
      RFC 1112 [RFC1112]. In this model one or more senders source
      packets to a single IP multicast address. When receivers join the
      group, they receive all packets sent to that IP multicast address.
      This is known as a (*,G) group.

   Group Controller Key Server (GCKS)
      A Group Key Management Protocol (GKMP) server that manages IPsec
      state for a group. A GCKS authenticates and provides the IPsec SA
      policy and keying material to GKMP group members.

   Group Key Management Protocol (GKMP)
      A key management protocol used by a GCKS to distribute IPsec
      Security Association policy and keying material. A GKMP is used
      when a group of IPsec devices require the same SAs. For example,
      when an IPsec SA describes an IP multicast destination, the sender
      and all receivers must have the group SA.

   Group Key Management Protocol Subsystem
      A subsystem in an IPsec device implementing a Group Key Management
      Protocol. The GKMP Subsystem provides IPsec SAs to the IPsec
      subsystem on the IPsec device.

   Group Member
      An IPsec device that belongs to a group. A Group Member is
      authorized to be a Group Speaker and/or a Group Receiver.

   Group Owner
      An administrative entity that chooses the policy for a group.

   Group Security Association (GSA)
      A collection of IPsec Security Associations (SAs) and GKMP
      Subsystem SAs necessary for a Group Member to receive key updates.
      A GSA describes the working policy for a group.

   Group Receiver
      A Group Member that is authorized to receive packets sent to a
      group by a Group Speaker.

   Group Speaker
      A Group Member that is authorized to send packets to a group.

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 sender and
      an IP multicast address is considered a group. This is known as an
      (S,G) group.

   Tunnel Mode with Address Preservation
      A type of IPsec tunnel mode used by security gateway
      implementations when encapsulating IP multicast packets such that
      they remain IP multicast packets. This mode is necessary for IP
      multicast routing to correctly route IP multicast packets
      protected by IPsec.

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

3.0 Security Association Modes

   IPsec supports two modes of use: transport mode and tunnel mode.  In
   transport mode, IP Authentication Header (AH) [RFC4302] and IP
   Encapsulating Security Payload (ESP) [RFC4303] provide protection
   primarily for next layer protocols; in tunnel mode, AH and ESP are
   applied to tunneled IP packets.

   A host implementation of IPsec using the multicast extensions MAY use
   both transport mode and tunnel mode to encapsulate an IP multicast
   packet. These processing rules are identical to the rules described
   in [RFC4301, Section 4.1]. However, the destination address for the
   IPsec packet is an IP multicast address rather than a unicast host

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
   [RFC4301, Section 4.1]. In particular, the security gateway must use
   tunnel mode to encapsulate incoming fragments, since IPsec cannot
   directly operate on fragments.

3.1 Tunnel Mode with Address Preservation

   New header construction semantics are required when tunnel mode is
   used to encapsulate IP multicast packets that are to remain IP
   multicast packets. This is due to the following unique requirements
   of IP multicast routing protocols (e.g., PIM-SM [RFC2362]).

   - IP multicast routing protocols compare the destination address on
     a packet to the multicast routing state. If the destination of an
     IP multicast packet is changed it will no longer be properly
     routed. Therefore, an IPsec security gateway must preserve the
     multicast IP destination address after IPsec tunnel encapsulation.

     The GKMP Subsystem on a security gateway implementing the IPsec
     multicast extensions preserves the multicast IP address as
     follows. Firstly, the GKMP Subsystem sets the Remote Address PFP
     flag in the SPD-S entry for the traffic selectors. This flag
     causes the remote address of the packet matching IPsec SA traffic
     selectors to be propagated to the IPsec tunnel encapsulation.
     Secondly, the GKMP Subsystem needs to 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 GKMP Subsystem on an IPsec security gateway.

   - IP multicast routing protocols also typically create multicast
     distribution trees based on the source address. If an IPsec
     security gateway changes the source address of an IP multicast
     packet (e.g., to its own IP address), the resulting IPsec
     protected packet may fail RPF checks on other routers. A failed
     RPF check may result in the packet being dropped.

     To accommodate routing protocol RPF checks, the GKMP Subsystem 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, the GKMP
     Subsystem needs to signal that source address preservation is in
     effect for a particular IPsec SA. The GKMP MUST define an
     attribute that signals source address preservation to the 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 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

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 Security Policy Database (SPD)

   A new Security Policy Database (SPD) attribute is introduced: SPD
   entry directionality. Directionality can take three types. Each SPD
   entry can be marked "symmetric", "sender only" or "receiver only".
   Symmetric SPD entries are the common entries as specified by RFC
   4301. Symmetric SHOULD be the default directionality unless specified
   otherwise. SPD entries marked as "sender only" or "receiver only"
   SHOULD support multicast IP addresses in their destination address
   selectors. If the processing requested is bypass or discard and a
   sender only type is configured the entry SHOULD be put in 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 RFC 4301.

   SPD entries created by a GCKS may be assigned identical SPIs to SPD
   entries created by IKEv2 [RFC4306]. This is not a problem for the
   inbound traffic as the appropriate SAs can be matched using the
   algorithm described in RFC 4301. In addition, SAs with identical SPI
   values but not manually keyed can be differentiated because they
   contain a link to their parent SPD entries. However, the outbound
   traffic needs to be matched against the 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 Security Association Database (SAD)

   The 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 GCKS, not by the receiver,
   as for a unicast SA. This is similar to the unicast case and does not
   require changes to SAD.
   However, the SPD needs a mechanism for automatic multicast SA

4.1.3 Peer Authorization Database (PAD)

   The Peer Authorization Database (PAD) needs to be extended in order
   to accommodate peers that may take on specific roles in the group.
   Such roles can be GCKS, Group Speaker (in case of SSM) or a Group
   Receiver. A peer can have multiple roles. The PAD may also contain
   root certificates for PKI used by the group. GKMP/IPsec Interactions with the PAD

   The RFC 4301 section 4.4.3 introduced the  PAD. In summary, the PAD
   manages the IPsec entity authentication mechanism(s) and
   authorization of each such peer identity to negotiate modifications
   to the SPD/SAD. Within the context of the GKMP/IPsec subsystem, the
   PAD defines for each group:

   . For those groups that authenticate identities using a Public Key
     Infrastructure, the PAD contains the group's set of one or more
     trusted root public key certificates. The PAD may also include the
     PKI configuration data needed to retrieve supporting certificates
     needed for an end entity's certificate path validation.

   . A set of one or more group membership authorization rules. The GCKS
     examines these rules to determine a candidate group member's
     acceptable authentication mechanism and to decide whether that
     candidate has the authority to join the group.

   . A set of one or more GCKS role authorization rules. A group member
     uses these rules to decide which systems are authorized to act as a
     GCKS for a given group. These rules also declare the permitted GCKS
     authentication mechanism(s).

   . A set of one or more Group Speaker role authorization rules. In
     some groups the group members allowed to send protected packets is

   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). Each group member

Weis, et al.             Expires August, 2006                 [Page 8]

Internet-Draft     Multicast Extensions to RFC 4301         June, 2005

   receives the policy token (using a method not described in this memo)
   and verifies the Group Owner's signature on the policy token. If that
   GO signature is accepted, then the group member dynamically updates
   its PAD with the policy token's contents.

   The PAD MUST provide a management interface capability that allows an
   administrator to enforce that the scope of a 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
   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
   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 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 GKMP
   SAs used to download IPsec SAs [RFC3740, Section 4]. These SAs are
   collectively referred to as a Group Security Association (GSA). Concurrent 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 IPsec SA that maintains anti-replay state. A group
     that does not rely on IP Security anti-replay services can share
     one IPsec SA for all of its Group Speakers.

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

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 IPsec SAs
   as follows:

  - As a precursor to the Group Speaker beginning its re-key rollover
     continuity processing, the GCKS periodically multicasts a Re-Key
     Event (RKE) message to the group. The RKE multicast contains group
     policy directives, and new IPsec SA policy and keying material. In
     the absence of a reliable multicast transport protocol, the GCKS
     may re-transmit the RKE a policy defined number of times to improve
     the availability of re-key information.

  - The RKE multicast configures the group's SPD/SAD with the new IPsec
     SAs. Each IPsec SA that replaces an existing SA is called a
     "leading edge" IPsec SA. The leading edge IPsec SA has a new
     Security Parameter Index (SPI) and it is keyed by its associated
     keying material. For a short period after the GCKS multicasts the
     RKE, a Group Speaker does not yet transmit data using the leading
     edge IPsec SA. Meanwhile, other Group Members prepare to use this
     IPsec SA by installing the new IPsec SAs to their respective

  - After waiting a sufficiently long enough period such that all of
     the Group Members have processed the RKE multicast, the Group
     Speaker begins to transmit using the leading edge IPsec SA with its
     data encrypted by the new keying material. Only authorized Group
     Members can decrypt these IPsec SA multicast transmissions. The
     time delay that a Group Speaker waits before starting its first
     leading edge 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" SA is the oldest security
     association in use by the group for that speaker. All authorized
     Group Members can receive and decrypt data for this SA, but the
     Group Speaker does not transmit new data using the "trailing edge"
     SA after it has transitioned to the "leading edge GSA". The
     trailing edge SA is deleted by the group's endpoints according to
     group policy (e.g., after a defined period has elapsed)"

   This re-key rollover strategy allows the group to drain its in
   transit datagrams from the network while transitioning to the leading
   edge 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 [RFC3401], data origin authentication is a security
   service that verifies the identity of the claimed source of data.
   While HMAC authentication methods are 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.

   When the property of data origin authentication is required for an
   IPsec SA distributed from a GKCS, an authentication transform where
   the originator keeps a secret should be used. Two possible algorithms
   are TESLA [RFC4082] or RSA [RFC4359].

   In some cases, (e.g., digital signature authentication transforms)
   the processing cost of the algorithm is significantly greater than an
   HMAC authentication method. To protect against denial of service
   attacks from device that is not authorized to join the group, the
   IPsec SA using this algorithm may be encapsulated with an IPsec SA
   using an HMAC authentication algorithm. However, doing so requires
   the packet to be sent across the IPsec boundary for additional
   inbound processing [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 IKEv2 [RFC4306]. A fundamental
   GKMP IP Security subsystem requirement is that both the GKMP and
   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
   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 [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 IKEv2. Section 4.1.3 describes these

4.3.2 New Security Association Attributes

   A number of new security association attributes are defined in this
   document. Each GKMP supporting this architecture MUST support the
   following list of attributes described elsewhere in this document.

   - Address Preservation (Section 3.1). This attribute describes
   whether address preservation is to be applied to the SA on the source
   address, destination address, or both source and destination

   - 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 [RFC4301, Section 5], with the
   additions described below when these IP multicast extensions are

5.1 Outbound IP Multicast Traffic Processing

   If an IPsec SA is marked as supporting tunnel mode with address
   preservation (as described in Section 3.1), either or both of the
   outer header source or destination addresses is marked as being
   preserved. If the source address is marked as being preserved, during
   header construction the "src address" header field MUST be "copied
   from inner hdr" rather than "constructed" as described in [RFC4301].
   Similarly, If the destination address is marked as being preserved,
   during header construction the "dest address" header field MUST be
   "copied from inner hdr" rather than "constructed".

5.2 Inbound IP Multicast Traffic Processing

   If an IPsec SA is marked as supporting tunnel mode with address
   preservation (as described in Section 3.0), the marked address (i.e.,
   source and/or destination address) on the outer IP header MUST be
   verified to be the same value as the inner IP header. If the
   addresses are not consistent, the IPsec system MUST treat the error
   in the same manner as other invalid selectors, as described in
   [RFC4301, Section 5.2]. In particular the IPsec system MUST discard
   the packet, as well as treat the inconsistency as an auditable event.

6.0 Networking Issues

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.

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

   Both Mobile IPv4 [RFC3344] and Mobile IPv6 provide transparent
   unicast communications to a mobile Node. However, comparable support
   for secure multicast mobility management is not specified by these
   standards. The goal is the ability to maintain an end-to-end
   transport mode group SA between a Group Speaker mobile node that has
   a volatile care-of-address and a Group Receiver membership that also
   may have mobile endpoints. In particular, there is no secure
   mechanism for route optimization of the triangular multicast path
   between the correspondent Group Receiver Nodes, the home agent, and
   the mobile Node. Any proposed solution must be secure against hostile
   re-direct and flooding attacks. NAT Translation Mappings Are Not Predictable

   The following spontaneous NAT behaviors adversely impact source-
   specific secure multicast groups. When a NAT gateway is on the path
   between a Group Speaker residing behind a NAT and a public IPv4
   multicast Group Receiver, the NAT gateway alters the private source
   address to a public IPv4 address. This translation must be
   coordinated with every Group Receiver's inbound SPD multicast entries
   that depend on that source address as a traffic selector. One might
   mistakenly assume that the GCKS could set up the Group Members with
   an 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

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 GCKS may not have global consistent knowledge of a group
     endpoint's current public and private address mappings due to
     network errors or race conditions. For example, a Group Member's
     address may change due to a DHCP assigned address lease expiration.

  - Alternate paths may exist between a given pair of Group Members. If
     there are parallel NAT gateways along those paths, then the address
     translation state information at each NAT gateway may produce
     different translations on a per packet basis.

   The consequence of this problem is that the GCKS can not be pre-
   configured with NAT mappings, as the SPD at the Group Members will
   lose synchronization as soon as a NAT mapping changes due to any of
   the above events. In the worst case, Group Members in different
   sections of the network will see different NAT mappings, because the
   multicast packet traversed multiple NAT gateways.

6.1.2 Secondary Problems Created by NAT Traversal SSM Routing Dependency on Source IP Address

   Source-Specific Multicast (SSM) routing depends on a multicast
   packet's source IP address and multicast destination IP address to
   make a correct forwarding decision. However, a NAT gateway alters
   that packet's source IP address as its passes from a private network
   into the public network. Mobility changes a Group Member's point of
   attachment to the Internet, and this will change the packet's source
   IP address. Regardless of why it happened, this alteration in the
   source IP address makes it infeasible for transit multicast routers
   in the public Internet to know which SSM speaker originated the
   multicast packet, which in turn selects the correct multicast
   forwarding policy. ESP Cloaks Its Payloads from NAT Gateway

   When traversing NAT, application layer protocols that contain IPv4
   addresses in their payload need the intervention of an Application
   Layer Gateway (ALG) that understands that application layer protocol
   [RFC3027] [RFC3235]. The ALG massages the payload's private IPv4
   addresses into equivalent public IPv4 addresses. However, when
   encrypted by end-to-end ESP, such payloads are opaque to application
   layer gateways.

   When multiple Group Speakers reside behind a NAT with a single public
   IPv4 address, the NAT gateway can not do UDP or TCP protocol port

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
   [RFC3948] avoids this problem. However, this capability must be
   configured at the GCKS as a group policy, and it must be supported in
   unison by all of the group endpoints within the group, even those
   that reside in the public Internet. UDP Checksum Dependency on Source IP Address

   An IPsec subsystem using UDP within an ESP payload will encounter NAT
   induced problems. The original IPv4 source address is an input
   parameter into a receiver's UDP pseudo-header checksum verification,
   yet that value is lost after the IP header's address translation by a
   transit NAT gateway. The UDP header checksum is opaque within the
   encrypted ESP payload. Consequently, the checksum can not be
   manipulated by the transit NAT gateways. UDP checksum verification
   needs a mechanism that recovers the original source IPv4 address at
   the Group Receiver endpoints.

   In a transport mode multicast application GSA, the UDP checksum
   operation requires the origin endpoint's IP address to complete
   successfully. In IKEv2, this information is exchanged between the
   endpoints by a NAT-OA payload (NAT original address). See also
   reference [RFC3947]. A comparable facility must exist in a GKMP
   payload that defines the multicast application GSA attributes for
   each Group Speaker. Cannot Use AH with NAT Gateway

   The presence of a NAT gateway makes it impossible to use an
   Authentication Header, keyed by a group-wide key, to protect the
   integrity of the IP header for transmissions between members of the
   cryptographic group.

6.1.3 Avoidance of NAT Using an IPv6 Over IPv4 Network

   A straightforward and standards-based architecture that effectively
   avoids the GKMP interaction with NAT gateways is the IPv6 over IPv4
   transition mechanism [RFC2529]. In IPv6 over IPv4 (a.k.a. "6over4"),
   the underlying IPv4 network is treated as a virtual multicast-capable
   Local Area Network. The IPv6 traffic tunnels over that IPv4 virtual
   link layer.

   Applying GKMP/IPsec in a 6over4 architecture leverages the fact that
   an administrative domain deploying GKMP/IPsec would already be
   planning to deploy IPv4 multicast router(s). The group's IPv6
   multicast routing can execute in parallel to IPv4 multicast routing
   on that same physical router infrastructure. In particular, IPv6
   multicast routers operating with 6over4 mode enabled on their network

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 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 IPv4 with NAT deployment. In particular, new
   GKMP/IPsec multicast applications SHOULD prefer 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
     application layer protocol itself must embed references to IPv6
     addresses rather than IPv4 addresses within its payloads. For new
     applications, this may not be of consequence; it usually only
     becomes an issue if the application and its protocol has an
     embedded base.

  - An embedded base of GKMP/IPsec IPv4 multicast applications that are
     only available in binary form will not be able to migrate to these
     transitional IPv6 mechanisms.

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

6.1.4 GKMP/IPsec Multi-Realm IPv4 NAT Architecture

   In a multi-realm group, GKMP/IPsec security association endpoints may
   straddle any combination of IPv4 public addresses and private
   addresses [RFC1918]. In such cases, transport layer endpoint
   identifiers when resolved to their underlying private or public IPv4
   addresses entangle the GKMP protocol with NAT gateway behaviors. The
   NAT translation of 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 IPv4 NAT and Network
   Address Protocol Translation (NAPT) traversal. However, the attendant
   Group Owner configuration procedures are labor-intensive, prone to
   configuration mismatch errors between the GCKS and NAT gateways, and
   they do not scale well to large groups. Given the large number of
   documented NAT problems and its erosion of end-to-end security, new
   GKMP/IPsec applications and deployments SHOULD strongly prefer the
   use of IPv6.

Weis, et al.             Expires August, 2006                [Page 16]

Internet-Draft     Multicast Extensions to RFC 4301         June, 2005 GKMP/IPsec IPv4 NAT Architectural Assumptions

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

  - The secure multicast group destination address is a statically
     allocated public IPv4 multicast address known to all group

  - 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 IPv4
     addresses are globally unique. In this context, a "permanent" 6to4
     address means that the address is constant for the group's

  - Each private IPv4 address space has one or more NAT gateways
     directly connected to the IPv4 public Internet, and a packet does
     not have to traverse multiple private networks to reach the public
     Internet. This can be thought of as a "spoke and hub" configuration
     wherein the public Internet is the hub.

  - A GCKS may reside within one of the private networks, but it also
     MUST have a permanent public IPv4 address on at least one of its
     network interfaces.

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

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

  - Each of an administrative domain's NAT gateways are explicitly
     configured with static private/public address translation mappings
     for the 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 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. 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 cannot participate in NAPT. The multicast
   application GSA must be handled differently depending on whether the
   application requires source-specific multicast.

   If the application requires source-specific multicast routing, then
   there must be a separate public IP-v4 address statically reserved at
   the NAT gateway for each Group Speaker endpoint private/public
   address mapping. This constraint allows the GCKS to specify at every
   Group Member the inbound 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 GCKS 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
   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 GCKS configuration.

Weis, et al.             Expires August, 2006                [Page 18]

Internet-Draft     Multicast Extensions to RFC 4301         June, 2005

   If the application requires the any-source multicast service model,
   then the NAT gateway's source address translation can use dynamically
   allocated public IPv4 addresses rather than statically allocated IPv4
   addresses. However, unless the group uses UDP encapsulated ESP, then
   the NAT gateway must have a pool of public IPv4 addresses reserved
   that is at least as large as the number of Group Speaker endpoints
   within its private network. The public IP address pool allows the NAT
   gateway to do a one-to-one mapping from every Group Speaker
   endpoint's private source address to a dynamically allocated public
   source address. In this case, the use of NAPT rather than NAT is not
   an option, since the transport layer protocol is within an opaque ESP
   payload. The GCKS specifies the SPD/SAD traffic selector as the
   combination of the group's destination multicast address and the SPI.

   In some deployments, the number of public IPv4 addresses assigned to
   a NAT gateway is very limited (e.g. only one public IPv4 address).
   Also, it may be difficult to predict how many Group Speaker endpoints
   will reside within the private network before the group begins its
   operation. For these cases, the group MAY use UDP encapsulated ESP.
   The NAT gateway applies NAPT to the UDP header's source port field,
   sidestepping the constraint of its limited public IPv4 address pool.
   The Group Owner modifies the group policy 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 [RFC3948].

7.0 Security Considerations

   This document describes architecture for securing group network
   traffic using IPsec. As such, security considerations are found
   throughout this document.

8.0 IANA Considerations

   This document has no actions for IANA.

9.0 Acknowledgements


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 RFCs to Indicate
   Requirement Level", BCP 14, RFC 2119, March 1997.

Weis, et al.             Expires August, 2006                [Page 19]

Internet-Draft     Multicast Extensions to 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
   Internet Protocol", RFC 4301, December 2005.

   [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December

   [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
   4303, December 2004.

10.2 Informative References

   [COREPT] Colegrove, A., and H. Harney, "Group Security Policy Token
   v1", (work in progress), draft-ietf-msec-policy-token-sec-06.txt
   (work in progress), January 2006.

   [RFC2362] Estrin, D., et. al., "Protocol Independent Multicast-Sparse
   Mode (PIM-SM): Protocol  Specification",  RFC 2362, June 1998.
   [RFC2526] Johnson, D., and S. Deering., "Reserved IPv6 Subnet Anycast
   Addresses", RFC 2526, March 1999.

   [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
   Domains without Explicit Tunnels", RFC 2529, March 1999.

   [RFC2588] Finlayson, R., "IP Multicast and Firewalls", RFC 2588, May

   [RFC2709] Srisuresh, P., "Security Model with Tunnel-mode IPsec for
   NAT Domains", RFC 2709, October 1999.

   [RFC2914] Floyd, S., "Congestion Control Principles", RFC 2914,
   September 2000.

   [RFC3027] Holdrege, M., and P. Srisuresh, "Protocol Complications
   with 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 Management Protocol,
   Version 3", RFC 3376, October 2002.

Weis, et al.             Expires August, 2006                [Page 20]

Internet-Draft     Multicast Extensions to RFC 4301         June, 2005

   [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
   Group Domain of Interpretation", RFC 3547, December 2002.

   [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific
   Multicast (SSM)", RFC 3569, July 2003.

   [RFC3940] Adamson, B., et. al., "Negative-acknowledgment (NACK)-
   Oriented Reliable Multicast (NORM) Protocol", RFC 3940, November

   [RFC3947] Kivinen, T., et. al., "Negotiation of NAT-Traversal in the
   IKE", RFC 3947, January 2005.

   [RFC3948] Huttunen, A., et. al., "UDP Encapsulation of IPsec ESP
   Packets", RFC 3948, January 2005.

   [RFC4082] Perrig, A., et. al., "Timed Efficient Stream Loss-Tolerant
   Authentication (TESLA): Multicast Source Authentication Transform
   Introduction", RFC 4082, June 2005.

   [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC
   4306, December 2005.

   [RFC4359] Weis., B., "The Use of RSA/SHA-1 Signatures within
   Encapsulating Security Payload (ESP) and Authentication Header (AH)",
   RFC 4359, January 2006.

   [ZLLY03] Zhang, X., et. al., "Protocol Design for Scalable and
   Reliable Group Rekeying", IEEE/ACM Transactions on Networking (TON),
   Volume 11, Issue 6, December 2003. See

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.

A.1 Unidirectional Multicast Applications

   Multi-media content delivery multicast applications that do not have
   congestion notification or retransmission error recovery mechanisms
   are inherently unidirectional. RFC 4301 only defines bi-directional
   unicast security associations (as per sections 4.4.1 and 5.1 with
   respect to security association directionality). The 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 management interface MUST have the ability to
   setup a GKMP Subsystem group having a unidirectional GSA security

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 digital signature authentication is available (E.g., RFC
   4359), source authentication MAY be used to authenticate a receiver
   Node's transmission to the speaker. The 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.

   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.

A.3 Any-To-Any Multicast Applications

   Another family of secure multicast applications exhibits a "any to
   many" communications pattern. A representative example of such an
   application is a videoconference combined with an electronic

   For such applications, all (or a large subset) of the Group Members
   are authorized multicast speakers. In such service models, creating a
   distinct IPsec SA with anti-replay state for every potential speaker
   does not scale to large groups. The group SHOULD share one IPsec SA
   for all of its speakers. The IPsec SA SHOULD NOT use the IPsec anti-
   replay protection service for the speaker's multicast data flow to
   the Group Receivers.

   The 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-170

   Phone: +1-408-526-4796
   Email: bew@cisco.com

   George Gross
   IdentAware Security
   82 Old Mountain Road
   Lebanon, NJ 08833

   Phone: +1-908-268-1629
   Email: gmgross@identaware.com

   Dragan Ignjatic
   1000 W. 14th Street
   North Vancouver, BC V7P 3P3

   Phone: +1-604-982-3424
   Email: dignjatic@polycom.com

Weis, et al.             Expires August, 2006                [Page 24]

Internet-Draft     Multicast Extensions to 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.

   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

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.


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

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

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