draft-ietf-pim-sm-bsr-07.txt   draft-ietf-pim-sm-bsr-08.txt 
Internet Engineering Task Force PIM WG Internet Engineering Task Force PIM WG
INTERNET-DRAFT Nidhi Bhaskar/Cisco INTERNET-DRAFT Nidhi Bhaskar/Cisco
draft-ietf-pim-sm-bsr-07.txt Alexander Gall/SWITCH draft-ietf-pim-sm-bsr-08.txt Alexander Gall/SWITCH
James Lingard James Lingard
Stig Venaas/UNINETT Stig Venaas/UNINETT
3 March 2006 6 May 2006
Expires: September 2006 Expires: November 2006
Bootstrap Router (BSR) Mechanism for PIM Bootstrap Router (BSR) Mechanism for PIM
Status of this Document Status of this Document
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have 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 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. be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 3, line 20 skipping to change at page 3, line 20
1.3. Administrative Scoping and BSR . . . . . . . . . . . 7 1.3. Administrative Scoping and BSR . . . . . . . . . . . 7
2. BSR State and Timers. . . . . . . . . . . . . . . . . . 9 2. BSR State and Timers. . . . . . . . . . . . . . . . . . 9
3. Bootstrap Router Election and RP-Set 3. Bootstrap Router Election and RP-Set
Distribution. . . . . . . . . . . . . . . . . . . . . . 9 Distribution. . . . . . . . . . . . . . . . . . . . . . 9
3.1. Bootstrap Router Election. . . . . . . . . . . . . . 9 3.1. Bootstrap Router Election. . . . . . . . . . . . . . 9
3.1.1. Per-Scope-Zone Candidate-BSR State 3.1.1. Per-Scope-Zone Candidate-BSR State
Machine . . . . . . . . . . . . . . . . . . . . . 10 Machine . . . . . . . . . . . . . . . . . . . . . 10
3.1.2. Per-Scope-Zone State Machine for Non- 3.1.2. Per-Scope-Zone State Machine for Non-
Candidate-BSR Routers . . . . . . . . . . . . . . 12 Candidate-BSR Routers . . . . . . . . . . . . . . 12
3.1.3. Bootstrap Message Processing Checks . . . . . . . 14 3.1.3. Bootstrap Message Processing Checks . . . . . . . 14
3.1.4. State Machine Transition Events . . . . . . . . . 14 3.1.4. State Machine Transition Events . . . . . . . . . 15
3.1.5. State Machine Actions . . . . . . . . . . . . . . 15 3.1.5. State Machine Actions . . . . . . . . . . . . . . 16
3.2. Sending Candidate-RP-Advertisement Messages. . . . . 17 3.2. Sending Candidate-RP-Advertisement Messages. . . . . 17
3.3. Creating the RP-Set at the BSR . . . . . . . . . . . 18 3.3. Creating the RP-Set at the BSR . . . . . . . . . . . 19
3.4. Forwarding Bootstrap Messages. . . . . . . . . . . . 20 3.4. Forwarding Bootstrap Messages. . . . . . . . . . . . 21
3.5. Unicasting Bootstrap Messages to New and 3.5. Bootstrap Messages to New and Rebooting
Rebooting Routers. . . . . . . . . . . . . . . . . . 21 Routers. . . . . . . . . . . . . . . . . . . . . . . 22
3.6. Receiving and Using the RP-Set . . . . . . . . . . . 22 3.5.1. No-Forward Bootstrap Messages . . . . . . . . . . 22
4. Message Formats . . . . . . . . . . . . . . . . . . . . 22 3.5.2. Unicasting Bootstrap Messages . . . . . . . . . . 23
4.1. Bootstrap Message Format . . . . . . . . . . . . . . 24 3.6. Receiving and Using the RP-Set . . . . . . . . . . . 23
4.1.1. Semantic Fragmentation of BSMs. . . . . . . . . . 28 4. Message Formats . . . . . . . . . . . . . . . . . . . . 23
4.2. Candidate-RP-Advertisement Message Format. . . . . . 29 4.1. Bootstrap Message Format . . . . . . . . . . . . . . 25
5. Timers and Timer Values . . . . . . . . . . . . . . . . 31 4.1.1. Semantic Fragmentation of BSMs. . . . . . . . . . 29
6. Security Considerations . . . . . . . . . . . . . . . . 34 4.2. Candidate-RP-Advertisement Message Format. . . . . . 30
6.1. Possible Threats . . . . . . . . . . . . . . . . . . 34 5. Timers and Timer Values . . . . . . . . . . . . . . . . 32
6.2. Limiting Third-Party DoS Attacks . . . . . . . . . . 34 6. Security Considerations . . . . . . . . . . . . . . . . 35
6.3. Bootstrap Message Security . . . . . . . . . . . . . 35 6.1. Possible Threats . . . . . . . . . . . . . . . . . . 35
6.3.1. Rejecting Unicast Bootstrap Messages. . . . . . . 35 6.2. Limiting Third-Party DoS Attacks . . . . . . . . . . 35
6.3.2. Rejecting Bootstrap Messages from Invalid 6.3. Bootstrap Message Security . . . . . . . . . . . . . 36
6.3.1. Rejecting Bootstrap Messages from Invalid
Neighbors . . . . . . . . . . . . . . . . . . . . 36 Neighbors . . . . . . . . . . . . . . . . . . . . 36
6.4. Candidate-RP-Advertisement Message Security. . . . . 36 6.4. Candidate-RP-Advertisement Message Security. . . . . 37
6.4.1. Non-Cryptographic Security of C-RP-Adv 6.4.1. Non-Cryptographic Security of C-RP-Adv
Messages. . . . . . . . . . . . . . . . . . . . . 36 Messages. . . . . . . . . . . . . . . . . . . . . 37
6.4.2. Cryptographic Security of C-RP-Adv 6.4.2. Cryptographic Security of C-RP-Adv
Messages. . . . . . . . . . . . . . . . . . . . . 37 Messages. . . . . . . . . . . . . . . . . . . . . 37
6.5. Denial of Service using IPsec. . . . . . . . . . . . 37 6.5. Denial of Service using IPsec. . . . . . . . . . . . 38
7. Contributors. . . . . . . . . . . . . . . . . . . . . . 38 7. Contributors. . . . . . . . . . . . . . . . . . . . . . 38
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 38 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 38
9. IANA Considerations . . . . . . . . . . . . . . . . . . 38 9. IANA Considerations . . . . . . . . . . . . . . . . . . 39
10. Normative References . . . . . . . . . . . . . . . . . 38 10. Normative References . . . . . . . . . . . . . . . . . 39
11. Informative References . . . . . . . . . . . . . . . . 39 11. Informative References . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
This document assumes some familiarity with the concepts of Protocol This document assumes some familiarity with the concepts of Protocol
Independent Multicast - Sparse Mode (PIM-SM), as defined in [1], and Bi- Independent Multicast - Sparse Mode (PIM-SM), as defined in [1], and Bi-
directional Protocol Independent Multicast (BIDIR-PIM), as defined in directional Protocol Independent Multicast (BIDIR-PIM), as defined in
[2], as well as with Administratively Scoped IP Multicast, as described [2], as well as with Administratively Scoped IP Multicast, as described
in [3], and the IPv6 Scoped Address Architecture, described in [4]. in [3], and the IPv6 Scoped Address Architecture, described in [4].
skipping to change at page 4, line 24 skipping to change at page 4, line 24
be able to map a particular multicast group address to the same be able to map a particular multicast group address to the same
Rendezvous Point (RP). The PIM specifications do not mandate the use of Rendezvous Point (RP). The PIM specifications do not mandate the use of
a single mechanism to provide routers with the information to perform a single mechanism to provide routers with the information to perform
this group-to-RP mapping. this group-to-RP mapping.
This document describes the PIM Bootstrap Router (BSR) mechanism. BSR This document describes the PIM Bootstrap Router (BSR) mechanism. BSR
is one way that a multicast router can learn the information required to is one way that a multicast router can learn the information required to
perform the group-to-RP mapping. The mechanism is dynamic, largely perform the group-to-RP mapping. The mechanism is dynamic, largely
self-configuring, and robust to router failure. self-configuring, and robust to router failure.
BSR was first defined in RFC 2362 [9], which has since been obsoleted. BSR was first defined in RFC 2362 [7], which has since been obsoleted.
This document provides an updated specification of the BSR mechanism This document provides an updated specification of the BSR mechanism
from RFC 2362, and also extends it to cope with administratively scoped from RFC 2362, and also extends it to cope with administratively scoped
region boundaries and different flavors of routing protocols. region boundaries and different flavors of routing protocols.
Throughout the document, any reference to the PIM protocol family is Throughout the document, any reference to the PIM protocol family is
restricted to the subset of RP-based protocols, namely PIM-SM and BIDIR- restricted to the subset of RP-based protocols, namely PIM-SM and BIDIR-
PIM, unless stated otherwise. PIM, unless stated otherwise.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 5, line 44 skipping to change at page 5, line 44
note that this algorithm is part of the specification of the individual note that this algorithm is part of the specification of the individual
routing protocols (and may differ among them), not of the BSR routing protocols (and may differ among them), not of the BSR
specification. E.g. PIM-SM [1] defines one such algorithm. It makes specification. E.g. PIM-SM [1] defines one such algorithm. It makes
use of a hash function for the case where a group range has multiple RPs use of a hash function for the case where a group range has multiple RPs
with the same priority. The hash mask length is used by this function. with the same priority. The hash mask length is used by this function.
There are a number of ways in which such group-to-RP mappings can be There are a number of ways in which such group-to-RP mappings can be
established. The simplest solution is for all the routers in the domain established. The simplest solution is for all the routers in the domain
to be statically configured with the same information. However, static to be statically configured with the same information. However, static
configuration generally doesn't scale well, and, except when used in configuration generally doesn't scale well, and, except when used in
conjunction with Anycast-RP (see [10] and [11]), does not dynamically conjunction with Anycast-RP (see [8] and [9]), does not dynamically
adapt to route around router or link failures. adapt to route around router or link failures.
The BSR mechanism provides a way in which viable group-to-RP mappings The BSR mechanism provides a way in which viable group-to-RP mappings
can be created and rapidly distributed to all the PIM routers in a can be created and rapidly distributed to all the PIM routers in a
domain. It is adaptive, in that if an RP becomes unreachable, this will domain. It is adaptive, in that if an RP becomes unreachable, this will
be detected and the RP-Sets will be modified so that the unreachable RP be detected and the RP-Sets will be modified so that the unreachable RP
is no longer used. is no longer used.
1.2. Protocol Overview 1.2. Protocol Overview
skipping to change at page 14, line 16 skipping to change at page 14, line 16
When a Bootstrap message is received, the following initial checks must When a Bootstrap message is received, the following initial checks must
be performed: be performed:
if ((DirectlyConnected(BSM.src_ip_address) == FALSE) OR if ((DirectlyConnected(BSM.src_ip_address) == FALSE) OR
(we have no Hello state for BSM.src_ip_address)) { (we have no Hello state for BSM.src_ip_address)) {
drop the Bootstrap message silently drop the Bootstrap message silently
} }
if (BSM.dst_ip_address == ALL-PIM-ROUTERS) { if (BSM.dst_ip_address == ALL-PIM-ROUTERS) {
if (BSM.no_forward_bit == 0) {
if (BSM.src_ip_address != RPF_neighbor(BSM.BSR_ip_address)) { if (BSM.src_ip_address != RPF_neighbor(BSM.BSR_ip_address)) {
drop the Bootstrap message silently drop the Bootstrap message silently
} }
} else if (BSM.dst_ip_address is my primary address on the interface) { } else if ((any previous BSM for this scope has been accepted) OR
(more than BS_Period has elapsed since startup)) {
#only accept no-forward BSM if quick refresh on startup
drop the Bootstrap message silently
}
} else if ((Unicast BSM support enabled) AND
(BSM.dst_ip_address is one of my addresses)) {
if ((any previous BSM for this scope has been accepted) OR if ((any previous BSM for this scope has been accepted) OR
(more than BS_Period has elapsed since startup)) { (more than BS_Period has elapsed since startup)) {
#the packet was unicast, but this wasn't #the packet was unicast, but this wasn't
#a quick refresh on startup #a quick refresh on startup
drop the Bootstrap message silently drop the Bootstrap message silently
} }
} else { } else {
drop the Bootstrap message silently drop the Bootstrap message silently
} }
if (the interface the message arrived on is an Admin Scope if (the interface the message arrived on is an Admin Scope
border for the BSM.first_group_address) { border for the BSM.first_group_address) {
drop the Bootstrap message silently drop the Bootstrap message silently
} }
Basically, the packet must have come from a directly connected neighbor Basically, the packet must have come from a directly connected neighbor
for which we have active Hello state. It must have been sent to the for which we have active Hello state. It must have been sent to the
ALL-PIM-ROUTERS group by the correct upstream router towards the BSR ALL-PIM-ROUTERS group, and unless it is a No-Forward BSM, been sent by
that originated the Bootstrap message, or the router must have recently the correct upstream router towards the BSR that originated the
restarted, have no BSR state for that admin scope and have received the Bootstrap message; or, if it is a No-Forward BSM, we must have recently
Bootstrap message by unicast. The destination address of a unicast restarted and have no BSR state for that admin scope. Also, if unicast
Bootstrap message must be our primary address on the interface it was BSM support is enabled, a unicast BSM is accepted if it is addressed to
received, that is, the address we source PIM Hello messages from. In us and we have recently restarted and have no BSR state for that admin
addition it must not have arrived on an interface that is a configured scope. In addition, it must not have arrived on an interface that is a
admin scope border for the first group address contained in the configured admin scope border for the first group address contained in
Bootstrap message. the Bootstrap message.
3.1.4. State Machine Transition Events 3.1.4. State Machine Transition Events
If the Bootstrap message passes the initial checks above without being If the Bootstrap message passes the initial checks above without being
discarded, then it may cause a state transition event in one of the discarded, then it may cause a state transition event in one of the
above state machines. For both candidate and non-candidate BSRs, the above state machines. For both candidate and non-candidate BSRs, the
following transition events are defined: following transition events are defined:
Receive Preferred BSM Receive Preferred BSM
A Bootstrap message is received from a BSR that has higher or A Bootstrap message is received from a BSR that has higher or
skipping to change at page 16, line 6 skipping to change at page 16, line 15
3.1.5. State Machine Actions 3.1.5. State Machine Actions
The state machines specify actions that include setting the Bootstrap The state machines specify actions that include setting the Bootstrap
Timer and the Scope-Zone Expiry Timer to various values. These values Timer and the Scope-Zone Expiry Timer to various values. These values
are defined in Section 5. are defined in Section 5.
In addition to setting and cancelling the timers, the following actions In addition to setting and cancelling the timers, the following actions
may be triggered by state changes in the state machines: may be triggered by state changes in the state machines:
Forward BSM Forward BSM
A Bootstrap message that passes the Bootstrap Message A multicast Bootstrap message with No-Forward bit cleared that
Processing Checks is forwarded out of all interfaces with PIM passes the Bootstrap Message Processing Checks is forwarded
neighbors (including the interface it is received on), except out of all interfaces with PIM neighbors (including the
where this would cause the BSM to cross an admin-scope interface it is received on), except where this would cause
boundary for the scope zone indicated in the message. For the BSM to cross an admin-scope boundary for the scope zone
details, see section 3.4. indicated in the message. For details, see section 3.4.
Originate BSM Originate BSM
A new Bootstrap message is constructed by the BSR, giving the A new Bootstrap message is constructed by the BSR, giving the
BSR's address and BSR priority, and containing the BSR's BSR's address and BSR priority, and containing the BSR's
chosen RP-Set. The message is forwarded out of all interfaces chosen RP-Set. The message is forwarded out of all interfaces
on which PIM neighbors exist, except where this would cause on which PIM neighbors exist, except where this would cause
the BSM to cross an admin-scope boundary for the scope zone the BSM to cross an admin-scope boundary for the scope zone
indicated in the message. indicated in the message.
Store RP-Set Store RP-Set
skipping to change at page 19, line 5 skipping to change at page 19, line 16
3.3. Creating the RP-Set at the BSR 3.3. Creating the RP-Set at the BSR
Upon receiving a C-RP-Adv message, the router needs to decide whether or Upon receiving a C-RP-Adv message, the router needs to decide whether or
not to accept each of the group ranges included in the message. For not to accept each of the group ranges included in the message. For
each group range in the message, the router checks to see if it is the each group range in the message, the router checks to see if it is the
elected BSR for any scope zone that contains the group range, or if it elected BSR for any scope zone that contains the group range, or if it
is elected as the non-scoped BSR. If so, the group range is accepted; is elected as the non-scoped BSR. If so, the group range is accepted;
if not, the group range is ignored. if not, the group range is ignored.
For security reasons, we recommend that implementations have a way of
restricting which IP addresses the BSR accepts C-RP-Adv messages from,
e.g., access lists. For use of scoped BSR, it may also be useful to
specify which group ranges should be accepted.
If the group range is accepted, a group-to-C-RP mapping is created for If the group range is accepted, a group-to-C-RP mapping is created for
this group range and the RP Address from the C-RP-Adv message. this group range and the RP Address from the C-RP-Adv message.
If the mapping is not already part of the C-RP-Set, it is added to the If the mapping is not already part of the C-RP-Set, it is added to the
C-RP-Set and the associated Group-to-C-RP mapping Expiry Timer (CGET) is C-RP-Set and the associated Group-to-C-RP mapping Expiry Timer (CGET) is
initialized to the holdtime from the C-RP-Adv message. Its priority is initialized to the holdtime from the C-RP-Adv message. Its priority is
set to the Priority from the C-RP-Adv message. set to the Priority from the C-RP-Adv message.
If the mapping is already part of the C-RP-Set, it is updated with the If the mapping is already part of the C-RP-Set, it is updated with the
Priority from the C-RP-Adv message and its associated CGET is reset to Priority from the C-RP-Adv message and its associated CGET is reset to
skipping to change at page 19, line 37 skipping to change at page 20, line 4
When a CGET expires, the corresponding group-to-C-RP mapping is removed When a CGET expires, the corresponding group-to-C-RP mapping is removed
from the C-RP-Set. from the C-RP-Set.
The BSR constructs the RP-Set from the C-RP-Set. It may apply a local The BSR constructs the RP-Set from the C-RP-Set. It may apply a local
policy to limit the number of Candidate-RPs included in the RP-Set. The policy to limit the number of Candidate-RPs included in the RP-Set. The
BSR may override the prefix indicated in a C-RP-Adv message unless the BSR may override the prefix indicated in a C-RP-Adv message unless the
`Priority' field from the C-RP-Adv message is less than 128. `Priority' field from the C-RP-Adv message is less than 128.
For inclusion in a BSM, the RP-Set is subdivided into sets of {group- For inclusion in a BSM, the RP-Set is subdivided into sets of {group-
prefix, RP-Count, RP-addresses}. For each RP-address, the "RP-Holdtime" prefix, RP-Count, RP-addresses}. For each RP-address, the "RP-Holdtime"
field is set to the Holdtime from the C-RP-Set, subject to the field is set to the Holdtime from the C-RP-Set, subject to the
constraint that it MUST be larger than BS_Period and SHOULD be larger constraint that it MUST be larger than BS_Period and SHOULD be larger
than 2.5 times BS_Period to allow for some Bootstrap messages getting than 2.5 times BS_Period to allow for some Bootstrap messages getting
lost. lost. If some holdtimes from the C-RP-Sets do not satisfy this
constraint, the BSR MUST replace those holdtimes with a value satisfying
the constraint. An exception to this is the holdtime of zero which is
used to immediately withdraw mappings.
The format of the Bootstrap message allows `semantic fragmentation', if The format of the Bootstrap message allows `semantic fragmentation', if
the length of the original Bootstrap message exceeds the packet maximum the length of the original Bootstrap message exceeds the packet maximum
boundaries. However, we recommend against configuring a large number of boundaries. However, we recommend against configuring a large number of
routers as C-RPs, to reduce the semantic fragmentation required. routers as C-RPs, to reduce the semantic fragmentation required.
In general BSMs are originated at regular intervals according to the In general BSMs are originated at regular intervals according to the
BS_Period timer. We do recommend that a BSM is also originated whenever BS_Period timer. We do recommend that a BSM is also originated whenever
the RP-set to be announced in the BSMs changes. This will usually the RP-set to be announced in the BSMs changes. This will usually
happen when receiving C-RP advertisements from a new C-RP, or when a C- happen when receiving C-RP advertisements from a new C-RP, or when a C-
skipping to change at page 20, line 49 skipping to change at page 21, line 19
The "Admin Scope Zone" bit of all group ranges other than the first The "Admin Scope Zone" bit of all group ranges other than the first
SHOULD be set to 0 on origination, and MUST be ignored on receipt. SHOULD be set to 0 on origination, and MUST be ignored on receipt.
When an elected BSR is being shut down, it should immediately originate When an elected BSR is being shut down, it should immediately originate
a Bootstrap message listing its current RP-Set, but with the BSR a Bootstrap message listing its current RP-Set, but with the BSR
Priority field set to the lowest priority value possible. This will Priority field set to the lowest priority value possible. This will
cause the election of a new BSR to happen more quickly. cause the election of a new BSR to happen more quickly.
3.4. Forwarding Bootstrap Messages 3.4. Forwarding Bootstrap Messages
Bootstrap messages originate at the BSR, and are hop-by-hop forwarded by Generally, bootstrap messages originate at the BSR, and are hop-by-hop
intermediate routers if they pass the Bootstrap Message Processing forwarded by intermediate routers if they pass the Bootstrap Message
Checks. When a Bootstrap message is forwarded, it is forwarded out of Processing Checks. There are two exceptions to this. One is that a
every multicast-capable interface which has PIM neighbors (including the bootstrap message is not forwarded if its No-Forward bit is set, see
3.5.1. The other is that unicast BSMs, see 3.5.2, are usually not
forwarded. Implementers MAY, however, at their own discretion choose to
re-send a No-Forward or unicast BSM in a multicast BSM which MUST have
the No-Forward bit cleared. It is essential that the No-Forward bit is
cleared, since no RPF check is performed by the receiver when set.
one over which the message was received). The exception to this is if By hop-by-hop forwarding, we mean that the bootstrap message itself is
the interface is an administrative scope boundary for the admin scope forwarded, not the entire IP packet. Each hop constructs an IP packet
zone indicated in the first group address in the Bootstrap message for each of the interfaces the BSM is to be forwarded out of; each
packet. packet containing the entire BSM that was received.
When a Bootstrap message is forwarded, it is forwarded out of every
multicast-capable interface which has PIM neighbors (including the one
over which the message was received). The exception to this is if the
interface is an administrative scope boundary for the admin scope zone
indicated in the first group address in the Bootstrap message packet.
As an optimization, a router MAY choose not to forward a BSM out of the As an optimization, a router MAY choose not to forward a BSM out of the
interface the message was received on if that interface is a point-to- interface the message was received on if that interface is a point-to-
point interface. On interfaces with multiple PIM neighbors, a router point interface. On interfaces with multiple PIM neighbors, a router
SHOULD forward an accepted BSM onto the interface that BSM was received SHOULD forward an accepted BSM onto the interface that BSM was received
on, but if the number of PIM neighbors on that interface is large, it on, but if the number of PIM neighbors on that interface is large, it
MAY delay forwarding a BSM onto that interface by a small randomized MAY delay forwarding a BSM onto that interface by a small randomized
interval to prevent message implosion. A configuration option MAY be interval to prevent message implosion. A configuration option MAY be
provided to disable forwarding onto the interface a message was received provided to disable forwarding onto the interface a message was received
on, but we recommend that the default behavior is to forward onto that on, but we recommend that the default behavior is to forward onto that
skipping to change at page 21, line 39 skipping to change at page 22, line 21
forwarding onto the incoming interface may safely be disabled. forwarding onto the incoming interface may safely be disabled.
A ZBR constrains all BSMs which are of equal or smaller scope than the A ZBR constrains all BSMs which are of equal or smaller scope than the
configured boundary. That is, the BSMs are not accepted from, configured boundary. That is, the BSMs are not accepted from,
originated or forwarded on the interfaces on which the boundary is originated or forwarded on the interfaces on which the boundary is
configured. For IPv6 the check is a comparison between the scope of the configured. For IPv6 the check is a comparison between the scope of the
first range in the scoped BSM and the scope of the configured boundary. first range in the scoped BSM and the scope of the configured boundary.
For IPv4, the first range in the scoped BSM is checked to see if it is For IPv4, the first range in the scoped BSM is checked to see if it is
contained in or is the same as the range of the configured boundary. contained in or is the same as the range of the configured boundary.
3.5. Unicasting Bootstrap Messages to New and Rebooting Routers 3.5. Bootstrap Messages to New and Rebooting Routers
To allow new or rebooting routers to learn the RP-Set quickly, when a To allow new or rebooting routers to learn the RP-Set quickly, when a
Hello message is received from a new neighbor, or a Hello message with a Hello message is received from a new neighbor, or a Hello message with a
new GenID is received from an existing neighbor, one router on the LAN new GenID is received from an existing neighbor, one router on the LAN
unicasts a stored copy of the Bootstrap message for each admin scope sends a stored copy of the Bootstrap message for each admin scope zone
zone to the new or rebooting router. to the new or rebooting router.
This message SHOULD be sent as a No-Forward Bootstrap message, see
3.5.1. For backwards compatibility, this message MAY instead or in
addition be sent as a Unicast Bootstrap message, see 3.5.2. These
messages MUST only be accepted at startup, see 3.1.3.
The router that does this is the Designated Router (DR) on the LAN, or, The router that does this is the Designated Router (DR) on the LAN, or,
if the new or rebooting router is the DR, the router that would be the if the new or rebooting router is the DR, the router that would be the
DR if the new or rebooting router were excluded from the DR election DR if the new or rebooting router were excluded from the DR election
process. process.
Before unicasting a Bootstrap message in this manner, the DR must wait Before sending a Bootstrap message in this manner, the router must wait
until it has sent a triggered Hello message on this interface; until it has sent a triggered Hello message on this interface;
otherwise, the new neighbor will discard the Bootstrap message. otherwise, the new neighbor will discard the Bootstrap message.
3.5.1. No-Forward Bootstrap Messages
A No-Forward Bootstrap message, is a bootstrap message that has the No-
Forward bit set. All implementations SHOULD support sending of No-
Forward Bootstrap messages, and SHOULD also accept them. The RPF check
MUST NOT be performed in the BSM processing check for a No-Forward BSM,
see 3.1.3. The messages have the same source and destination addresses
as the usual multicast Bootstrap messages.
3.5.2. Unicasting Bootstrap Messages
For backwards compatibility implementations MAY support Unicast
Bootstrap messages. Whether to send Unicast Bootstrap Messages instead
of or in addition to No-Forward Bootstrap Messages, and also whether to
accept such messages, SHOULD be configurable. This message is unicast
to the neighbor.
3.6. Receiving and Using the RP-Set 3.6. Receiving and Using the RP-Set
The RP-Set maintained by BSR is used by RP-based multicast routing The RP-Set maintained by BSR is used by RP-based multicast routing
protocols like PIM-SM and BIDIR-PIM. These protocols may obtain RP-Sets protocols like PIM-SM and BIDIR-PIM. These protocols may obtain RP-Sets
from other sources as well. How the final group-to-RP mappings are from other sources as well. How the final group-to-RP mappings are
obtained from these RP-Sets is not part of the BSR specification. In obtained from these RP-Sets is not part of the BSR specification. In
general, the routing protocols need to re-calculate the mappings when general, the routing protocols need to re-calculate the mappings when
any of their RP-Sets change. How such a change is signalled to the any of their RP-Sets change. How such a change is signalled to the
routing protocol is also not part of the present specification. routing protocol is also not part of the present specification.
skipping to change at page 22, line 39 skipping to change at page 23, line 43
4 Bootstrap 4 Bootstrap
8 Candidate-RP-Advertisement 8 Candidate-RP-Advertisement
As with all other PIM control messages, BSR messages have IP protocol As with all other PIM control messages, BSR messages have IP protocol
number 103. number 103.
Candidate-RP-Advertisement messages are unicast to a BSR. Usually, Candidate-RP-Advertisement messages are unicast to a BSR. Usually,
Bootstrap messages are multicast with TTL 1 to the ALL-PIM-ROUTERS Bootstrap messages are multicast with TTL 1 to the ALL-PIM-ROUTERS
group, but in some circumstances (described in section 3.5) Bootstrap group, but in some circumstances (described in section 3.5.2) Bootstrap
messages are unicast to a specific PIM neighbor. Unicast Bootstrap messages are unicast to a specific PIM neighbor.
messages MUST be sent with TTL 1 to the source address of the neighbor's
PIM hello messages.
The IP source address used for Candidate-RP-Advertisement messages is a The IP source address used for Candidate-RP-Advertisement messages is a
domain-wide reachable address. The IP source address used for Bootstrap domain-wide reachable address. The IP source address used for Bootstrap
messages (regardless of whether they are being originated or forwarded) messages (regardless of whether they are being originated or forwarded)
is the link-local address of the interface on which the message is being is the link-local address of the interface on which the message is being
sent (that is, the same source address that the router uses for the sent (that is, the same source address that the router uses for the
Hello messages it sends out that interface). Hello messages it sends out that interface).
All Bootstrap and Candidate-RP-Advertisement messages SHOULD carry the
Router Alert IP option [7] for IPv4, and the IPv6 Router Alert Option
[8] for IPv6. See section 6 for information about the way in which the
Router Alert option is checked by receiving routers.
The IPv4 ALL-PIM-ROUTERS group is 224.0.0.13. The IPv6 ALL-PIM-ROUTERS The IPv4 ALL-PIM-ROUTERS group is 224.0.0.13. The IPv6 ALL-PIM-ROUTERS
group is ff02::d. group is ff02::d.
In this section we use the following terms defined in the PIM-SM In this section we use the following terms defined in the PIM-SM
specification [1]: specification [1]:
o Encoded-Unicast format o Encoded-Unicast format
o Encoded-Group format o Encoded-Group format
skipping to change at page 23, line 35 skipping to change at page 24, line 32
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr Family | Encoding Type | Unicast Address | Addr Family | Encoding Type | Unicast Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
Addr Family Addr Family
The PIM address family of the `Unicast Address' field of this The PIM address family of the `Unicast Address' field of this
address. address.
Values of 0-127 are as assigned by the IANA for Internet Address Values of 0-127 are as assigned by the IANA for Internet Address
Families in [12]. Values 128-250 are reserved to be assigned by Families in [10]. Values 128-250 are reserved to be assigned by
the IANA for PIM-specific Address Families. Values 251 though 255 the IANA for PIM-specific Address Families. Values 251 though 255
are designated for private use. As there is no assignment are designated for private use. As there is no assignment
authority for this space, collisions should be expected. authority for this space, collisions should be expected.
Encoding Type Encoding Type
The type of encoding used within a specific Address Family. The The type of encoding used within a specific Address Family. The
value `0' is reserved for this field, and represents the native value `0' is reserved for this field, and represents the native
encoding of the Address Family. encoding of the Address Family.
Unicast Address Unicast Address
skipping to change at page 25, line 4 skipping to change at page 25, line 50
native encoding and 128 for IPv6 native encoding). native encoding and 128 for IPv6 native encoding).
Group multicast Address Group multicast Address
Contains the group address. Contains the group address.
4.1. Bootstrap Message Format 4.1. Bootstrap Message Format
A bootstrap message may be divided up into 'semantic fragments' if the A bootstrap message may be divided up into 'semantic fragments' if the
resulting IP datagram would exceed the maximum packet size boundaries. resulting IP datagram would exceed the maximum packet size boundaries.
Basically, a single Bootstrap message can be sent as multiple semantic Basically, a single Bootstrap message can be sent as multiple semantic
fragments (each in a separate IP datagram), so long as the fragment tags fragments (each in a separate IP datagram), so long as the fragment tags
of all the semantic fragments comprising the message are the same. The of all the semantic fragments comprising the message are the same. The
format of a single non-fragmented message is the same as the one used format of a single non-fragmented message is the same as the one used
for semantic fragments. for semantic fragments.
The format of a single `fragment' is given below: The format of a single `fragment' is given below:
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum | |PIM Ver| Type |N| Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Tag | Hash Mask Len | BSR Priority | | Fragment Tag | Hash Mask Len | BSR Priority |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSR Address (Encoded-Unicast format) | | BSR Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Address 1 (Encoded-Group format) | | Group Address 1 (Encoded-Group format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Count 1 | Frag RP Cnt 1 | Reserved | | RP Count 1 | Frag RP Cnt 1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP Address 1 (Encoded-Unicast format) | | RP Address 1 (Encoded-Unicast format) |
skipping to change at page 27, line 16 skipping to change at page 28, line 16
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPm Holdtime | RPm Priority | Reserved | | RPm Holdtime | RPm Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PIM Version, Reserved, Checksum PIM Version, Reserved, Checksum
Described in [1]. Described in [1].
Type Type
PIM Message Type. Value is 4 for a Bootstrap message. PIM Message Type. Value is 4 for a Bootstrap message.
[N]o-forward bit
When set, this bit means that the Bootstrap message fragment is not
to be forwarded.
Fragment Tag Fragment Tag
A randomly generated number, acts to distinguish the fragments A randomly generated number, acts to distinguish the fragments
belonging to different Bootstrap messages; fragments belonging to belonging to different Bootstrap messages; fragments belonging to
same Bootstrap message carry the same `Fragment Tag'. same Bootstrap message carry the same `Fragment Tag'.
Hash Mask Len Hash Mask Len
The length (in bits) of the mask to use in the hash function. For The length (in bits) of the mask to use in the hash function. For
IPv4 we recommend a value of 30. For IPv6 we recommend a value of IPv4 we recommend a value of 30. For IPv6 we recommend a value of
126. This field SHOULD be the same for all fragments belonging to 126. This field SHOULD be the same for all fragments belonging to
the same Bootstrap message. the same Bootstrap message.
skipping to change at page 34, line 45 skipping to change at page 35, line 45
The third party DoS attack above can be greatly reduced if PIM routers The third party DoS attack above can be greatly reduced if PIM routers
acting as DR do not continue to forward Register traffic to the RP in acting as DR do not continue to forward Register traffic to the RP in
the presence of ICMP Protocol Unreachable or ICMP Host Unreachable the presence of ICMP Protocol Unreachable or ICMP Host Unreachable
responses. If a PIM router sending Register packets to an RP receives responses. If a PIM router sending Register packets to an RP receives
one of these responses to a data packet it has sent, it should rate- one of these responses to a data packet it has sent, it should rate-
limit the transmission of future Register packets to that RP for a short limit the transmission of future Register packets to that RP for a short
period of time. period of time.
As this does not affect interoperability, the precise details are left As this does not affect interoperability, the precise details are left
to the implementor to decide. However we note that a router to the implementer to decide. However we note that a router
implementing such rate limiting must only do so if the ICMP packet implementing such rate limiting must only do so if the ICMP packet
correctly echoes part of a Register packet that was sent to the RP. If correctly echoes part of a Register packet that was sent to the RP. If
this check were not made, then simply sending ICMP Unreachable packets this check were not made, then simply sending ICMP Unreachable packets
to the DR with the source address of the RP spoofed would be sufficient to the DR with the source address of the RP spoofed would be sufficient
to cause a denial-of-service attack on the multicast traffic originating to cause a denial-of-service attack on the multicast traffic originating
from that DR. from that DR.
6.3. Bootstrap Message Security 6.3. Bootstrap Message Security
If a legitimate PIM router is compromised, there is little any security If a legitimate PIM router is compromised, there is little any security
mechanism can do to prevent that router subverting PIM traffic in that mechanism can do to prevent that router subverting PIM traffic in that
domain. However we recommend that implementors provide a mechanism domain. However we recommend that implementers provide a mechanism
whereby a PIM router using the BSR mechanisms can be configured with the whereby a PIM router using the BSR mechanisms can be configured with the
IP addresses of valid BSR routers, and that any Bootstrap message from IP addresses of valid BSR routers, and that any Bootstrap message from
any other BSR should then be dropped and logged as a security issue. We any other BSR should then be dropped and logged as a security issue. We
also recommend that this not be enabled by default, as it makes the also recommend that this not be enabled by default, as it makes the
initial configuration of a PIM domain problematic - it is the sort of initial configuration of a PIM domain problematic - it is the sort of
feature that might be enabled once the configuration of a domain has feature that might be enabled once the configuration of a domain has
stabilized. stabilized.
The primary security requirement for BSR (as for PIM) is that it is The primary security requirement for BSR (as for PIM) is that it is
possible to prevent hosts that are not legitimate PIM routers, either possible to prevent hosts that are not legitimate PIM routers, either
skipping to change at page 35, line 31 skipping to change at page 36, line 31
The Bootstrap Message Processing Checks prevent a router from accepting The Bootstrap Message Processing Checks prevent a router from accepting
a Bootstrap message from outside of the PIM Domain, as the source a Bootstrap message from outside of the PIM Domain, as the source
address on Bootstrap messages must be an immediate PIM neighbor. There address on Bootstrap messages must be an immediate PIM neighbor. There
is however a small window of time after a reboot where a PIM router will is however a small window of time after a reboot where a PIM router will
accept a bad Bootstrap message unicast from an immediate neighbor, and accept a bad Bootstrap message unicast from an immediate neighbor, and
it might be possible to unicast a Bootstrap message to a router during it might be possible to unicast a Bootstrap message to a router during
this interval from outside the domain, using the spoofed source address this interval from outside the domain, using the spoofed source address
of a neighbor. This can be prevented if PMBRs perform source-address of a neighbor. This can be prevented if PMBRs perform source-address
filtering to prevent packets entering the PIM domain with IP source filtering to prevent packets entering the PIM domain with IP source
addresses that are infrastructure addresses in the PIM domain. addresses that are infrastructure addresses in the PIM domain. It might
also be a good idea to configure the PMBRs to not accept any Bootstrap
messages from outside the domain. One might configure the PMBRs to drop
all unicast PIM messages (Bootstrap message, Candidate RP Advertisement,
PIM register and PIM register stop).
The principal threat to Bootstrap message security comes from hosts The principal threat to Bootstrap message security comes from hosts
within the PIM domain that attempt to subvert the BSR mechanism. They within the PIM domain that attempt to subvert the BSR mechanism. They
may be able to do this by sending PIM messages to their local router, or may be able to do this by sending PIM messages to their local router, or
by unicasting a Bootstrap message to another PIM router during the brief by unicasting a Bootstrap message to another PIM router during the brief
interval after it has restarted. interval after it has restarted.
6.3.1. Rejecting Unicast Bootstrap Messages The use of unicast BSMs is for backwards compatibility only. Due to the
possible security implications, implementations supporting unicast BSMs
All Bootstrap messages SHOULD carry the Router Alert option, for IPv4 should provide a configuration option for whether they are to be used.
the Router Alert IP option [7], and for IPv6, the IPv6 Router Alert
Option [8]. If a PIM router receives a Bootstrap message that does not
carry the Router Alert option, it SHOULD drop it (a configuration option
should also be provided to disable this check on a per-interface basic
for backward compatibility with older PIM routers). The Router Alert
option allows a PIM router to perform checks on unicast packets it would
otherwise blindly forward. All PIM routers should check that packets
with Router Alert that are not destined for the router itself are not
PIM Bootstrap messages. Any such packets should be dropped and logged
as a possible security issue - it is never acceptable for a PIM
Bootstrap message to travel multiple IP hops.
6.3.2. Rejecting Bootstrap Messages from Invalid Neighbors 6.3.1. Rejecting Bootstrap Messages from Invalid Neighbors
Most hosts that are likely to attempt to subvert PIM BSR are likely to Most hosts that are likely to attempt to subvert PIM BSR are likely to
be located on leaf subnets. We recommend that implementors provide a be located on leaf subnets. We recommend that implementers provide a
configuration option that specifies an interface is a leaf subnet, and configuration option that specifies an interface is a leaf subnet, and
that no PIM packets are accepted on such interfaces. that no PIM packets are accepted on such interfaces.
On multi-access subnets with multiple PIM routers and hosts that are not On multi-access subnets with multiple PIM routers and hosts that are not
trusted, we recommend that IPsec AH is used to protect communication trusted, we recommend that IPsec AH is used to protect communication
between PIM routers, and that such routers are configured to drop and between PIM routers, and that such routers are configured to drop and
log communication attempts from any host that do not pass the log communication attempts from any host that do not pass the
authentication check. When all the PIM routers are under the same authentication check. When all the PIM routers are under the same
administrative control, this authentication may use a configured shared administrative control, this authentication may use a configured shared
secret. The securing of interactions between PIM neighbors is discussed secret. The securing of interactions between PIM neighbors is discussed
skipping to change at page 36, line 36 skipping to change at page 37, line 29
Even if it is not possible to subvert Bootstrap messages, an attacker Even if it is not possible to subvert Bootstrap messages, an attacker
might be able to perform most of the same attacks by simply sending C- might be able to perform most of the same attacks by simply sending C-
RP-Adv messages to the BSR specifying the attacker's choice of RPs. RP-Adv messages to the BSR specifying the attacker's choice of RPs.
Thus it is necessary to control the sending of C-RP-Adv messages in Thus it is necessary to control the sending of C-RP-Adv messages in
essentially the same ways that we control Bootstrap messages. However, essentially the same ways that we control Bootstrap messages. However,
C-RP-Adv messages are unicast and normally travel multiple hops, so C-RP-Adv messages are unicast and normally travel multiple hops, so
controlling them is more difficult. controlling them is more difficult.
6.4.1. Non-Cryptographic Security of C-RP-Adv Messages 6.4.1. Non-Cryptographic Security of C-RP-Adv Messages
We specify that C-RP-Adv messages SHOULD also carry the Router Alert We recommend that PMBRs are configured to drop C-RP-Adv messages. One
option, and that the BSR SHOULD by default drop and log C-RP-Adv might configure the PMBRs to drop all unicast PIM messages (Bootstrap
messages that do not carry this option. Setting Router Alert on these message, Candidate RP Advertisement, PIM register and PIM register
packets is practical because the rate of C-RP-Adv messages should be stop). PMBRs may also perform source-address filtering to prevent
very low, so the extra load on routers forwarding these packets will be packets entering the PIM domain with IP source addresses that are
insignificant. PIM routers forwarding such a packet may then be capable infrastructure addresses in the PIM domain. We also recommend that
of checking whether the packet came from a valid PIM neighbor, although implementations have a way of restricting which IP addresses the BSR
note that such checks are only possible if the unicast and multicast accepts C-RP-Adv messages from. The BSR can then be configured to only
topologies in the network are congruent. If this is not the case, it is accept C-RP-Adv messages from infrastructure addresses or the subset
legitimate to receive a C-RP-Adv message from a router which is not a used for candidate RPs.
valid PIM neighbor, and therefore in this situation a PIM router MUST
NOT drop C-RP-Adv messages that do not come from a valid PIM neighbor.
If the unicast and multicast topologies are known to be congruent, the If the unicast and multicast topologies are known to be congruent, the
following checks should be made. On interfaces that are configured to following checks should be made. On interfaces that are configured to
be leaf subnets, all C-RP-Adv messages should be dropped. On multi- be leaf subnets, all C-RP-Adv messages should be dropped. On multi-
access subnets with multiple PIM routers and hosts that are not trusted, access subnets with multiple PIM routers and hosts that are not trusted,
the router can at least check that the source MAC address is that of a the router can at least check that the source MAC address is that of a
valid PIM neighbor. PMBRs should ensure that no C-RP-Adv messages enter valid PIM neighbor.
the domain from an external neighbor.
6.4.2. Cryptographic Security of C-RP-Adv Messages 6.4.2. Cryptographic Security of C-RP-Adv Messages
For true security, we recommend that all C-RPs are configured to use For true security, we recommend that all C-RPs are configured to use
IPsec authentication. The authentication process for a C-RP-Adv message IPsec authentication. The authentication process for a C-RP-Adv message
between a C-RP and the BSR is identical to the authentication process between a C-RP and the BSR is identical to the authentication process
for PIM Register messages between a DR and the relevant RP, except that for PIM Register messages between a DR and the relevant RP, except that
there will normally be fewer C-RPs in a domain than there are DRs, so there will normally be fewer C-RPs in a domain than there are DRs, so
key management is a little simpler. We do not describe the details of key management is a little simpler. We do not describe the details of
this process further here, but refer to the Security Considerations this process further here, but refer to the Security Considerations
section of [1]. Note that the use of cryptographic security for C-RP-Adv section of [1]. Note that the use of cryptographic security for C-RP-
messages does not remove the need for the non-cryptographic mechanisms, Adv messages does not remove the need for the non-cryptographic
as explained below. mechanisms, as explained below.
6.5. Denial of Service using IPsec 6.5. Denial of Service using IPsec
An additional concern is that of Denial-of-Service attacks caused by An additional concern is that of Denial-of-Service attacks caused by
sending high volumes of Bootstrap messages or C-RP-Adv messages with sending high volumes of Bootstrap messages or C-RP-Adv messages with
invalid IPsec authentication information. It is possible that these invalid IPsec authentication information. It is possible that these
messages could overwhelm the CPU resources of the recipient. messages could overwhelm the CPU resources of the recipient.
The non-cryptographic security mechanisms above prevent unicast The non-cryptographic security mechanisms above restrict from where
Bootstrap messages from traveling multiple hops, and constrain who can unicast Bootstrap messages and C-RP-Adv messages are accepted. In
originate such messages. However, it is obviously important that PIM addition, we recommend that rate-limiting mechanisms can be configured,
messages that are required to have Router Alert checked are checked for to be applied to receival of unicast PIM packets. The rate-limiter MUST
this option before the IPsec AH is checked. Thus the remaining
vulnerability primarily exists for hosts on multi-access subnets
containing more than one PIM router. A PIM router receiving PIM packets
with Router Alert set from such a subnet should already be checking that
the source MAC address is that of a valid PIM neighbor, but this is
hardly strong security. In addition, we recommend that rate-limiting
mechanisms can be configured, to be applied to the forwarding of unicast
PIM packets containing Router Alert options. The rate-limiter MUST
independently rate-limit different types of PIM packets - for example a independently rate-limit different types of PIM packets - for example a
flood of C-RP-Adv messages MUST NOT cause a rate limiter to drop low- flood of C-RP-Adv messages MUST NOT cause a rate limiter to drop low-
rate Bootstrap messages. Such a rate-limiter might itself be used to rate Bootstrap messages. Such a rate-limiter might itself be used to
cause a denial of service attack by causing valid packets to be dropped, cause a denial of service attack by causing valid packets to be dropped,
but in practice this is more likely to constrain bad PIM messages close but in practice this is more likely to constrain bad PIM messages. The
to their origin. In addition, the rate limiter will prevent attacks on rate limiter will prevent attacks on PIM from affecting other activity
PIM from affecting other activity on the destination router, such as on the receiving router, such as unicast routing.
unicast routing.
7. Contributors 7. Contributors
Bill Fenner, Mark Handley, Roger Kermode and David Thaler have Bill Fenner, Mark Handley, Roger Kermode and David Thaler have
contributed greatly to this draft. They were authors of this draft up contributed greatly to this draft. They were authors of this draft up
to version 03. Most of the current text is identical to 03. to version 03, and much of the current text comes from version 03.
8. Acknowledgments 8. Acknowledgments
PIM-SM was designed over many years by a large group of people, PIM-SM was designed over many years by a large group of people,
including ideas from Deborah Estrin, Dino Farinacci, Ahmed Helmy, Steve including ideas from Deborah Estrin, Dino Farinacci, Ahmed Helmy, Steve
Deering, Van Jacobson, C. Liu, Puneet Sharma, Liming Wei, Tom Pusateri, Deering, Van Jacobson, C. Liu, Puneet Sharma, Liming Wei, Tom Pusateri,
Tony Ballardie, Scott Brim, Jon Crowcroft, Paul Francis, Joel Halpern, Tony Ballardie, Scott Brim, Jon Crowcroft, Paul Francis, Joel Halpern,
Horst Hodel, Polly Huang, Stephen Ostrowski, Lixia Zhang, Girish Horst Hodel, Polly Huang, Stephen Ostrowski, Lixia Zhang, Girish
Chandranmenon, Pavlin Radoslavov, John Zwiebel, Isidor Kouvelas and Hugh Chandranmenon, Pavlin Radoslavov, John Zwiebel, Isidor Kouvelas and Hugh
Holbrook. This BSR specification draws heavily on text from RFC 2362. Holbrook. This BSR specification draws heavily on text from RFC 2362.
Many members of the PIM Working Group have contributed comments and Many members of the PIM Working Group have contributed comments and
corrections for this document, including Christopher Thomas Brown, Ardas corrections for this document, including Christopher Thomas Brown, Ardas
Cilingiroglu, Murthy Esakonu, Venugopal Hemige, Prashant Jhingran, Cilingiroglu, Murthy Esakonu, Venugopal Hemige, Prashant Jhingran,
Rishabh Parekh and Katta Sambasivarao. Rishabh Parekh and Katta Sambasivarao.
9. IANA Considerations 9. IANA Considerations
IANA is requested to assign a value for the IPv6 Router Alert Option [8] This document has no actions for IANA.
to be used for both Bootstrap and Candidate-RP-Advertisement messages.
10. Normative References 10. Normative References
[1] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol [1] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol
Independent Multicast - Sparse Mode (PIM-SM): Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", Internet Draft draft-ietf-pim-sm- Specification (Revised)", Internet Draft draft-ietf-pim-sm-
v2-new-11.txt v2-new-11.txt
[2] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-directional [2] M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bi-directional
Protocol Independent Multicast (BIDIR-PIM)", Internet Draft draft- Protocol Independent Multicast (BIDIR-PIM)", Internet Draft draft-
skipping to change at page 39, line 5 skipping to change at page 39, line 32
[4] S. Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill, "IPv6 [4] S. Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill, "IPv6
Scoped Address Architecture", RFC 4007, Mar 2005. Scoped Address Architecture", RFC 4007, Mar 2005.
[5] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", RFC [5] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture", RFC
4291, Feb 2006. 4291, Feb 2006.
[6] S. Bradner, "Key words for use in RFCs to Indicate Requirement [6] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, Mar 1997. Levels", BCP 14, RFC 2119, Mar 1997.
[7] D. Katz, "IP Router Alert Option", RFC 2113, Feb 2006.
[8] C. Partridge, A. Jackson, "IPv6 Router Alert Option", RFC 2711, Oct
1999.
11. Informative References 11. Informative References
[9] D. Estrin et al., "Protocol Independent Multicast - Sparse Mode [7] D. Estrin et al., "Protocol Independent Multicast - Sparse Mode
(PIM-SM): Protocol Specification", RFC 2362, June 1998 (now (PIM-SM): Protocol Specification", RFC 2362, June 1998 (now
obsolete). obsolete).
[10] D. Kim, D. Meyer, H. Kilmer, D. Farinacci, "Anycast Rendevous Point [8] D. Kim, D. Meyer, H. Kilmer, D. Farinacci, "Anycast Rendevous Point
(RP) mechanism using Protocol Independent Multicast (PIM) and (RP) mechanism using Protocol Independent Multicast (PIM) and
Multicast Source Discovery Protocol (MSDP)", RFC 3446, Jan 2003. Multicast Source Discovery Protocol (MSDP)", RFC 3446, Jan 2003.
[11] D. Farinacci, Y. Cai, "Anycast-RP using PIM", Internet Draft draft- [9] D. Farinacci, Y. Cai, "Anycast-RP using PIM", Internet Draft draft-
ietf-pim-anycast-rp-07.txt ietf-pim-anycast-rp-07.txt
[12] IANA, "Address Family Numbers", linked from [10] IANA, "Address Family Numbers", linked from
http://www.iana.org/numbers.html http://www.iana.org/numbers.html
Authors' Addresses Authors' Addresses
Nidhi Bhaskar Nidhi Bhaskar
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
nbhaskar@cisco.com nbhaskar@cisco.com
Alexander Gall Alexander Gall
SWITCH SWITCH
Limmatquai 138 Limmatquai 138
 End of changes. 51 change blocks. 
136 lines changed or deleted 156 lines changed or added

This html diff was produced by rfcdiff 1.30. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/