Provider-provisioned VPN
![](http://upload.wikimedia.org/wikipedia/commons/thumb/c/c7/Provider_provisioned_VPN.svg/220px-Provider_provisioned_VPN.svg.png)
Provider-provisioned VPN (PPVPN) are Virtual Private Network implemented by the connectivity service providers or large enterprises on networks they operate by their own. They can be opposed to "customer-provisioned VPN" where the VPN is implemented by the customer who acquire the connectivity service on top of the technical specificities of the provider.
When internet service providers implement PPVPNs on their own networks, the security model of typical PPVPN protocols is weaker with respect to tunneling protocols used in customer-provided VPN, especially for confidentiality, because data privacy may not be needed.
Provider-provisioned VPN building blocks
[edit]![](http://upload.wikimedia.org/wikipedia/commons/thumb/7/75/Site-to-Site_VPN_terminology-en.svg/300px-Site-to-Site_VPN_terminology-en.svg.png)
Depending on whether a provider-provisioned VPN (PPVPN) operates in Layer 2 (L2) or Layer 3 (L3), the building blocks described below may be L2 only, L3 only, or a combination of both. Multiprotocol Label Switching (MPLS) functionality blurs the L2–L3 identity.[1][original research?]
RFC 4026 generalized the following terms to cover L2 MPLS VPNs and L3 (BGP) VPNs, but they were introduced in RFC 2547.[2][3]
- Customer (C) devices
A device that is within a customer's network and not directly connected to the service provider's network. C devices are not aware of the VPN.
- Customer edge device (CE)
A device at the edge of the customer's network which provides access to the PPVPN. Sometimes it is just a demarcation point between provider and customer responsibility. Other providers allow customers to configure it.
- Provider edge device (PE)
A device, or set of devices, at the edge of the provider network that connects to customer networks through CE devices and presents the provider's view of the customer site. PEs are aware of the VPNs that connect through them, and maintain VPN state.
- Provider device (P)
A device that operates inside the provider's core network and does not directly interface to any customer endpoint. It might, for example, provide routing for many provider-operated tunnels that belong to different customers' PPVPNs. While the P device is a key part of implementing PPVPNs, it is not itself VPN-aware and does not maintain VPN state. Its principal role is allowing the service provider to scale its PPVPN offerings, for example, by acting as an aggregation point for multiple PEs. P-to-P connections, in such a role, often are high-capacity optical links between major locations of providers.
User-visible PPVPN services
[edit]OSI Layer 2 services
[edit]VLAN
[edit]VLAN is a Layer 2 technique that allows for the coexistence of multiple local area network (LAN) broadcast domains interconnected via trunks using the IEEE 802.1Q trunking protocol. Other trunking protocols have been used but have become obsolete, including Inter-Switch Link (ISL), IEEE 802.10 (originally a security protocol but a subset was introduced for trunking), and ATM LAN Emulation (LANE).
Virtual Private LAN Service (VPLS)
[edit]Developed by Institute of Electrical and Electronics Engineers, VLANs allow multiple tagged LANs to share common trunking. VLANs frequently comprise only customer-owned facilities. Whereas VPLS as described in the above section (OSI Layer 1 services) supports emulation of both point-to-point and point-to-multipoint topologies, the method discussed here extends Layer 2 technologies such as 802.1d and 802.1q LAN trunking to run over transports such as metro Ethernet.
As used in this context, a VPLS is a Layer 2 PPVPN, emulating the full functionality of a traditional LAN. From a user standpoint, a VPLS makes it possible to interconnect several LAN segments in a way that is transparent to the user, making the separate LAN segments behave as one single LAN.[4]
In a VPLS, the provider network emulates a learning bridge, which may include VLAN service optionally.
Pseudo-wire (PW)
[edit]PW is similar to VPLS but can provide different L2 protocols at both ends. Typically, its interface is a WAN protocol such as Asynchronous Transfer Mode or Frame Relay. In contrast, when aiming to provide the appearance of a LAN contiguous between two or more locations, the Virtual Private LAN service or IPLS would be appropriate.
Ethernet-over-IP tunneling
[edit]EtherIP (RFC 3378)[5] is an Ethernet-over-IP tunneling protocol specification. EtherIP has only a packet encapsulation mechanism. It has no confidentiality or message integrity protection. EtherIP was introduced in the FreeBSD network stack[6] and the SoftEther VPN[7] server program.
IP-only LAN-like service (IPLS)
[edit]A subset of VPLS, the CE devices must have Layer 3 capabilities; the IPLS presents packets rather than frames. It may support IPv4 or IPv6.
Ethernet virtual private network (EVPN)
[edit]Ethernet VPN (EVPN) is an advanced solution for providing Ethernet services over IP-MPLS networks. In contrast to the VPLS architectures, EVPN enables control-plane-based MAC (and MAC,IP) learning in the network. PEs participating in the EVPN instances learn the customer's MAC (MAC,IP) routes in control-plane using MP-BGP protocol. Control-plane MAC learning brings a number of benefits that allow EVPN to address the VPLS shortcomings, including support for multi-homing with per-flow load balancing and avoidance of unnecessary flooding over the MPLS core network to multiple PEs participating in the P2MP/MP2MP L2VPN (in the occurrence, for instance, of ARP query). It is defined RFC 7432.
OSI Layer 3 PPVPN architectures
[edit]This section discusses the main architectures for PPVPNs, one where the PE disambiguates duplicate addresses in a single routing instance, and the other, virtual router, in which the PE contains a virtual router instance per VPN. The former approach, and its variants, have gained the most attention.
One of the challenges of PPVPNs involves different customers using the same address space, especially the IPv4 private address space.[8] The provider must be able to disambiguate overlapping addresses in the multiple customers' PPVPNs.
- BGP/MPLS PPVPN
In the method defined by RFC 2547, BGP extensions advertise routes in the IPv4 VPN address family, which are in the form of 12-byte strings, beginning with an 8-byte route distinguisher (RD) and ending with a 4-byte IPv4 address. RDs disambiguate otherwise duplicate addresses in the same PE.[citation needed]
PEs understand the topology of each VPN, which is interconnected with MPLS tunnels directly or via P routers. In MPLS terminology, the P routers are label switch routers without awareness of VPNs.[citation needed]
- Virtual router PPVPN
The virtual router architecture,[9][10] as opposed to BGP/MPLS techniques, requires no modification to existing routing protocols such as BGP. By the provisioning of logically independent routing domains, the customer operating a VPN is completely responsible for the address space. In the various MPLS tunnels, the different PPVPNs are disambiguated by their label but do not need routing distinguishers.[citation needed]
Unencrypted tunnels
[edit]Some virtual networks use tunneling protocols without encryption to protect the privacy of data. While VPNs often provide security, an unencrypted overlay network does not fit within the secure or trusted categorization.[11] For example, a tunnel set up between two hosts with Generic Routing Encapsulation (GRE) is a virtual private network but is neither secure nor trusted.[12][13]
Native plaintext tunneling protocols include Layer 2 Tunneling Protocol (L2TP) when it is set up without IPsec and Point-to-Point Tunneling Protocol (PPTP) or Microsoft Point-to-Point Encryption (MPPE).[14]
See also
[edit]References
[edit]- ^ "Configuring PFC3BXL and PFC3B Mode Multiprotocol Label Switching" (PDF). Archived (PDF) from the original on 24 November 2020. Retrieved 24 October 2020.
- ^ E. Rosen & Y. Rekhter (March 1999). "BGP/MPLS VPNs". Internet Engineering Task Force (IETF). RFC 2547. Archived from the original on 1 September 2022. Retrieved 8 October 2022.
- ^ Lewis, Mark (2006). Comparing, designing, and deploying VPNs (1st print. ed.). Indianapolis, Ind.: Cisco Press. pp. 5–6. ISBN 1587051796.
- ^ Ethernet Bridging (OpenVPN), archived from the original on 8 October 2022, retrieved 8 October 2022
- ^ Hollenbeck, Scott; Housley, Russell (September 2002). "EtherIP: Tunneling Ethernet Frames in IP Datagrams". Archived from the original on 8 October 2022. Retrieved 8 October 2022.
- ^ Glyn M Burton: RFC 3378 EtherIP with FreeBSD Archived 23 March 2018 at the Wayback Machine, 3 February 2011
- ^ net-security.org news: Multi-protocol SoftEther VPN becomes open source Archived 8 October 2022 at the Wayback Machine, January 2014
- ^ Address Allocation for Private Internets Archived 8 October 2022 at the Wayback Machine, RFC 1918, Y. Rekhter et al., February 1996
- ^ RFC 2917, A Core MPLS IP VPN Architecture
- ^ RFC 2918, E. Chen (September 2000)
- ^ Yang, Yanyan (2006). "IPsec/VPN security policy correctness and assurance". Journal of High Speed Networks. 15: 275–289. CiteSeerX 10.1.1.94.8561.
- ^ "Overview of Provider Provisioned Virtual Private Networks (PPVPN)". Secure Thoughts. Archived from the original on 16 September 2016. Retrieved 29 August 2016.
- ^ RFC 1702: Generic Routing Encapsulation over IPv4 networks. October 1994.
- ^ IETF (1999), RFC 2661, Layer Two Tunneling Protocol "L2TP"
External Links
[edit]- "ISP Network Deployment for Integrated Access in Large Enterprises". support.huawei.com. Retrieved 2024-07-12.