idnits 2.17.1 draft-ietf-mboned-mroutesec-04.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 3978, Section 5.1.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 980. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 957. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 964. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 970. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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 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: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 21 longer pages, the longest (page 17) being 71 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages 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 == Line 696 has weird spacing: '... source with ...' -- 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 (October 12, 2004) is 7133 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-10 ** Downref: Normative reference to an Experimental RFC: RFC 3618 (ref. '2') == Outdated reference: A later version (-07) exists of draft-ietf-ssm-arch-06 == 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') == Outdated reference: A later version (-09) exists of draft-ietf-pim-bidir-07 Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MBONED WG P. Savola 2 Internet-Draft CSC/FUNET 3 Expires: April 12, 2005 R. Lehtonen 4 TeliaSonera 5 D. Meyer 6 October 12, 2004 8 PIM-SM Multicast Routing Security Issues and Enhancements 9 draft-ietf-mboned-mroutesec-04.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 12, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). 42 Abstract 44 This memo describes security threats for the larger (intra-domain, or 45 inter-domain) multicast routing infrastructures. Only Protocol 46 Independent Multicast - Sparse Mode (PIM-SM) is analyzed, in its 47 three main operational modes: the traditional Any Source Multicast 48 (ASM) model, Source-Specific Multicast (SSM) model, and the ASM model 49 enhanced by the Embedded-RP group-to-RP mapping mechanism. This memo 50 also describes enhancements to the protocol operations to mitigate 51 the identified threats. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Threats to Multicast Routing . . . . . . . . . . . . . . . . . 4 58 3.1 Receiver-based Attacks . . . . . . . . . . . . . . . . . . 5 59 3.1.1 Joins to Different Groups . . . . . . . . . . . . . . 5 60 3.2 Source-based Attacks . . . . . . . . . . . . . . . . . . . 6 61 3.2.1 Sending Multicast to Empty Groups . . . . . . . . . . 6 62 3.2.2 Disturbing Existing Group by Sending to It . . . . . . 8 63 3.3 Aggravating Factors to the Threats . . . . . . . . . . . . 9 64 3.3.1 Distant RP/Source Problem . . . . . . . . . . . . . . 9 65 3.3.2 No Receiver Information in PIM Joins . . . . . . . . . 9 66 4. Threat Analysis . . . . . . . . . . . . . . . . . . . . . . . 9 67 4.1 Summary of the Threats . . . . . . . . . . . . . . . . . . 9 68 4.2 Enhancements for Threat Mitigation . . . . . . . . . . . . 10 69 5. PIM Security Enhancements . . . . . . . . . . . . . . . . . . 11 70 5.1 Remote Routability Signalling . . . . . . . . . . . . . . 11 71 5.2 Rate-limiting Possibilities . . . . . . . . . . . . . . . 12 72 5.3 Specific Rate-limiting Suggestions . . . . . . . . . . . . 13 73 5.3.1 Group Management Protocol Rate-limiter . . . . . . . . 14 74 5.3.2 Source Transmission Rate-limiter . . . . . . . . . . . 14 75 5.3.3 PIM Signalling Rate-limiter . . . . . . . . . . . . . 14 76 5.3.4 Unicast-decapsulation Rate-limiter . . . . . . . . . . 15 77 5.3.5 PIM Register Rate-limiter . . . . . . . . . . . . . . 15 78 5.3.6 MSDP Source-Active Rate-limiter . . . . . . . . . . . 15 79 5.4 Passive Mode for PIM . . . . . . . . . . . . . . . . . . . 15 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 84 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 17 85 9.2 Informative References . . . . . . . . . . . . . . . . . . . 17 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 87 A. RPF Considers Interface, Not Neighbor . . . . . . . . . . . . 18 88 B. Return Routability Extensions . . . . . . . . . . . . . . . . 19 89 B.1 Sending PIM-Prune Messages Down the Tree . . . . . . . . . 19 90 B.2 Analysing Multicast Group Traffic at DR . . . . . . . . . 20 91 B.3 Comparison of the Above Approaches . . . . . . . . . . . . 20 92 Intellectual Property and Copyright Statements . . . . . . . . 21 94 1. Introduction 96 This document describes security threats to the Protocol Independent 97 Multicast - Sparse Mode (PIM-SM) multicast routing infrastructures, 98 and suggests ways to make these architectures more resistant to the 99 described threats. 101 Only attacks which have an effect on the multicast routing 102 infrastructures (whether intra- or inter-domain) are considered. 104 "On-link" attacks where the hosts are specifically targeting the 105 Designated Router (DR) or other routers on the link, or where hosts 106 are disrupting other hosts on the same link, possibly using group 107 management protocols, are discussed elsewhere (e.g., [10] and [12]). 108 These attacks are not discussed further in this document. 110 Similar to unicast, the multicast payloads may need end-to-end 111 security. Security mechanisms to provide confidentiality, 112 authentication, and integrity are described in other documents (e.g., 113 [9]). These attacks that these security mechanisms protect against 114 are not discussed further in this document. 116 PIM builds on a model where Reverse Path Forwarding (RPF) checking 117 is, among other things, used to ensure loop-free properties of the 118 multicast distribution trees. As a side effect, this limits the 119 impact of an attacker using a forged source address, which is often 120 used as a component in unicast-based attacks. However, a host can 121 still spoof an address within the same subnet, or spoof the source of 122 a unicast-encapsulated PIM Register message, which a host may send on 123 its own. 125 We consider PIM-SM [1] operating in the traditional Any Souce 126 Multicast (ASM) model (including the use of Multicast Source 127 Discovery Protocol (MSDP) [2] for source discovery), in 128 Source-Specific Multicast [3] (SSM) model, and the Embedded-RP [4] 129 group-to-RP mapping mechanism in ASM model. Bidirectional-PIM [15] 130 is typically deployed only in intra-domain, and is similar to ASM but 131 without register messages. Bidirectional-PIM is not finished as of 132 this writing, and its considerations are not discussed further in 133 this document. 135 2. Terminology 137 ASM 139 "ASM" [6] is used to refer to the traditional Any Source 140 Multicast model with multiple PIM domains and a signalling 141 mechanism (MSDP) to exchange information about active sources 142 between them. 144 SSM 146 "SSM" [7] is used to refer to Source-Specific Multicast. 148 SSM channel 150 SSM channel (S, G) identifies the multicast delivery tree 151 associated with a source address S and a SSM destination 152 address G. 154 Embedded-RP 156 "Embedded-RP" refers to the ASM model where the Embedded-RP 157 mapping mechanism is used to find the Rendezvous Point (RP) for 158 a group, and MSDP is not used. 160 Target Router 162 "Target Router" is used to refer to either the RP processing a 163 packet (ASM or Embedded-RP), or the DR that is receiving 164 (Source, Group) (or (S,G)) joins, (in all models). 166 3. Threats to Multicast Routing 168 We make the broad assumption that the multicast routing networks are 169 reasonably trusted. That is, we assume that the multicast routers 170 themselves are well-behaved, in the same sense that unicast routers 171 are expected to behave well. While this assumption is not entirely 172 correct, it simplifies the analysis of threat models. The threats 173 caused by misbehaving multicast routers (including fake multicast 174 routers) are not considered in this memo -- the generic threat model 175 would be similar to [5]. RP discovery mechanisms like Bootstrap 176 Router (BSR) and Auto-RP are also considered out of the scope. 178 As the threats described in this memo are mainly Denial of Service 179 (DoS) attacks, it may be useful to note that the attackers will try 180 to find a scarce resource anywhere in the control or data plane, as 181 described in [5]. 183 There are multiple threats relating to the use of host-to-router 184 signalling protocols -- such as Internet Group Management Protocol 185 (IGMP) or Multicast Listener Discovery (MLD) -- but these are outside 186 the scope of this memo. 188 PIM-SM can be abused in the cases where RPF checks are not 189 applicable, in particular, in the stub LAN networks -- as spoofing 190 the on-link traffic is very simple. For example, a host could get 191 elected to become DR for the subnet, but not perform any of its 192 functions. A host can also easily make PIM routers on the link stop 193 forwarding multicast by sending PIM Assert messages. This implies 194 that a willful attacker will be able to circumvent many of the 195 potential rate-limiting functions performed at the DR (as one can 196 always send the messages yourself). The PIM-SM specification, 197 however, states that these messages should only be accepted from 198 known PIM neighbors; if this is performed, the hosts would first have 199 to establish a PIM adjacency with the router. Typically, adjacencies 200 are formed with anyone on the link, so a willful attacker would have 201 a high probability of success in forming a protocol adjacency. These 202 are described at some length in [1], but are also considered out of 203 scope of this memo. 205 3.1 Receiver-based Attacks 207 These attacks are often referred to as control plane attacks and the 208 aim of the attacker is usually to increase the amount of multicast 209 state information in routers above a manageable level. 211 3.1.1 Joins to Different Groups 213 Description of the threat: Join Flooding. Join Flooding occurs when 214 a host tries to join, once or a couple of times, to a group or a SSM 215 channel, and the DR generates a PIM Join to the Target Router. The 216 group/SSM channel or the Targer Router may or may not exist. 218 Example of this is a host trying to join different, non-existent 219 groups at a very rapid pace, trying to overload the routers on the 220 path with an excessive amount of (*/S,G) state (also referred to as 221 "PIM State"), or the Target Router with an excessive number of 222 packets. 224 Note that even if a host joins to a group multiple times, the DR only 225 sends one PIM Join message, without waiting for any acknowledgement; 226 the next message is only sent after the PIM Join timer expires or the 227 state changes at the DR. 229 This kind of joining causes PIM state to be created, but this state 230 is relatively short-lived (260 seconds by default, which is the 231 default time that the state is active at DR in the absence of 232 IGMP/MLD Reports/Leaves). It should also be noted that the host can 233 join a number of different ASM groups or SSM channels with only one 234 IGMPv3 [11] or MLDv2 [12] Report as the protocol allows to include 235 multiple sources in the same message, resulting in multiple PIM Joins 236 from one IGMPv3/MLDv2 message. 238 However, even short-lived state may be harmful when the intent is to 239 cause as much state as possible. The host can continue to send 240 IGMP/MLD Reports to these groups to make the state attack more 241 long-lived. This results in: 243 o ASM: a (*,G) join is sent to an intra-domain RP, causing state on 244 that path; in turn, that RP joins to the DR of the source if the 245 source is active. If the source address was specified by the host 246 in the IGMPv3/MLDv2 Report, a (S,G) Join is sent directly to the 247 DR of the source, as with SSM, below. 249 o SSM: a (S,G) join is sent inter-domain to the DR of the source S, 250 causing state on that path. If the source does not exist, the 251 join goes to the closest router on the path to S as possible. 253 o Embedded-RP: a (*,G) join is sent towards an inter/intra-domain RP 254 embedded in the group G, causing state on that path. If the RP 255 does not exist, the join goes to the closest router to the RP 256 address as possible. Similarly, an explicit (S,G) join goes to 257 the DR, as with SSM above. 259 That is, SSM and Embedded-RP always enable "inter-domain" state 260 creation. ASM defaults to intra-domain, but can be used for 261 inter-domain state creation as well. 263 If the source or RP (only in case of Embedded-RP) does not exist, the 264 multicast routing protocol does not have any means to remove the 265 distribution tree if the joining host remains active. Worst case 266 attack could be a host remaining active to many different groups 267 (containing either imaginary source or RP). Please note that the 268 imaginary RP problem is related to only Embedded-RP, where the RP 269 address is extracted from the group address, G. 271 For example, if the host is able to generate 100 IGMPv3 (S,G) joins a 272 second, each carrying 10 sources, the amount of state after 260 273 seconds would be 260 000 state entries -- and 100 packets per second 274 is still a rather easily achievable number. 276 3.2 Source-based Attacks 278 These attacks are often referred to as "data plane" attacks; however, 279 with traditional ASM and MSDP, these also include an MSDP control 280 plane threat. 282 3.2.1 Sending Multicast to Empty Groups 284 Description of the threat: Data Flooding. Data Flooding occurs when 285 a host sends data packets to a multicast group or SSM channel for 286 which there are no real subscribers. 288 Note that since register encapsulation is not subject to RPF checks, 289 the hosts can also craft and send these packets themselves, also 290 spoofing the source address of the register messages unless ingress 291 filtering [13] has been deployed [14]. That is, as the initial data 292 registering is not subject to the same RPF checks as many other 293 multicast routing procedures, making control decisions based on that 294 data leads to many potential threats. 296 Examples of this threat are a virus/worm trying to propagate to 297 multicast addresses, an attacker trying to crash routers with 298 excessive MSDP state, or an attacker wishing to overload the RP with 299 encapsulated packets or different groups. This results in: 301 o ASM: the DR register-encapsulates the packets in Register messages 302 to the intra-domain RP, which may join to the source and issue a 303 Register-Stop, but continues to get the data. A notification 304 about the active source is sent (unless the group or source is 305 configured to be local) inter-domain with MSDP and propagated 306 globally. 308 o SSM: the DR receives the data, but the data does not propagate 309 from the DR unless someone joins the (S,G) channel. 311 o Embedded-RP: the DR register-encapsulates the packets to the 312 intra/inter-domain RP, which may join to the source and issue a 313 Register-Stop. Data continues to be encapsulated if different 314 groups are used. 316 This yields many potential attacks, especially if at least parts of 317 the multicast forwarding functions are implemented on a "slow" path 318 or CPU in the routers, at least: 320 o The MSDP control plane traffic generated can cause a significant 321 amount of control and data traffic which may overload the routers 322 receiving it. A thorough analysis of MSDP vulnerabilities can be 323 found in [16], and is only related to the ASM. However, this is 324 the most serious threat at the moment, because MSDP will flood the 325 multicast group information to all multicast domains in Internet 326 including the multicast packet encapsulated to MSDP source-active 327 message. This creates a lot of data and state to be shared by all 328 multicast enabled routers and if the source remains active, the 329 flooding will be repeated every 60 seconds by default. 331 o As a large amount of data is forwarded on the multicast tree; if 332 multicast forwarding is performed on CPU, it may be a serious 333 performance bottleneck, and a way to perform DoS on the path. 335 Similarly, the DR must always be capable of processing (and 336 discarding, if necessary) the multicast packets received from the 337 source. These are potentially present in every model. 339 o If the encapsulation is performed on software, it may be a 340 performance bottleneck, and a way to perform DoS on the DR. 341 Similarly, if the decapsulation is performed on software, it may 342 be a performance bottleneck, and a way to perform DoS on the RP. 343 Note: the decapsulator may know, based on access configuration, a 344 rate-limit or something else, that it doesn't need to decapsulate 345 the packet, avoiding bottlenecks. These threats are related to 346 ASM and Embedded-RP. 348 3.2.2 Disturbing Existing Group by Sending to It 350 Description of the threat: Group Integrity Violation. Group 351 Integrity Violation occurs when a host sends packets to a group or 352 SSM channel, which already exists, to disturb the users of the 353 existing group/SSM channel. 355 The SSM service model prevents injection of packets to (S,G) 356 channels, avoiding this problem. However, if the source address can 357 be spoofed to be a topologically-correct address, it's possible to 358 get the packet into the distribution tree -- typically only those 359 hosts which are on-link with the source are able to perform this, so 360 this is not really relevant in the scope of this memo. 362 With ASM and Embedded-RP sources can inject forged traffic through 363 RPs, which provide the source discovery for the group. The RP(s) 364 send the traffic over the shared tree towards receivers (routers with 365 (*,G) state). DR then forwards the forged traffic to receivers 366 unless the legitimate recipients are able to filter out unwanted 367 sources, e.g., using MSF API [8]. Typically this is not used or 368 supported by the applications using these protocols. 370 Note that with ASM and Embedded-RP, the RP may exert some form of 371 control on who can send to a group, as the first packets are 372 register-encapsulated in register packets to the RP -- if the RP 373 drops the packet based on access-list, rate-limiter or something 374 else, it doesn't get injected to an existing group. 376 With ASM this "source control" is distributed across all the PIM 377 domains, which significantly decreases its applicability. 378 Embedded-RP enables easier control because source discovery is done 379 through single RP per group. 381 As a result, for this attack to succeed, the RP must decapsulate the 382 packets, causing the propagation of data and the integrity violation. 384 3.3 Aggravating Factors to the Threats 386 This section describes a few factors, which aggravate the threats 387 described in Section 3.1 and Section 3.2. These could also be viewed 388 as individual threats on their own. 390 3.3.1 Distant RP/Source Problem 392 In the shared tree model, if the RP or a source is distant 393 (topologically), then joins will travel to the distant RP or source 394 and keep the state information in the path active, even if the data 395 is being delivered locally. 397 Note that this problem will be exacerbated if the RP/source space is 398 global; if a router is registering to a RP/source that is not in the 399 local domain (say, fielded by the site's direct provider), then the 400 routing domain is flat. 402 Also note that PIM assumes that the addresses used in PIM messages 403 are valid. However, there is no way to ensure this, and using 404 non-existent S or G in (*,G) or (S,G) -messages will cause the 405 signalling to be set up, even though one cannot reach the address. 407 This will be analysed at more length in Section 5.1. 409 3.3.2 No Receiver Information in PIM Joins 411 Only DRs, which are directly connected to receivers, know the exact 412 receiver information (e.g. IP address). PIM does not forward that 413 information further in the multicast distribution tree. Therefore 414 individual routers (e.g. domain edge routers) are not able to make 415 policy decisions on who can be connected to the distribution tree. 417 4. Threat Analysis 419 4.1 Summary of the Threats 421 Trying to summarize the severity of the major classes of threats with 422 respect to each multicast usage model, we have a matrix of resistance 423 to different kinds of threats: 425 +----------------+------------------+-----------------+ 426 | Forged Join | Being a Source | Group Integrity | 427 +-------------+----------------+------------------+-----------------+ 428 | ASM | bad 1) | very bad | bad/mediocre | 429 +-------------+----------------+------------------+-----------------+ 430 | SSM | bad | very good | very good | 431 +-------------+----------------+------------------+-----------------+ 432 | Embedded-RP | bad 1),2) | good/mediocre 3) | good | 433 +-------------+----------------+------------------+-----------------+ 435 Notes: 437 1) in ASM host can directly join also (S,G) groups with IGMPv3/MLDv2 438 and thus have same characteristics as SSM (also allows inter-domain 439 state to be created). 441 2) allows inter-domain shared state to be created. 443 3) Embedded-RP allows a host to determine the RP for a given group 444 (or set of groups), which in turn allows that host to mount a PIM 445 register attack. In this case, the host can mount the attack without 446 implementing any of the PIM register machinery. 448 4.2 Enhancements for Threat Mitigation 450 There are several desirable actions ("requirements") which could be 451 considered to mitigate these threats; these are listed below. A few 452 more concrete suggestions are presented later in the section. 454 o Inter-domain MSDP (ASM) should be retired to avoid attacks; or, if 455 this is not reasonable, the DRs should rate-limit the register 456 encapsulation (note that the hosts can circumvent this) and (more 457 importantly) the RPs should rate-limit the register decapsulation 458 especially from different sources, or MSDP must rate-limit the 459 MSDP data generation for new sources. 461 o DRs should rate-limit PIM Joins and Prunes somehow; there are 462 multiple possibilities how exactly this should be considered 463 (i.e., which variables to take into the consideration). 465 o DRs could rate-limit register encapsulation somehow; there are 466 multiple ways to perform this. Note that the hosts can avoid this 467 by performing the register encapsulation themselves if so 468 inclined. 470 o RPs could rate-limit register decapsulation somehow; there are 471 multiple ways to perform this. Note that if the source of the 472 unicast packets is spoofed by the host, this may have an effect on 473 how e.g. rate-limiters behave. 475 o RPs should rate limit the MSDP SA messages coming from MSDP peers. 477 o RPs could limit or even disable the SA cache size. However, this 478 could have negative effects on normal operation. 480 o RPs should provide good interfaces to reject packets which are not 481 interesting; for example, if an Embedded-RP group is not 482 configured to be allowed in the RP, the register encapsulated 483 packets would not even be decapsulated. 485 o DRs could rate-limit the multicast traffic somehow to reduce the 486 disturbing possibilities; there are multiple possibilities how 487 exactly this should be considered. 489 o DRs should rate-limit the number of groups/SSM channels that can 490 be created by a given source, S. 492 5. PIM Security Enhancements 494 This section includes more in-depth description of the 495 above-mentioned rate-limiting etc. functions as well as description 496 of the remote routability signalling issue. 498 5.1 Remote Routability Signalling 500 As described in Section 3.3.1, non-existent DRs or RPs may cause some 501 problems when setting up multicast state. There seem to be a couple 502 of different approaches to mitigate this, especially if rate-limiting 503 is not extensively deployed. 505 With ASM and Embedded-RP, Register message delivery could be ensured 506 somehow. For example: 508 1) At the very least, receiving an ICMP unreachable message (of 509 any flavor) should cause the DR to stop the Register packets -- as 510 the RP will not be receiving them anyway. (However, one should 511 note that easy spoofing of such ICMP messages could cause a DoS on 512 legitimate traffic.) 514 2) An additional method could be implementing a timer on the RPs 515 so that unless nothing is heard back from the RP within a defined 516 time period, the flow of Register messages would stop. 517 (Currently, the RPs are not required to answer back, unless they 518 want to join to the source.) 519 3) An extreme case would be performing some form of return 520 routability check prior to starting the register messages: first a 521 packet would be sent to the RP, testing its existence and 522 willingness to serve, and also proving to the RP that the sender 523 of the "bubble" and the sender of the registers are the same and 524 the source address is not forged (i.e., the RP would insert a 525 cookie in the bubble, and it would have to be present in the 526 register message.) 528 It would be desirable to have some kind of state management for PIM 529 Joins (and other messages) as well, for example, a "Join Ack" which 530 could be used to ensure that the path to the source/RP actually 531 exists. However, this is very difficult if not impossible with the 532 current architecture: PIM messages are sent hop-by-hop, and there is 533 not enough information to trace back the replies to e.g., notify the 534 routers in the middle to release the corresponding state, and to 535 nofify the DR that the path did not exist. 537 Appendix B discusses this receiver-based remote routability 538 signalling in more detail. 540 5.2 Rate-limiting Possibilities 542 There seem to be many ways to implement rate-limiting (for 543 signalling, data encapsulation and multicast traffic) at the DRs or 544 RPs -- the best approach likely depends on the threat model; factors 545 in the evaluation might be e.g.: 547 o Whether the host is willfully maliscious, uncontrolled (e.g., 548 virus/worm), or a regular user just doing something wrong. 550 o Whether the threat is aimed towards a single group, a single RP 551 handling the group, or the (multicast) routing infrastructure in 552 general. 554 o Whether the host on a subnet is spoofing its address (but still as 555 one which fulfills the RPF checks of the DR) or not. 557 o Whether the host may generate the PIM join (and similar) messages 558 itself to avoid rate-limiters at the DR if possible. 560 o Whether unicast RPF checks are applied on the link (i.e., whether 561 the host can send register-encapsulated register-messages on its 562 own). 564 o Whether blocking the misbehaving host on a subnet is allowed to 565 also block other, legitimate hosts on the same subnet. 567 o Whether these mechanisms would cause false positives on links with 568 only properly working hosts if many of them are receivers or 569 senders. 571 As should be obvious, there are many different scenarios here which 572 seem to call for different kinds of solutions. 574 For example, the rate-limiting could be performed based on: 576 1. multicast address, or the RP where the multicast address maps to 578 2. source address 580 3. the (source address, multicast address) -pair (or the RP which 581 maps to the multicast address) 583 4. data rate in case of rate limiting the source 585 5. everything (multicast groups and sources would not be 586 distinguished at all) 588 In the above, we make an assumption that rate-limiting would be 589 performed per-interface (on DRs) if a more fine-grained filter is not 590 being used. 592 It should be noted that some of the rate limiting functions can be 593 used as a tool for DoS against legimate multicast users. Therefore 594 several parameters for rate limiting should be used to prevent such 595 operation. 597 5.3 Specific Rate-limiting Suggestions 599 These suggestions take two forms: limiters designed to be run on all 600 the edge networks, preventing or limiting an attack in the first 601 place, and the limiters designed to be run at the border of PIM 602 domains or at the RPs, which should provide protection in case 603 edge-based limiting fails or was not implemented, or when additional 604 control is required. 606 Almost none of the suggested rate-limiters take legitimate users into 607 account. That is, for example, being able to allow some hosts on a 608 link to transmit/receive, while disallowing others, is very 609 challenging to do right, because the attackers can easily circumvent 610 such systems. Therefore the intent is to limit the damage to only 611 one link, one DR, or one RP -- and avoid the more global effects on 612 the Internet multicast architecture. 614 It could also be possible to perform white-listing of groups, 615 sources, or (S,G) -pairs from the rate-limiters -- so that packets 616 related to these would not be counted towards the limits (e.g., the 617 case of an aggressive but legitimate source, while not not desiring 618 to modify the limiting parameters for all the traffic. 620 5.3.1 Group Management Protocol Rate-limiter 622 A token-bucket -based rate-limiter to all Group Management Protocols 623 (IGMP, MLD), which would limit the average rate of accepted groups or 624 sources, on the specific interface, with a bucket of depth of 625 G_DEPTH, refilling at G_RATE tokens per second. Example values could 626 be G_RATE=1 and G_DEPTH=20. Note that e.g., an IGMPv3 join with two 627 included sources for one group would count as two groups/sources. 629 This would be the first-order defense against state-creation attacks 630 from the hosts. However, as it cannot be guaranteed that all the 631 routers would implement something like this, other kinds of 632 protections would be useful as well. This harms legitimate receivers 633 on the same link as an attacker as well. 635 5.3.2 Source Transmission Rate-limiter 637 A token-bucket -based rate-limiter which would limit the multicast 638 data transmission (excluding link-local groups) on a specific 639 interface with a bucket of depth of GSEND_DEPTH, refilling at 640 GSEND_RATE tokens per second. Example values could be GSEND_RATE=10 641 and GSEND_DEPTH=20. 643 This would be the first-order defense against data flooding attacks. 644 However, as it cannot be guaranteed that all routers would implement 645 something like this, and as the RP (if SSM is not used) could be 646 loaded from multiple senders, additional protections are needed as 647 well. This harms legitimate senders on the same link as an attacker 648 as well. This does not protect from a host sending a lot of traffic 649 to the same group; this only harms the DR and the RP of the group, 650 and is similar to unicast DDoS attacks against one source, and is not 651 considered critical for the overall security. 653 5.3.3 PIM Signalling Rate-limiter 655 A token-bucket -based rate-limiter which would limit the all 656 multicast PIM messaging, either through a specific interface or 657 globally on the router, with a bucket of depth of PIM_DEPTH, 658 refilling at PIM_RATE tokens per second. Example values could be 659 PIM_RATE=1000 and PIM_DEPTH=10000. 661 This would second-order defense againt PIM state attacks when GMP 662 rate-limiters haven't been implemented or haven't been effective. 664 This limiter might not need to be active by default, as long as the 665 values are configurable. The main applicability for this filter 666 would be applying it at a border of PIM domain in case PIM state 667 attacks are detected. This harms legitimate receivers as well. 669 5.3.4 Unicast-decapsulation Rate-limiter 671 A simple decapsulation rate-limiter protecting the CPU usage in the 672 router, limiting X pps (the need and limit depends on the router 673 architecture), disregarding the source of the registers. This could 674 also be an additional check to be used before decapsulation and 675 checking the group to throttle the worst of the decapsulation CPU 676 consumption. This limit should have to be quite high, and would 677 hamper the existing legimate sessions as well. 679 5.3.5 PIM Register Rate-limiter 681 A token-bucket -based rate-limiter for register decapsulation of PIM 682 Register messages, with a bucket of depth of REG_DEPTH, refilling at 683 REG_RATE tokens per second. If the router has restarted recently, a 684 larger initial bucket should be used. Example values could be 685 REG_RATE=1 and REG_DEPTH=10 (or REG_DEPTH=500 after restart). 687 This would be second-order defense against data flooding: if the DRs 688 would not implement appropriate limiters, or if the total number of 689 flooded groups rises too high, the RP should be able to limit the 690 rate with which new groups are created. This does not harm 691 legitimate senders, as long as their group has already been created. 693 5.3.6 MSDP Source-Active Rate-limiter 695 A token-bucket -based, source-based rate-limiter, limiting new groups 696 per source with a bucket of depth of SAG_DEPTH, refilling at 697 SAG_RATE tokens per second. Example values could be SAG_RATE=1 and 698 SAG_DEPTH=10. 700 This would be a second-order defense, both at the MSDP SA sending and 701 receiving sites, against data flooding and MSDP vulnerabilities in 702 particular. The specific threat being addressed here is a source (or 703 multiple different sources) trying to "probe" (e.g., virus or worm) 704 different multicast addresses. [16] discusses different MSDP attack 705 prevention mechanisms at length. 707 5.4 Passive Mode for PIM 709 As described in the last paragraph of section 3, hosts are also able 710 to form PIM adjacencies and send disrupting traffic unless great care 711 is observed at the routers. This stems from the fact that most 712 implementations require that stub LANs with only one PIM router must 713 also have PIM enabled (to enable PIM processing of the sourced data 714 etc.) Such stub networks however do not require to actually run the 715 PIM protocol on the link. Therefore such implementations should 716 provide an option to specify that the interface is "passive" with 717 regard to PIM: no PIM packets are sent or processed (if received), 718 but hosts can still send and receive multicast on that interface. 720 6. Security Considerations 722 This memo analyzes the security of PIM routing infrastructures in 723 some detail, and proposes enhancements to mitigate the observed 724 threats. 726 This document does not discuss adding (strong) authentication to the 727 multicast protocols. PIM-SM specification [1] describes the 728 application of IPsec for routing authentication; it is worth noting 729 that being able to authenticate the register messages and being able 730 to prevent illegitimate users from establishing PIM adjacencies would 731 seem to be the two most important goals. IGMPv3 specification [11] 732 describes the use of IPsec for group management (similar applies to 733 MLDv2 as well), which is out of scope for this memo; however, it is 734 worth noting that being able to control the group memberships might 735 reduce the receiver-based attacks. 737 However, one should keep in mind two caveats: authentication alone 738 might not be sufficient, especially if the user or the host stack 739 (consider a worm propagation scenario) cannot be expected to "behave 740 well"; and that adding such authentication likely provides new attack 741 vectors, e.g., in the form of a CPU DoS attack with excessive amount 742 of cryptographic operations. 744 7. IANA Considerations 746 This memo is for informational purposes and does not introduce new 747 namespaces for the IANA to manage. 749 [[ Note to the RFC-editor: please remove this section upon 750 publication ]] 752 8. Acknowledgements 754 Kamil Sarac discussed "return routability" issues at length. Stig 755 Venaas provided feedback to improve the document quality. Bill 756 Fenner and Russ Housley provided useful comments during the IESG 757 evaluation. 759 9. References 761 9.1 Normative References 763 [1] Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, "Protocol 764 Independent Multicast - Sparse Mode PIM-SM): Protocol 765 Specification (Revised)", draft-ietf-pim-sm-v2-new-10 (work in 766 progress), July 2004. 768 [2] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol 769 (MSDP)", RFC 3618, October 2003. 771 [3] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", 772 draft-ietf-ssm-arch-06 (work in progress), September 2004. 774 [4] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) 775 Address in an IPv6 Multicast Address", 776 draft-ietf-mboned-embeddedrp-07 (work in progress), July 2004. 778 [5] Barbir, A., Murphy, S. and Y. Yang, "Generic Threats to Routing 779 Protocols", draft-ietf-rpsec-routing-threats-06 (work in 780 progress), April 2004. 782 9.2 Informative References 784 [6] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 785 1112, August 1989. 787 [7] Bhattacharyya, S., "An Overview of Source-Specific Multicast 788 (SSM)", RFC 3569, July 2003. 790 [8] Thaler, D., Fenner, B. and B. Quinn, "Socket Interface 791 Extensions for Multicast Source Filters", RFC 3678, January 792 2004. 794 [9] Hardjono, T. and B. Weis, "The Multicast Group Security 795 Architecture", RFC 3740, March 2004. 797 [10] Daley, G. and G. Kurup, "Trust Models and Security in Multicast 798 Listener Discovery", draft-daley-magma-smld-prob-00 (work in 799 progress), July 2004. 801 [11] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A. 802 Thyagarajan, "Internet Group Management Protocol, Version 3", 803 RFC 3376, October 2002. 805 [12] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 806 (MLDv2) for IPv6", RFC 3810, June 2004. 808 [13] Ferguson, P. and D. Senie, "Network Ingress Filtering: 809 Defeating Denial of Service Attacks which employ IP Source 810 Address Spoofing", BCP 38, RFC 2827, May 2000. 812 [14] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 813 Networks", BCP 84, RFC 3704, March 2004. 815 [15] Handley, M., Kouvelas, I., Speakman, T. and L. Vicisano, 816 "Bi-directional Protocol Independent Multicast (BIDIR-PIM)", 817 draft-ietf-pim-bidir-07 (work in progress), July 2004. 819 [16] Rajvaidya, P., Ramachandran, K. and K. Almeroth, "Detection and 820 Deflection of DoS Attacks Against the Multicast Source 821 Discovery Protocol", UCSB Technical Report, May 2003. 823 Authors' Addresses 825 Pekka Savola 826 CSC/FUNET 827 Espoo 828 Finland 830 EMail: psavola@funet.fi 832 Rami Lehtonen 833 TeliaSonera 834 Hataanpaan valtatie 20 835 Tampere 33100 836 Finland 838 EMail: rami.lehtonen@teliasonera.com 840 David Meyer 842 EMail: dmm@1-4-5.net 844 Appendix A. RPF Considers Interface, Not Neighbor 846 In most current implementations, the RPF check considers only the 847 incoming interface, and not the upstream neighbor (RPF neighbor). 849 This can result in accepting packets from the "wrong" RPF neighbor 850 (the neighbor is "wrong" since, while the RPF check succeeds and the 851 packet is forwarded, the unicast policy would not have forwarded the 852 packet). 854 This is a problem in the media where more than two routers can 855 connect to, in particular, Ethernet-based Internet Exchanges. 856 Therefore any neighbor on such a link could inject any PIM signalling 857 as long as a route matching the address used in the signalling is 858 going through the interface. 860 However, one should note that for PIM signalling to be accepted, a 861 PIM adjancency must have been established. However, typically, this 862 does not help much against willful attackers, as typically PIM 863 adjacencies are formed with anyone on the link. Still, the 864 requirement is that the neighbor who has enabled PIM in the concerned 865 interface. I.e., in most cases, the threat is limited to attackers 866 within the operators in the exchange, not third parties. On the 867 other hand, data plane forwarding has no such checks -- and having 868 such checks would require one to look at the link-layer addresses 869 used; that is, this checking is not as feasible as one might hope. 871 Appendix B. Return Routability Extensions 873 The multicast state information is built from the receiver side and 874 it can be currently pruned only by the receiver side DR. If the RP 875 or the source for the group is non-existent, the state can't be 876 pruned by the DR without return routability extensions to provide 877 such information. There might be also need to remove the state in 878 some cases when there is no multicast traffic sent to that group. 879 This section discusses about the alternative ways to remove the 880 unused state information in the routers, so that it can't be used in 881 state based DoS attacks. Note that rate limiting PIM Joins gives 882 some protection against the state attacks. 884 B.1 Sending PIM-Prune Messages Down the Tree 886 When a router discovers the non-existence of the RP or the source, it 887 can create a PIM-Prune message and send it back to the join 888 originator. However, since it does not know the unicast IP address 889 of join originator DR, it cannot directly unicast it to that router. 891 A possible alternative is to use a link-local multicast group address 892 (e.g., all-pim routers local multicast address) to pass this 893 information back toward the joining DR. Since the routers from this 894 current router all the way back to the joining DR has forwarding 895 state entry for the group, they can use this state information to see 896 how to forward the PIM-Prune message back. 898 Each on-tree router, in addition to forwarding the PIM-Prune message, 899 can also prune the state from their state tables. This way, the 900 PIM-Prune message will go back to the DR by following the so far 901 created multicast forwarding state information. In addition, if we 902 use some sort of RPF checks during this process, we can also make it 903 more difficult to inject such PIM-Prune messages maliciously. 905 A potential abuse scenario may involve an attacker having access to a 906 router on the direct path to send such PIM-Prune messages down the 907 tree branch so as to prune the branch from the tree. But such an 908 attacker can currently achieve the same effect by sending PIM-Prune 909 message toward the source from the same point on the tree. So, the 910 proposed mechanism does not really aggravate the situation. 912 One visible overhead in this new scenario might be that someone can 913 send bogus join messages to create redundant PIM-Join and PIM-Prune 914 messages in the network. 916 B.2 Analysing Multicast Group Traffic at DR 918 Another possible way to remove the unused state information would be 919 to analyse individual group traffic at the DR and if there is no 920 multicast traffic for a certain group within a certain time limit, 921 the state should be removed. In here, if the receiver is malicious 922 and wants to create states in the network, then it can send joins to 923 different groups and create states on routers for each of these 924 different groups until the DR decides that the groups are inactive 925 and initiates the prune process. In addition, during the prune 926 process, the routers will again process all these prune messages and 927 therefore will be spending time. 929 B.3 Comparison of the Above Approaches 931 Both of these solutions have the same problem of renewing the 932 multicast state information. DR shouldn't permanently block the 933 state building for that group, but to restrict the PIM Joins if it 934 notices that the receiver is abusing the system. One additional 935 option is to block the PIM Joins to the non-existent source/RP for a 936 certain time. 938 In the first approach (sending PIM-Prunes down the tree), part of the 939 goal was to prune the states in the routers much sooner than in the 940 second approach (e.g. goal is to make sure that the routers will not 941 be keeping unnecessary states for long time). 943 The second approach works also for DoS attacks related to the 944 existing source/RP addresses and could be more quickly implemented 945 and deployed in the network and does not have any relationship 946 related to the other deployments (no need to change all PIM routers). 948 Intellectual Property Statement 950 The IETF takes no position regarding the validity or scope of any 951 Intellectual Property Rights or other rights that might be claimed to 952 pertain to the implementation or use of the technology described in 953 this document or the extent to which any license under such rights 954 might or might not be available; nor does it represent that it has 955 made any independent effort to identify any such rights. Information 956 on the procedures with respect to rights in RFC documents can be 957 found in BCP 78 and BCP 79. 959 Copies of IPR disclosures made to the IETF Secretariat and any 960 assurances of licenses to be made available, or the result of an 961 attempt made to obtain a general license or permission for the use of 962 such proprietary rights by implementers or users of this 963 specification can be obtained from the IETF on-line IPR repository at 964 http://www.ietf.org/ipr. 966 The IETF invites any interested party to bring to its attention any 967 copyrights, patents or patent applications, or other proprietary 968 rights that may cover technology that may be required to implement 969 this standard. Please address the information to the IETF at 970 ietf-ipr@ietf.org. 972 Disclaimer of Validity 974 This document and the information contained herein are provided on an 975 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 976 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 977 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 978 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 979 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 980 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 982 Copyright Statement 984 Copyright (C) The Internet Society (2004). This document is subject 985 to the rights, licenses and restrictions contained in BCP 78, and 986 except as set forth therein, the authors retain all their rights. 988 Acknowledgment 990 Funding for the RFC Editor function is currently provided by the 991 Internet Society.