Network Working Group Eric C. Rosen Internet Draft Peter Psenak Expiration Date:
JulySeptember 2004 Cisco Systems, Inc. Padma Pillay-Esnault Juniper Networks, Inc. JanuaryMarch 2004 Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs draft-ietf-ospf-2547-dnbit-03.txtdraft-ietf-ospf-2547-dnbit-04.txt Status of this Memo This document is an Internet-Draft and is in full conformance with 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. 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. Abstract This document specifies a procedure that deals with a particular issue that may arise when a Service Provider (SP) provides "BGP/MPLS IP VPN" service to a customer, and the customer uses OSPFOSPFv2 to advertise its routes to the SP. In this situation, a Customer Edge (CE) Router and a Provider Edge (PE) Router are OSPF peers, and customer routes are sent via OSPFOSPFv2 from the CE to the PE. The customer routes are converted into BGP routes, and BGP carries them across the backbone to other PE routers. The routes are then converted back to OSPF routes sent via OSPF to other CE routers. As a result of converting the routes from OSPF to BGP and back to OSPF, some of the information needed to prevent loops may be lost. A procedure is needed to ensure that once a route is sent from a PE to a CE, the route will be ignored by any PE which receives it back from a CE. This document specifies the necessary procedure, using one of the options bits in the LSA (Link State Advertisements) to indicate that an LSA has already been forwarded by a PE, and should be ignored by any other PEs that see it. Table of Contents 1 Specification of Requirements ........................ 2 2 Introduction ......................................... 2 3 Information Loss and Loops ........................... 4 4 Using the LSA Options to Prevent Loops ............... 5 5 Security Considerations .............................. 5 6 Acknowledgments ...................................... 6 7 Authors' Addresses ................................... 6 8 Normative References ................................. 67 9 Intellectual Property ................................Statement ...................... 7 10 Full Copyright Statement ............................. 7 1. Specification of Requirements 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 RFC 2119. 2. Introduction [VPN] describes a method by which a Service Provider (SP) can use its IP backbone to provide an "IP VPN" service to customers. In that sort of service, a customer's edge devices (CE devices) are connected to the provider's edge routers (PE routers). Each CE device is in a single VPN. Each PE device may attach to multiple CEs, of the same or of different VPNs. A VPN thus consists of a set of "network segments" connected by the SP's backbone. A CE exchanges routes with a PE, using a routing protocol that is jointly agreed to by the customer and the SP. The PE runs that routing protocol's decision process (i.e., performs the routing computation) to determine the set of IP address prefixes for which the following two conditions hold: - each address prefix in the set can be reached via that CE - the path from that CE to each such address prefix does NOT include the SP backbone (i.e., does not include any PE routers). The PE routers which attach to a particular VPN redistribute routes to these address prefixes into BGP, so that they can use BGP to distribute the VPN's routes to each other. BGP carries these routes in the "VPN-IP"VPN-IPv4 address family", so that they are distinct from ordinary Internet routes. The VPN-IPVPN-IPv4 address family also extends the IP addresses on the left so that address prefixes from two different VPNs are always distinct to BGP, even if both VPNs use the same piece of the private RFC1918 address space. Thus routes from different VPNs can be carried by a single BGP instance, and can be stored in a common BGP table, without fear of conflict. If a PE router receives a particular VPN-IPVPN-IPv4 route via BGP, and if that PE is attached to a CE in the VPN to which the route belongs, then BGP's decision process may install that route in the BGP route table. If so, the PE translates the route back into an IP route, and redistributes it to the routing protocol which is running on the link to that CE. This methodology provides a "peer model"; CE routers peer with PE routers, but CE routers at different sites do not peer with each other. If a VPN uses OSPFOSPFv2 as its internal routing protocol, it is not necessarily the case that the CE routers of that VPN use OSPFOSPFv2 to peer with the PE routers. Each site in a VPN can use OSPFOSPFv2 as its intra- siteintra-site routing protocol, while using, e.g., BGP or RIP to distribute routes to a PE router. However, it is certainly convenient, when OSPFOSPFv2 is being used intra-site, to use it on the PE-CE link as well, and [VPN] explicitly allows this. In this case, a PE will run a separate instance of OSPFOSPFv2 for each VPN which is attached to the PE; the PE will in general have multiple VPN-specific OSPFOSPFv2 routing tables. When OSPFOSPFv2 is used on a PE-CE link which belongs to a particular VPN, the PE router must redistribute to that VPN's OSPFOSPFv2 instance certain routes which have been installed in the BGP routing table. Similarly, a PE router must redistribute to BGP routes which have been installed in the VPN-specific OSPF routing tables. Procedures for this are specified in [VPN-OSPF]. The routes which are redistributed from BGP to OSPFOSPFv2 are advertised in LSAs that are originated by the PE. The PE acts as an OSPF border router, advertising some of these routes in AS-external LSAs, and some in summary LSAs, as specified in [VPN-OSPF]. Similarly, when a PE router receives an LSA from a CE router, it runs the OSPF routing computation. Any route that gets installed in the OSPF routing table must be translated into a VPN-IPVPN-IPv4 route and then redistributed into BGP. BGP will then distribute these routes to the other PE routers. 3. Information Loss and Loops A PE, say PE1, may learn a route to a particular VPN-IPVPN-IPv4 address prefix via BGP. This may cause it to generate a summary LSA or an AS-external LSA in which it reports that address prefix. This LSA may then be distributed to a particular CE, say CE1. The LSA may then be distributed throughout a particular OSPF area, reaching another CE, say CE2. CE2 may then distribute the LSA to another PE, say PE2. As stated in the previous section, PE2 must run the OSPF routing computation to determine whether a particular address prefix, reported in an LSA from CE2, is reachable from CE2 via a path which does not include any PE router. Unfortunately, there is no standard way to do this. The OSPFOSPFv2 LSAs do not necessarily carry the information needed to enables PE2 to determine that the path to address prefix X in a particular LSA from CE2 is actually a path that includes, say, PE1. If PE2 then leaks X into BGP as a VPN-IPVPN-IPv4 route, then PE2 is violating one of the constraints for loop-freedom in BGP, viz., that routes learned from a particular BGP domain not be redistributed back into that BGP domain. This could cause a routing loop to be created. It is therefore necessary to have a means by which an LSA may carry the information that a particular address prefix has been learned from a PE router. Any PE router which receives an LSA with this information would omit the information in this LSA from its OSPF routing computation, and thus would not leak the information back into BGP. When a PE generates an AS-external LSA, it could use a distinct tag value to indicate that the LSA is carrying information about an address prefix for whom the path includes a PE router. However, this method is not available in the case where the PE generates a Summary LSA. Per [OSPF-VPN],[VPN-OSPF], each PE router must function as an OSPF area 0 router. If the PE-CE link is an area 0 link, then it is possible for the PE to receive, over that link, a summary LSA which originated at another PE router. Thus we need some way of marking a summary LSA to indicate that it is carrying information about a path via a PE router. 4. Using the LSA Options to Prevent Loops The high-order bit of the LSA Options field (a previously unused bit) is used to solve the problem described in the previous section. We refer to this bit as the DN bit. When a type 3, 5, or 7 LSA is sent from a PE to a CE, the DN bit MUST be set. The DN bit MUST be clear in all other LSA types. +-------------------------------------+ | DN | * | DC | EA | N/P | MC | E | * | +-------------------------------------+ Options Field with DN Bit (RFC 2328, Section A.2) When the PE receives, from a CE router, a type 3, 5, or 7 LSA with the DN bit set, the information from that LSA MUST NOT be used during the OSPF route calculation. As a result, the LSA is not translated into a BGP route. The DN bit MUST be ignored in all other LSA types. This prevents routes learned via BGP from being redistributed to BGP. (This restriction is analogous to the usual OSPF restriction that inter-area routes which are learned from area 0 are not passed back to area 0.) Note that the DN bit has no other effect on LSA handling. In particular, an LSA with the DN bit set will be put in the topological database, aged, flooded, etc., just as if DN waswere not set. 5. Security Considerations An attacker may cause the DN bit to be set, in an LSA traveling from CE to PE, when the DN bit should really be clear. This may cause the address prefixes mentioned in that LSA to be unreachable from other sites of the VPN. Similarly, an attacker may cause the DN bit to be clear, in an LSA traveling in either direction, when the DN bit should really be set. This may cause routing loops for traffic which is destined to the address prefixes mentioned in that LSA. These possibilities may be eliminated by using cryptographic authentication as specified in section D of [OSPF].[OSPFv2]. 6. Acknowledgments The idea of using the high-order options bit for this purpose is due to Derek Yeung. Thanks to Yakov Rekhter for his contribution to this work. We also wish to thank Acee Lindem for his helpful comments. 7. Authors' Addresses Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 E-mail: email@example.com Peter Psenak Parc Pegasus, De Kleetlaan 6A 1831 Diegem Belgium E-mail: firstname.lastname@example.org Padma Pillay-Esnault Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 E-mail: email@example.com 8. Normative References [OSPF][OSPFv2] "OSPF Version 2", RFC 2328, Moy, J., April 1998 [VPN] "BGP/MPLS IP VPNs", draft-ietf-l3vpn-rfc2547bis-01.txt, Rosen, Rekhter, et. al., September 2003 [OSPF-VPN][VPN-OSPF] "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", draft- ietf-l3vpn-ospf-2547-00.txt,ietf-l3vpn-ospf-2547-01.txt, Rosen, Psenak, Pillay-Esnault, June 2003February 2004 9. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual propertyIntellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neithernor does it represent that it has made any independent effort to identify any such rights. Information on the IETF'sprocedures with respect to rights in standards-track and standards-related documentationRFC documents can be found in BCP-11.BCP 78 and BCP 79. Copies of claims of rightsIPR disclosures made available for publicationto the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementorsimplementers or users of this specification can be obtained from the IETF Secretariat.on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights whichthat may cover technology that may be required to practiceimplement this standard. Please address the information to the IETF Executive Director.at ietf- firstname.lastname@example.org. 10. Full Copyright Statement "CopyrightCopyright (C) The Internet Society (2004). All Rights Reserved.This document and translations of it may be copied and furnishedis subject to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided thatthe above copyright notice and this paragraph are included on all such copiesrights, licenses and derivative works. However, this document itself may not be modifiedrestrictions contained in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations,BCP 78 and except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked byset forth therein, the Internet Society or its successors or assigns.authors retain all their rights. This document and the information contained herein isare provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMSDISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."PURPOSE.