idnits 2.17.1 draft-ietf-pim-sm-bsr-05.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1712. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1702), 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. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 127 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the 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 (18 February 2005) is 7007 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-11 == Outdated reference: A later version (-09) exists of draft-ietf-pim-bidir-07 ** Obsolete normative reference: RFC 3513 (ref. '5') (Obsoleted by RFC 4291) -- Obsolete informational reference (is this intentional?): RFC 2362 (ref. '7') (Obsoleted by RFC 4601, RFC 5059) == Outdated reference: A later version (-07) exists of draft-ietf-pim-anycast-rp-02 Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force PIM WG 2 INTERNET-DRAFT Nidhi Bhaskar/Cisco 3 draft-ietf-pim-sm-bsr-05.txt Alexander Gall/SWITCH 4 James Lingard/Data Connection 5 Stig Venaas/UNINETT 6 18 February 2005 7 Expires: August 2005 9 Bootstrap Router (BSR) Mechanism for PIM 11 Status of this Document 13 By submitting this Internet-Draft, I certify that any applicable patent 14 or other IPR claims of which I am aware have been disclosed, or will be 15 disclosed, and any of which I become aware will be disclosed, in 16 accordance with RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering Task 19 Force (IETF), its areas, and its working groups. Note that other groups 20 may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference material 25 or to cite them other than a "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This document is a product of the IETF PIM WG. Comments should be 34 addressed to the authors, or the WG's mailing list at pim@ietf.org. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). All Rights Reserved. 40 Abstract 42 This document specifies the Bootstrap Router (BSR) mechanism 43 for the class of multicast routing protocols in the PIM 44 (Protocol Independent Multicast) family that use the concept 45 of a Rendezvous Point as a means for receivers to discover the 46 sources that send to a particular multicast group. BSR is one 47 way that a multicast router can learn the set of group-to-RP 48 mappings required in order to function. The mechanism is 49 dynamic, largely self-configuring, and robust to router 50 failure. 52 Table of Contents 54 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 4 55 1.1. Background . . . . . . . . . . . . . . . . . . . . . 4 56 1.2. Protocol Overview. . . . . . . . . . . . . . . . . . 6 57 1.3. Administrative Scoping and BSR . . . . . . . . . . . 7 58 2. BSR State and Timers. . . . . . . . . . . . . . . . . . 9 59 3. Bootstrap Router Election and RP-Set 60 Distribution. . . . . . . . . . . . . . . . . . . . . . 9 61 3.1. Bootstrap Router Election. . . . . . . . . . . . . . 9 62 3.1.1. Per-Scope-Zone Candidate-BSR State 63 Machine . . . . . . . . . . . . . . . . . . . . . 10 64 3.1.2. Per-Scope-Zone State Machine for Non- 65 Candidate-BSR Routers . . . . . . . . . . . . . . 12 66 3.1.3. Bootstrap Message Processing Checks . . . . . . . 14 67 3.1.4. State Machine Transition Events . . . . . . . . . 14 68 3.1.5. State Machine Actions . . . . . . . . . . . . . . 15 69 3.2. Sending Candidate-RP-Advertisement Messages. . . . . 16 70 3.3. Creating the RP-Set at the BSR . . . . . . . . . . . 18 71 3.4. Forwarding Bootstrap Messages. . . . . . . . . . . . 20 72 3.5. Unicasting Bootstrap Messages to New and 73 Rebooting Routers. . . . . . . . . . . . . . . . . . 21 74 3.6. Receiving and Using the RP-Set . . . . . . . . . . . 21 75 4. Message Formats . . . . . . . . . . . . . . . . . . . . 21 76 4.1. Bootstrap Message Format . . . . . . . . . . . . . . 24 77 4.1.1. Semantic Fragmentation of BSMs. . . . . . . . . . 27 78 4.2. Candidate-RP-Advertisement Message Format. . . . . . 29 79 5. Timers and Timer Values . . . . . . . . . . . . . . . . 30 80 6. Security Considerations . . . . . . . . . . . . . . . . 33 81 6.1. Possible Threats . . . . . . . . . . . . . . . . . . 33 82 6.2. Limiting Third-Party DoS Attacks . . . . . . . . . . 33 83 6.3. Bootstrap Message Security . . . . . . . . . . . . . 34 84 6.3.1. Rejecting Unicast Bootstrap Messages. . . . . . . 34 85 6.3.2. Rejecting Bootstrap Messages from Invalid 86 Neighbors . . . . . . . . . . . . . . . . . . . . 35 87 6.4. Candidate-RP-Advertisement Message Security. . . . . 35 88 6.4.1. Non-Cryptographic Security of C-RP-Adv 89 Messages. . . . . . . . . . . . . . . . . . . . . 35 90 6.4.2. Cryptographic Security of C-RP-Adv 91 Messages. . . . . . . . . . . . . . . . . . . . . 36 92 6.5. Denial of Service using IPsec. . . . . . . . . . . . 36 93 7. Contributors. . . . . . . . . . . . . . . . . . . . . . 37 94 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 37 95 9. IANA Considerations . . . . . . . . . . . . . . . . . . 37 96 10. Normative References . . . . . . . . . . . . . . . . . 37 97 11. Informative References . . . . . . . . . . . . . . . . 38 99 1. Introduction 101 This document assumes some familiarity with the concepts of Protocol 102 Independent Multicast - Sparse Mode (PIM-SM), as defined in [1], and Bi- 103 directional Protocol Independent Multicast (BIDIR-PIM), as defined in 104 [2], as well as with Administratively Scoped IP Multicast, as described 105 in [3], and the IPv6 Scoped Address Architecture, described in [4]. 107 For correct operation, every multicast router within a PIM domain must 108 be able to map a particular multicast group address to the same 109 Rendezvous Point (RP). The PIM specifications do not mandate the use of 110 a single mechanism to provide routers with the information to perform 111 this group-to-RP mapping. 113 This document describes the PIM Bootstrap Router (BSR) mechanism. BSR 114 is one way that a multicast router can learn the information required to 115 perform the group-to-RP mapping. The mechanism is dynamic, largely 116 self-configuring, and robust to router failure. 118 BSR was first defined in RFC 2362 [7], which has since been obsoleted. 119 This document provides an updated specification of the BSR mechanism 120 from RFC 2362, and also extends it to cope with administratively scoped 121 region boundaries and different flavours of routing protocols. 123 Throughout the document, any reference to the PIM protocol family is 124 restricted to the subset of RP-based protocols, namely PIM-SM and BIDIR- 125 PIM, unless stated otherwise. 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119 [6]. 131 1.1. Background 133 A PIM domain is a contiguous set of routers that all implement PIM and 134 are configured to operate within a common boundary defined by PIM 135 Multicast Border Routers (PMBRs). PMBRs connect each PIM domain to the 136 rest of the internet. 138 Every PIM multicast group needs to be associated with the IP address of 139 a Rendezvous Point (RP). This address is used as the root of a group- 140 specific distribution tree whose branches extend to all nodes in the 141 domain that want to receive traffic sent to the group. Senders inject 142 packets into the tree in such a manner that they reach all connected 143 receivers. How this is done and how the packets are forwarded along the 144 distribution tree depends on the particular routing protocol. 146 For all senders to reach all receivers, it is crucial that all routers 147 in the domain use the same mappings of group addresses to RP addresses. 149 An exception to the above is where a PIM domain has been broken up into 150 multiple administrative scope regions. These are regions where a border 151 has been configured so that a set of multicast groups will not be 152 forwarded across that border. In this case, all PIM routers within the 153 same scope region must map a particular scoped group to the same RP 154 within that region. 156 In order to determine the RP for a multicast group, a PIM router 157 maintains a collection of group-to-RP mappings, called the RP-Set. A 158 group-to-RP mapping contains the following elements. 160 o Multicast group range, expressed as an address and prefix length 162 o RP priority 164 o RP address 166 o Hash mask length 168 o SM / BIDIR flag 170 In general, the group ranges of these group-to-RP mappings may overlap 171 in arbitrary ways; hence a particular multicast group may be covered by 172 multiple group-to-RP mappings. When this is the case, the router 173 chooses only one of the RPs by applying a deterministic algorithm so 174 that all routers in the domain make the same choice. It is important to 175 note that this algorithm is part of the specification of the individual 176 routing protocols (and may differ among them), not of the BSR 177 specification. 179 There are a number of ways in which such group-to-RP mappings can be 180 established. The simplest solution is for all the routers in the domain 181 to be statically configured with the same information. However, static 182 configuration generally doesn't scale well, and, except when used in 183 conjunction with Anycast-RP (see [8] and [9]), does not dynamically 184 adapt to route around router or link failures. 186 The BSR mechanism provides a way in which viable group-to-RP mappings 187 can be created and rapidly distributed to all the PIM routers in a 188 domain. It is adaptive, in that if an RP becomes unreachable, this will 189 be detected and the RP-Sets will be modified so that the unreachable RP 190 is no longer used. 192 1.2. Protocol Overview 194 In this section we give an informal and non-definitive overview of the 195 BSR mechanism. The definitive specification begins in section 2. 197 The general idea behind the BSR mechanism is that some of the PIM 198 routers within a PIM domain are configured to be potential RPs for the 199 domain. These are known as Candidate-RPs (C-RPs). A subset of the C- 200 RPs will eventually be used as the actual RPs for the domain. In 201 addition, some of the PIM routers in the domain are configured to be 202 candidate bootstrap routers, or Candidate-BSRs (C-BSRs). One of these 203 C-BSRs will be elected to be the bootstrap router (BSR) for the domain, 204 and all the PIM routers in the domain will learn the result of this 205 election through Bootstrap messages. The C-RPs will then report their 206 candidacy to the elected BSR, which chooses a subset of these C-RPs and 207 distributes corresponding group-to-RP mappings to all the routers in the 208 domain through Bootstrap messages. 210 In more detail, the BSR mechanism works as follows. There are four 211 basic phases (although in practice all phases may be occurring 212 simultaneously): 214 1. BSR Election. Each Candidate-BSR originates Bootstrap messages 215 (BSMs). Every BSM contains a BSR Priority field. Routers within 216 the domain flood the BSMs throughout the domain. A C-BSR that 217 hears about a higher-priority C-BSR than itself then suppresses its 218 sending of further BSMs for some period of time. The single 219 remaining C-BSR becomes the elected BSR, and its BSMs inform all 220 the other routers in the domain that it is the elected BSR. 222 2. C-RP Advertisement. Each Candidate-RP within a domain sends 223 periodic Candidate-RP-Advertisement (C-RP-Adv) messages to the 224 elected BSR. A C-RP-Adv message includes the priority of the 225 advertising C-RP, as well as a list of group ranges for which the 226 candidacy is advertised. In this way, the BSR learns about 227 possible RPs that are currently up and reachable. 229 3. RP-Set Formation. The BSR selects a subset of the C-RPs that it 230 has received C-RP-Adv messages from to form the RP-Set. In general 231 it should do this in such a way that the RP-Set is neither too 232 large to inform all the routers in the domain about, nor too small 233 so that load is overly concentrated on some RPs. It should also 234 attempt to produce an RP-Set that does not change frequently. 236 4. RP-Set Flooding. In future Bootstrap messages, the BSR includes 237 the RP-Set information. Bootstrap messages are flooded through the 238 domain, which ensures that the RP-Set rapidly reaches all the 239 routers in the domain. BSMs are originated periodically to ensure 240 consistency after failure restoration. 242 When a PIM router receives a Bootstrap message, it adds the group- 243 to-RP mappings contained therein to its pool of mappings obtained 244 from other sources (e.g. static configuration). It calculates the 245 final mappings of group addresses to RP addresses from this pool 246 according to rules specific to the particular routing protocol and 247 uses that information to construct multicast distribution trees. 249 If a PIM domain becomes partitioned, each area separated from the old 250 BSR will elect its own BSR, which will distribute an RP-Set containing 251 RPs that are reachable within that partition. When the partition heals, 252 another election will occur automatically and only one of the BSRs will 253 continue to send out Bootstrap messages. As is expected at the time of 254 a partition or healing, some disruption in packet delivery may occur. 255 This time will be on the order of the region's round-trip time and the 256 BS_Timeout value. 258 1.3. Administrative Scoping and BSR 260 The mechanism described in the previous section does not work when the 261 PIM domain is divided into administratively scoped regions. To handle 262 this situation, we use the protocol modifications described in this 263 section. 265 Administrative scoping permits a PIM domain to be divided into multiple 266 admin-scope regions. Each admin-scope region is a convex connected set 267 of PIM routers, and is associated with a set of group addresses. The 268 boundary of the admin-scope region is formed by Zone Border Routers 269 (ZBRs). ZBRs are configured not to forward traffic for any of the 270 scoped group addresses into or out of the scoped region. It is 271 important to note that a given scope boundary always creates at least 272 two scoped regions: one on either side of the boundary. 274 In IPv4, administratively scoped regions are associated with a set of 275 addresses given by an address and a prefix length. In IPv6, 276 administratively scoped regions are associated with a set of addresses 277 given by a single scope ID value. The set of addresses corresponding to 278 a given scope ID value is defined in [5]. For example, a scope ID of 5 279 maps to the 16 IPv6 address ranges ff[0-f]5::/16. 281 There are certain topological restrictions on admin-scope regions. 282 Firstly, the scope zone border must be complete and convex. By this we 283 mean that there must be no path from inside the scoped zone to outside 284 it that does not pass through a configured scope border router, and that 285 the multicast capable path between any arbitrary pair of multicast 286 routers in the scope zone must remain in the zone. In addition, a 287 boundary for one scope must always be a boundary for all smaller scopes, 288 where a smaller scope for IPv4 is one whose address range is contained 289 within the other address range, and for IPv6 is one whose scope ID is 290 less than the other scope ID. 292 Administrative scoping complicates BSR because we do not want a PIM 293 router within the scoped region to use an RP outside the scoped region. 294 Thus we need to modify the basic mechanism to ensure that this doesn't 295 happen. 297 This is done by running a separate copy of the basic BSR mechanism, as 298 described in the previous section, within each admin scope region of a 299 PIM domain. Thus a separate BSR election takes place for each admin- 300 scope region, a C-RP typically registers to the BSR of every admin scope 301 zone it is in, and every PIM router receives Bootstrap messages for 302 every scope zone it is in. The Bootstrap messages sent by the BSR for a 303 particular scope zone contain information about the RPs that should be 304 used for the set of addresses associated with that scope zone. 306 Bootstrap messages are marked to indicate which scope zone they belong 307 to. Such admin scoped Bootstrap messages are flooded in the normal way, 308 but will not be forwarded by a ZBR across the boundary for that scope 309 zone. 311 For the BSR mechanism to function correctly with admin scoping, within 312 each admin scope region there must be at least one C-BSR, and at least 313 one C-RP that is configured to be a C-RP for the set of group addresses 314 associated with the scoped region. 316 Even when administrative scoping is used, a copy of the BSR mechanism is 317 still used across the entire PIM domain, in order to distribute RP 318 information for groups that are not administratively scoped. We call 319 this copy of the mechanism Non-Scoped BSR. The copies of the mechanism 320 run for each admin-scope region are called Scoped BSR. 322 Only the C-BSRs and the ZBRs need to be configured to know about the 323 existence of the scope zones. Other routers, including the C-RPs, learn 324 of their existence from Bootstrap messages. 326 All PIM routers within a PIM bootstrap domain where admin scope ranges 327 are in use must be capable of receiving Bootstrap messages and storing 328 the winning BSR and RP-Set for all admin scope zones that apply. Thus 329 PIM routers that only implement RFC 2362 or Non-Scoped BSR (which only 330 allows one BSR per domain) cannot be used within the admin-scope regions 331 of a PIM domain. 333 2. BSR State and Timers 335 A PIM router implementing BSR holds the following state. 337 RP-Set 339 Per Configured or Learned Scope Zone (Z): 341 At all routers: 343 Current Bootstrap Router's IP Address 345 Current Bootstrap Router's BSR Priority 347 Last BSM received from current BSR 349 Bootstrap Timer (BST(Z)) 351 Per group-to-RP mapping (M): 353 Group-to-RP mapping Expiry Timer (GET(M,Z)) 355 At a Candidate-BSR for Z: 357 My state: One of "Candidate-BSR", "Pending-BSR", 358 "Elected-BSR" 360 At a router that is not a Candidate-BSR for Z: 362 My state: One of "Accept Any", "Accept Preferred" 364 Scope-Zone Expiry Timer (SZT(Z)) 366 At the current Bootstrap Router for Z only: 368 Per group-to-C-RP mapping (M): 370 Group-to-C-RP mapping Expiry Timer (CGET(M,Z)) 372 At a C-RP only: 374 C-RP Advertisement Timer (CRPT) 376 3. Bootstrap Router Election and RP-Set Distribution 378 3.1. Bootstrap Router Election 380 For simplicity, Bootstrap messages are used in both the BSR election and 381 the RP-Set distribution mechanisms. 383 Each Bootstrap message indicates the scope that it belongs to. If the 384 Admin Scope Zone bit is set in the first group range in the Bootstrap 385 message, the message is called a scoped BSM. If the Admin Scope Zone 386 bit is not set in the first group range in the Bootstrap message, the 387 message is called a non-scoped BSM. 389 In a scoped IPv4 BSM, the scope of the message is given by the first 390 group range in the message, which can be any sub-range of 224/4. In a 391 scoped IPv6 BSM, the scope of the message is given by the scope ID of 392 the first group range in the message, which must have a mask length of 393 at least 16. For example, a group range of ff05::/16 with the Admin 394 Scope Zone bit set indicates that the Bootstrap message is for the scope 395 with scope ID 5. If the mask length of the first group range in a 396 scoped IPv6 BSM is less than 16, the message MUST be dropped and a 397 warning SHOULD is logged. 399 The state machine for Bootstrap messages depends on whether or not a 400 router has been configured to be a Candidate-BSR for a particular scope 401 zone. The per-scope-zone state machine for a C-BSR is given below, 402 followed by the state machine for a router that is not configured to be 403 a C-BSR. 405 3.1.1. Per-Scope-Zone Candidate-BSR State Machine 407 +-----------------------------------------------------------------------+ 408 | When in C-BSR state | 409 +-----------+------------------+--------------------+-------------------+ 410 | Event | Receive | Bootstrap | Receive Non- | 411 | | Preferred BSM | Timer Expires | preferred BSM | 412 | | | | from Elected | 413 | | | | BSR | 414 +-----------+------------------+--------------------+-------------------+ 415 | | -> C-BSR state | -> P-BSR state | -> P-BSR state | 416 | | Forward BSM; | Set Bootstrap | Set Bootstrap | 417 | Action | Store RP-Set; | Timer to | Timer to | 418 | | Set Bootstrap | BS_Rand_Override | BS_Rand_Override | 419 | | Timer to | | | 420 | | BS_Timeout | | | 421 +-----------+------------------+--------------------+-------------------+ 422 +-----------------------------------------------------------------------+ 423 | When in P-BSR state | 424 +------------+-------------------+-------------------+------------------+ 425 | Event | Receive | Bootstrap | Receive Non- | 426 | | Preferred BSM | Timer Expires | preferred BSM | 427 +------------+-------------------+-------------------+------------------+ 428 | | -> C-BSR state | -> E-BSR state | -> P-BSR state | 429 | | Forward BSM; | Originate BSM; | | 430 | Action | Store RP-Set; | Set Bootstrap | | 431 | | Set Bootstrap | Timer to | | 432 | | Timer to | BS_Period | | 433 | | BS_Timeout | | | 434 +------------+-------------------+-------------------+------------------+ 436 +-----------------------------------------------------------------------+ 437 | When in E-BSR state | 438 +------------+-------------------+-------------------+------------------+ 439 | Event | Receive | Bootstrap | Receive Non- | 440 | | Preferred BSM | Timer Expires | preferred BSM | 441 +------------+-------------------+-------------------+------------------+ 442 | | -> C-BSR state | -> E-BSR state | -> E-BSR state | 443 | | Forward BSM; | Originate BSM; | Originate BSM; | 444 | Action | Store RP-Set; | Set Bootstrap | Set Bootstrap | 445 | | Set Bootstrap | Timer to | Timer to | 446 | | Timer to | BS_Period | BS_Period | 447 | | BS_Timeout | | | 448 +------------+-------------------+-------------------+------------------+ 450 A Candidate-BSR may be in one of three states for a particular scope 451 zone: 453 Candidate-BSR (C-BSR) 454 The router is a candidate to be the BSR for the scope zone, but 455 currently another router is the preferred BSR. 457 Pending-BSR (P-BSR) 458 The router is a candidate to be the BSR for the scope zone. 459 Currently no other router is the preferred BSR, but this router is 460 not yet the elected BSR. This is a temporary state that prevents 461 rapid thrashing of the choice of BSR during BSR election. 463 Elected-BSR (E-BSR) 464 The router is the elected BSR for the scope zone and it must 465 perform all the BSR functions. 467 In addition to the three states, there is one timer: 469 o The Bootstrap Timer (BST) - used to time out old bootstrap router 470 information, and used in the election process to terminate P-BSR 471 state. 473 On startup, the initial state for this configured scope zone is 474 "Pending-BSR"; the Bootstrap Timer is initialized to the BS_Timeout 475 value. 477 3.1.2. Per-Scope-Zone State Machine for Non-Candidate-BSR Routers 479 +-----------------------------------------------------------------------+ 480 | When in NoInfo state | 481 +---------------------+-------------------------------------------------+ 482 | Event | Receive BSM | 483 +---------------------+-------------------------------------------------+ 484 | | -> AP state | 485 | Action | Forward BSM; Store RP-Set; | 486 | | Set Bootstrap Timer to BS_Timeout; | 487 | | Set SZT to SZ_Timeout | 488 +---------------------+-------------------------------------------------+ 490 +-----------------------------------------------------------------------+ 491 | When in Accept Any state | 492 +---------------+----------------------------+--------------------------+ 493 | Event | Receive BSM | Scope-Zone Expiry | 494 | | | Timer Expires | 495 +---------------+----------------------------+--------------------------+ 496 | | -> AP state | -> NoInfo state | 497 | | Forward BSM; Store | Cancel timers; | 498 | Action | RP-Set; Set | Clear state | 499 | | Bootstrap Timer to | | 500 | | BS_Timeout; Set | | 501 | | SZT to SZ_Timeout | | 502 +---------------+----------------------------+--------------------------+ 503 +-----------------------------------------------------------------------+ 504 | When in Accept Preferred state | 505 +----------+-----------------------+------------------+-----------------+ 506 | Event | Receive Preferred | Bootstrap | Receive Non- | 507 | | BSM | Timer Expires | preferred BSM | 508 +----------+-----------------------+------------------+-----------------+ 509 | | -> AP state | -> AA state | -> AP state | 510 | | Forward BSM; Store | Refresh RP- | | 511 | Action | RP-Set; Set | Set; Remove | | 512 | | Bootstrap Timer to | BSR state | | 513 | | BS_Timeout; Set SZT | | | 514 | | to SZ_Timeout | | | 515 +----------+-----------------------+------------------+-----------------+ 516 A router that is not a Candidate-BSR may be in one of three states: 518 NoInfo 519 The router has no information about this scope zone. This state 520 does not apply if the router is configured to know about this scope 521 zone, or for the global scope zone. When in this state, no state 522 information is held and no timers run that refer to this scope 523 zone. 525 Accept Any (AA) 526 The router does not know of an active BSR, and will accept the 527 first Bootstrap message it sees as giving the new BSR's identity 528 and the RP-Set. 530 Accept Preferred (AP) 531 The router knows the identity of the current BSR, and is using the 532 RP-Set provided by that BSR. Only Bootstrap messages from that BSR 533 or from a C-BSR with higher weight than the current BSR will be 534 accepted. 536 In addition to the three states, there are two timers: 538 o The Bootstrap Timer (BST) - used to time out old bootstrap router 539 information. 541 o The Scope-Zone Expiry Timer (SZT) - used to time out the scope zone 542 itself if Bootstrap messages specifying this scope zone stop arriving. 544 On startup, the initial state for this scope zone is "Accept Any" for 545 routers that know about this scope zone, either through configuration or 546 because the scope zone is the global scope which always exists; the 547 Scope-Zone Expiry Timer is considered to be always running for such 548 scope zones. For routers that do not know about a particular scope 549 zone, the initial state is NoInfo; no timers exist for the scope zone. 551 3.1.3. Bootstrap Message Processing Checks 553 When a Bootstrap message is received, the following initial checks must 554 be performed: 556 if ((DirectlyConnected(BSM.src_ip_address) == FALSE) OR 557 (we have no Hello state for BSM.src_ip_address)) { 558 drop the Bootstrap message silently 559 } 561 if (BSM.dst_ip_address == ALL-PIM-ROUTERS) { 562 if (BSM.src_ip_address != RPF_neighbor(BSM.BSR_ip_address)) { 563 drop the Bootstrap message silently 564 } 565 } else if (BSM.dst_ip_address is one of my addresses) { 566 if ((any previous BSM for this scope has been accepted) OR 567 (more than BS_Period has elapsed since startup)) { 568 #the packet was unicast, but this wasn't 569 #a quick refresh on startup 570 drop the Bootstrap message silently 571 } 572 } else { 573 drop the Bootstrap message silently 574 } 576 if (the interface the message arrived on is an Admin Scope 577 border for the BSM.first_group_address) { 578 drop the Bootstrap message silently 579 } 581 Basically, the packet must have come from a directly connected neighbor 582 for which we have active Hello state. It must have been sent to the 583 ALL-PIM-ROUTERS group by the correct upstream router towards the BSR 584 that originated the Bootstrap message, or the router must have recently 585 restarted, have no BSR state for that admin scope and have received the 586 Bootstrap message by unicast. In addition it must not have arrived on 587 an interface that is a configured admin scope border for the first group 588 address contained in the Bootstrap message. 590 3.1.4. State Machine Transition Events 592 If the Bootstrap message passes the initial checks above without being 593 discarded, then it may cause a state transition event in one of the 594 above state machines. For both candidate and non-candidate BSRs, the 595 following transition events are defined: 597 Receive Preferred BSM 598 A Bootstrap message is received from a BSR that has higher or 599 equal weight than the current BSR. If a router is in P-BSR 600 state, then it uses its own weight as that of the current BSR. 602 The weight of a BSR is defined to be the concatenation in 603 fixed-precision unsigned arithmetic of the BSR Priority field 604 from the Bootstrap message and the IP address of the BSR from 605 the Bootstrap message (with the BSR Priority taking the most- 606 significant bits and the IP address taking the least 607 significant bits). 609 Receive Non-preferred BSM 610 A Bootstrap message is received from a BSR that has lower 611 weight than the current BSR. If a router is in P-BSR state, 612 then it uses its own weight as that of the current BSR. 614 Receive Non-preferred BSM from Elected BSR 615 A Bootstrap message is received from the elected BSR, but the 616 BSR Priority field in the received message has changed, so 617 that now the currently elected BSR has lower weight that the 618 router itself. 620 Receive BSM 621 A Bootstrap message is received, regardless of BSR weight. 623 In addition to state machine transitions caused by the receipt of 624 Bootstrap messages, a state machine transition takes place each time the 625 Bootstrap Timer or Scope-Zone Expiry Timer expires. 627 3.1.5. State Machine Actions 629 The state machines specify actions that include setting the Bootstrap 630 Timer and the Scope-Zone Expiry Timer to various values. These values 631 are defined in Section 5. 633 In addition to setting and cancelling the timers, the following actions 634 may be triggered by state changes in the state machines: 636 Forward BSM 637 A Bootstrap message that passes the Bootstrap Message 638 Processing Checks is forwarded out of all interfaces with PIM 639 neighbors (including the interface it is received on), except 640 where this would cause the BSM to cross an admin-scope 641 boundary for the scope zone indicated in the message. For 642 details, see section 3.4. 644 Originate BSM 645 A new Bootstrap message is constructed by the BSR, giving the 646 BSR's address and BSR priority, and containing the BSR's 647 chosen RP-Set. The message is forwarded out of all multicast- 648 capable interfaces, except where this would cause the BSM to 649 cross an admin-scope boundary for the scope zone indicated in 650 the message. 652 Store RP-Set 653 The router uses the group-to-RP mappings contained in a BSM to 654 update its local RP-Set. 656 If a mapping does not yet exist, it is created and the 657 associated Group-to-RP mapping Expiry Timer (GET) is 658 initialized with the holdtime from the BSM. 660 If a mapping already exists, its GET is set to the holdtime 661 from the BSM. If the holdtime is zero, the mapping is removed 662 immediately. 664 All RP mappings associated with the scope zone of the BSM are 665 updated with the new hash mask length from the received BSM. 666 This includes any RP mappings learned from the current BSR but 667 not contained in the received BSM, as well as any RP mappings 668 learned from any previous BSR for the scope zone. 670 In addition, the entire BSM is stored for use in the action 671 Refresh RP-Set and to prime a new PIM neighbor as described 672 below. 674 Refresh RP-Set 675 When the Bootstrap Timer expires, the router uses the copy of 676 the last BSM that it has received to refresh its RP-Set 677 according to the action Store RP-Set as if it had just 678 received it. This will increase the chance that the group-to- 679 RP mappings will not expire during the election of the new 680 BSR. 682 Remove BSR state 683 When the Bootstrap Timer expires, all state associated with 684 the current BSR is removed (see section 2). Note that this 685 does not include any group-to-RP mappings. 687 3.2. Sending Candidate-RP-Advertisement Messages 689 Every C-RP periodically unicasts a C-RP-Adv message to the BSR for each 690 scope zone for which it has state, to inform the BSR of the C-RP's 691 willingness to function as an RP. These messages are sent with an 692 interval of C_RP_Adv_Period. 694 [NOTE: possible optimization: prime the CRPT with a small random value 695 when a new BSR is elected. This will allow the newly elected BSR to 696 learn group mappings fast.] 698 [NOTE: what happens if the message becomes too large to fit in a single 699 packet? With the per-mapping timers, it's not a problem to send several 700 advertisements. We need to say something about this.] 702 The Priority field in these messages is used by the BSR to select which 703 C-RPs to include in the RP-Set. Note that lower values of this field 704 indicate higher priorities, so that a value of zero is the highest 705 possible priority. C-RPs should by default send C-RP-Adv messages with 706 the Priority field set to 192. 708 When a C-RP is being shut down, it SHOULD immediately send a C-RP-Adv 709 message to the BSR for each scope zone for which it is currently serving 710 as an RP; the Holdtime in this C-RP-Adv message should be zero. The BSR 711 will then immediately time out the C-RP and generate a new Bootstrap 712 message removing the shut down RP from the RP-Set. 714 [NOTE: Should a new BSM be sent immediately when a C-RP-Adv message with 715 Holdtime of 0 is received? Need to clarify.] 717 A C-RP-Adv message carries a list of group address and group mask field 718 pairs. This enables the C-RP to specify the group prefixes for which it 719 is willing to be the RP. If the C-RP becomes an RP, it may enforce this 720 scope acceptance when receiving Register or Join/Prune messages. 722 A C-RP is configured with a list of group ranges for which it should 723 advertise itself as the C-RP. A C-RP uses the following algorithm to 724 determine which ranges to send to a given BSR. 726 For each group range R in the list, the C-RP advertises that range to 727 the scoped BSR for the smallest scope that "contains" R. For IPv6, the 728 containing scope is determined by matching the scope identifier of the 729 group range with the scope of the BSR. For IPv4, it is the longest- 730 prefix match for R, amongst the known admin-scope ranges. If no scope 731 is found to contain the group range the C-RP includes it in the C-RP-Adv 732 sent to the non-scoped BSR. If a non-scoped BSR is not known, the range 733 is not included in any C-RP-Adv. 735 In addition, for each IPv4 group range R in the list, for each scoped 736 BSR whose scope range is strictly contained within R, the C-RP SHOULD by 737 default advertise that BSR's scope range to that BSR. And for each IPv6 738 group range R in the list with prefix length < 16, the C-RP SHOULD by 739 default advertise each sub-range of prefix length 16 to the scoped BSR 740 with the corresponding scope ID. An implementation MAY supply a 741 configuration option to prevent the behavior described in this 742 paragraph, but such an option SHOULD be disabled by default. 744 For IPv6, the mask length of all group ranges included in the C-RP-Adv 745 message sent to a scoped BSR MUST be >= 16. 747 If the above algorithm determines that there are no group ranges to 748 advertise to the BSR for a particular scope zone, a C-RP-Adv message 749 MUST NOT be sent to that BSR. A C-RP MUST NOT send a C-RP-Adv message 750 with no group ranges in it. 752 If the same router is the BSR for more than one scope zone, the C-RP-Adv 753 messages for these scope zones MAY be combined into a single message. 755 If the C-RP is a ZBR for an admin scope zone, then the Admin Scope Zone 756 bit MUST be set in the C-RP-Adv messages it sends for that scope zone; 757 otherwise this bit MUST NOT be set. This information is currently only 758 used for logging purposes by the BSR, but might allow for future 759 extensions of the protocol. 761 3.3. Creating the RP-Set at the BSR 763 Upon receiving a C-RP-Adv message, the router needs to decide whether or 764 not to accept each of the group ranges included in the message. For 765 each group range in the message, the router checks to see if it is the 766 elected BSR for any scope zone that contains the group range, or if it 767 is elected as the non-scoped BSR. If so, the group range is accepted; 768 if not, the group range is ignored. 770 If the group range is accepted, a group-to-C-RP mapping is created for 771 this group range and the RP Address from the C-RP-Adv message. 773 If the mapping is not already part of the C-RP-Set, it is added to the 774 C-RP-Set and the associated Group-to-C-RP mapping Expiry Timer (CGET) is 775 initialized to the holdtime from the C-RP-Adv message. Its priority is 776 set to the Priority from the C-RP-Adv message. 778 If the mapping is already part of the C-RP-Set, it is updated with the 779 Priority from the C-RP-Adv message and its associated CGET is reset to 780 the holdtime from the C-RP-Adv message. If the holdtime is zero, the 781 mapping is immediately removed from the C-RP-Set. 783 The hash mask length is a global property of the BSR and is therefore 784 the same for all mappings managed by the BSR. 786 [NOTE: This is substantially different from version 03, where state was 787 kept per C-RP. The behaviour is the same if a C-RP always sends all 788 advertisements in a single message. However, there seems to be no 789 requirement for this (and the case where all advertisements don't fit in 790 a single message seems not to be covered). Keeping state per group 791 mapping allows a C-RP to send C-RP-Adv messages in chunks and even 792 allows for different holdtimes for different group ranges (which may or 793 may not be useful) while being compatible with the old version.] 795 For compatibility with the previous version of the BSR specification, a 796 C-RP-Adv message with no group ranges SHOULD be treated as though it 797 contained the single group range ff00::/8 or 224/4. Therefore, 798 according to the rule above, this group range will be accepted if and 799 only if the router is elected as the non-scoped BSR. 801 When a CGET expires, the corresponding group-to-C-RP mapping is removed 802 from the C-RP-Set. 804 The BSR constructs the RP-Set from the C-RP-Set. It may apply a local 805 policy to limit the number of Candidate-RPs included in the RP-Set. The 806 BSR may override the prefix indicated in a C-RP-Adv message unless the 807 `Priority' field from the C-RP-Adv message is less than 128. 809 For inclusion in a BSM, the RP-Set is subdivided into sets of {group- 810 prefix, RP-Count, RP-addresses}. For each RP-address, the corresponding 811 Holdtime is included in the "RP-Holdtime" field. The format of the 812 Bootstrap message allows `semantic fragmentation', if the length of the 813 original Bootstrap message exceeds the packet maximum boundaries. 814 However, we recommend against configuring a large number of routers as 815 C-RPs, to reduce the semantic fragmentation required. 817 A BSR originates separate scoped BSMs for each scope zone for which it 818 is the elected BSR, as well as originating non-scoped BSMs if it is the 819 elected non-scoped BSR. 821 Each group-to-C-RP mapping is included in precisely one of these BSM, 822 namely the scoped BSM for the narrowest scope containing the group range 823 of the mapping, if any, or the non-scoped BSM otherwise. 825 A scoped BSM MUST have at least one group range, and the first group 826 range in a scoped BSM MUST have the "Admin Scope Zone" bit set. This 827 group range identifies the scope of the BSM. In a scoped IPv4 BSM, the 828 first group range is the range corresponding to the scope of the BSM. 829 In a scoped IPv6 BSM, the first group range may be any group range 830 subject to the general condition that all the group ranges in such a BSM 831 MUST have a mask length of at least 16 and MUST have the same scope ID 832 as the scope of the BSM. 834 RP mappings may be included in the first group range of a BSM, just as 835 for any other group range. After this group range, other group ranges 836 for which there are RP mappings appear in any order. 838 The "Admin Scope Zone" bit of all group ranges other than the first 839 SHOULD be set to 0 on origination, and MUST be ignored on receipt. 841 When an elected BSR is being shut down, it should immediately originate 842 a Bootstrap message listing its current RP-Set, but with the BSR 843 Priority field set to the lowest priority value possible. This will 844 cause the election of a new BSR to happen more quickly. 846 3.4. Forwarding Bootstrap Messages 848 Bootstrap messages originate at the BSR, and are hop-by-hop forwarded by 849 intermediate routers if they pass the Bootstrap Message Processing 850 Checks. When a Bootstrap message is forwarded, it is forwarded out of 851 every multicast-capable interface which has PIM neighbors (including the 852 one over which the message was received). The exception to this is if 853 the interface is an administrative scope boundary for the admin scope 854 zone indicated in the first group address in the Bootstrap message 855 packet. 857 As an optimization, a router MAY choose not to forward a BSM out of the 858 interface the message was received on if that interface is a point-to- 859 point interface. On interfaces with multiple PIM neighbors, a router 860 SHOULD forward an accepted BSM onto the interface that BSM was received 861 on, but if the number of PIM neighbors on that interface is large, it 862 MAY delay forwarding a BSM onto that interface by a small randomized 863 interval to prevent message implosion. A configuration option MAY be 864 provided to disable forwarding onto the interface a message was received 865 on, but we recommend that the default behavior is to forward onto that 866 interface. 868 Rationale: A BSM needs to be forwarded onto the interface the message 869 was received on (in addition to the other interfaces) because the 870 routers on a LAN may not have consistent routing information. If three 871 routers on a LAN are A, B, and C, and at router B RPF(BSR)==A and at 872 router C RPF(BSR)==B, then router A originally forwards the BSM onto the 873 LAN, but router C will only accept it when router B re-forwards the 874 message onto the LAN. If the underlying routing protocol configuration 875 guarantees that the routers have consistent routing information, then 876 forwarding onto the incoming interface may safely be disabled. 878 A ZBR constrains all BSMs which are of equal or smaller scope than the 879 configured boundary. That is, the BSMs are not accepted from, 880 originated or forwarded on the interfaces on which the boundary is 881 configured. For IPv6 the check is a comparison between the scope of the 882 first range in the scoped BSM and the scope of the configured boundary. 883 For IPv4, the first range in the scoped BSM is checked to see if it is 884 contained in or is the same as the range of the configured boundary. 886 3.5. Unicasting Bootstrap Messages to New and Rebooting Routers 888 To allow new or rebooting routers to learn the RP-Set quickly, when a 889 Hello message is received from a new neighbor, or a Hello message with a 890 new GenID is received from an existing neighbor, one router on the LAN 891 unicasts a stored copy of the Bootstrap message for each admin scope 892 zone to the new or rebooting router. 894 The router that does this is the Designated Router (DR) on the LAN, or, 895 if the new or rebooting router is the DR, the router that would be the 896 DR if the new or rebooting router were excluded from the DR election 897 process. 899 Before unicasting a Bootstrap message in this manner, the DR must wait 900 until it has sent a triggered Hello message on this interface; 901 otherwise, the new neighbor will discard the Bootstrap message. 903 3.6. Receiving and Using the RP-Set 905 The RP-Set maintained by BSR is used by RP-based multicast routing 906 protocols like PIM-SM and BIDIR-PIM. These protocols may obtain RP-Sets 907 from other sources as well. How the final group-to-RP mappings are 908 obtained from these RP-Sets is not part of the BSR specification. In 909 general, the routing protocols need to re-calculate the mappings when 910 any of their RP-Sets change. How such a change is signalled to the 911 routing protocol is also not part of the present specification. 913 Some group-to-RP mappings in the RP-Set indicate group ranges for which 914 PIM-SM should be used; others indicate group ranges for use with BIDIR- 915 PIM. Routers that only support one of these protocols MUST NOT ignore 916 ranges indicated as being for the other protocol. They MUST NOT treat 917 them as being for the protocol they support. 919 4. Message Formats 921 BSR messages are PIM messages, as defined in [1]. The values of the PIM 922 Message Type field for BSR messages are: 924 4 Bootstrap 926 8 Candidate-RP-Advertisement 928 As with all other PIM control messages, BSR messages have IP protocol 929 number 103. 931 Candidate-RP-Advertisement messages are unicast to a BSR. Usually, 932 Bootstrap messages are multicast with TTL 1 to the ALL-PIM-ROUTERS 933 group, but in some circumstances (described in section 3.5) Bootstrap 934 messages are unicast to a specific PIM neighbor. 936 The IP source address used for Candidate-RP-Advertisement messages is a 937 domain-wide reachable address. The IP source address used for Bootstrap 938 messages (regardless of whether they are being originated or forwarded) 939 is the link-local address of the interface on which the message is being 940 sent (that is, the same source address that the router uses for the 941 Hello messages it sends out that interface). 943 All Bootstrap and Candidate-RP-Advertisement messages SHOULD carry the 944 Router Alert IP option. See section 6 for information about the way in 945 which the Router Alert option is checked by receving routers. 947 The IPv4 ALL-PIM-ROUTERS group is 224.0.0.13. The IPv6 ALL-PIM-ROUTERS 948 group is ff02::d. 950 In this section we use the following terms defined in the PIM-SM 951 specification [1]: 953 o Encoded-Unicast format 955 o Encoded-Group format 957 We repeat these here to aid readability. 959 Encoded-Unicast address 961 An Encoded-Unicast address takes the following format: 963 0 1 2 3 964 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | Addr Family | Encoding Type | Unicast Address 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 969 Addr Family 970 The PIM address family of the `Unicast Address' field of this 971 address. 973 Values of 0-127 are as assigned by the IANA for Internet Address 974 Families in [10]. Values 128-250 are reserved to be assigned by 975 the IANA for PIM-specific Address Families. Values 251 though 255 976 are designated for private use. As there is no assignment 977 authority for this space, collisions should be expected. 979 Encoding Type 980 The type of encoding used within a specific Address Family. The 981 value `0' is reserved for this field, and represents the native 982 encoding of the Address Family. 984 Unicast Address 985 The unicast address as represented by the given Address Family and 986 Encoding Type. 988 Encoded-Group address 990 Encoded-Group addresses take the following format: 992 0 1 2 3 993 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 995 | Addr Family | Encoding Type |B| Reserved |Z| Mask Len | 996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 997 | Group multicast Address 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 1000 Addr Family 1001 described above. 1003 Encoding Type 1004 described above. 1006 [B]IDIR bit 1007 When set, all BIDIR capable PIM routers will operate the protocol 1008 described in [2] for the specified group range. 1010 Reserved 1011 Transmitted as zero. Ignored upon receipt. 1013 Admin Scope [Z]one 1014 When set, this bit indicates that this group address range is an 1015 administratively scoped range. 1017 Mask Len 1018 The Mask length field is 8 bits. The value is the number of 1019 contiguous one bits left justified used as a mask which, combined 1020 with the group address, describes a range of groups. It is less 1021 than or equal to the address length in bits for the given Address 1022 Family and Encoding Type. If the message is sent for a single 1023 group then the Mask length must equal the address length in bits 1024 for the given Address Family and Encoding Type. (e.g. 32 for IPv4 1025 native encoding and 128 for IPv6 native encoding). 1027 Group multicast Address 1028 Contains the group address. 1030 4.1. Bootstrap Message Format 1032 A Bootstrap message is divided up into `semantic fragments' if the 1033 original message exceeds the maximum packet size boundaries. Basically, 1034 a single Bootstrap message can be sent as multiple packets (semantic 1035 fragments), so long as the fragment tags of all the packets comprising 1036 the message is the same. 1038 If the Bootstrap message contains information about more than one admin 1039 scope zone, each different scope zone MUST occupy a different semantic 1040 fragment. This allows Zone Border Routers for an admin scope zone to 1041 not forward only those fragments that should not traverse the admin 1042 scope boundary. 1044 The format of a single `fragment' is given below: 1046 0 1 2 3 1047 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 |PIM Ver| Type | Reserved | Checksum | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | Fragment Tag | Hash Mask Len | BSR Priority | 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | BSR Address (Encoded-Unicast format) | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | Group Address 1 (Encoded-Group format) | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | RP Count 1 | Frag RP Cnt 1 | Reserved | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | RP Address 1 (Encoded-Unicast format) | 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 | RP1 Holdtime | RP1 Priority | Reserved | 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | RP Address 2 (Encoded-Unicast format) | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | RP2 Holdtime | RP2 Priority | Reserved | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | . | 1068 | . | 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 | RP Address m (Encoded-Unicast format) | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 | RPm Holdtime | RPm Priority | Reserved | 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 | Group Address 2 (Encoded-Group format) | 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | . | 1077 | . | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | Group Address n (Encoded-Group format) | 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | RP Count n | Frag RP Cnt n | Reserved | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | RP Address 1 (Encoded-Unicast format) | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 | RP1 Holdtime | RP1 Priority | Reserved | 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 | RP Address 2 (Encoded-Unicast format) | 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 | RP2 Holdtime | RP2 Priority | Reserved | 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 | . | 1092 | . | 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | RP Address m (Encoded-Unicast format) | 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 | RPm Holdtime | RPm Priority | Reserved | 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 PIM Version, Reserved, Checksum 1100 Described in [1]. 1102 Type 1103 PIM Message Type. Value is 4 for a Bootstrap message. 1105 Fragment Tag 1106 A randomly generated number, acts to distinguish the fragments 1107 belonging to different Bootstrap messages; fragments belonging to 1108 same Bootstrap message carry the same `Fragment Tag'. 1110 Hash Mask Len 1111 The length (in bits) of the mask to use in the hash function. For 1112 IPv4 we recommend a value of 30. For IPv6 we recommend a value of 1113 126. This field SHOULD be the same for all fragments belonging to 1114 the same Bootstrap message. 1116 BSR Priority 1117 Contains the BSR priority value of the included BSR. This field is 1118 considered as a high order byte when comparing BSR addresses. Note 1119 that for historical reasons, the highest BSR priority is 255 (the 1120 higher the better), whereas the highest RP Priority (see below) is 1121 0 (the lower the better). 1123 BSR Address 1124 The address of the bootstrap router for the domain. The format for 1125 this address is given in the Encoded-Unicast address in [1]. 1127 Group Address 1..n 1128 The group prefix (address and mask) with which the Candidate-RPs 1129 are associated. Format described in [1]. In an fragment 1130 containing admin scope ranges, the first group address in the 1131 fragment MUST satisfy the following conditions: it MUST have the 1132 Admin Scope bit set; for IPv4 it MUST be the group range for the 1133 entire admin scope range; for IPv6 the Mask Len MUST be at least 16 1134 and have the scope ID of the admin scope range. This is the case 1135 even if there are no RPs in the RP-Set for the entire admin scope 1136 range - in this case the sub-ranges for the RP-Set are specified 1137 later in the fragment along with their RPs. 1139 RP Count 1..n 1140 The number of Candidate-RP addresses included in the whole 1141 Bootstrap message for the corresponding group prefix. A router 1142 does not replace its old RP-Set for a given group prefix 1143 until/unless it receives `RP-Count' addresses for that prefix; the 1144 addresses could be carried over several fragments. If only part of 1145 the RP-Set for a given group prefix was received, the router 1146 discards it, without updating that specific group prefix's RP-Set. 1148 Frag RP Cnt 1..m 1149 The number of Candidate-RP addresses included in this fragment of 1150 the Bootstrap message, for the corresponding group prefix. The 1151 `Frag RP Cnt' field facilitates parsing of the RP-Set for a given 1152 group prefix, when carried over more than one fragment. 1154 RP address 1..m 1155 The address of the Candidate-RPs, for the corresponding group 1156 prefix. The format for these addresses is given in the Encoded- 1157 Unicast address in [1]. 1159 RP1..m Holdtime 1160 The Holdtime (in seconds) for the corresponding RP. This field is 1161 copied from the `Holdtime' field of the associated RP stored at the 1162 BSR. 1164 RP1..m Priority 1165 The `Priority' of the corresponding RP and Encoded-Group Address. 1166 This field is copied from the `Priority' field stored at the BSR 1167 when receiving a C-RP-Adv message. The highest priority is `0' 1168 (i.e. unlike BSR priority, the lower the value of the `Priority' 1169 field, the better). Note that the priority is per RP per Group 1170 Address. 1172 Within a Bootstrap message, the BSR Address, all the Group Addresses and 1173 all the RP Addresses MUST be of the same address family. In addition, 1174 the address family of the fields in the message MUST be the same as the 1175 IP source and destination addresses of the packet. This permits maximum 1176 implementation flexibility for dual-stack IPv4/IPv6 routers. 1178 4.1.1. Semantic Fragmentation of BSMs 1180 Bootstrap messages may be split over several PIM Bootstrap Message 1181 Fragment (BSMF) packets; this is known as semantic fragmentation. There 1182 are two reasons for semantic fragmentation: 1184 o The BSM would exceed the link MTU the packet will be forwarded 1185 over. 1187 o The BSM includes information about more than one admin scope zone. 1189 Let us initially consider only the former case; the packet would be too 1190 large because the set of group prefixes and the RPs for each group 1191 prefix are too long to fit in one packet. The BSR will then split the 1192 BSM across several BSMF packets; each of these must be a well-formed 1193 BSMF packet in its own right. 1195 If the BSR can split up the BSM so that different group prefixes (and 1196 their RP information) can fit in different fragments, then it should do 1197 so. If one of these BSMF packets is then lost, the state from the 1198 previous BSM for the group-prefix from the missing packet will be 1199 retained. Each fragment that does arrive will update the RP information 1200 for the group-prefixes contained in that fragment, and the new group-to- 1201 RP mapping for those can be used immediately. The information from the 1202 missing fragment will be obtained when the BSM is next transmitted. In 1203 this case, whilst the Fragment Tag must be set to the same value for all 1204 BSMFs comprising a single BSM, the tag is not actually used by routers 1205 receiving the BSM. 1207 If the list of RPs for a single group-prefix is too long to fit in a 1208 single BSMF packet, then that information must be split across multiple 1209 BSMF packets. In this case, all the BSMF packets comprising the 1210 information for that group-prefix must be received before the group-to- 1211 RP mapping in use can be modified. This is the purpose of the RP Count 1212 field - a router receiving BSMF packets from the same BSM (ie that have 1213 the same fragment tag) must wait until the BSMFs providing RP Count RPs 1214 for that group-prefix have been received before the new group-to-RP 1215 mapping can be used for that group-prefix. If a single BSMF from such a 1216 large group-prefix is lost, then that entire group-prefix will have to 1217 wait until the next BSM is originated. 1219 Next we need to consider how a BSR would remove group-prefixes from the 1220 BSM. A router receiving a set of BSMFs cannot tell if a group-prefix is 1221 missing. If it has seen a group-prefix before, it must assume that that 1222 group-prefix still exists, and that the BSMF describing it has been 1223 lost. It should retain this information for BS_Timeout. Thus for a BSR 1224 to remove a group-prefix from the BSR, it should include that group- 1225 prefix, but with a RP Count of zero, and it should resend this 1226 information in each BSM for BS_Timeout. 1228 Finally, we come to the case of fragments for the purpose of conveying 1229 admin scope group-prefixes. In general, the information for each admin 1230 scope range is independent of information about other admin scope 1231 ranges. As no BSMF is allowed to convey information for more than one 1232 admin scope range, then the procedure above also applies to BSMs that 1233 are fragmented due to admin scoping. However, to time out all the state 1234 for an entire admin scope zone requires waiting SZ_Timeout rather than 1235 BS_Timeout, as admin scope zones are not expected to come and go 1236 frequently. 1238 4.2. Candidate-RP-Advertisement Message Format 1240 Candidate-RP-Advertisement messages are periodically unicast from the C- 1241 RPs to the BSR. 1243 0 1 2 3 1244 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 |PIM Ver| Type | Reserved | Checksum | 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1248 | Prefix Count | Priority | Holdtime | 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 | RP Address (Encoded-Unicast format) | 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 | Group Address 1 (Encoded-Group format) | 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 | . | 1255 | . | 1256 | . | 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 | Group Address n (Encoded-Group format) | 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 PIM Version, Reserved, Checksum 1262 Described in [1]. 1264 Type 1265 PIM Message Type. Value is 8 for a Candidate-RP-Advertisement 1266 message. 1268 Prefix Count 1269 The number of encoded group addresses included in the message; 1270 indicating the group prefixes for which the C-RP is advertising. 1271 C-RPs MUST NOT send C-RP-Adv messages with a Prefix Count of `0'. 1273 Priority 1274 The `Priority' of the included RP, for the corresponding Encoded- 1275 Group Address (if any). The highest priority is `0' (i.e. the 1276 lower the value of the `Priority' field, the higher the priority). 1277 This field is stored at the BSR upon receipt along with the RP 1278 address and corresponding Encoded-Group Address. 1280 Holdtime 1281 The amount of time (in seconds) the advertisement is valid. This 1282 field allows advertisements to be aged out. This field should be 1283 set to 2.5 times C_RP_Adv_Period. 1285 RP Address 1286 The address of the interface to advertise as a Candidate RP. The 1287 format for this address is given in the Encoded-Unicast address in 1288 [1]. 1290 Group Address-1..n 1291 The group prefixes for which the C-RP is advertising. Format 1292 described in Encoded-Group-Address in [1]. 1294 Within a Candidate-RP-Advertisement message, the RP Address and all the 1295 Group Addresses MUST be of the same address family. In addition, the 1296 address family of the fields in the message MUST be the same as the IP 1297 source and destination addresses of the packet. This permits maximum 1298 implementation flexibility for dual-stack IPv4/IPv6 routers. 1300 5. Timers and Timer Values 1302 Timer Name: Bootstrap Timer (BST(Z)) 1304 +---------------------+--------------------------+----------------------+ 1305 | Value Name | Value | Explanation | 1306 +---------------------+--------------------------+----------------------+ 1307 | BS_Period | Default: 60 seconds | Periodic interval | 1308 | | | with which BSMs | 1309 | | | are normally | 1310 | | | originated | 1311 +---------------------+--------------------------+----------------------+ 1312 | BS_Timeout | Default: 130 seconds | Interval after | 1313 | | | which a BSR is | 1314 | | | timed out if no | 1315 | | | BSM is received | 1316 | | | from that BSR | 1317 +---------------------+--------------------------+----------------------+ 1318 | BS_Rand_Override | see below | Randomized | 1319 | | | interval used to | 1320 | | | reduce control | 1321 | | | message overhead | 1322 | | | during BSR | 1323 | | | election | 1324 +---------------------+--------------------------+----------------------+ 1326 Note that BS_Timeout MUST be larger than BS_Period, even if their values 1327 are changed from the defaults. We recommend that BS_Timeout is set to 2 1328 times BS_Period plus 10 seconds. 1330 BS_Rand_Override is calculated using the following pseudocode, in which 1331 all values are in units of seconds. The values of BS_Rand_Override 1332 generated by this pseudocode are between 5 and 23 seconds, with smaller 1333 values generated if the C-BSR has a high bootstrap weight, and larger 1334 values generated if the C-BSR has a low bootstrap weight. 1336 BS_Rand_Override = 5 + priorityDelay + addrDelay 1338 where priorityDelay is given by: 1340 priorityDelay = 2 * log_2(1 + bestPriority - myPriority) 1342 and addrDelay is given by the following for IPv4: 1344 if (bestPriority == myPriority) { 1345 addrDelay = log_2(1 + bestAddr - myAddr) / 16 1346 } else { 1347 addrDelay = 2 - (myAddr / 2^31) 1348 } 1350 and addrDelay is given by the following for IPv6: 1352 if (bestPriority == myPriority) { 1353 addrDelay = log_2(1 + bestAddr - myAddr) / 64 1354 } else { 1355 addrDelay = 2 - (myAddr / 2^127) 1356 } 1358 and bestPriority is given by: 1360 bestPriority = max(storedPriority, myPriority) 1362 and bestAddr is given by: 1364 bestAddr = max(storedAddr, myAddr) 1366 and where myAddr is the Candidate-BSR's address, storedAddr is the 1367 stored BSR's address, myPriority is the Candidate-BSR's configured 1368 priority, and storedPriority is the stored BSR's priority. 1370 Timer Name: Scope Zone Expiry Timer (SZT(Z)) 1372 +----------------+-----------------------------+------------------------+ 1373 | Value Name | Value | Explanation | 1374 +----------------+-----------------------------+------------------------+ 1375 | SZ_Timeout | Default: 1300 seconds | Interval after | 1376 | | | which a scope zone | 1377 | | | is timed out if no | 1378 | | | BSM is received | 1379 | | | for that scope | 1380 | | | zone | 1381 +----------------+-----------------------------+------------------------+ 1383 Note that SZ_Timeout MUST be larger than BS_Timeout, even if their 1384 values are changed from the defaults. We recommend that SZ_Timeout is 1385 set to 10 times BS_Timeout. 1387 Timer Name: Group-to-C-RP mapping Expiry Timer (CGET(M,Z)) 1389 +--------------------------+--------------------+-----------------------+ 1390 | Value Name | Value | Explanation | 1391 +--------------------------+--------------------+-----------------------+ 1392 | C-RP Mapping Timeout | from message | Holdtime from C- | 1393 | | | RP-Adv message | 1394 +--------------------------+--------------------+-----------------------+ 1396 Timer Name: Group-to-RP mapping Expiry Timer (GET(M,Z)) 1398 +-------------------------+--------------------+------------------------+ 1399 | Value Name | Value | Explanation | 1400 +-------------------------+--------------------+------------------------+ 1401 | RP Mapping Timeout | from message | Holdtime from BSM | 1402 +-------------------------+--------------------+------------------------+ 1404 Timer Name: C-RP Advertisement Timer (CRPT) 1406 +---------------------+-------------------------+-----------------------+ 1407 | Value Name | Value | Explanation | 1408 +---------------------+-------------------------+-----------------------+ 1409 | C_RP_Adv_Period | Default: 60 seconds | Periodic interval | 1410 | | | with which C-RP- | 1411 | | | Adv messages are | 1412 | | | sent to a BSR | 1413 +---------------------+-------------------------+-----------------------+ 1414 6. Security Considerations 1416 6.1. Possible Threats 1418 Threats affecting the PIM BSR mechanism are primarily of two forms: 1419 denial of service attacks, and traffic diversion attacks. An attacker 1420 that subverts the BSR mechanism can prevent multicast traffic from 1421 reaching the intended recipients, can divert multicast traffic to a 1422 place where they can monitor it, and can potentially flood third parties 1423 with traffic. 1425 Traffic can be prevented from reaching the intended recipients by one of 1426 two mechanisms: 1428 o Subverting a BSM, and specifying RPs that won't actually forward 1429 traffic. 1431 o Registering with the BSR as a C-RP, and then not forwarding 1432 traffic. 1434 Traffic can be diverted to a place where it can be monitored by both of 1435 the above mechanisms; in this case the RPs would forward the traffic, 1436 but are located so as to aid monitoring or man-in-the-middle attacks on 1437 the multicast traffic. 1439 A third party can be flooded by either of the above two mechanisms by 1440 specifying the third party as the RP, and register-encapsulated traffic 1441 will then be forwarded to them. 1443 6.2. Limiting Third-Party DoS Attacks 1445 The third party DoS attack above can be greatly reduced if PIM routers 1446 acting as DR do not continue to forward Register traffic to the RP in 1447 the presence of ICMP Protocol Unreachable or ICMP Host Unreachable 1448 responses. If a PIM router sending Register packets to an RP receives 1449 one of these responses to a data packet it has sent, it should rate- 1450 limit the transmission of future Register packets to that RP for a short 1451 period of time. 1453 As this does not affect interoperability, the precise details are left 1454 to the implementor to decide. However we note that a router 1455 implementing such rate limiting must only do so if the ICMP packet 1456 correctly echoes part of a Register packet that was sent to the RP. If 1457 this check were not made, then simply sending ICMP Unreachable packets 1458 to the DR with the source address of the RP spoofed would be sufficient 1459 to cause a denial-of-service attack on the multicast traffic originating 1460 from that DR. 1462 6.3. Bootstrap Message Security 1464 If a legitimate PIM router is compromised, there is little any security 1465 mechanism can do to prevent that router subverting PIM traffic in that 1466 domain. However we recommend that implementors provide a mechanism 1467 whereby a PIM router using the BSR mechanisms can be configured with the 1468 IP addresses of valid BSR routers, and that any Bootstrap message from 1469 any other BSR should then be dropped and logged as a security issue. We 1470 also recommend that this not be enabled by default, as it makes the 1471 initial configuration of a PIM domain problematic - it is the sort of 1472 feature that might be enabled once the configuration of a domain has 1473 stabilized. 1475 The primary security requirement for BSR (as for PIM) is that it is 1476 possible to prevent hosts that are not legitimate PIM routers, either 1477 within or outside the domain, from subverting the BSR mechanism. 1479 The Bootstrap Message Processing Checks prevent a router from accepting 1480 a Bootstrap message from outside of the PIM Domain, as the source 1481 address on Bootstrap messages must be an immediate PIM neighbor. There 1482 is however a small window of time after a reboot where a PIM router will 1483 accept a bad Bootstrap message unicast from an immediate neighbor, and 1484 it might be possible to unicast a Bootstrap message to a router during 1485 this interval from outside the domain, using the spoofed source address 1486 of a neighbor. This can be prevented if PMBRs perform source-address 1487 filtering to prevent packets entering the PIM domain with IP source 1488 addresses that are infrastructure addresses in the PIM domain. 1490 The principal threat to Bootstrap message security comes from hosts 1491 within the PIM domain that attempt to subvert the BSR mechanism. They 1492 may be able to do this by sending PIM messages to their local router, or 1493 by unicasting a Bootstrap message to another PIM router during the brief 1494 interval after it has restarted. 1496 6.3.1. Rejecting Unicast Bootstrap Messages 1498 All Bootstrap messages SHOULD carry the Router Alert IP option. If a 1499 PIM router receives a Bootstrap message that does not carry the Router 1500 Alert option, it SHOULD drop it (a configuration option should also be 1501 provided to disable this check on a per-interface basic for backward 1502 compatibility with older PIM routers). The Router Alert option allows a 1503 PIM router to perform checks on unicast packets it would otherwise 1504 blindly forward. All PIM routers should check that packets with Router 1505 Alert that are not destined for the router itself are not PIM Bootstrap 1506 messages. Any such packets should be dropped and logged as a possible 1507 security issue - it is never acceptable for a PIM Bootstrap message to 1508 travel multiple IP hops. 1510 6.3.2. Rejecting Bootstrap Messages from Invalid Neighbors 1512 Most hosts that are likely to attempt to subvert PIM BSR are likely to 1513 be located on leaf subnets. We recommend that implementors provide a 1514 configuration option that specifies an interface is a leaf subnet, and 1515 that no PIM packets are accepted on such interfaces. 1517 On multi-access subnets with multiple PIM routers and hosts that are not 1518 trusted, we recommend that IPsec AH is used to protect communication 1519 between PIM routers, and that such routers are configured to drop and 1520 log communication attempts from any host that do not pass the 1521 authentication check. When all the PIM routers are under the same 1522 administrative control, this authentication may use a configured shared 1523 secret. The securing of interactions between PIM neighbors is discussed 1524 in more detail in the Security Considerations section of [1], and so we 1525 do not discuss the details further here. The same security mechanisms 1526 that can be used to secure PIM Join, Prune and Assert messages should 1527 also be used to secure Bootstrap messages. 1529 6.4. Candidate-RP-Advertisement Message Security 1531 Even if it is not possible to subvert Bootstrap messages, an attacker 1532 might be able to perform most of the same attacks by simply sending C- 1533 RP-Adv messages to the BSR specifying the attacker's choice of RPs. 1534 Thus it is necessary to control the sending of C-RP-Adv messages in 1535 essentially the same ways that we control Bootstrap messages. However, 1536 C-RP-Adv messages are unicast and normally travel multiple hops, so 1537 controlling them is more difficult. 1539 6.4.1. Non-Cryptographic Security of C-RP-Adv Messages 1541 We specify that C-RP-Adv messages SHOULD also carry the Router Alert IP 1542 option, and that the BSR SHOULD by default drop and log C-RP-Adv 1543 messages that do not carry this option. Setting Router Alert on these 1544 packets is practical because the rate of C-RP-Adv messages should be 1545 very low, so the extra load on routers forwarding these packets will be 1546 insignificant. PIM routers forwarding such a packet may then be capable 1547 of checking whether the packet came from a valid PIM neighbor, although 1548 note that such checks are only possible if the unicast and multicast 1549 topologies in the network are congruent. If this is not the case, it is 1550 legitimate to receive a C-RP-Adv message from a router which is not a 1551 valid PIM neighbor, and therefore in this situation a PIM router MUST 1552 NOT drop C-RP-Adv messages that do not come from a valid PIM neighbor. 1554 If the unicast and multicast topologies are known to be congruent, the 1555 following checks should be made. On interfaces that are configured to 1556 be leaf subnets, all C-RP-Adv messages should be dropped. On multi- 1557 access subnets with multiple PIM routers and hosts that are not trusted, 1558 the router can at least check that the source MAC address is that of a 1559 valid PIM neighbor. PMBRs should ensure that no C-RP-Adv messages enter 1560 the domain from an external neighbor. 1562 6.4.2. Cryptographic Security of C-RP-Adv Messages 1564 For true security, we recommend that all C-RPs are configured to use 1565 IPsec authentication. The authentication process for a C-RP-Adv message 1566 between a C-RP and the BSR is identical to the authentication process 1567 for PIM Register messages between a DR and the relevant RP, except that 1568 there will normally be fewer C-RPs in a domain than there are DRs, so 1569 key management is a little simpler. We do not describe the details of 1570 this process further here, but refer to the Security Considerations 1571 section of [1]. Note that the use of cryptographic security for C-RP- 1572 Adv messages does not remove the need for the non-cryptographic 1573 mechanisms, as explained below. 1575 6.5. Denial of Service using IPsec 1577 An additional concern is that of Denial-of-Service attacks caused by 1578 sending high volumes of Bootstrap messages or C-RP-Adv messages with 1579 invalid IPsec authentication information. It is possible that these 1580 messages could overwhelm the CPU resources of the recipient. 1582 The non-cryptographic security mechanisms above prevent unicast 1583 Bootstrap messages from traveling multiple hops, and constrain who can 1584 originate such messages. However, it is obviously important that PIM 1585 messages that are required to have Router Alert checked are checked for 1586 this option before the IPsec AH is checked. Thus the remaining 1587 vulnerability primarily exists for hosts on multi-access subnets 1588 containing more than one PIM router. A PIM router receiving PIM packets 1589 with Router Alert set from such a subnet should already be checking that 1590 the source MAC address is that of a valid PIM neighbor, but this is 1591 hardly strong security. In addition, we recommend that rate-limiting 1592 mechanisms can be configured, to be applied to the forwarding of unicast 1593 PIM packets containing Router Alert options. The rate-limiter MUST 1594 independently rate-limit different types of PIM packets - for example a 1595 flood of C-RP-Adv messages MUST NOT cause a rate limiter to drop low- 1596 rate Bootstrap messages. Such a rate-limiter might itself be used to 1597 cause a denial of service attack by causing valid packets to be dropped, 1598 but in practice this is more likely to constrain bad PIM messages close 1599 to their origin. In addition, the rate limiter will prevent attacks on 1600 PIM from affecting other activity on the destination router, such as 1601 unicast routing. 1603 7. Contributors 1605 Bill Fenner, Mark Handley, Roger Kermode and David Thaler have 1606 contributed greatly to this draft. They were authors of this draft up 1607 to version 03. Most of the current text is identical to 03. 1609 8. Acknowledgments 1611 PIM-SM was designed over many years by a large group of people, 1612 including ideas from Deborah Estrin, Dino Farinacci, Ahmed Helmy, Steve 1613 Deering, Van Jacobson, C. Liu, Puneet Sharma, Liming Wei, Tom Pusateri, 1614 Tony Ballardie, Scott Brim, Jon Crowcroft, Paul Francis, Joel Halpern, 1615 Horst Hodel, Polly Huang, Stephen Ostrowski, Lixia Zhang, Girish 1616 Chandranmenon, Pavlin Radoslavov, John Zwiebel, Isidor Kouvelas and Hugh 1617 Holbrook. This BSR specification draws heavily on text from RFC 2362. 1619 Many members of the PIM Working Group have contributed comments and 1620 corrections for this document, including Christopher Thomas Brown, Ardas 1621 Cilingiroglu, Murthy Esakonu, Venugopal Hemige, Prashant Jhingran, 1622 Rishabh Parekh and Katta Sambasivarao. 1624 9. IANA Considerations 1626 This document has no actions for IANA. 1628 10. Normative References 1630 [1] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol 1631 Independent Multicast - Sparse Mode (PIM-SM): Protocol 1632 Specification (Revised)", Internet Draft draft-ietf-pim-sm- 1633 v2-new-11.txt 1635 [2] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-directional 1636 Protocol Independent Multicast (BIDIR-PIM)", Internet Draft draft- 1637 ietf-pim-bidir-07.txt 1639 [3] D. Meyer, "Administratively Scoped IP Multicast", RFC 2365, Jul 1640 1998. 1642 [4] S. Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill, "IPv6 1643 Scoped Address Architecture", Internet Draft draft-ietf- 1644 ipv6-scoping-arch-02.txt 1646 [5] R. Hinden, S. Deering, "Internet Protocol Version 6 (IPv6) 1647 Addressing Architecture", RFC 3513, Apr 2003. 1649 [6] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1650 Levels", BCP 14, RFC 2119, Mar 1997. 1652 11. Informative References 1654 [7] D. Estrin et al., "Protocol Independent Multicast - Sparse Mode 1655 (PIM-SM): Protocol Specification", RFC 2362, June 1998 (now 1656 obsolete). 1658 [8] D. Kim, D. Meyer, H. Kilmer, D. Farinacci, "Anycast Rendevous Point 1659 (RP) mechanism using Protocol Independent Multicast (PIM) and 1660 Multicast Source Discovery Protocol (MSDP)", RFC 3446, Jan 2003. 1662 [9] D. Farinacci, Y. Cai, "Anycast-RP using PIM", Internet Draft draft- 1663 ietf-pim-anycast-rp-02.txt 1665 [10] IANA, "Address Family Numbers", linked from 1666 http://www.iana.org/numbers.html 1668 Authors' Addresses 1670 Nidhi Bhaskar 1671 Cisco Systems 1672 170 W. Tasman Drive 1673 San Jose, CA 95134 1674 USA 1675 nbhaskar@cisco.com 1677 Alexander Gall 1678 SWITCH 1679 Limmatquai 138 1680 P.O. Box 1681 CH-8021 Zurich 1682 Switzerland 1683 gall@switch.ch 1685 James Lingard 1686 Data Connection Ltd 1687 100 Church Street 1688 Enfield 1689 EN2 6BQ 1690 United Kingdom 1691 james.lingard@dataconnection.com 1692 Stig Venaas 1693 UNINETT 1694 NO-7465 Trondheim 1695 Norway 1696 venaas@uninett.no 1698 Copyright Statement 1700 Copyright (C) The Internet Society (2005). This document is subject to 1701 the rights, licenses and restrictions contained in BCP 78, and except as 1702 set forth therein, the authors retain all their rights. 1704 Disclaimer of Validity 1706 This document and the information contained herein are provided on an 1707 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 1708 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1709 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1710 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1711 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1712 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.