Internet Engineering Task Force                          Mark Baugher(Cisco)
   INTERNET-DRAFT                                    Thomas Hardjono (Verisign)
   draft-ietf-msec-ipsec-multicast-issues-00.txt             Brian Weis (Cisco)
   Expires: June, 2003
                                                                 December, 2002


                      IP Multicast issues with IPsec

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 IPsec Architecture [RFC2401] and IPsec transform RFCs [RFC2402,
   RFC2406] define certain semantics for use of IPsec with IP multicast
   traffic. The recent revisions to each of the protocol documents
   [ESPbis, AHbis] propose changes to those semantics. However, neither
   the existing nor proposed semantics are sufficiently general such
   that IPsec can be used to protect the wide variety of IPv4 and IPv6
   multicast applications that are expected by the IP multicast
   community. This document reviews these semantics and proposes
   changes which would enable IPsec to be generally useful for a wider
   variety of IPv4 and IPv6 multicast traffic.










   Baugher, et. al.       Expires June, 2003                         1
               IP Multicast issues with IPsec      December, 2002

Table of Contents

1.0 Introduction......................................................2
2.0 General Issues....................................................2
  2.1 SPI allocation and SA lookup....................................2
  2.2 Multiple sender SAs and replay protection.......................4
3.0 Proposed Changes to ESP...........................................4
  3.1 SPI allocation and SA lookup....................................4
  3.2 Multiple sender SAs and replay protection.......................5
4.0 Proposed Changes to AH............................................6
  4.1 SPI allocation and SA lookup....................................6
  4.2 Multiple sender SAs and replay protection.......................7
5.0 Security Considerations...........................................7
6.0 References........................................................7
  6.1 Normative References............................................7
  6.2 Informative References..........................................7
Authors Addresses.....................................................8

1.0 Introduction

   At the time RFCs 2401/2402/2406 were written, use of IPsec for
   multicast was for the most part not deployed. However the authors of
   those RFCs and the IPsec Working Group had the vision that IPsec
   would someday be just as useful for IP multicast as IP unicast. At
   that time there were a number of unsolved problems, and those are
   candidly listed in RFC 2401.

   However, because so little attention had been placed toward use the
   of IPsec to protect multicast traffic, and because new methods of IP
   multicast have been invented since that time, it is only natural
   that what is currently documented in those RFCs do not handle all of
   the current IP multicast needs.

   Although this document is primarily concerned with IP multicast, the
   issues raised are not restricted to multicast; IPv4 or IPv6
   broadcast and anycast groups are similarly affected.

   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 [RFC2119].

2.0 General Issues

   There are two distinct unrelated problems which have been
   discovered, first by the SMuG IRTF WG and then by the IETF MSEC WG
   which was formed to focus on the security of IP multicast groups.

2.1 SPI allocation and SA lookup

   RFC 2401 states an SA will use the 3-tuple (destination address,
   IPsec protocol, and SPI) to look up the SA in the SAD. That is

   Baugher, et. al.       Expires June, 2003                         2
               IP Multicast issues with IPsec      December, 2002

   sufficient and satisfactory in many IP multicast cases. It can be
   accomplished in those cases by using a multicast key management
   scheme which is built around a centralized group controller. As long
   as a single group controller synchronizes SPI values, this 3-tuple
   is sufficient -- even as the authors of RFC 2401 predicted in
   Section 4.7 of RFC 2401:

      So some system or person will need to coordinate among all
      multicast groups to select an SPI or SPIs on behalf of each
      multicast group and then communicate the group's IPsec
      information to all of the legitimate members of that multicast
      group via mechanisms not defined here.

   The text quoted above from RFC 2401 does not say that there MUST be
   a single controller, but appears to be giving clarification text
   based on the expectations of the time.

   However, since this time Source-Specific Multicast (SSM) has been
   specified which allows for sender-specific SAs. An SSM "group" is
   composed of a particular sender and its receivers. Multiple SSM
   groups may use that same multicast address, but no coordination
   between senders is assumed. Similarly, IGMP version 3 also operates
   on the basis of (Source, Group) pairs. Therefore, when we wish to
   protect this traffic with IPsec we cannot assume any security
   coordination between the senders. A 3-tuple is no longer sufficient.

   Section 4.7 of RFC 2401 also says

      Specifications for other, more general multicast cases are
      deferred to later IPsec documents.

   Given the above two quotes it would seem that we should be able to
   accommodate multiple multicast controllers within the existing
   architecture.

   RFC 2406 did not further restrict the SA lookup as described in RFC
   2401. It also describes the 3-tuple to be used in all cases (unicast
   and multicast).

   The proposed new ESP [ESPbis] and AH [AHbis] do change the semantics
   of SA lookup. It makes them less specific in both the unicast and
   multicast cases. For the IP multicast case, the lookup is reduced to
   a SPI lookup (and optionally the protocol ID).

   However, even if all SPIs within one IP multicast group are
   coordinated by a single multiple multicast controller, there is no
   guarantee that all IP multicast groups will be coordinated by a
   single multiple multicast controller. Thus, the SPI alone is
   insufficient for lookups for Source-Specific Multicast.

   In order to effectively differentiate between SAs administered by
   different group controllers, we need a MORE specific SA lookup than
   RFC 2406 rather than the less specific lookup as proposed in
   [ESPbis].

   Baugher, et. al.       Expires June, 2003                         3
               IP Multicast issues with IPsec      December, 2002


2.2 Multiple sender SAs and replay protection

   RFC 2401 points out that having senders share a single SA is useful
   under some circumstances (see Section 4.7 of [RFC2401). It
   acknowledges that the anti-replay service provided by a sequence
   number in the AH or ESP packet is not possible with present
   semantics.

   RFC 2406 agrees with this, and further states that anti-replay
   SHOULD NOT be used with a multi-sender SA in Section 3.4.3:

      (Note that there are no provisions for managing transmitted
      Sequence Number values among multiple senders directing traffic
      to a single SA (irrespective of whether the destination address
      is unicast, broadcast, or multicast).  Thus the anti-replay
      service SHOULD NOT be used in a multi-sender environment that
      employs a single SA.)

   The new ESP [ESPbis] goes even further to deprecate multiple sender
   SAs in Section 2.2. However, there are multicast applications with
   very large numbers of senders to the same IP multicast group, where
   the senders are low end devices which cannot store a single SA per
   sender.

3.0 Proposed Changes to ESP

   The following sections propose changes to [ESPbis] to address the
   above general issues.

3.1 SPI allocation and SA lookup

   Section 2.1 (Security Parameters Index) specifies exactly how the
   SPI should be dealt with:

      For multicast SAs, the SPI (and optionally the protocol ID) in
      combination with the destination address is used to select an SA.
      This is because multicast SAs are defined by a multicast
      controller, not by each IPsec receiver. (See the Security
      Architecture document for more details.)

   As noted above, this is not sufficient for IP multicast, even in the
   case where each IP multicast address has only one multiple multicast
   controller. We propose this section to be replaced with the
   following wording:

      For broadcast, multicast, and anycast SAs, the SPI and protocol
      ID (ESP) in combination with the destination address is used to
      select an SA. In some cases, these other parameters (such as a
      source address) MAY be used by a receiver to further the correct
      SA. This is because multicast SAs may be defined by one or more
      non-cooperating multicast controllers.


   Baugher, et. al.       Expires June, 2003                         4
               IP Multicast issues with IPsec      December, 2002

   Section 3.4.2 (Security Association Lookup) of [ESPbis] would also
   need to discuss these semantics. It currently states:

      Upon receipt of a packet containing an ESP Header, the receiver
      determines the appropriate (unidirectional) SA, based on the SPI
      alone (unicast) or SPI combined with destination IP address
      (multicast).  (This process is described in more detail in the
      Security Architecture document.)

   We propose this text be replaced as follows.

      Upon receipt of a unicast packet containing an ESP Header, the
      receiver determines the appropriate (unidirectional) SA, based on
      the SPI alone. If the packet is a broadcast, multicast, or
      anycast packet, the receiver determines the appropriate SA based
      on the SPI combined with the security protocol and destination
      address. (This process is described in more detail in the
      Security Architecture document.)

      If the packet is a broadcast, multicast, or anycast packet, there
      may be more than one SA pointed to by the combination of SPI,
      security protocol and destination address if multiple non-
      cooperating multicast controllers are present in the network. In
      this case the receiver MAY use other parameters (such as a source
      address) to identify the correct SA. Key management MAY indicate
      (e.g., with an SA attribute) that such processing is necessary in
      order for a receiver to properly process the ESP packets for a
      group if that is known a priori.

3.2 Multiple sender SAs and replay protection

   Section 2.2 (Sequence Number) states:

      Sharing an SA among multiple senders is deprecated, since there
      is no general means of synchronizing packet counters among the
      senders or meaningfully managing a receiver packet counter and
      window in the context of multiple senders.

   It is true that with the current semantics that synchronizing packet
   counters across multiple senders is not possible. However, there is
   a need to provide anti-replay in this situation and there will be
   research into methods which allow anti-replay in this situation.

   Therefore, rather than forbid the use of multiple-sender SAs we
   propose relaxing the multiple-sender SA restriction found in RFC
   2406 to accommodate new methods of replay detection as they become
   available. We propose the following replacement for the above text
   in [ESPbis].

      For a multi-sender multicast SA, the anti-replay service MUST NOT
      be used unless key management signals its use. If the anti-replay
      service is used in this case, each receiver must keep a replay
      winder per sender.


   Baugher, et. al.       Expires June, 2003                         5
               IP Multicast issues with IPsec      December, 2002

   This text intentionally restricts any new anti-replay functionality
   being used unless it has been negotiated in or downloaded from key
   management. In this way, older IPsec and hardware implementations of
   IPsec will be shielded from having to implement or understand the
   new semantics.

4.0 Proposed Changes to AH

   The following sections propose changes to [AHbis] to address the
   above general issues.

4.1 SPI allocation and SA lookup

   Section 2.4 (Security Parameters Index) specifies exactly how the
   SPI should be dealt with. It is identical to [ESPbis] wording.

      For multicast SAs, the SPI (and optionally the protocol ID) in
      combination with the destination address is used to select an SA.
      This is because multicast SAs are defined by a multicast
      controller, not by each IPsec receiver. (See the Security
      Architecture document for more details.)

   As in the case with [ESPbis], we propose this section to be replaced
   with the following wording:

      For broadcast, multicast, and anycast SAs, the SPI and protocol
      ID (ESP) in combination with the destination address is used to
      select an SA. In some cases this other parameters (such as a
      source address) MAY be used by a receiver to further the correct
      SA. This is because multicast SAs may be defined by one or more
      non-cooperating multicast controllers.

   Section 3.4.2 (Security Association Lookup) of [AHbis] also needs to
   be modified to reflect these semantics. It currently states:

      Upon receipt of a packet containing an IP Authentication Header,
      the receiver determines the appropriate (unidirectional) SA,
      based on the destination IP address, security protocol (AH), and
      the SPI.

   We propose this text be replaced as follows.

      If the packet is a broadcast, multicast, or anycast packet, there
      may be more than one SA pointed to by the combination of SPI,
      security protocol and destination address if multiple non-
      cooperating multicast controllers are present in the network. In
      this case the receiver MAY use other parameters (such as a source
      address) to identify the correct SA. Key management MAY indicate
      (e.g., with an SA attribute) that such processing is necessary in
      order for a receiver to properly process the AH packets for a
      group if that is known a priori.


   Baugher, et. al.       Expires June, 2003                         6
               IP Multicast issues with IPsec      December, 2002

4.2 Multiple sender SAs and replay protection

   Section 2.5 (Sequence Number) states the same text as [ESPbis]
   Section 2.2. We propose the same text here as is proposed in Section
   3.2.

5.0 Security Considerations

   This entire document discusses how multicast data packets can be
   effectively protected within the IPsec architecture.

6.0 References

6.1 Normative References

   [RFC2401] Kent, S., R. Atkinson, "Security Architecture for the
   Internet Protocol", November 1998

   [RFC2402] Kent, S., and R. Atkinson, "IP Authentication Header", RFC
   2402, November 1998.

   [RFC2406] Kent, S., and R. Atkinson, "IP Encapsulating Security
   Payload", RFC 2406, November 1998.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Level", BCP 14, RFC 2119, March 1997.

6.2 Informative References

   [ESPbis] Kent, S., "IP Encapsulating Security Payload (ESP)",
   http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-03.txt,
   Work in progress 2002.

   [AHbis] Kent, S., ?IP Authentication Header?,
   http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2402bis-
   01.txt, Work in progress 2002.


   Baugher, et. al.       Expires June, 2003                         7
               IP Multicast issues with IPsec      December, 2002

Authors Addresses

   Mark Baugher
   Cisco Systems
   5510 SW Orchid Street
   Portland, OR  97219, USA
   (503) 245-4543
   mbaugher@cisco.com

   Thomas Hardjono
   VeriSign
   401 Edgewater Place, Suite 280
   Wakefield, MA 01880
   Tel: 781-245-6996
   thardjono@verisign.com

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







   Baugher, et. al.       Expires June, 2003                         8