RFC 4797

Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks 🎀

Okay so this is RFC 4797 🦋, an Informational doc from January 2007. The authors are Y. Rekhter and R. Bonica (both at Juniper Networks) and E. Rosen (Cisco Systems, Inc.). It doesn't obsolete or update anything in its title block.

Status of This Memo 💅

This memo is just giving info to the Internet community. It is not a standard of any kind 🙈. Anyone can share it freely, no restrictions.

Copyright Notice 🌸

Copyright (C) The IETF Trust (2007).

IESG Note 🚩

Heads up, bestie: this doc describes an automated way to set up tunnels between provider-edge routers in a VPN, but it does NOT give you an automated way to set up the security associations for those tunnels. Without that piece, it's not appropriate for the Internet standards track 😭.

Abstract ✨

This doc describes an implementation strategy for BGP/MPLS IP Virtual Private Networks (VPNs) where the outermost MPLS label (aka the tunnel label) gets swapped out for either an IP header or an IP header with Generic Routing Encapsulation (GRE) 🧚.

The whole idea is that you can deploy BGP/MPLS IP VPN tech in networks where the edge devices are MPLS and VPN aware, but the interior devices aren't 🫶.

Table of Contents 🍓

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.  Conventions Used In This Document . . . . . . . . . . . . . . . 4
3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.  Specification . . . . . . . . . . . . . . . . . . . . . . . . . 5
  4.1.  MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE  . . . . 5
  4.2.  MPLS-in-IP/MPLS-in-GRE Decapsulation by Egress PE . . . . . 6
5.  Implications on Packet Spoofing . . . . . . . . . . . . . . . . 7
6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 8

1. Introduction 🧚‍♀️

Let's start with what a "conventional" BGP/MPLS IP VPN [2] looks like, bestie 💖:

• Each Provider Edge (PE) router keeps track of one or more Virtual Routing and Forwarding (VRF) instances. A VRF instance is basically a VPN-specific forwarding table 🗺️.
• PE routers swap reachability info with each other using BGP [3] with multi-protocol extensions [4] 🤝.
• MPLS Label Switching Paths (LSPs) [5] connect the PE routers to each other 🔗.

In simple setups, one Autonomous System (AS) runs the whole VPN service. All the service provider routers live in that one AS, and all the VPN sites plug into it. So when an ingress PE gets a packet from a VPN site, it looks up the packet's destination IP address in the VRF tied to that packet's ingress attachment circuit ✨. That lookup tells the ingress PE which MPLS label stack to use, which data link header to use, and which output interface to send it out. The label stack gets prepended to the packet, the data link header gets prepended to that, and the finished frame is queued for the output interface 📦.

The innermost label in the MPLS label stack is called the VPN route label. It only matters to, and is only visible to, the egress PE router, and it's what controls how the egress PE forwards the packet 👑.

The outermost label is the tunnel label 🚇. Its job is to get the packet delivered to the egress PE that understands the VPN route label. More specifically, the tunnel label identifies an MPLS LSP that connects the ingress PE to the egress PE. In BGP/MPLS IP VPNs, that LSP is called a tunnel LSP.

The tunnel LSP gives you a forwarding path between ingress and egress PE. Quality of service (QoS) info can be mapped from the VPN packet onto the tunnel LSP header so the required forwarding behaviors stay intact at each hop along the path 💅.

Sections 9 and 10 of reference [2] cover fancier setups, like carriers' carrier and multi-AS backbones, where service providers offer L3VPN services across multiple autonomous systems. In those setups, VPN route labels can be stitched together across AS boundaries, and inside each AS, tunnel LSPs carry VPN packets from network edge to network edge 🌈.

In most configurations, tunnel LSPs never cross AS boundaries. The tunnel LSP is always inside a single AS. The one exception is Inter-provider Option C, where tunnel LSPs may cross AS boundaries 🙌.

This memo describes how to build an MPLS packet that carries the VPN route label but not the tunnel label. Then, using either GRE or IP encapsulation, the ingress PE sends that MPLS packet across the network to the egress PE 🦋.

So basically, a GRE or IP tunnel replaces the tunnel LSP from "conventional" BGP/MPLS IP VPNs. Like the tunnel LSP, the GRE/IP tunnel gives you a forwarding path between ingress and egress PE. QoS info can be copied from the VPN packet to the GRE/IP tunnel header so the required forwarding behaviors survive at each hop 🫧. The catch: the GRE/IP tunnel has no traffic engineering capabilities, so any traffic engineering features the tunnel LSP had are lost 😭.

2. Conventions Used In This Document 📚

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 [1] 🤓.

3. Motivation 🌷

"Conventional" BGP/MPLS IP VPNs need an MPLS Label Switched Path (LSP) between a packet's ingress PE and its egress PE. Which means you can't build a BGP/MPLS IP VPN if any part of the path between ingress and egress PE doesn't support MPLS 🚫.

So to let BGP/MPLS IP VPNs work even when there are non-MPLS routers on the path, it's really useful to have an alternative. That alternative lets you replace the tunnel label with either an IP header or an (IP + GRE) header. The encapsulation header carries the egress PE's address in its destination IP address field, and that's what gets the packet delivered to the egress PE 🎯.

Now, the ingress and egress PEs themselves do have to support MPLS. That's fine though, because they already need BGP/MPLS IP VPN support anyway. The transit routers, on the other hand, don't need MPLS or BGP/MPLS VPN support at all 🙌.

4. Specification 💜

Here's the short version of the technical approach:

1. Keep using MPLS to identify a VPN route by still adding an MPLS label stack to the VPN packets. Between the ingress and egress PE, the outermost member of the label stack represents the VPN route label.
2. An MPLS-in-GRE or MPLS-in-IP [6] encapsulation turns that MPLS packet back into an IP packet. This basically creates a GRE or IP tunnel between the ingress PE and the egress PE 🚀.

The net effect is that an MPLS packet gets sent through a GRE or IP tunnel ✨.

Service providers must protect that IP or GRE tunnel as recommended in Section 8.2 of reference [6]. Here's what that document says:

"If the tunnel lies entirely within a single administrative domain, address filtering at the boundaries can be used to ensure that no packet with the IP source address of a tunnel endpoint or with the IP destination address of a tunnel endpoint can enter the domain from outside. However, when the tunnel head and the tunnel tail are not in the same administrative domain, this may become difficult, and filtering based on the destination address can even become impossible if the packets must traverse the public Internet. Sometimes only source address filtering (but not destination address filtering) is done at the boundaries of an administrative domain. If this is the case, the filtering does not provide effective protection at all unless the decapsulator of an MPLS-in-IP or MPLS-in-GRE validates the IP source address of the packet. This document does not require that the decapsulator validate the IP source address of the tunneled packets, but it should be understood that failure to do so presupposes that there is effective destination-based (or a combination of source-based and destination-based) filtering at the boundaries."

This is a serious one, so watch the filtering 🚨.

4.1. MPLS-in-IP/MPLS-in-GRE Encapsulation by Ingress PE 🎀

The following description is not meant to specify an implementation strategy. Any implementation procedure that produces the same result is fine 💖.

When an ingress PE gets a packet from a Customer Edge (CE) router, it looks up the packet's destination IP address in the VRF tied to that packet's ingress attachment circuit. That lets the ingress PE find a VPN-IP route. The VPN-IP route has an associated VPN route label and an associated BGP Next Hop. The label gets pushed onto the packet. Then an IP (or IP+GRE) encapsulation header is prepended, creating an MPLS-in-IP (or MPLS-in-GRE) encapsulated packet 📦. The IP source address field of that header is an address of the ingress PE itself. The IP destination address field holds the value of the associated BGP Next Hop, which is an IP address of the egress PE 🎯. QoS info can be copied from the VPN packet to the GRE/IP tunnel header so the required forwarding behaviors are kept at each hop along the path 🫶.

The IP address of the remote tunnel endpoints MAY be inferred from the Network Address of the Next Hop field of the MP_REACH_NLRI BGP attribute [4]. Keep in mind the set of Next Hop Network Addresses isn't known ahead of time. It's learned dynamically through the BGP distribution of VPN-IP routes 🔍. As long as a consistent set of tunnel capabilities exists between all the PEs and Autonomous System Border Routers (ASBRs), you don't need any a priori configuration of the remote tunnel endpoints 🧠. The entire set of PEs and ASBRs MUST have the same tunnel capabilities if you want dynamic creation of IP (or GRE) tunnels 🙏. The preference to use an IP (or GRE) tunnel MUST be configured. A set of PEs using two or more tunnel mechanisms (i.e., LSP, GRE, IP, etc.) MUST determine the tunnel type on a per-peer basis. Automatic association of tunnel capabilities on a per-peer basis is for future study 🔮. And finally, these tunnels SHOULD NOT be IGP-visible links, and routing adjacencies SHOULD NOT be supported across these tunnels 🙅‍♀️.

4.2. MPLS-in-IP/MPLS-in-GRE Decapsulation by Egress PE ✨

Okay so every egress PE is also an ingress PE 💅, which means it can also decapsulate MPLS-in-IP (or MPLS-in-GRE) packets 🦋. Once the packets are unwrapped, they SHOULD be handed to the routing function for ordinary MPLS switching. Main character energy 👑

Now here's the lowkey important bit 🙈. If the service provider uses source-based filtering at the network edges to protect the IP/GRE tunnel (instead of destination-based filtering), then the decapsulator must validate the IP source address of the tunneled packets. Literally don't skip this one, bestie 💀

5. Implications on Packet Spoofing 🕵️‍♀️

It's giving "worth knowing" 🌸. If the tunnel MPLS labels get swapped out for an unsecured IP encapsulation, like GRE or plain IP, then it becomes way harder to protect the VPNs against spoofed packets 😭.

The reason is that a Service Provider (SP) can block spoofed MPLS packets really simply: it just doesn't accept MPLS packets from outside its own boundaries. Or, more generally, it keeps track of which labels are validly received over which interfaces, and throws away any packet that shows up with a label that isn't valid for the interface it came in on 🧚.

Protecting against spoofed IP packets is a whole different vibe 🥲. It requires all SP boundary routers to do filtering. That means either (a) filtering packets from "outside" the SP that are addressed to PE routers, or (b) filtering packets from "outside" the SP that have source addresses belonging "inside", and also filtering on each PE all packets that have source addresses belonging "outside" the SP 🔥.

Ngl, maintaining these filter lists can be a lot of management work 💅. Depending on the implementation, they can also hit performance 📉. However, these filters may be required for reasons other than protecting against spoofed VPN packets. In that case, the extra maintenance overhead of these filters for protection against VPN packet spoofing (among other things) may be of no practical significance 🫶. One tip the original mentions: allocating the IP addresses used for GRE or IP tunnels out of a single (or a small number of) IP block could simplify maintaining the filters 🎀.

6. Security Considerations 🚨

Okay this section is SERIOUS bestie 😤. Security considerations in reference [6] apply here as well 🔐. On top of that, additional security issues are discussed in the previous section "Implications on Packet Spoofing" 💜. Go read that one again, no skipping!

7. Acknowledgments 🫶

Big thank you to Robert Raszuk and Scott Wainner for their contributions to this document 🌈✨.

8. Normative References 📚

• [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [2] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
• [3] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
• [4] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
• [5] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
• [6] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.

Authors' Addresses 🏡

Yakov Rekhter
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA  94089
US

EMail: yakov@juniper.net


Ronald P. Bonica
Juniper Networks
2251 Corporate Park Drive
Herndon, VA  20171
US

EMail: rbonica@juniper.net


Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA  01719
US

EMail: erosen@cisco.com

---

Full Copyright Statement ©️

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property 🧾

The IETF takes no position regarding the validity or scope of any Intellectual 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. It also doesn't represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79 📖.

Copies of IPR disclosures made to 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 implementers or users of this specification, can be obtained from the IETF 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 that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org 💌.

Acknowledgement 💖

Funding for the RFC Editor function is currently provided by the Internet Society 🌷.