Virtual private network: Difference between revisions
imported>Sandy Harris (change order & some heading levels) |
imported>Howard C. Berkowitz No edit summary |
||
| Line 13: | Line 13: | ||
| url = http://www.ietf.org/rfc/rfc2764.txt | | url = http://www.ietf.org/rfc/rfc2764.txt | ||
}}</ref> | }}</ref> | ||
==Motivations for VPNs== | |||
Before the term VPN came into general use, other terminology was used. Some authors discourage the terms, but others find they are a valuable complement to the more technical VPN terminology, as they emphasize business relationships. | |||
The most basic motivation to have a VPN is financial: if the customer does not have to build a private network but can map it onto a commodity IP service, both the capital and operational costs drop. Small users, who might not be able to fund highly skilled networking personnel, can outsource that cost. Indeed, [[cloud computing]] technology is a superset of VPNs, which outsources servers as well as the network. | |||
It is a wise provider that arms its sales personnel with a set of basic questions to determine the customer requirement. The customer usually can articulate a set of requirements:<ref name=NANOG-wantVPN>{{citation | |||
| url = http://www.nanog.org/meetings/nanog16/presentations/vpn.pdf | |||
| title = So Your Customer Wants a VPN From You | |||
| author = Berkowitz, H. | |||
| publisher = North American Network Operators Group | |||
| conference = NANOG 16, Eugene, Oregon | |||
| date = May 23-25, 1999}}</ref> | |||
*Availability & Performance | |||
*Security | |||
*Compatibility with existing networks and servers | |||
*Network management approach | |||
*Budget | |||
Providers also speak informally of "clue factor", or the knowledge level of the customer. Some VPN technologies are too complex for customers, or, indeed, service providers. For example, it has been easier for many traditional telephone companies to use "layer 2 VPN" technology to emulate existing Frame Relay or dedicated line services, rather than train technicians in [[routing]]. | |||
If all the sites are under the control of a single network administration authority, such as an enterprise, the VPN is called an '''[[intranet]]'''. If the sites are under the control of multiple administrators that have agreed to technical and operational policies, the VPN is called an '''[[extranet]]'''. | |||
The global [[Internet]] is under the control of multiple administrators that agree to exchange reachability to a set of addresses under the authority of the [[Internet Assigned Numbers Authority]] (IANA), using the [[Border Gateway Protocol]]. A number of large SPs are treating their customers' public Internet connectivity as "just another VPN", yet one that is totally isolated from the intranets and extranets. Modern VPN technology lets the same addresses appear, without conflict, in multiple VPNs. | |||
==Technical framework== | |||
[[Image:Basic AS Connectivity.png|left|100px|thumb|General Internet connectivity onto which VPNs will be overlaid. Note that while all nodes interconnect, they are not necessarily adjacent]] | [[Image:Basic AS Connectivity.png|left|100px|thumb|General Internet connectivity onto which VPNs will be overlaid. Note that while all nodes interconnect, they are not necessarily adjacent]] | ||
In almost all cases | In almost all cases a VPN is an [[overlay network]] onto a lower-level connectivity network, such as the Internet, a non-public set of IP nodes over a private routed network, or IP over on-demand services such as dialup. | ||
[[Image:Overlay networks.png|right|150px|thumb|Two VPNs and a set of sites. VPN A is 1-6-2-4 and VPN B is 1-5-3]] | [[Image:Overlay networks.png|right|150px|thumb|Two VPNs and a set of sites. VPN A is 1-6-2-4 and VPN B is 1-5-3]] | ||
== | ===Implementation architecture=== | ||
Customer organizations may have a network support group that runs | Customer organizations may have a network support group that runs a backbone, through which multiple, administratively isolated, VPNs can run. For example, an enterprise with multiple physical sites, connected by [[satellite]] links, might have separate VPNs for finance, manufacturing, research, and human resources. When a backbone is administered in this manner, the VPNs are called '''customer-provisioned VPNs (CPVPN)'''. | ||
Alternatively, the enterprise(s) can contract with a SP to operate the VPNs. The customer needs to tell the SP how many isolated VPNs are needed, the address spaces that each will use, and the [[quality of service]], [[availability]], and [[bandwidth]] that will be required. In this case, if the customer has no involvement in the SP backbone, the VPNs are called '''provider-provisioned VPNs (PPVPN)s'''.<ref name=rfc4026>{{citation | Alternatively, the enterprise(s) can contract with a SP to operate the VPNs. The customer needs to tell the SP how many isolated VPNs are needed, the address spaces that each will use, and the [[quality of service]], [[availability]], and [[bandwidth]] that will be required. In this case, if the customer has no involvement in the SP backbone, the VPNs are called '''provider-provisioned VPNs (PPVPN)s'''.<ref name=rfc4026>{{citation | ||
| Line 29: | Line 54: | ||
| publisher = Internet Engineering Task Force | | publisher = Internet Engineering Task Force | ||
| url = http://www.ietf.org/rfc/rfc4026.txt | | url = http://www.ietf.org/rfc/rfc4026.txt | ||
}}</ref> | }}</ref> | ||
In PPVPNs, the '''customer''' sites interconnect to a '''backbone''' is operated by a '''service provider''', who provides VPN service to the customers. A customer may be a single enterprise, a set of enterprises, an [[Internet Service Provider]] (ISP), an [[Application Service Provider]] (ASP), another SP that offers the same kind of VPN service to its own customers (i.e., a VPN "wholesaler"), etc. | In PPVPNs, the '''customer''' sites interconnect to a '''backbone''' is operated by a '''service provider''', who provides VPN service to the customers. A customer may be a single enterprise, a set of enterprises, an [[Internet Service Provider]] (ISP), an [[Application Service Provider]] (ASP), another SP that offers the same kind of VPN service to its own customers (i.e., a VPN "wholesaler"), etc. | ||
| Line 50: | Line 67: | ||
Initially, think of the sites speaking to the backbone through some mutually agreed [[protocol (computer)|protocol]]; the concept of a VPN works with a wide variety of protocols, as long as they are mutually agreed among the sites and compatible with the backbone infrastructure. The backbone providing connectivity is typically overlaid onto some physical or logical infrastructure, so that the "provider backbone" can contain multiple VPNs. Another way to phrase this relationship is that the VPNs are '''tunneled''' through the provider backbone. | Initially, think of the sites speaking to the backbone through some mutually agreed [[protocol (computer)|protocol]]; the concept of a VPN works with a wide variety of protocols, as long as they are mutually agreed among the sites and compatible with the backbone infrastructure. The backbone providing connectivity is typically overlaid onto some physical or logical infrastructure, so that the "provider backbone" can contain multiple VPNs. Another way to phrase this relationship is that the VPNs are '''tunneled''' through the provider backbone. | ||
Sites connect to the "(inter-site) backbone" through '''customer edge (CE)''' devices or functions. The CE need not be a | Sites connect to the "(inter-site) backbone" through '''customer edge (CE)''' devices or functions. The CE need not be a physical device. A CE may be aware of multiple VPNs. | ||
There are many situations where a given enterprise, or set of enterprises forming an extranet, may use a combination of CPVPNs and PPVPNs. | |||
===Customer provisioning=== | ===Customer provisioning=== | ||
[[Image:CPVPN.png|thumb|left|250px|Two customer-provided VPNs]] | [[Image:CPVPN.png|thumb|left|250px|Two customer-provided VPNs]] | ||
| Line 98: | Line 117: | ||
| url = http://www.ietf.org/rfc/rfc4577.txt | | url = http://www.ietf.org/rfc/rfc4577.txt | ||
}}</ref> | }}</ref> | ||
==References== | ==References== | ||
{{reflist|2}} | {{reflist|2}} | ||
Revision as of 21:55, 13 March 2010
- See also: Tunneling protocol
- See also: Cloud computing
A virtual private network (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..." [1]
Motivations for VPNs
Before the term VPN came into general use, other terminology was used. Some authors discourage the terms, but others find they are a valuable complement to the more technical VPN terminology, as they emphasize business relationships.
The most basic motivation to have a VPN is financial: if the customer does not have to build a private network but can map it onto a commodity IP service, both the capital and operational costs drop. Small users, who might not be able to fund highly skilled networking personnel, can outsource that cost. Indeed, cloud computing technology is a superset of VPNs, which outsources servers as well as the network.
It is a wise provider that arms its sales personnel with a set of basic questions to determine the customer requirement. The customer usually can articulate a set of requirements:[2]
- Availability & Performance
- Security
- Compatibility with existing networks and servers
- Network management approach
- Budget
Providers also speak informally of "clue factor", or the knowledge level of the customer. Some VPN technologies are too complex for customers, or, indeed, service providers. For example, it has been easier for many traditional telephone companies to use "layer 2 VPN" technology to emulate existing Frame Relay or dedicated line services, rather than train technicians in routing.
If all the sites are under the control of a single network administration authority, such as an enterprise, the VPN is called an intranet. If the sites are under the control of multiple administrators that have agreed to technical and operational policies, the VPN is called an extranet.
The global Internet is under the control of multiple administrators that agree to exchange reachability to a set of addresses under the authority of the Internet Assigned Numbers Authority (IANA), using the Border Gateway Protocol. A number of large SPs are treating their customers' public Internet connectivity as "just another VPN", yet one that is totally isolated from the intranets and extranets. Modern VPN technology lets the same addresses appear, without conflict, in multiple VPNs.
Technical framework
In almost all cases a VPN is an overlay network onto a lower-level connectivity network, such as the Internet, a non-public set of IP nodes over a private routed network, or IP over on-demand services such as dialup.
Implementation architecture
Customer organizations may have a network support group that runs a backbone, through which multiple, administratively isolated, VPNs can run. For example, an enterprise with multiple physical sites, connected by satellite links, might have separate VPNs for finance, manufacturing, research, and human resources. When a backbone is administered in this manner, the VPNs are called customer-provisioned VPNs (CPVPN).
Alternatively, the enterprise(s) can contract with a SP to operate the VPNs. The customer needs to tell the SP how many isolated VPNs are needed, the address spaces that each will use, and the quality of service, availability, and bandwidth that will be required. In this case, if the customer has no involvement in the SP backbone, the VPNs are called provider-provisioned VPNs (PPVPN)s.[3]
In PPVPNs, the customer sites interconnect to a backbone is operated by a service provider, who provides VPN service to the customers. A customer may be a single enterprise, a set of enterprises, an Internet Service Provider (ISP), an Application Service Provider (ASP), another SP that offers the same kind of VPN service to its own customers (i.e., a VPN "wholesaler"), etc. [4]
Initially, think of the sites speaking to the backbone through some mutually agreed protocol; the concept of a VPN works with a wide variety of protocols, as long as they are mutually agreed among the sites and compatible with the backbone infrastructure. The backbone providing connectivity is typically overlaid onto some physical or logical infrastructure, so that the "provider backbone" can contain multiple VPNs. Another way to phrase this relationship is that the VPNs are tunneled through the provider backbone.
Sites connect to the "(inter-site) backbone" through customer edge (CE) devices or functions. The CE need not be a physical device. A CE may be aware of multiple VPNs.
There are many situations where a given enterprise, or set of enterprises forming an extranet, may use a combination of CPVPNs and PPVPNs.
Customer provisioning
In a customer-provided VPN, the customer manages connectivity among the CE. It is possible and common to have CPVPNs tunnel among customer sites using a secure tunneling protocol, such as IPSec, over physical connections to Internet Service Providers. The ISP, in such cases, will be completely unaware of the VPNs.
Provider provisioning
In a provider-provisioned VPN, the CE provide reachability information to provider edge (PE) devices or functions that are aware of both the VPN, and the provider backbone onto which the VPNs are mapped. Again, a PE need not be a physical device. The PEs are aware of the VPNs, but also of the interconnection of PEs, which is hidden from the customers.
Internal to the provider backbone may be provider (P) devices or functions that maintain connectivity in the provider backbone, but are themselves unaware of the VPNs.
Connectivity to the CE and PE
While the first VPNs used Internet Protocol version 4 (IPv4) for connectivity to the CE if the CE was an onsite physical device operated by the SP, or from the CE to the PE if the CE belongs to the customer, the VPN is not limited to running as a routed network. In a given environment, there may be:
- Routed (OSI Layer 3) VPNs using IPv4 or Internet Protocol version 6 (IPv6). IPv4 address space is becoming scarce, so a very practical application may be to run IPv4 VPNs over an IPv6 backbone; only CEs and PEs would need to support IPv6.
- Layer 2 VPNs (L2VPN), which present frame relay or Asynchronous Transfer Mode (ATM) interfaces to the customer equipment.[5] This is very useful to keep supporting old equipment that only has FR or ATM interfaces. "Layer 2.5" VPNs can present Multi-Protocol Label Switching (MPLS) interfaces to customer-owned equipment that understands that protocol; even commercial FR and ATM services frequently run over MPLS internal to the SP backbone. It is also possible for the VPN to run a local area network protocol such as IEEE 802.3 or a virtual LAN protocol such as IEEE 802.1Q.
- Layer 1 VPNs, where the VPN interface appears as an 802.3 or serial communications interface that accepts bit streams.[6]
Some L2 offerings are called virtual private LAN service, while other L1 offerings are called virtual private line service, both having the abbreviation VPLS. Using L2VPN and L1VPN is much less likely to lead to confusion.
L2VPNs and L1VPNs usually need a routing protocol to pass VPN administration information, although there are provider-provisioned autodiscovery mechanisms that will isolate the customer from this requirement.
Communicating policies and reachability between customer and provider
Depending on the type of VPN in use, the customer may run a routing protocol internal to the customer sites, of which the SP need not be aware.
If the customer needs to tell the PE what VPNs exist, what address spaces each support, and even if there are restrictions on connectivity within a single VPN, then this needs to be manually configured, which is maintenance-intensive, or the information can be sent through extensions to a routing protocol such as the Border Gateway Protocol (BGP)[4] or Open Shortest Path First (OSPF) [5]
References
- ↑ B. Gleeson, A. Lin, J. Heinanen, G. Armitage & A. Malis (February 2000), A Framework for IP Based Virtual Private Networks, Internet Engineering Task Force, RFC2764
- ↑ Berkowitz, H. (May 23-25, 1999), So Your Customer Wants a VPN From You, North American Network Operators Group
- ↑ Andersson L. and Madsen T. (March 2005), Provider Provisioned Virtual Private Network (VPN) Terminology, Internet Engineering Task Force, RFC4026
- ↑ 4.0 4.1 Rosen, E. and Rekhter, Y. (February 2006), BGP/MPLS IP Virtual Private Networks (VPNs), Internet Engineering Task Force, RFC4364
- ↑ 5.0 5.1 Rosen E. and Andersson L., ed. (September 2006), Framework for Layer 2 Virtual Private Networks (L2VPNs), Internet Engineering Task Force, RFC4664 Cite error: Invalid
<ref>tag; name "rfc4577" defined multiple times with different content - ↑ Takeda, T., ed. (September 2006), Applicability Statement for Layer 1 Virtual Private Network (L1VPN) Basic Mode, Internet Engineering Task Force, RFC5253