What is a VP²N, and What makes it a better VPN?
Chuck Wade
The modern public Internet has become the primary infrastructure supporting communications of all types. However, this same infrastructure harbors many threats from a diverse collection of adversaries, thus presenting serious challenges for enterprises that require absolute security, yet must rely on the public Internet for core communications services. This article presents an expansive view of how virtual private networks can be designed to reconcile these conflicting needs while addressing other essential requirements. Central to this approach is a comprehensive understanding of what ‘private’ means in practice.
The term Virtual Private Network or VPN has been widely used since the latter half of the 1980s, but the meaning of this term has changed significantly from its origins. In 21st-century usage, the term VPN is closely associated with various methods for encrypting information transported across the public Internet. There are many VPN technologies for establishing encrypted sessions, and a variety of publicly available VPN services have emerged to facilitate setup and usage of encrypted communications.
However, encrypting data in transit across a VPN does not sufficiently isolate traffic to avoid some real-world threats. Furthermore, the equipment that provides encrypted communications is itself vulnerable to threats originating from the public Internet. There have been numerous examples throughout this century where equipment flaws have led to complete compromises of VPNs or where VPNs have been the vector for successful attacks on enterprise intranets.
History provides several worthwhile lessons that can inform new approaches to designing more secure VPNs, so looking to the past is a good place to start.
The Original VPNs
The first VPNs emerged in the latter half of the 1980s, but they did not provide encryption and were essentially bundles of point-to-point circuits provided directly by the major telcos at the time. Prior to the emergence of the modern Internet, the primary telecommunications costs for enterprises involved measured-use telephone calls used for both voice and modem (i.e., data, fax) communications. In other words, the monthly telephone bills that enterprises had to face were exceedingly complex accounting records for every minute of use for switched telephone services, with charges based on factors such as whether calls were considered “local” to an area, or were long-distance calls going outside of the local area. Other factors included time-of-day usage or call origination. In every case, the duration of a call was multiplied by the applicable rates to determine the cost of placing a call, whether voice or modem.
For many enterprises, the majority of tariffed calls were between the enterprise’s own sites. If calls were placed within a site, then typically a local PBX handled the call (i.e., calls were placed between PBX extensions), and hence represented no incremental cost. To gain control over inter-site telecommunications costs, enterprises started leasing circuits between their PBXs to handle inter-site calling, thereby reducing measured-use costs while improving internal communications. Enterprise data centers also increasingly utilized leased telco circuits for data communications, particularly for maintaining continuous connections between sites.
During this ’80s timeframe, telco-provided digital circuits became more commonplace, and enterprises were quick to adopt digital leased circuits for both data and voice. Also, the use of trunked digital services, especially T1 circuits that could handle up to 24 digital circuits over the same wires used to handle a single analog circuit, led to a surge in what was generally referred to as “private” enterprise networks. Since leased services essentially bypassed the telco call switching services, these enterprise networks were paying for themselves through elimination of measured-use internal calling charges. Another source of cost savings came from acquiring bandwidth in bulk, and then using it for both voice and rapidly growing data communications services. Some enterprises even started running their own circuits between sites or using microwave communications to bypass the telcos entirely.
The shift toward private enterprise networks represented both a threat and an opportunity to the major telcos. While the loss of traditional toll calling revenue was beginning to impact their bottom lines, the growth in data communications was a potential opportunity to replace lost revenue. What the telcos wanted to head off, though, was the move by enterprises to deploy their own circuits or microwave links. There were also concerns that third parties were beginning to compete directly for private circuit business by leveraging new fiber-optic communications services — a trend that was emerging in major metropolitan areas.
Since the major telcos recognized that they had an advantage with more circuit infrastructure going to more places than any of the emerging alternative providers, they began to develop and offer services that made it easier for enterprises to acquire circuits utilizing the telco’s infrastructure. One hook that was especially attractive was that the telcos could provide rapid additions of new circuits to an enterprise network.
The pitch from telcos to enterprises was that the telco could offer the same circuits to enterprises, but built from the public infrastructure that the telcos used to manage their own networks. The marketing term used to describe these service offerings was “Virtual Private Networking,” where enterprises were getting virtually the same services as they used for their private networks, but utilizing the public telco infrastructure. What made the VPN approach attractive was the ease of deployment and the ability to rely on the telcos to manage the enterprise’s circuits.
The two meanings of “Private”
To understand how this original concept of VPNs morphed into the modern concept involving encrypted tunnels, it helps to recognize that the term ‘private’ has two distinct meanings in the English language that can lead to confusion as to what is meant when something is described as being private.
The first meaning is to imply that some property or resource is owned or controlled by a particular party or closely aligned parties. A useful synonym is the concept of exclusivity.
The second meaning refers to not disclosing or keeping hidden details about, or information relating to, a party or parties. Confidential is an appropriate synonym for this meaning of ‘private.’
It is worth noting that the term ‘public’ is an antonym for both meanings of private, and so public also has two meanings: (1) open sharing of property or resources with anyone, and (2) unconstrained access by anyone to details or information. It is unfortunate that private and public both start with the letter ‘P,’ since this has resulted in some confusing acronyms where either term might apply where ‘P’ is used.
Given these insights into the meaning of ‘private,’ it should be clear that the original circa 1980s use of the term VPN implied exclusivity, as enterprises were offered apparently exclusive access to circuits, even though those circuits utilized shared public infrastructure. In fact, it was not at all uncommon for directly competing enterprises to be using circuits that traversed the same wires. While confidentiality was a concern, the general belief was that if traffic was isolated on separate circuits, then it was not exposed. While that was (and is) a naïve perspective, there are still significant benefits to exclusivity that are worth considering for modern 21st-century enterprise networks.
The remainder of this article will examine ways to build VPNs that offer both exclusivity and confidentiality, and explain why this combined approach offers greater security. A new term, “VP²N,” is introduced to describe this dual-purpose approach to building networks that can be fundamentally more secure.
Achieving Confidentiality for an Enterprise Network
At the start of the second quarter of the 21st century, the public Internet is by far the predominant public network infrastructure. While some enterprises do “own” private fiber lines or microwave links, these sorts of resources are often used to extend Internet access (or ‘intranets’) within an enterprise. At the same time, the public Internet is rife with abuse and misuse, resulting in serious security threats from all potential vectors and threat actors of all stripes.
In this context, strong encryption of data in transit and at rest represents table stakes for protecting any enterprise of any size that makes use of the public Internet. Fortunately, strong encryption technologies are now commodities that are baked into many products, including network equipment, such as routers and firewalls. Approaches will be presented for how enterprises can leverage routers or firewalls (hereinafter referred to as just ‘routers’) to communicate securely between enterprise sites via the public Internet. The specific problem of interest will be how to build a multi-site VP²N using current router technology that can provide a high degree of protection for local network resources at each site.
Figure 1 shows a hypothetical enterprise network spanning five sites interconnected via the public Internet. At each site, local protected networks connect to a router that establishes encrypted tunnels over the Internet to each of the other four sites. In essence, this network interconnects the local network resources at each of the five sites. The routers themselves can be off-the-shelf commodity products, presuming that they can operate at gigabit speeds and offer hardware support for the encryption protocols. Ideally, they should also provide switched VLAN support for local network connections at each site while providing extension of the Ethernet layer 2 protocols across the encrypted tunnels (e.g., using Layer 2 Tunnelling Protocol, L2TP, or equivalent protocols).
This sort of enterprise network is fairly typical, and there are no significant technical hurdles to constructing a traditional VPN network of this kind. However, the devil is in the details, and some details worth paying close attention to are:
Authentication
Whatever encryption protocols are employed, they must support mutual authentication of the tunnel endpoints using, at a minimum, public key exchanges. Ideally, public key certificates should be used to improve scalability and manageability. For these sorts of VPN networks, a single, stand-alone Certification Authority (CA) can be used to issue certificates for each router along with certificate revocation lists (CRLs) for potentially compromised keys or planned retirement of network routers.
Perfect Forward Secrecy
To reduce the risk of adversaries recording traffic traversing an encrypted tunnel and subjecting these recordings to intense off-line attacks, the encryption protocols used should support perfect forward secrecy. This is also a hedge against the potential that quantum computing could undermine current key-exchange protocols, thereby enabling decryption of recorded traffic in the future.
Recovery
Change is the enemy of stability, and unstable situations can introduce exposures. Consequently, a VPN network should anticipate situations such as equipment failures, equipment theft, site decommissioning, introduction of new sites, key compromises, departure of key employees, and onboarding of new employees.
Firewall rules
Any device exposed to the public Internet (i.e., a VPN router) needs to protect itself, and restrict forwarding of any traffic that is not expressly allowed. Router firewall rules must be based on the principle of deny everything except what is allowed, and any allowed traffic must be logged. Firewall rules can also reduce the exposure footprint by disabling any service that is not actually needed. Firewall rules should also protect the routers from internal attacks arriving on local connection ports.
Audit controls
Auditable control procedures must be established to constantly demonstrate that the VPN is in compliance with required policies, and that practices are followed that maintain compliance. In particular, operation of the VPN system should adhere to the principle of least privilege, and multi-party controls should be employed for any sensitive actions or authorizations.
Network Management
Without active monitoring of overall system behavior, it is not possible to know if the system is behaving as expected. Proactive alerts need to be issued that will reach responsible parties when any anomalous conditions arise. Change management must track every network configuration change, and provide the ability to fall back when changes cause undesirable behavior. Access to management controls must be tightly restricted, and all actions logged. Ideally, management access should be constrained to only come from isolated VLANs or VRFs. Of critical importance, software patches dealing with security concerns should be promptly applied to any affected devices.
Layered encryption
A VPN only encrypts traffic in motion. Furthermore, the traffic is decrypted and potentially available in clear text as soon as it emerges from encryption tunnel endpoints. Robust confidentiality should ensure that data at rest is also encrypted, ideally using methods that are independent of how VPN encryption is implemented. Data moved between sites should remain encrypted before entering the VPN and after emerging at the destination. Interactive user sessions should employ end-to-end encryption between the user’s workstation and any server or other system accessed via the workstation. All of these encryption methods must incorporate strong authentication of the parties as an integral aspect of establishing each encrypted session.
Traffic hiding
While observers on the public Internet won’t be able to directly eavesdrop on the content of communications between sites, it would still be possible to observe traffic patterns based on time, volume, and endpoints. Such information leakage can sometimes be used to glean insights that should not be exposed to threat actors. Where this is a concern, it may be necessary to introduce random flows of traffic that will hide traffic patterns that should not be observed.
Internet access
One of the trickiest issues to deal with for any VPN is where and how Internet access should be allowed. It can be tempting to have the routers that establish the inter-site VPN connections also act as Internet firewalls supporting user access from or to the Internet. However, as a practical matter, it is often best to separate these functions between different pieces of equipment. Given that high-performance routers can be acquired at modest cost, it makes little sense to try and save on equipment costs by consolidating the router and Internet firewall functions. A better strategy is often to establish only one or two places where Internet access is allowed, and force all traffic from the protected local networks to utilize these restricted access points.
While it might be harder than it first appears, it is quite feasible to build a VPN of the type shown in Figure 1 that complies with accepted best practices. As long as such a VPN is actively monitored and managed, this approach can provide robust security. But, can it be made better?
Adding Exclusivity to an Enterprise VP²N
A glaring concern with the VPN shown above is that every router connects directly to the Internet. Any examination of a router’s logs will show a constant barrage of probes and attacks coming from all over the world. While it should not be possible for such attacks to compromise a router, the reality is that there have been far too many examples of routers (and firewalls) having egregious exposures that have led to total compromise of such devices. Should any one of the routers succumb to a successful attack, the entire enterprise network would potentially be compromised.
But there is a simple, straightforward way to mitigate this risk: Eliminate any default routes in the routers. Instead, add static routes to each of the sanctioned remote sites. With this simple change, each router can only communicate with its peers, and any attempt from the public Internet to access the router will go nowhere, since there would be no way for the router to respond. This simple approach achieves robust exclusivity, and hence the other ‘P’ in VP²N.
One valuable benefit of this approach is that authentication between the router peers is now multi-factor. Before the first packet tries to establish an encrypted tunnel between the routers, there must be a route defined on each router pointing to its peer. Not only does this leverage completely independent technical implementations, but it also provides a form of mutual authentication, since both sides must be configured to enable exchange of any packets. Furthermore, the public IP addresses for each router cannot be randomly assigned, but must be allocated by the Internet service provider, thereby providing another control.
Once the routers are able to exchange packets over the Internet, the only communications should be what is required to establish an encrypted tunnel, and this should, in turn, require mutual authentication utilizing public key cryptography (or its post-quantum equivalent). Hence, two independent authentication factors are required and cannot be circumvented.
Another important benefit of this approach is that most of the noise in the router logs will go away, since there will be no visible attempts to probe or attack the routers. This is important, since log monitoring will be much simpler, and any anomalies should be quite apparent. This isolation can also help mitigate some types of DDoS attacks that attempt to overwhelm local resources.
While static assignment of routes to peers is a straightforward process that can be automated for improved maintainability and scalability, it is also possible to introduce dynamic routing between the peers. If dynamic routing is introduced, then separate security protocols should be established to handle peer acceptance and exchange of route tables. One benefit of using dynamic routing is that it would provide an independent check on the reachability of each peer, along with detection of any problems with encrypted tunnels.
Another approach could use VLANs to isolate dynamic routing protocols so that even an inside operator would not be able to inject invalid routes. As noted above, a similar approach should also be used for isolating management access to the routers.
The Public Internet as a Private² Full-Mesh Network
One of the benefits derived from the telco-provided VPN services introduced in the latter half of the 1980s was that the use of multiplexed services utilizing T1 and T3 trunked circuits made it feasible to build meshier networks — i.e., networks with more connections between sites. For example, a site connected via a T1 circuit with 24 channels could utilize telco services to direct those 24 channels to multiple destinations. This capability was useful to the legacy networks of the day, but also proved helpful in building out early Internet services in the 1990s.
A full-mesh network where every node in the network has a direct connection to every other node requires ‘C’ connections as defined by this formula:
C = (n²— n)/2
where ‘n’ is the number of nodes or sites in the network. Figure 1 illustrates a full-mesh network with five nodes and C = 10 connections. Although this implies that the number of required connections in a full-mesh network is proportional to the square of ‘n’ — a potentially limiting factor as networks scale to many nodes — this is not a problem for a virtual network where the connections are virtual tunnels defined by software. Instead, each node will need (n — 1) virtual connections to its peers, which is a linear problem that can be readily handled by using network models to generate the required configurations for both tunnels and static routes.
Deploying full-mesh VP²Ns allows consistency for all inter-site communications, even when connecting to diverse Internet services. For example, some sites might be served by providers using IPv6, while other sites might interface with IPv4 providers. These dual-stack situations can be handled within the VP²N, thus isolating the private devices connected via this network from having to support dual-stack configurations.
A full-mesh network is also easier to manage and maintain. When problems occur, such as a router failure or connectivity problems within the public Internet, it is easier to determine the cause and take corrective action. At the same time, the VP²N provides a robust, secure facility for extending network management to every site within the private network.
These concepts can be leveraged to enhance resilience for a VP²N by supporting parallel inter-site connections utilizing dedicated resources such as direct fiber pathways or microwave links. Similarly, modern wireless cellular networks and low-earth orbit (LEO) satellite networks can be used to provide alternative paths that can circumvent problems within an Internet last-mile provider or the Internet at large.
An ideal approach for a highly resilient network would utilize redundant routers at each site that could simultaneously connect to both a traditional ISP service and a wireless service. This approach can eliminate multiple single-points-of-failure, including physical infrastructure at a site. For example, an ISP connection might enter a site from the street, while a LEO satellite connection could enter from the site’s roof and take diverse paths within the site.
In conclusion…
Although the VP²N approach does not fit all use cases, there are still many important use cases where this approach should be considered. Some examples include public safety networks, industrial control systems, electrical grid operations, supply chain logistics, financial networks, physical security systems, hospital systems, and even small enterprises that need robust security with minimal fuss. A key benefit is that these approaches can scale from small networks to quite large networks comprising hundreds of sites and many thousands of devices all interconnected via fully private networks.
As a final observation, the approaches outlined above can be implemented in a phased manner to ease deployment and allow graceful transitions from existing networked systems. However, the focus needs to be on achieving both confidentiality and exclusivity in a fully coordinated manner — that is the essential objective.
Keep Out, Photo by Sam Davis on Unsplash
Window blinds, Photo by something magical on Unsplash