idnits 2.17.1 draft-ietf-l3vpn-gre-ip-2547-05.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.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 379. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 363. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 369. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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 (August 4, 2005) is 6811 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) ** Obsolete normative reference: RFC 1771 (ref. '3') (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2858 (ref. '4') (Obsoleted by RFC 4760) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L3VPN Working Group Y. Rekhter 3 Internet-Draft R. Bonica 4 Expires: February 5, 2006 Juniper Networks 5 E. Rosen 6 Cisco Systems, Inc. 7 August 4, 2005 9 Use of PE-PE GRE or IP in BGP/MPLS IP Virtual Private Networks 10 draft-ietf-l3vpn-gre-ip-2547-05 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 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 This Internet-Draft will expire on February 5, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This draft describes an implementation strategy for BGP/MPLS IP 44 Virtual Private Networks (VPNs) in which the outermost MPLS label 45 (i.e., the tunnel label) is replaced with either an IP header or an 46 IP header with Generic Routing Encapsulation (GRE). 48 The implementation strategy described herein enables the deployment 49 of BGP/MPLS IP VPN technology in networks whose edge devices are MPLS 50 and VPN aware, but whose interior devices are not. 52 Table of Contents 54 1. Conventions Used In This Document . . . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 7 58 4.1 MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE . . . . 7 59 4.2 MPLS-in-IP/MPLS-in-GRE Decapsulation by Egress PE . . . . 8 60 5. Implications On Packet Spoofing . . . . . . . . . . . . . . . 9 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 63 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 64 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 66 Intellectual Property and Copyright Statements . . . . . . . . 14 68 1. Conventions Used In This Document 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 RFC2119 [1]. 74 2. Introduction 76 A "conventional" BGP/MPLS IP VPN [2] is characterized as follows: 78 Each Provider Edge (PE) router maintains one or more Virtual 79 Routing and Forwarding (VRF) instances. A VRF instances is a VPN 80 specific forwarding table. 82 PE routers exchange reachability information with one another 83 using BGP [3] with multi-protocol extensions [4]. 85 MPLS Label Switching Paths (LSPs) [5] connect PE routers one 86 another. 88 In simple configurations, the VPN service is offered by a single 89 Autonomous System (AS). All service provider routers are contained 90 by a single AS and all VPN sites attach to that AS. When an ingress 91 PE router receives a packet from a VPN site, it looks up the packet's 92 destination IP address in a VRF that is associated with packet's 93 ingress attachment circuit. As a result of this lookup, the ingress 94 PE router determines an MPLS label stack, a data link header, and an 95 output interface. The label stack is prepended to the packet, the 96 data link header is prepended to that, and the resulting frame is 97 queued for the output interface. 99 The innermost label in the MPLS label stack is called the VPN route 100 label. The VPN route label is significant and visible to the egress 101 PE router only. It controls forwarding of the packet by the egress 102 PE router. 104 The outermost label in the MPLS label stack is called the tunnel 105 label. The tunnel label causes the packet to be delivered to the 106 egress PE router which understands the VPN route label. 107 Specifically, the tunnel label identifies an MPLS LSP that connects 108 the ingress PE router to the egress PE router. In the context of 109 BGP/MPLS IP VPNs, this LSP is called a tunnel LSP. 111 The tunnel LSP provides a forwarding path between the ingress and 112 egress PE routers. QoS information can be mapped from the VPN packet 113 to the tunnel LSP header so that required forwarding behaviors can be 114 maintained at each hop along the forwarding path. 116 Sections 9 and 10 of reference [2] define more complex configurations 117 (i.e., carriers' carrier and multi-AS backbones) in which service 118 providers offer L3VPN services across multiple automous systems. In 119 these configurations, VPN route labels can be stitched together 120 across AS boundares. Within each AS, tunnel LSPs carry VPN packets 121 from network edge to network edge. 123 In most configurations, tunnel LSPs never traverse AS boundaries. 124 The tunnel LSP is always contained within a single AS. In one 125 particular configuration (i.e., Inter-provider Option C), tunnel LSPs 126 may traverse AS boundaries. 128 This memo describes procedures for creating an MPLS packet which 129 carries the VPN route label, but does not carry the tunnel label. 130 Then, using either GRE or IP encapsulation, the ingress PE router 131 sends the MPLS packet across the network to the egress PE router. 133 That is, a GRE or IP tunnel replaces the tunnel LSP that was present 134 in "conventional" BGP/MPLS IP VPNs. Like the tunnel LSP, the GRE/IP 135 tunnel provides a forwarding path between the ingress and egress PE 136 routers. QoS information can be copied from the VPN packet to the 137 GRE/IP tunnel header so that required forwarding behaviors can be 138 maintained at each hop along the forwarding path. However, because 139 the GRE/IP tunnel lacks traffic engineering capabilities, any traffic 140 engineering features provided by the tunnel LSP are lost. 142 3. Motivation 144 "Conventional" BGP/MPLS IP VPNs require an MPLS Label Switched Path 145 (LSP) between a packet's ingress PE router and its egress PE router. 146 This means that a BGP/MPLS IP VPN cannot be implemented if there is a 147 part of the path between the ingress and egress PE routers which does 148 not support MPLS. 150 In order to enable BGP/MPLS IP VPNs to be deployed even when there 151 are non-MPLS routers along the path between the ingress and egress PE 152 routers, it is desirable to have an alternative which allows the 153 tunnel label to be replaced with either IP or (IP + GRE) header. The 154 encapsulation header would have the address of the egress PE router 155 in its destination IP address field, and this would cause the packet 156 to be delivered to the egress PE router. 158 In this procedure, the ingress and egress PE routers themselves must 159 support MPLS, but that is not an issue, as those routers must 160 necessarily have BGP/MPLS IP VPN support, whereas the transit routers 161 need not support MPLS or BGP/MPLS VPNs. 163 4. Specification 165 In short, the technical approach specified here is: 167 1. Continue to use MPLS to identify a VPN route, by continuing to 168 add an MPLS label stack to the VPN packets. Between the ingress 169 and egress PE router, the outermost member of the label stack will 170 represent the VPN route label. 172 2. An MPLS-in-GRE or MPLS-in-IP [6] encapsulation will be used 173 to turn the MPLS packet, described above, back into an IP packet. 174 This in effect creates a GRE or an IP tunnel between the ingress 175 PE router and the egress PE router. 177 The net effect is that an MPLS packet gets sent through a GRE or an 178 IP tunnel. 180 Service providers must protect the above mentioned IP or GRE tunnel 181 as recommended in Section 8.2 of reference [6]. As stated in that 182 document, 184 "If the tunnel lies entirely within a single administrative 185 domain, address filtering at the boundaries can be used to ensure 186 that no packet with the IP source address of a tunnel endpoint or 187 with the IP destination address of a tunnel endpoint can enter the 188 domain from outside. 190 However, when the tunnel head and the tunnel tail are not in the 191 same administrative domain, this may become difficult, and 192 filtering based on the destination address can even become 193 impossible if the packets must traverse the public Internet. 195 Sometimes only source address filtering (but not destination 196 address filtering) is done at the boundaries of an administrative 197 domain. If this is the case, the filtering does not provide 198 effective protection at all unless the decapsulator of an 199 MPLS-in-IP or MPLS-in-GRE validates the IP source address of the 200 packet. This document does not require that the decapsulator 201 validate the IP source address of the tunneled packets, but it 202 should be understood that failure to do so presupposes that there 203 is effective destination-based (or a combination of source-based 204 and destination-based) filtering at the boundaries." 206 4.1 MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE 208 The following description is not meant to specify an implementation 209 strategy; any implementation procedure which produces the same result 210 is acceptable. 212 When an ingress PE router receives a packet from a CE router, it 213 looks up the packet's destination IP address in a VRF that is 214 associated with packet's ingress attachment circuit. This enables 215 the (ingress) PE router to find a VPN-IP route. The VPN-IP route 216 will have an associated VPN route label and an associated BGP Next 217 Hop. The label is pushed on the packet. Then an IP (or IP+GRE) 218 encapsulation header is prepended to the packet, creating an 219 MPLS-in-IP (or MPLS-in-GRE) encapsulated packet. The IP source 220 address field of the encapsulation header will be an address of the 221 ingress PE router itself. The IP destination address field of the 222 encapsulation header will contain the value of the associated BGP 223 Next Hop; this will be an IP address of the egress PE router. QoS 224 information can be copied from the VPN packet to the GRE/IP tunnel 225 header so that required forwarding behaviors can be maintained at 226 each hop along the forwarding path. 228 The IP address of the remote tunnel endpoints MAY be inferred from 229 the Network Address of the Next Hop field of the MP_REACH_NLRI BGP 230 attribute [4]. Note that the set of Next Hop Network Addresses is 231 not known in advance, but is learned dynamically via the BGP 232 distribution of VPN-IP routes. Assuming a consistent set of tunnel 233 capabilities exist between all the PE's and ASBR's, no apriori 234 configuration of the remote tunnel endpoints is needed. The entire 235 set of PE and ASBR routers MUST have the same tunnel capabilities if 236 the dynamic creation of IP (or GRE) tunnels is desired. The 237 preference to use an IP (or GRE) tunnel MUST be configured. A set of 238 PE's using two or more tunnel mechanisms (i.e. LSP, GRE, IP, etc.) 239 MUST determine the tunnel type on a per peer basis. The automatic 240 association of tunnel capabilities on a per peer basis is for future 241 study. Note that these tunnels SHOULD NOT be IGP-visible links and 242 routing adjacencies SHOULD NOT be supported across these tunnel. 244 4.2 MPLS-in-IP/MPLS-in-GRE Decapsulation by Egress PE 246 Every egress PE is also an ingress PE, and hence has the ability to 247 decapsulate MPLS-in-IP (or MPLS-in-GRE) packets. After 248 decapsulation, the packets SHOULD be delivered to the routing 249 function for ordinary MPLS switching. 251 As stated above, if the service provider deploys source-based 252 filtering at network edges to protect the IP/GRE tunnel (instead of 253 destination-based filtering), the decapsulator must validate the IP 254 source address of the tunneled packets. 256 5. Implications On Packet Spoofing 258 It should be noted that if the tunnel MPLS labels are replaced with 259 an unsecured IP encapsulation, like GRE or IP, it becomes more 260 difficult to protect the VPNs against spoofed packets. This is 261 because a Service Provider (SP) can protect against spoofed MPLS 262 packets by the simple expedient of not accepting MPLS packets from 263 outside its own boundaries (or more generally by keeping track of 264 which labels are validly received over which interfaces, and 265 discarding packets which arrive with labels that are not valid for 266 their incoming interfaces). 268 By contrast, protection against spoofed IP packets requires all SP 269 boundary routers to perform filtering; either (a) filtering packets 270 from "outside" of the SP which are addressed to PE routers, or (b) 271 filtering packets from "outside" of the SP which have source 272 addresses that belong "inside" and, in addition, filtering on each PE 273 all packets which have source addresses that belong "outside" of the 274 SP. 276 The maintenance of these filter lists can be management intensive. 277 Furthermore, depending upon implementation, these filter lists can be 278 performance affecting. However, such filters may be required for 279 reasons other than protection against spoofed VPN packets, in which 280 case the additional maintenance overhead of these filters to protect 281 (among other things) against spoofing of VPN packets may be of no 282 practical significance. Note that allocating IP addresses used for 283 GRE or IP tunnels out of a single (or a small number of) IP block 284 could simplify maintenance of the filters. 286 6. Security Considerations 288 Security considerations in reference [6] apply here as well. 289 Additional security issues are discussed in the section "Implications 290 on packet spoofing" above. 292 7. IANA Considerations 294 No actions for IANA required. 296 8. Acknowledgments 298 Thanks to Robert Raszuk and Scott Wainner for their contributions to 299 this document. 301 9. Normative References 303 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 304 Levels", BCP 14, RFC 2119, March 1997. 306 [2] Rosen, E., "BGP/MPLS IP VPNs", draft-ietf-l3vpn-rfc2547bis-03 307 (work in progress), October 2004. 309 [3] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", 310 RFC 1771, March 1995. 312 [4] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol 313 Extensions for BGP-4", RFC 2858, June 2000. 315 [5] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label 316 Switching Architecture", RFC 3031, January 2001. 318 [6] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in 319 IP or Generic Routing Encapsulation (GRE)", RFC 4023, 320 March 2005. 322 Authors' Addresses 324 Yakov Rekhter 325 Juniper Networks 326 1194 N. Mathilda Ave. 327 Sunnyvale, CA 94089 328 US 330 Email: yakov@juniper.net 332 Ronald P. Bonica 333 Juniper Networks 334 2251 Corporate Park Drive 335 Herndon, VA 20171 336 US 338 Email: rbonica@juniper.net 339 Eric C. Rosen 340 Cisco Systems, Inc. 341 250 Apollo Drive 342 Chelmsford, MA 01824 343 US 345 Email: erosen@cisco.com 347 Intellectual Property Statement 349 The IETF takes no position regarding the validity or scope of any 350 Intellectual Property Rights or other rights that might be claimed to 351 pertain to the implementation or use of the technology described in 352 this document or the extent to which any license under such rights 353 might or might not be available; nor does it represent that it has 354 made any independent effort to identify any such rights. Information 355 on the procedures with respect to rights in RFC documents can be 356 found in BCP 78 and BCP 79. 358 Copies of IPR disclosures made to the IETF Secretariat and any 359 assurances of licenses to be made available, or the result of an 360 attempt made to obtain a general license or permission for the use of 361 such proprietary rights by implementers or users of this 362 specification can be obtained from the IETF on-line IPR repository at 363 http://www.ietf.org/ipr. 365 The IETF invites any interested party to bring to its attention any 366 copyrights, patents or patent applications, or other proprietary 367 rights that may cover technology that may be required to implement 368 this standard. Please address the information to the IETF at 369 ietf-ipr@ietf.org. 371 Disclaimer of Validity 373 This document and the information contained herein are provided on an 374 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 375 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 376 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 377 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 378 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 379 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 381 Copyright Statement 383 Copyright (C) The Internet Society (2005). This document is subject 384 to the rights, licenses and restrictions contained in BCP 78, and 385 except as set forth therein, the authors retain all their rights. 387 Acknowledgment 389 Funding for the RFC Editor function is currently provided by the 390 Internet Society.