MSEC Working Group                                              B. Weis
Internet-Draft                                            Cisco Systems
Intended status: Standards Track                               G. Gross
Expires: August 22, 2008                            IdentAware Security
                                                            D. Ignjatic
                                                                Polycom
                                                      February 22, 2008

    Multicast Extensions to the Security Architecture for the Internet
                                 Protocol
                 draft-ietf-msec-ipsec-extensions-08.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that
   any applicable patent or other IPR claims of which he or she is
   aware have been or will be disclosed, and any of which he or she
   becomes aware will be disclosed, in accordance with Section 6 of
   BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-Drafts
   as reference material or to cite them other than as "work in
   progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

 Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   The Security Architecture for the Internet Protocol describes
   security services for traffic at the IP layer. That architecture
   primarily defines services for Internet Protocol (IP) unicast
   packets. This document describes how the IPsec security services
   are applied to IP multicast packets. These extensions are relevant
   only for an IPsec implementation that supports multicast.





Weis                   Expires August 22, 2008               [Page 1]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008


Table of Contents

1. Introduction.....................................................3
  1.1 Scope.........................................................3
  1.2 Terminology...................................................4
2. Overview of IP Multicast Operation...............................6
3. Security Association Modes.......................................6
  3.1 Tunnel Mode with Address Preservation.........................7
4. Security Association.............................................8
  4.1 Major IPsec Databases.........................................8
    4.1.1 Group Security Policy Database (GSPD).....................8
    4.1.2 Security Association Database (SAD)......................11
    4.1.3 Group Peer Authorization Database (GPAD).................11
  4.2 Group Security Association (GSA).............................13
  4.3 Data Origin Authentication...................................16
  4.4 Group SA and Key Management..................................16
    4.4.1 Co-Existence of Multiple Key Management Protocols........16
    4.4.2 New Security Association Attributes......................17
5. IP Traffic Processing...........................................17
  5.1 Outbound IP Traffic Processing...............................17
  5.2 Inbound IP Traffic Processing................................18
6. Security Considerations.........................................21
  6.1 Security Issues Solved by IPsec Multicast Extensions.........21
  6.2 Security Issues Not Solved by IPsec Multicast Extensions.....21
    6.2.1 Outsider Attacks.........................................22
    6.2.2 Insider Attacks..........................................22
  6.3 Implementation or Deployment Issues that Impact Security.....23
    6.3.1 Homogeneous Group Cryptographic Algorithm Capabilities...23
    6.3.2 Groups that Span Two or More Security Policy Domains.....23
    6.3.3 Source-Specific Multicast Group Sender Transient Locators23
7. IANA Considerations.............................................24
8. Acknowledgements................................................24
9. References......................................................24
  9.1 Normative References.........................................24
  9.2 Informative References.......................................24
Appendix A - Multicast Application Service Models..................27
  A.1 Unidirectional Multicast Applications........................27
  A.2 Bi-directional Reliable Multicast Applications...............27
  A.3 Any-To-Any Multicast Applications............................28
Author's Address...................................................29
Full Copyright Statement...........................................29
Intellectual Property..............................................30




Weis, et al.           Expires August 22, 2008               [Page 2]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008


1. Introduction

   The Security Architecture for the Internet Protocol [RFC4301]
   provides security services for traffic at the IP layer. It
   describes an architecture for IPsec compliant systems, and a set of
   security services for the IP layer. These security services
   primarily describe services and semantics for IPsec Security
   Associations (SAs) shared between two IPsec devices. Typically,
   this includes SAs with traffic selectors that include a unicast
   address in the IP destination field, and results in an IPsec packet
   with a unicast address in the IP destination field. The security
   services defined in RFC 4301 can also be used to tunnel IP
   multicast packets, where the tunnel is a pairwise association
   between two IPsec devices.  RFC4301 defined manually keyed
   transport mode IPsec SA support for IP packets with a multicast
   address in the IP destination address field. However, RFC4301 did
   not define the interaction of an IPsec subsystem with a Group Key
   Management protocol or the semantics of a tunnel mode IPsec SA with
   an IP multicast address in the outer IP header.

   This document describes OPTIONAL 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 that result in an IPsec packet with an IP multicast
   address in the IP destination field. It also describes additional
   semantics for IPsec Group Key Management (GKM) subsystems. Note
   that this document uses the term "GKM protocol" generically and
   therefore it does not assume a particular GKM protocol.

   An IPsec implementation that does not supports multicast is not
   required to support these extensions.

   Throughout this document, RFC 4301 semantics remain unchanged by
   the presence these multicast extensions unless specifically noted
   to the contrary.

1.1 Scope

   The IPsec extensions described in this document support IPsec
   Security Associations that result in IPsec packets with IPv4 or
   IPv6 multicast group addresses as the destination address. Both
   Any-Source Multicast (ASM) and Source-Specific Multicast (SSM)
   [RFC3569] group addresses are supported. These extensions are used
   when management policy requires IP multicast packets protected by
   IPsec to remain IP multicast packets. When management policy
   requires that the IP multicast packets are encapsulated as IP
   unicast packets (e.g., because the network connected to the
   unprotected interface does not support IP multicast), the
   extensions in this document are not used.


Weis, et al.           Expires August 22, 2008               [Page 3]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008


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

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

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

   This version of the multicast IPsec extension specification
   requires that all IPsec devices participating in a Security
   Association are homogeneous. They MUST share a common set of
   cryptographic transform and protocol handling capabilities. The
   semantics of an "IPsec composite group" [COMPGRP], a heterogeneous
   IPsec cryptographic group formed from the union of two or more sub-
   groups, is an area for future standardization.

1.2 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119
   [RFC2119].


   The following key terms are used throughout this document.

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

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





Weis, et al.           Expires August 22, 2008               [Page 4]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008


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

   Group Key Management Subsystem
      A subsystem in an IPsec device implementing a Group Key
      Management protocol. The GKM subsystem provides IPsec SAs to
      the IPsec subsystem on the IPsec device. Refer to RFC 3547
      [RFC3547] and RFC 4535 [RFC4535] for additional information.

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

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

   Group Security Association (GSA)
      A collection of IPsec Security Associations (SAs) and GKM
      Subsystem SAs necessary for a Group Member to receive key
      updates. A GSA describes the working policy for a group. Refer
      to RFC 4046 [RFC4046] for additional information.

   Group Security Policy Database (GSPD)
      The GSPD is a multicast-capable security policy database, as
      mentioned in RFC3740 and RFC4301 section 4.4.1.1. Its semantics
      are a superset of the unicast SPD defined by RFC4301 section 
      4.4.1. Unlike a unicast SPD-S in which point-to-point traffic
      selectors are inherently bi-directional, multicast security
      traffic selectors in the GSPD-S introduce a "sender only",
      "receiver only" or "symmetric" directional attribute. Refer to
      section 4.1.1 for more details.

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

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

   Source-Specific Multicast (SSM)
      The Internet Protocol (IP) multicast service model as defined
      in RFC 3569 [RFC3569]. In this model, each combination of a
      sender and an IP multicast address is considered a group. This
      is known as an (S,G) group.

   Tunnel Mode with Address Preservation

Weis, et al.           Expires August 22, 2008               [Page 5]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008


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

2. Overview of IP Multicast Operation

   IP multicasting is a means of sending a single packet to a "host
   group", a set of zero or more hosts identified by a single IP
   destination address. IP multicast packets are delivered to all
   members of the group with either "best-efforts" reliability
   [RFC1112], or as part of a reliable stream (e.g., NORM) [RFC3940].

   A sender to an IP multicast group sets the destination of the
   packet to an IP address that has been allocated for IP multicast.
   Allocated IP multicast addresses are defined in RFC 3171, RFC 3306,
   and RFC 3307 [RFC3171] [RFC3306] [RFC3307]. Potential receivers of
   the packet "join" the IP multicast group by registering with a
   network routing device [RFC3376] [RFC3810], signaling its intent to
   receive packets sent to a particular IP multicast group.

   Network routing devices configured to pass IP multicast packets
   participate in multicast routing protocols (e.g., PIM-SM)
   [RFC4601]. Multicast routing protocols maintain state regarding
   which devices have registered to receive packets for a particular
   IP multicast group. When a router receives an IP multicast packet,
   it forwards a copy of the packet out of each interface for which
   there are known receivers.

3. Security Association Modes

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

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

   A security gateway implementation of IPsec MUST use a tunnel mode
   SA, for the reasons described in Section 4.1 of [RFC4301]. In
   particular, the security gateway needs to use tunnel mode to
   encapsulate incoming fragments, since IPsec cannot directly
   operate on fragments.


Weis, et al.           Expires August 22, 2008               [Page 6]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008


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. These semantics are due to the following unique
   requirements of IP multicast routing protocols (e.g., PIM-SM
   [RFC4601]). This document describes these new header construction
   semantics as "tunnel mode with address preservation", which are
   described as follows.

   - When an IP multicast packet is received by a host or router the
      destination address of the packet is compared to the local IP
      multicast state. If the destination of an IP multicast packet is
      changed the host or router receiving the IP multicast packet
      will not process it properly. Therefore, an IPsec host or
      security gateway needs to preserve the multicast IP destination
      address after IPsec tunnel encapsulation.

   - IP multicast routing protocols typically create multicast
      distribution trees based on the source address as well as the
      group address. If an IPsec security gateway changes the source
      address of an IP multicast packet (to its own IP address), the
      resulting IPsec protected packet may fail Reverse Path
      Forwarding (RPF) checks performed by other routers. A failed RPF
      check may result in the packet being dropped. To accommodate
      routing protocol RPF checks, the security gateway implementing
      the IPsec multicast extensions SHOULD preserve the original
      packet IP source address. However, it should be noted that a
      security gateway performing source address preservation will not
      receive ICMP PMTU or other messages intended for the security
      gateway. Security gateway applications not requiring source
      address preservation will be able to receive ICMP PMTU messages
      and process them as described in section 6.1 of RFC 4301.

   Because some applications of address preservation may require only
   the destination address to be preserved, specification of
   destination address preservation and source address preservation
   are separated in the above description. Destination address
   preservation and source address preservation attributes are
   described in the Group Security Policy Database (GSPD) (defined
   later in this document), and are copied into corresponding SAD
   entries.

   Address preservation is applicable only for tunnel mode IPsec SAs
   that specify the IP version of the encapsulating header to be the
   same version as that of the inner header. When the IP versions are
   different, IP multicast packets can be encapsulated using a tunnel
   interface, for example as described in [RFC4891], where the tunnel
   is also treated as an interface by IP multicast routing protocols.



Weis, et al.           Expires August 22, 2008               [Page 7]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008


   In summary, retaining both the IP source and destination addresses
   of the inner IP header allows IP multicast routing protocols to
   route a packet properly when the packet is protected by IPsec.
   This result is necessary in order for the multicast extensions to
   allow a host or security gateway to provide IPsec services for IP
   multicast packets. This method of RFC 4301 tunnel mode is known as
   "tunnel mode with address preservation".


4. Security Association

4.1 Major IPsec Databases

   The following sections describe the GKM Subsystem and IPsec
   extension interactions with the IPsec databases. The major IPsec
   databases need expanded semantics to fully support multicast.

4.1.1 Group Security Policy Database (GSPD)

   The Group Security Policy Database is a security policy database
   capable of supporting both unicast security associations as
   defined by RFC 4301 and the multicast extensions defined by this
   specification. The GSPD is considered to be the SPD, with the
   addition of the semantics relating to the multicast extensions
   described in this section.

   This document describes a new "Address Preservation" (AP) flag
   indicating that tunnel mode with address preservation is to be
   applied to a GSPD entry. The AP flag has two attributes: AP-L used
   in the processing of the local tunnel address, and AP-R used in the
   processing of the remote tunnel process. This flag is added to the
   GSPD "Processing info" field of the GSDP. The following text
   reproduced from Section 4.4.1.2 of RFC 4301 includes this
   additional processing. (Note: for brevity, only the Processing info
   related to tunnel processing has been reproduced.)

         o Processing info -- which action is required -- PROTECT,
           BYPASS, or DISCARD.  There is just one action that goes
           with all the selector sets, not a separate action for each
           set. If the required processing is PROTECT, the entry
           contains the following information.
            - IPsec mode -- tunnel or transport
            - (if tunnel mode) local tunnel address -- For a non
               mobile host, if there is just one interface, this is
               straightforward; if there are multiple interfaces, this
               must be statically configured.  For a mobile host, the
               specification of the local address is handled
               externally to IPsec. If tunnel mode with address
               preservation is specified for the local tunnel address,
               the AP-L attribute is set to TRUE for the local tunnel
               address and the local tunnel address is unspecified.

Weis, et al.           Expires August 22, 2008               [Page 8]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008


               The presence of the AP-L attribute indicates that the
               inner IP header source address will be copied to the
               outer IP header source address during IP header
               construction for tunnel mode.
            - (if tunnel mode) remote tunnel address -- There is no
               standard way to determine this.  See 4.5.3, "Locating a
               Security Gateway". If tunnel mode with address
               preservation is specified for the remote tunnel
               address, the AP-R attribute is set to TRUE for the
               remote tunnel address and the remote tunnel address is
               unspecified. The presence of the AP-R attribute
               indicates that the inner IP header destination address
               will be copied to the outer IP header destination
               address during IP header construction for tunnel mode.

   This document describes unique directionality processing for GSPD
   entries with a remote IP multicast address. Since an IP multicast
   address must not be sent as the source address of an IP packet
   [RFC1112], directionality of Local and Remote address and ports is
   maintained during incoming SPD-S and SPD-I checks rather than
   being swapped. Section 4.4.1 of RFC 4301 is amended as follows:

            Representing Directionality in an SPD Entry

               For traffic protected by IPsec, the Local and Remote
               address and ports in an SPD entry are swapped to
               represent directionality, consistent with IKE
               conventions.  In general, the protocols that IPsec
               deals with have the property of requiring symmetric
               SAs with flipped Local/Remote IP addresses. However,
               SPD entries with a remote IP multicast address do not
               have their Local and Remote address and ports in an
               SPD entry swapped during incoming SPD-S and SPD-I
               checks.

   A new Group Security Policy Database (GSPD) attribute is
   introduced: GSPD entry directionality. The following text is added
   to the bullet list of SPD fields described in Section 4.4.1.2 of
   RFC 4301.
         o Directionality -- can one of three types: "symmetric",
           "sender only" or "receiver only". "Symmetric" indicates
           that a pair of SAs are to be created (one in each
           direction as specified by RFC 4301). GSPD entries marked
           as "sender only" indicate that one SA is to be created in
           the outbound direction. GSPD entries marked as "receiver
           only" indicate that one SA is to be created in the inbound
           direction. GSPD entries marked as "sender only" or
           "receiver only" SHOULD support multicast IP addresses in
           their destination address selectors. If the processing
           requested is BYPASS or DISCARD and a "sender only" type is
           configured the entry SHOULD be put in GSPD-O only.

Weis, et al.           Expires August 22, 2008               [Page 9]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008


           Reciprocally, if the type is "receiver only", the entry
           SHOULD go to GSPD-I only.

   GSPD entries created by a GCKS may be assigned identical SPIs to
   SAD entries created by IKEv2 [RFC4306]. This is not a problem for
   the inbound traffic as the appropriate SAs can be matched using
   the algorithm described in RFC 4301 section 4.1. However, the
   outbound traffic needs to be matched against the GSPD selectors so
   that the appropriate SA can be created.

   To facilitate dynamic group keying, the outbound GSPD MUST
   implement a policy action capability that triggers a GKM protocol
   registration exchange (as per Section 5.1 of [RFC4301]). For
   example, the Group Sender GSPD policy might trigger on a match
   with a specified multicast application packet entering the
   implementation via the protected interface, or emitted by the
   implementation on the protected side of the boundary and directed
   toward the unprotected interface.. The ensuing Group Sender
   registration exchange would set up the Group Sender's outbound SAD
   entry that encrypts the multicast application's data stream. In
   the inverse direction, group policy may also set up an inbound
   IPsec SA.

   At the Group Receiver endpoint(s), the IPsec subsystem MAY use
   GSPD policy mechanisms (e.g., trigger on detection of IGMP/MLD
   join group exchange) that initiate a GKM protocol registration
   exchange. The ensuing Group Receiver registration exchange would
   set up the Group Receiver's inbound SAD entry that decrypts the
   multicast application's data stream. In the inverse direction, the
   group policy may also set up an outbound IPsec SA (e.g., when
   supporting an ASM service model).

   The IPsec subsystem MAY provide GSPD policy mechanisms that
   automatically initiate a GKM protocol de-registration exchange.
   De-registration allows a GCKS to minimize exposure of the group's
   secret key by re-keying a group on a group membership change
   event. It also minimizes cost on a GCKS for those groups that
   maintain member state. One such policy mechanism could be the
   detection of IGMP/MLD leave group exchange. However, a security
   gateway Group Member would not initiate a GKM protocol de-
   registration exchange until it detects that there are no more
   receivers behind a protected interface.

   Additionally, the GKM subsystem MAY set up the GSPD/SAD state
   information independent of the multicast application's state. In
   this scenario, the group's Group Owner issues management
   directives that tell the GKM subsystem when it should start GKM
   registration and de-registration protocol exchanges. Typically the
   registration policy strives to make sure that the group's IPsec
   subsystem state is "always ready" in anticipation of the multicast
   application starting its execution.

Weis, et al.           Expires August 22, 2008              [Page 10]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008



4.1.2 Security Association Database (SAD)

   The SAD contains an item describing whether tunnel or transport
   mode is applied to traffic on this SA. The text in RFC 4301 Section 
   4.4.2.1 is amended to describe Address Preservation.

         o IPsec protocol mode: tunnel or transport.  Indicates which
           mode of AH or ESP is applied to traffic on this SA. When
           tunnel mode is specified, the data item also indicates
           whether or not address preservation is applied to the
           outer IP header. Address preservation MUST NOT be
           specified when the IP version of the encapsulating header
           and IP version of the inner header do not match. The local
           address, remote address, or both addresses MAY be marked
           as being preserved during tunnel encapsulation.

   An inbound multicast SA MUST be configured with the source
   addresses of each Group Sender peer authorized to transmit to the
   multicast SA in question.

4.1.3 Group Peer Authorization Database (GPAD)

   The multicast IPsec extensions introduce a new data structure
   called the Group Peer Authorization Database (GPAD). Analogous to
   the PAD (refer to RFC 4301 section 4.4.3), the GPAD provides a link
   between a Group Key Management protocol and the SPD. The GPAD
   contains three group role authorization rule sets.

   A group role authorization rule set specifies which peers are
   authorized to participate in a group in a given Group Role. The
   GCKS GKM subsystem examines these rules to determine whether a
   candidate Group Member has the authority to join the group. A Group
   Member GKM subsystem uses these rules to decide which systems are
   authorized to act as a GCKS for a given group. The third group role
   authorization rule set determines which Group Members are
   authorized to send data to the group.

   When making a group role authorization decision, the GKM subsystem
   queries the GPAD with the 3-tuple {Group Identifier, Group Role,
   GKM ID}. These three GPAD search indices are defined as follows:

   . Group Identifier - The Group Identifier is an opaque byte string
      of IKE ID type Key ID that identifies a secure multicast group.
      The Group Identifier byte string MUST be at least four bytes
      long and less than 256 bytes long. The GPAD administrator MUST
      assign each Group Identifier a unique value within the scope of
      all secure multicast groups administered by the GPAD's security
      domain.



Weis, et al.           Expires August 22, 2008              [Page 11]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008


   . Group Role - There are three types of group roles: Group Member,
      Group Sender (i.e., a Group Member authorized to be a multicast
      sender), and GCKS. A Group Member may be authorized to act in
      more than one role within a given group.

   . GKM ID - The GKM ID is the identifier used in the GKM protocol's
      identification payload. The GKM protocol MUST support the six
      IKE ID payload types specified in RFC 4301 section 4.4.3.1.


   A Group Role authorization rule set is an ordered list of GPAD
   Entry Identifiers. GPAD Entry Identifiers have the same syntax and
   pattern matching semantics as the PAD Entry Identifiers defined in
   RFC 4301 section 4.4.3.1. Every group has three group role
   authorization rule sets, one group role authorization rule set per
   Group Role. Within the GPAD, the group authorization rule sets are
   indexed by the 2-tuple {Group Identifier, Group Role}.

   When the GKM subsystem needs to make an authorization decision, it
   linearly searches the selected group role authorization rule set
   until either it acquires a GPAD Entry Identifier match to the GKM
   ID, or it reaches the end of the rule set. A match authorizes the
   GKM ID to act in the specified Group Role. The no find condition
   indicates the GKM ID is not authorized for the requested Group
   Role.

   For long lived large-scale groups, there are operational and
   security benefits to having an automated and distributed group
   security policy management facility. The security policy changes
   can be rapidly propagated across the whole group membership rather
   than at the pace of manual administration at individual systems. In
   the context of the GPAD, the management facility promotes the
   timely and accurate introduction of newly authorized Group Members,
   updates to existing role authorizations, and the revocation of a
   compromised Group Member's role authorizations. The latter
   capability intercepts a compromised Group Member from re-joining
   the group.

   For example, some GKM protocols (e.g., GSAKMP [RFC4535]) distribute
   their group's GPAD, GSPD, and SAD configuration in a security
   policy token [RFC4534] signed by the group's policy authority, also
   known as the Group Owner (GO). Each Group Member GSAKMP subsystem
   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's GSAKMP
   subsystem dynamically updates the GPAD, GSPD, and SAD with the
   policy token's contents. Alternatively, the group's security policy
   management facility could be based on a trusted configuration
   management protocol rather than a GKM protocol.



Weis, et al.           Expires August 22, 2008              [Page 12]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008


   A group security policy management facility is not mandated by this
   specification. The GPAD MUST have a trusted management interface
   that allows the manual creation, editing, and deletion of the group
   role authorization rule sets. The GPAD, GSPD, and SAD databases MAY
   be configured by a group security policy management facility
   through that same management interface. How an IPsec subsystem
   implementation coordinates the manual and automated database
   modifications to avoid conflicts is a local matter outside the
   scope of this specification.

   The GPAD MUST provide a management interface capability that allows
   an administrator to enforce that the scope of a GKM group's policy
   specified GSPD/SAD modifications is restricted to only those
   traffic data flows that belong to that group. This authorization
   MUST be configurable at GKM group granularity. In the inverse
   direction, the GPAD management interface MUST provide a
   mechanism(s) to ensure that IKEv2 security associations do not
   negotiate traffic selectors that conflict or override GKM group
   policies.

4.2 Group Security Association (GSA)

   An IPsec implementation supporting these extensions will support a
   number of security associations: one or more IPsec SAs, and one or
   more GKM SAs used to download IPsec SAs [RFC3740]. These SAs are
   collectively referred to as a Group Security Association (GSA).

4.2.1 Concurrent IPsec SA Life Spans and Re-key Rollover

   During a secure multicast group's lifetime, multiple IPsec group
   security associations can exist concurrently. This occurs
   principally due to two reasons:

   - There are multiple Group Senders authorized in the group, each
     with its own IPsec SA which maintains anti-replay state. A group
     that does not rely on IP Security anti-replay services can share
     one IPsec SA for all of its Group Senders.

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

   The rekey continuity rollover algorithm depends on an IPsec SA
   management interface between the GKM subsystem and the IPsec
   subsystem. The IPsec subsystem MUST provide management interface
   mechanisms for the GKM subsystem to add IPsec SAs and to delete
   IPsec SAs. For illustrative purposes, this text defines the rekey
   rollover continuity algorithm in terms of two timer parameters
   that govern IPsec SA lifespans relative to the start of a group

Weis, et al.           Expires August 22, 2008              [Page 13]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008


   rekey event. However, it should be emphasized that the GKM
   subsystem interprets the group's security policy to direct the
   correct timing of IPsec SA activation and deactivation. A given
   group policy may choose timer values that differ from those
   recommended by this text. The two rekey rollover continuity timer
   parameters are:

   1. Activation Time Delay (ATD) - The ATD defines how long after the
      start of a rekey event to activate new IPsec SAs. The ATD
      parameter is expressed in units of seconds. Typically, the ATD
      parameter is set to the maximum time it takes to deliver a
      multicast message from the GCKS to all of the group's members.
      For a GCKS that relies on a Reliable Multicast Transport
      Protocol (RMTP), the ATD parameter could be set equal to the
      RTMP protocol's maximum error recovery time. When a RMTP is not
      present, the ATD parameter might be set equal to the network's
      maximum multicast message delivery latency across all of the
      group's endpoints. The ATD is a GKM group policy parameter. This
      value SHOULD be configurable at the Group Owner management
      interface on a per group basis.

   2. Deactivation Time Delay (DTD) - The DTD defines how long after
      the start of a rekey event to deactivate those IPsec SAs that
      are destroyed by the rekey event. The purpose of the DTD
      parameter is to minimize the residual exposure of a group's
      keying material after a rekey event has retired that keying
      material. The DTD is independent of and should not to be
      confused with the IPsec SA soft lifetime attribute. The DTD
      parameter is expressed in units of seconds. Typically, the DTD
      parameter would be set to the ADT plus the maximum time it takes
      to deliver a multicast message from the Group Sender to all of
      the group's members. For a Group Sender that relies on a RMTP,
      the DTD parameter could be set equal to ADT plus the RTMP
      protocol's maximum error recovery time. When a RMTP is not
      present, the DTD parameter might be set equal to ADT plus the
      network's maximum multicast message delivery latency across all
      of the group's endpoints. A GKM subsystem MAY implement the DTD
      as a group security policy parameter. If a GKM subsystem does
      not implement the DTD parameter then other group security policy
      mechanisms MUST determine when to deactivate an IPsec SA.

   Each group re-key multicast message sent by a GCKS signals the
   start of a new Group Sender IPsec SA time epoch, with each such
   epoch having an associated set of two IPsec SAs. Note that this
   document refers to re-key mechanisms as being multicast because of
   the inherent scalability of IP multicast distribution. However,
   there is no particular reason that re-keying mechanisms must be
   multicast. For example, [ZLLY03] describes a method of re-key
   employing both unicast and multicast messages.

   The group membership interacts with these IPsec SAs as follows:

Weis, et al.           Expires August 22, 2008              [Page 14]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008



   - As a precursor to the Group Sender beginning its re-key rollover
     continuity processing, the GCKS periodically multicasts a Re-Key
     Event (RKE) message to the group. The RKE multicast MAY contain
     group policy directives, new IPsec SA policy, and group keying
     material. In the absence of a RMTP, the GCKS may re-transmit the
     RKE a policy-defined number of times to improve the availability
     of re-key information. The GKM subsystem starts the ATD and DTD
     timers after it receives the last RKE retransmission.

   - The GKM subsystem interprets the RKE multicast to configure the
     group's GSPD/SAD with the new IPsec SAs. Each IPsec SA that
     replaces an existing SA is called a "leading edge" IPsec SA. The
     leading edge IPsec SA has a new Security Parameter Index (SPI)
     and its associated keying material keys it. For a time period of
     ATD seconds in duration after the GCKS multicasts the RKE, a
     Group Sender does not yet transmit data using the leading edge
     IPsec SA. Meanwhile, other Group Members prepare to use this
     IPsec SA by installing the new IPsec SAs to their respective
     GSPD/SAD.

   - After waiting for the ATD period, such that all of the Group
     Members have received and processed the RKE message, the GKM
     subsystem directs the Group Sender to begin to transmit using the
     leading edge IPsec SA with its data encrypted by the new keying
     material. Only authorized Group Members can decrypt these IPsec
     SA multicast transmissions.

   - The Group Sender's "trailing edge" SA is the oldest security
     association in use by the group for that sender. All authorized
     Group Members can receive and decrypt data for this SA, but the
     Group Sender does not transmit new data using the trailing edge
     IPsec SA after it has transitioned to the leading edge IPsec SA.
     The trailing edge IPsec SA is deleted by the group's GKM
     subsystems after the DTD time period has elapsed since the RKE
     transmission.

   This re-key rollover strategy allows the group to drain its in
   transit datagrams from the network while transitioning to the
   leading edge IPsec SA. Staggering the roles of each respective
   IPsec SA as described above improves the group's synchronization
   even when there are high network propagation delays. Note that due
   to group membership joins and leaves, each Group Sender IPsec SA
   time epoch may have a different group membership set.

   It is a group policy decision whether the re-key event transition
   between epochs provides forward and backward secrecy. The group's
   re-key protocol keying material and algorithm (e.g., Logical Key
   Hierarchy, refer to [RFC2627] and Appendix A of [RFC4535]) enforces
   this policy. Implementations MAY offer a Group Owner management
   interface option to enable/disable re-key rollover continuity for a

Weis, et al.           Expires August 22, 2008              [Page 15]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008


   particular group. This specification requires that a GKM/IPsec
   implementation MUST support at least two concurrent IPsec SA per
   Group Sender and this re-key rollover continuity algorithm.


4.3 Data Origin Authentication

   As defined in [RFC4301], data origin authentication is a security
   service that verifies the identity of the claimed source of data.
   A Message Authentication Code (MAC) is often used to achieve data
   origin authentication for connections shared between two parties.
   However, typical MAC authentication methods using a single shared
   secret are not sufficient to provide data origin authentication
   for groups with more than two parties. With a MAC algorithm, every
   group member can use the MAC key to create a valid MAC tag,
   whether or not they are the authentic originator of the group
   application's data.

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

   In some cases, (e.g., digital signature authentication transforms)
   the processing cost of the algorithm is significantly greater than
   an HMAC authentication method. To protect against denial of
   service attacks from a device that is not authorized to join the
   group, the IPsec SA using this algorithm may be encapsulated with
   an IPsec SA using a MAC authentication algorithm. However, doing
   so requires the packet to be sent across the IPsec boundary a
   second time for additional inbound processing (see Section 5.2 of
   [RFC4301]). This use of AH or ESP encapsulated within AH or ESP
   accommodates the constraint that AH and ESP define an Integrity
   Check Value (ICV) for only a single authenticator transform.

4.4 Group SA and Key Management

4.4.1 Co-Existence of Multiple Key Management Protocols

   Often, the GKM subsystem will be introduced to an existent IPsec
   subsystem as a companion key management protocol to IKEv2
   [RFC4306]. A fundamental GKM protocol IP Security subsystem
   requirement is that both the GKM protocol and IKEv2 can
   simultaneously share access to a common Group Security Policy
   Database and Security Association Database. The mechanisms that
   provide mutually exclusive access to the common GSPD/SAD data
   structures are a local matter. This includes the GSPD-outbound
   cache and the GSPD-inbound cache. However, implementers should note
   that IKEv2 SPI allocation is entirely independent from GKM SPI
   allocation because group security associations are qualified by a
   destination multicast IP address and may optionally have a source

Weis, et al.           Expires August 22, 2008              [Page 16]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008


   IP address qualifier. See [RFC4303, Section 2.1] for further
   explanation.

   The Peer Authorization Database does require explicit coordination
   between the GKM protocol and IKEv2. Section 4.1.3 describes these
   interactions.

4.4.2 New Security Association Attributes

   A number of new security association attributes are defined to
   convey extensions defined in this document. Each GKM protocol
   supporting this architecture MUST support the following list of
   attributes described elsewhere in this document.

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

   - Directional attribute (Section 4.1.1). This attribute describes
   whether a pair of SAs (one in each direction) is to be installed
   (to match the "symmetric" SPD directionality), only in the
   outbound direction (to match "receiver only" SPD directionality),
   or only in the inbound direction (to match "sender only" SPD
   directionality).

   - Any of the cryptographic transform-specific parameters and keys
   that are sent from the GCKS to the Group Members (e.g., data
   origin authentication parameters as described in section 4.3).

   - Re-key rollover procedure time intervals (section 4.2.1). The
   time that the Group Receiver IPsec subsystems will wait after
   creating the leading edge IPsec SA before they will retire the
   trailing edge IPsec SA. Also, the time that the Group Sender will
   delay before it starts transmitting on the leading edge's IPsec
   SA.

5. IP Traffic Processing

   Processing of traffic follows Section 5 of [RFC4301], with the
   additions described below when these IP multicast extensions are
   supported.

5.1 Outbound IP Traffic Processing

   If an IPsec SA is marked as supporting tunnel mode with address
   preservation (as described in Section 3.1), either or both of the
   outer header source or destination addresses are marked as being
   preserved.



Weis, et al.           Expires August 22, 2008              [Page 17]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008


   Header construction for tunnel mode is described in Section 5.1.2
   of RFC 4301. The first bullet of that section is amended as
   follows:

         o If address preservation is not marked in the SAD entry for
           either the outer IP header Source Address or Destination
           Address, the outer IP header Source Address and
           Destination Address identify the "endpoints" of the tunnel
           (the encapsulator and decapsulator). If address
           preservation is marked for the IP header Source Address,
           it is copied from the inner IP header Source Address. If
           address preservation is marked for the IP header
           Destination Address, it is copied from the inner IP header
           Destination Address. The inner IP header Source Address
           and Destination Addresses identify the original sender and
           recipient of the datagram (from the perspective of this
           tunnel), respectively. Address preservation MUST NOT be
           marked when the IP version of the encapsulating header and
           IP version of the inner header do not match.

   Note (3) regarding construction of tunnel addresses in Section
   5.1.2.1 of RFC 4301 is amended as follows:

         (3) Unless marked for address preservation Local and Remote
              addresses depend on the SA, which is used to determine
              the Remote address, which in turn determines which Local
              address (net interface) is used to forward the packet.
              If address preservation is marked for the Local address,
              it is copied from the inner IP header. If address
              preservation is marked for the Remote address, that
              address is copied from the inner IP header.

5.2 Inbound IP Traffic Processing

   IPsec-protected packets generated by an IPsec device supporting
   these multicast extensions may (depending on its GSPD policy)
   preserve a destination address such that the IP destination address
   is not an IPsec device. This requires an IPsec device supporting
   these multicast extensions to process IP traffic that is not
   addressed to the IPsec device itself. The following additions to
   IPsec inbound IP traffic processing are necessary.

   For compatibility with RFC 4301, the phrase "addressed to this
   device" is taken to mean packets with a unicast destination address
   belonging to the system itself, and multicast packets that are
   received by the system itself. However, multicast packets not
   received by the IPsec device are not considered addressed to this
   device.




Weis, et al.           Expires August 22, 2008              [Page 18]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008


   The discussion of processing Inbound IP Traffic described in
   Section 5.2 of RFC 4301 is amended as follows. The first dash in
   item 2 is amended as follows:

         - If the packet appears to be IPsec protected and it is
            addressed to this device, or appears to be IPsec protected
            and is addressed to a multicast group, an attempt is made
            to map it to an active SA via the SAD.

   A new item is added to the list between items 3a and 3b to describe
   processing of IPsec packets with destination address preservation
   applied:

         3aa. If the packet is addressed to a multicast group and AH
            or ESP is specified as the protocol, the packet is looked
            up in the SAD. Use the SPI plus the destination or SPI
            plus destination and source addresses, as specified in
            Section 4.1. If there is no match, the packet is directed
            to SPD-I lookup. Note that if the IPsec device is a
            security gateway, and the SPD-I policy is to PYPASS the
            packet, a subsequent security gateway along the routed
            path of the multicast packet may decrypt the packet.

   Figure 3 in RFC 4301 is updated to show the new processing path
   defined in item 3aa.



























Weis, et al.           Expires August 22, 2008              [Page 19]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008


                       Unprotected Interface
                                |
                                V
                             +-----+   IPsec protected
         ------------------->|Demux|-------------------+
         |                   +-----+                   |
         |                      |                      |
         |            Not IPsec |                      |
         |                      |  IPsec protected not |
         |                      V  addressed to device |
         |     +-------+    +---------+ and not in SAD |
         |     |DISCARD|<---|SPD-I (*)|<------------+  |
         |     +-------+    +---------+             |  |
         |                   |                      |  |
         |                   |-----+                |  |
         |                   |     |                |  |
         |                   |     V                |  |
         |                   |  +------+            |  |
         |                   |  | ICMP |            |  |
         |                   |  +------+            |  |
         |                   |                      |  V
      +---------+            |                   +-----------+
  ....|SPD-O (*)|............|...................|PROCESS(**)|...IPsec
      +---------+            |                   | (AH/ESP)  | Boundary
         ^                   |                   +-----------+
         |                   |       +---+             |
         |            BYPASS |   +-->|IKE|             |
         |                   |   |   +---+             |
         |                   V   |                     V
         |               +----------+          +---------+   +----+
         |--------<------|Forwarding|<---------|SAD Check|-->|ICMP|
           nested SAs    +----------+          | (***)   |   +----+
                               |               +---------+
                               V
                       Protected Interface

            Figure 1.  Processing Model for Inbound Traffic
                       (amending Figure 3 of RFC 4301)


   The discussion of processing Inbound IP Traffic described in
   Section 5.2 of RFC 4301 is amended to insert a new item 6 as
   follows.

         6. If an IPsec SA is marked as supporting tunnel mode with
           address preservation (as described in Section 3.1), the

Weis, et al.           Expires August 22, 2008              [Page 20]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008


           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 discard the packet, as
           well as treat the inconsistency as an auditable event.


6. Security Considerations

   The IP security multicast extensions defined by this specification
   build on the unicast-oriented IP security architecture [RFC4301].
   Consequently, this specification inherits many of the RFC4301
   security considerations and the reader is advised to review it as
   companion guidance.

6.1 Security Issues Solved by IPsec Multicast Extensions

   The IP security multicast extension service provides the following
   network layer mechanisms for secure group communications:

   - Confidentiality using a group shared encryption key.

   - Group source authentication and integrity protection using a
     group shared authentication key.

   - Group Sender data origin authentication using a digital
     signature, TESLA, or other mechanism.

   - Anti-replay protection for a limited number of Group Senders
     using the ESP (or AH) sequence number facility.

   - Filtering of multicast transmissions identified with a source
     address of systems that are not authorized by group policy to be
     Group Senders. This feature leverages the IPsec state-less
     firewall service (i.e., SPD-I and/or SDP-O entries with a packet
     disposition specified as DISCARD).

   In support of the above services, this specification enhances the
   definition of the SPD, PAD, and SAD databases to facilitate the
   automated group key management of large-scale cryptographic groups.

6.2 Security Issues Not Solved by IPsec Multicast Extensions

   As noted in RFC4301 section 2.2, it is out of scope of this
   architecture to defend the group's keys or its application data
   against attacks targeting vulnerabilities of the operating
   environment in which the IPsec implementation executes. However, it
   should be noted that the risk of attacks originating by an
   adversary in the network is magnified to the extent that the group
   keys are shared across a large number of systems.


Weis, et al.           Expires August 22, 2008              [Page 21]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008


   The security issues that are left unsolved by the IPsec multicast
   extension service divide into two broad categories: outsider
   attacks, and insider attacks.

6.2.1 Outsider Attacks

   The IPsec multicast extension service does not defend against an
   Adversary outside of the group who has:

   - the capability to launch a multicast flooding denial-of-service
     attack against the group, originating from a system whose IPsec
     subsystem does not filter the unauthorized multicast
     transmissions.

   - compromised a multicast router, allowing the Adversary to corrupt
     or delete all multicast packets destined for the group endpoints
     downstream from that router.

   - captured a copy of an earlier multicast packet transmission and
     then replayed it to a group that does not have the anti-replay
     service enabled. Note that for a large-scale any-source multicast
     group, it is impractical for the Group Receivers to maintain an
     anti-replay state for every potential Group Sender. Group
     policies that require anti-replay protection for a large-scale
     any-source-multicast group should consider an application layer
     total order multicast protocol.

6.2.2 Insider Attacks

   For large-scale groups, the IP security multicast extensions are
   dependent on an automated Group Key Management protocol to
   correctly authenticate and authorize trustworthy members in
   compliance to the group's policies. Inherent in the concept of a
   cryptographic group is a set of one or more shared secrets
   entrusted to all of the group's members. Consequently, the
   service's security guarantees are no stronger than the weakest
   member admitted to the group by the GKM system. The GKM system is
   responsible for responding to compromised group member detection by
   executing a re-key procedure. The GKM re-keying protocol will expel
   the compromised group members and distribute new group keying
   material to the trusted members. Alternatively, the group policy
   may require the GKM system to terminate the group.

   In the event that an Adversary has been admitted into the group by
   the GKM system, the following attacks are possible and they can not
   be solved by the IPsec multicast extension service:

   - The Adversary can disclose the secret group key or group data to
     an unauthorized party outside of the group. After a group key or
     data compromise, cryptographic methods such as traitor tracing or


Weis, et al.           Expires August 22, 2008              [Page 22]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008


     watermarking can assist in the forensics process. However, these
     methods are outside the scope of this specification.

   - The insider Adversary can forge packet transmissions that appear
     to be from a peer group member. To defend against this attack for
     those Group Sender transmissions that merit the overhead, the
     group policy can require the Group Sender to multicast packets
     using the data origin authentication service.

   - If the group's data origin authentication service uses digital
     signatures, then the insider Adversary can launch a computational
     resource denial of service attack by multicasting bogus signed
     packets.

6.3 Implementation or Deployment Issues that Impact Security

6.3.1 Homogeneous Group Cryptographic Algorithm Capabilities

   The IP security multicast extensions service can not defend against
   a poorly considered group security policy that allows a weaker
   cryptographic algorithm simply because all of the group's endpoints
   are known to support it. Unfortunately, large-scale groups can be
   difficult to upgrade to the current best in class cryptographic
   algorithms. One possible approach to solving many of these problems
   is the deployment of composite groups that can straddle
   heterogeneous groups [COMPGRP]. A standard solution for
   heterogeneous groups is an activity for future standardization. In
   the interim, synchronization of a group's cryptographic
   capabilities could be achieved using a secure and scalable software
   distribution management tool.

6.3.2 Groups that Span Two or More Security Policy Domains

   Large-scale groups may span multiple legal jurisdictions (e.g
   countries) that enforce limits on cryptographic algorithms or key
   strengths. As currently defined, the IPsec multicast extension
   service requires a single group policy per group. As noted above,
   this problem remains an area for future standardization.

6.3.3 Source-Specific Multicast Group Sender Transient Locators

   A Source Specific Multicast (SSM) Group Sender's source IP address
   can dynamically change during a secure multicast group's lifetime.
   Examples of the events that can cause the Group Sender's source
   address to change include but are not limited to NAT, a mobility
   induced change in the care-of-address, and a multi-homed host
   using a new IP interface. The change in the Group Sender's source
   IP address will cause those GSPD entries related to that multicast
   group to become out of date with respect to the group's multicast
   routing state. In the worst case, there is a risk that the Group
   Sender's data originating from a new source address will be BYPASS

Weis, et al.           Expires August 22, 2008              [Page 23]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008


   processed by a security gateway. If this scenario was not
   anticipated, then it could leak the group's data. Consequently, it
   is recommended that SSM secure multicast groups have a default
   DISCARD policy for all unauthorized Group Sender source IP
   addresses for the SSM group's destination IP address.

7. IANA Considerations

   This document has no actions for IANA.

8. Acknowledgements

   The authors wish to thank Steven Kent, Russ Housley, Pasi Eronen,
   and Tero Kivinen for their helpful comments.

   The "Guidelines for Writing RFC Text on Security Considerations"
   [RFC3552] was consulted to develop the Security Considerations
   section of this memo.

9. References

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

   [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
             Internet Protocol", RFC 4301, December 2005.

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

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

9.2 Informative References

   [COMPGRP] Gross G. and H. Cruickshank, "Multicast IP Security
             Composite Cryptographic Groups", draft-ietf-msec-ipsec-
             composite-group-01.txt, work in progress, February 2007.

   [RFC2526] Johnson, D., and S. Deering, "Reserved IPv6 Subnet
             Anycast Addresses", RFC 2526, March 1999.

   [RFC2627] Wallner, D., Harder, E. and R. Agee, "Key Management for
             Multicast: Issues and Architectures", RFC 2627,
             September 1998.


Weis, et al.           Expires August 22, 2008              [Page 24]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008


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

   [RFC3171] Albanni, Z., et al., "IANA Guidelines for IPv4
             Multicast Address Assignments", RFC 3171, August 2001.

   [RFC3306] Haberman B. and D. Thaler, "Unicast-Prefix-based IPv6
             Multicast Addresses", RFC3306, August 2002.

   [RFC3307] Haberman B., "Allocation Guidelines for IPv6 Multicast
             Addresses", RFC3307, August 2002.

   [RFC3376] Cain, B., et al., "Internet Group Management Protocol,
             Version 3", RFC 3376, October 2002.

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

   [RFC3552] Rescorla, E., et al., "Guidelines for Writing RFC Text on
             Security Considerations", RFC 3552, July 2003.

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

   [RFC3740] Hardjono, T., and B. Weis, "The Multicast Group Security
             Architecture", RFC 3740, March 2004.

   [RFC3810] Vida, R., and L. Costa, "Multicast Listener Discovery
             Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

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

   [RFC4046] Baugher, M., Dondeti, L., Canetti, R., and F. Lindholm,
             "Multicast Security (MSEC) Group Key Management
             Architecture", RFC4046, April 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.


Weis, et al.           Expires August 22, 2008              [Page 25]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008


   [RFC4534] Colegrove, A., and H. Harney, "Group Security Policy
             Token v1", RFC 4534, June 2006.

   [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross,
             "GSAKMP: Group Secure Association Key Management
             Protocol", RFC 4535, June 2006.

   [RFC4601] Fenner, B., et al., "Protocol Independent Multicast -
             Sparse Mode (PIM-SM): Protocol  Specification
             (Revised)",  RFC 4601, August 2006.

   [RFC4891] Graveman R., et al., "Using IPsec to Secure IPv6-in-IPv4
             Tunnels", RFC 4891, May 2007.

   [ZLLY03] Zhang, X., et al., "Protocol Design for Scalable and
             Reliable Group Rekeying", IEEE/ACM Transactions on
             Networking (TON), Volume 11, Issue 6, December 2003. See
             http://www.cs.utexas.edu/users/lam/Vita/Cpapers/ZLLY01.p
             df.

































Weis, et al.           Expires August 22, 2008              [Page 26]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008


Appendix A - Multicast Application Service Models

   The vast majority of secure multicast applications can be
   catalogued by their service model and accompanying intra-group
   communication patterns. Both the Group Key Management (GKM)
   Subsystem and the IPsec subsystem MUST be able to configure the
   GSPD/SAD security policies to match these dominant usage scenarios.
   The GSPD/SAD policies MUST include the ability to configure both
   Any-Source-Multicast groups and Source-Specific-Multicast groups
   for each of these service models. The GKM Subsystem management
   interface MAY include mechanisms to configure the security policies
   for service models not identified by this standard.

A.1 Unidirectional Multicast Applications

   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 traffic selectors (as per sections 4.4.1 and
   5.1 with respect to traffic selector directionality). The GKM
   Subsystem requires that the IPsec subsystem MUST support
   unidirectional SPD entries, which cause a Group Security
   Association (GSA) to be installed in only one direction. Multicast
   applications that have only one group member authorized to transmit
   can use this type of group security association to enforce that
   group policy. In the inverse direction, the GSA does not have a SAD
   entry, and the GSPD configuration is optionally set up to discard
   unauthorized attempts to transmit unicast or multicast packets to
   the group.

   The GKM Subsystem's management interface MUST have the ability to
   set up a GKM Subsystem group having a unidirectional GSA security
   policy.

A.2 Bi-directional Reliable Multicast Applications

   Some secure multicast applications are characterized as one Group
   Sender to many receivers, but with inverse data flows required by a
   reliable multicast transport protocol (e.g., NORM). In such
   applications, the data flow from the sender is multicast, and the
   inverse flow from the group's receivers is unicast to the sender.
   Typically, the inverse data flows carry error repair requests and
   congestion control status.

   For such applications, it is advantageous to use the same IPsec SA
   for protection of both unicast and multicast data flows. This does
   introduce one risk: the IKEv2 application may choose the same SPI
   for receiving unicast traffic as the GCKS chooses for a group
   IPsec SA covering unicast traffic. If both SAs are installed in
   the SAD, the SA lookup may return the wrong SPI as the result of
   an SA lookup. To avoid this problem, IPsec SAs installed by the

Weis, et al.           Expires August 22, 2008              [Page 27]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008


   GKM SHOULD use the 2-tuple {destination IP address, SPI} to
   identify each IPsec SA. In addition, the GKM SHOULD use a unicast
   destination IP address that does not match any destination IP
   address in use by an IKE-v2 unicast IPsec SA. For example, suppose
   a Group Member is using both IKEv2 and a GKM protocol, and the
   group security policy requires protecting the NORM inverse data
   flows as described above. In this case, group policy SHOULD
   allocate and use a unique unicast destination IP address
   representing the NORM Group Sender. This address would be
   configured in parallel to the Group Sender's existing IP
   addresses. The GKM subsystems at both the NORM Group Sender and
   Group Receiver endpoints would install the IPsec SA protecting the
   NORM unicast messages such that the SA lookup uses the unicast
   destination address as well as the SPI.

   The GSA SHOULD use IPsec anti-replay protection service for the
   sender's multicast data flow to the group's receivers. Because of
   the scalability problem described in the next section, it is not
   practical to use the IPsec anti-replay service for the unicast
   inverse flows. Consequently, in the inverse direction the IPsec
   anti-replay protection MUST be disabled. However, the unicast
   inverse flows can use the group's IPsec group authentication
   mechanism. The group receiver's GSPD entry for this GSA SHOULD be
   configured to only allow a unicast transmission to the sender node
   rather than a multicast transmission to the whole group.

   If an ESP digital signature authentication is available (e.g., RFC
   4359), source authentication MAY be used to authenticate a receiver
   node's transmission to the sender. The GKM protocol MUST define a
   key management mechanism for the Group Sender to validate the
   asserted signature public key of any receiver node without
   requiring that the sender maintain state about every group
   receiver.

   This multicast application service model is RECOMMENDED because it
   includes congestion control feedback capabilities. Refer to
   [RFC2914] for additional background information.

   The GKM Subsystem's Group Owner management interface MUST have the
   ability to set up a symmetric GSPD entry and one Group Sender. The
   management interface SHOULD be able to configure a group to have at
   least 16 concurrent authorized senders, each with their own GSA
   anti-replay state.

A.3 Any-To-Any Multicast Applications

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


Weis, et al.           Expires August 22, 2008              [Page 28]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008


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

   The GKM Subsystem's management interface MUST have the ability to
   set up a group having an Any-To-Many Multicast GSA security policy.


Author's Address

   Brian Weis
   Cisco Systems
   170 W. Tasman Drive,
   San Jose, CA 95134-1706
   USA

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

   George Gross
   IdentAware Security
   977 Bates Road
   Shoreham, VT 05770
   USA

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

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

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



Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.


Weis, et al.           Expires August 22, 2008              [Page 29]


Internet-Draft     Multicast Extensions to RFC 4301  February 22, 2008


   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, THE IETF TRUST 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.

   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 provided by the IETF
   Administrative Support Activity (IASA).
















Weis, et al.           Expires August 22, 2008              [Page 30]