WDIFF

draft-ietf-msec-ipsec-extensions-07.txt --> draft-ietf-msec-ipsec-extensions-08.txt

Internet-Draft Cisco Systems
Intended status: Standards Track G. Gross
Expires: June 9, August 22, 2008 IdentAware Security
D. Ignjatic
Polycom
December 9, 2007
February 22, 2008

Multicast Extensions to the Security Architecture for the Internet
Protocol
draft-ietf-msec-ipsec-extensions-07.txt
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.

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. It also defines services for manually keyed Security
Associations (SAs) matching IP multicast traffic selectors. This document further defines describes how the IPsec security services for manually and
dynamically keyed SAs matching
are applied to IP multicast traffic selectors
within packets. These extensions are relevant
only for an IPsec implementation that Security Architecture. supports multicast.

Weis Expires June 9, August 22, 2008 [Page 1]

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

Table of Contents

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

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

Internet-Draft Multicast Extensions to RFC 4301 December 2007 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
results 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] [RFC3376] 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

Weis, et al. Expires June 9, 2008 [Page 3]

Internet-Draft Multicast Extensions to RFC 4301 December 2007
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.

Weis, et al. Expires June 9, 2008 [Page 4]

Internet-Draft Multicast Extensions to RFC 4301 December 2007

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 UDP data packets delivered to all
members of the group with either "best-effort" "best-efforts" reliability
[RFC1112], or as part of a reliable delivery stream (e.g., NORM) [RFC3940].

Weis, et al. Expires June 9, 2008 [Page 5]

Internet-Draft Multicast Extensions to RFC 4301 December 2007

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 or 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 using the multicast
extensions 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", and is which are
described as follows.

- When an IP multicast routing protocols compare packet is received by a host or router the
destination address
on a of the packet is compared to the local IP
multicast routing state. If the destination of an IP multicast packet is
changed it the host or router receiving the IP multicast packet
will no longer be
properly routed. not process it properly. Therefore, an IPsec host or
security gateway needs to

Weis, et al. Expires June 9, 2008 [Page 6]

Internet-Draft Multicast Extensions to RFC 4301 December 2007 preserve the multicast IP destination
address after IPsec tunnel encapsulation.

The GKM Subsystem on a security gateway implementing the IPsec
multicast extensions preserves the multicast IP address as
follows. Firstly, the GKM Subsystem sets the Remote Address PFP
flag in the GSPD-S entry for the traffic selectors. This flag
causes the remote address of the packet matching IPsec SA
traffic selectors to be propagated to the IPsec tunnel
encapsulation. Secondly, the GKM Subsystem needs to signal that
destination address preservation is in effect for a particular
IPsec SA. The GKM protocol MUST define an attribute that signals
destination address preservation to the GKM Subsystem on an
IPsec security gateway.

- IP multicast routing protocols also typically create multicast
distribution trees based on the source address as well as the
group address. If an IPsec security gateway changes the source
address of an IP multicast packet (e.g., to (to its own IP address), the
resulting IPsec protected packet may fail Reverse Path
Forwarding (RPF) checks
on performed by other routers. A failed RPF
check may result in the packet being dropped. To accommodate
routing protocol RPF checks, the GKM Subsystem on
a security gateway implementation implementing
the IPsec multicast extensions needs to SHOULD preserve the original
packet IP source address as follows. Firstly, the GSPD-S entry for the
traffic selectors sets the Source Address PFP flag. This flag
causes the remote address to address. However, it should be propagated to the IPsec SA.
Secondly, the GKM Subsystem needs to signal noted that a
security gateway performing source address preservation is in effect will not
receive ICMP PMTU or other messages intended for a particular IPsec SA. The GKM
Subsystem MUST define a protocol attribute that signals the security
gateway. Security gateway applications not requiring source
address preservation will be able to the GKM Subsystem on an IPsec security
gateway.

Some receive ICMP PMTU messages
and process them as described in section 6.1 of RFC 4301.

Because some applications of address preservation may only require only
the destination address to be preserved. For this reason, the 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 processing semantics
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 MUST
be followed. February 22, 2008

In summary, retaining both the IP source and destination addresses
of the inner IP header allow allows IP multicast routing protocols to
route the a packet irrespective of properly when the packet being 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

Weis, et al. Expires June 9, 2008 [Page 7]

Internet-Draft Multicast Extensions to RFC 4301 December 2007 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 needed 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 implementing supporting both unicast security associations as
defined by RFC4301 RFC 4301 and the multicast extensions defined by this
specification. A new Group Security Policy Database (GSPD)
attribute is introduced: GSPD entry directionality. Directionality
can take three types. Each The GSPD entry can is considered to be marked "symmetric",
"sender only" or "receiver only". "Symmetric" GSPD entries are the
common entries as specified by RFC 4301. "Symmetric" SHOULD be SPD, with the
addition of the semantics relating to the
default directionality unless specified otherwise. GSPD entries
marked as "sender only" or "receiver only" SHOULD support multicast IP addresses extensions
described in their destination address selectors. If
the processing requested is bypass or discard and this section.

This document describes a "sender only"
type new "Address Preservation" (AP) flag
indicating that tunnel mode with address preservation is configured the entry SHOULD to be put
applied to a GSPD entry. The AP flag has two attributes: AP-L used
in GSPD-O only.
Reciprocally, if the type is "receiver only", processing of the entry SHOULD go
to GSPD-I only. SSM is supported by local tunnel address, and AP-R used in the use
processing of unicast IP address
selectors as documented in RFC 4301.

GSPD entries created by a GCKS may be assigned identical SPIs to
SAD entries created by IKEv2 [RFC4306]. the remote tunnel process. This flag is not a problem for
the inbound traffic as added to the appropriate SAs can be matched using
GSPD "Processing info" field of the algorithm described in GSDP. The following text
reproduced from Section 4.4.1.2 of RFC 4301 section 4.1. In addition, SAs 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 identical SPI values but all the selector sets, not manually keyed can be
differentiated because they contain a link to their parent SPD
entries. However, separate action for each
set. If the outbound traffic needs to be matched against required processing is PROTECT, the GSPD selectors so that entry
contains the appropriate SA can be created on
packet arrival. following information.
- IPsec implementations that support multicast MUST
use the destination mode -- tunnel or transport
- (if tunnel mode) local tunnel address as the additional selector and match
it against the GSPD entries marked "sender only".

To facilitate dynamic group keying, the outbound GSPD MUST
implement -- For a policy action capability that triggers non
mobile host, if there is just one interface, this is
straightforward; if there are multiple interfaces, this
must be statically configured. For a GKM protocol
registration exchange (as per Section 5.1 mobile host, the
specification of [RFC4301]). For
example, the Group Sender GSPD policy might trigger on a match local address is handled
externally to IPsec. If tunnel mode with a address
preservation is specified multicast application packet. The ensuing Group
Sender registration exchange would setup for the Group Sender's
outbound SAD entry that encrypts local tunnel address,
the multicast application's data AP-L attribute is set to TRUE for the local tunnel
address and the local tunnel address is unspecified.

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

Internet-Draft Multicast Extensions to RFC 4301 December 2007

stream. In February 22, 2008

The presence of the inverse direction, group policy may also setup an
inbound IPsec SA.

At AP-L attribute indicates that the Group Receiver endpoint(s),
inner IP header source address will be copied to the GSPD policy might trigger
on
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 match
Security Gateway". If tunnel mode with address
preservation is specified for the multicast application packet sent from remote tunnel
address, the
Group Sender. AP-R attribute is set to TRUE for the
remote tunnel address and the remote tunnel address is
unspecified. The ensuing Group Receiver registration exchange
would setup presence of the Group Receiver's inbound SAD entry AP-R attribute
indicates that decrypts 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 application's data stream. In address. Since an IP multicast
address must not be sent as the inverse direction, 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 group policy may also setup Local and Remote
address and ports in an outbound SPD entry are swapped to
represent directionality, consistent with IKE
conventions. In general, the protocols that IPsec SA (e.g. when
supporting an ASM service model).
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 provide use
GSPD policy mechanisms (e.g. (e.g., trigger on detection of IGMP/MLD leave
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 may allow 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 setup 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 tells 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.

4.1.2 Security Association Database (SAD)

The Security Association Database (SAD) can support multicast SAs,
if manually configured. An outbound multicast SA has the same
structure as a unicast

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 source address text in RFC 4301 Section
4.4.2.1 is that 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 Group
Sender and the destination data item also indicates
whether or not address preservation is applied to the multicast group address.
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. The SPI value for a multicast SA is
provided by a GCKS, not by the receiver as occurs for a unicast SA.
Other than the SPI assignment and the inbound packet de-
multiplexing described in RFC4301 section 4.1, the SAD behaves
identically for unicast and multicast security associations.

4.1.3 Group Peer Authorization Database (PAD)

The Peer Authorization Database (PAD) is extended in order to
accommodate peers that may take on specific roles in the group.
Such roles can be GCKS, Group Sender or a Group Receiver. A peer
can have multiple roles. The PAD may also contain root certificates
for PKI used by the group.

Weis, et al. Expires June 9, 2008 [Page 9]

Internet-Draft Multicast Extensions to RFC 4301 December 2007

4.1.3.1 GKM/IPsec Interactions with the PAD

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

. For those groups that authenticate identities using (GPAD)

The multicast IPsec extensions introduce a Public Key
Infrastructure, new data structure
called the PAD contains Group Peer Authorization Database (GPAD). Analogous to
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 (refer to determine RFC 4301 section 4.4.3), the GPAD provides a candidate group
member's acceptable authentication mechanism link
between a Group Key Management protocol and to decide
whether that candidate has the authority to join the group.

. A set of one or more GCKS SPD. The GPAD
contains three group role authorization rules. rule sets.

A group
member uses these rules to decide role authorization rule set specifies which systems peers are
authorized to act as participate in a GCKS for group in a given group. These rules also declare the
permitted GCKS authentication mechanism(s).

. A set of one or more Group Sender role authorization rules. In
some groups the action of sending protected packets is
restricted to a subset of group members. A Role. The
GCKS uses GKM subsystem examines these rules to declare which systems are authorized to be a Group Sender for
a given group.

Some GKM protocols (e.g. GSAKMP [RFC4535]) distribute their group's
PAD configuration in a security policy token [RFC4534] signed by
the group's policy authority, also known as the Group Owner (GO).
Each group member receives the policy token (using determine whether a method not
described in this memo) and verifies the
candidate Group Owner's signature on
the policy token. If that GO signature is accepted, then the group
member dynamically updates its PAD with Member has the policy token's
contents.

The PAD MUST provide a management interface capability that allows
an administrator authority to enforce that join the scope of a group. A Group
Member GKM group's policy
specified GSPD/SAD modifications subsystem uses these rules to decide which systems are restricted
authorized to only those
traffic act as a GCKS for a given group. The third group role
authorization rule set determines which Group Members are
authorized to send data flows that belong to that the group. This

When making a group role authorization
MUST be configurable at decision, the GKM group granularity. In subsystem
queries the inverse
direction, GPAD with the PAD management interface MUST provide a mechanism(s)
to enforce that IKEv2 security associations do not negotiate
traffic selectors that conflict or override 3-tuple {Group Identifier, Group Role,
GKM group policies.

Weis, et al. Expires June 9, 2008 [Page 10]

Internet-Draft Multicast Extensions to RFC 4301 December 2007

This document refers to re-key mechanisms ID}. These three GPAD search indices are defined as being multicast
because of the inherent scalability of IP multicast distribution.
However, there follows:

. Group Identifier - The Group Identifier is no particular reason an opaque byte string
of IKE ID type Key ID that re-key mechanisms need
be multicast. For example, [ZLLY03] describes identifies a method of re-key
employing both unicast and secure multicast messages.

4.2 group.
The Group Security Association (GSA)

As stated in Section 4 of [RFC3740] an IPsec implementation
supporting these extensions has a number of security associations:
one or more IPsec SAs, Identifier byte string MUST be at least four bytes
long and one or more GKM SAs used to download
IPsec SAs. These SAs are collectively referred to as a less than 256 bytes long. The GPAD administrator MUST
assign each Group
Security Association (GSA).

4.2.1 Concurrent IPsec SA Life Spans and Re-key Rollover

During Identifier a cryptographic group's lifetime, multiple IPsec group
security associations can exist concurrently. This occurs
principally due 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 two reasons: RFC 4301 February 22, 2008

. Group Role - There are multiple Group Senders 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 three types of its group roles: Group Senders.

- The life spans of Member,
Group Sender (i.e., a Group Sender's two (or more) IPsec SAs are
allowed Member authorized to overlap be a multicast
sender), and GCKS. A Group Member may be authorized to act in time, so that there
more than one role within a given group.

. GKM ID - The GKM ID is continuity the identifier used in the
multicast data stream across group re-key events. This capability 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 referred to an ordered list of GPAD
Entry Identifiers. GPAD Entry Identifiers have the same syntax and
pattern matching semantics as "re-key rollover continuity".

Each the PAD Entry Identifiers defined in
RFC 4301 section 4.4.3.1. Every group re-key multicast message sent 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 a GCKS signals the
start of a new 2-tuple {Group Identifier, Group Sender time epoch, with each such epoch
having Role}.

When the GKM subsystem needs to make an associated IPsec SA. The authorization decision, it
linearly searches the selected group membership interacts with
these IPsec SAs as follows:

- As role authorization rule set
until either it acquires a precursor GPAD Entry Identifier match to the Group Sender beginning its re-key rollover
continuity processing, GKM
ID, or it reaches the GCKS periodically multicasts a Re-Key
Event (RKE) message end of the rule set. A match authorizes the
GKM ID to act in the group. specified Group Role. The RKE multicast contains 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 directives, and new IPsec SA management facility. The security policy and keying
material. changes
can be rapidly propagated across the whole group membership rather
than at the pace of manual administration at individual systems. In
the absence context of a reliable multicast transport
protocol, the GCKS may re-transmit GPAD, the RKE a policy defined
number management facility promotes the
timely and accurate introduction of times newly authorized Group Members,
updates to improve existing role authorizations, and the availability revocation of re-key
information.

- a
compromised Group Member's role authorizations. The RKE multicast configures 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 GSPD/SAD with GPAD, GSPD, and SAD configuration in a security
policy token [RFC4534] signed by the new
IPsec SAs. group's policy authority, also
known as the Group Owner (GO). Each IPsec SA that replaces an existing SA is called a
"leading edge" IPsec SA. The leading edge IPsec SA has Group Member GSAKMP subsystem
receives the policy token (using a new
Security Parameter Index (SPI) method not described in this
memo) and new associated keying
material. For a short period after verifies the GCKS multicasts Group Owner's signature on the policy token.
If that GO signature is accepted, then the RKE, a Group Sender does not yet transmit data using Member's GSAKMP
subsystem dynamically updates the leading edge 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 June 9, August 22, 2008 [Page 11] 12]

Internet-Draft Multicast Extensions to RFC 4301 December 2007

IPsec SA. Meanwhile, other Group Members prepare to use this
IPsec SA February 22, 2008

A group security policy management facility is not mandated by installing the new IPsec SAs to their respective
GSPD/SAD.

- After waiting this
specification. The GPAD MUST have a sufficiently long enough period such trusted management interface
that all of
the Group Members have processed the RKE multicast, the Group
Sender begins to transmit using allows the leading edge IPsec SA with
its data encrypted by manual creation, editing, and deletion of the new keying material. Only authorized
Group Members can decrypt these IPsec SA multicast transmissions. group
role authorization rule sets. The period that a Group Sender waits before starting its first
leading edge SA transmission is a GKM/IPsec policy parameter.

This transmit delay period value for a new "leading edge" IPsec
SA SHOULD GPAD, GSPD, and SAD databases MAY
be configurable at the Group Owner management interface
on configured by a per group basis. The period duration will typically be
measured in seconds, and should take account for the time security policy management facility
through that same management interface. How an IPsec subsystem
implementation coordinates the RKE message takes to reach all Group Members, as well as the
time Group Members need manual and automated database
modifications to process the RKE message. If group
policy includes retransmitting RKE messages for availability, the
period should include avoid conflicts is a local matter outside the retransmission times as well. Periods
scope of longer duration (e.g, this specification.

The GPAD MUST provide a management interface capability that allows
an administrator to pre-distribute future SAs) are also
possible, but since the SA lifetimes will begin decrementing
immediately enforce that the effective useful lifetime scope of the SA may 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
greatly reduced.

- The Group Sender's "trailing edge" SA is configurable at GKM group granularity. In the oldest security
association in use by inverse
direction, the group for GPAD management interface MUST provide a
mechanism(s) to ensure that sender. All authorized IKEv2 security associations do not
negotiate traffic selectors that conflict or override GKM group
policies.

4.2 Group Members can receive Security Association (GSA)

An IPsec implementation supporting these extensions will support a
number of security associations: one or more IPsec SAs, and decrypt data for this SA, but the
Group Sender does not transmit new data using the "trailing edge"
SA after it has transitioned one or
more GKM SAs used to the "leading edge SA". The
trailing edge download IPsec SAs [RFC3740]. These SAs are
collectively referred to as a Group Security Association (GSA).

4.2.1 Concurrent IPsec SA is deleted by the Life Spans and Re-key Rollover

During a secure multicast group's endpoints according
to lifetime, multiple IPsec group policy (e.g., after a defined period has elapsed)"
security associations can exist concurrently. This re-key rollover strategy allows the group occurs
principally due to drain its two reasons:

- There are multiple Group Senders authorized in
transit datagrams from the network while transitioning to the
leading edge SA. Staggering the roles of group, each respective
with its own IPsec SA
as described above improves the group's synchronization even when
there are high network propagation delays. Note that due to which maintains anti-replay state. A group
membership joins and leaves, each Group Sender time epoch may have
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 different group membership set.

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

The rekey continuity rollover algorithm depends on an IPsec SA
management interface between epochs provides forward the GKM subsystem and backward secrecy. the IPsec
subsystem. The group's
re-key protocol keying material and algorithm (e.g. Logical Key
Hierarchy) enforces this policy. Implementations MAY offer a Group
Owner IPsec subsystem MUST provide management interface option to enable/disable re-key rollover
continuity
mechanisms for a particular group. This specification requires that
a GKM/IPsec implementation MUST support at least two concurrent the GKM subsystem to add IPsec SAs per Group Sender and to delete
IPsec SAs. For illustrative purposes, this re-key text defines the rekey
rollover continuity
algorithm. algorithm in terms of two timer parameters
that govern IPsec SA lifespans relative to the start of a group

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

Internet-Draft Multicast Extensions to RFC 4301 December 2007

4.3 Data Origin Authentication

As defined in [RFC4301], data origin authentication is a security
service February 22, 2008

rekey event. However, it should be emphasized that verifies the identity of the claimed source of data.
A Message Authentication Code (MAC) is often used to achieve data
origin authentication for connections shared between two parties.
But 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 GKM
subsystem interprets the group
application's data.

When group's security policy to direct the property
correct timing of data origin authentication is required for an IPsec SA distributed activation and deactivation. A given
group policy may choose timer values that differ from a GKCS, an authentication transform
where 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 originator keeps
start of 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 rekey event to activate new IPsec SAs. The ATD
parameter is expressed in units of seconds. Typically, the algorithm ATD
parameter is significantly greater than
an HMAC authentication method. To protect against denial of
service attacks set to the maximum time it takes to deliver a
multicast message from device that is not authorized the GCKS to join all of the
group, group's members.
For a GCKS that relies on a Reliable Multicast Transport
Protocol (RMTP), the IPsec SA using this algorithm may ATD parameter could be encapsulated with
an IPsec SA using set equal to the
RTMP protocol's maximum error recovery time. When a MAC authentication algorithm. However, doing
so requires RMTP is not
present, the packet to ATD parameter might be sent across set equal to the IPsec boundary for
additional inbound processing (see Section 5.2 network's
maximum multicast message delivery latency across all of [RFC4301]). the
group's endpoints. The ATD is a GKM group policy parameter. This
use of ESP encapsulated within ESP accommodates
value SHOULD be configurable at the constraint
that an ESP trailer Group Owner management
interface on a per group basis.

2. Deactivation Time Delay (DTD) - The DTD defines an Integrity Check Value (ICV) for
only how long after
the start of a single authenticator transform. Relaxing this constraint on rekey event to deactivate those IPsec SAs that
are destroyed by the use rekey event. The purpose of the ICV field DTD
parameter is an area for future standardization.

4.4 Group SA 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 Key Management

4.4.1 Co-Existence should not to be
confused with the IPsec SA soft lifetime attribute. The DTD
parameter is expressed in units of Multiple Key Management Protocols

Often, seconds. Typically, the GKM subsystem will DTD
parameter would be introduced set to an existent IPsec
subsystem as a companion key management protocol the ADT plus the maximum time it takes
to IKEv2
[RFC4306]. A fundamental GKM protocol IP Security subsystem
requirement is that both deliver a multicast message from the GKM protocol and IKEv2 can
simultaneously share access Group Sender to all of
the group's members. For a common Group Security Policy
Database and Security Association Database. The mechanisms Sender that
provide mutually exclusive access relies on a RMTP,
the DTD parameter could be set equal to ADT plus the common GSPD/SAD data
structures are RTMP
protocol's maximum error recovery time. When a local matter. This includes RMTP is not
present, the GSPD-outbound
cache and DTD parameter might be set equal to ADT plus the GSPD-inbound cache. However, implementers should note
that IKEv2 SPI allocation is entirely independent from
network's maximum multicast message delivery latency across all
of the group's endpoints. A GKM SPI
allocation because subsystem MAY implement the DTD
as a group security associations are qualified 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
destination 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 address and may optionally have multicast distribution. However,
there is no particular reason that re-keying mechanisms must be
multicast. For example, [ZLLY03] describes a source
IP address qualifier. See [RFC4303, Section 2.1] for further
explanation. method of re-key
employing both unicast and multicast messages.

The group membership interacts with these IPsec SAs as follows:

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

Internet-Draft Multicast Extensions to RFC 4301 December 2007

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. February 22, 2008

- Address Preservation (Section 3.1). This attribute describes
whether address preservation is to be applied As a precursor to the SA on Group Sender beginning its re-key rollover
continuity processing, the
source address, destination address, or both source and
destination addresses.

- Directional attribute (Section 4.1.1). This attribute describes
whether GCKS periodically multicasts a pair of SAs (one in each direction) are Re-Key
Event (RKE) message to be installed
(to match the "symmetric" SPD directionality), only in the
outbound direction (to match "receiver only" SPD directionality),
or only in group. The RKE multicast MAY contain
group policy directives, new IPsec SA policy, and group keying
material. In the inbound direction (to match "sender only" SPD
directionality).

- Any absence of the cryptographic transform-specific parameters and keys
that are sent from a RMTP, the GCKS may re-transmit the
RKE a policy-defined number of times to improve 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). availability
of re-key information. The
time that GKM subsystem starts the Group Receiver IPsec subsystems will wait ATD and DTD
timers after
creating it receives the leading edge 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 before they will retire the
trailing edge that
replaces an existing SA is called a "leading edge" IPsec SA. Also, the The
leading edge IPsec SA has a new Security Parameter Index (SPI)
and its associated keying material keys it. For a time that period of
ATD seconds in duration after the GCKS multicasts the RKE, a
Group Sender will
delay before it starts transmitting on does not yet transmit data using the leading edges edge
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 Multicast Traffic Processing

If an Meanwhile, other Group Members prepare to use this
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 by installing the source address is marked as being preserved,
during header construction new IPsec SAs to their respective
GSPD/SAD.

- After waiting for the "src address" header field MUST be
"copied from inner hdr" rather than "constructed" as described in
[RFC4301]. Similarly, if ATD period, such that all of the destination address is marked as being
preserved, during header construction Group
Members have received and processed the "dest address" header
field MUST be "copied from inner hdr" rather than "constructed".

Weis, et al. Expires June 9, 2008 [Page 14]

Internet-Draft Multicast Extensions RKE message, the GKM
subsystem directs the Group Sender to RFC 4301 December 2007

5.2 Inbound IP Multicast Traffic Processing

If an begin to transmit using the
leading edge IPsec SA is marked as supporting tunnel mode with address
preservation (as described 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 Section 3.1), use by the marked address
(i.e., source and/or destination address) on group for that sender. All authorized
Group Members can receive and decrypt data for this SA, but the outer IP header
MUST be verified
Group Sender does not transmit new data using the trailing edge
IPsec SA after it has transitioned to be the same value as leading edge IPsec SA.
The trailing edge IPsec SA is deleted by the inner IP header. If group's GKM
subsystems after the addresses are not consistent, DTD time period has elapsed since the IPsec system MUST treat RKE
transmission.

This re-key rollover strategy allows the
error group to drain its in
transit datagrams from the same manner as other invalid selectors, as described
in Section 5.2 of [RFC4301]. In particular network while transitioning to the
leading edge 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 SA. Staggering the unicast-oriented IP security architecture [RFC4301].
Consequently, this specification inherits many roles of each respective
IPsec SA as described above improves the RFC4301
security considerations group's synchronization
even when there are high network propagation delays. Note that due
to group membership joins and the reader leaves, each Group Sender IPsec SA
time epoch may have a different group membership set.

It is advised 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 review it as
companion guidance.

6.1 Security Issues Solved by IPsec [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

The IP 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 multicast extension
service provides that verifies the following
network layer mechanisms identity of the claimed source of data.
A Message Authentication Code (MAC) is often used to achieve data
origin authentication for secure group communications:

- Confidentiality using a group connections shared encryption key.

- Group source between two parties.
However, typical MAC authentication and integrity protection methods using a
group single shared
secret are not sufficient to provide data origin authentication key.

- Group Sender
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 using a digital
signature, TESLA, or other mechanism.

- Anti-replay protection is required for an
IPsec SA distributed from a limited number 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 Group Senders
using the ESP (or AH) sequence number facility.

- Filtering algorithm is significantly greater than
an HMAC authentication method. To protect against denial of multicast transmissions by those group members who
are
service attacks from a device that is not authorized by group policy to be Group Senders. This
feature leverages join the IPsec state-less firewall service.

In support of
group, the above services, IPsec SA using this specification enhances algorithm may be encapsulated with
an IPsec SA using a MAC authentication algorithm. However, doing
so requires the
definition 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 SPD, PAD, constraint that AH and SAD databases to facilitate 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
automated group GKM subsystem will be introduced to an existent IPsec
subsystem as a companion 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 protocol to IKEv2
[RFC4306]. A fundamental GKM protocol IP Security subsystem
requirement is out of scope of this
architecture 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 defend the group's keys or its application common GSPD/SAD data
against those attacks against many aspects of
structures are a local matter. This includes the operating
environment in which GSPD-outbound
cache and the IPsec implementation executes. GSPD-inbound cache. However, it 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 June 9, August 22, 2008 [Page 15] 16]

Internet-Draft Multicast Extensions to RFC 4301 December 2007

should be noted that February 22, 2008

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

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

4.4.2 New Security Association Attributes

A number of attacks originating by an
adversary new security association attributes are defined to
convey extensions defined in this document. Each GKM protocol
supporting this architecture MUST support the network 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 magnified to be installed
(to match the "symmetric" SPD directionality), only in the
outbound direction (to match "receiver only" SPD directionality),
or only in the extent that inbound direction (to match "sender only" SPD
directionality).

- Any of the group cryptographic transform-specific parameters and keys are shared across a large number of systems.

The security issues
that are left unsolved by sent from 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 GCKS to the group who has: 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 capability to launch a multicast flooding denial-of-service
attack against
time that the group, originating from a system whose Group Receiver IPsec
subsystem does not filter subsystems will wait after
creating the unauthorized multicast
transmissions.

- Compromised a multicast router, allowing leading edge IPsec SA before they will retire the Adversary to corrupt
or delete all multicast packets destined for
trailing edge IPsec SA. Also, the group endpoints
downstream from that router.

- Captured a copy of an earlier multicast packet transmission and
then replays it to a group time that does not have the anti-replay
service enabled. Note that for a large-scale any source multicast
group, Group Sender will
delay before it is impractical for starts transmitting on 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, 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 security multicast extensions are
dependent on
supported.

5.1 Outbound IP Traffic Processing

If 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 IPsec SA is a set marked as supporting tunnel mode with address
preservation (as described in Section 3.1), either or both of one the
outer header source or more shared secrets
entrusted destination addresses are marked as being
preserved.

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

Internet-Draft Multicast Extensions to all 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 group's members. Consequently, SAD entry for
either the
service's security guarantees are no stronger than outer IP header Source Address or Destination
Address, the weakest
member admitted to outer IP header Source Address and
Destination Address identify the group by "endpoints" of the GKM system. The GKM system tunnel
(the encapsulator and decapsulator). If address
preservation is
responsible marked for responding to compromised group member detection by
executing a group key recovery procedure. The GKM re-keying
protocol will expel the compromised group members and distribute
new group keying material to IP header Source Address,
it is copied from the trusted members. Alternatively, inner IP header Source Address. If
address preservation is marked for the group policy may require IP header
Destination Address, it is copied from the GKM system to terminate inner IP header
Destination Address. The inner IP header Source Address
and Destination Addresses identify the group.

In original sender and
recipient of the event that an Adversary has been admitted into datagram (from the group by perspective of this
tunnel), respectively. Address preservation MUST NOT be
marked when the GKM system, IP version of the following attacks are possible encapsulating header and they can not
be solved by
IP version of the IPsec multicast extension service:

Weis, et al. Expires June 9, 2008 [Page 16]

Internet-Draft Multicast Extensions to inner header do not match.

Note (3) regarding construction of tunnel addresses in Section
5.1.2.1 of RFC 4301 December 2007

- The Adversary can disclose is amended as follows:

(3) Unless marked for address preservation Local and Remote
addresses depend on the secret group key or group data SA, which is used to
an unauthorized party outside of determine
the group. After a group key or
data compromise, cryptographic methods such as traitor tracing or
watermarking can assist Remote address, which in the forensics process. However, these
methods are outside the scope of this specification.

- The insider Adversary can forge packet transmissions that appear turn determines which Local
address (net interface) is used to be from a peer group member. To defend against this attack for
those Group Sender transmissions that merit the overhead, forward the
group policy can require packet.
If address preservation is marked for the Group Sender to multicast packets
using Local address,
it is copied from the data origin authentication service.

- inner IP header. If address
preservation is marked for the group's data origin authentication service uses digital
signatures, then Remote address, that
address is copied from the insider Adversary can launch a computational
resource denial of service attack inner IP header.

5.2 Inbound IP Traffic Processing

IPsec-protected packets generated by multicasting bogus signed
packets.

6.3 Implementation or Deployment Issues that Impact Security

6.3.1 Homogeneous Group Cryptographic Algorithm Capabilities

The an IPsec device supporting
these multicast extensions may (depending on its GSPD policy)
preserve a destination address such that the IP security destination address
is not an IPsec device. This requires an IPsec device supporting
these multicast extensions service can not defend against
a poorly considered group security policy to process IP traffic that allows a weaker
cryptographic algorithm simply because all of is not
addressed to the group's endpoints IPsec device itself. The following additions to
IPsec inbound IP traffic processing are known necessary.

For compatibility with RFC 4301, the phrase "addressed to support it. Unfortunately, large-scale groups can be
difficult this
device" is taken to upgrade mean packets with a unicast destination address
belonging to the current best in class cryptographic
algorithms. One possible approach 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 solving many this
device.

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

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

The discussion of these problems
is the deployment processing Inbound IP Traffic described in
Section 5.2 of composite groups that can straddle
heterogeneous groups [COMPGRP]. A standard solution for
heterogeneous groups RFC 4301 is an activity for future standardization. In amended as follows. The first dash in
item 2 is amended as follows:

- If the interim, synchronization of a group's cryptographic
capabilities could packet appears to be achieved using a secure IPsec protected 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 it is
addressed to this device, or key
strengths. As currently defined, the appears to be IPsec multicast extension
service requires a single group policy per group. As noted above,
this problem remains protected
and is addressed to a multicast group, an area for future standardization.

6.3.3 Network Address Translation

With attempt is made
to map it to an active SA via the advent of NAT SAD.

A new item is added to the list between items 3a and mobile nodes, IPsec multicast
applications need 3b to overcome several architectural barriers describe
processing of IPsec packets with destination address preservation
applied:

3aa. If the packet is addressed to
their successful deployment. This section surveys those problems a multicast group and identifies AH
or ESP is specified as the GSPD/SAD state information 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 GKM
protocol supporting NAT IPsec device is a
security gateway, and mobile nodes need the SPD-I policy is to synchronize
across PYPASS the group membership.
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 June 9, August 22, 2008 [Page 17] 19]

Internet-Draft Multicast Extensions to RFC 4301 December 2007

6.3.3.1 GSPD Losses Synchronization with Internet Layer's State

The most prominent problem facing GKM protocols supporting February 22, 2008

Unprotected Interface
|
V
+-----+ IPsec
is that the GKM protocol's group security policy mechanism can
inadvertently configure the group's GSPD traffic selectors with
unreliable transient IP addresses. The IP addresses are transient
because 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 either node mobility or Network Address Translation
(NAT), both RFC 4301)

The discussion of which can unilaterally change a Group Sender's
source processing Inbound IP address without signaling the GKM protocol. The absence Traffic described in
Section 5.2 of RFC 4301 is amended to insert a GSPD synchronization mechanism can cause 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 group's data
traffic

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 discarded rather than processed correctly.

6.3.3.2 Mobile Multicast Care-Of Address Route Optimization

Both Mobile IPv4 [RFC3344] and Mobile IPv6 provide transparent
unicast communications verified to a mobile Node. However, comparable
support for secure multicast mobility management is be the same
value as the inner IP header. If the addresses are not specified
by these standards. The goal is
consistent, the ability to maintain an end-to-
end transport mode group SA between a Group Sender 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 IPsec system MUST discard the packet, as
well as treat the triangular inconsistency as an auditable event.

6. Security Considerations

The IP security multicast path
between extensions defined by this specification
build on the correspondent Group Receiver nodes, unicast-oriented IP security architecture [RFC4301].
Consequently, this specification inherits many of the home agent, RFC4301
security considerations and the mobile node. Any proposed solution needs reader is advised to be secure against
hostile re-direct and flooding attacks.

6.3.3.3 NAT Translation Mappings Are Not Predictable review it as
companion guidance.

6.1 Security Issues Solved by IPsec Multicast Extensions

The following spontaneous NAT behaviors adversely impact source-
specific secure IP security multicast groups. When a NAT gateway is on extension service provides the
path between following
network layer mechanisms for secure group communications:

- Confidentiality using a group shared encryption key.

- Group Sender residing behind a NAT source authentication and integrity protection using a public
IPv4 multicast
group shared authentication key.

- Group Receiver, the NAT gateway alters the private
source address to Sender data origin authentication using a digital
signature, TESLA, or other mechanism.

- Anti-replay protection for a public IPv4 address. This translation needs to
be coordinated with every limited number of Group Receiver's inbound GSPD Senders
using the ESP (or AH) sequence number facility.

- Filtering of multicast
entries that depend on that transmissions identified with a source
address as a traffic selector.
One might mistakenly assume of systems that the GCKS could set up the are not authorized by group policy to be
Group
Members Senders. This feature leverages the IPsec state-less
firewall service (i.e., SPD-I and/or SDP-O entries with a GSPD entry that anticipates packet
disposition specified as DISCARD).

In support of the value(s) that above services, this specification enhances the
NAT translates
definition of the packet's source address. However, there are
known cases where this address translation can spontaneously
change without warning:

- NAT gateways may re-boot SPD, PAD, and lose their address translation
state information.

- The NAT gateway may de-allocate its address translation state
after an inactivity timer expires. The address translation used
by the NAT gateway after SAD databases to facilitate the resumption
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 flow may differ
than
against attacks targeting vulnerabilities of the operating
environment in which the IPsec implementation executes. However, it
should be noted that known the risk of attacks originating by an
adversary in the network is magnified to the GSPD selectors at extent that the group endpoints.
keys are shared across a large number of systems.

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

Internet-Draft Multicast Extensions to RFC 4301 December 2007

- February 22, 2008

The GCKS may 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 have global consistent knowledge defend against an
Adversary outside of a the group
endpoint's current public and private address mappings due who has:

- the capability to
network errors or race conditions. For example, launch a Group Member's
address may change due to multicast flooding denial-of-service
attack against the group, originating from a DHCP assigned address lease
expiration. system whose IPsec
subsystem does not filter the unauthorized multicast
transmissions.

- Alternate paths may exist between compromised a given pair of Group Members.
If there are parallel NAT gateways along those paths, then multicast router, allowing the
address translation state information at each NAT gateway may
produce different translations on Adversary to corrupt
or delete all multicast packets destined for the group endpoints
downstream from that router.

- captured a per packet basis.

The consequence copy of this problem is an earlier multicast packet transmission and
then replayed it to a group that the GCKS can does not be pre-
configured with NAT mappings, as have the GSPD at anti-replay
service enabled. Note that for a large-scale any-source multicast
group, it is impractical for the Group Members
will lose synchronization as soon as a NAT mapping changes due Receivers to
any of the above events. In the worst case, maintain an
anti-replay state for every potential Group Members in
different sections of the network will see different NAT mappings,
because the multicast packet traversed multiple NAT gateways.

6.3.3.4 SSM Routing Dependency on Source IP Address

Source-Specific Multicast (SSM) routing depends on Sender. Group
policies that require anti-replay protection for a large-scale
any-source-multicast group should consider an application layer
total order multicast
packet's source protocol.

6.2.2 Insider Attacks

For large-scale groups, the IP address and security multicast destination IP address extensions are
dependent on an automated Group Key Management protocol to
correctly authenticate and authorize trustworthy members in
compliance 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 group's policies. Inherent in the concept of a Group Member's
point
cryptographic group is a set of attachment one or more shared secrets
entrusted to all of the Internet, and this will change group's members. Consequently, the
packet's source IP address. Regardless of why it happened, this
alteration in
service's security guarantees are no stronger than the source IP address makes it infeasible weakest
member admitted to the group by the GKM system. The GKM system is
responsible for transit
multicast routers in responding to compromised group member detection by
executing a re-key procedure. The GKM re-keying protocol will expel
the public Internet compromised group members and distribute new group keying
material to know which SSM sender
originated the multicast packet, which in turn selects trusted members. Alternatively, the correct
multicast forwarding policy.

6.3.3.5 ESP Cloaks Its Payloads from NAT Gateway

When traversing NAT, application layer protocols that contain IPv4
addresses in their payload need group policy
may require the intervention of an Application
Layer Gateway (ALG) that understands that application layer
protocol [RFC3027] [RFC3235]. The ALG massages GKM system to terminate the payload's
private IPv4 addresses group.

In the event that an Adversary has been admitted into equivalent public IPv4 addresses.
However, when encrypted the group by end-to-end ESP, such payloads are
opaque to application layer gateways.

When multiple Group Senders reside behind a NAT with a single
public IPv4 address,
the NAT gateway GKM system, the following attacks are possible and they can not do UDP or TCP
protocol port translation (i.e. NAPT) because the ESP encryption
conceals
be solved by the transport layer protocol headers. IPsec multicast extension service:

- The use of UDP
encapsulated ESP [RFC3948] avoids this problem. However, this
capability needs to be configured at Adversary can disclose the GCKS as a secret group policy,
and it needs key or group data to be supported in unison by all
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 June 9, August 22, 2008 [Page 19] 22]

Internet-Draft Multicast Extensions to RFC 4301 December 2007

endpoints within February 22, 2008

watermarking can assist in the group, even 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 reside 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 public
Internet.

6.3.3.6 UDP Checksum Dependency on Source IP Address

An IPsec subsystem using UDP within multicast extension
service requires a single group policy per group. As noted above,
this problem remains an ESP payload will encounter
NAT induced problems. The original IPv4 area for future standardization.

6.3.3 Source-Specific Multicast Group Sender Transient Locators

A Source Specific Multicast (SSM) Group Sender's 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 dynamically change during a mechanism secure multicast group's lifetime.
Examples of the events that recovers can cause the original Group Sender's source
IPv4
address at the Group Receiver endpoints.

In to change include but are not limited to NAT, a transport mode multicast application GSA, mobility
induced change in the UDP checksum
operation requires care-of-address, and a multi-homed host
using a new IP interface. The change in the origin endpoint's Group Sender's source
IP address will cause those GSPD entries related to complete
successfully. In IKEv2, this information is obtained from the
Traffic Selectors associated that multicast
group to become out of date with respect to the exchange [RFC4306, Section
2.23]. See also reference [RFC3947]. A facility that obtains group's multicast
routing state. In the
same result needs to exist in worst case, there is a GKM protocol payload risk that defines the multicast application GSA attributes for each Group Sender.

6.3.3.7 Cannot Use AH with NAT Gateway

The presence of
Sender's data originating from a NAT gateway makes it impossible new source address will be BYPASS

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

Internet-Draft Multicast Extensions to use an
Authentication Header, keyed RFC 4301 February 22, 2008

processed by a group-wide key, to protect the
integrity of 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 header
addresses for transmissions between members of the cryptographic group. 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 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.

Weis, et al. Expires June 9, 2008 [Page 20]

Internet-Draft Multicast Extensions to RFC 4301 December 2007

[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 2004. 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., 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.

[RFC3027] Holdrege, M., and P. Srisuresh, "Protocol Complications
with the IP Network Address Translator", RFC 3027,
January 2001.

[RFC3171] Albanni, Z., et. 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.

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

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

[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.

[RFC3376] Cain, B., et. 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.

Weis, et al. Expires June 9, 2008 [Page 21]

Internet-Draft Multicast Extensions to RFC 4301 December 2007

[RFC3552] Rescorla, E., et. 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, Tl, 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. et al., "Negative-acknowledgment (NACK)-
Oriented Reliable Multicast (NORM) Protocol", RFC 3940,
November 2004.

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

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

[RFC4046] Baugher, M., Dondeti, L., Canetti, R., and F. Lindholm,
"Multicast Security (MSEC) Group Key Management
Architecture", RFC4046, April 2005.

[RFC4082] Perrig, A., et. 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. 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. et al., "Protocol Design for Scalable and
Reliable Group Rekeying", IEEE/ACM Transactions on

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

Internet-Draft Multicast Extensions to RFC 4301 December 2007
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 June 9, August 22, 2008 [Page 23] 26]

Internet-Draft Multicast Extensions to RFC 4301 December 2007 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
Associations (GSA)to
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 setup 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
setup
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. (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 June 9, August 22, 2008 [Page 24] 27]

Internet-Draft Multicast Extensions to RFC 4301 December 2007 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 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 node
rather than a multicast transmission to the whole group.

If an ESP digital signature authentication is available (E.g., (e.g., RFC
4359), source authentication MAY be used to authenticate a receiver
Node's
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 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 setup 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 a 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 June 9, August 22, 2008 [Page 25] 28]

Internet-Draft Multicast Extensions to RFC 4301 December 2007 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
setup
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

Weis, et al. Expires June 9, 2008 [Page 26]

Internet-Draft Multicast Extensions to RFC 4301 December 2007

Full Copyright Statement

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.

Weis, et al. Expires June 9, 2008 [Page 27]

Internet-Draft Multicast Extensions to RFC 4301 December 2007

Acknowledgement

Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).

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

----