< draft-ietf-pim-sm-bsr-11.txt   draft-ietf-pim-sm-bsr-12.txt >
Internet Engineering Task Force PIM WG Internet Engineering Task Force PIM WG
INTERNET-DRAFT Nidhi Bhaskar/Arastra INTERNET-DRAFT Nidhi Bhaskar/Arastra
draft-ietf-pim-sm-bsr-11.txt Alexander Gall/SWITCH draft-ietf-pim-sm-bsr-12.txt Alexander Gall/SWITCH
James Lingard/Arastra James Lingard/Arastra
Stig Venaas/UNINETT Stig Venaas/UNINETT
9 July 2007 3 August 2007
Expires: January 2008 Expires: February 2008
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 39 skipping to change at page 3, line 39
3.6. Receiving and Using the RP-Set . . . . . . . . . . . 25 3.6. Receiving and Using the RP-Set . . . . . . . . . . . 25
4. Message Formats . . . . . . . . . . . . . . . . . . . . 25 4. Message Formats . . . . . . . . . . . . . . . . . . . . 25
4.1. Bootstrap Message Format . . . . . . . . . . . . . . 28 4.1. Bootstrap Message Format . . . . . . . . . . . . . . 28
4.1.1. Semantic Fragmentation of BSMs. . . . . . . . . . 31 4.1.1. Semantic Fragmentation of BSMs. . . . . . . . . . 31
4.2. Candidate-RP-Advertisement Message Format. . . . . . 33 4.2. Candidate-RP-Advertisement Message Format. . . . . . 33
5. Timers and Timer Values . . . . . . . . . . . . . . . . 35 5. Timers and Timer Values . . . . . . . . . . . . . . . . 35
6. Security Considerations . . . . . . . . . . . . . . . . 38 6. Security Considerations . . . . . . . . . . . . . . . . 38
6.1. Possible Threats . . . . . . . . . . . . . . . . . . 38 6.1. Possible Threats . . . . . . . . . . . . . . . . . . 38
6.2. Limiting Third-Party DoS Attacks . . . . . . . . . . 39 6.2. Limiting Third-Party DoS Attacks . . . . . . . . . . 39
6.3. Bootstrap Message Security . . . . . . . . . . . . . 39 6.3. Bootstrap Message Security . . . . . . . . . . . . . 39
6.3.1. Rejecting Bootstrap Messages from Invalid 6.3.1. Unicast Bootstrap Messages. . . . . . . . . . . . 39
Neighbors . . . . . . . . . . . . . . . . . . . . 40 6.3.2. Multi-access subnets. . . . . . . . . . . . . . . 40
6.4. Candidate-RP-Advertisement Message Security. . . . . 40 6.4. Candidate-RP-Advertisement Message Security. . . . . 41
6.4.1. Non-Cryptographic Security of C-RP-Adv 6.4.1. Non-Cryptographic Security of C-RP-Adv
Messages. . . . . . . . . . . . . . . . . . . . . 41 Messages. . . . . . . . . . . . . . . . . . . . . 41
6.4.2. Cryptographic Security of C-RP-Adv 6.4.2. Cryptographic Security of C-RP-Adv
Messages. . . . . . . . . . . . . . . . . . . . . 41 Messages. . . . . . . . . . . . . . . . . . . . . 41
6.5. Denial of Service using IPsec. . . . . . . . . . . . 41 6.5. Denial of Service using IPsec. . . . . . . . . . . . 41
7. Contributors. . . . . . . . . . . . . . . . . . . . . . 42 7. Contributors. . . . . . . . . . . . . . . . . . . . . . 42
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 42 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . 42
9. IANA Considerations . . . . . . . . . . . . . . . . . . 42 9. IANA Considerations . . . . . . . . . . . . . . . . . . 42
10. Normative References . . . . . . . . . . . . . . . . . 42 10. Normative References . . . . . . . . . . . . . . . . . 42
11. Informative References . . . . . . . . . . . . . . . . 43 11. Informative References . . . . . . . . . . . . . . . . 43
skipping to change at page 13, line 20 skipping to change at page 13, line 20
The initial state for this configured scope zone is "Pending-BSR"; the The initial state for this configured scope zone is "Pending-BSR"; the
Bootstrap Timer is initialized to BS_Rand_Override. This is the case Bootstrap Timer is initialized to BS_Rand_Override. This is the case
both if the router is a Candidate BSR at startup, and if reconfigured to both if the router is a Candidate BSR at startup, and if reconfigured to
become one later. become one later.
3.1.2. Per-Scope-Zone State Machine for Non-Candidate-BSR Routers 3.1.2. Per-Scope-Zone State Machine for Non-Candidate-BSR Routers
The following state machine is used for scope zones which are discovered The following state machine is used for scope zones which are discovered
by the router from bootstrap messages. A simplified state machine is by the router from bootstrap messages. A simplified state machine is
used for scope zones which are explicitely configured on the router and used for scope zones which are explicitly configured on the router and
for the global zone. The differences are listed at the end of this for the global zone. The differences are listed at the end of this
section. section.
+-----------------------------------------------------------------------+ +-----------------------------------------------------------------------+
| When in NoInfo state | | When in NoInfo state |
+---------------------+-------------------------------------------------+ +---------------------+-------------------------------------------------+
| Event | Receive BSM | | Event | Receive BSM |
+---------------------+-------------------------------------------------+ +---------------------+-------------------------------------------------+
| | -> AP state | | | -> AP state |
| Action | Forward BSM; Store RP-Set; | | Action | Forward BSM; Store RP-Set; |
skipping to change at page 15, line 5 skipping to change at page 15, line 5
o The Bootstrap Timer (BST) - used to time out old bootstrap router o The Bootstrap Timer (BST) - used to time out old bootstrap router
information. information.
o The Scope-Zone Expiry Timer (SZT) - used to time out the scope zone o The Scope-Zone Expiry Timer (SZT) - used to time out the scope zone
itself if Bootstrap messages specifying this scope zone stop arriving. itself if Bootstrap messages specifying this scope zone stop arriving.
The initial state for scope zones about which the router has no The initial state for scope zones about which the router has no
knowledge is "NoInfo". knowledge is "NoInfo".
The state machine used for scopes which have been configured explicitely The state machine used for scopes which have been configured explicitly
on the router and for the global scope, which always exists, differs on the router and for the global scope, which always exists, differs
from the state machine above as follows. from the state machine above as follows.
o The "NoInfo" state doesn't exist. o The "NoInfo" state doesn't exist.
o No SZT is maintained. Hence, the event "Scope-Zone Expiry Timer o No SZT is maintained. Hence, the event "Scope-Zone Expiry Timer
Expires" does not exist and no actions with regard to this timer Expires" does not exist and no actions with regard to this timer
are executed. are executed.
The initial state for this state machine is "Accept Any". The initial state for this state machine is "Accept Any".
skipping to change at page 25, line 40 skipping to change at page 25, line 40
routing protocol is also not part of the present specification. routing protocol is also not part of the present specification.
Some group-to-RP mappings in the RP-Set indicate group ranges for which Some group-to-RP mappings in the RP-Set indicate group ranges for which
PIM-SM should be used; others indicate group ranges for use with BIDIR- PIM-SM should be used; others indicate group ranges for use with BIDIR-
PIM. Routers that only support one of these protocols MUST NOT ignore PIM. Routers that only support one of these protocols MUST NOT ignore
ranges indicated as being for the other protocol. They MUST NOT treat ranges indicated as being for the other protocol. They MUST NOT treat
them as being for the protocol they support. them as being for the protocol they support.
If a mapping is not already part of the RP-Set, it is added to the RP- If a mapping is not already part of the RP-Set, it is added to the RP-
Set and the associated Group-to-RP mapping Expiry Timer (GET) is Set and the associated Group-to-RP mapping Expiry Timer (GET) is
initialized to the holdtime from the Bootstrap Message. Its priority is initialized to the holdtime from the Bootstrap message. Its priority is
set to the Priority from the Bootstrap Message. set to the Priority from the Bootstrap message.
If a mapping is already part of the RP-Set, it is updated with the If a mapping is already part of the RP-Set, it is updated with the
Priority from the Bootstrap Message and its associated GET is reset to Priority from the Bootstrap message and its associated GET is reset to
the holdtime from the Bootsrap Message. If the holdtime is zero, the the holdtime from the Bootstrap message. If the holdtime is zero, the
mapping is removed from the RP-Set immediately. mapping is removed from the RP-Set immediately.
4. Message Formats 4. Message Formats
BSR messages are PIM messages, as defined in [1]. The values of the PIM BSR messages are PIM messages, as defined in [1]. The values of the PIM
Message Type field for BSR messages are: Message Type field for BSR messages are:
4 Bootstrap 4 Bootstrap
8 Candidate-RP-Advertisement 8 Candidate-RP-Advertisement
skipping to change at page 39, line 26 skipping to change at page 39, line 26
to the implementer 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 in a domain is compromised, there is little
mechanism can do to prevent that router subverting PIM traffic in that any security mechanism can do to prevent that router subverting PIM
domain. However we recommend that implementers provide a mechanism traffic in that domain.
whereby a PIM router using the BSR mechanisms can be configured with the
IP addresses of valid BSR routers, and that any Bootstrap message with a
non-valid BSR address should be dropped and logged as a security issue.
Due to the RPF check of the BSR address, it will not be trivial to
inject messages with a spoofed BSR address. We recommend not to enable
this mechanism by default, as it makes the initial configuration of a
PIM domain problematic - it is the sort of feature that the
administrator might enable once the configuration of a domain has
stabilized.
The primary security requirement for BSR (as for PIM) is that it is Implementations SHOULD provide a per interface configuration option
possible to prevent hosts that are not legitimate PIM routers, either where one can specify that no Bootstrap messages are to be sent out of
within or outside the domain, from subverting the BSR mechanism. or accepted on the interface. This should generally be configured on
all PMBRs in order to not receive messages from neighboring domains.
This avoids receiving legitimate messages with conflicting BSR
information from other domains, and also prevents BSR attacks from
neighboring domains. This option is also useful on leaf interfaces
where there are only hosts present. However, the Security
Considerations section of [1], state that there should be a mechanism
for not accepting PIM Hello messages on leaf interfaces and messages are
only accepted from valid PIM neighbors. There may however be additional
issues with unicast Bootstrap messages, see below. In addition to
dropping all multicast Bootstrap messages on PMBRs we also recommend
configuring PMBRs (both towards other domains and on leaf interfaces) to
drop all unicast PIM messages (Bootstrap message, Candidate RP
Advertisement, PIM register and PIM register stop).
6.3.1. Unicast Bootstrap Messages
There are some possible security issues with unicast Bootstrap Messages.
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. The best way to protect against this is to use the above
filtering to prevent packets entering the PIM domain with IP source mentioned mechanism configuring border and leaf interfaces to drop all
addresses that are infrastructure addresses in the PIM domain. It might bootstrap messages, including unicast messages. This can also be
also be a good idea to configure the PMBRs to not accept any Bootstrap prevented if PMBRs perform source-address filtering to prevent packets
messages from outside the domain. One might configure the PMBRs to drop entering the PIM domain with IP source addresses that are infrastructure
all unicast PIM messages (Bootstrap message, Candidate RP Advertisement, addresses in the PIM domain.
PIM register and PIM register stop).
The principal threat to Bootstrap message security comes from hosts
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
by unicasting a Bootstrap message to another PIM router during the brief
interval after it has restarted.
The use of unicast BSMs is for backwards compatibility only. Due to the
possible security implications, implementations supporting unicast BSMs
should provide a configuration option for whether they are to be used.
6.3.1. Rejecting Bootstrap Messages from Invalid Neighbors The use of unicast Bootstrap messages is for backwards compatibility
only. Due to the possible security implications, implementations
supporting unicast Bootstrap messages SHOULD provide a configuration
option for whether they are to be used.
Most hosts that are likely to attempt to subvert PIM BSR are likely to 6.3.2. Multi-access subnets
be located on leaf subnets. We recommend that implementers provide a
configuration option that specifies an interface is a leaf subnet, and
that no PIM packets are accepted on such interfaces.
On multi-access subnets with multiple PIM routers and hosts that are not As mentioned above, implementations SHOULD provide a per interface
trusted, we recommend that IPsec AH is used to protect communication configuration option so that leaf interfaces and interfaces facing other
between PIM routers, and that such routers are configured to drop and domains can be configured to drop all Bootstrap messages. In this
log communication attempts from any host that do not pass the section we will consider multi-access subnets where there are both
multiple PIM routers in a PIM domain and also PIM routers outside the
PIM domain or non-trusted hosts. On such subnets one should if possible
configure the PMBRs to drop Bootstrap messages. This is possible
provided that the routers in the PIM domain receive Bootstrap messages
on other internal subnets. That is, for each of the routers on the
multi-access subnet that are in our domain, the RPF interface for each
of the candidate BSR addresses must be an internal interface (an
interface not on a multi-access subnet). There are however network
topologies where this is not possible. For such topologies, we
recommend that IPsec AH is used to protect communication between the PIM
routers in the domain, and that such routers are configured to drop and
log communication attempts from any node 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. In order to prevent replay attacks one will need to have one SA secret. In order to prevent replay attacks one will need to have one SA
per sender using the sender address for SA lookup. The securing of per sender using the sender address for SA lookup. The securing of
interactions between PIM neighbors is discussed in more detail in the interactions between PIM neighbors is discussed in more detail in the
Security Considerations section of [1], and so we do not discuss the Security Considerations section of [1], and so we do not discuss the
details further here. The same security mechanisms that can be used to details further here. The same security mechanisms that can be used to
secure PIM Join, Prune and Assert messages should also be used to secure secure PIM Join, Prune and Assert messages should also be used to secure
Bootstrap messages. How exactly to secure PIM link-local messages is Bootstrap messages. How exactly to secure PIM link-local messages is
still being worked on by the PIM working group, see [10]. still being worked on by the PIM working group, see [10].
skipping to change at page 43, line 23 skipping to change at page 43, line 32
[8] 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, January Multicast Source Discovery Protocol (MSDP)", RFC 3446, January
2003. 2003.
[9] D. Farinacci, Y. Cai, "Anycast-RP Using Protocol Independent [9] D. Farinacci, Y. Cai, "Anycast-RP Using Protocol Independent
Multicast (PIM)", RFC 4610, August 2006 Multicast (PIM)", RFC 4610, August 2006
[10] W. Atwood, S. Islam, "Security Issues in PIM-SM Link-local [10] W. Atwood, S. Islam, "Security Issues in PIM-SM Link-local
Messages", Internet Draft draft-ietf-pim-sm-linklocal-00, Work in Messages", Internet Draft draft-ietf-pim-sm-linklocal-01, Work in
Progress, October 2006. Progress, July 2007.
[11] IANA, "Address Family Numbers", linked from [11] 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
Arastra, Inc. Arastra, Inc.
P.O. Box 10905 P.O. Box 10905
Palo Alto, CA 94303 Palo Alto, CA 94303
 End of changes. 15 change blocks. 
55 lines changed or deleted 63 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/