Talk:Virtual private network

Textbooks and conflict of interest

I've written books in this area, but wanted to leave it to others to recommend appropriate references or further reading. I happen to think they are informative on customer and provider VPN relationships :-). For the customer side, WAN Survival Guide (Wiley, 2001), and for the provider side, Building Service Provider Networks (Wiley, 2002).

I did put in a public domain, very basic tutorial. Howard C. Berkowitz 12:18, 14 July 2008 (CDT)

Query

The current initial definition reads: "A virtual private network (VPN) a set of sites, owned by customers, which are connected through some type of backbone." I think that is seriously misleading. Yes, there are quite a few VPNs to which that definition applies, but it does not seem general enough.

I'd prefer something like "A Virtual Private Network, or VPN, is a network which can safely be used as if it were private, even though some of its communication uses insecure connections. All traffic on those connections is encrypted."

To my way of thinking, the current article is clear and well-written, but mostly wrong as a general description of VPNs. Provider-based VPNs are an important class of VPN, but they should be described either under a sub-heading or in a separate article, not as the main VPN article.

However, I thought I'd ask here before making major changes Sandy Harris 08:54, 1 August 2008 (CDT)

Some good points, Sandy, that probably need some expansion or clarification of its terms. Let me start with "customer". I'll come back to why I think the definition is accurate, and my first example is one where your revision wouldn't have been applicable.

In IETF discussions and documents, "customer" is used in several ways. It's perfectly acceptable to have no contracted external provider, but you will still have an internal network administrator that is considered the "provider". Let me take one simple and real example of what was totally invisible to outside providers, but where the separation still made sense.

Companies A and B merged, and their network groups consolidated. Both had numbered their networks in IPv4 private address space, so there were many address collisions in 10.0.0.0/8. They consolidated their network administration team, and asked for help because they weren't ready to renumber everything. Unfortunately, we don't have a whiteboard handy, and I note that graphics of some of these are useful.

In the first design, we arbitrarily said the former customer A network would be the "backbone" as well as providing for the needs of A. This was done without encryption, but with Generic Route Encapsulation (GRE) tunnels. Assume you are at a company B factory, site B1, which has several routers around its campus, numbered in B space. Router B1R2 connects to a client LAN with end user BU100 on it. B1R0 interconnects the three local B-space only routers, and then had a frame relay interface B1R0C1 ("connector 1") that linked it to sites B2 and B3 in other cities.

It turned out that company A had an facility of its own in the same city as B1, with local routers A1R1, A1R2 (LAN only) and a much faster wide area link on A1R0. In city A99, there was a main router, A99R0 and two office routers, A99R1 and A99R2. At this point, assume A and B run completely different routing protocols. There also was a B facility, B99, in city 99.

On router B1R0, we created a tunnel interface on the WAN interface, the tunnel in B space. The WAN interface itself was in A space and connected to A99R0, where there was another tunnel interface in B space mapped onto the WAN interface. In city 99, some people in company B moved to the building with router A99R1 in it.

At this point, an ugly one, A-space is both the enterprise A VPN and the backbone. B space is real space in B-only facility, but is always a VPN mapped onto A space in the WAN.

For the interim step, we configured B space tunnel interfaces on A99R0 and A99R1. We added an Ethernet interface, A99R1C2, to the router where the B people were moving to the A company location, and numbered that interface in B space. When a packet started out in City 1 on router B1R2, it would go by an in-town WAN link to B1R0. The packet would physically go over a new local line that connected B1R0 to A1R0, and that line terminated on a second WAN interface in A1R0, which again had both an A-space physical address and a B-space tunnel address. There was a B-space tunnel over the WAN link between the cities. When the packet arrived at A99R0, that router had an A-space physical interface to the A99R1 site, with B-space interfces mapped onto it. Ethernet interface A99R1C2 was actually numbered in B space, and the former B people still thought their computer talked B address space to city 1; the packets atarted on a B space interface, traveled over the B tunnels in City 1 to the B tunnels in city 99, and eventually got to the B-space Ethernet, A99R1C2.

Subsequently, we added a third space, Y, into 172.16.0.0/16, and created a true backbone space, Z, in 192.168.0.0/16 and began renumbering both A and B into it; see my RFC 2071 for some of the router-specific techniques. At this point, A, B, and Y are all VPNs mapped onto Z-space.

Nothing went over the public Internet; the WAN was all dedicated line and frame relay, which were judged to be secure enough without encryption. Essentially, we mapped a VPN for B space onto the combined user and backbone A. No ISPs involved. No encryption.

Where the provider-provisioned VPN terminology became very useful were to describe routers:

• A space only and B space only routers were the equivalent of CEs, which, in a PPVPN, is only aware of its own VPN.
• Routers with interfaces in more than one VPN(A, B, or Y) were PE; they might also connect to Z space.
• Routers, which initially just aggregated traffic onto faster links and were in Z space only were P routers.

I'm perfectly willing to make the point that the "provider" may be internal to an enterprise, but it is quite common to use multiple VPNs, sometimes encrypted and sometimes not, in a network run by the enterprise's network group. If some of the inter-site links are on the public Internet, they certainly would be encrypted, but the ISP has absolutely no idea that several enterprise VPNs are running over it. If he looked at the line, he would only see IPSec packets in public address space he assigned.

I definitely would not say that that an architectural model with the concepts of CE, PE, and P, and backbones, is a provider-provisioned only technique. It's quite common to have the architecture in pure intranets. CE/PE/P is not unique to BGP/MPLS PPVPNs. As you can see, the functions all existed in a pure GRE backbone. Encryption may be present in all, part, or none of the backbone and/or VPNs.

Howard C. Berkowitz 12:42, 1 August 2008 (CDT)

To me, your example is a real private WAN, or set of them. I would not use the virtual unless some of the privacy is implemented by encrypting otherwise insecure links. But then, the only VPN work I've done was on FreeS/WAN, Linux IPsec, so perhaps I have too narrow a view. Anyone else care to chime in? Sandy Harris 19:22, 1 August 2008 (CDT)

Virtualization need have nothing to do with encryption

I'm not making these examples up out of random opinion, but IETF work that easily go back ten years.

In 2000, http://www.ietf.org/rfc/rfc2764.txt observed "VPN is simply defined as the 'emulation of a private Wide Area Network (WAN) facility using IP facilities' (including the public Internet, or private IP backbones). As such, there are as many types of VPNs as there are types of WANs, hence the confusion over what exactly constitutes a VPN...In this document a VPN is modeled as a connectivity object"

To take your example with Linux IPSec, surely you don't think that the encrypted paths were physical? They were mapped onto IP, which is agnostic of the transmission medium.

GMPLS, ASON, and other work assume multiple levels of abstraction or multiplexing. If I go to an undersea optical ring in the Southwest Pacific, I'd find ten or more wavelengths over it, each running OC-192 signal (about 10 Gbps). Each one of those lambdas (i.e., wavelengths) could be leased to a different international carrier, who is a wholesaler to ten national telecommunications provider. The fiber lessor puts ten 802.1Q-in-Q tunneled VLANs, each carrying ten of their customers' entire bandwidth. Into each of those customer appearance, the customer puts ten of his own 802.1Q (not Q-in-Q) VLANs. Into each one of those VLANs is an assortment of IP tunnels using IPIP, IPSec, GRE, and L2TP, all appearing as an interface (sortware defined, but routers don't care). They could also be MPLS or GMPLS tunnels. Every one of those GRE tunnels could hve ten IPSec domains within it.

What, then, is real? What is virtual? I can keep stacking protocols, and this is not a hypothetical -- I constantly see networks at that level. When there is a single fiber cut and hundreds of apparently independent circuits die, it gives a sense of how much encapsulation there may be -- and, for that matter, if I had done a good failover on that fiber, the users might never notice that a kilometer of fiber is now wrapped around a truck's wheel.

If you have authoritative definitions that say security is the determinant of a VPN, I'd like to see them. Howard C. Berkowitz 20:08, 1 August 2008 (CDT)

VPN Consortium http://www.vpnc.org/vpn-technologies.html gives:

"A virtual private network (VPN) is a private data network that makes use of the public telecommunication infrastructure, maintaining privacy through the use of a tunneling protocol and security procedures. ...

"Before the Internet became nearly-universal, a virtual private network consisted of one or more circuits leased from a communications provider. ... The VPN customer trusted the VPN provider to maintain the integrity of the circuits and to use the best available business practices to avoid snooping of the network traffic. Thus, these are called trusted VPNs.

"As the Internet became more popular ... Seeing that trusted VPNs offered no real security, vendors started to create protocols that would allow traffic to be encrypted at the edge of one network ... and then decrypted when it reached ... Networks that are constructed using encryption are called secure VPNs.

"A secure VPN can be run as part of a trusted VPN, creating a ... hybrid VPNs.

I concede that the definition of VPN need not include encryption, but I still much prefer their definition to what is in the article because it does mention security and does not involve "customers" and "providers", neither of which are necessarily required either.

I understand that you prefer it, but the IETF routinely uses the CE/PE/P router terminology with "provider" understood to mean the operator of the backbone, which can be, and often is, the same enterprise. In the example I gave of the merged companies, the only WAN connections were frame relay or private line; the "provider" of the VPN was the network operations group of the merged companies. I've personally given presentations at the North American Network Operators Group (NANOG) where it was completely understood that the outside service provider simply provided IP or data link connectivity, and the VPN function was an overlay operated by the "customer" — but many enterprise network groups consider the end users as their "customer".

Indeed, one of the more common reasons that ISPs will recommend that the customer run his own VPN is that the enterprise does not want the ISP to see unencrypted data. The CE/PE/P router architecture works perfectly well in keeping several differently encrypted networks running over the same facilities; the CE routers only see one VPN, the PE are aware of multiple VPNs and may participate in IPSec, and the P routers just carry IP packets between the PE and P routers.

I believe there are enough authoritative sources that use CE/PE/P, without becoming confused about business relationships, that this really should remain in the article. The IETF is a bit wider in scope than the VPN Consortium. No one at NANOG became confused, nor did any of the technical reviewers of my book on enterprise WANs. Howard C. Berkowitz 20:30, 2 August 2008 (CDT)

To me, the quoted RFC definition "VPN is simply defined as the 'emulation of a private Wide Area Network (WAN) facility using IP facilities' (including the public Internet, or private IP backbones)." is much better — both clearer and more general and therefore more accurate — than either the current article lede or Virtual_private_network/Definition. Sandy Harris 02:13, 13 March 2010 (UTC)

Sure; we can go with that. Howard C. Berkowitz 02:15, 13 March 2010 (UTC)

Quick overview

My quick assessment is this article is detailed, but most readers won't get it. It needs diagrams, simpler explanations building to more complex ones. I think this article is one where secondary sources would be helpful as additions, to form some kind of bridge, so that readers can get a sense of what the whole vpn idea is about. But I haven't read this article in depth (although it looks intimdating.) If my help is needed here, let me know.--Thomas Wright Sulcer 18:09, 12 March 2010 (UTC)