idnits 2.17.1 draft-giuliano-mboned-v6mcast-framework-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2003) is 7621 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) == Missing Reference: 'RFC 2119' is mentioned on line 90, but not defined == Unused Reference: 'RFC2119' is defined on line 340, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-ssm-arch-03 == Outdated reference: A later version (-09) exists of draft-ietf-pim-bidir-05 == Outdated reference: A later version (-06) exists of draft-ietf-bgmp-spec-05 == Outdated reference: A later version (-11) exists of draft-ietf-idmr-dvmrp-v3-10 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Leonard Giuliano 2 draft-giuliano-mboned-v6mcast-framework-01.txt Juniper Networks 3 Greg Shepherd 4 Procket Networks 5 Matthew Davy 6 Indiana University 7 Expires: December 2003 June 2003 9 Framework for Deploying Interdomain IPv6 Multicast 10 12 Status of this Document 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This document is a product of an individual. Comments are solicited 34 and should be addressed to the author(s). 36 Copyright Notice 38 Copyright (C) The Internet Society (2003). All Rights Reserved. 40 Abstract 42 This document describes an architectural framework for deploying 43 interdomain multicast for IPv6 with simplicity, scalability, 44 efficiency and security as the primary goals, applying the lessons 45 learned from deploying IPv4 multicast. In order to achieve this 46 objective, the deprecation of network-based source discovery, and 47 therefore Any Source Multicast, is proposed. Source-Specific 48 Multicast is proposed as the service model supported for deploying 49 interdomain IPv6 multicast. The architectural components responsible 50 for providing source discovery are also discussed. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Source Discovery . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Network-based vs. Application-based Source 57 Discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Interdomain Multicast for IPv6 . . . . . . . . . . . . . . . . 6 59 4. Intradomain Multicast for IPv6 . . . . . . . . . . . . . . . . 7 60 4.1. Other Service Models for Intradomain IPv6 Mul- 61 ticast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 8 63 5.1. Control Plane Vulnerabilities . . . . . . . . . . . . . . . 8 64 5.2. Data Plane Vulnerabilities. . . . . . . . . . . . . . . . . 9 65 6. Intellectual Property. . . . . . . . . . . . . . . . . . . . . 9 66 7. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 10 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 8.1. Normative References. . . . . . . . . . . . . . . . . . . . 11 69 8.2. Informative References. . . . . . . . . . . . . . . . . . . 11 70 9. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 13 71 10. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 13 73 1. Introduction 75 The deployment of IPv4 multicast has been much slower than initially 76 predicted. While there are many reasons for this slow adoption, one 77 of the dominant factors has been the complexity involved in 78 implementing and deploying multicast. In the past, interim 79 workarounds were applied to address short-term deficiencies in the 80 architecture. Unfortunately, many of these temporary fixes have 81 become integral components that have proven difficult to "undeploy" 82 and have stifled future developments and enhancements. This document 83 proposes an architecture for IPv6 that applies the lessons learned 84 from deploying IPv4 multicast, rather than repeating the mistakes of 85 the past. 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC 2119]. 91 2. Source Discovery 93 The majority of the complexity involved in multicast comes from the 94 assumption that the network is responsible for the discovery of 95 sources. The receiver of multicast traffic merely requests data for 96 a given group address. It is the network's job to find all the 97 sources for this group and deliver their packets to the receiver. 98 This original model of multicast, where source discovery is a 99 function of the network layer, is known as Any Source Multicast (ASM) 100 [RFC1112]. 102 However, with the Source-Specific Multicast [SSM] service model, the 103 receiving host determines the address of the source(s) through out- 104 of-band means and requests data for a group from the specified 105 source(s). By specifying the source in addition to the group, the 106 network no longer needs to determine all the sources, thus the 107 function of the network becomes much simpler. 109 2.1. Network-based vs. Application-based Source Discovery 111 It should be noted that in the vast majority of cases, the end result 112 of ASM and SSM is functionally identical. That is, since the 113 predominant implementations and deployments of Protocol Independent 114 Multicast- Sparse Mode (PIM-SM) [PIM-SM] on the Internet today (the 115 de facto standard protocol for ASM multicast routing) switchover from 116 the shared tree to the shortest path tree (SPT) immediately, traffic 117 is delivered from source to receiver along the SPT. Therefore, since 118 the end result of ASM and SSM is the same (ie, SPTs), the debate is 119 not ASM vs. SSM. Rather, the issue is network-based vs. out-of-band 120 source discovery. For the sake of this discussion, we will assume 121 the application layer provides this out-of-band function. 123 Since the original vision of multicast assumes the network will 124 provide source discovery, multicast protocols have required 125 mechanisms to support this vision, and these mechanisms generally 126 have introduced sub-optimal properties. For example, dense protocols 127 like Distance Vector Multicast Routing Protocol (DVMRP) [DVMRP] and 128 PIM-DM periodically flood data throughout the domain to inform 129 routers in the domain of active sources. Sparse protocols like PIM- 130 SM employ rendezvous points (RPs) so that one router in the domain 131 will be responsible for being aware of active sources for a given 132 group range. The mechanisms needed to provision an RP, inform 133 routers throughout the domain of the identity of the RP, register 134 sources with the RP, and exchange source information between 135 different RPs have each contributed a significant amount of 136 complexity to the architecture. In each case, the primary 137 disadvantages of these protocols (ie, lack of scalability of flooding 138 in dense protocols, and the complexity of RP behavior in sparse 139 protocols) can be attributed to source discovery. Furthermore, IPv4 140 uses MSDP [MSDP] to distribute active source information between RPs. 141 With MSDP, all speakers of the protocol must maintain a cache 142 containing information about every active source on the Internet. 143 MSDP relies upon an extremely complex set of peer-RPF rules which are 144 not well understood, are very challenging to troubleshoot and are 145 often circumvented (for example, by using mesh-groups). 147 Long ago it was determined that maintaining a list of all the 148 hostnames or all the websites on the Internet was unwise. This task 149 was deemed unsuitable even for hosts to provide. However, when the 150 network provides multicast source discovery, we assume that routers 151 will provide this exact function. 153 The main reason why network-based source discovery was deemed 154 necessary was because it was believed that some multi-source 155 applications (eg, videoconferencing, online gaming) could only be 156 supported in this manner. However, Section 1 of [SSM] describes how 157 even these applications can be supported with application-based 158 source discovery: 160 SSM can be used to build multi- source applications where all 161 participants' identities are not known in advance, but the 162 multi-source "rendezvous" functionality does not occur in the 163 network layer in this case. Just like in an application that 164 uses unicast as the underlying transport, this functionality can 165 be implemented by the application or by an application-layer 166 library. 168 [MULT-SSM] and [DISC-SSM] further examine and propose ways to support 169 multi-source discovery in SSM. 171 Since network-based source-discovery significantly contributes to the 172 cost and complexity of the network infrastructure without providing 173 commensurate functionality and benefit, this document proposes to 174 deprecate network-based multicast source discovery in IPv6. With 175 source discovery provided by the application layer, SSM is proposed 176 as the only service model supported for deploying interdomain IPv6 177 multicast. 179 3. Interdomain Multicast for IPv6 181 The primary issue with interdomain multicast in IPv6 today is the 182 support for RPs in different domains. In IPv4, MSDP addresses this 183 problem. However, because of the undesirable properties of MSDP 184 mentioned earlier, there appears to be little interest for 185 introducing MSDP to IPv6. 187 BGMP [BGMP] has been specified as a protocol to provide support for 188 interdomain multicast in IPv6. Specifically, support for RPs in 189 different domains is described. However, many believe BGMP is too 190 complex to be a feasible option for deployment. There are currently 191 no known implementations of BGMP. 193 [EMBED] has been proposed to address this issue by embedding the IP 194 address of the RP within the multicast group address. However, this 195 would require a new behavior for the PIM-SM protocol, specifically, 196 sending PIM joins toward an RP in another domain, to be investigated 197 and specified. And this new behavior would need to be deployed on 198 all routers over which this multicast traffic would flow. 200 With network-based source discovery deprecated, there is no longer a 201 need for PIM-SM RPs in IPv6. Interdomain multicast will work with a 202 subset of PIM-SM functionality (namely, (S,G) Joins/Prunes). Thus, 203 interdomain multicast for IPv6 requires no changes to any protocols 204 and can be deployed with current implementations of PIM-SM. 206 4. Intradomain Multicast for IPv6 208 PIM-SM, as defined in [PIM-SM], requires no changes to operate within 209 an IPv6 domain. Most current intradomain deployments of IPv4 210 multicast use Anycast RP to provide redundancy and load sharing. 211 Since Anycast RP relies on MSDP, there is currently no way to provide 212 this same functionality in IPv6. [Any-PIM] proposes an extension to 213 the PIM-SM register process to accomplish the internal MSDP 214 functionality of Anycast RP. 216 With network-based source discovery deprecated, there is no longer a 217 need for PIM-SM RPs. Intradomain multicast for IPv6 requires no 218 changes to any protocols and can be deployed with current 219 implementations of PIM-SM or BiDir-PIM. 221 4.1. Other Service Models for Intradomain IPv6 Multicast 223 There may still be some desire to support other multicast service 224 models such as ASM and Bidirectional-PIM (BiDir-PIM) [BIDIR] within a 225 domain. Following the philosophy of "what one does inside one's own 226 domain is one's own business", this document does not prohibit the 227 use of ASM or BiDir-PIM for intradomain purposes as long as it does 228 not leak out to the rest of the Internet. This is somewhat analogous 229 to using RFC-1918 addressing within a domain. 231 5. Security Considerations 233 IP Multicast is inherently vulnerable to attack because it allows a 234 host to create state within the control and data planes of the 235 network. Network-based source discovery amplifies this problem, as 236 the mechanisms that enable the network to discover sources generally 237 increase the likelihood and impact of attacks. 239 In recent years, IPv4 RPs and other MSDP speakers have been the 240 victims of DoS attacks during the Ramen and Slammer Worm attacks 241 [MCAST-DOS]. In both cases, these attacks were not even targeting 242 the multicast infrastructure. Rather, they inflicted damage 243 accidentally. Little has been done to harden this infrastructure, 244 and today IPv4 multicast networks remain vulnerable to attack. This 245 is because the mechanisms that provide network-based source discovery 246 are inherently prone to DoS attack. 248 5.1. Control Plane Vulnerabilities 250 If, for example, someone on an IPv4 multicast-enabled network 251 performs a port scan on a /16 multicast range of addresses, the first 252 hop PIM-SM router will create register messages for each packet sent 253 to a different group and send these 65k PIM registers to an RP, which 254 will have to decapsulate and create register state. The RP will then 255 create MSDP SAs for each s-g tuple and flood 65k SAs to all other 256 MSDP speakers on the Internet. Even with the strictest of filters in 257 place, the ASM service model dictates that any host could validly 258 source multicast traffic for 224.2/16 and 233/8. This means that a 259 single source could validly create state for 16.8 million different 260 groups, and the network would have to maintain this state. With 261 filters in place, the best that could be hoped for is the decreased 262 probability that an accidental attack (eg, a port scan on a random 263 multicast address range) will have an impact. For this reason, some 264 have suggested rate limiting. However, rate limiting control traffic 265 creates a new vulnerability to DoS attack since it is not possible 266 (or at least is very difficult) to tell the difference between bad 267 sources and good ones, and they both must now contend for the 268 configured limit of resources. Therefore, rate limits reduce the 269 probability that a router will run out of memory and crash, but 270 increase the probability that the multicast infrastructure will be 271 unable to create and maintain state, causing black holes for valid 272 sources during an attack. 274 MSDP has not yet been defined, implemented or deployed for use in 275 IPv6, however the DR-RP PIM register process is the same for IPv6 and 276 IPv4 ASM. Of course the IPv6 group range is much larger. For 277 example, the IPv6 group range is FF::0/8, so a single host could 278 validly source to nearly 2^120 groups and the network would be 279 responsible for maintaining this state. 281 With network-based source discovery deprecated, there is no need for 282 PIM-SM RPs, MSDP or the PIM-SM register process. This significantly 283 reduces the opportunities for a malicious attack. While state 284 creation is driven both by sources and receivers in ASM, only 285 receivers can create state in the network with SSM. SSM, like ASM, 286 is still vulnerable to an (S,G) flood attack, but is not vulnerable 287 to any of the other control plane attacks mentioned above. 289 5.2. Data Plane Vulnerabilities 291 In addition to the control plane vulnerabilities mentioned above, ASM 292 and BiDir-PIM provide easy targets for DoS attacks in the data plane. 293 When a receiving host reports interest in a group, it requests and is 294 delivered packets from ALL sources for that group. There is no way 295 to prevent delivery of unwanted sources. For example, one malicious 296 attacker (or misconfigured host) could transmit a high data rate of 297 unwanted traffic to a group, and all receivers of this group would be 298 flooded with this traffic. 300 Since an SSM subscriber explicitly specifies the source, data from 301 unwanted sources will not be delivered. In order to launch a data 302 plane attack, a malicious host must spoof the source address of the 303 SSM channel AND must be on the shortest path from the subscriber to 304 the source. While this is technically possible, it is significantly 305 less likely. 307 6. Intellectual Property 309 The IETF takes no position regarding the validity or scope of any 310 intellectual property or other rights that might be claimed to 311 pertain to the implementation or use of the technology described in 312 this document or the extent to which any license under such rights 313 might or might not be available; neither does it represent that it 314 has made any effort to identify any such rights. Information on the 315 IETF's procedures with respect to rights in standards-track and 316 standards-related documentation can be found in BCP-11. Copies of 317 claims of rights made available for publication and any assurances of 318 licenses to be made available, or the result of an attempt made to 319 obtain a general license or permission for the use of such 320 proprietary rights by implementors or users of this specification can 321 be obtained from the IETF Secretariat. 323 The IETF invites any interested party to bring to its attention any 324 copyrights, patents or patent applications, or other proprietary 325 rights which may cover technology that may be required to practice 326 this standard. Please address the information to the IETF Executive 327 Director. 329 7. Acknowledgments 331 The authors would like to thank Vijay Gill, John Zwiebel, Tom 332 Pusateri, Nidhi Bhaskar and Toerless Eckert for their input. Dave 333 Meyer provided extensive comments on the initial version of this 334 draft. 336 8. References 338 8.1. Normative References 340 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 341 Requirement Levels", RFC 2119, March, 1997. 343 [SSM] Holbrook, H., and B. Cain, "Source-Specific Multicast 344 for IP", draft-ietf-ssm-arch-03.txt. Work in Progress. 346 8.2. Informative References 348 [RFC1112] S. Deering, "Host Extensions for IP Multicasting", RFC 349 1112, August 1989 351 [PIM-SM] B. Fenner, et. al., "Protocol Independent 352 Multicast-Sparse Mode (PIM-SM): Protocol Specification 353 (Revised)", Work in Progress. 355 [MSDP] Meyer, D., and B. Fenner (Editors), "The Multicast 356 Source Discovery Protocol (MSDP)", 357 draft-ietf-msdp-spec-20.txt. Work in Progress. 359 [BIDIR] M. Handley, et. al., "Bi-directional Protocol 360 Independent Multicast", draft-ietf-pim-bidir-05.txt, 361 Work in Progress. 363 [BGMP] D. Thaler, "Border Gateway Multicast Protocol (BGMP): 364 Protocol Specification", draft-ietf-bgmp-spec-05.txt, 365 Work in Progress. 367 [EMBED] Savola, P., and B. Haberman, "Embedding the Address of 368 RP in IPv6 Multicast Address", 369 draft-savola-mboned-mcast-rpaddr-03.txt, Work in 370 Progress 372 [Any-PIM] Farinacci, D., and Y. Cai, "Anycast-RP using PIM", 373 draft-farinacci-pim-anycast-rp-00.txt, Work in 374 Progress 376 [MULT-SSM] M. Hoerdt, et al., "Multi-source communications over 377 SSM networks", 378 draft-hoerdt-mboned-multisource-ssm-00.txt, Work in 379 Progress 381 [DISC-SSM] F. Beck, et al., "Source Discovery Protocol in SSM 382 Networks", 383 draft-beck-mboned-ssm-source-discovery-protocol-00.txt, 384 Work in Progress 386 [MCAST-DOS] T. Pusateri, "Multicast DoS", In Proceedings of MBONED 387 Working Group, IETF56, March 2003 389 [DVMRP] T. Pusateri, "Distance Vector Multicast Routing Protocol", 390 draft-ietf-idmr-dvmrp-v3-10.txt, Work in Progress 392 9. Author's Addresses 394 Leonard Giuliano 395 Juniper Networks 396 Email: lenny@juniper.net 398 Greg Shepherd 399 Procket Networks 400 Email: shep@procket.com 402 Matthew Davy 403 Indiana University 404 Email: mpd@iu.edu 406 10. Full Copyright Statement 408 Copyright (C) The Internet Society (2003). All Rights Reserved. 410 This document and translations of it may be copied and furnished to 411 others, and derivative works that comment on or otherwise explain it 412 or assist in its implementation may be prepared, copied, published 413 and distributed, in whole or in part, without restriction of any 414 kind, provided that the above copyright notice and this paragraph are 415 included on all such copies and derivative works. However, this 416 document itself may not be modified in any way, such as by removing 417 the copyright notice or references to the Internet Society or other 418 Internet organizations, except as needed for the purpose of 419 developing Internet standards in which case the procedures for 420 copyrights defined in the Internet Standards process must be 421 followed, or as required to translate it into languages other than 422 English. 424 The limited permissions granted above are perpetual and will not be 425 revoked by the Internet Society or its successors or assigns. 427 This document and the information contained herein is provided on an 428 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 429 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 430 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 431 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 432 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.