Design of a Virtual Private Network

1,427 views

Published on

I did this as a semester project for the course Engineering of Packet Switched Networks.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,427
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
39
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Design of a Virtual Private Network

  1. 1. PROJECT PRESENTATION FOR CE/CS 6345 ENGINEERING OF PACKET SWITCHED NETWORKS SUBMITTED BY SHUBHAYU ROY. Design of a VPN The University Of Texas At Dallas. Richardson Texas .
  2. 2. The Problem Statement <ul><li>Design a VPN </li></ul><ul><li>What is a VPN ? </li></ul><ul><li>VPN or Virtual Private Network, functionally is equivalent to a Local Area Network. </li></ul><ul><li>But unlike a LAN the hosts in a VPN are not connected locally on the same physical network (via a switch). </li></ul><ul><li>Instead they are scattered at possibly different locations and sites over the Internet. </li></ul><ul><li>Hence the LAN topology is a simulated rather than being actual. Hence Virtual Private Network . </li></ul>
  3. 3. The Problem Statement <ul><li>Design a VPN </li></ul>
  4. 4. The Problem Statement <ul><li>Design a VPN </li></ul><ul><li>Now that we have an idea of what a VPN is </li></ul><ul><li>we must delve into how to build one. </li></ul>
  5. 5. The Problem Statement <ul><li>Design a VPN : Objectives </li></ul><ul><li>Providing a VPN service means: </li></ul><ul><ul><li>Any application on a host of a VPN should be able to access the VPN. </li></ul></ul><ul><ul><li>This means that the OS once it receives the packet from the application should be able to forward it similar to other LAN destinations. </li></ul></ul><ul><ul><li>Forward the packet to the corresponding Network Interface( similar to an actual network interface for wire transmission) </li></ul></ul><ul><ul><li>Any incoming packet from the VPN should reach the application via the OS when it arrives on the V Interface </li></ul></ul><ul><ul><li>The VPN packets must be available only to other hosts on the VPN </li></ul></ul><ul><ul><li>The packets must be capable of travelling over internet – preferably in the form of IP packets </li></ul></ul>
  6. 6. Solution <ul><li>Thus we see the need of a Virtual Interface. </li></ul><ul><li>Both VPN and IP (which is used to route VPN packets over the Internet) are Layer 2 technologies </li></ul><ul><li>We will need VPN packets to travel over internet to other VPN sites. </li></ul><ul><li>This can happen over IP communication </li></ul><ul><li>Hence we will need Encapsulation and Decapsulation of VPN packets to and from IP packets during transmission and reception. </li></ul>
  7. 7. Design
  8. 8. Existing Technologies <ul><li>There are many VPN clients available today. </li></ul><ul><li>They are capable of simulating IP communications over a LAN </li></ul><ul><li>They are however not many that provide generic support for the use of any network layer protocols, not specifically IP </li></ul><ul><li>Apple Talk, Novell IPX, experimental protocols </li></ul><ul><li>Our goal : include support for generic network layer protocols </li></ul>
  9. 9. Innovation <ul><li>In order to allow generic network layer protocol to run on the Virtual Network, we need to free the users of the VLAN from sticking to any specific packet format </li></ul><ul><li>In order for Virtual LAN to function, the VPN client program on the clients needs </li></ul><ul><ul><li>The virtual network address of the destination(provided by the program) </li></ul></ul><ul><ul><li>The virtual network address of the source (is known to VPN client program) </li></ul></ul>
  10. 10. Innovation <ul><li>So how does the VPN client program know where the packet at hand is headed?? </li></ul><ul><li>The VPN client program accepts as command line inputs the location and length in bits of the destID field in the otherwise unintelligible header. Smart. </li></ul><ul><li>It extract the destID thus. The packet public-key-encrypted using destination’s public key. (keys are either stored or exchanged) </li></ul><ul><li>Regardless of where the packet is headed on the VLAN the encapsulated IP datagram is always addressed to the central VPN server’s public address </li></ul><ul><li>However a Shim header is added for the server to understand. It contains: </li></ul><ul><ul><li>Client VPNID </li></ul></ul><ul><ul><li>Destination VPNID </li></ul></ul>
  11. 11. Innovation <ul><li>When VPN central server receives the IP datagram it decapsulates it to find a VPN datagram = Shim header + encrypted VPN packet. </li></ul><ul><li>Now what?? </li></ul><ul><li>The Server queries its database, with the destination VPNID(from shim header), and uses it to retrieve destination hosts public IP and port address. </li></ul><ul><li>Uses this to send packet to the destination </li></ul><ul><li>It also sends this info back to sending VPN program the triplet <destVPNID, publicIP,port for destVPN client program> </li></ul><ul><li>The sender stores these details for subsequent sendings to that host, in a cache DS. Flushes it regularly. </li></ul>
  12. 12. Model Packet from VLAN sender host encapsulated in IP packet . IP destination is initially that of central server The server queries the database to get the public IP and port of VPN destination host The encapsulated packet arrives at destination host. This packet is decapsulated to get the VPN packet which is then written by VPN client program to the TUN interface IP datagram to dest vpn host sent directly to VPN destinatin Destination host infor for caching
  13. 13. Security <ul><li>Public key security </li></ul><ul><li>Augment Central database triplets into Quadruplets </li></ul><ul><li>Extra field is to store the public key of that host </li></ul><ul><li>VPN program encrypts the app data while sending, after extracting destination VPNID </li></ul>
  14. 14. Questions? Send them in at [email_address] will be happy to respond in 24 hrs.
  15. 15. Thank you!

×