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)