--- 1/draft-ietf-mboned-embeddedrp-02.txt 2006-02-05 00:19:27.000000000 +0100 +++ 2/draft-ietf-mboned-embeddedrp-03.txt 2006-02-05 00:19:27.000000000 +0100 @@ -1,22 +1,22 @@ mboned Working Group P. Savola Internet Draft CSC/FUNET -Expiration Date: September 2004 +Expiration Date: October 2004 B. Haberman Caspian Networks - March 2004 + April 2004 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address - draft-ietf-mboned-embeddedrp-02.txt + draft-ietf-mboned-embeddedrp-03.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -44,47 +44,48 @@ Table of Contents 1. Introduction ............................................... 3 1.1. Background ............................................. 3 1.2. Solution ............................................... 3 1.3. Assumptions and Scope .................................. 4 1.4. Keywords ............................................... 4 2. Unicast-Prefix-based Address Format ........................ 4 3. Modified Unicast-Prefix-based Address Format ............... 5 - 4. Embedding the Address of the RP in the Multicast Address ... 5 + 4. Embedding the Address of the RP in the Multicast Address ... 6 5. Examples ................................................... 7 5.1. Example 1 .............................................. 7 - 5.2. Example 2 .............................................. 7 + 5.2. Example 2 .............................................. 8 5.3. Example 3 .............................................. 8 5.4. Example 4 .............................................. 8 6. Operational Considerations ................................. 8 6.1. RP Redundancy .......................................... 8 - 6.2. RP Deployment .......................................... 8 + 6.2. RP Deployment .......................................... 9 6.3. Guidelines for Assigning IPv6 Addresses to RPs ......... 9 - 6.4. Use as a Substitute for BSR ............................ 9 - 7. The Embedded-RP Group-to-RP Mapping Mechanism .............. 9 - 7.1. PIM-SM Group-to-RP Mapping ............................. 9 + 6.4. Use as a Substitute for BSR ............................ 10 + 7. The Embedded-RP Group-to-RP Mapping Mechanism .............. 10 + 7.1. PIM-SM Group-to-RP Mapping ............................. 10 7.2. Overview of the Model .................................. 10 8. Scalability Analysis ....................................... 11 9. Acknowledgements ........................................... 12 - 10. Security Considerations ................................... 12 - 11. References ................................................ 13 - 11.1. Normative References .................................. 13 - 11.2. Informative References ................................ 13 - Authors' Addresses ............................................. 14 - A. Discussion about Design Tradeoffs .......................... 14 - B. Changes .................................................... 15 - B.1 Changes since -01 ....................................... 15 - B.2 Changes since -00 ....................................... 15 - Intellectual Property Statement ................................ 16 - Full Copyright Statement ....................................... 16 + 10. Security Considerations ................................... 13 + 11. References ................................................ 14 + 11.1. Normative References .................................. 14 + 11.2. Informative References ................................ 14 + Authors' Addresses ............................................. 15 + A. Discussion about Design Tradeoffs .......................... 15 + B. Changes .................................................... 16 + B.1 Changes since -02 ....................................... 16 + B.2 Changes since -01 ....................................... 16 + B.3 Changes since -00 ....................................... 16 + Intellectual Property Statement ................................ 17 + Full Copyright Statement ....................................... 17 1. Introduction 1.1. Background As has been noticed [V6MISSUES], there exists a deployment problem with global, interdomain IPv6 multicast: PIM-SM [PIM-SM] RPs have no way of communicating the information about (active) multicast sources to other multicast domains, as Multicast Source Discovery Protocol (MSDP) [MSDP] has not been, on purpose, specified for IPv6. @@ -157,46 +158,50 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Unicast-Prefix-based Address Format As described in [RFC3306], the multicast address format is as follows: | 8 | 4 | 4 | 8 | 8 | 64 | 32 | - +--------+----+----+--------+--------+----------------+----------+ + +--------+----+----+--------+----+----------------+----------+ |11111111|flgs|scop|reserved| plen | network prefix | group ID | - +--------+----+----+--------+--------+----------------+----------+ + +--------+----+----+--------+----+----------------+----------+ Where flgs are "0011". (The first two bits have been yet undefined, sent as zero and ignored on receipt.) 3. Modified Unicast-Prefix-based Address Format This memo specifies a modification to the unicast-prefix-based address format: - 1. If the second high-order bit in "flgs" is set to 1, the address + 1. If the two high-order bits in "flgs" are set to 01, the address of the RP is embedded in the multicast address, as described in this memo. - 2. If the second high-order bit in "flgs" is set to 1, interpret + 2. If the two high-order bit in "flgs" are set to 01, interpret the last low-order 4 bits of "reserved" field as signifying the RP interface ID ("RIID"), as described in this memo. + The encoding and the protocol mode used when the two high-order bit + in "flgs" are set to 11 is intentionally unspecified until such time + that the highest-order bit is defined. + In consequence, the address format becomes: | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | - +--------+----+----+----+----+--------+----------------+----------+ + +--------+----+----+----+----+----+----------------+----------+ |11111111|flgs|scop|rsvd|RIID| plen | network prefix | group ID | - +--------+----+----+----+----+--------+----------------+----------+ + +--------+----+----+----+----+----+----------------+----------+ +-+-+-+-+ flgs is a set of 4 flags: |0|R|P|T| +-+-+-+-+ R = 1 indicates a multicast address that embeds the address on the RP. Then P MUST be set to 1, and consequently T MUST be set to 1, as specified in [RFC3306]. In the case that R = 1, the last 4 bits of the previously reserved field are interpreted as embedding the RP interface ID, as specified @@ -210,21 +215,22 @@ 4. Embedding the Address of the RP in the Multicast Address The address of the RP can only be embedded in unicast-prefix -based ASM addresses. That is, to identify whether an address is a multicast address as specified in this memo and to be processed any further, it must satisfy all of the below: o it MUST be a multicast address and have R, P, and T flag bits set - to 1 (that is, be part of the prefixes FF70::/12 or FFF0::/12), + to 1 -- that is, be part of the prefix FF70::/12 (note that + FFF0::/12 is unspecified), o "plen" MUST NOT be 0 (ie. not SSM), and o "plen" MUST NOT be greater than 64. The address of the RP can be obtained from a multicast address satisfying the above criteria by taking the two steps: 1. copy the first "plen" bits of the "network prefix" to a zeroed 128-bit address structure, and @@ -260,23 +266,24 @@ When processing an encoding to get the RP address, the multicast routers MUST perform at least the same address validity checks to the calculated RP address as to one received via other means (like BSR [BSR] or MSDP for IPv4). At least fe80::/10, ::/16, and ff00::/8 MUST be excluded. This is particularly important as the information is obtained from an untrusted source, i.e., any Internet user's input. One should note that the 4 bits reserved for "RIID" set the upper bound for RPs for the combination of scope, network prefix, and group - ID -- without varying any of these, you can have 4 bits worth of - different RPs. However, each of these is an IPv6 group address of - its own (i.e., there can be only one RP per multicast address). + ID -- without varying any of these, you can 2^4-1 = 15 different RPs + (as RIID=0 is reserved). However, each of these is an IPv6 group + address of its own (i.e., there can be only one RP per multicast + address). 5. Examples Four examples of multicast address allocation and resulting group-to- RP mappings are described here, to better illustrate the possibilities provided by the encoding. 5.1. Example 1 The network administrator of 2001:DB8::/32 wants to set up an RP for @@ -287,21 +294,21 @@ FF7x:y20:2001:DB8:zzzz:zzzz: Where "x" is the multicast scope, "y" the interface ID of the RP address, and "zzzz:zzzz" will be freely assignable to anyone. In this case, the address of the RP would be: 2001:DB8::y (and "y" could be anything from 1 to F, as 0 must not be used); the - address 2001:DB8::y/128 is added on a router as a loopback address + address 2001:DB8::y/128 is assigned to a router as a loopback address and injected to the routing system. 5.2. Example 2 As in Example 1, the network administrator can also allocate multicast addresses like "FF7x:y20:2001:DB8:DEAD::/80" to some of customers. In this case the RP address would still be "2001:DB8::y". Note the second rule of deriving the RP address: the "plen" field in the multicast address, 0x20 = 32, refers to the length of "network @@ -326,22 +333,22 @@ 5.4. Example 4 In the above networks, if the administrator wants to specify the RP to be in a non-zero /64 subnet, (s)he could always use something like "FF7x:y40:2001:DB8:BEEF:FEED::/96", and then their RP address would be "2001:DB8:BEEF:FEED::y". There are still 32 bits of multicast group-id's to assign to customers and self. 6. Operational Considerations - This desction describes the major operational considerations for - those deploying this mechanism. + This section describes the major operational considerations for those + deploying this mechanism. 6.1. RP Redundancy A technique called "Anycast RP" is used within a PIM-SM domain to share an address and multicast state information between a set of RP's mainly for redundancy purposes. Typically, MSDP has been used for that as well [ANYCASTRP]. There are also other approaches, like using PIM for sharing this information [ANYPIMRP]. RP failover cannot be used with this specification without additional @@ -382,58 +389,54 @@ If an administrator wishes to use an RP address that does not conform to the addressing topology but is still from the network provider's prefix (e.g., an additional loopback address assigned on a router, as described in example 1 in Section 5.1), that address can be injected into the routing system via a host route. 6.4. Use as a Substitute for BSR With embedded-RP, use of BSR or other RP configuration mechanisms throughout the PIM domain is not necessary, as each group address - specifies the RP to be used. + specifies how the RP to be used. 7. The Embedded-RP Group-to-RP Mapping Mechanism This section specifies the group-to-RP mapping mechanism works for Embedded RP. 7.1. PIM-SM Group-to-RP Mapping The only PIM-SM modification required is implementing this mechanism as one group-to-RP mapping method. The implementation will have to recognize the address format and derive and use the RP address using the rules in Section 4. This information is used at least when performing Reverse Path Forwarding (RPF) lookups, when processing Join/Prune messages, or performing Register-encapsulation. To avoid loops and inconsistancies, the group-to-RP mapping specified in this memo MUST be used for all embedded-RP groups (i.e., addresses - with prefix FF70::/12 or FFF0::/12). + with prefix FF70::/12). It is worth noting that compared to the other group-to-RP mapping mechanisms, which can be precomputed, the embedded-RP mapping must be redone for every new IPv6 group address which would map to a different RP. For efficiency, the results may be cached in an implementation-specific manner, to avoid computation for every embedded-RP packet. - This group-to-RP mapping mechanism must be supported by the DR - adjacent to the senders and any router on the path from any receiver - to the RP. Further, as the switch-over to Shortest Path Tree (SPT) - is also possible, it must be supported on the path between the - receivers and the senders as well. It also must be supported by any - router on the path from any sender to the RP -- in case the RP issues - a Register-Stop and Joins the sources. So, in practice, the - mechanism must be supported by all routers on any path between the - RP, receivers, and senders. + This group-to-RP mapping mechanism must be supported by the RP, the + DR adjacent to the senders and any router on the path from any + receiver to the RP. Paths for Shortest Path Tree (SPT) formation and + Register-Stop do not require the support, as those are accomplished + with an (S,G) Join. 7.2. Overview of the Model This section gives a high-level, non-normative overview of how Embedded RP operates, as specified in the previous section. The steps when a receiver wishes to join a group are: 1. A receiver finds out a group address from some means (e.g., SDR or a web page). @@ -494,24 +497,24 @@ As the address of the RP is tied to the multicast address, the RP failure management becomes more difficult, as failover or redundancy mechanisms (e.g., BSR, Anycast-RP with MSDP) cannot be used as-is. On the other hand, Anycast-RP using PIM could be used. This described briefly in Section 6.1. The PIM-SM specification states, "Any RP address configured or learned MUST be a domain-wide reachable address". What "reachable" precisely means is not clear, even without embedded-RP. This statement cannot be proven especially with the foreign RPs as one can - not even guarantee that the RP exists. Instead of configuring RPs - and DRs with a manual process (configuring a non-existent RP was - possible though rare), with this specification the hosts and users - using multicast indirectly specify the RP themselves, lowering the + not even guarantee that the RP exists. Instead of manually + configuring RPs and DRs (configuring a non-existent RP was possible + though rare), with this specification the hosts and users using + multicast indirectly specify the RP themselves, lowering the expectancy of the RP reachability. This is a relatively significant problem but not much different from the current multicast deployment: e.g., MLDv2 (S,G) joins, whether ASM or SSM, yield the same result [PIMSEC]. Being able to join/send to remote RPs raises security concerns that are considered separately, but it has an advantage too: every group has a "responsible RP" which is able to control (to some extent) who are able to send to the group. @@ -520,44 +523,57 @@ SSM) and their security properties has been described in [PIMSEC]. 9. Acknowledgements Jerome Durand commented on an early draft of this memo. Marshall Eubanks noted an issue regarding short plen values. Tom Pusateri noted problems with an earlier SPT-join approach. Rami Lehtonen pointed out issues with the scope of SA-state and provided extensive commentary. Nidhi Bhaskar gave the draft a thorough review. Toerless Eckert, Hugh Holbrook, and Dave Meyer provided very - extensive feedback. The whole MboneD working group is also - acknowledged for the continued support and comments. + extensive feedback. In particular, Pavlin Radoslavov, Dino + Farinacci, and Nidhi Bhaskar provided good comments during and after + WG last call. The whole MboneD working group is also acknowledged + for the continued support and comments. 10. Security Considerations - The address of the RP is encoded in the multicast address -- and thus - become more visible as single points of failure. Even though this - does not significantly affect the multicast routing security, it may - expose the RP to other kinds of attacks. The operators are + The addresses of RPs are encoded in the multicast addresses -- and + thus become more visible as single points of failure. Even though + this does not significantly affect the multicast routing security, it + may expose the RP to other kinds of attacks. The operators are encouraged to pay special attention to securing these routers. See Section 6.1 on considerations regarding failover and Section 6.2 on placement of RPs leading to a degree of fate-sharing properties. As any RP will have to accept PIM-SM Join/Prune/Register messages from any DR, this might cause a potential DoS attack scenario. However, this can be mitigated by the fact that the RP can discard all such messages for all multicast addresses that do not encode the - address of the RP. The implementation MAY also allow manual - configuration of which multicast addresses or prefixes embedding the - RP could be used. + address of the RP. Both the sender- and receiver-based attacks are + described at more length in [PIMSEC]. - In a similar fashion, when a receiver joins to an RP, the DRs must - accept similar PIM-SM messages back from RPs. However, this is not a - considerable threat. + Additionally the implementation MAY also allow manual configuration + of which multicast addresses or prefixes embedding the RP are allowed + to be used. This can be used to limit the use of the RP to + designated groups only. In some cases, it is desirable to be able to + restrict (at the RP) which unicast addresses are allowed to send or + join to a group. (However, note that Join/Prune messages would still + leave state in the network, and Register messages can be spoofed + [PIMSEC].) Obviously, these controls are only possible at the RP, + not at the intermediate routers or the DR. + + It is recommended that routers supporting this specification do not + act as RPs unless explicitly configured to do so; as becoming an RP + does not require any advertisement (e.g., through BSR or manually), + otherwise any router could potentially become an RP (and be abused as + such). One should observe that the embedded-RP threat model is actually rather similar to SSM; both mechanisms significantly reduce the threats at the sender side. On the receiver side, the threats are somewhat comparable, as an attacker could do an MLDv2 (S,G) join towards a non-existent source, which the local RP could not block based on the MSDP information. The implementation MUST perform at least the same address validity checks to the embedded-RP address as to one received via other means; @@ -580,41 +596,41 @@ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3306] Haberman, B., Thaler, D., "Unicast-Prefix-based IPv6 Multicast Addresses", RFC3306, August 2002. 11.2. Informative References [ANYCAST] Hagino, J., Ettikan, K., "An analysis of IPv6 - anycast", work-in-progress, - draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt, June 2003. + anycast", work-in-progress, draft-ietf-ipngwg-ipv6- + anycast-analysis-02.txt, June 2003. [ANYCASTRP] Kim, D. et al, "Anycast RP mechanism using PIM and MSDP", RFC 3446, January 2003. [ANYPIMRP] Farinacci, D., Cai, Y., "Anycast-RP using PIM", work-in-progress, draft-ietf-pim-anycast-rp-00.txt, November 2003. [BSR] Fenner, B., et al., "Bootstrap Router (BSR) Mechanism for PIM Sparse Mode", work-in-progress, draft-ietf-pim-sm- bsr-03.txt, February 2003. [MSDP] Meyer, D., Fenner, B, (Eds.), "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003. [PIMSEC] Savola, P., Lehtonen, R., Meyer, D., "PIM-SM Multicast Routing Security Issues and Enhancements", - work-in-progress, draft-savola-mboned-mroutesec-00.txt, - January 2004. + work-in-progress, draft-ietf-mboned-mroutesec-00.txt, + April 2004. [PIM-SM] Fenner, B. et al, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised), work-in-progress, draft-ietf-pim-sm-v2-new-09.txt, February 2004. [SSM] Holbrook, H. et al, "Source-Specific Multicast for IP", work-in-progress, draft-ietf-ssm-arch-04.txt, October 2003. @@ -631,20 +647,29 @@ Brian Haberman Caspian Networks One Park Drive, Suite 300 Research Triangle Park, NC 27709 EMail: brian@innovationslab.net Phone: +1-919-949-4828 A. Discussion about Design Tradeoffs + The document only specifies FF70::/12 for now; if/when the upper-most + bit is used, one must specify how FFF0::/12 applies to Embedded-RP. + For example, a different mode of PIM or another protocol might use + that range, in contrast to FF70::/12, as currently specified, being + for PIM-SM only. + + Instead of using flags bits ("FF70::/12"), one could have used the + left-most reserved bits instead ("FF3x:8000::/17"). + It has been argued that instead of allowing the operator to specify RIID, the value could be pre-determined (e.g., "1"). However, this has not been adopted, as this eliminates address assignment flexibility from the operator. Values 64 < "plen" < 96 would overlap with upper bits of the multicast group-id; due to this restriction, "plen" must not exceed 64 bits. This is in line with RFC 3306. The embedded-RP addressing could be used to convey other information @@ -653,39 +678,46 @@ encoded in the RP address somehow, or in the multicast group address. In any case, such modifications are beyond the scope of this memo. For the cases where the RPs do not exist or are unreachable, or too much state is being generated to reach in a resource exhaustion DoS attack, some forms of rate-limiting or other mechanisms could be deployed to mitigate the threats while trying not to disturb the legitimate usage. However, as the threats are generic, they are considered out of scope and discussed separately in [PIMSEC]. - The mechanism is not usable with Bidirectional PIM without protocol - extensions, as pre-computing the Designated Forwarder is not - possible. - B. Changes [[ RFC-Editor: please remove before publication ]] - B.1 Changes since -01 + B.1 Changes since -02 + + o Clarified security considerations, wrt. RPs being abused by third + parties and policy controls at the RP. + o Clarified that only RPs, DRs next to sources sending to embedded- + RP groups, and routers between the receivers and the RPs need to + have support this mapping. + o Try to be clearer that FF70::/12 is meant for PIM-SM at the + moment, while FFF0::/12 is unspecified. + o Minor miscellaneous changes. + + B.2 Changes since -01 o Lots of editorial cleanups and some reorganization, without technical changes. o Remove the specification that RIID=0 SHOULD NOT be accepted, but state that they "must not" be used (implementation vs. operational wording). o Specify that the RP address MUST NOT be of prefixes fe80::/10, ::/16, or ff00::/8. - B.2 Changes since -00 + B.3 Changes since -00 o Lots of editorial cleanups, or cleanups without techinical changes. o Reinforce the notion of Embedded RP just being a group-to-RP mapping mechanism (causing substantive rewriting in section 7); highlight the fact that precomputing the group-to-RP mapping is not possible. o Add (a bit) more text on RP redundancy and deployment tradeoffs wrt. RPs becoming SPoF. o Clarify the usability/scalability issues in section 8.