Network Working Group Michael Brig
Internet-Draft Aegis BMD Program Office
Intended status: Standard Track 17211 Avenue D, Suite 160
Expires: November 20, 2011 Dahlgren, VA 22448-5148
Phone: 540-663-1919
Email: michael.brig@mda.mil
Deterministic RP (D-RP) Specification
draft-brigm-deterministicrp-00.txt
Copyright (c) 2011 IETF Trust and the persons identified as the document
authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents (http://trustee.ietf.org/license-info) in
effect on the date of publication of this document. Please review these
documents carefully, as they describe your rights and restrictions
with respect to this document.
This Internet-Draft is submitted in full conformance with the provisions
of BCP 78 and BCP 79. Internet-Drafts are working documents of the
Internet Engineering Task Force (IETF). Note that other groups may also
distribute working documents as Internet-Drafts. The list of current
Internet-Drafts is at http://datatracker.ietf.org/drafts/current.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet-Drafts as reference material or to
cite them other than as "work in progress."
Comments are solicited and should be addressed to the working group's
mailing list and/or the author(s).
Abstract
This document specifies the Deterministic Rendezvous Point (D-RP)
mechanism for Protocol Independent Multicast (PIM) Sparse Mode (SM)
networks. It intends to provide a simple and robust RP service.
The mechanism is deterministic since it elects the highest priority
candidate to be the D-RP from those available for each IP address family.
If a D-RP fails, the election process begins again using the remaining C-RPs
for the IP address family. If no candidates are availabe, the network will
transition to PIM Dense Mode (DM) routing for that IP address family.
In the future if C-RPs emerge for the address family, the network will
elect a new D-RP and return to operations with PIM SM routing.
1. Introduction
From [2], a PIM SM multicast domain requires at least one Rendezvous Point
(RP) and each RP may service one or more multicast groups. Concurrently,
each multicast group can be serviced by one and only one RP. This protocol
mechanism is intended for high availability, moderately sized, well managed,
and tightly controlled multicast domains; therefore, only a single RP will
be needed to service all multicast groups of each IP address family. If IPv4
and IPv6 multicast are simultaneously operational in a PIM SM domain running
this protocol, one D-RP will service IPv4 multicast while another D-RP will
service IPv6 multicast.
This mechanism provides a simple and fault tolerant RP service for IP multicast
domains. For this protocol to operate effectively, all routers in the PIM domain
must utilize it and be configured either as candidate-RPs (C-RPs) or non-candidates.
The mechanism will support IPv4 multicast by itself, IPv6 multicast by itself, or
IPv4 and IPv6 multicast operating simultaneously on the same infrastructure but
distinct from one other. The C-RP sets for IPv4 and IPv6 should, therefore, be
distinct and not intersect. In the later case, there would be at most one D-RP for
each IP address family at any time.
This mechanism is built upon reference [1] and reference [2] for PIM ver.2. It is
specifically not intended to operate with PIM ver.1.
2. Protocol Specification
During the D-RP election process, C-RPs periodically flood the PIM domain with
PIM type 8 "Candidate-RP-Advertisement" messages declaring their candidacy for
D-RP of the IP address family. The protocol will elect the candidate with the
highest priority to D-RP from the available C-RPs and any existing D-RP
of the IP address family. After election, the D-RP will periodically flood
the network with a new PIM ver.2 type 11 "elected-RP" message for the
duration of its operation as D-RP. If the D-RP fails, the election process
begins again using the remaining C-RPs for the IP address family. If no
candidates are availabe, the network will transition to PIM Dense Mode (DM)
routing for that IP address family. In the future if C-RPs emerge for the
address family, the network will elect a new D-RP and return to PIM SM
routing.
Alternately, the PIM ver.2 type 8 "Candidate-RP-Advertisement" message
defined in [3] could be modified by using a single bit from its reserve field
as the "Elected" (E) bit. When E = 0, the Candidate/Elected-RP (C/E-RP) message
would be a candidate-RP advertisement for that IP address family. When
E = 1, the (C/E-RP) message would be an elected-RP advertisement for that
IP address family.
Each IP address family will have 10 integer priority values ranging from 1 to
10 for the network administrator to assign relative importance to C-RPs.
It is believed that 10 C-RPs per IP address family represents the largest
practical set of C-RPs which a PIM ver.2 network may require. The greater
the priority value of the C-RP, the greater its relative importance to
the network. These value shall fill the priority fields of
Candidate-RP-Advertisement, Elected-RP-Advertisement, and Candidate/Elected-
RP-Advertisement messages when transmitted in the multicast domain.
When a Elected-RP-Advertisement message has a Holdtime = 0 or a
Candidate/Elected-RP-Adevertisemen message with E = 1 has a Holdtime = 0, the
E-RP Valid Time and Timer shall be considered infinite.
2.1 State Transitions for PIM ver.2 Routers configured as Candidate RPs.
On startup, Candidates enter C-RP state after transmitting a C-RP message,
setting the C-RP Xmit Timer, C-RP Valid Timer, and RP Election Timer.
+---------------------------------------------------------------------+
| When in Active C-RP state |
+------+---------------+---------------+--------------+---------------+
|Event |RP Election |Rcvd E-RP |C-RP Valid |Rcvd C-RP |
| |Expires |Message with |Timer Timeout.|message with |
| | |lower priority | |higher priority|
| | |than candidate.| |than candidate.|
+------+---------------+---------------+--------------+---------------+
| |-> |-> |-> |-> |
| |E-RP; |E-RP; |Standby C-RP; |Standby C-RP; |
|Action|Xmit E-RP |Xmit E-RP |Set RP Alive |Set RP Alive |
| |message, Set |message, Set |Timer. |Timer. |
| |E-RP Xmit |E-RP Xmit | | |
| |Timer, Set E-RP|Timer, Set E-RP| | |
| |valid Timer, |valid Timer. | | |
| |set RP Election|set RP Election| | |
| |Timer, set |Timer | | |
| |E-RP Valid | | | |
| |Timer | | | |
+------+---------------+---------------+--------------+---------------+
+-------------------------------------+
|When in Active C-RP state (continued)|
+------+----------------+-------------+
|Event |Rcvd E-RP |C-RP Xmit |
| |message with |Timeout |
| |higher priority | |
| |than candidate. | |
+------+----------------+-------------+
| |-> |-> |
| |Standby C-RP; |Active C-RP; |
|Action|Set RP Alive |Xmit C-RP |
| |Timer. |message; Set |
| | |C-RP Xmit |
| | |Timer. |
+------+----------------+-------------+
+--------------------------------------------------------------------+
| When in E-RP state |
+------+------------------+---------------------+--------------------+
|Event |rcvd C-RP message |E-RP Valid Timer |E-RP Xmit |
| |is higher priority|Timeout |Timeout |
| |than the priority | | |
| |of the Elected RP | | |
+------+------------------+---------------------+--------------------+
| |-> |-> |-> |
| |Standby C-RP; |Active C-RP; |E-RP; |
|Action|Set RP Alive |Xmit C-RP message, |Xmit E-RP message; |
| |Timer. |Set C-RP Xmit Timer. |Set E-RP Xmit Timer.|
| | |Set C-RP Valid Timer.| |
+------+------------------+---------------------+--------------------+
+--------------------------------------+
| When in Standby C-RP state |
+------+---------------+---------------+
|Event |RP Alive Timer |rcvd Elected RP|
| |expires |message |
+------+---------------+---------------+
| |-> |-> |
|Action|Active C-RP; |Standby C-RP; |
| |Xmit C-RP |Set RP Alive |
| |message, Set |Timer. |
| |C-RP Valid | |
| |Timer, Set C-RP| |
| |Xmit Timer, | |
| |set RP Election| |
| |Timer. | |
+------+---------------+---------------+
2.2 State Transition Diagrams for PIM ver.2 Routers configured as
non-candidates.
On startup, non-Candidates enters PIM DM RTR state.
+------------------------+
|When in PIM DM RTR state|
+------+-----------------+
|Event | rcvd Elected RP |
| | message |
+------+-----------------+
| | -> |
|Action| TRANSIENT; |
| | Set TRANSIENT |
| | Timer. |
+------+-----------------+
+------------------------------------+
| When in TRANSIENT state |
+------+-------------+---------------+
|Event |transient |rcvd Elected RP|
| |timer Timeout|message |
+------+-------------+---------------+
| |-> |-> |
|Action|PIM SM RTR |TRANSIENT; |
| |Set RP Alive | |
| |Timer. | |
+------+-------------+---------------+
+-------------------------------------+
| When in PIM SM RTR state |
+------+------------------------------+
|Event |RP Alive Timer|rcvd Elected RP|
| |expires |message |
+------+--------------+---------------+
| |-> |-> |
|Action|PIM DM RTR. |PIM SM RTR; |
| | |Set RP Alive |
| | |Timer. |
+------+--------------+---------------+
3. PIM ver.2 Messages
3.1 Candidate-RP-Advertisement Message (Type=8) for IPv6.
This mechanism utilizes the PIM ver.2 type 8 "candidate-RP-Advertisement"
message as defined in [3]. This message will flood the PIM domain
periodically to announce the candidacy of a potential RP for
D-RP. Both IPv4 multicast and IPv6 multicast are supported by This
message but only IPv6 is illustrated for the sake of brevity.
PIM VER = 2
Type = 8
Prefix Count = 1
IPv6 Group Address is the entire IPv6 multicast address range.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Count | Priority | Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C-RP IPv6 Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Group Address (Encoded-Mulicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.2 Elected-RP-Advertisement Message (type = 11) proposed for IPv6.
This mechanism could utilize a new PIM ver.2 type 11
"elected-RP-Advertisement" message. It is a means of determining Group to
RP mappings. The message would be defined identically to the
"candidate-RP-Advertisement" defined in [3] with the exception that the
type field would be set to 11. This message would flood the PIM domain
periodically to announce the D-RP. Only the D-RP should utilize this
message at any time. Both IPv4 multicast and IPv6 multicast are supported
by This message but only IPv6 is illustrated for the sake of brevity.
PIM VER = 2
Type = 11
Prefix Count = 1
IPv6 Group Address is the entire IPv6 multicast address range.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type | Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Count | Priority | Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| E-RP IPv6 Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Group Address (Encoded-Mulicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.3 Candidate/Elected-RP-Advertisement Message (type=8) proposed for IPv6.
As an alternative to the PIM type 11 "elected-RP-advertisement" message, this
mechanism could utilize a modified PIM ver.2 type 8 "candidate-RP-advertisement"
message renamed the "candidate/elected-RP-Advertisement" message. It is a means
of determining Group to RP mappings. This would be defined identically to the
"candidate-RP-Advertisement" defined in [3] with the exception of a new one bit
"elected" field taken from the reserve bits. This message would flood the PIM
domain periodically to announce the D-RP or candidate RPs. Only one PIM router,
the D-RP, should utilize this message with the "elected" bit set to 1 while many
PIM Routers could utilize this message with the "elected" bit set to 0. Both IPv4
multicast and IPv6 multicast are supported by This message but only IPv6 is
illustrated for the sake of brevity.
PIM VER = 2
Type = 8
Prefix Count = 1
E = 0; Candidate-RP Message
E = 1; Elected-RP Message
IPv6 Group Address is the entire IPv6 multicast address range.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PIM Ver| Type |E| Reserved | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Count | Priority | Holdtime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| C/E-RP IPv6 Address (Encoded-Unicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Group Address (Encoded-Mulicast format) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5 State Information and Timers
5.1 RP Election Timer - default of 4 seconds.
5.2 C-RP Transmit Timer - default of 1 second.
5.3 C-RP Valid Timer - set to a configured value and transmitted in the
Candidate-RP-Advertisement message or the
Candidate/Elected-RP-Advertisement message.
5.4 E-RP Transmit Timer - default of 1 second.
5.5 E-RP Valid Timer - set to a configured value and transmitted in the
Elected-RP-Advertisement message or the
Candidate/Elected-RP-Advertisement message.
5.6 RP Alive Timer - default of 5 seconds.
5.7 Transcient Timer - default of 3 seconds.
6 Security Considerations
Since D-RP is specifically designed to provide a reliable and fault-tolerant RP
service for PIM SM multicast networks, it is vulnerable to the security
considerations and mitigations outlined in [5] and [6] while a D-RP is
operational. D-RP is vulnerable to routers mascarading as C-RPs and D-RPs with
and without high configured priority values. It is vulnerable to denial of
service if an attacker could sufficiently flood the IP multicast domain with data
and therefore prevent the majority of the PIM routers from receiving timely C-RP
and D-RP messages.
When an D-RP cannot be elected, this mechanism falls back to PIM DM
operations until a C-RP becomes available, and a new D-RP is elected. While in
DM, it is vulnerable to the security considerations and mitigations outlined in
[1].
7 Contributors
LCDR Charles Schlice
AEGIS BMD B33
540-663-1763
charles.schlise@mda.mil
Jeff Chaney
AEGIS BMD B33C
540-663-1790
Jeff.chaney@mda.mil
Thomas Tharp
IO Technologies
540-663-1865
thomas.tharp.ctr@mda.mil
8 References
[1] Adams, A., Nicholas, J., Siadak, W.,
"Protocol Independent Multicast - Dense Mode (PIM-DM):
Protocol Specification (Revised)", RFC 3973, January 2005
[2] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[3] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas,
"Bootstrap Router (BSR) Mechanism for Protocol Independent
Multicast (PIM)", RFC 5059, January 2008.
[4] Venaas, S.,
"A Registry for PIM Message Types", RFC 6166, April 2011
[5] Savola, P., Lehtonen, R., Meyer, D.
"Protocol Independent Multicast - Sparse Mode (PIM-SM)
Multicast Routing Security Issues and Enhancements",
RFC 4609, August 2006.
[6] Atwood, W., Islam, S., Siami, M.,"Authentication and
Confidentiality in Protocol Independent Multicast Sparse
Mode (PIM-SM) Link-Local Messages", RFC 4601, March 2010