idnits 2.17.1 draft-savola-mboned-mroutesec-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (Jan 22, 2004) is 7371 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-v2-new-08 ** Downref: Normative reference to an Experimental RFC: RFC 3618 (ref. '2') == Outdated reference: A later version (-07) exists of draft-ietf-ssm-arch-04 == Outdated reference: A later version (-07) exists of draft-ietf-mboned-embeddedrp-00 == Outdated reference: A later version (-07) exists of draft-ietf-rpsec-routing-threats-04 ** Downref: Normative reference to an Informational draft: draft-ietf-rpsec-routing-threats (ref. '5') Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force P. Savola 2 Internet-Draft CSC/FUNET 3 Expires: July 22, 2004 R. Lehtonen 4 TeliaSonera 5 D. Meyer 6 Jan 22, 2004 8 PIM-SM Multicast Routing Security Issues and Enhancements 9 draft-savola-mboned-mroutesec-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on July 22, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This memo describes security threats for the larger (intra-domain, or 40 inter-domain) multicast routing infrastructures. Only Protocol 41 Independent Multicast - Sparse Mode (PIM-SM) is analyzed, in its 42 three main operational modes: the traditional Any Source Multicast 43 (ASM) model, Source-Specific Multicast (SSM) model, and the ASM model 44 enhanced by the Embedded RP group-to-RP mapping mechanism. This memo 45 also describes enhancements to the protocol operations to mitigate 46 these threats. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Threats to Multicast Routing . . . . . . . . . . . . . . . . 4 53 3.1 Receiver-based Attacks . . . . . . . . . . . . . . . . . . . 4 54 3.1.1 Joins to Different Groups . . . . . . . . . . . . . . . . . 5 55 3.2 Source-based Attacks . . . . . . . . . . . . . . . . . . . . 6 56 3.2.1 Sending Multicast to Empty Groups . . . . . . . . . . . . . 6 57 3.2.2 Disturbing Existing Group by Sending to It . . . . . . . . . 7 58 3.3 Aggravating Factors to the Threats . . . . . . . . . . . . . 8 59 3.3.1 Distant RP/Source Problem . . . . . . . . . . . . . . . . . 8 60 3.3.2 RPF Considers Interface, Not Neighbor . . . . . . . . . . . 8 61 3.3.3 No Receiver Information in PIM Joins . . . . . . . . . . . . 9 62 3.3.4 Injecting a Bogus Route . . . . . . . . . . . . . . . . . . 9 63 4. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . 9 64 4.1 Summary of the Threats . . . . . . . . . . . . . . . . . . . 9 65 4.2 Enhancements for Threat Mitigation . . . . . . . . . . . . . 10 66 5. PIM Security Enhancements . . . . . . . . . . . . . . . . . 11 67 5.1 Remote Routability Signalling . . . . . . . . . . . . . . . 11 68 5.2 RPF to Check Neighbor, not Interface . . . . . . . . . . . . 12 69 5.3 Rate-limiting Possibilities . . . . . . . . . . . . . . . . 12 70 6. Security Considerations . . . . . . . . . . . . . . . . . . 13 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13 72 Normative References . . . . . . . . . . . . . . . . . . . . 13 73 Informative References . . . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 75 Intellectual Property and Copyright Statements . . . . . . . 16 77 1. Introduction 79 This memo describes security threats to the Protocol Independent 80 Multicast - Sparse Mode (PIM-SM) multicast routing infrastructures, 81 and suggests ways to make these architectures more resistant to the 82 described threats. 84 Only attacks which have an effect on the multicast routing (whether 85 intra- or inter-domain) are considered. For example, attacks where 86 the hosts are specifically targeting the Designated Router (DR) or 87 other routers of the link, or where hosts are disrupting other hosts 88 on the same link are out of scope. Similarly, ensuring 89 confidentiality, authentication and integrity of multicast groups and 90 traffic is out of the scope [9]. 92 PIM builds on a model where Reverse Path Forwarding (RPF) check is 93 (among other things) used to ensure loop-free properties of the 94 multicast distribution trees. As a side effect, this limits the 95 effect of using forged source addresses, which is often as a 96 component in unicast-based attacks. However, a host can still spoof 97 an address within the same subnet, or spoof the source of a 98 unicast-encapsulated PIM Register messages, which a host may send on 99 its own. 101 We consider PIM-SM [1] operating in the traditional Any Souce 102 Multicast (ASM) model (including the use of Multicast Source 103 Discovery Protocol (MSDP) [2] for source discovery), in 104 Source-Specific Multicast [3] (SSM) model, and the Embedded-RP [4] 105 group-to-RP mapping mechanism in ASM model. If Bidirectional-PIM 106 enhancements are globally significant, and have implications, they 107 could also be considered. 109 2. Terminology 111 ASM 113 Term "ASM" [6] is used to refer to the traditional Any Source 114 Multicast model with multiple PIM domains and a signalling 115 mechanism (MSDP) to exchange information about active sources 116 between them. 118 SSM 120 Term "SSM" [7] is used to refer to Source-Specific Multicast. 122 Embedded-RP 124 Embedded-RP refers to ASM model where the Embedded-RP mapping 125 mechanism is used to find the RP for a group, and MSDP is not 126 needed. 128 Target Router 130 Target Router is used to refer to either the RP processing a 131 packet (ASM or Embedded-RP), or DR close to the transmitting 132 source (SSM). 134 3. Threats to Multicast Routing 136 We make the broad assumption that the multicast routing networks are 137 reasonably trusted. That is, we assume that the multicast routers 138 themselves behave "well", in the same sense that unicast routers are 139 expected to behave well, and are not a significant source of abuse. 140 This assumption is not entirely correct, but it simplifies the 141 analysis of threat models. If seen important, the threats caused by 142 misbehaving multicast routers (including fake multicast routers) may 143 be considered separately. 145 As the threats described in this memo are mainly Denial of Service 146 (DoS) attacks, it may be useful to note that the attackers will try 147 to find a scarce resource anywhere in the control or data plane, as 148 described in [5]. 150 3.1 Receiver-based Attacks 152 These attacks are often referred to as control plane threats and the 153 aim of the attacker is usually to increase the amount of multicast 154 state information in routers above a manageable level. 156 One should note that hosts can also originate PIM messages (e.g. PIM 157 Joins) as long as their source address passes the RPF checks. This 158 implies that a willful attacker will be able to circumvent many of 159 the potential rate-limiting functions performed at the DR -- as one 160 can always send the messages yourself. The PIM-SM specification, 161 however, states that these messages should only be accepted from 162 known PIM neighbors [1]; if these would be implemented, the hosts 163 would have to forge PIM Hello messages as well. 165 One should also note that even if a host joins to a group multiple 166 times, the DR only sends one PIM Join message, without waiting for 167 any acknowledgement; the next message is only sent after the timer 168 expires or the state changes at the DR. 170 Also, if the host uses IGMPv3 [10] or MLDv2 [11], it is able to join 171 multiple sources for the same group and each of these joins for the 172 same group generates new PIM (Source, Group), or (S,G) Joins. 174 3.1.1 Joins to Different Groups 176 Description of the threat: Join Flooding. This happens when a host 177 tries to join, once or a couple of times, to a group or a channel, 178 and the DR generates a PIM Join towards the Target Router. The group/ 179 channel or the Targer Router may or may not exist. 181 Example of this is a host trying to join different, non-existent 182 groups at a very rapid pace, trying to overload the routers on the 183 path with an excessive amount of (*/S,G) state (also refered to as 184 "PIM State"), or the Target Router with an excessive number of 185 packets. 187 This kind of joining causes PIM state to be created, but this state 188 is relatively short-lived (260 seconds by default, which is the 189 default time that the state is active at DR in the absence of IGMP/ 190 MLD Reports/Leaves). It should also be noted that the host can join a 191 number of different channels with only one IGMPv3/MLDv2 Report as the 192 protocol allows to include multiple sources in the same message. 193 However, even short-lived state may be harmful, if the intent is to 194 cause as much state as possible. The host can continue to send IGMP/ 195 MLD Reports to these groups to make the state attack more long-lived. 196 This results in: 198 o ASM: a (*,G) join is sent towards an intra-domain RP, causing 199 state on that path; in turn, that RP joins to the DR of the source 200 (if it exists). If the source address was specified by the host in 201 the IGMPv3/MLDv2 Report, a (S,G) Join is sent directly towards the 202 specified source. 204 o SSM: a (S,G) join is sent inter-domain to the DR of the source S, 205 causing state on that path. If the source does not exist, the 206 join goes to the closest router to S as possible. 208 o Embedded RP: a (*,G) join is sent towards an inter/intra-domain RP 209 embedded in the group G, causing state on that path. If the RP 210 does not exist, the join goes to the closest router to the RP as 211 possible. 213 If the source or RP does not exist, the multicast routing protocol 214 does not have any means to remove the distribution tree if the host 215 remains active. Worst case attack could be a host remaining active to 216 many different groups (containing either imaginary source or RP). 218 3.2 Source-based Attacks 220 These attacks are often referred to as "data plane" threats; however, 221 with traditional ASM and MSDP, these also include an MSDP control 222 plane threat. 224 3.2.1 Sending Multicast to Empty Groups 226 Description of the threat: Data Flooding. This happens when a host 227 sends data packets to a multicast group or channel for which there 228 are no real subscribers. 230 Note that as unicast-encapsulation is not subject to RPF checks, the 231 hosts can also craft and send these packets themselves, also spoofing 232 the source address of the register messages unless ingress filtering 233 [12] has been deployed [13]. 235 Examples of this are a virus/worm trying to propagate to multicast 236 addresses, an attacker trying to crash routers with excessive MSDP 237 state, or an attacker wishing to overload the RP with encapsulated 238 packets or different groups. This results in: 240 o ASM: the DR unicast-encapsulates the packets in Register messages 241 to the intra-domain RP, which may join to the source and issue a 242 Register-Stop, but continues to get the data. A notification 243 about the active source is sent (unless the group or source is 244 configured to be local) inter-domain with MSDP and propagated 245 globally. 247 o SSM: the DR receives the data, but the data does not propagate 248 from the DR unless someone joins the (S,G) channel. 250 o Embedded RP: the DR register-encapsulates the packets to the 251 intra/inter-domain RP, which may join to the source and issue a 252 Register-Stop. The data continues to be encapsulated. 254 This yields many potential attacks, especially if at least parts of 255 the multicast forwarding functions are implemented on a "slow" path 256 or with software in the routers, at least: 258 o The MSDP control plane traffic generated can cause a significant 259 amount of messages/data which may overload the routers receiving 260 it. The thorough analysis of MSDP vulnerabilities can be found 261 from [14]. This is only related to the ASM. However, this is the 262 most serious threat at the moment, because MSDP will flood the 263 multicast group information to all multicast domains in Internet 264 including the multicast packet encapsulated to MSDP source-active 265 message. This creates a lot of data and state to be shared by all 266 multicast enabled routers and if the source remains active, the 267 flooding will be repeated every 60 seconds by default. 269 o As a large amount of data is forwarded on the multicast tree; if 270 multicast forwarding is performed on software, it may be a 271 performance bottleneck, and a way to perform DoS on the path. 272 Similarly, the DR must always be capable of processing (and 273 discarding, if necessary) the multicast packets received from the 274 source. These are potentially present in every model. 276 o If the encapsulation is performed on software, it may be a 277 performance bottleneck, and a way to perform DoS on the DR. 278 Similarly, if the decapsulation is performed on software, it may 279 be a performance bottleneck, and a way to perform DoS on the RP. 280 Note: the decapsulator may know, based on access configuration, a 281 rate-limit or something else, that it doesn't need to decapsulate 282 the packet, avoiding bottlenecks. These threats are related to 283 ASM and Embedded RP. 285 3.2.2 Disturbing Existing Group by Sending to It 287 Description of the threat: Group Integrity Violation. This happens 288 when a host sends packets to a group or channel, which already 289 exists, to disturb the users of the existing group/channel. 291 The SSM service model prevents injection of packets to (S,G) 292 channels, avoiding this problem. However, if the source address can 293 be spoofed to be a topologically-correct address, it's possible to 294 get the packet into the distribution tree -- typically only those 295 hosts which are on-link with the source are able to perform this, so 296 this is not really relevant in the scope of this memo. 298 With ASM and Embedded RP sources can inject bogus traffic through 299 RPs, which provide the source discovery for the group. The RP(s) send 300 the traffic over the shared tree towards receivers (routers with 301 (*,G) state). DR then forwards the bogus traffic to receivers unless 302 the legitimate recipients are able to filter out unwanted sources, 303 e.g., using MSF API [8]. Typically this is not used or supported by 304 the applications using these protocols. 306 Note that with ASM and Embedded RP, the RP may exert some form of 307 control on who can send to a group, as the first packets are 308 unicast-encapsulated in register packets to the RP -- if the RP drops 309 the packet based on access-list, rate-limiter or something else, it 310 doesn't get injected to an existing group. 312 With ASM this "source control" is distributed across all the PIM 313 domains, which decreases it's applicability. Embedded RP enables 314 easier control, because source discovery is done through single RP 315 per group. 317 So, for this attack to succeed, the RP must decapsulate the packets, 318 and join to the source. 320 3.3 Aggravating Factors to the Threats 322 This section describes a few factors, which aggravate the threats 323 described in sections Section 3.1 and Section 3.2. These could also 324 be viewed as individual threats on their own. 326 There are multiple threats relating to the use of host-to-router 327 signalling protocols -- such as Internet Group Management Protocol 328 (IGMP) or Multicast Listener Discovery (MLD) -- but these are outside 329 the scope of this memo. 331 PIM-SM can also be abused in the cases where RPF checks are not 332 applicable, in particular, in the stub LAN networks -- as spoofing 333 the on-link traffic is very simple. For example, a host would get 334 elected to become DR for the subnet, but not perform any of its 335 functions. These are described at some length in [1], but are also 336 considered out of scope of this memo. 338 3.3.1 Distant RP/Source Problem 340 In the shared tree model, if the RP or a source is distant 341 (topologically), then joins will travel to the distant RP or source 342 and keep the state information in the path active, even if the data 343 is being delivered locally. 345 Note that this problem will be exacerbated if the RP/source space is 346 global; if a router is registering to a RP/source that is not in the 347 local domain (say, fielded by the site's direct provider), then the 348 routing domain is flat. 350 Also note that PIM assumes that the addresses used in PIM messages 351 are valid. However, there is no way to ensure this, and using 352 non-existent S or G in (*,G) or (S,G) -messages will cause the 353 signalling to be set up, even though one cannot reach the address. 355 This will be analysed at more length in Section 5.1. 357 3.3.2 RPF Considers Interface, Not Neighbor 359 In most current implementations, the RPF check considers only the 360 incoming interface, and not the upstream neighbor (RPF neighbor). 362 This can result in accepting packets from the "wrong" RPF neighbor 363 (the neighbor is "wrong" since, while the RPF check succeeds and the 364 packet is forwarded, the unicast policy would not have forwarded the 365 packet). 367 This is a problem in the media where more than two routers can 368 connect to, in particular, Ethernet-based Internet Exchanges. 369 Therefore any neighbor on such a link could inject any PIM signalling 370 as long as a route matching the address used in the signalling is 371 going through the interface. 373 3.3.3 No Receiver Information in PIM Joins 375 Only DRs, which are directly connected to receivers, know the exact 376 receiver information (e.g. IP address). PIM does not forward that 377 information further in the multicast distribution tree. Therefore 378 individual routers (e.g. domain edge routers) are not able to make 379 policy decisions on who can be connected to the distribution tree. 381 3.3.4 Injecting a Bogus Route 383 Hosts that able to inject a bogus route can be used to "steal" PIM 384 Joins. This prevents the correct multicast tree forming. If the 385 injected route information changes, it causes route flapping and that 386 could have harmful effect on multicast routing and packet delivery 387 (depending on the group). The threat is similar to unicast case 388 meaning that by injecting a bogus route, routing does not work 389 correctly. 391 4. Threat Analysis 393 4.1 Summary of the Threats 395 Trying to summarize the severity of the major classes of threats with 396 respect to each multicast usage model, we have a matrix of resistance 397 to different kinds of threats: 399 +----------------+------------------+-----------------+ 400 | Bogus Join | Being a Source | Group Integrity | 401 +-------------+----------------+------------------+-----------------+ 402 | ASM | bad 1) | very bad | bad/mediocre | 403 +-------------+----------------+------------------+-----------------+ 404 | SSM | bad | very good | very good | 405 +-------------+----------------+------------------+-----------------+ 406 | Embedded RP |bad/mediocre 2) | good/mediocre 3) | good | 407 +-------------+----------------+------------------+-----------------+ 409 Notes: 411 1) in ASM host can directly join also (S,G) groups with IGMPv3/MLDv2 412 and thus have same characteristics as SSM (also allows inter-domain 413 shared state to be created). 415 2) allows inter-domain shared state to be created. 417 3) register messages can be sent to long-distance RPs with spoofed 418 source addresses and this could create unnecessary joins towards DRs 419 (from spoofed source address space). 421 4.2 Enhancements for Threat Mitigation 423 There are several desirable actions ("requirements") which could be 424 considered to mitigate these threats; these are listed below. A 425 future revision of this memo will describe the best methods and 426 parameters at more detail. 428 o Inter-domain MSDP (ASM) should be retired (or not introduced) to 429 avoid attacks; or, if this is not reasonable, the DRs should 430 rate-limit the unicast-encapsulation (note that the hosts can 431 avoid this) and (more importantly) the RPs should rate-limit the 432 unicast-decapsulation especially from different sources, or MSDP 433 must rate-limit the MSDP data generation for new sources. 435 o DRs should rate-limit PIM Joins and Prunes somehow; there are 436 multiple possibilities how exactly this should be considered 437 (i.e., which variables to take into the consideration). 439 o DRs could rate-limit unicast-encapsulation somehow; there are 440 multiple ways to perform this. Note that the hosts can avoid this 441 by performing the unicast-encapsulation themselves if so inclined. 443 o RPs could rate-limit unicast-decapsulation somehow; there are 444 multiple ways to perform this. Note that if the source of the 445 unicast packets is spoofed by the host, this may have an effect on 446 how e.g. rate-limiters behave. 448 o RPs should rate limit the MSDP SA messages coming from MSDP peers. 450 o RPs could limit or even disable the SA cache size. However, this 451 could have negative effects on normal operation. 453 o RPs should provide good interfaces to reject packets which are not 454 interesting; for example, if an Embedded RP group is not 455 configured to be allowed in the RP, the unicast-encapsulated 456 packets would not even be decapsulated. 458 o DRs could rate-limit the multicast traffic somehow to reduce the 459 disturbing possibilities; there are multiple possibilities how 460 exactly this should be considered. 462 o DRs should rate-limit the number of groups that can be created by 463 a given source, S. 465 5. PIM Security Enhancements 467 This section includes in-depth description of the above-mentioned 468 rate-limiting etc. functions as well as description of the remote 469 routability signalling issue. 471 5.1 Remote Routability Signalling 473 As described in section Section 3.3.1, non-existent DRs or RPs may 474 cause some problems when setting up multicast state. There seem to 475 be a couple of different approaches to mitigate this, especially if 476 rate-limiting is not extensively deployed. 478 With ASM and Embedded RP, Register message delivery could be ensured 479 somehow. For example: 481 1) At the very least, receiving an ICMP unreachable message (of 482 any flavor) should cause the DR to stop the Register packets -- as 483 the RP will not be receiving them anyway. 485 2) An additional method could be implementing a timer on the RPs 486 so that unless nothing is heard back from the RP within a defined 487 time period, the flow of Register messages would stop. (Currently, 488 the RPs are not required to answer back, unless they want to join 489 to the source.) 491 3) An extreme case would be performing some form of return 492 routability check prior to starting the register messages: first a 493 packet would be sent to the RP, testing its existence and 494 willingness to serve, and also proving to the RP that the sender 495 of the "bubble" and the sender of the registers are the same and 496 the source address is not forged (i.e., the RP would insert a 497 cookie in the bubble, and it would have to be present in the 498 register message.) 500 With all the models, PIM Joins and other state management messages 501 could also be somehow managed. For example: 503 1) At the very least, receiving an ICMP unreachable message (of 504 any flavor) should cause the DR to stop the PIM messages toward 505 the destination, as the packets will not be received anyway. 507 (Currently the sending of an ICMP error message in response to a 508 multicast packet, even though in this case the PIM message to only 509 received by one router, is prohibited.) 511 2) A possible method would be limiting the number of PIM messages 512 sent towards a destination until some response (e.g. other PIM 513 state messages). 515 5.2 RPF to Check Neighbor, not Interface 517 As described in Section 3.3.2, especially Ethernet-based Internet 518 Exchange Points (IXP) are susceptible to signalling attacks from any 519 member of the IXP, as the RPF considers the Interface, not a 520 Neighbor. 522 Consequently, PIM must be modified so that on non- point-to-point 523 links, the RPF must also consider whether the neighbor is correct. 524 Note that in case of IPv6, this requires (an already necessary) a 525 mapping between link-local and global addresses. 527 5.3 Rate-limiting Possibilities 529 There seem to be many ways to implement rate-limiting (for 530 signalling, data encapsulation and multicast traffic) at the DRs or 531 RPs -- the best approach likely depends on the threat model; factors 532 in the evaluation might be e.g.: 534 o Whether the host is willfully malicious, uncontrolled (e.g., 535 virus/worm), or a regular user just doing something wrong. 537 o Whether the threat is aimed towards a single group, a single RP 538 handling the group, or the (multicast) routing infrastructure in 539 general. 541 o Whether the host on a subnet is spoofing its address (but still as 542 one which fulfills the RPF checks of the DR) or not. 544 o Whether the host may generate the PIM join (and similar) messages 545 itself to avoid rate-limiters at the DR if possible. 547 o Whether unicast RPF checks are applied on the link (i.e., whether 548 the host can send unicast-encapsulated register-messages on its 549 own). 551 o Whether blocking the misbehaving host on a subnet is allowed to 552 also block other, legitimate hosts on the same subnet. 554 o Whether these mechanisms would cause false positives on links with 555 only properly working hosts if many of them are receivers or 556 senders. 558 As should be obvious, there are many different scenarios here which 559 seem to call for different kinds of solutions. 561 For example, the rate-limiting could be performed based on: 563 1. multicast address, or the RP where the multicast address maps to 565 2. source address 567 3. the (source address, multicast address) -pair (or the RP which 568 maps to the multicast address) 570 4. data rate in case of rate limiting the source 572 5. everything (multicast groups and sources would not be 573 distinguished at all) 575 In the above, we make an assumption that rate-limiting would be 576 performed per-interface (on DRs) if a more fine-grained filter is not 577 being used. 579 It should be noted that some of the rate limiting functions can be 580 used as a tool for DoS against legimate multicast users. Therefore 581 several parameters for rate limiting should be used to prevent such 582 operation. 584 The next revisions of this document (or separated in other documents, 585 if appropriate) will include more explicit discussion of the best 586 ways to perform rate-limiting, especially considering the effects on 587 the legimate traffic. 589 6. Security Considerations 591 This memo analyzes the security of PIM routing infrastructures in 592 some detail, and proposes enhancements to mitigate the observed 593 threats. 595 7. IANA Considerations 597 This memo is for informational purposes and does not introduce new 598 namespaces for the IANA to manage. 600 Normative References 602 [1] Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, "Protocol 603 Independent Multicast - Sparse Mode PIM-SM): Protocol 604 Specification (Revised)", draft-ietf-pim-sm-v2-new-08 (work in 605 progress), October 2003. 607 [2] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol 608 (MSDP)", RFC 3618, October 2003. 610 [3] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", 611 draft-ietf-ssm-arch-04 (work in progress), October 2003. 613 [4] Savola, P. and B. Haberman, "Embedding the Address of RP in IPv6 614 Multicast Address", draft-ietf-mboned-embeddedrp-00 (work in 615 progress), October 2003. 617 [5] Barbir, A., Murphy, S. and Y. Yang, "Generic Threats to Routing 618 Protocols", draft-ietf-rpsec-routing-threats-04 (work in 619 progress), December 2003. 621 Informative References 623 [6] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 624 1112, August 1989. 626 [7] Bhattacharyya, S., "An Overview of Source-Specific Multicast 627 (SSM)", RFC 3569, July 2003. 629 [8] Thaler, D., Fenner, B. and B. Quinn, "Socket Interface 630 Extensions for Multicast Source Filters", 631 draft-ietf-magma-msf-api-05 (work in progress), July 2003. 633 [9] Hardjono, T. and B. Weis, "The Multicast Security 634 Architecture", draft-ietf-msec-arch-05 (work in progress), 635 January 2004. 637 [10] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. 638 Thyagarajan, "Internet Group Management Protocol, Version 3", 639 RFC 3376, October 2002. 641 [11] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 642 (MLDv2) for IPv6", draft-vida-mld-v2-08 (work in progress), 643 December 2003. 645 [12] Ferguson, P. and D. Senie, "Network Ingress Filtering: 646 Defeating Denial of Service Attacks which employ IP Source 647 Address Spoofing", BCP 38, RFC 2827, May 2000. 649 [13] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 650 Networks", draft-savola-bcp38-multihoming-update-03 (work in 651 progress), December 2003. 653 [14] Rajvaidya, P., Ramachandran, K. and K. Almeroth, "Detection and 654 Deflection of DoS Attacks Against the Multicast Source 655 Discovery Protocol", IEEE Infocom 2003. 657 Authors' Addresses 659 Pekka Savola 660 CSC/FUNET 662 Espoo 663 Finland 665 EMail: psavola@funet.fi 667 Rami Lehtonen 668 TeliaSonera 669 Hataanpaan valtatie 20 670 Tampere 33100 671 Finland 673 EMail: rami.lehtonen@teliasonera.com 675 David Meyer 677 EMail: dmm@1-4-5.net 679 Intellectual Property Statement 681 The IETF takes no position regarding the validity or scope of any 682 intellectual property or other rights that might be claimed to 683 pertain to the implementation or use of the technology described in 684 this document or the extent to which any license under such rights 685 might or might not be available; neither does it represent that it 686 has made any effort to identify any such rights. Information on the 687 IETF's procedures with respect to rights in standards-track and 688 standards-related documentation can be found in BCP-11. Copies of 689 claims of rights made available for publication and any assurances of 690 licenses to be made available, or the result of an attempt made to 691 obtain a general license or permission for the use of such 692 proprietary rights by implementors or users of this specification can 693 be obtained from the IETF Secretariat. 695 The IETF invites any interested party to bring to its attention any 696 copyrights, patents or patent applications, or other proprietary 697 rights which may cover technology that may be required to practice 698 this standard. Please address the information to the IETF Executive 699 Director. 701 Full Copyright Statement 703 Copyright (C) The Internet Society (2004). All Rights Reserved. 705 This document and translations of it may be copied and furnished to 706 others, and derivative works that comment on or otherwise explain it 707 or assist in its implementation may be prepared, copied, published 708 and distributed, in whole or in part, without restriction of any 709 kind, provided that the above copyright notice and this paragraph are 710 included on all such copies and derivative works. However, this 711 document itself may not be modified in any way, such as by removing 712 the copyright notice or references to the Internet Society or other 713 Internet organizations, except as needed for the purpose of 714 developing Internet standards in which case the procedures for 715 copyrights defined in the Internet Standards process must be 716 followed, or as required to translate it into languages other than 717 English. 719 The limited permissions granted above are perpetual and will not be 720 revoked by the Internet Society or its successors or assignees. 722 This document and the information contained herein is provided on an 723 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 724 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 725 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 726 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 727 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 729 Acknowledgment 731 Funding for the RFC Editor function is currently provided by the 732 Internet Society.