idnits 2.17.1 draft-ietf-ospf-2547-dnbit-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 306. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 279. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 292. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 (March 2004) is 7341 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) == 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-01 Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 6 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: September 2004 Cisco Systems, Inc. 6 Padma Pillay-Esnault 7 Juniper Networks, Inc. 9 March 2004 11 Using an LSA Options Bit to Prevent Looping in BGP/MPLS IP VPNs 13 draft-ietf-ospf-2547-dnbit-04.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 OSPFv2 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 OSPFv2 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 ................................. 7 65 9 Intellectual Property Statement ...................... 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-IPv4 address family", so that they are distinct from 99 ordinary Internet routes. The VPN-IPv4 address family also extends 100 the IP addresses on the left so that address prefixes from two 101 different VPNs are always distinct to BGP, even if both VPNs use the 102 same piece of the private RFC1918 address space. Thus routes from 103 different VPNs can be carried by a single BGP instance, and can be 104 stored in a common BGP table, without fear of conflict. 106 If a PE router receives a particular VPN-IPv4 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 OSPFv2 as its internal routing protocol, it is not 118 necessarily the case that the CE routers of that VPN use OSPFv2 to 119 peer with the PE routers. Each site in a VPN can use OSPFv2 as its 120 intra-site routing protocol, while using, e.g., BGP or RIP to 121 distribute routes to a PE router. However, it is certainly 122 convenient, when OSPFv2 is being used intra-site, to use it on the 123 PE-CE link as well, and [VPN] explicitly allows this. In this case, 124 a PE will run a separate instance of OSPFv2 for each VPN which is 125 attached to the PE; the PE will in general have multiple VPN-specific 126 OSPFv2 routing tables. 128 When OSPFv2 is used on a PE-CE link which belongs to a particular 129 VPN, the PE router must redistribute to that VPN's OSPFv2 instance 130 certain 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 OSPFv2 are advertised 136 in 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-IPv4 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-IPv4 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 OSPFv2 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-IPv4 164 route, then PE2 is violating one of the constraints for loop-freedom 165 in BGP, 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 [VPN-OSPF], 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. 208 (This restriction is analogous to the usual OSPF restriction that 209 inter-area routes which are learned from area 0 are not passed back 210 to area 0.) 212 Note that the DN bit has no other effect on LSA handling. In 213 particular, an LSA with the DN bit set will be put in the topological 214 database, aged, flooded, etc., just as if DN were not set. 216 5. Security Considerations 218 An attacker may cause the DN bit to be set, in an LSA traveling from 219 CE to PE, when the DN bit should really be clear. This may cause the 220 address prefixes mentioned in that LSA to be unreachable from other 221 sites of the VPN. Similarly, an attacker may cause the DN bit to be 222 clear, in an LSA traveling in either direction, when the DN bit 223 should really be set. This may cause routing loops for traffic which 224 is destined to the address prefixes mentioned in that LSA. 226 These possibilities may be eliminated by using cryptographic 227 authentication as specified in section D of [OSPFv2]. 229 6. Acknowledgments 231 The idea of using the high-order options bit for this purpose is due 232 to Derek Yeung. Thanks to Yakov Rekhter for his contribution to this 233 work. We also wish to thank Acee Lindem for his helpful comments. 235 7. Authors' Addresses 237 Eric C. Rosen 238 Cisco Systems, Inc. 239 1414 Massachusetts Avenue 240 Boxborough, MA 01719 242 E-mail: erosen@cisco.com 244 Peter Psenak 245 Parc Pegasus, 246 De Kleetlaan 6A 247 1831 Diegem 248 Belgium 250 E-mail: ppsenak@cisco.com 252 Padma Pillay-Esnault 253 Juniper Networks 254 1194 N. Mathilda Avenue 255 Sunnyvale, CA 94089 257 E-mail: padma@juniper.net 259 8. Normative References 261 [OSPFv2] "OSPF Version 2", RFC 2328, Moy, J., April 1998 263 [VPN] "BGP/MPLS IP VPNs", draft-ietf-l3vpn-rfc2547bis-01.txt, Rosen, 264 Rekhter, et. al., September 2003 266 [VPN-OSPF] "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", draft- 267 ietf-l3vpn-ospf-2547-01.txt, Rosen, Psenak, Pillay-Esnault, February 268 2004 270 9. Intellectual Property Statement 272 The IETF takes no position regarding the validity or scope of any 273 Intellectual Property Rights or other rights that might be claimed to 274 pertain to the implementation or use of the technology described in 275 this document or the extent to which any license under such rights 276 might or might not be available; nor does it represent that it has 277 made any independent effort to identify any such rights. Information 278 on the procedures with respect to rights in RFC documents can be 279 found in BCP 78 and BCP 79. 281 Copies of IPR disclosures made to the IETF Secretariat and any 282 assurances of licenses to be made available, or the result of an 283 attempt made to obtain a general license or permission for the use of 284 such proprietary rights by implementers or users of this 285 specification can be obtained from the IETF on-line IPR repository at 286 http://www.ietf.org/ipr. 288 The IETF invites any interested party to bring to its attention any 289 copyrights, patents or patent applications, or other proprietary 290 rights that may cover technology that may be required to implement 291 this standard. Please address the information to the IETF at ietf- 292 ipr@ietf.org. 294 10. Full Copyright Statement 296 Copyright (C) The Internet Society (2004). This document is subject 297 to the rights, licenses and restrictions contained in BCP 78 and 298 except as set forth therein, the authors retain all their rights. 300 This document and the information contained herein are provided on an 301 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 302 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 303 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 304 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 305 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 306 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.