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