idnits 2.17.1 draft-bhatia-karp-pim-gap-analysis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 16, 2013) is 3782 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 191, but no explicit reference was found in the text == Unused Reference: 'RFC4306' is defined on line 215, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bhatia 3 Internet-Draft Alcatel-Lucent 4 Intended status: Standards Track M. Jethanandani 5 Expires: June 19, 2014 Ciena Corporation 6 D. Zhang 7 Huawei Technologies Co. LTD. 8 December 16, 2013 10 Analysis of Protocol Independent Multicast Sparse Mode (PIM-SM) Security 11 According to KARP Design Guide 12 draft-bhatia-karp-pim-gap-analysis-01 14 Abstract 16 This document analyzes the Protocol Independent Multicast Sparse Mode 17 (PIM-SM) according to the guidelines set forth in the KARP Design 18 Guide. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 19, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 1. Introduction 54 This document performs the initial analysis of the current state of 55 Protocol Independent Multicast Sparse Mode (PIM-SM) [RFC4601] 56 according to the requirements of KARP Design Guidelines [RFC6518] 58 The base PIM-SM specification [RFC4601] introduces the use non- 59 cryptographic authentication approaches to protect PIM-SM packets and 60 recommends the use of transport mode of IPsec AH [RFC4302] to protect 61 PIM-SM unicast and multicast packets. The memo assumes that the SAs 62 are manually deployed. 64 Authentication and Confidentiality in PIM-SM Link-Local Messages 65 [RFC5796] proposes the mechanisms to authenticate the PIM-SM 66 multicast messages using the IP security (IPsec) Encapsulating 67 Security Payload (ESP) [RFC4303] or (optionally) the IP 68 Authentication Header (AH) [RFC4302] . 70 The document specifies manual key management as mandatory to 71 implement and provides the necessary structure for an automated key 72 management protocol that the PIM routers may use. 74 However, some gaps remain between the current state and the 75 requirements for manually keyed routing security expressed in the 76 [RFC6862] document. This document explores these gaps and proposes 77 directions for addressing the gaps. 79 2. Current State 81 Unlike OSPFv2 [RFC2328], PIM-SM does not propose any in-band security 82 solution. Instead, IPsec is used to protect both unicast and 83 muticast control packets. 85 Authentication and Confidentiality in PIM-SM Link-Local Messages 86 [RFC5796] describes how IPsec can be used to secure and authenticate 87 PIM-SM protocol packets. It mandates the use of manual keying and 88 optionally provides support for an automated group key management 89 mechanism. However, it leaves the procedures for implementing 90 automated group key management to other documents and does not 91 discuss how this can be done. 93 The mechanism proposed in Authentication and Confidentiality in PIM- 94 SM Link-Local Messages [RFC5796] supports packet level integrity 95 protection using a wide variety of cryptographic algorithms. In 96 addition, the Security Parameter Index (SPI) [RFC4301] provides an 97 identifier for the security association. Along with other IPsec 98 facilities, SPI provides a mechanism for moving from one key to 99 another, meeting the key rollover requirements. Because the 100 algorithm can be changed as part of rekeying, algorithm agility is 101 provided. 103 Authentication and Confidentiality in PIM-SM Link-Local Messages 104 [RFC5796] uses manually configured keys, rather than some automated 105 key management protocol, since no suitable key management mechanism 106 was available at this time. This is because PIM-SM adjacencies are 107 formed on a one-to-many basis and most key management mechanisms are 108 designed for a one-to-one communication model. Since authentication 109 and confidentiality in PIM-SM Link-Local Messages [RFC5796] uses 110 manual keying it clearly states that it provides no protection 111 against both inter-session and intra-session replay attacks. This 112 can be exploited in various ways. For instance, by replaying the 113 Join message sent by a legitimate requester, an attacker can direct 114 multicast traffic to be delivered to links where it is not required. 115 Similarly, replaying a Prune Message can deprive the receivers from 116 that multicast traffic. 118 3. Deployment Issues Imposed by IPsec and Manual Keying 120 Since multiple PIM-SM routers can exist on a single link, it would be 121 worth noting that setting up IPsec Security Associations (SAs) 122 manually can be a very tedious process. The routers might not even 123 support IPsec, rendering automatic key negotiation either impractical 124 (in those platforms where an extra license has to be obtained for 125 using IPsec) or infeasible (in those platforms where IPsec support is 126 not available at all). 128 PIM-SM [RFC4601] requires all PIM-SM routers to configure an IPsec 129 Security Association (SA) when sending PIM Register packets to each 130 Rendezvous Point (RP). This can become highly unscalable as the 131 number of RPs increase or in case of Anycast-RP [RFC4610] deployment 132 where each PIM-SM router close to the source will need to establish 133 IPsec tunnels to all PIM-SM routers in the Anycast-RP set. 135 Similarly, the Security Policy Database at each Rendezvous Point 136 should be configured to choose an SA to use when sending Register- 137 Stop messages. Because Register-Stop messages are unicast to the 138 destination DR, a different SA and a potentially unique SPI are 139 required for each DR. 141 In order to simplify the management problem, PIM-SM [RFC4601] 142 suggests using the same authentication algorithm and authentication 143 parameters, regardless of the sending RP and regardless of the 144 destination DR. While this alleviates the management problem by some 145 extent it still requires a unique SA on each DR which can result in a 146 significant scaling issue as the size of the PIM-SM network grows. 148 4. Gap Analysis 150 In PIM-SM, multiple types of PIM messages (Hello, Join/Prune, 151 Bootstrap, Assert) are delivered with multicast. As it exists today, 152 PIM-SM supports only manual key management. When using manual 153 keying, the replay protection mechanism (replay protection window) of 154 IPSec will be switched off. That is why IPSec cannot protect against 155 any replay protection in this case. In addition, the PIM messages do 156 not have any replay protection mechanism, e.g. nonce or sequence 157 numbers. Therefore, PIM-SM is subject to both inter- and intra- 158 connection replay attacks. From the aspect of meeting the 159 requirements for replay protection, a significant gap exists between 160 the optimal state and where PIM-SM is today. 162 In order to encourage deployment of PIM-SM security, an 163 authentication option is required that does not have the deployment 164 challenges of IPSec. We therefore need an alternate authentication 165 mechanism to IPSec as suggested by the first phase of the KARP design 166 guide, where the guide suggests securing the routing protocols using 167 manual keying. 169 The new mechanism should work for both the unicast and multicast PIM- 170 SM routing exchanges. It should also provide both inter-session and 171 intra-session replay protection that has been spelled out in the 172 [RFC6862] document. 174 5. Security Considerations 176 TBD 178 6. IANA Considerations 180 This document places no new request to IANA 182 7. Acknowledgements 184 We would like to thank Stig Venaas and Bill Atwood for reviewing and 185 providing feedback on this draft. 187 8. References 189 8.1. Normative References 191 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 192 Requirement Levels", BCP 14, RFC 2119, March 1997. 194 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 195 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 196 Protocol Specification (Revised)", RFC 4601, August 2006. 198 [RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and 199 Confidentiality in Protocol Independent Multicast Sparse 200 Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010. 202 8.2. Informative References 204 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 206 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 207 Internet Protocol", RFC 4301, December 2005. 209 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 210 2005. 212 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 213 4303, December 2005. 215 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 216 4306, December 2005. 218 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol 219 Independent Multicast (PIM)", RFC 4610, August 2006. 221 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 222 Routing Protocols (KARP) Design Guidelines", RFC 6518, 223 February 2012. 225 [RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and 226 Authentication for Routing Protocols (KARP) Overview, 227 Threats, and Requirements", RFC 6862, March 2013. 229 Authors' Addresses 231 Manav Bhatia 232 Alcatel-Lucent 233 India 235 Email: manav.bhatia@alcatel-lucent.com 236 Mahesh Jethanandani 237 Ciena Corporation 238 3939 North 1st Street 239 San Jose, CA 95134 240 USA 242 Phone: +1 (408) 904-2160 243 Email: mjethanandani@gmail.com 245 Dacheng Zhang 246 Huawei Technologies Co. LTD. 247 Beijing 248 China 250 Email: zhangdacheng@huawei.com