Security experts have already realized the "opportunities" (read: attack vectors) offered by an enterprise-wide LAN cloud and demonstrated practical VPLS-based attacks. Demonstrations of these VPLS-based attacks can be seen on slides 23 to 31 in the All your packets belong to us presentation given at ShmooCon 2009. In addition to security threats, it's vital to understand the advantages, limitations and threats of VPLS in order to offer a range of secure services matching your customers' expectations.
The evolution of VPLS from previous networking technologies
Before addressing how service providers can offer secure VPLS solutions, it's important to know how VPLS developed. When the emerging service provider networking vendors tried to replace "old-world" technologies like (frame relay and ATM) with "new-world" IP, they focused on IP-based virtual private networks (VPNs), which were successfully implemented with MPLSVPNtechnology.
But MPLS VPN technology did not fit all the needs of incumbent service providers, which had to transport legacy traffic, such as ATM-based video surveillance, across their infrastructure. Early adopters also discovered that even though IP was ubiquitous at the time when MPLS VPN technology was introduced, large enterprises still had to support small but significant amounts of non-IP traffic. Even worse, some IP-based applications (including server clustering in disaster-recovery solutions) required transparent LAN communication.
Networking vendors tried to cover all service provider needs and introduced technologies that enabled point-to-point transport of any traffic across the service provider infrastructure, including AToM(Any Transport over MPLS) and L2TPv3 (Layer 2 Tunneling Protocol version 3). These point-to-point offerings allowed service providers to create pseudowirescarrying Ethernet, ATM or frame relay data across their MPLS or IP infrastructure, addressing the legacy needs of enterprise customers. With all the building blocks in place, it wasn't long before someone tried to replicate the Local Area Network Emulation (LANE) idea from the ATM world and build a technology that would dynamically create MPLS pseudowires to offer any-to-any bridged LAN service -- and VPLS was born.
VPLS lacks layer 3 security features
VPLS is a technology that provides any-to-any bridged Ethernet transport among several customer sites across a service provider infrastructure.
All sites on the same VPN are connected to the VPLS service and belong to the same LAN bridging domain. Frames sent by workstations attached to the site LANs are forwarded according to IEEE 802.1 bridging standards. VPLS offers none of the layer 3 security or isolation features offered by layer 3 VPN technologies, including MPLS VPN and IPSec.
VPLS layer 2 switching problems
The networking industry made numerous attempts to implement layer 2 switching -- previously known as bridging -- across lower-speed WAN networks. All of these attempts, including WAN bridges, bridge routers (WAN bridges with limited routing functionality called b routers) and ATM-based LANE, have failed because of the inherent limitations of bridging. As I wrote in the article "Making the case for Layer 2 and Layer 3 VPNs," "the world is not flat, and Layer 2 services cannot cover the needs of an entire network."
- A single workstation can saturate the WAN links of all sites connected to the VPLS service.
- An intruder gaining access to a workstation on one site can try layer 2 penetration techniques on all workstations and servers connected to the VPLS cloud.
- VPLS-based services cannot implement traffic filters, as these filters would violate the "transparent LAN" principle.
With these threats in mind, it's easy to see that you should offer VPLS services only to the customers actually requiring multi-site transparent LAN solutions, not to everyone asking about a simple VPN service.
Which customers need VPLS?
If your customer has applications that use non-IP protocols (including legacy Microsoft or AppleTalk networks), VPLS is the best alternative, as long as the customer understands its security implications. To implement a secure solution on top of a VPLS backbone, each customer site should use a router to connect to the VPLS backbone. A managed router service will achieve the maximum value-add, if the customer will go that route.
VPLS is also a perfect fit for disaster recovery scenarios, where you need to create an impression that servers located at different sites belong to the same LAN.
VPLS: Not appropriate for all customers
When a customer with insufficient IT knowledge approaches your sales team asking for a VPN solution linking numerous remote sites, VPLS might not be the best solution, and he probably needs a more scalable MPLS VPN solution. Implementing VPLS would be faster and easier (more so since the customer is not networking-savvy), but after the first major incident -- and it will happen eventually -- you'll be faced with an extremely unhappy customer and a tarnished reputation.
By: Ivan Pepelnjak
No comments:
Post a Comment