--- 1/draft-ietf-mboned-embeddedrp-03.txt 2006-02-05 00:19:28.000000000 +0100 +++ 2/draft-ietf-mboned-embeddedrp-04.txt 2006-02-05 00:19:28.000000000 +0100 @@ -2,21 +2,21 @@ mboned Working Group P. Savola Internet Draft CSC/FUNET Expiration Date: October 2004 B. Haberman Caspian Networks April 2004 Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address - draft-ietf-mboned-embeddedrp-03.txt + draft-ietf-mboned-embeddedrp-04.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. @@ -41,64 +41,67 @@ mechanism. This allows an easy deployment of scalable inter-domain multicast, and simplifies the intra-domain multicast configuration as well. This memo updates the addressing format presented in RFC 3306. Table of Contents 1. Introduction ............................................... 3 1.1. Background ............................................. 3 1.2. Solution ............................................... 3 1.3. Assumptions and Scope .................................. 4 - 1.4. Keywords ............................................... 4 + 1.4. Terminology ............................................ 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 ... 6 5. Examples ................................................... 7 5.1. Example 1 .............................................. 7 - 5.2. Example 2 .............................................. 8 + 5.2. Example 2 .............................................. 7 5.3. Example 3 .............................................. 8 5.4. Example 4 .............................................. 8 - 6. Operational Considerations ................................. 8 - 6.1. RP Redundancy .......................................... 8 + 6. Operational Considerations ................................. 9 + 6.1. RP Redundancy .......................................... 9 6.2. RP Deployment .......................................... 9 6.3. Guidelines for Assigning IPv6 Addresses to RPs ......... 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 ................................... 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 + 6.5. Controlling the Use of RPs ............................. 10 + 7. The Embedded-RP Group-to-RP Mapping Mechanism .............. 11 + 7.1. PIM-SM Group-to-RP Mapping ............................. 11 + 7.2. Overview of the Model .................................. 11 + 8. Scalability Analysis ....................................... 12 + 9. Acknowledgements ........................................... 13 + 10. Security Considerations ................................... 14 + 11. References ................................................ 15 + 11.1. Normative References .................................. 15 + 11.2. Informative References ................................ 15 + Authors' Addresses ............................................. 16 + A. Discussion about Design Tradeoffs .......................... 16 + B. Changes .................................................... 17 + B.3 Changes since -03 ....................................... 17 + B.2 Changes since -02 ....................................... 17 + B.3 Changes since -01 ....................................... 18 + B.4 Changes since -00 ....................................... 18 + Intellectual Property Statement ................................ 18 + Full Copyright Statement ....................................... 19 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. Therefore the whole interdomain Any Source Multicast model is rendered unusable; Source-Specific Multicast (SSM) [SSM] avoids these - problems but is not a complete solution for several reasons. + problems but is not a complete solution for several reasons, as noted + below. Further, it has been noted that there are some problems with the support and deployment of mechanisms SSM would require [V6MISSUES]: it seems unlikely that SSM could be usable as the only interdomain multicast routing mechanism in the short term. 1.2. Solution This memo describes a multicast address allocation policy in which the address of the RP is encoded in the IPv6 multicast group address, @@ -127,40 +130,46 @@ Addresses in the subrange will be called embedded-RP addresses. This scheme obviates the need for MSDP, and the routers are not required to include any multicast configuration, except when they act as an RP. This memo updates the addressing format presented in RFC 3306. 1.3. Assumptions and Scope - In general, a 128-bit RP address can't be embedded into a 128-bit - group address with space left to carry the group identity itself. An - appropriate form of encoding is thus defined by requiring that the - Interface-IDs of RPs in the embedded-RP range can be assigned to be a - specific value. + A 128-bit RP address can't be embedded into a 128-bit group address + with space left to carry the group identity itself. An appropriate + form of encoding is thus defined by requiring that the Interface-IDs + of RPs in the embedded-RP range can be assigned to be a specific + value. If these assumptions can't be followed, either operational procedures and configuration must be slightly changed or this mechanism can not be used. The assignment of multicast addresses is outside the scope of this document; it is up to the RP and applications to ensure that group addresses are unique using some unspecified method. However, the mechanisms are very probably similar to ones used with [RFC3306]. Similarly, RP failure management methods, such as Anycast-RP, are out of scope for this document. These do not work without additional specification or deployment. This is covered briefly in Section 6.1. -1.4. Keywords +1.4. Terminology + + Embedded-RP behaves as if all the members of the group were all + intra-domain to the information distribution. However, as it gives a + solution for the global IPv6 multicast Internet, spanning multiple + administrative domains, we say it is a solution for inter-domain + multicast. 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: @@ -247,168 +256,207 @@ || +------------+------------------------+ || | network pre| 0000000000000000000000 | || +------------+------------------------+ \\ ``=================> copy RIID to the last 4 bits +------------+---------------------+--+ | network pre| 0000000000000000000 |ID| +------------+---------------------+--+ One should note that there are several operational scenarios (see - Example 2 below) when [RFC3306] statement "all non-significant bits + Example 3 below) when [RFC3306] statement "all non-significant bits of the network prefix field SHOULD be zero" is ignored. This is to allow multicast group address allocations to be consistent with unicast prefixes, while the multicast addresses would still use the RP associated with the network prefix. "plen" higher than 64 MUST NOT be used as that would overlap with the high-order bits of multicast group-id. 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 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). + (as RIID=0 is reserved, see section 6.3). 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 - the network and all the customers. (S)he chooses network - prefix=2001:DB8 and plen=32, and wants to use this addressing - mechanism. The multicast addresses (s)he will be able to use are of - the form: + the network and all the customers, by placing it on an existing + subnet, e.g., 2001:DB8:BEEF:FEED::/64. + + In that case, the group addresses would be 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 ("y" could be anything + from 1 to F, as 0 must not be used). + +5.2. Example 2 + + As in Example 1, the network administrator of 2001:DB8::/32 wants to + set up the RP, but to make it more flexible, wants to place it on a + specifically routed subnet, and wants to keep larger address space + for group allocations. That is, the administrator selects the least + specific part of the prefix, with plen=32, and the group addresses + will be of the form: 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: + address, and "zzzz:zzzz" will be 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 assigned to a router as a loopback address - and injected to the routing system. + The address 2001:DB8::y/128 is assigned to a router as a loopback + address and injected to the routing system; if the network + administrator sets up only one or a couple of RPs (and e.g., not one + RP per subnet), this approach may be preferable to the one described + in Example 1. -5.2. Example 2 +5.3. Example 3 - As in Example 1, the network administrator can also allocate + As in Example 2, 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 prefix" field considered when obtaining the RP address. In this case, only the first 32 bits of the network prefix field, "2001:DB8" are preserved: the value of "plen" takes no stance on actual unicast/multicast prefix lengths allocated or used in the networks, here from 2001:DB8:DEAD::/48. In short, this distinction allows more flexible RP address configuration in the scenarios where it is desirable to have the group addresses to be consistent with the unicast prefix allocations. -5.3. Example 3 +5.4. Example 4 - In the network of Examples 1 and 2, the network admin sets up + In the network of Examples 1, 2 and 3, the network admin sets up addresses for use by their customers, but an organization wants to have their own PIM-SM domain. The organization can pick multicast addresses like "FF7x:y30:2001:DB8:BEEF::/80", and then their RP address would be "2001:DB8:BEEF::y". -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 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 - mechanisms or techniques such as MSDP, PIM-SM extensions, or - "anycasting" (i.e., the shared-unicast model [ANYCAST]) the RP + The most feasible candidate for RP failover is using PIM for Anycast + RP or "anycasting" (i.e., the shared-unicast model [ANYCAST]) the RP address in the IGP without state sharing (depending on the redundancy requirements, this may or may not be enough, though). However, the redundancy mechanisms are outside of the scope of this memo. 6.2. RP Deployment As there is no need to share inter-domain state with MSDP, each DR connecting multicast sources could act as an RP without scalability concerns about setting up and maintaining MSDP sessions. This might be particularly attractive when concerned about RP redundancy. In the case where the DR close to a major source for a group acts as the RP, a certain amount of fate-sharing properties can be obtained without using any RP failover mechanisms: if the DR goes down, the multicast transmission may not work anymore in any case. Along the same lines, it's may also be desirable to distribute the RP responsibilities to multiple RPs. As long as different RPs serve - different groups, this is is trivial: each group could map to a + different groups, this is trivial: each group could map to a different RP (or sufficiently many different RPs that the load on one RP is not a problem). However, load sharing one group faces the similar challenges as Anycast-RP. 6.3. Guidelines for Assigning IPv6 Addresses to RPs With this mechanism, the RP can be given basically any network prefix up to /64. The interface identifier will have to be manually configured to match "RIID". RIID = 0 must not be used as using it would cause ambiguity with the Subnet-Router Anycast Address [ADDRARCH]. 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 + described in example 2 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 how the RP to be used. + specifies the RP to be used. + +6.5. Controlling the Use of RPs + + Compared to the MSDP inter-domain ASM model, the control and + management of who can use an RP and how changes slightly and deserves + explicit discussion. + + MSDP advertisement filtering typically includes at least two + capabilities: being able to filter who is able to create a global + session ("source filtering"), and being able to filter which groups + should be globally accessible ("group filtering"). These are done to + prevent local groups from being advertised to the outside, or + preventing unauthorized senders from creating global groups. + + However, such controls do not yet block the outsiders from using such + groups, as they could join the groups even without Source Active + advertisement with an (S,G) Join by guessing/learning the source + and/or the group address. For proper protection, one should set up, + e.g., PIM multicast scoping borders at the border routers. + Therefore, embedded-RP has by default roughtly equivalent level of + "protection" as MSDP with SA filtering. + + A new issue with control comes from the fact that nodes in a "foreign + domain" may register to an RP, or send PIM Join to an RP. (These have + been possible in the past as well, to a degree, but only through + willfull attempts or purposeful RP configuration at DRs.) The main + threat in this case is that an outsider illegitimately uses the RP to + host his/hers own group(s). This can be mitigated to an extent by + filtering which groups or group ranges are allowed at the RP; more + specific controls are beyond the scope of this memo. Note that this + does not seem to be a serious threat in the first place as anyone + with a /64 prefix can create an own RP, without having to + illegitimately get it from someone else. 7. The Embedded-RP Group-to-RP Mapping Mechanism - This section specifies the group-to-RP mapping mechanism works for - Embedded RP. + This section specifies the group-to-RP mapping mechanism 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 @@ -460,52 +508,53 @@ just acts as a group-to-RP mapping mechanism; instead of obtaining the address of the RP from local configuration or configuration protocols (e.g., BSR), it is derived transparently from the encoded multicast address. 8. Scalability Analysis Interdomain MSDP model for connecting PIM-SM domains is mostly hierarchical in configuration and deployment, but flat with regard to information distribution. The embedded-RP inter-domain model behaves - as if all of the Internet was a single PIM domain, with just one RP - per group. So, the inter-domain multicast becomes a flat, RP- - centered topology. The scaling issues are described below. + as if every group formed its own Internet-wide PIM domain, with the + group mapping to a single RP, wherever the receivers or senders are. + So, the inter-domain multicast becomes a flat, RP-centered topology. + The scaling issues are described below. Previously foreign sources sent the unicast-encapsulated data to - their local RP, now they do so to the foreign RP "responsible" for - the specific group (i.e., the prefix where the group address was - derived from). This is especially important with large multicast - groups where there are a lot of heavy senders -- particularly if - implementations do not handle unicast-decapsulation well. + their "local" RP, now they do so to the "foreign" RP responsible for + the specific group. This is especially important with large + multicast groups where there are a lot of heavy senders -- + particularly if implementations do not handle unicast-decapsulation + well. - This model increases the amount of Internet-wide multicast state - slightly: the backbone routers might end up with (*, G) and (S, G, - rpt) state between receivers (and past receivers, for PIM Prunes) and - the RP, in addition to (S, G) states between the receivers and - senders, if SPT is used. However, the traditional ASM model also - requires MSDP state to propagate everywhere in inter-domain, so the - total amount of state is smaller. + With IPv4 ASM multicast, there is roughly two kinds of Internet-wide + state: MSDP (propagated everywhere), and multicast routing state (on + the receiver or sender branches). The former is eliminated, but the + backbone routers might end up with (*, G) and (S, G, rpt) state + between receivers (and past receivers, for PIM Prunes) and the RP, in + addition to (S, G) states between the receivers and senders, if SPT + is used. However, the total amount of state is smaller. The embedded-RP model is practically identical in both inter-domain and intra-domain cases to the traditional PIM-SM in intra-domain. On the other hand, PIM-SM has been deployed (in IPv4) in inter-domain using MSDP; compared to that inter-domain model, this specification - simplifies the multicast routing by removing the RP for senders and - receivers in foreign domains, and eliminating the MSDP information - distribution. + simplifies the tree construction (i.e., multicast routing) by + removing the RP for senders and receivers in foreign domains, and + eliminating the MSDP information distribution. 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. + failure management becomes more difficult, as the deployed failover + or redundancy mechanisms (e.g., BSR, Anycast-RP with MSDP) cannot be + used as-is. However, Anycast-RP using PIM provides equal redundancy; + 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 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 @@ -524,56 +573,66 @@ 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. 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. + Farinacci, Nidhi Bhaskar, and Jerome Durand 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 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. Both the sender- and receiver-based attacks are described at more length in [PIMSEC]. - 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. + Additionally the implementation SHOULD also allow manual + configuration of which multicast prefixes 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 + 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). + such). Further, multicast groups or group ranges to-be-served MAY + need to be explicitly configured at the RPs, to protect from being + used unwillingly. Note that the more specific controls (e.g., + "insider-must-create" or "invite-outsiders" models) to who is allowed + to use the groups are beyond the scope of this memo. + + Excluding internal-only groups from MSDP advertisements does not + protect the groups from outsiders, only offers security by obscurity; + embedded-RP offers similar level of protection. When real protection + is desired, e.g., PIM scoping should be set up at the borders; this + is described at more length in Section 6.5. 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; @@ -682,42 +741,54 @@ 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]. B. Changes [[ RFC-Editor: please remove before publication ]] - B.1 Changes since -02 + B.3 Changes since -03 + + o Further clarifications, especially regarding Inter/intra-domain + terminology. + o Recommend more strongly that multicast groups can be configured, + and that they should be explicitly configured, to protect against + abuse. + o Note that more detailed controls on who can use a multicast + address are out of scope. + o Add discussion about controls/manageability and how that has + changed from the MSDP model. + + B.2 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 + B.3 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.3 Changes since -00 + B.4 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.