Virtual Private Network (VPN)
1
Motivation
Your offshore software firm got an outsourcing project from Google. You can now access Google’s code repository, we can VNC into remote desktops of Google and you sometimes do some testing and code deploying in those remote boxes. Even more so, you are allowed to work from your home. However, Google has a very fast, efficient and secure communication mechanism internally. Internally all the PCs are used by authenticated google employees. Now that your company and you want to work with them from outside, Google needs a way to make sure that communication with you is reliable and secure. Google wants to bring your company’s LAN and your personal home machine to be logically inside their LAN. Hence, there arises the need for Virtual Private Network. VPN is the overlay mechanism to get you inside their private network.
2
Classification
Depending on the usage of VPN, we can broadly classify it into 2 groups: Site to Site VPN (when your LANs or sites are inter-connected with your other branches or your other partner sites) and Remote Access VPN (e.g. an employee connecting from remote network location to his office’s private network).
Depending on the network layers there are variations like L2VPN (“allows for the coexistence of multiple LAN broadcast domains, interconnected via trunks using the IEEE 802.1Q trunking protocol” [1]), L3VPN (An L3VPN interconnects sets of hosts and routers based on Layer 3 addresses [2]) etc. Again, L3VPN mainly has two types PPVPN (the network providers join together to connect separate customer sites) and CPVPN (the network providers do not know that underlying traffic is using VPN technology only the customers do). This division of customer and provider stems from data security. This happens when you do not trust your provider for your security and you build firewall and obfuscate data so that provider only thinks you are delivering IP packets for it to transport. Most of the time customers hire providers to deploy firewalls or edge WAN routers.
3
IP Based Virtual
Private Networks from RFC 2764
RFC 2764 gives a general framework for VPN across IP backbone. Because of numerous implementation of such vpn system, this RFC specifies the standard requirements. As vpn is a network transport protocol, it has common requirements that of other transport protocols. Generally, VPN has following requirements:
1. Opaque Packet Transport
2. Data Security
3. Quality of Service Guarantees
4. Tunneling mechanisms
But we focus on the most important one i.e. tunneling mechanism.
3.1 Tunneling mechanism
Most of the time, tunneling is used to form private networks. A tunnel makes an overlay link from end to end. This overlay channel can be over any network stack or layer. For IP overlay but for the end-to-end IP nodes traffic is not understandable by the underlying IP backbone and it forms a point-to-point link [3]. Actually, tunneling places the entire packet into another packet that the router and the end-points understand. IPSec, PPTP, L2TP etc are such protocols to encapsulate packets.
Tunnels are overlaid mainly over data link layer (packets are forwarded using MAC layer address) or IP layer (packets are forwarded using IP address).
RFC 2764[3] gives pointers to some existing tunneling mechanisms and describes the general requirements for tunneling. It is important to know the requirement to understand the tunneling mechanism. The requirements are as follows:
1.
Multiplexing: Multiplexing gives each tunnel a unique id and ensures
which tunnel the packet should be forwarded. There is a globally unique
identifier for vpn namely, VPN-ID. Because of multiplexing R3 is able to
forward to R1, R2, R4 and R5.
|
2. Signaling Protocol: Signaling establishes end-to-end tunnel requirement. With signaling protocol the peers negotiate tunnel attributes like VPN-ID, multiplexing, IP etc.
3. Data Security: Although encryption of data and authentication is a customer requirement, but here the main issue is to forward and route data correctly. “Packets on one VPN cannot be misrouted to a tunnel on a second VPN since those tunnels are not visible to the forwarding table of the first VPN.”[3]
4. Multiprotocol Transport: Endpoints much have a common tunneling protocol which supports other transport protocol in the network.
5. Frame Sequencing: This serves the same purpose to as in TCP to accomplish in order delivery of packets and to safeguard replay attack.
6. Tunnel Maintenance: This has to do with maintaining connection setup, release, failure, restart etc. There is timer, ICMP ping, periodic check mechanism to learn whether a vpn is up or down.
7. Large Maximum Transmission Unit (MTU): VPN MTUs are broken down into fragments because of the underlying link to link or hop to hop MTU sizes. So the vpn endpoints have way to reassemble the fragmented ones.
8. Minimization of Tunnel Overhead
9. Flow and Congestion Control: This issue is exactly same as TCP’s flow and congestion control but naturally it is complex. Although tunnels may be overlaid over data link or network layer, its end-to-end nature introduced such control options. Already, there are critics and many applications that do not use TCP as a transport because of its flow and congestion control.
10. QoS and Traffic Management
4
Mobile VPN from
[4] refers to an IETF draft on Tunnel Establishment Protocol submitted my Mobile IP Working Group.
Here the tunnel endpoints are known as Downstream Agent and Home Agent. Downstream agens is the mobile’s nearest tunnel agent. The mobile registers with it so that it can bind the mobile address and agen’t IP address. The home agent is the tunnel end point that connects to the user’s desired site.
Reference:
[1] http://en.wikipedia.org/wiki/Vpn
[2] http://www.ietf.org/rfc/rfc4026.txt
[3] http://rfc-editor.org/rfc/rfc2764.txt
[4] http://www.ietf.org/proceedings/98aug/I-D/draft-ietf-mobileip-calhoun-tep-01.txt