idnits 2.17.1 draft-chown-mboned-multicast-filtering-02.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 65 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 12, 2012) is 4420 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mboned T. Chown 3 Internet-Draft University of Southampton 4 Intended status: Informational L. Giuliano 5 Expires: September 13, 2012 Juniper Networks 6 March 12, 2012 8 Multicast Filtering Practices 9 draft-chown-mboned-multicast-filtering-02 11 Abstract 13 Operators of multicast networks may apply various filters to 14 multicast traffic at boundary routers or on MSDP peerings. The aim 15 of this text is to discuss appropriate filtering policies, as well as 16 documenting existing filtering practices, with a view to generating 17 some discussion towards producing guidance on best filtering 18 practice. 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 September 13, 2012. 37 Copyright Notice 39 Copyright (c) 2012 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 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. General Discussion of Policies . . . . . . . . . . . . . . . . 4 56 2.1. Multicast Addressing and Domain Borders . . . . . . . . . 4 57 2.2. MSDP SA Policy and Policers . . . . . . . . . . . . . . . 4 58 2.3. Multicast Scoping . . . . . . . . . . . . . . . . . . . . 5 59 2.4. PIM Policy . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.5. IGMP Policy . . . . . . . . . . . . . . . . . . . . . . . 6 61 2.6. SAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 3. Summary of Reported Filtering Practices . . . . . . . . . . . 6 63 3.1. Border and MSDP Filtering . . . . . . . . . . . . . . . . 7 64 3.2. Organisational filtering . . . . . . . . . . . . . . . . . 9 65 3.3. Subnet filtering . . . . . . . . . . . . . . . . . . . . . 9 66 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 70 8. Informative References . . . . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 73 1. Introduction 75 Multicast filtering can be applied at a multicast boundary or on an 76 MSDP peering as a means to prevent unintended leakage of multicast 77 traffic beyond its desired scope. An informal discussion of 78 filtering practices suggested that those practices vary from 79 organisation to organisation. The aim of this text is to gather and 80 document commonly used existing filtering practices. Whether it is 81 then possible to draw up a definitive best practice is to be 82 determined; it is quite possible that due to the shifting nature of 83 the target that a point-in-time recommendation would quickly be 84 overtaken by events. For example, the recent addition of unicast 85 prefix-based IPv4 multicast addresses [RFC6034] meant that filtering 86 of all of 234.0.0.0/8 became undesirable. However, general 87 principles may remain valid over time. 89 The text begins with a discussion of appropriate policies in Section 90 2, followed by Section 3 in which we document a summary of reported 91 practices at border, organisational and subnet scopes. We then draw 92 some conclusions in Section 3. 94 For sites on academic research networks, some examples of filtering 95 recommendations already exists, e.g. in documentation [I2multicast] 96 from the Internet2 Multicast WG, and in the JANET IPv4 Multicast 97 Guide [JANETmulticast]. There is also a more specific proposal for 98 the Rutgers network [RutgersProposal], which includes a good 99 discussion of organisational-local scope address usage within its 100 network as a whole. 102 When determining filtering policies, one needs to consider how strict 103 to be; some ranges are not supposed to be used, but there may be no 104 harm per se in accepting them. There are certainly some ranges that 105 should not be filtered, such as the newly assigned 234.0.0.0/8 range 106 mentioned above, and the GLOP range under 233.0.0.0/8. 108 An additional resource is the registry of IPv4 multicast address 109 space held by IANA [IANAmulticast]. This registry should be a 110 definitive guide to the formal use of ranges of addresses within the 111 overall IPv4 multicast address space. A similar registry is 112 maintained for IPv6 multicast address space [IANA6multicast]. 114 This text is still quite an early draft, aimed at soliciting 115 feedback, both on content and whether the goal of the draft is 116 actually worthwhile. Different sites may have different 117 requirements. There may also be issues with handling scope 118 boundaries that need to be considered. So there may be general 119 principles that could be captured in a document such as this, even if 120 specific filtering rules are not included. 122 2. General Discussion of Policies 124 In this section we discuss how we might believe filters to be applied 125 with respect to various multicast protocol functions. This may 126 include rate limiting and policing in addition to straight filtering. 127 In the following section we summarise actual filtering practices that 128 have been reported. 130 2.1. Multicast Addressing and Domain Borders 132 To date, IPv4 multicast addresses have been assigned from the 133 following ranges for global usage: 224.0/16, 224.1/16, 224.2/16, 134 224.3/16, 224.4/16, 232/8, 233/8 and 234/8. All other IPv4 multicast 135 addresses are therefore reserved, unassigned or scoped, and as such, 136 have no legitimate reason for use on the Internet. Therefore we 137 recommend operational filters that permit these address ranges and 138 block all others at domain borders. 140 It should be noted that some networks do use multicast addresses 141 outside of these ranges for internal purposes. For example, 239/8, 142 which is administratively scoped for Organization-Local usage, is 143 functionally analogous to RFC 1918 unicast IPv4 addresses, and is 144 often used by networks to support internal customers or 145 infrastructure services. As such, these types of addresses may be 146 used within a domain, but should never be allowed to cross domain 147 borders. 149 2.2. MSDP SA Policy and Policers 151 MSDP policies should include filters that allow SAs only from the 152 assigned ASM IPv4 multicast address ranges: 224.0/16, 224.1/16, 153 224.2/16, 224.3/16, 224.4/16, 233/8 and 234/8. The 232/8 address 154 range is reserved for SSM only, and thus, should never appear in 155 MSDP. 157 The most common multicast attack vector that has appeared on the 158 Internet has been MSDP SA storms. In nearly all cases, these were 159 triggered by Internet worms that probed large blocks of addresses in 160 an attempt to scan vulnerable ports. Typically, these worms were 161 intended to scan only unicast addresses at random, however, the worm 162 coders accidentally included multicast addresses in the random pools 163 of destinations to scan. When port scans with destination addresses 164 of multicast addresses occur on multicast-enabled network, these 165 packets generate PIM register messages and, consequently, MSDP SA 166 messages according to standard PIM and MSDP procedures, resulting in 167 a flood of SA messages across the Internet that can put great strain 168 on MSDP-speaking routers. 170 MSDP filters that allow SAs from only the assigned ranges do help to 171 reduce the potential pool for these accidental attacks. However, the 172 addition of MSDP policers provides much stronger protection from SA 173 storms. MSDP policers can be applied on a per-peer and per-source 174 basis. Per-peer policers are used to detect when the number of SAs 175 received from an MSDP peer exceeds a certain configured threshold. 176 These policers are functionally analogous to BGP max prefix limits 177 applied on BGP peers, which alert an operator when the number of 178 routes received from a BGP peer exceeds a certain configured 179 threshold. Typically, this type of per-peer threshold is determined 180 by observing the number of SAs that are normally advertised by a peer 181 and then selecting some multiple of that to be a limit. For example, 182 if a peer normally advertises 2k SAs, an operator may set the per- 183 peer threshold to 5k. 185 The challenge with per-peer limits is that they are not granular 186 enough to determine good SAs from bad ones. As such, these can 187 actually lower the bar needed to launch a denial of service attack. 188 For example, with a 5k per-peer threshold, an attacker need only 189 generate 5k SAs to trigger the limit and potentially block all the 190 legitimate SAs from propagating. As such, operators may want to use 191 per-peer limits to trigger an alarm, rather than tear down the MSDP 192 session. Additionally, per-source MSDP policers can be used to 193 provide further granularity between good and bad SAs. Per-source SA 194 policers define the maximum number of SAs that can be permitted from 195 the same source (or source range). For example, an operator can use 196 a per-source limit of 1k, which would prevent any source from 197 generating more than 1k MSDP SAs. With per-source limits in place, a 198 heavily distributed attack would be necessary to generate enough MSDP 199 state to impact routers as no single source can generate enough 200 state. 202 2.3. Multicast Scoping 204 Multicast scoping is used to block multicast packets based on group 205 address. Scoping filters should be used on all domain borders to 206 allow only the assigned IPv4 multicast addresses (224.0/16, 224.1/16, 207 224.2/16, 224.3/16, 224.4/16, 232/8, 233/8 and 234/8) and block all 208 other multicast groups from ingress/egress these borders. 210 2.4. PIM Policy 212 While multicast scoping blocks traffic in the data plane, it does not 213 affect the control plane. Thus, an illegitimate group could be 214 joined, with traffic carried across a providers network only to be 215 dropped at the border by a scoping filter. However, with PIM join 216 filters, the join could be dropped at the border so that no state is 217 created in the first place. Therefore, PIM join filters can be used 218 for additional protection on all domain borders to allow joins for 219 only the assigned IPv4 multicast addresses (224.0/16, 224.1/16, 220 224.2/16, 224.3/16, 224.4/16, 232/8, 233/8 and 234/8) and block joins 221 for all other multicast groups. Additionally, PIM join filters can 222 be used to block joins based on the source address of the multicast 223 source (ie, the S in the (S,G) join). So PIM join filters can also 224 be configured to prevent joins for illegitimate interdomain sources, 225 such as RFC 1918 addresses. 227 PIM register filters can also be used to protect an RP from creating 228 register state for illegitimate groups by allowing PIM registers on 229 an RP for only the assigned IPv4 ASM multicast addresses (224.0/16, 230 224.1/16, 224.2/16, 224.3/16, 224.4/16, 233/8 and 234/8) and blocking 231 registers for all other multicast groups. PIM register filters can 232 also be configured to prevent registers for illegitimate interdomain 233 sources, such as RFC 1918 addresses. 235 2.5. IGMP Policy 237 As with PIM join filters, IGMP filters can be used for additional 238 protection on all receiver LANs to allow IGMP reports for only the 239 assigned IPv4 multicast addresses (224.0/16, 224.1/16, 224.2/16, 240 224.3/16, 224.4/16, 232/8, 233/8 and 234/8) and block reports for all 241 other multicast groups. IGMP filters can also be configured to 242 prevent IGMPv3 source-included reports for illegitimate interdomain 243 sources, such as RFC 1918 addresses. 245 2.6. SAP 247 In the early years of multicast, routers were often configured to 248 listen to the SAP group (224.2.127.254) and cache the SDP messages. 249 This was used as a quick and dirty way of determining if multicast 250 was working properly. Just by looking at the SAP/SDP cache on a 251 router and guessing if the number of session entries looked about 252 right, an operator could quickly determine if multicast flows were 253 traversing the router. However, this imprecise method of management 254 and troubleshooting eventually proved dangerous, as improperly 255 formatted SDP messages occasionally crashed routers as well as 256 improperly configured SAP sources accidently transmitted the 257 multicast stream they intended to announce on the SAP group, causing 258 harm to routers that cached this data. As such, routers should not 259 be configured to listen to the SAP group and cache SDP messages. 261 3. Summary of Reported Filtering Practices 262 3.1. Border and MSDP Filtering 264 In this section we summarise IPv4 multicast addresses that are 265 commonly filtered at site borders or on MSDP peerings. Based on 266 responses we received from a couple of multicast community lists, it 267 wasn't clear which filters are applied on border routers and which on 268 MSDP SA messages. Some sites apply minimal traffic filters, but 269 heavier MSDP filtering. 271 A site may choose to filter on addresses or on observed TTLs; it is 272 now general practice to filter on addresses rather than the TTL 273 filtering that was common a long time ago. 275 Some sites choose to route multicast around their unicast firewalls, 276 for performance or other operational reasons, but this shouldn't 277 alter the requirement to filter groups appropriately where necessary. 279 In this section we draw on the small number contributions so far; we 280 hope to get more inputs in time. In general, many 224.0.0.* 281 addresses that are used by infrastructure are typically blocked, as 282 well as some addresses that are global scope but should not be, like 283 Ghostcast. 285 The following list includes multicast IPv4 addresses that are being 286 filtered based on the union of responses received so far (hence the 287 apparent duplication of certain prefixes). The list of filters 288 applied by all respondents would be somewhat shorter. 290 224.0.1.1 NTP 291 224.0.1.2 SGI-Dogfight 292 224.0.1.3 Rwhod 293 224.0.1.8 SUN NIS+ 294 224.0.1.20 any private experiment 295 224.0.1.22 SVRLOC 296 224.0.1.24 microsoft-ds 297 224.0.1.25 nbc-pro 298 224.0.1.35 SVRLOC-DA 299 224.0.1.38 Retrospect 300 224.0.1.39 cisco-rp-announce 301 224.0.1.40 cisco-rp-discovery 302 224.0.1.41 gatekeeper 303 224.0.1.60 hp-device-disc 304 224.0.1.65 iapp 305 224.0.1.76 IAPP lucaent-avaya-ap 306 224.0.2.1 rwho 307 224.0.2.2 SUN RPC 308 224.0.2.3 EPSON-disc-set 309 224.0.23.1 Ricoh-device-ctrl 310 224.0.23.2 Ricoh-device-ctrl 311 224.1.0.1 Cisco Aironet 312 224.1.0.38 Retrospect 313 224.2.0.2 Altiris Rapideploy 314 224.2.0.3 Altiris Rapideploy 315 224.77.0.0/16 Norton Ghost 316 224.101.101.101 Sun Sunray 317 225.1.2.3 Altiris Development Server and Deployment Agent 318 226.77.0.0/16 Norton Ghost 319 229.55.150.208 Norton Ghost 320 231.0.0.0/8 ? 321 234.21.81.1 Limewire 322 234.42.42.0/30 ImageCast 323 234.42.42.32/31 ImageCast 324 234.42.42.40/30 ImageCast 325 234.142.142.42/31 ImageCast 326 234.142.142.44/30 ImageCast 327 234.142.142.48/28 ImageCast 328 234.142.142.64/26 ImageCast 329 234.142.142.128/29 ImageCast 330 234.142.142.136/30 ImageCast 331 234.142.142.140/31 ImageCast 332 234.142.142.142 ImageCast 333 239.0.0.0/8 Scoped groups 334 239.252.0.0/14 Scoped groups 335 239.234.5.6 ECopy ShareScan 337 One site gave figures for matches/hits on its filters; it may be 338 interesting to gather such statistics at other sites. 340 Different networks make different use of the scoped address space 341 under 239.0.0.0/8, which may lead to different organisational filters 342 in different scenarios. Organisation-local scope IPv4 multicast 343 addressing is described in [RFC2365]. 345 The SSM range 232.0.0.0/8 should not be carried in MSDP peerings; 346 this is an example of different policy applied at the site border to 347 an MSDP peering. Usually the filters are probably the same though. 349 As a general principle, multicast sourced from private address ranges 350 [RFC1918] or from 169.254.0.0/16, 192.0.2.0/24 or 127.0.0.0/8 should 351 be dropped, regardless of the multicast destination. 353 In certain cases, rate limiting may be desirable, where complete 354 filtering might not, e.g. in mitigating against SAP [RFC2974] storms, 355 or against unintended MSDP SA bursts. 357 Where BSR is deployed, a site should consider dropping BSR packets at 358 its border, both BSR messages and C-RP messages. Except for 359 Embedded-RP it probably makes sense to drop PIM register messages at 360 the site border, unless a site's RP is external. 362 3.2. Organisational filtering 364 As described in [RutgersProposal], a site may use multiple 365 organisational scopes within its site, which may use different blocks 366 from 239.0.0.0/8, and thus require appropriate filtering at 367 boundaries, e.g. between metropolitan campuses. 369 3.3. Subnet filtering 371 Two respondents are currently filtering uPNP between subnets, and one 372 is filtering mDNS. One reason for the uPNP filtering was due to 373 issues with errant Ricoh printers which flood announcements with too- 374 large TTLs. 376 Subnet filtering may help protect against other forms of 377 misconfigured client subnets. One site has networks that consist of 378 multiple edge routers, where the outside 'LAN side' is strictly meant 379 to be for local subnets only, and all intranet comms are to go 380 through the 'WAN interface'. They have had cases where multihomed 381 client networks were misconfigured, cross-connecting IP subnets with 382 layer 2 boxes. To prevent multiplication of multicasts, they 383 configure all edge routers in the intranet to accept multicast 384 packets from the 'LAN side' only if the source IP of the multicast 385 packets belongs to the IP subnet of that LAN. So it's a simple 386 filter, with no scaling issues. 388 At least one site is filtering multicast traffic from its wireless 389 links; this is presumably streamed video or audio content. Multicast 390 support is required on wireless links for IPv6 operation. At layer 391 2, multicast IPv6 Router Advertisements may be filtered on ports that 392 do not have known routers attached. 394 One site is running per-subnet boundary filters on its wired 395 multicast-enabled subnets. The list below reflects these. One could 396 add local scope relative addresses, though in practice the latter 397 would all fall under 239.255.0.0/16 if it is the smallest scope group 398 applied to a subnet. 400 224.0.1.1 NTP 401 224.0.1.2 SGI-Dogfight 402 224.0.1.3 Rwhod 403 224.0.1.8 SUN NIS+ 404 224.0.1.24 microsoft-ds 405 224.0.1.25 nbc-pro 406 224.0.1.60 hp-device-disc 407 224.0.1.76 IAPP 408 224.0.2.1 rwho 409 224.0.2.2 SUN RPC 410 234.21.81.1 Limewire 411 239.255.0.0/16 subnet scope 413 The importance of such subnet filtering may depend on TTLs used. 415 4. Conclusions 417 This document discusses filters and related mechanisms that should be 418 applied in multicast deployments, and summarises the reported use of 419 such multicast filtering practices in the wild. It includes 420 discussion of various multicast protocols and of reported practices 421 of applying filters at various scope boundaries. The next iteation 422 of this draft will include more detailed conclusions. 424 Further feedback on the text, and the practices reported to date is 425 welcomed. 427 5. Security Considerations 429 There are no extra security consideration for this document. 431 6. IANA Considerations 433 There are no extra IANA consideration for this document. 435 7. Acknowledgments 437 The author would like to thank the following people for their 438 contributions to this text: Scott Bertilson, Alan Buxey, Bruce 439 Curtis, Andy Gatward, Bob Gerdes, Jeffry J. Handal, Lonnie Leger, 440 Bert Manfredi, Garry Peirce, William F. Maton Sotomayor, and Stig 441 Venaas. 443 8. Informative References 445 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 446 E. Lear, "Address Allocation for Private Internets", 447 BCP 5, RFC 1918, February 1996. 449 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 450 RFC 2365, July 1998. 452 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 453 Announcement Protocol", RFC 2974, October 2000. 455 [RFC6034] Thaler, D., "Unicast-Prefix-Based IPv4 Multicast 456 Addresses", RFC 6034, October 2010. 458 [JANETmulticast] 459 Price, D., "IPv4 Multicast on JANET", 2006, . 463 [IANA6multicast] 464 "IPv6 Multicast Address Space Registry", . 468 [IANAmulticast] 469 "IPv4 Multicast Address Space Registry", . 473 [RutgersProposal] 474 "iDRAFT Proposal for RUNet Administratively Scoped 475 Multicast", . 478 [I2multicast] 479 "Enabling IP Multicast with Internet2", . 482 Authors' Addresses 484 Tim Chown 485 University of Southampton 486 Highfield 487 Southampton, Hampshire SO17 1BJ 488 United Kingdom 490 Email: tjc@ecs.soton.ac.uk 492 Leonard Giuliano 493 Juniper Networks 495 Email: lenny@juniper.net