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