Network Working Group Dino Farinacci INTERNET-DRAFT Procket Networks Expiration Date: December 2004 Yiqun Cai cisco Systems June 21, 2004 Anycast-RP using PIM Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC3668. 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. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This specification allows Anycast-RP (Rendezvous Point) to be used inside a domain, which runs Protocol Independent Multicast (PIM) only. There are no other multicast protocols required to support Anycast-RP, such as MSDP, which has been used traditionally to solve this problem. Farinacci, Cai [Page 1] Internet Draft Anycast-RP using PIM June 21, 2004 1.0 Introduction Anycast-RP as described in [I1] is a mechanism ISP-based backbones have used to get fast convergence when a PIM Rendezvous Point (RP) router fails. To allow receivers and sources to Rendezvous to the closest RP, the packets from a source needs to get to all RPs to find joined receivers. This notion of receivers finding sources is the fundamental problem of source discovery which MSDP was intended to solve. However, if one would like to retain the Anycast-RP benefits from [I1] with less protocol machinery, removing MSDP from the solution space is an option. This memo extends the Register mechanism in PIM so Anycast-RP functionality can be retained without using MSDP. 1.1 Terminology 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.0 Requirements o Each router acting as an RP MUST be configured with a loopback interface using the same (shared) IP address. This address is used to tell other routers in the PIM domain what IP address to use for the RP address. o The RP address or a prefix that covers the RP address is injected into the unicast routing system inside of the domain. o Each RP configures all other RPs used in the Anycast-RP set. This must be consistently configured in all RPs in the set. Farinacci, Cai [Page 2] Internet Draft Anycast-RP using PIM June 21, 2004 3.0 Mechanism The following diagram illustrates a domain using 3 RPs where receivers are joining to the closest RP according to where unicast routing metrics take them and 2 sources sending packets to their respective RPs. S1-----RP1 RP2 RP3------S3 / \ | / \ | R1 R1' R2 Assume the above scenario is completely connected where R1, R1', and R2 are receivers for a group, and S1 and S2 send to that group. Assume RP1, RP2 and RP3 are all assigned the same IP address which is used as the Anycast-RP address (let's say the IP address is RPA). Note, the address used for the RP address in the domain (the Anycast- RP address) needs to be a different than the addresses used by the Ancyast-RP routers to communicate with each other. The following procedure is used when S1 starts sourcing traffic: o S1 sends a multicast packet. o The DR directly attached to S1 will form a PIM Register message to send to RP1. The IP address to use is the Anycast-RP address. o RP1 will receive the PIM Register message, decapsulate it, send the packet down the shared-tree to get the packet to receivers R1 and R1'. o RP1 is configured with RP2 and RP3's IP address. It will forward the Register message from S1's DR to both of them. RP1 will use its own IP address as the source address for the PIM Register message. o RP1 sends a Register-Stop back to the DR. o RP1 MAY join back to the source-tree by triggering a (S1,G) Join message toward S1. However, RP1 MUST create (S1,G) state. o RP2 receives the Register message from RP1, decapsulates it, and also sends the packet down the shared-tree to get the packet to receiver R2. o RP2 sends a Register-Stop back to the RP1. RP1 processes the Register-Stop just like it would if it was a DR. Farinacci, Cai [Page 3] Internet Draft Anycast-RP using PIM June 21, 2004 o RP2 MAY join back to the source-tree by triggering a (S1,G) Join message toward S1. However, RP2 MUST create (S1,G) state. o RP3 receives the Register message from RP1, decapsulates it, but since there are no receivers joined for the group, it can discard the packet. o RP3 sends a Register-Stop back to the RP1. o RP3 creates (S1,G) state so when a receiver joins after S1 starts sending, RP3 can join quickly to the source-tree for S1. The procedure for S3 sending follows the same as above but it is RP3 which forwards the Register originated by S3's DR to RP1 and RP2. Therefore, this example shows how sources anywhere in the domain, associated with different RPs, can reach all receivers, also associated with different RPs, in the same domain. 4.0 Observations and Guidelines about this Proposal o An RP will forward a Register only if the Register is received from an IP address not in the Anycast-RP list (i.e. the Register came from a DR and not another RP). o Each DR that PIM registers for a source will send the message to it's closest RP address. Therefore there are no changes to the DR logic. o Packets flow to all receivers no matter what RP they have joined to. o The source gets Registered to a single RP by the DR, it's the responsibility of the RP, the DR selects (based on routing metrics), to get the packet to all other RPs in the Anycast-RP set. o Logic is changed only in the RPs. The logic change is for forwarding Register messages. Register-Stop processing is unchanged. However, an implementation MAY suppress sending Register-Stop messages in response to a Register received from an RP. o The rate-limiting of Register and Register-Stop messages are done end-to-end. That is from DR -> RP1 -> {RP2 and RP3}. There is no need for specific rate-limiting logic between the RPs. o When topology changes occur, the existing source-tree adjusts as it Farinacci, Cai [Page 4] Internet Draft Anycast-RP using PIM June 21, 2004 does today according to [N1]. The existing shared-trees, as well, adjust as it does today according to [N1]. o Physical RP changes are as fast as unicast route convergence. Retaining the benefit of [I1]. o An RP that doesn't support this specification can be mixed with RPs that do support this specification. However, the non-supporter RPs should not have sources registering to it but may have receivers joined to it. o If Null Registers are sent (Registers with an IP header and no IP payload), they MUST be replicated to all of the RPs in the Anycast- RP set so that source state remains alive for active sources. o The number of RPs in the Anycast-RP set should remain small so the amount of non-native replication is kept to a minimum. 5.0 Interaction with MSDP running in an Anycast-PIM Router The objective of this Anycast-PIM proposal is to remove the dependence on using MSDP. This can be achieved by removing MSDP peering between the Anycast RPs. However, to advertise internal sources to routers outside of a PIM routing domain and to learn external sources from other routing domains, MSDP may still be required. 5.1 Anycast-PIM Stub Domain Functionality In this capacity, when there are internal sources that need to be advertised externally, an Anycast-RP which receives a Register message, either from a DR or an Anycast-RP, should process it as described in this specification as well as how to process a Register message as described in [N1]. That means an SA for the same internal source could be originated by multiple Anycast-RPs doing the MSDP peering. There is nothing inherently wrong with this other than the source is being advertised into the MSDP infrastructure from multiple places from the source domain. However, if this is not desirable, configuration of one or more (rather than all) Anycast-RP MSDP routers would allow only those routers to originate SAs for the internal source. And in some situations, there is a good possibility Farinacci, Cai [Page 5] Internet Draft Anycast-RP using PIM June 21, 2004 not all Anycast-RPs in the set will have MSDP peering sessions so this issue can be mitigated to a certain extent. From an Anycast-RP perspective, a source should be considered internal to a domain, when it is discovered by an Anycast-RP through a received Register message. Regardless, if the Register message was sent by a DR, another Anycast-RP member, or the router itself. For learning sources external to a domain, the MSDP SA messages could arrive at multiple MSDP-peering Anycast-RPs. The rules for processing an SA, according to [I1], should be followed. That is, if G is joined in the domain, an (S,G) join is sent towards the source. And if data accompanies the SA, each Anycast-PIM RP doing MSDP peering will forward the data down each of their respective shared-trees. The above assumes each Anycast-RP has external MSDP peering connections. If this is not the case, the Anycast-PIM routers with the MSDP peering connections would follow the same procedure as if a Data-Register or Null-Register was received from either a DR or another Anycast-RP. That is, they would send Registers to the other members of the Anycast-RP set. If there is a mix of Anycast-RPs that do and do not have external MSDP peering connections, then the ones that do must be configured with the set that do not. So Register messages are sent only to the members of the Anycast-RP set that do not have external MSDP peering connections. 5.2 Anycast-PIM Transit Domain Functionality Within a routing domain, it is recommended that an Anycast-RP set defined in this specification should not be mixed with MSDP peering among the members. In some cases, the source discovery will work but it may not be obvious to the implementations what sources are local to the domain and which are not. This may affect external MSDP advertisement of internal sources. Having said that, this draft makes no attempt to connect MSDP peering domains together by using Anycast-PIM inside a transit domain. 6.0 IANA Considerations This document makes no request to IANA. Note to RFC Editor: this section may be removed on publication as an RFC. Farinacci, Cai [Page 6] Internet Draft Anycast-RP using PIM June 21, 2004 7.0 Security Consideration This section describes the security consideration for Register and Register-Stop messages between Anycast-RPs. For PIM messages between DR and RP, please see [I3]. 7.1 Attack Based On Forged Messages An attacker may forge a Register message using one of the addresses in the Anycast-RP list in order to achieve one or more of the following effects: 1. Overwhelm the target RP in a denial-of-service attack 2. Inject unauthorized data to receivers served by the RP 3. Inject unauthorized data and create bogus SA entries in other PIM domains if the target RP has external MSDP peerings An attacker may also forge a Register-Stop message using one of the addresses in the Anycast-RP list. However, besides denial-of- service, the effect of such an attack is limited because an RP usually ignores Register-Stop messages. 7.2 Protect Register and Register-Stop Messages The DOS attack using forged Register or Register-Stop messages can not be prevented. But the RP can still be protected. For example, the RP can rate-limit incoming messages. It can also choose to refuse to process any Register-Stop messages. The actual protection mechansim is implementation specific. The distribution of unauthorized data and bogus SA entries can be prevented using the method recommended in [I3]. That is IPsec [I3] transport mode using the Authentication Header (AH). There are two options a network administrator can choose from. An RP can be configured using a unique SA and SPI for traffic (Registers or Register-Stops) to each member of Anycast-RPs in the list. Alternatively, a single authentication algorithm and associated parameters can be used for the entire Anycast-RP set in order to reduce the overhead of key distribution. Farinacci, Cai [Page 7] Internet Draft Anycast-RP using PIM June 21, 2004 8.0 Acknowledgments The authors would like to thank Yiqun Cai and Dino Farinacci for prototyping this draft in the cisco IOS and Procket implementations, respectively. The authors would like to thank John Zwiebel for doing interoperability testing of the two prototype implementations. And finally, the authors would like to thank Greg Shepard from Procket Networks, Lenny Giuliano from Juniper Networks, Prashant Jhingran from Huawei Technologies, and Pekka Savola from CSC/FUNET, for their comments on earlier drafts. 9.0 Author Information Dino Farinacci Procket Networks dino@procket.com Yiqun Cai cisco Systems ycai@cisco.com 10.0 References 10.1 Normative References [N1] Estrin, et al., "Protocol Independent Multicast-Sparse Mode (PIM- SM): Protocol Specification", RFC 2362, June 1998. 10.2 Informative References [I1] Kim, Meyer, Kilmer, Farinacci, "Anycast RP mechanism using PIM and MSDP", RFC 3446, January 2003. [I2] Fenner, Handley, Holbrook, Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM):Protocol Specification (Revised)", Internet Draft draft-ietf-pim-sm-v2-new-09.txt, February 2004. [I3] Kent, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. Farinacci, Cai [Page 8] Internet Draft Anycast-RP using PIM June 21, 2004 Appendix A - Possible Configuration Language A possible set of commands to be used could be: ip pim anycast-rp Where: describes the Anycast-RP set for the RP which is assigned to the group range. This IP address is the address that first-hop and last-hop PIM routers use to register and join to. describes the IP address where Register messages are forwarded to. This IP address is any address assigned to the RP router not including the . Example: From the illustration above, the configuration commands would be: ip pim anycast-rp RPA RP1 ip pim anycast-rp RPA RP2 ip pim anycast-rp RPA RP3 Comment: It may be useful to include the local router's IP address in the command set so the above lines can be cut-and-pasted or scripted into all the RPs in the Anycast-RP set. But the implementation would have to be aware of it's own address and not inadvertently send a Register to itself. Farinacci, Cai [Page 9]