idnits 2.17.1 draft-ietf-mboned-mroutesec-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 916. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 900. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 906. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 922), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 (Apr 16, 2004) is 7315 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-09 ** 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-02 == Outdated reference: A later version (-07) exists of draft-ietf-rpsec-routing-threats-06 ** Downref: Normative reference to an Informational draft: draft-ietf-rpsec-routing-threats (ref. '5') Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Savola 3 Internet-Draft CSC/FUNET 4 Expires: October 15, 2004 R. Lehtonen 5 TeliaSonera 6 D. Meyer 7 Apr 16, 2004 9 PIM-SM Multicast Routing Security Issues and Enhancements 10 draft-ietf-mboned-mroutesec-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 15, 2004. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 This memo describes security threats for the larger (intra-domain, or 43 inter-domain) multicast routing infrastructures. Only Protocol 44 Independent Multicast - Sparse Mode (PIM-SM) is analyzed, in its 45 three main operational modes: the traditional Any Source Multicast 46 (ASM) model, Source-Specific Multicast (SSM) model, and the ASM model 47 enhanced by the Embedded-RP group-to-RP mapping mechanism. This memo 48 also describes enhancements to the protocol operations to mitigate 49 the identified threats. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Threats to Multicast Routing . . . . . . . . . . . . . . . . . 4 56 3.1 Receiver-based Attacks . . . . . . . . . . . . . . . . . . 4 57 3.1.1 Joins to Different Groups . . . . . . . . . . . . . . 5 58 3.2 Source-based Attacks . . . . . . . . . . . . . . . . . . . 6 59 3.2.1 Sending Multicast to Empty Groups . . . . . . . . . . 6 60 3.2.2 Disturbing Existing Group by Sending to It . . . . . . 7 61 3.3 Aggravating Factors to the Threats . . . . . . . . . . . . 8 62 3.3.1 Distant RP/Source Problem . . . . . . . . . . . . . . 9 63 3.3.2 No Receiver Information in PIM Joins . . . . . . . . . 9 64 4. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 9 65 4.1 Summary of the Threats . . . . . . . . . . . . . . . . . . 9 66 4.2 Enhancements for Threat Mitigation . . . . . . . . . . . . 10 67 5. PIM Security Enhancements . . . . . . . . . . . . . . . . . . 11 68 5.1 Remote Routability Signalling . . . . . . . . . . . . . . 11 69 5.2 Rate-limiting Possibilities . . . . . . . . . . . . . . . 12 70 5.3 Specific Rate-limiting Suggestions . . . . . . . . . . . . 13 71 5.3.1 Group Management Protocol Rate-limiter . . . . . . . . 13 72 5.3.2 Source Transmission Rate-limiter . . . . . . . . . . . 14 73 5.3.3 PIM Signalling Rate-limiter . . . . . . . . . . . . . 14 74 5.3.4 Unicast-decapsulation Rate-limiter . . . . . . . . . . 14 75 5.3.5 MSDP Source-Active Rate-limiter . . . . . . . . . . . 15 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 15 81 9.2 Informative References . . . . . . . . . . . . . . . . . . . 16 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 83 A. RPF Considers Interface, Not Neighbor . . . . . . . . . . . . 17 84 B. Return Routability Extensions . . . . . . . . . . . . . . . . 18 85 B.1 Sending PIM-Prune Messages Down the Tree . . . . . . . . . 18 86 B.2 Analysing Multicast Group Traffic at DR . . . . . . . . . 19 87 B.3 Comparison of the Above Approaches . . . . . . . . . . . . 19 88 Intellectual Property and Copyright Statements . . . . . . . . 20 90 1. Introduction 92 This memo describes security threats to the Protocol Independent 93 Multicast - Sparse Mode (PIM-SM) multicast routing infrastructures, 94 and suggests ways to make these architectures more resistant to the 95 described threats. 97 Only attacks which have an effect on the multicast routing (whether 98 intra- or inter-domain) are considered. For example, attacks where 99 the hosts are specifically targeting the Designated Router (DR) or 100 other routers on the link, or where hosts are disrupting other hosts 101 on the same link are out of scope. Similarly, ensuring 102 confidentiality, authentication and integrity of multicast groups and 103 traffic is out of the scope [9]. 105 PIM builds on a model where Reverse Path Forwarding (RPF) check is 106 (among other things) used to ensure loop-free properties of the 107 multicast distribution trees. As a side effect, this limits the 108 effect of using forged source addresses, which is often used as a 109 component in unicast-based attacks. However, a host can still spoof 110 an address within the same subnet, or spoof the source of a 111 unicast-encapsulated PIM Register messages, which a host may send on 112 its own. 114 We consider PIM-SM [1] operating in the traditional Any Souce 115 Multicast (ASM) model (including the use of Multicast Source 116 Discovery Protocol (MSDP) [2] for source discovery), in 117 Source-Specific Multicast [3] (SSM) model, and the Embedded-RP [4] 118 group-to-RP mapping mechanism in ASM model. If the Bidirectional-PIM 119 enhancements are globally significant, and have implications, they 120 could also be considered, but are out of scope for now. 122 2. Terminology 124 ASM 126 "ASM" [6] is used to refer to the traditional Any Source 127 Multicast model with multiple PIM domains and a signalling 128 mechanism (MSDP) to exchange information about active sources 129 between them. 131 SSM 133 "SSM" [7] is used to refer to Source-Specific Multicast. 135 SSM channel 137 SSM channel (S, G) identifies the multicast delivery tree 138 associated with a source address S and a SSM destination 139 address G. 141 Embedded-RP 143 "Embedded-RP" refers to the ASM model where the Embedded-RP 144 mapping mechanism is used to find the RP for a group, and MSDP 145 is not used. 147 Target Router 149 "Target Router" is used to refer to either the RP processing a 150 packet (ASM or Embedded-RP), or the DR that is receiving 151 (Source, Group) (or (S,G)) joins, (in all models). 153 3. Threats to Multicast Routing 155 We make the broad assumption that the multicast routing networks are 156 reasonably trusted. That is, we assume that the multicast routers 157 themselves are well-behaved, in the same sense that unicast routers 158 are expected to behave well, and are not a significant source of 159 abuse. While this assumption is not entirely correct, it simplifies 160 the analysis of threat models. The threats caused by misbehaving 161 multicast routers (including fake multicast routers) are not 162 considered in this memo. In general, the threat model would then be 163 similar to [5]. 165 As the threats described in this memo are mainly Denial of Service 166 (DoS) attacks, it may be useful to note that the attackers will try 167 to find a scarce resource anywhere in the control or data plane, as 168 described in [5]. 170 3.1 Receiver-based Attacks 172 These attacks are often referred to as control plane attacks and the 173 aim of the attacker is usually to increase the amount of multicast 174 state information in routers above a manageable level. 176 One should note that hosts can also originate PIM messages (e.g. PIM 177 Joins) as long as their source address passes the RPF checks. This 178 implies that a willful attacker will be able to circumvent many of 179 the potential rate-limiting functions performed at the DR (as one can 180 always send the messages yourself). The PIM-SM specification, 181 however, states that these messages should only be accepted from 182 known PIM neighbors [1]; if this is performed, the hosts would first 183 have to establish a PIM adjacency with the router. Typically, 184 adjacencies are formed with anyone on the link, so a willful attacker 185 would have a high probability of success in forming a protocol 186 adjacency. 188 One should also note that even if a host joins to a group multiple 189 times, the DR only sends one PIM Join message, without waiting for 190 any acknowledgement; the next message is only sent after the timer 191 expires or the state changes at the DR. 193 Also, if the host uses IGMPv3 [10] or MLDv2 [11], it is able to join 194 multiple sources for the same group and each of these joins for the 195 same group generates new PIM (S,G) Joins to the DR adjacent to the 196 source. 198 3.1.1 Joins to Different Groups 200 Description of the threat: Join Flooding. Join Flooding occurs when a 201 host tries to join, once or a couple of times, to a group or a SSM 202 channel, and the DR generates a PIM Join to the Target Router. The 203 group/SSM channel or the Targer Router may or may not exist. 205 Example of this is a host trying to join different, non-existent 206 groups at a very rapid pace, trying to overload the routers on the 207 path with an excessive amount of (*/S,G) state (also referred to as 208 "PIM State"), or the Target Router with an excessive number of 209 packets. 211 This kind of joining causes PIM state to be created, but this state 212 is relatively short-lived (260 seconds by default, which is the 213 default time that the state is active at DR in the absence of IGMP/ 214 MLD Reports/Leaves). It should also be noted that the host can join a 215 number of different SSM channels with only one IGMPv3/MLDv2 Report as 216 the protocol allows to include multiple sources in the same message. 218 However, even short-lived state may be harmful when the intent is to 219 cause as much state as possible. The host can continue to send IGMP/ 220 MLD Reports to these groups to make the state attack more long-lived. 221 This results in: 223 o ASM: a (*,G) join is sent to an intra-domain RP, causing state on 224 that path; in turn, that RP joins to the DR of the source if the 225 source is active. If the source address was specified by the host 226 in the IGMPv3/MLDv2 Report, a (S,G) Join is sent directly to the 227 DR of the source, as with SSM, below. 229 o SSM: a (S,G) join is sent inter-domain to the DR of the source S, 230 causing state on that path. If the source does not exist, the 231 join goes to the closest router on the path to S as possible. 233 o Embedded-RP: a (*,G) join is sent towards an inter/intra-domain RP 234 embedded in the group G, causing state on that path. If the RP 235 does not exist, the join goes to the closest router to the RP as 236 possible. Similarly, an explicit (S,G) join goes to the DR, as 237 with SSM above. 239 That is, SSM and Embedded-RP always enable "inter-domain" state 240 creation. ASM defaults to intra-domain, but can be used for 241 inter-domain state creation as well. 243 If the source or RP does not exist, the multicast routing protocol 244 does not have any means to remove the distribution tree if the 245 joining host remains active. Worst case attack could be a host 246 remaining active to many different groups (containing either 247 imaginary source or RP). 249 For example, if the host is able to generate 100 IGMPv3 (S,G) joins a 250 second, each carrying 10 sources, the amount of state after 260 251 seconds would be 260 000 state entries -- and 100 packets per second 252 is still a rather easily achievable number. 254 3.2 Source-based Attacks 256 These attacks are often referred to as "data plane" attacks; however, 257 with traditional ASM and MSDP, these also include an MSDP control 258 plane threat. 260 3.2.1 Sending Multicast to Empty Groups 262 Description of the threat: Data Flooding. Data Flooding occurs when 263 a host sends data packets to a multicast group or SSM channel for 264 which there are no real subscribers. 266 Note that since unicast-encapsulation is not subject to RPF checks, 267 the hosts can also craft and send these packets themselves, also 268 spoofing the source address of the register messages unless ingress 269 filtering [12] has been deployed [13]. 271 Examples of this threat are a virus/worm trying to propagate to 272 multicast addresses, an attacker trying to crash routers with 273 excessive MSDP state, or an attacker wishing to overload the RP with 274 encapsulated packets or different groups. This results in: 276 o ASM: the DR unicast-encapsulates the packets in Register messages 277 to the intra-domain RP, which may join to the source and issue a 278 Register-Stop, but continues to get the data. A notification 279 about the active source is sent (unless the group or source is 280 configured to be local) inter-domain with MSDP and propagated 281 globally. 283 o SSM: the DR receives the data, but the data does not propagate 284 from the DR unless someone joins the (S,G) channel. 286 o Embedded-RP: the DR register-encapsulates the packets to the 287 intra/inter-domain RP, which may join to the source and issue a 288 Register-Stop. Data continues to be encapsulated if different 289 groups are used. 291 This yields many potential attacks, especially if at least parts of 292 the multicast forwarding functions are implemented on a "slow" path 293 or CPU in the routers, at least: 295 o The MSDP control plane traffic generated can cause a significant 296 amount of control and data traffic which may overload the routers 297 receiving it. A thorough analysis of MSDP vulnerabilities can be 298 found in [14], and is only related to the ASM. However, this is 299 the most serious threat at the moment, because MSDP will flood the 300 multicast group information to all multicast domains in Internet 301 including the multicast packet encapsulated to MSDP source-active 302 message. This creates a lot of data and state to be shared by all 303 multicast enabled routers and if the source remains active, the 304 flooding will be repeated every 60 seconds by default. 306 o As a large amount of data is forwarded on the multicast tree; if 307 multicast forwarding is performed on CPU, it may be a serious 308 performance bottleneck, and a way to perform DoS on the path. 309 Similarly, the DR must always be capable of processing (and 310 discarding, if necessary) the multicast packets received from the 311 source. These are potentially present in every model. 313 o If the encapsulation is performed on software, it may be a 314 performance bottleneck, and a way to perform DoS on the DR. 315 Similarly, if the decapsulation is performed on software, it may 316 be a performance bottleneck, and a way to perform DoS on the RP. 317 Note: the decapsulator may know, based on access configuration, a 318 rate-limit or something else, that it doesn't need to decapsulate 319 the packet, avoiding bottlenecks. These threats are related to 320 ASM and Embedded-RP. 322 3.2.2 Disturbing Existing Group by Sending to It 324 Description of the threat: Group Integrity Violation. Group Integrity 325 Violation occurs when a host sends packets to a group or SSM channel, 326 which already exists, to disturb the users of the existing group/SSM 327 channel. 329 The SSM service model prevents injection of packets to (S,G) 330 channels, avoiding this problem. However, if the source address can 331 be spoofed to be a topologically-correct address, it's possible to 332 get the packet into the distribution tree -- typically only those 333 hosts which are on-link with the source are able to perform this, so 334 this is not really relevant in the scope of this memo. 336 With ASM and Embedded-RP sources can inject forged traffic through 337 RPs, which provide the source discovery for the group. The RP(s) send 338 the traffic over the shared tree towards receivers (routers with 339 (*,G) state). DR then forwards the forged traffic to receivers unless 340 the legitimate recipients are able to filter out unwanted sources, 341 e.g., using MSF API [8]. Typically this is not used or supported by 342 the applications using these protocols. 344 Note that with ASM and Embedded-RP, the RP may exert some form of 345 control on who can send to a group, as the first packets are 346 unicast-encapsulated in register packets to the RP -- if the RP drops 347 the packet based on access-list, rate-limiter or something else, it 348 doesn't get injected to an existing group. 350 With ASM this "source control" is distributed across all the PIM 351 domains, which decreases its applicability. Embedded-RP enables 352 easier control because source discovery is done through single RP per 353 group. 355 As a result, for this attack to succeed, the RP must decapsulate the 356 packets, causing the propagation of data and the integrity violation. 358 3.3 Aggravating Factors to the Threats 360 This section describes a few factors, which aggravate the threats 361 described in Section 3.1 and Section 3.2. These could also be viewed 362 as individual threats on their own. 364 There are multiple threats relating to the use of host-to-router 365 signalling protocols -- such as Internet Group Management Protocol 366 (IGMP) or Multicast Listener Discovery (MLD) -- but these are outside 367 the scope of this memo. 369 PIM-SM can also be abused in the cases where RPF checks are not 370 applicable, in particular, in the stub LAN networks -- as spoofing 371 the on-link traffic is very simple. For example, a host would get 372 elected to become DR for the subnet, but not perform any of its 373 functions. These are described at some length in [1], but are also 374 considered out of scope of this memo. 376 3.3.1 Distant RP/Source Problem 378 In the shared tree model, if the RP or a source is distant 379 (topologically), then joins will travel to the distant RP or source 380 and keep the state information in the path active, even if the data 381 is being delivered locally. 383 Note that this problem will be exacerbated if the RP/source space is 384 global; if a router is registering to a RP/source that is not in the 385 local domain (say, fielded by the site's direct provider), then the 386 routing domain is flat. 388 Also note that PIM assumes that the addresses used in PIM messages 389 are valid. However, there is no way to ensure this, and using 390 non-existent S or G in (*,G) or (S,G) -messages will cause the 391 signalling to be set up, even though one cannot reach the address. 393 This will be analysed at more length in Section 5.1. 395 3.3.2 No Receiver Information in PIM Joins 397 Only DRs, which are directly connected to receivers, know the exact 398 receiver information (e.g. IP address). PIM does not forward that 399 information further in the multicast distribution tree. Therefore 400 individual routers (e.g. domain edge routers) are not able to make 401 policy decisions on who can be connected to the distribution tree. 403 4. Threat Analysis 405 4.1 Summary of the Threats 407 Trying to summarize the severity of the major classes of threats with 408 respect to each multicast usage model, we have a matrix of resistance 409 to different kinds of threats: 411 +----------------+------------------+-----------------+ 412 | Forged Join | Being a Source | Group Integrity | 413 +-------------+----------------+------------------+-----------------+ 414 | ASM | bad 1) | very bad | bad/mediocre | 415 +-------------+----------------+------------------+-----------------+ 416 | SSM | bad | very good | very good | 417 +-------------+----------------+------------------+-----------------+ 418 | Embedded-RP | bad 1),2) | good/mediocre 3) | good | 419 +-------------+----------------+------------------+-----------------+ 421 Notes: 423 1) in ASM host can directly join also (S,G) groups with IGMPv3/MLDv2 424 and thus have same characteristics as SSM (also allows inter-domain 425 state to be created). 427 2) allows inter-domain shared state to be created. 429 3) Embedded-RP allows a host to determine the RP for a given group 430 (or set of groups), which in turn allows that host to mount a PIM 431 register attack. In this case, the host can mount the attack without 432 implementing any of the PIM register machinery. 434 4.2 Enhancements for Threat Mitigation 436 There are several desirable actions ("requirements") which could be 437 considered to mitigate these threats; these are listed below. A few 438 more concrete suggestions are presented later in the section. 440 o Inter-domain MSDP (ASM) should be retired to avoid attacks; or, if 441 this is not reasonable, the DRs should rate-limit the 442 unicast-encapsulation (note that the hosts can circumvent this) 443 and (more importantly) the RPs should rate-limit the 444 unicast-decapsulation especially from different sources, or MSDP 445 must rate-limit the MSDP data generation for new sources. 447 o DRs should rate-limit PIM Joins and Prunes somehow; there are 448 multiple possibilities how exactly this should be considered 449 (i.e., which variables to take into the consideration). 451 o DRs could rate-limit unicast-encapsulation somehow; there are 452 multiple ways to perform this. Note that the hosts can avoid this 453 by performing the unicast-encapsulation themselves if so inclined. 455 o RPs could rate-limit unicast-decapsulation somehow; there are 456 multiple ways to perform this. Note that if the source of the 457 unicast packets is spoofed by the host, this may have an effect on 458 how e.g. rate-limiters behave. 460 o RPs should rate limit the MSDP SA messages coming from MSDP peers. 462 o RPs could limit or even disable the SA cache size. However, this 463 could have negative effects on normal operation. 465 o RPs should provide good interfaces to reject packets which are not 466 interesting; for example, if an Embedded-RP group is not 467 configured to be allowed in the RP, the unicast-encapsulated 468 packets would not even be decapsulated. 470 o DRs could rate-limit the multicast traffic somehow to reduce the 471 disturbing possibilities; there are multiple possibilities how 472 exactly this should be considered. 474 o DRs should rate-limit the number of groups/SSM channels that can 475 be created by a given source, S. 477 5. PIM Security Enhancements 479 This section includes more in-depth description of the 480 above-mentioned rate-limiting etc. functions as well as description 481 of the remote routability signalling issue. 483 5.1 Remote Routability Signalling 485 As described in Section 3.3.1, non-existent DRs or RPs may cause some 486 problems when setting up multicast state. There seem to be a couple 487 of different approaches to mitigate this, especially if rate-limiting 488 is not extensively deployed. 490 With ASM and Embedded-RP, Register message delivery could be ensured 491 somehow. For example: 493 1) At the very least, receiving an ICMP unreachable message (of 494 any flavor) should cause the DR to stop the Register packets -- as 495 the RP will not be receiving them anyway. (However, one should 496 note that easy spoofing of such ICMP messages could cause a DoS on 497 legitimate traffic.) 499 2) An additional method could be implementing a timer on the RPs 500 so that unless nothing is heard back from the RP within a defined 501 time period, the flow of Register messages would stop. (Currently, 502 the RPs are not required to answer back, unless they want to join 503 to the source.) 505 3) An extreme case would be performing some form of return 506 routability check prior to starting the register messages: first a 507 packet would be sent to the RP, testing its existence and 508 willingness to serve, and also proving to the RP that the sender 509 of the "bubble" and the sender of the registers are the same and 510 the source address is not forged (i.e., the RP would insert a 511 cookie in the bubble, and it would have to be present in the 512 register message.) 514 It would be desirable to have some kind of state management for PIM 515 Joins (and other messages) as well, for example, a "Join Ack" which 516 could be used to ensure that the path to the source/RP actually 517 exists. However, this is very difficult if not impossible with the 518 current architecture: PIM messages are sent hop-by-hop, and there is 519 not enough information to trace back the replies to e.g., notify the 520 routers in the middle to release the corresponding state, and to 521 nofify the DR that the path did not exist. 523 Appendix B discusses this receiver-based remote routability 524 signalling in more detail. 526 5.2 Rate-limiting Possibilities 528 There seem to be many ways to implement rate-limiting (for 529 signalling, data encapsulation and multicast traffic) at the DRs or 530 RPs -- the best approach likely depends on the threat model; factors 531 in the evaluation might be e.g.: 533 o Whether the host is willfully maliscious, uncontrolled (e.g., 534 virus/worm), or a regular user just doing something wrong. 536 o Whether the threat is aimed towards a single group, a single RP 537 handling the group, or the (multicast) routing infrastructure in 538 general. 540 o Whether the host on a subnet is spoofing its address (but still as 541 one which fulfills the RPF checks of the DR) or not. 543 o Whether the host may generate the PIM join (and similar) messages 544 itself to avoid rate-limiters at the DR if possible. 546 o Whether unicast RPF checks are applied on the link (i.e., whether 547 the host can send unicast-encapsulated register-messages on its 548 own). 550 o Whether blocking the misbehaving host on a subnet is allowed to 551 also block other, legitimate hosts on the same subnet. 553 o Whether these mechanisms would cause false positives on links with 554 only properly working hosts if many of them are receivers or 555 senders. 557 As should be obvious, there are many different scenarios here which 558 seem to call for different kinds of solutions. 560 For example, the rate-limiting could be performed based on: 562 1. multicast address, or the RP where the multicast address maps to 564 2. source address 566 3. the (source address, multicast address) -pair (or the RP which 567 maps to the multicast address) 569 4. data rate in case of rate limiting the source 571 5. everything (multicast groups and sources would not be 572 distinguished at all) 574 In the above, we make an assumption that rate-limiting would be 575 performed per-interface (on DRs) if a more fine-grained filter is not 576 being used. 578 It should be noted that some of the rate limiting functions can be 579 used as a tool for DoS against legimate multicast users. Therefore 580 several parameters for rate limiting should be used to prevent such 581 operation. 583 The next revisions of this document (or separated in other documents, 584 if appropriate) will include more explicit discussion of the best 585 ways to perform rate-limiting, especially considering the effects on 586 the legimate traffic. 588 5.3 Specific Rate-limiting Suggestions 590 These suggestions take two forms: limiters designed to be run on all 591 the edge networks, preventing or limiting an attack in the first 592 place, and the limiters designed to be run at the border of PIM 593 domains or at the RPs, which should provide protection in case 594 edge-based limiting fails or was not implemented, or when additional 595 control is required. 597 Almost none of the suggested rate-limiters take legitimate users into 598 account. That is, for example, being able to allow some hosts on a 599 link to transmit/receive, while disallowing others, is very 600 challenging to do right, because the attackers can easily circumvent 601 such systems. Therefore the intent is to limit the damage to only 602 one link, one DR, or one RP -- and avoid the more global effects on 603 the Internet multicast architecture. 605 It could also be possible to perform white-listing of groups, 606 sources, or (S,G) -pairs from the rate-limiters -- so that packets 607 related to these would not be counted towards the limits (e.g., the 608 case of an aggressive but legitimate source, while not not desiring 609 to modify the limiting parameters for all the traffic. 611 5.3.1 Group Management Protocol Rate-limiter 613 A token-bucket -based rate-limiter to all Group Management Protocols 614 (IGMP, MLD), which would limit the average rate of accepted groups or 615 sources, on the specific interface, to G_MAX per second, with a 616 bucket of G_LONG. Example values could be G_MAX=1 and G_LONG=20. 617 Note that e.g., an IGMPv3 join with two included sources for one 618 group would count as two groups/sources. 620 This would be the first-order defense against state-creation attacks 621 from the hosts. However, as it cannot be guaranteed that all the 622 routers would implement something like this, other kinds of 623 protections would be useful as well. This harms legitimate receivers 624 on the same link as an attacker as well. 626 5.3.2 Source Transmission Rate-limiter 628 A token-bucket -based rate-limiter which would limit the multicast 629 data transmission (excluding link-local groups) on a specific 630 interface to GSEND_MAX groups per second, with a bucket of 631 GSEND_LONG. Example values could be GSEND_MAX=10 and GSEND_LONG=20. 633 This would be the first-order defense against data flooding attacks. 634 However, as it cannot be guaranteed that all routers would implement 635 something like this, and as the RP (if SSM is not used) could be 636 loaded from multiple senders, additional protections are needed as 637 well. This harms legitimate senders on the same link as an attacker 638 as well. This does not protect from a host sending a lot of traffic 639 to the same group; this only harms the DR and the RP of the group, 640 and is similar to unicast DDoS attacks against one source, and is not 641 considered critical for the overall security. 643 5.3.3 PIM Signalling Rate-limiter 645 A token-bucket -based rate-limiter which would limit the all 646 multicast PIM messaging, either through a specific interface or 647 globally on the router, to PIM_MAX new entries per second, with a 648 bucket of PIM_LONG. Example values could be 1000 and 10000. 650 This would second-order defense againt PIM state attacks when GMP 651 rate-limiters haven't been implemented or haven't been effective. 652 This limiter might not need to be active by default, as long as the 653 values are configurable. The main applicability for this filter 654 would be applying it at a border of PIM domain in case PIM state 655 attacks are detected. This harms legitimate receivers as well. 657 5.3.4 Unicast-decapsulation Rate-limiter 659 A token-bucket -based rate-limiter for unicast-decapsulation, 660 limiting the decapsulation to DECAP_MAX new groups per second, with a 661 bucket of DECAP_LONG. If the router has restarted recently, a larger 662 initial bucket should be used. Example values could be DECAP_MAX=1 663 and DECAP_LONG=10 (or DECAP_LONG=500 after restart). 665 This would be second-order defense against data flooding: if the DRs 666 would not implement appropriate limiters, or if the total number of 667 flooded groups rises too high, the RP should be able to limit the 668 rate with which new groups are created. This does not harm 669 legitimate senders, as long as their group has already been created. 671 5.3.5 MSDP Source-Active Rate-limiter 673 A token-bucket -based, source-based rate-limiter, limiting new groups 674 per source to SAG_MAX per second, with a bucket of SAG_LONG. Example 675 values could be SAG_MAX=1 and SAG_LONG=10. 677 This would be a second-order defense, both at the MSDP SA sending and 678 receiving sites, against data flooding and MSDP vulnerabilities in 679 particular. The specific threat being addressed here is a source (or 680 multiple different sources) trying to "probe" (e.g., virus or worm) 681 different multicast addresses. [14] discusses different MSDP attack 682 prevention mechanisms at length. 684 6. Security Considerations 686 This memo analyzes the security of PIM routing infrastructures in 687 some detail, and proposes enhancements to mitigate the observed 688 threats. 690 7. IANA Considerations 692 This memo is for informational purposes and does not introduce new 693 namespaces for the IANA to manage. 695 8. Acknowledgements 697 Kamil Sarac discussed "return routability" issues at length. 699 9. References 701 9.1 Normative References 703 [1] Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, "Protocol 704 Independent Multicast - Sparse Mode PIM-SM): Protocol 705 Specification (Revised)", draft-ietf-pim-sm-v2-new-09 (work in 706 progress), February 2004. 708 [2] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol 709 (MSDP)", RFC 3618, October 2003. 711 [3] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", 712 draft-ietf-ssm-arch-04 (work in progress), October 2003. 714 [4] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) 715 Address in an IPv6 Multicast Address", 716 draft-ietf-mboned-embeddedrp-02 (work in progress), March 2004. 718 [5] Barbir, A., Murphy, S. and Y. Yang, "Generic Threats to Routing 719 Protocols", draft-ietf-rpsec-routing-threats-06 (work in 720 progress), April 2004. 722 9.2 Informative References 724 [6] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 725 1112, August 1989. 727 [7] Bhattacharyya, S., "An Overview of Source-Specific Multicast 728 (SSM)", RFC 3569, July 2003. 730 [8] Thaler, D., Fenner, B. and B. Quinn, "Socket Interface 731 Extensions for Multicast Source Filters", RFC 3678, January 732 2004. 734 [9] Hardjono, T. and B. Weis, "The Multicast Security 735 Architecture", draft-ietf-msec-arch-05 (work in progress), 736 January 2004. 738 [10] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. 739 Thyagarajan, "Internet Group Management Protocol, Version 3", 740 RFC 3376, October 2002. 742 [11] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 743 (MLDv2) for IPv6", draft-vida-mld-v2-08 (work in progress), 744 December 2003. 746 [12] Ferguson, P. and D. Senie, "Network Ingress Filtering: 747 Defeating Denial of Service Attacks which employ IP Source 748 Address Spoofing", BCP 38, RFC 2827, May 2000. 750 [13] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 751 Networks", draft-savola-bcp38-multihoming-update-03 (work in 752 progress), December 2003. 754 [14] Rajvaidya, P., Ramachandran, K. and K. Almeroth, "Detection and 755 Deflection of DoS Attacks Against the Multicast Source 756 Discovery Protocol", UCSB Technical Report, May 2003. 758 Authors' Addresses 760 Pekka Savola 761 CSC/FUNET 763 Espoo 764 Finland 766 EMail: psavola@funet.fi 768 Rami Lehtonen 769 TeliaSonera 770 Hataanpaan valtatie 20 771 Tampere 33100 772 Finland 774 EMail: rami.lehtonen@teliasonera.com 776 David Meyer 778 EMail: dmm@1-4-5.net 780 Appendix A. RPF Considers Interface, Not Neighbor 782 In most current implementations, the RPF check considers only the 783 incoming interface, and not the upstream neighbor (RPF neighbor). 785 This can result in accepting packets from the "wrong" RPF neighbor 786 (the neighbor is "wrong" since, while the RPF check succeeds and the 787 packet is forwarded, the unicast policy would not have forwarded the 788 packet). 790 This is a problem in the media where more than two routers can 791 connect to, in particular, Ethernet-based Internet Exchanges. 792 Therefore any neighbor on such a link could inject any PIM signalling 793 as long as a route matching the address used in the signalling is 794 going through the interface. 796 However, one should note that for PIM signalling to be accepted, a 797 PIM adjancency must have been established. However, typically, this 798 does not help much against willful attackers, as typically PIM 799 adjacencies are formed with anyone on the link. Still, the 800 requirement is that the neighbor who has enabled PIM in the concerned 801 interface. I.e., in most cases, the threat is limited to attackers 802 within the operators in the exchange, not third parties. On the 803 other hand, data plane forwarding has no such checks -- and having 804 such checks would require one to look at the link-layer addresses 805 used; that is, this checking is not as feasible as one might hope. 807 Appendix B. Return Routability Extensions 809 The multicast state information is built from the receiver side and 810 it can be currently pruned only by the receiver side DR. If the RP or 811 the source for the group is non-existent, the state can't be pruned 812 by the DR without return routability extensions to provide such 813 information. There might be also need to remove the state in some 814 cases when there is no multicast traffic sent to that group. This 815 section discusses about the alternative ways to remove the unused 816 state information in the routers, so that it can't be used in state 817 based DoS attacks. Note that rate limiting PIM Joins gives some 818 protection against the state attacks. 820 B.1 Sending PIM-Prune Messages Down the Tree 822 When a router discovers the non-existance of the RP or the source 823 (XXX: does it actually know if there is RP/Source or not), it can 824 create a PIM-Prune message and send it back to the join originator. 825 However, since it does not know the unicast IP address of join 826 originator DR, it cannot directly unicast it to that router. 828 A possible alternative is to use a link-local multicast group address 829 (e.g., all-pim routers local multicast address) to pass this 830 information back toward the joining DR. Since the routers from this 831 current router all the way back to the joining DR has forwarding 832 state entry for the group, they can use this state information to see 833 how to forward the PIM-Prune message back. 835 Each on-tree router, in addition to forwarding the PIM-Prune message, 836 can also prune the state from their state tables. This way, the 837 PIM-Prune message will go back to the DR by following the so far 838 created multicast forwarding state information. In addition, if we 839 use some sort of RPF checks during this process, we can also make it 840 more difficult to inject such PIM-Prune messages maliciously. 842 A potential abuse scenario may involve an attacker having access to a 843 router on the direct path to send such PIM-Prune messages down the 844 tree branch so as to prune the branch from the tree. But such an 845 attacker can currently achieve the same effect by sending PIM-Prune 846 message toward the source from the same point on the tree. So, the 847 proposed mechanism does not really aggravate the situation. 849 One visible overhead in this new scenario might be that someone can 850 send bogus join messages to create redundant PIM-Join and PIM-Prune 851 messages in the network. 853 B.2 Analysing Multicast Group Traffic at DR 855 Another possible way to remove the unused state information would be 856 to analyse individual group traffic at the DR and if there is no 857 multicast traffic for a certain group within a certain time limit, 858 the state should be removed. In here, if the receiver is malicious 859 and wants to create states in the network, then it can send joins to 860 different groups and create states on routers for each of these 861 different groups until the DR decides that the groups are inactive 862 and initiates the prune process. In addition, during the prune 863 process, the routers will again process all these prune messages and 864 therefore will be spending time. 866 B.3 Comparison of the Above Approaches 868 Both of these solutions have the same problem of renewing the 869 multicast state information. DR shouldn't permanently block the state 870 building for that group, but to restrict the PIM Joins if it notices 871 that the receiver is abusing the system. One additional option is to 872 block the PIM Joins to the non-existent source/RP for a certain time. 874 In the first approach (sending PIM-Prunes down the tree), part of the 875 goal was to prune the states in the routers much sooner than in the 876 second approach (e.g. goal is to make sure that the routers will not 877 be keeping unnecessary states for long time). 879 The second approach works also for DoS attacks related to the 880 existing source/RP addresses and could be more quickly implemented 881 and deployed in the network and does not have any relationship 882 related to the other deployments (no need to change all PIM routers). 884 Intellectual Property Statement 886 The IETF takes no position regarding the validity or scope of any 887 Intellectual Property Rights or other rights that might be claimed to 888 pertain to the implementation or use of the technology described in 889 this document or the extent to which any license under such rights 890 might or might not be available; nor does it represent that it has 891 made any independent effort to identify any such rights. Information 892 on the IETF's procedures with respect to rights in IETF Documents can 893 be found in BCP 78 and BCP 79. 895 Copies of IPR disclosures made to the IETF Secretariat and any 896 assurances of licenses to be made available, or the result of an 897 attempt made to obtain a general license or permission for the use of 898 such proprietary rights by implementers or users of this 899 specification can be obtained from the IETF on-line IPR repository at 900 http://www.ietf.org/ipr. 902 The IETF invites any interested party to bring to its attention any 903 copyrights, patents or patent applications, or other proprietary 904 rights that may cover technology that may be required to implement 905 this standard. Please address the information to the IETF at 906 ietf-ipr@ietf.org. 908 Disclaimer of Validity 910 This document and the information contained herein are provided on an 911 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 912 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 913 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 914 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 915 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 916 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 918 Copyright Statement 920 Copyright (C) The Internet Society (2004). This document is subject 921 to the rights, licenses and restrictions contained in BCP 78, and 922 except as set forth therein, the authors retain all their rights. 924 Acknowledgment 926 Funding for the RFC Editor function is currently provided by the 927 Internet Society.