PIM Working Group W. Atwood Internet-Draft S. Islam Updates: 4601 (if approved) Concordia University/CSE Intended status: Standards Track October 15, 2006 Expires: April 18, 2007 Security Issues in PIM-SM Link-local Messages draft-ietf-pim-sm-linklocal-00 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. This Internet-Draft will expire on April 18, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Atwood & Islam Expires April 18, 2007 [Page 1]
Internet-Draft PIM-SM Link-local Security October 2006 Abstract This document outlines the security issues for the link-local messages in the Protocol Independent Multicast - Sparse Mode (PIM-SM) routing protocol. It provides mechanisms to authenticate the PIM-SM link local messages using the IP security (IPsec) Authentication Header (AH). Atwood & Islam Expires April 18, 2007 [Page 2]
Internet-Draft PIM-SM Link-local Security October 2006 1. Introduction All the PIM-SM [1] control messages have IP protocol number 103. These messages are either unicast, or multicast with TTL = 1. The source address used for unicast messages is a domain-wide reachable address. For the multicast messages, a link-local address of the interface on which the message is being sent is used as the source address and a special multicast address, ALL_PIM_ROUTERS (224.0.0.13 in IPv4 and ff02::d in IPv6) is used as the destination address. These messages are called link-local messages. Hello, Join/Prune and Assert messages are included in this category. A forged link-local message may be sent to the ALL_PIM_ROUTERS multicast address by an attacker. This type of message affects the construction of the distribution tree [1]. The effects of these forged messages are outlined in section 6.1 of [1]. Some of the effects are very severe, whereas some are minor. PIM-SM version 2 was originally specified in RFC 2117, and revised in RFC 2362 and RFC 4601. RFC 4601 obsoletes RFC 2362, and corrects a number of deficiencies. The Security Considerations section of RFC 4601 is based primarily on the new Authentication Header (AH) specification described in RFC 4302 [2]. Securing the unicast messages can be achieved by the use of a normal unicast IPsec Security Association between the two communicants. Securing the user data exchanges is covered in RFC 3740 [5]. This document focuses on the security issues for link-local messages. It provides some guidelines to take advantage of the new permitted AH functionality in RFC 4302, and to bring the PIM-SM specification into alignment with the new AH specification. This document recommends manual key management as mandatory to implement, i.e., that all implementations MUST support, and discusses the need to develop a simple light-weight automated key management protocol that the PIM routers can use. Atwood & Islam Expires April 18, 2007 [Page 3]
Internet-Draft PIM-SM Link-local Security October 2006 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and indicate requirement levels for compliant PIM-SM implementations. Atwood & Islam Expires April 18, 2007 [Page 4]
Internet-Draft PIM-SM Link-local Security October 2006 3. Transport Mode vs. Tunnel Mode The transport mode Security Association (SA) is generally used between two hosts or routers/gateways when they are acting as hosts. The SA must be a tunnel mode SA if either end of the security association is a router/gateway. Two hosts MAY establish a tunnel mode SA between themselves. PIM-SM link-local messages are exchanged between routers. However, since the packets are locally delivered, the routers assume the role of hosts in the context of the tunnel mode SA. All implementations conforming to this specification MUST support transport mode SA to provide required IPsec security to PIM-SM link-local messages. They MAY also support tunnel mode SA to provide required IPsec security to PIM-SM link-local messages. Atwood & Islam Expires April 18, 2007 [Page 5]
Internet-Draft PIM-SM Link-local Security October 2006 4. Authentication Implementations conforming to this specification MUST support authentication for PIM-SM link-local messages. In order to provide authentication to PIM-SM link-local messages, implementations MUST support AH in transport mode. When authentication for PIM-SM link-local messages is enabled, o PIM-SM link-local packets that are not protected with AH MUST be silently discarded. o PIM-SM link-local packets that fail the authentication checks MUST be silently discarded. Atwood & Islam Expires April 18, 2007 [Page 6]
Internet-Draft PIM-SM Link-local Security October 2006 5. IPsec Requirements In order to implement this specification, the following IPsec capabilities are required. Transport mode IPsec in transport mode MUST be supported. Selectors The implementation MUST be able to use source address and SPI as selectors in the SPD. Manual key management Manually configured keys MUST be able to secure the specified traffic. Atwood & Islam Expires April 18, 2007 [Page 7]
Internet-Draft PIM-SM Link-local Security October 2006 6. Key Management All the implementations MUST support manual configuration of the SAs that will be used to authenticate PIM-SM link-local messages. This does not preclude the use of a negotiation protocol such as the Internet Key Exchange (IKE) [9] or Group Secure Association Key Management Protocol (GSAKMP) [10]to establish SAs. 6.1. Manual Key Management To establish the SAs at PIM-SM routers, manual key configuration will be feasible when the number of peers (directly connected routers) is small. The Network Administrator will configure a router manually during its boot up process. At that time, the authentication method and the choice of keys SHOULD be configured. The SAD entry will be created. The Network Administrator will also configure the Security Policy Database of a router to ensure the use of the associated SA while sending a link-local message. 6.2. Automated Key Management All the link-local messages of the PIM-SM protocol are sent to the destination address, ALL_PIM_ROUTERS, which is a multicast address. By using the sender address in conjunction with the destination address for Security Association lookup, link-local communication turns to an SSM or "one to many" communication. Since IKE is based on the Diffie-Hellman key agreement protocol and works only for two communicating parties, it is not possible to use IKE for providing the required "one to many" authentication. The other option is to use Group Domain Of Interpretation (GDOI) [11], which enables a group of users or devices to exchange encrypted data using IPsec data encryption. GDOI has been developed to be used in multicast applications, where the number of end users or devices may be large and the end users or devices can dynamically join/leave a multicast group. However, a PIM router is not expected to join/ leave very frequently, and the number of routers is small when compared to the possible number of users of a multicast application. Moreover, most of the PIM routers will be located inside the same administrative domain and are considered as trusted parties. Probably, a GDOI-lite with a subset of GDOI functionalities should be designed by the PIM working group. Atwood & Islam Expires April 18, 2007 [Page 8]
Internet-Draft PIM-SM Link-local Security October 2006 7. Number of Security Associations The number of Security Associations to be maintained by a PIM router depends on the required security level and available key management. This SHOULD be decided by the Network Administrator. Two different ways are shown in Figure 1 and 2. It is assumed that A, B and C are three PIM routers, where B and C are directly connected with A, and there is no direct link between B and C. A | SAa ------------>| SAb <------------| SAc <------------| | B | SAb ------------>| SAa <------------| | C | SAc ------------>| SAa <------------| | Directly connected network Figure 1: Activate unique Security Association for each peer The first method, shown in Figure 1 is OPTIONAL to implement. In this method, each node will use a unique SA for its outbound traffic. A, B, and C will use SAa, SAb, and SAc, respectively for sending any traffic. Each node will look up the SA to be used based on the source address. A will use SAb and SAc for packets received from B and C, respectively. The number of SAs to be activated and maintained by a PIM router will be equal to the number of directly connected routers plus one, for sending its own traffic. Also, the addition of a PIM router in the network will require the addition of another SA on every directly connected PIM router. This solution will be scalable and practically feasible with an automated key management protocol. However, it MAY be used with manual key management, if the number of directly connected router(s) is small. Atwood & Islam Expires April 18, 2007 [Page 9]
Internet-Draft PIM-SM Link-local Security October 2006 A | SAo ------------>| SAi <------------| | B | SAo ------------>| SAi <------------| | C | SAo ------------>| SAi <------------| | Directly connected network Figure 2: Activate two Security Associations The second method, shown in Figure 2, MUST be supported by every implementation. In this simple method, all the nodes will use two SAs, one for sending (SAo) and the other for receiving (SAi) traffic. Thus, the number of SAs is always two and will not be affected by addition of a PIM router. This document RECOMMENDS the above method for manual key configuration. However, it MAY also be used with automated key configuration. When manually configured, the method suffers from impersonation attacks as mentioned in the Security Considerations section. Atwood & Islam Expires April 18, 2007 [Page 10]
Internet-Draft PIM-SM Link-local Security October 2006 8. Rekeying This section will provide the rekeying rules. It will be written once is is decided whether or not to specify a re-keying protocol as part of this document. 8.1. Rekeying Procedure TBD 8.2. KeyRolloverInterval TBD 8.3. Rekeying Interval TBD Atwood & Islam Expires April 18, 2007 [Page 11]
Internet-Draft PIM-SM Link-local Security October 2006 9. IPsec Protection Barrier and SPD This section will provide the SPD selection function rules. It will be written once it is decided whether we need confidentiality in addition to authentication. Atwood & Islam Expires April 18, 2007 [Page 12]
Internet-Draft PIM-SM Link-local Security October 2006 10. Security Association Lookup For an SA that carries unicast traffic, three parameters (SPI, destination address and security protocol type (AH or ESP)) are used in the Security Association lookup process for inbound packets. The SPI is sufficient to specify an SA. However, an implementation may use the SPI in conjunction with the IPsec protocol type (AH or ESP) for the SA lookup process. According to RFC 4301 [4] and the AH specification [2], for multicast SAs, in conjunction with the SPI, the destination address or the destination address plus the sender address may also be used in the SA lookup. The security protocol field is not employed for a multicast SA lookup. The reason for the various prohibitions in the IPsec RFCs concerning multisender multicast SAs lies in the difficulty of coordinating the multiple senders. However, if the use of multicast for link-local messages is examined, it may be seen that in fact the communication need not be coordinated---from the prospective of a receiving router, each peer router is an independent sender. In effect, link-local communication is an SSM communication that happens to use an ASM address (which is shared among all the routers). Two possibilities may be envisaged: 1. The address ALL_PIM_ROUTERS can be specified to operate as a set of SSM Security Associations, when IPsec is enabled; 2. Secure Link-local communication can be specified to occur on an SSM address, instead of ALL_PIM_ROUTERS. Given that the sender address of an incoming packet will be (globally) unique for a specific sender and in conjunction with the SPI it will be possible for a receiver to sort out the associated SA for that sender from all the SAD entries (even if a single SAD is maintained regardless of the number of interfaces), this document mandates that the SPI and the sender address MUST be used in the SA lookup process. Atwood & Islam Expires April 18, 2007 [Page 13]
Internet-Draft PIM-SM Link-local Security October 2006 11. Activating the Anti-replay Mechanism Although link-level messages on a link constitute a multiple-sender, multiple-receiver group, the use of the sender address for SA lookup essentially resolves the communication into a separate SA for each sender/destination pair, even for the case where only two SAs are used for the entire administrative region. Therefore, the statement in the AH RFC (section 2.5 of [2]) that "for a multi-sender SA, the anti-replay features are not available" becomes irrelevant to the PIM-SM link-local message exchange. To activate the anti-replay mechanism in a unicast communication, the receiver uses the sliding window protocol and it maintains a sequence number for this protocol. This sequence number starts from zero. Each time the sender sends a new packet, it increments this number by one. In a multi-sender multicast group communication, a single sequence number for the entire group would not be enough. The whole scenario is different for PIM link-local messages. These messages are sent to local links with TTL = 1. A link-local message never propagates through one router to another. The use of the sender address for SA lookup converts the relationship from a multiple-sender group to multiple single-sender associations. This specification RECOMMENDS activation of the anti-replay mechanism only if the SAs are assigned using an automated key management. In manual key management, the anti-replay SHOULD NOT be activated. If the number of router(s) to be assigned manually is small, the Network Administrator MAY consider to activate anti-replay. If anti-replay is activated a PIM router MUST maintain a different sliding window for each directly connected sender. If the SAs are activated according to Figure 2, that is all the nodes use only two SAs, one SA for sending and the other is for receiving traffic, a PIM router MAY still activate the anti-replay mechanism. Instead of maintaining only two SAs, the router will maintain the same number of SAs as explained in the first method (see Figure 1) (because of the differentiation based on sender address). For each active SA a corresponding sequence number MUST be maintained. Thus, a PIM router will maintain a number of identical SAs, except that the sender address and the sequence number are different for each SA. In this way a PIM router will be at least free from all the attacks that can be performed by replaying PIM-SM packets. Note that when activating anti-replay with manual key configuration, the following actions must be taken by the network administrator: Atwood & Islam Expires April 18, 2007 [Page 14]
Internet-Draft PIM-SM Link-local Security October 2006 a. If a new router is added, the Network Administrator MUST add a new SA entry in each peer router. b. If an existing router has to restart, the Network Administrator MUST refresh the counter (ESN, see section 13) to zero for all the peer routers. This implies deleting all the existing SAs and adding a new SA with the same configuration and a re-initialized counter. Atwood & Islam Expires April 18, 2007 [Page 15]
Internet-Draft PIM-SM Link-local Security October 2006 12. Implementing a Security Association Database per Interface RFC 4601 suggests that it may be desirable to implement a separate Security Association Database (SPD) for each router interface. The use of the source address to resolve the SAs implies that the use of an SAD per interface is not necessary. This is in conformance with RFC 4301, which explicitly removes the requirement for separate SPDs that was present in RFC 2401 [6]. Atwood & Islam Expires April 18, 2007 [Page 16]
Internet-Draft PIM-SM Link-local Security October 2006 13. Extended Sequence Number In the [2], there is a provision for a 64-bit Extended Sequence Number (ESN) as the counter of the sliding window used in the anti- replay protocol. Both the sender and the receiver maintain a 64-bit counter for the sequence number, although only the lower order 32 bits is sent in the transmission. In other words, it will not affect the present header format of AH. If ESN is used, a sender router can send 2^64 -1 packets without any intervention. This number is very large, and from a PIM router's point of view, a PIM router can never exceed this number in its lifetime. This makes it reasonable to permit manual configuration for a small number of PIM routers, since the sequence number will never roll over. For this reason, when manual configuration is used, ESN SHOULD be deployed as the sequence number for the sliding window protocol. Atwood & Islam Expires April 18, 2007 [Page 17]
Internet-Draft PIM-SM Link-local Security October 2006 14. Security Considerations The whole document considers the security issues of PIM link-local messages and proposes a mechanism to protect them. Limitations of manual keys: The following are some of the known limitations of the usage of manual keys. o If the replay protection cannot be provided, the PIM routers will not be secured against all the attacks that can be performed by replaying PIM packets. o Manual keys are usually long lived (changing them often is a tedious task). This gives an attacker enough time to discover the keys. o As the administrator is manually configuring the keys, there is a chance that the configured keys are weak (there are known weak keys for DES/3DES at least). Impersonation attacks: The usage of the same key on all the PIM routers connected to a link leaves them all insecure against impersonation attacks if any one of the PIM routers is compromised, malfunctioning, or misconfigured. Detailed analysis of various vulnerabilities of routing protocols is provided in [12]. For further discussion of PIM-SM and multicast security the reader is referred to [13], [14] and the Security Considerations section of RFC 4601. Atwood & Islam Expires April 18, 2007 [Page 18]
Internet-Draft PIM-SM Link-local Security October 2006 15. References 15.1. Normative References [1] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [2] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [5] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004. 15.2. Informative References [6] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [7] Islam, S., "Security Issues in PIM-SM Link-local Messages, Master's Thesis, Concordia University", December 2003. [8] Islam, S., "Security Issues in PIM-SM Link-local Messages, Proceedings of LCN 2004", November 2004. [9] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [10] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: Group Secure Association Key Management Protocol", RFC 4535, June 2006. [11] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003. [12] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", draft-ietf-rpsec-routing-threats-07 (work in progress), October 2004. [13] Lingard, J. and P. Savola, "Last-hop Threats to Protocol Independent Multicast (PIM)", draft-savola-pim-lasthop-threats-02 (work in progress), June 2006. Atwood & Islam Expires April 18, 2007 [Page 19]
Internet-Draft PIM-SM Link-local Security October 2006 [14] Savola, P., Lehtonen, R., and D. Meyer, "PIM-SM Multicast Routing Security Issues and Enhancements", draft-ietf-mboned-mroutesec-04 (work in progress), October 2004. Atwood & Islam Expires April 18, 2007 [Page 20]
Internet-Draft PIM-SM Link-local Security October 2006 Authors' Addresses J. William Atwood Concordia University/CSE 1455 de Maisonneuve Blvd, West Montreal, QC H3G 1M8 Canada Phone: +1(514)848-2424 ext3046 Email: bill@cse.concordia.ca URI: http://www.cs.concordia.ca/~bill Salekul Islam Concordia University/CSE 1455 de Maisonneuve Blvd, West Montreal, QC H3G 1M8 Canada Atwood & Islam Expires April 18, 2007 [Page 21]
Internet-Draft PIM-SM Link-local Security October 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 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 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Atwood & Islam Expires April 18, 2007 [Page 22]
