idnits 2.17.1 draft-ietf-ospf-2547-dnbit-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 2004) is 7397 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'VPN-OSPF' is mentioned on line 138, but not defined == Outdated reference: A later version (-03) exists of draft-ietf-l3vpn-rfc2547bis-01 == Outdated reference: A later version (-06) exists of draft-ietf-l3vpn-ospf-2547-00 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Eric C. Rosen 3 Internet Draft Peter Psenak 4 Expiration Date: July 2004 Cisco Systems, Inc. 6 Padma Pillay-Esnault 7 Juniper Networks, Inc. 9 January 2004 11 Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs 13 draft-ietf-ospf-2547-dnbit-03.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document specifies a procedure that deals with a particular 38 issue that may arise when a Service Provider (SP) provides "BGP/MPLS 39 IP VPN" service to a customer, and the customer uses OSPF to 40 advertise its routes to the SP. In this situation, a Customer Edge 41 (CE) Router and a Provider Edge (PE) Router are OSPF peers, and 42 customer routes are sent via OSPF from the CE to the PE. The 43 customer routes are converted into BGP routes, and BGP carries them 44 across the backbone to other PE routers. The routes are then 45 converted back to OSPF routes sent via OSPF to other CE routers. As 46 a result of converting the routes from OSPF to BGP and back to OSPF, 47 some of the information needed to prevent loops may be lost. A 48 procedure is needed to ensure that once a route is sent from a PE to 49 a CE, the route will be ignored by any PE which receives it back from 50 a CE. This document specifies the necessary procedure, using one of 51 the options bits in the LSA (Link State Advertisements) to indicate 52 that an LSA has already been forwarded by a PE, and should be ignored 53 by any other PEs that see it. 55 Table of Contents 57 1 Specification of Requirements ........................ 2 58 2 Introduction ......................................... 2 59 3 Information Loss and Loops ........................... 4 60 4 Using the LSA Options to Prevent Loops ............... 5 61 5 Security Considerations .............................. 5 62 6 Acknowledgments ...................................... 6 63 7 Authors' Addresses ................................... 6 64 8 Normative References ................................. 6 65 9 Intellectual Property ................................ 7 66 10 Full Copyright Statement ............................. 7 68 1. Specification of Requirements 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in RFC 2119. 74 2. Introduction 76 [VPN] describes a method by which a Service Provider (SP) can use its 77 IP backbone to provide an "IP VPN" service to customers. In that 78 sort of service, a customer's edge devices (CE devices) are connected 79 to the provider's edge routers (PE routers). Each CE device is in a 80 single VPN. Each PE device may attach to multiple CEs, of the same 81 or of different VPNs. A VPN thus consists of a set of "network 82 segments" connected by the SP's backbone. 84 A CE exchanges routes with a PE, using a routing protocol that is 85 jointly agreed to by the customer and the SP. The PE runs that 86 routing protocol's decision process (i.e., performs the routing 87 computation) to determine the set of IP address prefixes for which 88 the following two conditions hold: 90 - each address prefix in the set can be reached via that CE 92 - the path from that CE to each such address prefix does NOT 93 include the SP backbone (i.e., does not include any PE routers). 95 The PE routers which attach to a particular VPN redistribute routes 96 to these address prefixes into BGP, so that they can use BGP to 97 distribute the VPN's routes to each other. BGP carries these routes 98 in the "VPN-IP address family", so that they are distinct from 99 ordinary Internet routes. The VPN-IP address family also extends the 100 IP addresses on the left so that address prefixes from two different 101 VPNs are always distinct to BGP, even if both VPNs use the same piece 102 of the private RFC1918 address space. Thus routes from different 103 VPNs can be carried by a single BGP instance, and can be stored in a 104 common BGP table, without fear of conflict. 106 If a PE router receives a particular VPN-IP route via BGP, and if 107 that PE is attached to a CE in the VPN to which the route belongs, 108 then BGP's decision process may install that route in the BGP route 109 table. If so, the PE translates the route back into an IP route, and 110 redistributes it to the routing protocol which is running on the link 111 to that CE. 113 This methodology provides a "peer model"; CE routers peer with PE 114 routers, but CE routers at different sites do not peer with each 115 other. 117 If a VPN uses OSPF as its internal routing protocol, it is not 118 necessarily the case that the CE routers of that VPN use OSPF to peer 119 with the PE routers. Each site in a VPN can use OSPF as its intra- 120 site routing protocol, while using, e.g., BGP or RIP to distribute 121 routes to a PE router. However, it is certainly convenient, when 122 OSPF is being used intra-site, to use it on the PE-CE link as well, 123 and [VPN] explicitly allows this. In this case, a PE will run a 124 separate instance of OSPF for each VPN which is attached to the PE; 125 the PE will in general have multiple VPN-specific OSPF routing 126 tables. 128 When OSPF is used on a PE-CE link which belongs to a particular VPN, 129 the PE router must redistribute to that VPN's OSPF instance certain 130 routes which have been installed in the BGP routing table. 131 Similarly, a PE router must redistribute to BGP routes which have 132 been installed in the VPN-specific OSPF routing tables. Procedures 133 for this are specified in [VPN-OSPF]. 135 The routes which are redistributed from BGP to OSPF are advertised in 136 LSAs that are originated by the PE. The PE acts as an OSPF border 137 router, advertising some of these routes in AS-external LSAs, and 138 some in summary LSAs, as specified in [VPN-OSPF]. 140 Similarly, when a PE router receives an LSA from a CE router, it runs 141 the OSPF routing computation. Any route that gets installed in the 142 OSPF routing table must be translated into a VPN-IP route and then 143 redistributed into BGP. BGP will then distribute these routes to the 144 other PE routers. 146 3. Information Loss and Loops 148 A PE, say PE1, may learn a route to a particular VPN-IP address 149 prefix via BGP. This may cause it to generate a summary LSA or an 150 AS-external LSA in which it reports that address prefix. This LSA 151 may then be distributed to a particular CE, say CE1. The LSA may 152 then be distributed throughout a particular OSPF area, reaching 153 another CE, say CE2. CE2 may then distribute the LSA to another PE, 154 say PE2. 156 As stated in the previous section, PE2 must run the OSPF routing 157 computation to determine whether a particular address prefix, 158 reported in an LSA from CE2, is reachable from CE2 via a path which 159 does not include any PE router. Unfortunately, there is no standard 160 way to do this. The OSPF LSAs do not necessarily carry the 161 information needed to enables PE2 to determine that the path to 162 address prefix X in a particular LSA from CE2 is actually a path that 163 includes, say, PE1. If PE2 then leaks X into BGP as a VPN-IP route, 164 then PE2 is violating one of the constraints for loop-freedom in BGP, 165 viz., that routes learned from a particular BGP domain not be 166 redistributed back into that BGP domain. This could cause a routing 167 loop to be created. 169 It is therefore necessary to have a means by which an LSA may carry 170 the information that a particular address prefix has been learned 171 from a PE router. Any PE router which receives an LSA with this 172 information would omit the information in this LSA from its OSPF 173 routing computation, and thus would not leak the information back 174 into BGP. 176 When a PE generates an AS-external LSA, it could use a distinct tag 177 value to indicate that the LSA is carrying information about an 178 address prefix for whom the path includes a PE router. However, this 179 method is not available in the case where the PE generates a Summary 180 LSA. Per [OSPF-VPN], each PE router must function as an OSPF area 0 181 router. If the PE-CE link is an area 0 link, then it is possible for 182 the PE to receive, over that link, a summary LSA which originated at 183 another PE router. Thus we need some way of marking a summary LSA to 184 indicate that it is carrying information about a path via a PE 185 router. 187 4. Using the LSA Options to Prevent Loops 189 The high-order bit of the LSA Options field (a previously unused bit) 190 is used to solve the problem described in the previous section. We 191 refer to this bit as the DN bit. When a type 3, 5, or 7 LSA is sent 192 from a PE to a CE, the DN bit MUST be set. The DN bit MUST be clear 193 in all other LSA types. 195 +-------------------------------------+ 196 | DN | * | DC | EA | N/P | MC | E | * | 197 +-------------------------------------+ 199 Options Field with DN Bit 200 (RFC 2328, Section A.2) 202 When the PE receives, from a CE router, a type 3, 5, or 7 LSA with 203 the DN bit set, the information from that LSA MUST NOT be used during 204 the OSPF route calculation. As a result, the LSA is not translated 205 into a BGP route. The DN bit MUST be ignored in all other LSA types. 207 This prevents routes learned via BGP from being redistributed to BGP. 209 Note that the DN bit has no other effect on LSA handling. In 210 particular, an LSA with the DN bit set will be put in the topological 211 database, aged, flooded, etc., just as if DN was not set. 213 5. Security Considerations 215 An attacker may cause the DN bit to be set, in an LSA traveling from 216 CE to PE, when the DN bit should really be clear. This may cause the 217 address prefixes mentioned in that LSA to be unreachable from other 218 sites of the VPN. Similarly, an attacker may cause the DN bit to be 219 clear, in an LSA traveling in either direction, when the DN bit 220 should really be set. This may cause routing loops for traffic which 221 is destined to the address prefixes mentioned in that LSA. 223 These possibilities may be eliminated by using cryptographic 224 authentication as specified in section D of [OSPF]. 226 6. Acknowledgments 228 The idea of using the high-order options bit for this purpose is due 229 to Derek Yeung. Thanks to Yakov Rekhter for his contribution to this 230 work. We also wish to thank Acee Lindem for his helpful comments. 232 7. Authors' Addresses 234 Eric C. Rosen 235 Cisco Systems, Inc. 236 1414 Massachusetts Avenue 237 Boxborough, MA 01719 239 E-mail: erosen@cisco.com 241 Peter Psenak 242 Parc Pegasus, 243 De Kleetlaan 6A 244 1831 Diegem 245 Belgium 247 E-mail: ppsenak@cisco.com 249 Padma Pillay-Esnault 250 Juniper Networks 251 1194 N. Mathilda Avenue 252 Sunnyvale, CA 94089 254 E-mail: padma@juniper.net 256 8. Normative References 258 [OSPF] "OSPF Version 2", RFC 2328, Moy, J., April 1998 260 [VPN] "BGP/MPLS IP VPNs", draft-ietf-l3vpn-rfc2547bis-01.txt, Rosen, 261 Rekhter, et. al., September 2003 263 [OSPF-VPN] "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", draft- 264 ietf-l3vpn-ospf-2547-00.txt, Rosen, Psenak, Pillay-Esnault, June 2003 266 9. Intellectual Property 268 The IETF takes no position regarding the validity or scope of any 269 intellectual property or other rights that might be claimed to 270 pertain to the implementation or use of the technology described in 271 this document or the extent to which any license under such rights 272 might or might not be available; neither does it represent that it 273 has made any effort to identify any such rights. Information on the 274 IETF's procedures with respect to rights in standards-track and 275 standards-related documentation can be found in BCP-11. Copies of 276 claims of rights made available for publication and any assurances of 277 licenses to be made available, or the result of an attempt made to 278 obtain a general license or permission for the use of such 279 proprietary rights by implementors or users of this specification can 280 be obtained from the IETF Secretariat. 282 The IETF invites any interested party to bring to its attention any 283 copyrights, patents or patent applications, or other proprietary 284 rights which may cover technology that may be required to practice 285 this standard. Please address the information to the IETF Executive 286 Director. 288 10. Full Copyright Statement 290 "Copyright (C) The Internet Society (2004). All Rights Reserved. 292 This document and translations of it may be copied and furnished to 293 others, and derivative works that comment on or otherwise explain it 294 or assist in its implementation may be prepared, copied, published 295 and distributed, in whole or in part, without restriction of any 296 kind, provided that the above copyright notice and this paragraph are 297 included on all such copies and derivative works. However, this 298 document itself may not be modified in any way, such as by removing 299 the copyright notice or references to the Internet Society or other 300 Internet organizations, except as needed for the purpose of 301 developing Internet standards in which case the procedures for 302 copyrights defined in the Internet Standards process must be 303 followed, or as required to translate it into languages other than 304 English. 306 The limited permissions granted above are perpetual and will not be 307 revoked by the Internet Society or its successors or assigns. 309 This document and the information contained herein is provided on an 310 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 311 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 312 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 313 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 314 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."