Faculteit Ingenieurswetenschappen Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. P. LAGASSE
Automatische VPN-tunneling tussen OSGi-gateways door Bas BOONE Jelle NELIS
Promotor: prof. dr. ir. F. GIELEN Co-promotor: prof. dr. ir. F. DE TURCK Scriptiebegeleiders: R. HENS en J. HOLLEZ
Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen
Academiejaar 2005–2006
Faculteit Ingenieurswetenschappen Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. P. LAGASSE
Automatische VPN-tunneling tussen OSGi-gateways door Bas BOONE Jelle NELIS
Promotor: prof. dr. ir. F. GIELEN Co-promotor: prof. dr. ir. F. DE TURCK Scriptiebegeleiders: R. HENS en J. HOLLEZ
Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen
Academiejaar 2005–2006
Dankwoord Graag zouden wij iedereen willen bedanken die heeft bijgedragen tot de verwezenlijking van dit eindwerk. Op de eerste plaats bedanken wij prof. dr. ir. F. Gielen en prof. dr. ir. F. De Turck. Speciale dank gaat uit naar onze thesisbegeleiders Raf Hens en Jan Hollez voor de geboden ondersteuning, inzichtvol commentaar en snelle reactie op al onze vragen. Verder willen we Nico Goeminne danken voor de gedane suggesties en Gudrun Evertsz-Montenegro voor het nalezen van de Engelstalige extended abstract.
Bas Boone en Jelle Nelis, juni 2006
Toelating tot bruikleen “De auteurs geven de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopi¨eren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie.”
Bas Boone en Jelle Nelis, juni 2006
Automatische VPN-tunneling tussen OSGi-gateways door Bas BOONE Jelle NELIS Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen Academiejaar 2005–2006 Promotor: prof. dr. ir. F. GIELEN Co-Promotor: prof. dr. ir. F. DE TURCK Scriptiebegeleiders: R. HENS en J. HOLLEZ Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. P. LAGASSE
Samenvatting In deze thesis wordt een systeem besproken dat toelaat een site-to-site VPN op te zetten tussen twee netwerken die met het internet verbonden zijn via een OSGi-gateway. Dit gebeurt op een voor de gebruiker transparante en gebruiksvriendelijke manier. Allereerst wordt er een specificatie opgesteld over wat er verwacht wordt van het systeem en wordt de architectuur voorgesteld. Vervolgens worden een aantal VPN-technologie¨en worden besproken en vergeleken, alsook een aantal adresseringsstrategie¨en, die het mogelijk maken netwerken te verbinden die overlappende subnetwerken gebruiken. Wanneer beslist is van welke technologie¨en gebruik zal gemaakt worden, worden een aantal ontwerpbeslissingen toegelicht. Uit de testresultaten blijkt dat het systeem bij hoge bandbreedtes (100 Mbps) een significante negatieve impact heeft op de throughput, maar bij lagere bandbreedtes een zeer kleine impact heeft op throughput, vertraging en pakketverlies. Thuisgebruikers en zelfs kleine bedrijven maken gebruik van breedbandverbindingen waar de bandbreedtes (vooral qua upload) beperkt zijn. De negatieve effecten van het systeem op de eigenschappen van de verbinding zijn in deze gevallen miniem. Tot slot worden een aantal mogelijke uitbreidingen en mogelijkheden voor verder onderzoek besproken.
Trefwoorden OSGi, VPN, veiligheid
Automatic VPN tunneling between OSGi gateways Bas Boone, Jelle Nelis Supervisor(s): Frank Gielen, Filip De Turck Abstract— This article describes an architecture and implementation for automatic VPN tunneling between OSGi gateways, aiming for a userfriendly, transparent solution to set up a secure tunnel between home networks.
II. D ESIGN To address these problems, several technologies, which are described further in the following subsections, are used.
Keywords—VPN, OSGi
A. OpenVPN I. I NTRODUCTION
M
ANY home users have a small home network, which can be used to share files and printers, play games, etc. Since these networks are usually connected to the Internet, they would also like to be able to connect to devices on other networks. Of course, security is important: access to a network should be limited to trusted networks, and all network traffic should be safe from eavesdroppers. A similar situation exists for companies: they would like their employees on the road to have access to the company network, but only if this can be done in a secure way. Solutions addressing this problem are called Virtual Private Networks (VPN’s). These solutions exist in hardware or in software. For client-to-site connections (where clients need to be connected to a network), these solutions usually suffice, although they require some technical competence on the networkside. For site-to-site connections (where two or more networks need to be connected), additional problems can arise: the gateways could be performing Network Address Translation (NAT), the gateways could have dynamically assigned IP-addresses, and the networks could be using overlapping private subnets. This article describes a solution which solves these problems, so that an authenticated, confidential and integer site-tosite VPN can be set up by non-technical users. The system is completely transparent for the client, meaning that no additional software must be installed on the client (only on the gateways) and existing connections are not hindered. The target users for this system are home users, and small companies looking for an easy-to-set-up VPN solution which does not require a lot of technical knowhow.
OpenVPN is used to set up a secure tunnel between gateways. OpenVPN is an SSL-based VPN solution which works by installing a virtual network interface. All traffic sent to this virtual network interface will then be authenticated, encrypted, encapsulated in UDP-packets, and sent to the remote gateway. Since it is SSL-based, X.509 certifcates are used for authentication. B. Address translation If two networks use overlapping subnetworks, address translation is used to prevent conflicts. Traffic destined for the remote network has its source address changed to a non-conflicting address, and incoming traffic from the remote network has its destination address changed back to the correct address. This way, an overlay network is created for both participating networks. C. Negotiation between gateways To be able to detect situations where subnets of the participating networks overlap, a negotiation is performed before the actual VPN setup. During this negotiation, the gateways decide which overlay networks to use. The design uses a listener pattern, so that new items that need to be negotiated (i.e. encryption algorithm to be used) can easily be added. D. OSGi The system is implemented as a set of OSGi applications (called “OSGi bundles”). The OSGi Service Platform is a component-oriented computing environment for networked devices. It is used in residential gateways, but also in digital mobile phones and embedded appliances. The main benefit of using OSGi is the ability of doing remote management of the applications. This allows for easy deployment and life cycle management. E. Naming system
Fig. 1. An example of a case where two networks use overlapping subnetworks: both use 192.168.0.0/24, and both gateways perform NAT.
To address the problem of gateways with dynamically assigned IP-addresses, each gateway is given a unique name. This name corresponds with the name in the X.509 certificate mentioned in section II-A. Gateways register their IP-address with a Gateway Naming System Server (GNS-server). Users can set up a VPN-connection by specifying the name of the gateway they want to connect to. Gateway names are also used by the user to specify a list of trusted gateways that can set up a VPN connection with them.
This naming system is also used to name individual hosts, so they can be looked up by other hosts, even though address translation is in effect (therefore using the original IP-addresses would not work). Every host can specify its desired name; it will be suffixed with the gateway name. III. T EST RESULTS Throughput and delay were measured for two setups: one using high bandwidth links (100 Mbps), and one using lower bandwidth links (effectively employing a home broadband Internet connection). If the system was employed, throughput suffered in the high bandwidth situation, because encryption on the gateways was executed slower than the rate of arriving packets. In the lower bandwidth situation, throughput was only 3% lower, which corresponds with the OpenVPN header overhead. The increase in delay was in both cases negligable. IV. C ONCLUSION The described system offers a userfriendly, transparent system to set up a VPN between two (or more) networks. Security, address conflicts, and naming issues are handled by the system, and shielded from the end user. R EFERENCES [1] OpenVPN website, http://www.openvpn.net [2] OSGi Alliance, About the OSGi Service Platform, 2004
INHOUDSOPGAVE
i
Inhoudsopgave 1 Probleemsituering
1
1.1
Probleemschets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Doel van de thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3
Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2 Specificatie
4
2.1
Vereisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2
Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3 Architectuur 3.1
3.2
8
Module view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.1.1
Negotiator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.1.2
ConfigurationManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.1.3
AddressTranslation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.1.4
Policing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.1.5
VPNInterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.1.6
AutoVPNInterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.1.7
WebInterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.1.8
GNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3.1.9
GNSserver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
Deployment view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.2.1
Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.2.2
Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.2.3
Serverpark Service Provider . . . . . . . . . . . . . . . . . . . . . . . . . .
12
INHOUDSOPGAVE
4 Technologiestudie 4.1
4.2
4.3
ii
13
OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
4.1.1
Motivatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
4.1.2
Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
4.1.3
Architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
VPN-technologie¨en . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.2.1
Vereisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.2.2
IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
4.2.3
OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
4.2.4
PPTP, L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.2.5
Vergelijking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
Adresseringsstrategie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
4.3.1
Netwerken samenvoegen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
4.3.2
Adresvertaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
5 Ontwerp
40
5.1
Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
5.2
Negotiator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
5.2.1
Generiek onderhandelingsprotocol . . . . . . . . . . . . . . . . . . . . . .
41
5.2.2
Implementatie onderhandelingsprotocol . . . . . . . . . . . . . . . . . . .
43
5.3
ConfigurationManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
5.4
AddressTranslation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
5.4.1
AddressTranslationConfig . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
5.4.2
NegotiatorListener methodes . . . . . . . . . . . . . . . . . . . . . . . . .
50
VPNInterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
5.5.1
Bundle startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
5.5.2
VPNImpl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
5.6
AutoVPNInterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
5.7
WebInterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
5.8
GNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
5.8.1
Protocol GNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
5.8.2
Bundle startup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
GNSServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
5.5
5.9
INHOUDSOPGAVE
iii
5.9.1
BIND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
5.9.2
GNSServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
6 Tests en resultaten
62
6.1
Testopstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
6.2
Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
6.3
Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
6.4
Pakketverlies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
6.5
Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
7 Conclusie 7.1
71
Verder onderzoek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
7.1.1
DNS op de gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
7.1.2
Broadcasts over de tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
7.1.3
Hostnamen op het virtuele netwerk . . . . . . . . . . . . . . . . . . . . . .
73
7.1.4
Uitbreiding naar IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
INHOUDSOPGAVE
Lijst van gebruikte afkortingen 3DES Triple DES 3DESE Triple DESE 3IDEA Triple IDEA AES Advanced Encyption Standard AH Authentication Header API Application Programming Interface ARP Address Resolution Protocol BIND Berkeley Internet Name Daemon bps bits per second CA Certificate Authority CBC Cipher Block Chaining CCP Compression Control Protocol CHAP Challenge Handshake Authentication Protocol CIDR Classless Inter-Domain Routing CIFS Common Internet File System DES Data Encryption Standard DESE PPP DES Encryption DHCP Dynamic Host Configuration Protocol
iv
INHOUDSOPGAVE
DNS Domain Name System DNS-SD DNS Service Discovery ECP Encryption Control Protocol ESP Encapsulating Security Payload FCS Frame Check Sequence FTP File Transfer Protocol GNS Gateway Naming System GRE Generic Routing Encapsulation HDLC High-Level Data Link Control HMAC Hash Message Authentication Code HTTP HyperText Transfer Protocol HTTPS HTTP Secure IBM International Business Machines ICMP Internet Control Message Protocol IDEA International Data Encryption Algorithm IEEE Institute of Electrical & Electronics Engineers IETF Internet Engineering Task Force IKE Internet Key Exchange IP Internet Protocol IPCP Internet Protocol Control Protocol IPSec Internet Protocol Security IPX Internetworking Packet Exchange IPXCP Internetworking Packet Exchange Control Protocol
v
INHOUDSOPGAVE
ISAKMP Internet Security Association Key Management Protocol ISO International Organization for Standardization ISP Internet Service Provider IV Initialisation Vector J2EE Java 2 Enterprise Edition JVM Java Virtual Machine kbps kilobits per second L2TP Layer 2 Tunneling Protocol LAC L2TP Access Concentrator LAN Local Area Network LCP Link Control Protocol LEAP Lightweight Extensible Authentication Protocol LLC Logical Link Control LNS L2TP Network Server MAC Media Access Control Mbps Megabits per second MD5 Message Digest 5 Algorithm mDNS Multicast DNS MPPE Microsoft Point-to-Point Encryption MS-CHAP Microsoft Challenge Handshake Authentication Protocol MSS Maximum Segment Size MTU Maximum Transmission Unit NAS Network Access Server
vi
INHOUDSOPGAVE
NAT Network Address Translation NCP Network Control Protocols NetBIOS Network Basic Input/Output System NIC Network Interface Card OSGi Open Services Gateway initiative PAC PPTP Access Concentrator PAP Password Authentication Protocol PNS PPTP Network Server PPP Point-to-Point Protocol PPTP Point-to-Point Tunneling Protocol PRF Pseudo Random Function PSK Pre-Shared Key RC5 Rivest Cipher 5 RFC Request For Comments RSA Rivest, Shamir & Adleman (public key encryption technology) RTP Real-time Transport Protocol RTT Round Trip Time SA Security Association SHA Secure Hash Algorithm SLP Service Location Protocol SP Service Provider SPI Security Parameter Index SSL Secure Socket Layer
vii
INHOUDSOPGAVE
SuSE Software- und System-Entwicklung TCP Transmission Control Protocol TLS Transport Layer Security UDP User Datagram Protocol VPN Virtual Private Network WAN Wide Area Network
viii
PROBLEEMSITUERING
1
Hoofdstuk 1
Probleemsituering 1.1
Probleemschets
Vele thuisgebruikers beschikken reeds over een thuisnetwerk . Ze kunnen dit gebruiken om onder andere bestanden en printers te delen en spelletjes te spelen. Indien dit netwerk aangesloten is op het internet, zou het interessant zijn indien ook toestellen op netwerken van andere gebruikers kunnen bereikt worden. Hierbij treden echter een paar problemen op. Een eerste probleem is veiligheid: niet iedereen mag toegang hebben tot hun netwerk en de communicatie mag niet afgeluisterd kunnen worden door derden. Verdere moeilijkheden kunnen optreden indien beide gateways gebruik maken van NAT, zodat het niet mogelijk is toestellen op het andere netwerk te bereiken zonder speciale voorzorgen. Ook het feit dat gateways dynamische IP-adressen kunnen hebben, kan voor bijkomende uitdagingen zorgen. Ten slotte is er nog de mogelijkheid dat twee netwerken overlappende subnetwerken gebruiken. De meeste thuisgebruikers hebben echter niet de technische kennis om deze problemen op te lossen. Een gelijkaardig probleem zien we bij bedrijven. Bedrijven kijken almaar meer over de geografische grenzen heen en eisen steeds meer flexibiliteit van hun werknemers. Verschillende filialen van eenzelfde bedrijf (nationaal of internationaal) moeten op een eenvoudige en betrouwbare manier bedrijfsinformatie kunnen delen. Verder kan het handig zijn dat een leverancier bepaalde, geselecteerde informatie kan opvragen die zich binnen het bedrijfsnetwerk bevindt. Vroeger werd dit meestal opgelost door gebruik te maken van zogenaamde leased lines, wat een hoge kost met zich meebracht. Werknemers zouden het bedrijfsnetwerk ook vanop een andere locatie moeten kunnen gebruiken. Dit kan onder andere gebruikt worden om aan thuiswerk te doen, maar ook kunnen
1.2 Doel van de thesis
2
rondreizende werknemers van zodra ze over een internetverbinding beschikken dezelfde bedrijfsinformatie raadplegen op de meest verscheidene locaties. Klanten kunnen hierdoor bijvoorbeeld sneller op de hoogte gebracht worden van de specificaties van de producten en/of diensten die men aanbiedt, wat een voorsprong ten opzichte van de concurrentie betekent. E´en van de vereisten die opgelegd worden door vele bedrijven voor een dergelijk systeem is de vertrouwelijkheid van de doorgestuurde informatie. Men wil niet dat belangrijke, innovatieve informatie in handen komt van de concurrentie. De oplossing voor dit probleem is een Virtual Private Network (VPN). Deze technologie stelt een gebruiker in staat een veilige verbinding te cre¨eren over een onveilig netwerk. Er is een onderscheid tussen site-to-site VPN’s, waarbij twee (of meer) netwerken op een veilige manier kunnen communiceren, en client-to-site VPN’s, waarbij een enkele client logisch gezien deel wordt van een ander netwerk. Grote bedrijven zullen echter meestal gebruik maken van een hardware VPN-oplossing, omwille van de schaalbaarheid. Voor kleinere bedrijven is dit meestal een te dure optie maar ontbreekt tevens de technische kennis om een dergelijke oplossing op poten te zetten. Ook voor thuisgebruikers is dit geen optie. Naast de dure hardware-oplossingen zijn er ook veel software-oplossingen, maar deze vereisen (vooral voor site-to-site) te veel kennis.
1.2
Doel van de thesis
Het doel van deze thesis is een VPN-oplossing te cre¨eren, waarbij een absoluut minimum aan configuratie nodig is en waarbij geen technische kennis vereist is bij de gebruikers. Deze VPNoplossing moet in staat zijn twee netwerken te verbinden (site-to-site), zodat de communicatie tussen deze twee netwerken geauthenticeerd, confidentieel en integer is. Verder moet de VPNoplossing transparant zijn voor de gebruikers op beide netwerken: dit betekent dat er geen extra software moet ge¨ınstalleerd worden op de machines van de gebruikers en dat bestaande verbindingen geen hinder ondervinden wanneer een verbinding opgezet wordt. De VPN-oplossing moet ook in staat zijn client-to-site verbindingen op te zetten; dit kan dan uiteraard niet zonder extra software te installeren op de client. Er zijn in grote lijnen twee soorten gebruikers: thuisgebruikers, die hun thuisnetwerken willen verbinden en kleine bedrijven die op zoek zijn naar een softwarematige, eenvoudig in te stellen VPN-oplossing. Voor thuisgebruikers is de makkelijke configureerbaarheid de belangrijkste vereiste, terwijl
1.3 Outline
3
veiligheid van de opgestelde verbinding van secundair belang is. Bedrijven echter zullen bereid zijn iets meer te moeten configureren als dit de nodige veiligheid met zich meebrengt. De oplossing moet werken op een “intelligente gateway”. Zulke gateways zijn vergelijkbaar met set-top boxes voor bijvoorbeeld interactieve digitale televisie, met het verschil dat de gateways generiek zijn en hun functionaliteit softwarematig aan te passen is. Ze kunnen ook van op afstand beheerd kan worden, bijvoorbeeld door de Internet Service Provider (ISP). Deze kan het systeem dan als een service aanbieden aan zijn klanten.
1.3
Outline
Gebaseerd op de specificatie van het systeem aan de hand van use cases en scenariodiagrammen in hoofdstuk 2 wordt er in hoofdstuk 3 een architectuur voorgesteld. Vooraleer deze architectuur kan worden ge¨ımplementeerd, moeten de benodigde technologie¨en onderzocht worden. In hoofdstuk 4 worden de belangrijkste VPN-technologie¨en besproken en vergeleken. Verder wordt ook het probleem van de adresseringsstrategie onderzocht en wordt OSGi besproken. Na het besluit over de te gebruiken technologie¨en wordt in hoofdstuk 5 de concrete implementatie van het systeem beschreven. Hoofdstuk 6 beschrijft de testopstelling die we gebruikt hebben om het uiteindelijk systeem te testen en geeft de gedane tests en hun resultaten weer. Tot slot volgt hoofdstuk 7 waar een algemeen besluit wordt geformuleerd. Tevens worden hierin mogelijke verdere uitbreidingen en onderzoeksdomeinen voorgesteld.
SPECIFICATIE
4
Hoofdstuk 2
Specificatie In sectie 2.1 wordt in grote lijnen uitgelegd wat het systeem waar deze thesis over handelt, als functionaliteit moet bevatten en aan welke kwaliteitsvereisten het moet voldoen. In sectie 2.2 wordt aan de hand van use cases duidelijk gemaakt wat er verwacht wordt.
2.1
Vereisten
Verbinding De hoofdfunctionaliteit bestaat uit het opzetten, onderhouden en afsluiten van een verbinding tussen twee intelligente gateways. Gebruiksvriendelijkheid
Dit dient op een dusdanige manier te gebeuren dat er zo weinig
mogelijk technische kennis vereist is. Een computerleek moet in staat zijn een verbinding op te zetten en af te breken. Eventuele configuratie wordt afgewenteld op een netwerkbeheerder die verantwoordelijk is voor het thuisnetwerk of in het geval van bedrijven voor het netwerk van de vestiging. Veiligheid
Bijkomende vereisten worden opgelegd voor het soort verbinding dat gemaakt
wordt. Verkeer dat van het ene naar het andere netwerk wordt verstuurd mag niet kunnen gelezen of veranderd worden door derden. Ook moet ervoor gezorgd worden dat de andere gateway wordt geauthenticeerd vooraleer een verbinding wordt opgezet. Transparantie
Het opzetten en sluiten van een verbinding moet transparant zijn voor de
eindgebruiker (elke gebruiker in elk van de netwerken). Alle diensten die werkten voordat
2.2 Use cases
5
de verbinding werd opgezet, moeten blijven werken nadat deze is opgezet. Reeds gemaakte verbindingen mogen niet onderbroken worden. Makkelijke installatie
Het systeem moet makkelijk installeerbaar zijn.
Aanpasbaarheid en uitbreidbaarheid Het systeem moet erop voorzien zijn dat er zich veranderingen kunnen voordoen in de gebruikte technologie (het moet bijvoorbeeld mogelijk zijn met minimale inspanning te veranderen van gebruikte VPN-technologie). Verder moet het eenvoudig zijn om nieuwe features toe te voegen.
2.2
Use cases
Figuur 2.1 toont welke soorten gebruikers er bestaan en welke acties zij mogen ondernemen. We kunnen een onderscheid maken tussen drie soorten actoren. De Service Administrator is diegene die de dienst aanbiedt. Deze is verantwoordelijk voor het aanbieden van de dienst aan de verschillende eindgebruikers. Hiervoor moet hij informatie over de verschillende gateways die gebruik maken van deze dienst bijhouden. Verder zijn er de eindgebruikers waarbij er onderscheid gemaakt wordt tussen een gewone eindgebruiker en de netwerkbeheerder. De netwerkbeheerder staat in voor de configuratie van de gateway terwijl de gewone gebruiker een verbinding moet kunnen opzetten, afsluiten en natuurlijk gebruiken. Figuur 2.2 toont hoe de netwerkbeheerder de lokale gateway kan instellen. De gateway kan eventueel informatie vragen aan de Service Provider. Figuur 2.3 laat zien hoe een gewone eindgebruiker de verbinding kan starten en stoppen. Bij het starten van een verbinding wordt, na authenticatie van de remote gateway, onderhandeld over de parameters die gaan worden gebruikt. Hierbij kan het nodig zijn om de Service Provider te gebruiken, bijvoorbeeld om bijkomende informatie nodig voor de verbinding op te vragen.
2.2 Use cases
6
Figuur 2.1: Use Case Diagram
Figuur 2.2: Use Case: Configureren gateway door netwerkbeheerder
2.2 Use cases
7
Figuur 2.3: Use Case: Starten en stoppen verbinding tussen gateways
ARCHITECTUUR
8
Hoofdstuk 3
Architectuur
Figuur 3.1: Module view
3.1
Module view
Figuur 3.1 toont alle modules van het systeem en hoe ze zich onderling verhouden. De module ConfigurationManager wordt door elke module die configuratie wil opslaan, gebruikt. De modules worden elk apart besproken in de volgende secties.
3.1 Module view
3.1.1
9
Negotiator
Bij het opstellen van een verbinding tussen twee gateways zijn er verschillende zaken die veranderlijk zijn. Denk maar aan de mogelijkheden die beide gateways aanbieden, de gebruikte fysieke en te gebruiken virtuele IP-ranges. Natuurlijk is het onbegonnen werk om voor elke verbinding handmatig te moeten aangeven welke waarden de te gebruiken parameters aannemen. Hier vloeit de Negotiator uit voort. Alle modules in het systeem hebben de mogelijkheid om parameters die ze in de onderhandeling tussen de twee gateways willen betrekken, te registreren. Bij de onderhandeling van een verbinding worden de modules die zich geregistreerd hebben, geraadpleegd voor het nemen van een beslissing over hun respectievelijke parameters. Deze manier van werken heeft een aantal voordelen. Zo wordt de logica van de feitelijke onderhandeling en de specifieke problemen die men kan tegenkomen bij de onderhandeling van bepaalde parameters gescheiden. Het toevoegen van een extra parameter wordt dan slechts een kwestie van het registreren ervan bij de Negotiator, aan de Negotiator zelf dient niets veranderd te worden. In feite weerhoudt niets iemand ervan om deze Negotiator te gebruiken voor een totaal ander systeem waar een dergelijke onderhandeling bij te pas komt.
3.1.2
ConfigurationManager
De ConfigurationManager houdt twee verschillende soorten informatie bij, enerzijds wordt informatie bijgehouden die gelijk is voor het gehele systeem, zoals de lijst van vertrouwde gateways. Anderszijds wordt per verbinding de informatie die onderhandeld werd door de Negotiator opgeslagen. Dit heeft als voordeel dat een module die bepaalde informatie nodig heeft om in zijn functionaliteit te voorzien niet op de hoogte moet zijn welke module hiervoor verantwoordelijk is. Informatie specifiek aan een module die niet gebruikt wordt door andere modules op het systeem hoort niet thuis in de ConfigurationManager, maar dient door die specifieke module bijgehouden worden.
3.1.3
AddressTranslation
De module AddressTranslation bevat alle functionaliteit om te beslissen of adresvertaling nodig is voor een bepaalde verbinding en om deze adresvertaling in te stellen op de gateway. De module wordt geregistreerd bij de Negotiator, die de feitelijke onderhandeling afhandelt, terwijl de module AddressTranslation de beslissingen neemt over het al dan niet gebruiken van adresvertaling en de eventuele parameters van de adresvertaling.
3.1 Module view
3.1.4
10
Policing
De module Policing staat in voor de authorisatie van gebruikers binnen het virtuele netwerk.
3.1.5
VPNInterface
De module VPNInterface staat in voor het opstarten en controleren van een VPN-verbinding. Een andere verantwoordelijkheid is het instellen van de routering naar het netwerk waarnaar de VPN-verbinding is ingesteld. Deze functionaliteit is ondergebracht in een aparte module, zodat het eenvoudig is om van onderliggende VPN-technologie te veranderen: enkel deze module moet in dat geval aangepast worden.
3.1.6
AutoVPNInterface
Het opzetten en afbreken van een verbinding heeft verschillende gevolgen: er moeten een aantal interne objecten aangemaakt of verwijderd worden, de adresvertaling moet opgezet of afgebroken worden en de onderliggende VPN-oplossing moet logischerwijze aangesproken worden. Om ervoor te zorgen dat de gateway zich niet in een inconsistente staat bevindt (bijvoorbeeld: de VPN-verbinding is afgesloten maar de bijbehorende adresvertaling is niet ongedaan gemaakt), worden alle acties die nodig zijn om een verbinding op te zetten of af te breken in deze module gebundeld.
3.1.7
WebInterface
De enige module waarmee de eindgebruiker rechtstreeks in contact komt is de webinterface die aangeboden wordt door het systeem. Er wordt een onderscheid gemaakt tussen verschillende soorten gebruikers. Enerzijds zijn er de eindgebruikers die enkel gemachtigd zijn verbindingen aan te maken, af te sluiten en te gebruiken. Anderszijds zijn er de netwerkbeheerders die bovenop de acties die een eindgebruiker mag ondernemen, meer geavanceerde acties mag uitvoeren. Meer specifiek: de netwerkbeheerder kan de lokale configuratie van het systeem wijzigen. Dit kan bijvoorbeeld het aanpassen van een lijst van vertrouwde gateways of een lijst van gebruikers die toegang tot het netwerk krijgen, zijn
3.1.8
GNS
De module GNS staat in voor het registreren van afbeeldingen van namen op IP-adressen bij de GNS-server. Elke communicatie met de GNS-server is beveiligd (geauthenticeerd en
3.2 Deployment view
11
ge¨encrypteerd).
3.1.9
GNSserver
De module GNSserver bevindt zich op een server die beheerd wordt door de Service Provider. Hij houdt de afbeeldingen van namen op IP-adressen bij, die hij ontvangt van de GNS en verschaft een lookup-service voor deze namen. Zoals vermeld in sectie 3.1.8 is de communicatie tussen gateway en GNS-server beveiligd. Twee soorten relaties worden bijgehouden: enerzijds zijn er de relaties (gatewaynaam, IPadres gateway), anderzijds zijn er de relaties (clientnaam, virtueel IP-adres client).
3.2
Deployment view
Figuur 3.2 toont waar elke module zich fysiek bevindt. Enkel de modules die instaan voor de communicatie tussen verschillende nodes zijn in de figuur opgenomen, zo zullen op beide gateways behalve de modules op de figuur ook volgende modules aanwezig zijn: ConfigurationManager, AddressTranslation, Policing en AutoVPNInterface.
Figuur 3.2: Deployment view
3.2 Deployment view
3.2.1
12
Client
De eindgebruiker heeft enkel een standaardbrowser nodig om gebruik te kunnen maken van het systeem.
3.2.2
Gateways
De eindgebruiker surft naar de webinterface van zijn lokale gateway om het systeem te besturen. Op aanvraag van de gebruiker zal het systeem in actie treden. Hierbij komt de module GNS in werking en communiceert hierbij met de module GNSServer die zich bevindt in het serverpark van de Service Provider (SP). Communicatie tussen de lokale gateway en de gateway waarmee verbinding wordt gemaakt gebeurt tussen de modules Negotiator en VPNInterface op beide gateways.
3.2.3
Serverpark Service Provider
De Service Provider biedt de module GNSServer aan.
TECHNOLOGIESTUDIE
13
Hoofdstuk 4
Technologiestudie 4.1 4.1.1
OSGi Motivatie
Als platform voor de “intelligente gateway” waarop het systeem moet werken, werd gekozen voor het OSGi-platform. Dit platform is uitstekend geschikt voor “residential Internet gateways” en is reeds aanwezig op een aantal commerci¨ele gateways. Hierna wordt het OSGi-platform in meer detail besproken, waarbij de punten die het geschikt maken, worden aangestipt.
4.1.2
Overzicht
Het OSGi Service Platform is een specificatie voor een Java-gebaseerd applicatieframework voor genetwerkte devices. Het was oorspronkelijk ontworpen voor gebruik in “residential Internet gateways” met het oog op huisautomatie. Het wordt nu echter ook voor veel andere doeleinden gebruikt, waaronder telematica, smart phones en embedded toestellen. In deze thesis ligt de focus uiteraard op het originele aspect van “residential Internet gateways”. OSGi specifieert een framework voor softwarecomponenten, die men “bundles” noemt. Het formaat van deze componenten is vastgelegd en er is een API voor de deployment van de componenten, zodat de lifecycle ervan gecontroleerd kan worden. Dit maakt OSGi uitermate geschikt om aan remote deployment en remote management te doen. Componenten kunnen eenvoudig ge¨ınstalleerd, verwijderd en ge¨ updatet worden. Het systeem is service-geori¨enteerd: componenten kunnen dynamisch elkaars services ontdekken en gebruiken.
4.1 OSGi
4.1.3
14
Architectuur
Figuur 4.1: OSGi architectuur
De OSGi-specificaties beschrijven een aantal lagen, zoals voorgesteld in figuur 4.1. De lagen in het geel vormen samen het OSGi-framework. JVM Het OSGi-framework draait op een Java Virtuele Machine (JVM). Er werd gekozen voor JVM omdat het een open standaard is die beschikt over de nodige features zoals portabiliteit, veiligheid en betrouwbaarheid. Class loading Het uitvoerbare deel van bundles zijn Java klassen, georganiseerd in packages. In tegenstelling tot andere frameworks zoals J2EE, kunnen deze klassen gedeeld worden tussen bundles. Dit maakt de implementatie complexer, maar heeft als voordeel dat bundles libraries kunnen bevatten voor andere bundles, zodat de memory footprint kleiner kan gehouden worden. De afhankelijkheid die op deze manier tussen bundles ontstaat, wordt op de volgende manier opgelost: elke bundle specifieert welke packages hij exporteert en welke hij importeert (zie figuur 4.2). Exporteren van een package betekent dat alle andere bundles gebruik kunnen maken van deze package. Bundles kunnen slechts gestart worden indien alle packages die ze importeren aanwezig zijn in het framework. Life cycle management Een bundle is een Java Archive (JAR). OSGi specifieert een aantal headers die aanwezig moeten zijn in het Manifest-bestand van de JAR, waaronder de ge¨ımporteerde en ge¨exporteerde
4.1 OSGi
15
Figuur 4.2: Gedeelde klassen
packages. Nadat bundles ge¨ınstalleerd zijn, kunnen ze gestart en gestopt worden. Het installeren van bundles kan gebeuren vanuit een andere bundle. De initi¨ele bundles kunnen dan ge¨ınstalleerd worden dankzij een Initial Provisioning specificatie, of via commandolijn parameters wanneer het framework opgestart wordt. Vooraleer een ge¨ınstalleerde bundle gestart kan worden, moet hij eerst geresolved worden. Hierbij wordt gekeken of alle afhankelijkheden van de bundle (bijvoorbeeld ge¨ımporteerde packages) voldaan zijn. Om een bundle te starten, wordt gekeken naar de “Bundle-Activator” header in de Manifest van de bundle. Deze bevat de naam van een klasse die de BundleActivator-interface moet implementeren. Deze klasse implementeert start- en stop-methodes. Een bundle hoeft niet noodzakelijk een Bundle-Activator te bevatten: in dat geval kan de bundle niet gestart of gestopt worden en dient hij enkel om ge¨ımporteerd te worden door andere bundles. Bundles kunnen op elk moment verwijderd worden. De packages die de bundle exporteert, blijven dan wel beschikbaar voor bundles die ervan gebruik maken. Over het algemeen is het zo dat de packages waarvan een bundle afhankelijk is nooit gewijzigd worden als een bundle actief is. Als het nodig is, zal de bundle eerst gestopt worden en daarna opnieuw opgestart. Service Registry Het OSGi-platform is van nature zeer dynamisch: bundles kunnen op elk moment gestopt en gestart worden. De Service Registry is er om bundles te kunnen laten samenwerken in deze dynamische omgeving. Hiermee kunnen bundles:
4.2 VPN-technologie¨en
16
• objecten registreren bij de Service Registry; deze objecten worden services genoemd. Services worden geregistreerd met een interfacenaam en een aantal properties. • de Service Registry doorzoeken naar services op basis van bepaalde criteria. • notificaties ontvangen wanneer een bepaalde service verschijnt of verdwijnt. Veiligheid Veiligheid is een belangrijk probleem voor een platform dat in staat moet zijn applicaties uit te voeren van vele verschillende bronnen. Er zijn dan ook verschillende veiligheidsmechanismen ingebouwd in OSGi. Eerst is er de Java 2 Code Security. Deze is ingebouwd in de JVM en laat toe bepaalde resources te beschermen door middel van Permissions. Bestanden kunnen bijvoorbeeld beschermd worden met FilePermissions. Verder kunnen in Java ook access modifiers gebruikt worden in de code om toegang tot klassen of methodes af te schermen. OSGi voegt hier nog bescherming van packages aan toe: packages van een bundle die niet ge¨exporteerd worden, kunnen niet bereikt worden door andere bundles. Er kunnen ook Package Permissions ingesteld worden: hiermee kan de import en export van bepaalde packages beperkt worden tot een set van vertrouwde bundles. Tot slot is er de Service Permission, waarmee er kan voor gezorgd worden dat enkel de gewenste bundles bepaalde services kunnen aanbieden of gebruiken.
4.2
VPN-technologie¨ en
4.2.1
Vereisten
De vereisten voor de VPN-technologie voor deze thesis zijn de volgende. • Vertrouwelijkheid, authenticatie en integriteit moeten ondersteund worden. • Er moet een implementatie zijn die aanspreekbaar is vanuit Java, aangezien de oplossing moet draaien op een OSGi-gateway. • Er moet een implementatie zijn die installeerbaar is op een OSGi-gateway. Dit houdt in
4.2 VPN-technologie¨en
dat deze implementatie in userspace
17
1
uitgevoerd zou moeten worden.
• Er moet een implementatie beschikbaar zijn voor zoveel mogelijk platformen. • De oplossing moet werken samen met NAT, aangezien veel thuisnetwerken achter een gateway zitten die NAT uitvoert. • Het moet mogelijk zijn policies in te stellen om aan toegangscontrole te doen (dit is vooral interessant voor bedrijven).
4.2.2
IPSec
Overzicht IPSec is een uitbreiding van het IP-protocol om veiligheid aan te bieden voor IP-verkeer. Het was oorspronkelijk ontworpen voor de nieuwe IPv6 standaard en later aangepast om ook met IPv4 te werken. De IPSec-architectuur is gestandaardiseerd in RFC 4301 [3]. IPSec gebruikt twee protocollen (AH en ESP) om authenticatie, integriteit en vertrouwelijkheid van communicatie te verzekeren. Verder zijn er ook nog twee mogelijke modi: tunnelmode of transportmode. Bij tunnelmode wordt elk IP-pakket volledig ge¨encrypteerd en/of geauthenticeerd en ge¨encapsuleerd in een nieuw IP pakket. Bij transportmode wordt enkel de IP-data ge¨encrypteerd en/of geauthenticeerd en worden nieuwe headers toegevoegd aan het IP pakket; de oorspronkelijke headers van het IP-pakket blijven ongewijzigd. Dit wordt grafisch voorgesteld in figuur 4.3.
Figuur 4.3: Het verschil tussen tunnel- en transportmode
Integriteit van de communicatie wordt verzekerd door het gebruik van Hash Message Authentication Codes (HMAC). De HMAC van een pakket wordt berekend door de hash te berekenen 1
Userspace slaat op code die uitgevoerd wordt als een gewoon proces; kernelspace slaat op code die uitgevoerd
wordt in de kernel, bijvoorbeeld als driver of module.
4.2 VPN-technologie¨en
18
van een geheime sleutel geconcateneerd met de inhoud van het pakket. Voor de hash kan men gebruik maken van MD5 of SHA. Indien de ontvanger ook over de geheime sleutel beschikt, kan hij ook deze hash berekenen en controleren of het bericht gewijzigd is tijdens het transport. Vertrouwelijkheid wordt verzekerd door symmetrische encryptie. De IPSec standaard schrijft voor dat NULL en DES encryptie verplicht aanwezig moeten zijn, maar over het algemeen worden krachtigere algoritmes gebruikt. Een beveiligde verbinding wordt een Security Association (SA) genoemd. Een SA wordt gedefinieerd door een set van parameters: • bron- en bestemming-IP-adres van de resulterende IPSec header. Dit zijn met andere woorden de peers van de IPSec verbinding. • IPSec protocol: AH of ESP (indien beide samen gebruikt worden, moeten twee SA’s opgezet worden) • algoritme en geheime sleutel voor encryptie • Security Parameter Index (SPI). Een 32-bit getal dat de SA identificeert. Een SA is geldig voor een unidirectionele verbinding. Voor een full duplex verbinding zijn dus twee SA’s nodig. Deze SA’s kunnen manueel worden ingesteld. De gebruikers moeten dan zelf op een of andere manier een (statische) geheime sleutel kiezen. Dit noemt men vaak een pre-shared key (PSK). Maar er kan ook gebruik gemaakt worden van het Internet Key Exchange-protocol (IKE), dat een sleutel voorziet voor de SA. Dit protocol wordt beschreven in sectie 4.2.2. Werking AH – Authentication Header Het AH protocol zorgt voor integriteit van IP-pakketten. De header (die een veelvoud van 32 bits lang is) wordt grafisch weergegeven in figuur 4.4. • HMAC: een HMAC van de geheime sleutel, de data van het IP-pakket en de onveranderlijke delen van de IP-header (zoals bron- en bestemmingsadres). Moet een veelvoud van 32 bits lang zijn. • Next Header: specifieert het protocol van de volgende header. In tunnelmode is dit 4, voor IP; in transportmode met TCP-verkeer is dit 6, voor TCP.
4.2 VPN-technologie¨en
19
Figuur 4.4: Een authenticated header
• SPI: de SPI van de security association, zodat de ontvanger weet welke sleutel en algoritme hij moet gebruiken. • Sequence Number: dit 32-bit getal wordt mee opgenomen in de hash om replay attacks te voorkomen. ESP – Encapsulating Security Payload Het ESP protocol zorgt voor vertrouwelijkheid en (optioneel voor) integriteit. De structuur van een met ESP ge¨encapsuleerd pakket wordt grafisch weergegeven in figuur 4.5.
Figuur 4.5: Een ESP header
4.2 VPN-technologie¨en
20
• SPI: zoals bij AH. • Sequence Number: zoals bij AH. • Data: ge¨encrypteerde data. In transportmode is dit de data in het IP-pakket; in tunnelmode is dit het volledige IP-pakket. Indien het encryptie-algoritme dit vereist, kan dit veld ook een initialisatievector (IV) bevatten. • Padding Length: Aangezien IPSec block ciphers gebruikt, is het nodig om padding te voorzien indien de lengte van de data niet een veelvoud van de blokgrootte is. • Next Header: zoals bij AH. • HMAC (optioneel): een HMAC over de ESP header, data en trailer. IKE – Internet Key Exchange
Het IKE-protocol is ontworpen om het veilig opzetten van
een IPSec verbinding mogelijk te maken, zonder met pre-shared keys te werken: het zorgt voor authenticatie van de peers, sleuteluitwisseling en opzetten van de SA’s. Het IKE-protocol wordt over het algemeen ge¨ımplementeerd door een userspace programma en gebruikt UDP poort 500 voor de communicatie. Het protocol werkt in twee fasen. In de eerste fase worden de peers geauthenticeerd en wordt een Internet Security Association Key Management Protocol (ISAKMP) SA vastgelegd. De authenticatie kan gebeuren aan de hand van PSK’s, RSA sleutels en X.509-certificaten. In de tweede fase worden de parameters van de SA’s voor IPSec onderhandeld. Deze communicatie wordt beschermd met de ISAKMP SA. Normaal onderhandelen de twee peers slechts ´e´en ISAKMP SA; deze kan dan gebruikt worden om twee (of meer) unidirectionele IPSec SA’s te onderhandelen. NAT-Traversal
Standaard IPSec kan in transportmode niet gebruikt worden in combinatie
met Network Address Translation (NAT). Verschillende problemen duiken op: • AH kan niet gebruikt worden aangezien het bronadres van de verzonden IP-pakketten (die worden herschreven door NAT) deel uitmaakt van de HMAC. De HMAC is na NAT dus niet meer geldig. • ESP kan ook niet gebruikt worden, omdat NAT een poortnummer van het onderliggende protocol (TCP of UDP) gebruikt om onderscheid te maken tussen verschillende verbin-
4.2 VPN-technologie¨en
21
dingen. Aangezien ESP deze poortnummers encrypteert, kan een NAT-router onmogelijk onderscheid maken tussen verschillende verbindingen die ESP gebruiken. • Ook in tunnelmode kunnen er problemen optreden, aangezien het ge¨encapsuleerde IP-adres niet vertaald wordt. Verdere problemen worden beschreven in [1]. Een mogelijke oplossing voor ESP is om de ESP-pakketten te encapsuleren in UDP-pakketten. Hierdoor beschikt de NAT-router toch weer over een poortnummer en zal hij nu wel onderscheid kunnen maken tussen verschillende verbindingen. NAT-traversal wordt beschreven in [2].
4.2.3
OpenVPN
Overzicht OpenVPN is een relatief nieuwe VPN-oplossing, gebaseerd op SSL/TLS. Het ontstond als reactie op de complexiteit en steile leercurve van typische IPSec-oplossingen. In tegenstelling tot IPSec, waarin IKE wordt gebruikt om sleutels uit te wisselen, gebruikt men in OpenVPN SSL/TLS. Dit protocol was in eerste instantie ontworpen voor de applicatielaag, maar kan ook gebruikt worden voor andere doeleinden. De voordelen tegenover IKE zijn dat het protocol eenvoudiger is (waardoor te verwachten is dat er minder fouten optreden bij implementatie) en dat het zijn deugdelijkheid al ruim bewezen heeft dankzij het gebruik in het HTTPS-protocol. Verder is het hierdoor mogelijk OpenVPN volledig in userspace te implementeren, zodat porteren veel vereenvoudigd wordt (er zijn geen aanpassingen of uitbreidingen van de IP-stack nodig). Voor alle duidelijkheid: OpenVPN is een echte VPN, waarbij willekeurig IP-verkeer kan beveiligd worden. Er bestaan namelijk ook vele zogenaamde “SSL-VPN’s”, die in feite niets meer zijn dan een webinterface naar een bepaalde applicatie, over HTTPS. Aangezien er geen RFC of andere standaard bestaat voor het protocol dat gebruikt wordt door OpenVPN, beschrijven we hier de implementatie zelf. Werking SSL/TLS SSL is een protocol dat als doel heeft privacy en data-integriteit te verlenen tussen twee communicerende applicaties (oorspronkelijk client en server). Het protocol werd ontwikkeld door Netscape en SSL versie 3 is (met enige wijzigingen) hernoemd naar TLS en vastgelegd in RFC 2246 [5].
4.2 VPN-technologie¨en
22
Authenticatie in SSL/TLS gebeurt aan de hand van X.509-certificaten. In de meeste gevallen wordt enkel de server geauthenticeerd, maar de server kan ook een certificaat eisen van de client, zodat beide partijen geauthenticeerd kunnen worden. SSL/TLS moet gedragen worden door een betrouwbaar transport protocol. Dit is meestal TCP (bijvoorbeeld bij HTTPS). OpenVPN protocol
OpenVPN heeft twee authenticatie-modi:
• Static Key: maakt gebruik van een pre-shared static key. • TLS: maakt gebruik van SSL/TLS en certificaten voor authenticatie en key exchange. In “static key mode” wordt op voorhand een pre-shared sleutel gegenereerd en gebruikt door beide OpenVPN peers, voor de tunnel gestart wordt. Deze sleutel bevat 4 onafhankelijke sleutels: “HMAC send”, “HMAC receive”, “encrypt” en “decrypt”. Standaard worden deze sleutels door beide partijen gebruikt. In “TLS mode” wordt een TLS-sessie opgestart met bidirectionele authenticatie. Beide partijen moeten hierbij een certificaat hebben, ondertekend door een Certificate Authority (CA). Als de authenticatie slaagt, worden encryptie/decryptie en HMAC sleutels gegenereerd, waarbij beide partijen random materiaal leveren. In deze mode worden de sleutels niet bidirectioneel gebruikt; elke partij bezit dus een eigen “HMAC send”, “HMAC receive”, “encrypt” en “decrypt”-sleutel. Zodra elke partij zijn sleutels heeft, kan de tunnelwerking beginnen. Headerformaat
De communicatie tussen client en server verloopt via UDP. De server ont-
vangt standaard verbindingen op poort 1194 (deze poort is toegewezen voor OpenVPN-communicatie door IANA, zie [12]). De pakketten zien eruit als volgt: packet message type
key id
payload
• Packet message type: (5 bit) specifieert of het gaat om een controle-, ack-, of databoodschap. • Key-id: (3 bit) de key-id verwijst naar een reeds onderhandelde TLS-sessie.
4.2 VPN-technologie¨en
23
• Payload: kan bestaan uit een controle-, ack- of data-boodschap. Data-boodschappen bevatten de IP-pakketten die over de tunnel gestuurd worden, nadat ze ge¨encrypteerd en geauthenticeerd zijn; controle- en ack-boodschappen bevatten TLS-data. Indien OpenVPN in “static key mode” opereert, worden enkel data-boodschappen verstuurd; de velden “package message type” en “key-id” worden in dat geval ook weggelaten. Indien OpenVPN in TLS-mode opereert, moet ook een TLS-verbinding opgezet worden. De payload hiervan wordt gedragen door controle-boodschappen. Bovendien vereist het TLSprotocol een betrouwbare verbinding; daarom wordt ook een betrouwbaarheidslaag toegevoegd (door gebruik te maken van ack-boodschappen). Er worden in dit geval dus twee stromen gemultiplext (zie figuur 4.6).
Figuur 4.6: Multiplexen van IP-pakketten bestemd voor de tunnel, met TLS-data.
Controle-boodschappen
In deze boodschappen wordt de TLS-data ge¨encapsuleerd. Aan-
gezien TLS een betrouwbaar protocol verwacht (en UDP niet betrouwbaar is), is het nodig een reliability layer toe te voegen. Dit is ge¨ımplementeerd als een simpel ack-retransmit-protocol. De controle-boodschappen zien er als volgt uit: • local session id (8 bytes): identificeert de TLS-sessie. De key-id die hierboven gespecifieerd werd, is een verkorte versie van deze session id, omwille van effici¨entieredenen. • HMAC van encapsulatieheader voor integriteitscheck: (indien deze optie werd gespecifieerd door de gebruiker (16 of 20 bytes)) deze optie werd ingevoerd om DoS-aanvallen te weren. Enkel clients die over de (statische) HMAC encrypt-sleutel beschikken kunnen zodoende een TLS-sessie starten met de server. • packet-id (4 bytes): zorgt voor bescherming tegen replay-aanvallen
4.2 VPN-technologie¨en
24
• ACK packet id array length (1 byte); indien aankomst van andere pakketten wordt bevestigd. • ACK packet-id array: (als length > 0) • ACK remote session id: (als length > 0) • message packet-id (4 bytes) • TLS payload ciphertext (n bytes): de eigenlijke TLS-data. Eens de TLS-sessie is opgezet wordt hierover informatie uitgewisseld om sleutels te onderhandelen: • key method type; bij type1 levert de server alle sleutels, bij type2 leveren beide partijen random materiaal om een sleutel te genereren, door gebruik te maken van de TLS PRF mixing functie. • key source structure; informatie om sleutels te generen • options string length • options string: in deze string kunnen opties gespecifieerd worden (onder meer een gebruikersnaam en wachtwoord om aan authenticatie op basis van gebruikersnaam/wachtwoordparen te doen, bovenop het certificaat) ACK-boodschappen Deze boodschappen zijn gelijkaardig aan de controle-boodschappen, maar bevatten enkel acknowledgements. Data-boodschappen Deze boodschappen encapsuleren de eigenlijke verstuurde data die kan bestaan uit IP-pakketten of ethernetpakketten. De data-boodschappen bestaan uit: • HMAC van de cijfertekst IV + cijfertekst (16 of 20 bytes, afhankelijk van het gekozen algoritme) • cijfertekst IV (lengte afhankelijk van gekozen algoritme) • cijfertekst
4.2 VPN-technologie¨en
25
De plaintext van de data-boodschappen bevat ten slotte een packet id (4 bytes) en de plaintext zelf (IP-pakket of ethernetpakket). De data-boodschappen bevatten geen reliability layer. Dit komt omdat de ge¨encapsuleerde protocollen (IP of ethernet) dit ook niet eisen. De betrouwbaarheid kan dan door een hoger niveau (bijvoorbeeld TCP) afgehandeld worden. Eigenschappen Userspace OpenVPN maakt gebruik van de tun- of de tapdriver. Dit is een virtuele netwerkinterface. De gebruiker kan deze gebruiken als een echte, fysische netwerkinterface, maar de pakketten die ernaar verstuurd worden, worden doorgestuurd naar de OpenVPN-applicatie. Hierdoor kan OpenVPN volledig in userspace werken en is het programma veel gemakkelijker te porteren dan oplossingen waarbij de IP-stack in kernelspace wordt uitgebreid. Er zijn dan ook versies beschikbaar voor de meeste courante besturingssystemen (Windows, Linux, Solaris, Mac OSX, *BSD). De tun- en tapdriver is standaard aanwezig in recente Linux-kernels, FreeBSDkernels, OpenBSD-kernels, en kan ge¨ınstalleerd worden met een commandline-tool in windows (mits beheerdersrechten). Management interface OpenVPN beschikt over een management interface. Vanaf de lokale computer kan een TCP-connectie gemaakt worden met OpenVPN. Over deze connectie kunnen dan commando’s gestuurd worden om de status op te vragen, wachtwoorden toe te voegen, . . .
4.2.4
PPTP, L2TP
Zowel Point-to-Point Tunneling Protocol (PPTP) als Layer 2 Tunneling Protocol (L2TP) maken onderliggend gebruik van Point-to-Point Protocol (PPP). Voor een volledige bespreking moet dus eerst PPP bekeken worden. PPP Het Internet Protocol (IP) zorgt ervoor dat een pakket van variabele lengte zijn weg kan vinden van bron naar bestemming, maar om dit tot een goed einde te brengen, worden er enkele diensten verwacht van de onderliggende laag. De netwerklaag gebruikt de diensten van de onderliggende datalinklaag (zie figuur 4.7). De belangrijkste verantwoordelijkheden van de datalinklaag zijn het encapsuleren van data die het krijgt van de netwerklaag voor transmissie, het verbeteren van
4.2 VPN-technologie¨en
26
Figuur 4.7: Gelaagd OSI-model
fouten en het effectief verzenden van de ge¨encapsuleerde data over de fysieke link. De eerste twee zorgen voor de interface tussen datalinklaag en netwerklaag, de laatste voor de interface tussen datalinklaag en fysieke laag. In IEEE802, een familie IEEE-standaarden over LANs, heten deze respectievelijk Logical Link Control (LLC) en Media Access Control (MAC). Mensen die ooit een thuisnetwerk opgezet of onderhouden hebben, zijn zeker bekend met de term Ethernet (IEEE802.3). Dit is dan ook ´e´en van de meest bekende protocollen die bovenstaand probleem aanpakt (zij het enkel het MAC-gedeelte, het LLC-gedeelte is voor LANs gestandaardiseerd onder de naam IEEE802.2). Wanneer er echter enkel een fysieke verbinding is zonder datalinklaag, kunnen er zonder verdere tussenkomst geen netwerkpakketten verstuurd worden. Twee voorbeelden hiervan en de bijhorende oplossingen worden hierna besproken. Serial Line Internet Protocol
Een simpel voorbeeld van een situatie waar enkel een fysieke
verbinding aanwezig is, komt men tegen wanneer twee computers rechtstreeks met elkaar worden verbonden door een seri¨ele kabel. Het Serial Line Internet Protocol (SLIP) wordt hierbij gebruikt om de brug te vormen tussen de fysieke laag en de netwerklaag. SLIP zorgt er enkel voor dat IPpakketten worden verpakt voor transmissie en stuurt ze door naar de fysieke laag. Dit protocol is dan ook nooit formeel gestandaardiseerd, maar is een de facto-standaard voor het verzenden van IP-pakketten over een seri¨ele verbinding. In [7] wordt de werking besproken, maar vooral
4.2 VPN-technologie¨en
27
de tekortkomingen komen ter sprake. Tekortkomingen SLIP De modem die een thuisgebruiker gebruikt om over internettoegang te beschikken, maakt in sommige gevallen enkel een fysieke verbinding met de ISP. Hoewel SLIP in principe in dit geval ook kan gebruikt worden, wordt dit doorgaans niet gedaan wegens de tekortkomingen besproken in [7]. Zo is het niet mogelijk om een ander protocol dan IP te versturen over SLIP en gebeurt er foutdetectie noch foutcorrectie. Er wordt geen compressie ondersteund, maar het belangrijkste nadeel is dat de twee machines in een SLIP-verbinding elkaars IP-adres vooraf moeten kennen omdat SLIP geen manier heeft om adresinformatie uit te wisselen. Point-to-Point Protocol Om aan deze tekortkomingen het hoofd te bieden, werd het Pointto-Point Protocol (PPP) ontwikkeld. PPP - niet zozeer een protocol, maar wel een verzameling van protocollen - biedt bovenop het encapsuleren van data van de netwerklaag verschillende diensten aan. PPP biedt niet alleen foutdetectie en compressie, maar ook authenticatie en encryptie aan, twee dingen die interessant zijn voor VPN-oplossingen. De werking van PPP kan onderverdeeld worden in drie secties die elk hun specifiek doel hebben. Net als SLIP moet PPP data komende van de netwerklaag verpakken voor transmissie, maar omdat meer geavanceerde diensten worden aangeboden zal dit complexer zijn dan de simpele encapsulatie van SLIP (de encapsulatie bestaat hier uit het simpelweg aanduiden van het einde van een pakket). 1. De interface naar de fysieke laag wordt verzorgd door het Link Control Protocol (LCP). 2. Een verzameling van protocollen, genaamd Network Control Protocol s, verzorgt de interface naar de netwerklaag. Voor elk netwerkprotocol dat PPP kan vervoeren, wordt een protocol gespecifieerd. 3. Bovenop de standaardcomponenten van PPP, die instaan voor het basisonderhoud van de fysieke verbinding en de netwerkverbindingen, worden er twee additionele groepen protocollen gedefinieerd. Deze staan in voor het ondersteunen van de basisprotocols (LCP Support Protocols) of het aanbieden van extra diensten over de opgezette verbinding (LCP Optional Feature Protocols).
4.2 VPN-technologie¨en
28
PPP: Encapsulatie De structuur van een PPP-frame is gebaseerd op het ISO High-Level Data Link Control (HDLC), oorspronkelijk ontwikkeld door IBM (zie [8]).
Figuur 4.8: PPP-frame
• Flag: Een sequentie van ´e´en byte (01111110) die het begin of het einde van een frame aanduidt. • Address: De binaire sequentie 11111111, het standaardbroadcastadres. Een HDLC-frame kan een adres bevatten, maar PPP kent geen afzonderlijke adressen toe aan beide kanten van de verbinding. • Control: De binaire sequentie 00000011. HDLC biedt verschillende modes aan, PPP echter ondersteunt slechts ´e´en van deze modes, namelijk een best-effort service. • Protocol: twee bytes die het ge¨encapsuleerde protocol aanduiden. Zie [9, 10, 11] voor de mogelijke waarden. • Data: Ge¨encapsuleerde data. • FCS: Frame Check Sequence, gebruikt voor foutdetectie. De velden Protocol en FCS zorgen al voor twee extra services ten opzichte van SLIP: respectievelijk de mogelijkheid van encapsulatie van meerdere protocollen en foutdetectie. PPP: Link Control Protocol
Voor elke fysieke link kan maximum ´e´en LCP-link opgezet
worden. Figuur 4.9 toont de mogelijke overgangen die een PPP-verbinding kan maken. Een PPP-verbinding begint en eindigt altijd in de Link Dead -fase, waar er geen fysieke verbinding is tussen beide eindpunten van de link. Van zodra er een fysieke verbinding wordt opgezet, start de onderhandeling over de LCP-configuratie. Indien dit niet lukt, blijft de verbinding in de Link Dead -fase. Na de succesvolle onderhandeling kan de authenticatie van start gaan, indien dit niet lukt wordt de LCP-verbinding afgebroken. Bij succesvolle authenticatie is er een volwaardige LCPverbinding.
4.2 VPN-technologie¨en
29
Figuur 4.9: Fase-overgangen bij het opzetten van een PPP-verbinding
Een LCP-verbinding wordt pas gesloten als de fysieke verbinding het begeeft of als ´e´en van beide uiteinden van de verbinding vraagt om de verbinding te sluiten. Het is dus niet zo dat als alle verbindingen die geopend waren over de LCP-verbinding (zoals NCP-verbindingen en verbindingen die aanvullende protocollen maken) gesloten zijn, automatisch de LCP-verbinding wordt verbroken. PPP: Network Control Protocols Op dit moment is er wel een actieve LCP-verbinding, maar er kan nog geen verkeer over gestuurd worden omdat hiervoor een NCP-verbinding moet opgezet worden voor het bijbehorende protocol. Elk netwerkprotocol dat men over PPP kan versturen heeft een eigen NCP-protocol. Voor IP bijvoorbeeld is dit het Internet Protocol Control Protocol (IPCP), voor IPX bestaat het Internetworking Packet Exchange Control Protocol
4.2 VPN-technologie¨en
30
(IPXCP). Vooraleer een NCP-verbinding opgezet kan worden, moet men beschikken over een volledig geconfigureerde LCP-verbinding. Lukt de onderhandeling voor een bepaalde NCP-verbinding, dan bevindt de PPP-verbinding zich in de Link Open-fase en kan de verbinding gebruikt worden. Er kunnen over ´e´en LCP-verbinding meerdere NCP-verbindingen gestart worden om meerdere netwerkprotocollen door te sturen over dezelfde fysieke verbinding. PPP: LCP Support Protocols Tijdens de onderhandeling van de LCP-verbinding kunnen er bijkomende protocollen gebruikt worden. Voor het probleem dat we hier bespreken zijn vooral de protocollen die authenticatie bijvoegen interessant. Bekende voorbeelden zijn het Password Authentication Protocol (PAP: zie [13]) en het Challenge Handshake Authentication Protocol (CHAP: zie [14]). PPP: LCP Optional Feature Protocols Nadat er een PPP-verbinding is opgezet zorgen deze protocollen ervoor dat er extra diensten kunnen geleverd worden. Een voorbeeld hiervan is compressie, dit wordt aangeboden door het Compression Control Protocol (CCP). Belangrijker voor een VPN-oplossing is het aanbieden van encryptie, dit kan door het Encryption Control Protocol (ECP: zie [15]). Verschillende encryptie-algoritmen worden ondersteund, waaronder DES en 3DES. PPTP Geschiedenis Het Point-to-Point Tunneling Protocol is ontwikkeld door een consortium waarin onder andere Microsoft en 3Com zetelden. PPTP gebruikt PPP om verkeer te tunnelen over een IP-netwerk zoals het internet, zonder PPP te veranderen. Cisco was de eerste die een implementatie klaar had en verkocht een licentie aan Microsoft. In deze implementatie kan de authenticatie gebeuren met Cisco LEAP of met MS-CHAP en encryptie gebeurt aan de hand van het Microsoft Point-to-Point Encryption protocol (MPPE: zie [16]). PPTP-clients worden sinds Windows 95 meegeleverd en de Routing And Remote Access Service for Microsoft Windows bevat een PPTP server. Vanaf versie 2.6.14 (28 oktober 2005) zit er offici¨ele ondersteuning voor PPTP in de Linux-kernel. SuSE 10 was de allereerste Linuxdistributie met een volledig werkende PPTP-client. Ook voor MacOS zijn er PPTP-clients beschikbaar.
4.2 VPN-technologie¨en
Veiligheid
31
Door de grote marktpenetratie en door het feit dat Microsoft eerst was met het
aanbieden van een implementatie, is Microsoft PPTP veruit het meest gebruikt. Er zijn echter op het internet vele waarschuwingen te vinden in verband met het gebrek aan veiligheid bij deze implementatie. Bruce Schneier en Mudge hebben de eerste versie van de implementatie van Microsoft onderzocht en concluderen dat ze inherent onveilig is, als voorbeeld geven ze L0phtcrack, een programma dat het mogelijk maakt om op basis van de doorgestuurde hashes makkelijk het wachtwoord te verkrijgen (zie [17, 18, 19]). Dit is op verschillende nieuwssites gepubliceerd geweest (zie [20, 21, 22]). Nadat dit aan het licht kwam heeft Microsoft enkele aanpassingen aangebracht aan hun implementatie, maar nog steeds werden veiligheidsproblemen gesignaleerd. Asleap bijvoorbeeld (zie [23, 24]) kan zwakke LEAP- en PPTP-wachtwoorden onderscheppen enkel en alleen door het verkeer af te luisteren. Met dit wachtwoord kan dan de hele PPTP-stroom gedecodeerd en gelezen worden. Bruce Schneier en Mudge onderzochten de verbeterde versie en publiceerden de resultaten, het bleek nog altijd mogelijk dezelfde wachtwoorden te weten te komen (zie [25, 19]). Verder zijn er nog enkele Microsoft Security Bulletins waar veiligheidsproblemen besproken worden. In MS01-009 ([26]) wordt toegelicht hoe een Denial-of-Service-aanval kan worden ondernomen door een slechtgevormde PPTP-pakketstroom te versturen. Er hoeft hiervoor geen geldige PPTP-sessie opgezet te worden. MS02-063 ([27]) bespreekt een gelijkaardige aanval. Een samenvatting van alle bekende exploits met betrekking tot PPTP en resultaten van tests omtrent deze exploits zijn te vinden in [28]. Werking Terwijl bij PPP ´e´en extra machine instaat voor de implementatie van het protocol, genaamd de Network Access Server (NAS) verdeelt PPTP de verantwoordelijkheden onder twee verschillende machines zoals ge¨ıllustreerd in figuur 4.10. De PPP-verbinding wordt door PPTP logisch uitgebreid door de PPP-frames te tunnelen tussen twee machines, namelijk de PPTP Access Concentrator (PAC) en de PPTP Network Server (PNS). In plaats van verbonden te worden met het publieke internet zoals dat het geval is bij PPP, wordt er over dit publieke internet een tunnel opgezet zodat de PPTP-client verbonden wordt met een privaat netwerk naar keuze. De PAC staat in voor de clientzijde van de tunnel. PSTN- of ISDN-lijnen zijn rechtstreeks verbonden met deze machine. De PAC moet in staat zijn een PPP-verbinding op te zetten en te onderhouden over de fysieke verbindingen waarvoor hij verantwoordelijk is ´en staat in voor
4.2 VPN-technologie¨en
32
Figuur 4.10: Werking van PPTP / L2TP
het afhandelen van het PPTP-protocol. De PNS staat in voor de serverzijde van de tunnel. Er bestaat een many-to-many-relatie tussen PACs en PNSs. Zo is het mogelijk dat eenzelfde PNS diensten aanbiedt aan gebruikers verbonden met verschillende PACs (client-to-site VPN). Het is eveneens mogelijk om voor eenzelfde virtueel netwerk verschillende PNSs te gebruiken. PPTP is verbindingsgeori¨enteerd. Zowel de PAC als de PNS houdt informatie bezig over alle gebruikers die verbonden zijn met een PAC. Wanneer een gebruiker verbonden met een welbepaalde PAC een verbinding met de PNS wil opzetten, wordt er een tunnel tussen PAC en PNS opgezet. Vooraleer PPP kan getunneld worden tussen PAC en PNS moet er een controleverbinding tussen hen opgezet worden. Deze verbinding is een standaard TCP-verbinding op poort 1723 waarover PPTP controle- en onderhoudsboodschappen stuurt. Deze verbinding wordt gebruikt voor het opzetten, onderhouden en afbreken van sessies over de tunnel. Naast de controleverbinding maakt PPTP gebruik van een IP-tunnel tussen dezelfde PAC en PNS. Er wordt gebruik gemaakt van een licht gewijzigde versie van Generic Routing Encapsulation (GRE: zie [29, 30]) om de PPP-pakketten te encapsuleren. Alle PPP-sessies tussen een bepaald PAC-PNS-paar worden over dezelfde tunnel vervoerd, op basis van een sleutel in de GRE-header kan een PPP-pakket toegewezen worden aan een welbepaalde PPP-sessie. Op deze manier worden verschillende PPP-sessies gemultiplext over ´e´en enkele tunnel. De pakketten die over deze tunnel lopen zijn PPP-pakketten ge¨encapsuleerd in GRE, verzonden over IP zoals te zien in figuur 4.11.
4.2 VPN-technologie¨en
33
PPTP is uiteraard niet beperkt tot inbelverbindingen. Bovenvernoemde PPTP-clients zorgen ervoor dat een niet-inbelclient zelf kan instaan voor een eindpunt van een PPTP-tunnel. De PPTP-client zorgt dan zowel voor het inpakken in en uitpakken van PPP-frames, als voor het tunnelen door PPTP.
Figuur 4.11: Structuur van een PPTP-pakket
L2TP Geschiedenis Layer 2 Tunneling Protocol komt voort uit twee andere protocollen die PPP tunnelen, namelijk Layer 2 Forwarding (L2F) van Cisco en PPTP. Voor authenticatie en encryptie steunt L2TP grotendeels op andere protocollen. Bij L2TP/PPP (hierbij worden PPP-sessies getunneld over L2TP) zorgt PPP voor authenticatie bij het opzetten van de controleverbinding en encryptie voor de dataverbinding. Een andere mogelijkheid is L2TP/IPSec, hierbij steunt L2TP op de mogelijkheden van IPSec qua authenticatie en encryptie. Cisco beweert een patent te hebben met betrekking tot L2F en L2TP, namelijk patent nummer 5.918.019 in de Verenigde Staten van Amerika. Werking De werking van L2TP is volledig analoog aan de werking van PPTP (zie figuur 4.10). PPP laat toe om TCP/IP-pakketten te versturen over dial-upverbindingen door ze te encapsuleren in PPP-frames en ze te versturen naar een ISP die de TCP/IP-pakketten uit deze PPP-frames haalt en ze het publieke internet instuurt. L2TP, net als PPTP, trekt deze logische verbinding door naar een zelf gekozen machine ergens op het internet. Er wordt een tunnel opgezet tussen een machine bij de eigen ISP en een zelf te kiezen machine. De functionaliteiten van de Network Access Server (NAS) worden net als bij PPTP gesplitst tussen de L2TP Access Concentrator (LAC) en de L2TP Network Server (LNS). De LAC doet zich voor als een NAS ten opzichte van de gebruiker, maar is in werkelijkheid het ingangspunt voor de L2TP-tunnel. De LNS doet dienst als eindpunt van de L2TP-tunnel en ontdoet de L2TP-pakketten van zijn L2TP- en PPP-header zodat enkel het TCP/IP-pakket overblijft en doorgestuurd wordt naar het achterliggende netwerk. Net als bij PPTP kunnen over een tunnel tussen LAC en LNS meerdere sessies lopen.
4.2 VPN-technologie¨en
34
Figuur 4.12: Structuur van een L2TP/PPP-pakket
L2TP tunnelt PPP-verkeer en erft dus authenticatie, encryptie en compressie over van PPP.Het biedt daarnaast een beperkte authenticatie van de eindpunten van de tunnel, maar biedt geen extra beveiliging van het verkeer over de tunnel. Figuur 4.12 toont de structuur van een L2TP/PPP-pakket. Een L2TP/PPP-pakket is niks anders dan een UDP-datagram met specifieke inhoud. Om verdere beveiliging aan te bieden gebruikt L2TP/IPSec de mogelijkheden van IPSec, zoals beschreven in 4.2.2. L2TP/PPPpakketten worden ge¨encapsuleerd in IPSec-pakketten om de extra beveiligingsmogelijkheden in IPSec te gebruiken. Er wordt dus een L2TP-tunnel opgezet over een beveiligde IPSec-verbinding. Tabel 4.2: Vergelijking VPN-technologie¨en
Authenticatie
IPSec
OpenVPN
PPTP
L2TP/PPP
L2TP/IPSec
PSK, RSA,
PSK,
MS-
PPP
IPSec, PPP
X.509
X.509,
CHAPv2,
user/pass
CISCO
Geen
Geen
IKE
PPP2
PPP
IPSec, PPP
LEAP Key exchange
IKE
TLS/SSL
Standaard
onder-
AES, DES,
Alle
steunde encryptie-
3DES, RC5,
OpenSSL
algoritmen
IDEA,
(3DES,
3IDEA,
AES, Blow-
CAST,
fish, ...)
in
Blowfish Kernelspace
of
Kernelspace
Userspace
Kernelspace
Kernelspace
Kernelspace
Nee
Ja
Ja
Ja
Nee
userspace Bridging 2
3DESE (RFC2420), DESE (RFC1969), MPPE (RFC3078), maar men kan voor elk encryptie-algoritme een
ECP schrijven.
4.2 VPN-technologie¨en
35
Tabel 4.2: Vergelijking VPN-technologie¨en
Platform
IPSec
OpenVPN
PPTP
L2TP/PPP
L2TP/IPSec
Beschikbaar
Windows,
Windows,
Windows,
Windows,
voor
bij-
Unix,
Linux,
Linux,
Linux,
na
alle
*BSD, Mac
*BSD,
*BSD,
*BSD,
OSX
meeste
meeste
meeste
Unices
Unices
Unices
platformen
NAT-traversal
Nee
Ja
Ja
Ja
Nee
Aanspreekbaar in
Nee
Ja
Nee
Nee
Nee
Java op algemene manier
4.2.5
Vergelijking
Tabel 4.2 toont de eigenschappen van de verschillende VPN-technologie¨en waarop deze vergelijking is gebaseerd. Allereerst zullen we PPTP en L2TP/PPP bespreken aangezien beide technologie¨en gelijkaardig zijn. Beiden tunnelen PPP-verkeer zonder verdere encryptie en doen aan authenticatie bij het opzetten van de verbinding, maar voorzien niet in per-pakketauthenticatie. Het enige grote verschil is de manier waarop het PPP-verkeer ge¨encapsuleerd wordt. PPTP gebruikt een GRE-achtig protocol om daarna via IP verzonden te worden. L2TP/PPP neemt een PPP-frame, voegt hier eigen informatie aan toe en encapsuleert dit in UDP voor verzending. Beide protocollen moeten in het algemeen in kernelspace ge¨ımplementeerd worden wat voor het systeem dat hier besproken wordt een groot probleem met zich meebrengt aangezien de VPN-oplossing met zo weinig mogelijk extra configuratie op de gateways moet kunnen ge¨ınstalleerd worden. Verder is de veiligheid die PPTP biedt onvoldoende voor het systeem. Bij L2TP is er dan weer sprake van een patentprobleem. Deze problemen geven aan dat het niet de moeite is het probleem van de installatie en moeilijke aanspreekbaarheid in Java te proberen op te lossen. IPSec en L2TP/IPSec zijn eveneens gelijkaardige protocollen met dat verschil dat IPSec enkel IP-verkeer kan transporteren terwijl L2TP/IPSec doordat het PPP tunnelt ook andere protocollen kan vervoeren. Tevens heeft L2TP/IPSec meerdere lagen van encryptie en authenticatie ten opzichte van IPSec. IPSec en L2TP/IPSec zijn in dit geval niet makkelijk bruikbaar
4.3 Adresseringsstrategie
36
aangezien er standaard niet door NAT kan getunneld worden en de meeste implementaties zich in kernelspace bevinden waardoor ze minder makkelijk aanspreekbaar zijn in Java en moeilijk installeerbaar zijn. OpenVPN is de beste oplossing voor dit probleem aangezien verschillende problemen rechtstreeks opgelost worden door dit protocol. • NAT is geen probleem. • policies kunnen worden ge¨ımplementeerd. • het is aanspreekbaar in Java door gebruik te maken van een TCP-verbinding. • de veiligheid wordt gegarandeerd door TLS voor sleuteluitwisseling en de effectieve datapakketten worden geauthenticeerd en ge¨encrypteerd met de meest recente cryptografische algoritmen uit de OpenSSL-bibliotheek.
4.3
Adresseringsstrategie
E´en van de problemen die kunnen optreden wanneer men een VPN-verbinding aanlegt tussen twee willekeurige netwerken, is dat van overlappende subnetwerken: beide gateways gebruiken overlappende (of gelijke) subnetwerken, als gevolg hiervan is het onmogelijk voor hosts op het ene netwerk om hosts op het andere netwerk te adresseren. Immers, deze hosts lijken op hetzelfde netwerk te zitten, de contacterende host zal zijn IP-pakketten niet naar de gateway sturen, maar een ARP-request versturen op het netwerk (en dus geen antwoord krijgen, of een antwoord van een verkeerde host). Dit probleem komt uiteraard enkel voor indien de netwerken gebruik maken van een subnetwerk uit de private adresruimte. Deze bestaat uit de subnetwerken 10.0.0.0/8, 172.16.0.0/12 en 192.168.0.0/16.3 Het probleem is zeker niet te verwaarlozen bij home gateways, omdat gateways van hetzelfde merk en type vaak hetzelfde subnetwerk gebruiken (typisch bijvoorbeeld 192.168.0.0/24 of 10.0.0.0/8). Een aantal mogelijke oplossingen worden beschreven in de volgende secties. 3
De CIDR-notatie wordt hier gebruikt om de netwerken aan te duiden.
4.3 Adresseringsstrategie
4.3.1
37
Netwerken samenvoegen
De meest voor de hand liggende oplossing is om de twee overlappende netwerken proberen samen te voegen tot ´e´en netwerk. Dit kan door de VPN-daemon te laten opereren in bridgemode. In deze mode gedraagt de VPN-tunnel zich als een ethernet-bridge: alle ethernet-pakketten die op het ene netwerk verstuurd worden (en de gateway bereiken), worden doorgestuurd over de tunnel naar het andere netwerk. Op deze manier vormen de twee netwerken samen ´e´en logisch netwerk. Om dit te doen werken moeten alle hosts op beide netwerken ingesteld zijn op hetzelfde subnetwerk (met hetzelfde netwerkmasker). Bovendien mogen geen 2 hosts uit de verschillende netwerken hetzelfde IP-adres hebben. Dit kan opgelost worden indien op beide netwerken alle hosts met DHCP geconfigureerd worden. Dan kan ´e´en van de gateways gekozen worden als DHCP-server, die dan niet-conflicterende IP-adressen kan uitdelen aan de hosts op beide netwerken. Eventueel kan een groter subnetwerk gekozen worden als nieuw netwerk, om er zeker van te zijn dat alle hosts een IP-adres kunnen krijgen. Deze oplossing vereist natuurlijk dat de gateways de oorspronkelijke DHCP-servers (dit kunnen eventueel de gateways zelf zijn) kunnen stopzetten. Het grote nadeel van deze oplossing is dat het zeer waarschijnlijk is dat een aantal hosts een nieuw IP-adres zullen moeten krijgen. Dit is echter niet wenselijk: alle bestaande verbindingen voor deze hosts zullen hierdoor afgebroken worden, ook al was het niet de gebruiker van deze host die de VPN-verbinding opgezet heeft! Een ander nadeel is dat deze oplossing enkel werkt voor netwerken waarbij alle IP-adressen door DHCP geconfigureerd worden. Als er een adresconflict is tussen twee hosts met hetzelfde statisch ingestelde IP-adres, zal dit manueel opgelost moeten worden.
4.3.2
Adresvertaling
Een tweede oplossing is om gebruik te maken van adresvertaling. Door op de gateways de bron- en bestemmingsadressen van pakketten aan te passen, kan een client op het ene netwerk aangesproken worden door een client op het andere netwerk aan de hand van een nieuw, virtueel IP-adres. Er wordt dus als het ware een overlay-netwerk gecre¨eerd. Op deze manier kunnen de hosts hun huidige IP-adres behouden, zodat bestaande verbindingen niet worden verbroken. Verder werkt deze methode ook voor netwerken met statisch ingestelde IP-adressen. Er zijn verschillende manieren om deze adresvertaling in te stellen:
4.3 Adresseringsstrategie
38
Adresvertaling met virtuele IP-adressen in het remote netwerk Dit systeem kan toegepast worden indien op beide netwerken alle hosts met DHCP geconfigureerd worden en de gateways DHCP-server zijn. De gateways op beide netwerken sturen de IP-adressen van de met DHCP geconfigureerde hosts door naar elkaar. De gateways reserveren voor elk van deze IP-adressen een nieuw, virtueel IP-adres op hun lokale netwerk en houden een relatie bij tussen fysiek en virtueel IP-adres. Wanneer een IP-pakket op de gateway toekomt met als bestemmingsadres een van de gereserveerde virtuele IP-adressen, wordt het bestemmingsadres van het pakket vertaald naar het fysieke IP-adres en wordt het pakket verstuurd naar de remote gateway. Op de andere gateway zal dan het bronadres vertaald worden naar het virtuele IP-adres dat daar gereserveerd is. Een probleem is wel dat pakketten voor het remote netwerk mogelijkerwijs niet op de gateway toekomen. Het virtuele IP-adres voor een host op het remote netwerk ligt immers binnen het eigen netwerk. Dit IP-adres zal dus geresolved worden aan de hand van een ARP-request. Het is dus nodig dat de gateway ARP-reply’s (met het MAC-adres van de gateway) zal genereren voor de hosts van het remote netwerk. Verder is het zo dat er voortdurende communicatie nodig is tussen de gateways, om elkaar in te lichten wanneer een nieuwe host verschijnt op hun netwerk. Adresvertaling met nieuwe subnetwerken Een betere oplossing is om aan beide netwerken een nieuw, onderling niet overlappend, virtueel subnetwerk toe te kennen. De gateway past dan adresvertaling toe op de volgende manier: • bij IP-pakketten met als bestemming het virtuele subnetwerk van de remote gateway wordt het bronadres vertaald naar een IP-adres uit het lokale virtuele subnetwerk • bij IP-pakketten met als bestemming het lokale virtuele subnetwerk wordt het bestemmingsadres vertaald naar het correcte IP-adres uit het lokale fysieke subnetwerk De gateway houdt dus een relatie bij voor alle clients op zijn netwerk. De routering moet zo ingesteld worden dat pakketten bestemd voor het remote virtuele subnetwerk, verstuurd worden over de tunnel. Het voordeel van deze methode is dat het onafhankelijk van de DHCP-server werkt. Verder is het zo dat elke gateway enkel verantwoordelijk is voor de adresvertaling van zijn eigen hosts. Dit
4.3 Adresseringsstrategie
39
maakt het eenvoudiger om te implementeren en eenvoudiger uitbreidbaar naar situaties waarin gateways verschillende VPN-verbindingen aanmaken. Een nadeel van deze methode is dat, aangezien men niet kan weten hoeveel hosts er op een gegeven subnetwerk zitten (doordat hosts een statisch ingesteld IP-adres kunnen hebben), men voor het virtuele subnetwerk altijd een even groot subnetwerk moet kiezen als het fysieke subnetwerk. Bovendien kan men voor de virtuele subnetwerken enkel kiezen uit de private adresruimte (indien men een publiek subnetwerk zou kiezen, is dit niet meer adresseerbaar door de hosts). Indien het fysieke subnetwerk 10.0.0.0/8 is, is het dus onmogelijk om een nieuw virtueel subnetwerk te kiezen dat groot genoeg is. Verder is het ook mogelijk, in het geval dat er meerdere VPN-verbindingen worden opgezet vanuit ´e´en gateway, dat de private subnetwerken waaruit een gateway kan kiezen voor virtuele subnetwerken, uitgeput raken. Elke VPN-verbinding zal er immers voor zorgen dat twee subnetwerken niet meer gebruikt kunnen worden (namelijk het lokale virtuele subnetwerk en het remote virtuele subnetwerk). Deze nadelen worden geminimaliseerd indien de subnetwerken van de deelnemende partijen niet te groot gekozen worden. Figuur 4.13 toont een voorbeeld van deze methode.
Figuur 4.13: Een voorbeeld van adresvertaling met nieuwe subnetwerken. Het linkernetwerk heeft als virtueel subnetwerk 192.168.1.0/24; het rechternetwerk heeft 192.168.2.0/24.
ONTWERP
40
Hoofdstuk 5
Ontwerp 5.1
Inleiding
In dit hoofdstuk wordt het ontwerp van het systeem besproken. De eerste ontwerpbeslissing betreft de inbedding in het OSGi Service Platform. Zoals vermeld in sectie 4.1 bestaan applicaties voor dit platform uit bundles die services kunnen aanbieden en gebruiken. Het is dan ook een logische stap om de verschillende modules uit de architectuur af te beelden op OSGi-bundles1 . Voor elke module wordt een Java interface aangemaakt (deze interfaces worden gegroepeerd in de package jason.interfaces) en een bundle die een klasse bevat die deze interface implementeert. Deze bundle wordt als service geregistreerd in het OSGi-framework. Deze aanpak heeft als voordeel dat de modules onafhankelijk van elkaar kunnen ge¨ımplementeerd worden (er is enkel een afhankelijkheid van de interfaces). Een ander voordeel is dat de modules onafhankelijk van elkaar kunnen ge¨ınstalleerd worden op de gateways en dat er eenvoudig een module kan vervangen worden. Indien men bijvoorbeeld een bug vaststelt in de VPNInterface, hoeft enkel deze bundle vervangen te worden, de andere bundles hoeven hiervoor niet eens gestopt te worden. Om dit te verwezenlijken werd gekozen voor een zwakke binding tussen de bundles: wanneer een bepaalde bundle een service wil gebruiken van een andere bundle, wordt de service op dat moment opgezocht. De bundles houden dus geen blijvende referenties bij naar andere bundles. Een andere ontwerpbeslissing betreft de keuze van OpenVPN als basis voor de VPNInterface. De keuze voor OpenVPN is gemotiveerd in 4.2.5. Voor de adresvertaling, besproken in 4.3.2, wordt gebruik gemaakt van iptables, een pro1
Een uitzondering is de module GNSserver. Deze module bevindt zich niet op een gateway, maar op een server
beheerd door de Service Provider. Deze is dan ook niet ge¨ımplementeerd als een OSGi-bundle, maar als een gewone Java-applicatie.
5.2 Negotiator
41
gramma dat kan gebruikt worden om de firewall- en adresvertalingsopties in de linuxkernel in te stellen. Dit betekent dat adresvertaling momenteel enkel mogelijk is op een linuxgateway, maar het is zeker mogelijk om deze functionaliteit ook te implementeren voor andere platformen. Bij de onderhandeling die optreedt tussen gateways alvorens een VPN-verbinding op te zetten, wordt gekeken of beide partijen adresvertaling ondersteunen, indien dit nodig blijkt. Ten slotte werd ook nog een protocol ontworpen voor de onderhandeling tussen gateways (sectie 5.2.1) en ´e´en voor de communicatie tussen gateway en GNS-Server (sectie 5.8.1). De module Policing werd niet ge¨ımplementeerd. De volgende secties beschrijven het ontwerp voor de verschillende modules/bundles.
5.2
Negotiator
Figuur 5.1 toont alle klassen gebruikt voor de implementatie van de module Negotiator.
5.2.1
Generiek onderhandelingsprotocol
Om de redenering in sectie 3.1.1 tot een goed einde te brengen, moeten beide onderhandelingspartners natuurlijk eenzelfde taal spreken. Deze taal wordt hieronder besproken. Bij het starten van de onderhandeling gaat de Negotiator van de gateway die de onderhandeling heeft gestart, aan alle geregistreerde bundles een gesorteerde lijst van waarden vragen van alle parameters waarvoor deze bundle zich geregistreerd heeft. Deze lijsten dienen gesorteerd te zijn volgens dalende voorkeur. Op basis van de aangeleverde lijsten wordt een bericht opgesteld dat naar de andere kant wordt verstuurd. Het bericht volgt de specificatie in figuur 5.2. Hierbij is <EOL> het einde van een lijn en zijn
en tekstsequenties waar geen : of ; in voorkomen. De Negotiator van de gateway die het bericht ontvangt, verwerkt dit bericht en krijgt alzo de gesorteerde lijsten waarvan eerder sprake. Aan elk van de op deze gateway geregistreerde bundles wordt, voor elke parameter waarvoor deze geregistreerd is, een gesorteerde lijst met waarden gegeven. Op basis van deze informatie beslist de bundle over deze parameters en geeft een lijst met beslissingen terug voor alle parameters waar een beslissing voor nodig is. Een antwoord wordt opgesteld aan de hand van de beslissingen van de bundles. Dit bericht volgt de specificatie in figuur 5.3. De beslissing neemt ´e´en van de volgende waarden aan: • ´e´en van de mogelijke waarden die werden aangeleverd door de beginnende gateway.
5.2 Negotiator
42
Figuur 5.1: Klassendiagram van relevante klassen voor de bundle Negotiator
• UNKNOWN geeft aan dat de beginnende gateway over een parameter wil onderhandelen die de ontvangende gateway niet kent (dus waarvoor geen bundle zich geregistreerd heeft). • N/A geeft aan dat er geen beslissing nodig is voor deze parameter, dit kan bijvoorbeeld voorkomen wanneer een extra parameter nodig is om tot een beslissing van een andere parameter te komen. • FAIL is een manier om de beginnende gateway duidelijk te maken dat er geen beslissing mogelijk is en dat een verbinding niet mogelijk is onder de op dat ogenblik geldende omstandigheden. Het is niet verplicht om een beslissing in te vullen, in dit geval wordt N/A als beslissing aangenomen.
5.2 Negotiator
43
Figuur 5.2: (a) Specificatie van vraag negotiatorprotocol (b) Voorbeeld van een vraag
Figuur 5.3: (a) Specificatie van antwoord negotiatorprotocol (b) Voorbeeld van een antwoord
De gateway die de onderhandeling heeft ingezet, bekijkt de beslissingen die de andere gateway genomen heeft, beslist of hij hier al dan niet mee akkoord gaat en stuurt een ACK of een NACK naar de andere gateway. Bij een ACK zal langs beide kanten de verbinding opgezet worden. Een NACK heeft als gevolg dat de onderhandeling en de bijbehorende verbinding wordt afgebroken.
5.2.2
Implementatie onderhandelingsprotocol
Om het Negotiatorprotocol van 5.2.1 te implementeren is er gebruik gemaakt van de listenerarchitectuur. Alle bundles die de onderhandeling van ´e´en of meerdere parameters wil uitbesteden aan de Negotiator moet een interface genaamd NegotiatorListener implementeren. In grote lijnen zijn er twee fasen: in de eerste registreert elke bundle zich bij de lokale Negotiator waarna er over verbindingen kan onderhandeld worden (tweede fase). Registratie Figuur 5.4 toont hoe een registratie bij de Negotiator in zijn werk gaat. Bij de lokale gateway registreert een bundle de parameters waarvoor hij verantwoordelijk wil zijn. Enige tijd later komt er een andere bundle online die zijn parameters wil registreren. Bij de registratie merkt de Negotiator dat ´e´en of meerdere van de parameters die de tweede bundle wil registreren reeds geregistreerd is door de eerste bundle. Nadat de bundle van de Negotiator te horen heeft gekregen welke parameters hij niet mag registreren, probeert hij nog een keer. Ditmaal lukt
5.2 Negotiator
44
Figuur 5.4: Registratiefase generiek onderhandelingsprotocol
de registratie. Eenzelfde registratie voltrekt zich bij alle gateways die gebruik maken van dit systeem. Onderhandeling Wanneer een gebruiker een verbinding wil starten zal het systeem een onderhandeling starten tussen de lokale gateway en de gateway waarmee de gebruiker verbinding wil maken. Deze onderhandeling is op zich eveneens onderverdeeld in verschillende stappen. Maar vooraleer er met de effectieve onderhandeling begonnen wordt, wordt er door middel van de mogelijkheden die SSL/TLS biedt gecontroleerd of de gateway waarmee wordt gecommuniceerd wel degelijk is wie hij zegt te zijn. Ook wordt gekeken of de andere kant voorkomt in de lokale lijst van vertrouwde gateways. Deze controles gebeuren aan beide kanten van de verbinding en zodra ´e´en van de controles faalt, wordt de onderhandeling afgebroken. Voor elke aanvraag tot onderhandeling die een gateway verwerkt, wordt een aparte thread opgestart zodat er terzelfdertijd opnieuw op nieuwe aanvragen gewacht kan worden. 1. Request: in figuur 5.5 wordt grafisch weergegeven wat er gebeurt in deze eerste stap. De Negotiator vraagt aan alle geregistreerde NegotiatorListener s een geordende lijst van keuzes voor elke parameter waarvoor die specifieke bundle zich geregistreerd heeft. Wanneer hij al deze lijsten ontvangen heeft, wordt het bericht gegenereerd volgens de specificatie in figuur 5.2. Eens het bericht aangemaakt is, wordt het over een beveiligde verbinding naar de andere gateway gestuurd.
5.2 Negotiator
45
Figuur 5.5: Genereren vraag generiek onderhandelingsprotocol
2. Antwoord: wanneer de vraag binnenkomt aan de andere kant van de verbinding, wordt tijdens het ontleden van het bericht gekeken welke NegotiatorListener lokaal verantwoordelijk is voor de verschillende parameters. De geordende lijsten van de desbetreffende parameters worden aan de juiste bundles gegeven zodat deze een beslissing kunnen nemen over hun parameters. De Negotiator ontvangt deze beslissingen en genereert een antwoord om terug te sturen naar de gateway die de onderhandeling heeft gestart. In figuur 5.6 wordt dit grafisch weergegeven.
Figuur 5.6: Beslissingsfase generiek onderhandelingsprotocol
3. Bevestiging: de beslissing die de gateway aan de andere kant van de verbinding genomen heeft over de te onderhandelen parameters, moet nog goedgekeurd worden door de gateway
5.2 Negotiator
46
die de onderhandeling heeft gestart. Dit gebeurt door het bericht met de beslissingen aan de verantwoordelijke bundles te geven. Van zodra ´e´en van de bundles niet akkoord gaat met de onderhandelde parameters (typisch zal dit gebeuren als de beslissing van een parameter FAIL is of in het geval de beslissing UNKNOWN is en de desbetreffende parameter verplicht is voor de huidige verbinding) zal een NACK verstuurd worden. Wanneer alle beslissingen echter in orde zijn, kunnen beide kanten alles in gereedheid brengen voor de effectieve VPN-verbinding. Figuur 5.7 geeft dit grafisch weer.
Figuur 5.7: Controlefase generiek onderhandelingsprotocol
NegotiatorListener Om gebruik te kunnen maken van de diensten van de Negotiator moet een bundle de interface NegotiatorListener implementeren, waar volgende functies worden gedefinieerd: • getParameterLists: een functie die wordt gebruikt in de eerste fase van de eigenlijke onderhandeling (figuur 5.5) om geordende voorkeurslijsten voor alle parameters te verkrijgen. • negotiateParameters: een functie die wordt gebruikt in de beslissingsfase (figuur 5.6) om de beslissing te laten gebeuren. • negotiatedParameters: een functie die de bundle op de hoogte brengt van de beslissing van de parameters zoals in figuur 5.7. Een bundle moet zich bij de Negotiator registreren voor elke parameter waar hij voor verantwoordelijk wil zijn.
5.3 ConfigurationManager
47
DefaultNegotiatorListener Voor het simpele geval dat een parameter niet wordt be¨ınvloed door andere parameters werd er een abstracte standaardimplementatie van NegotiatorListener aangeboden. Hierbij wordt enkel de functie die een beslissing neemt voor elke parameter, ge¨ımplementeerd. Het is niet de bedoeling van de onderhandeling om de wil van ´e´en van de gateways door te drukken, maar om een keuze te maken die voor beide gateways de best mogelijke optie is rekening houdend met de wensen van de andere gateway. De implementatie volgt de volgende redenering: allereerst worden uit beide gesorteerde lijsten die opties geschrapt die niet voorkomen in de andere lijst. Daarna worden voor alle resterende opties de indices opgeteld, de optie met de kleinste som wordt teruggegeven als beslissing. Figuur 5.8 laat een dergelijke onderhandeling zien. In stap 1 worden choice1, choice3 en choice5 geschrapt als mogelijke beslissing. De keuze tussen choice2 en choice4 gebeurt op basis van de graad van voorkeur die de gateways aan deze keuzes hebben gegeven. Alhoewel gateway 2 choice4 als absolute voorkeur heeft opgegeven, zal toch choice2 gekozen worden aangezien die keuze het best mogelijke compromis is.
Figuur 5.8: Voorbeeld van een standaardonderhandeling
5.3
ConfigurationManager
Figuur 5.9 toont alle klassen gebruikt voor de implementatie van de module ConfigurationManager. Nadat de onderhandeling heeft plaatsgevonden, moet de onderhandelde informatie ergens bijgehouden worden. Hiervoor zijn verschillende mogelijkheden. De Negotiator kan alle bundles afzonderlijk op de hoogte brengen of de informatie kan centraal opgeslagen worden. Dit laatste is precies waarvoor de ConfigurationManager in het leven geroepen is. Buiten verbindingsspecifieke informatie houdt de ConfigurationManager eveneens informatie bij die van toepassing is voor het lokale systeem, zoals een lijst van gateways waarmee een verbinding mag gemaakt worden en
5.4 AddressTranslation
48
Figuur 5.9: Klassendiagram van relevante klassen voor de bundle ConfigurationManager
certificaten van de lokale gateway. De lijst van vertrouwde gateways wordt bij het afsluiten van de bundle persistent opgeslagen zodat het falen van de ConfigurationManager niet tot gevolg heeft dat de configuratie verloren gaat. Om de verbindingsspecifieke informatie consistent te houden, worden er twee functies voorzien om verbindingen in het systeem te onderhouden. E´en om een verbinding aan te maken in het systeem en ´e´en om een verbinding uit het systeem te verwijderen.
5.4
AddressTranslation
Figuur 5.10 toont een overzicht van de belangrijkste klassen in de bundle AddressTranslation.
5.4 AddressTranslation
49
Figuur 5.10: Klassendiagram van relevante klassen voor de bundle AddressTranslation
5.4.1
AddressTranslationConfig
Om informatie over een bepaalde adresvertaling op te slaan, wordt gebruik gemaakt van klassen die de interface AddressTranslationConfig implementeren. In deze interface zijn methoden voorzien om de adresvertaling in te stellen en te herstellen. Verder omvat hij methoden om de gebruikte subnetwerken te verkrijgen voor de lokale virtuele IP-adressen, de remote virtuele IP-adressen en de IP-adressen voor de tunnel. Twee dergelijke klassen werden ge¨ımplementeerd: NoneAddressTranslationConfig en StaticRemappingAddressTranslationConfig. NoneAddressTranslationConfig voert geen adresvertaling uit en houdt dus enkel de informatie bij over de gebruikte subnetwerken. StaticRemappingAddressTranslationConfig voert een statische remapping van IP-adressen uit. Hierbij wordt een subnetwerk volledig afgebeeld op een nieuw subnetwerk, op volgende wijze: de offset van het (oude) IP-adres (bv. 192.168.0.20) binnen het (oude) subnetwerk (bv. 192.168.0.0/24) wordt opgeteld bij het nieuwe subnetwerk (bv. 10.0.0.0/24). Op deze manier wordt een nieuw IP-adres bekomen (in het voorbeeld 10.0.0.20), dat binnen het nieuwe subnet-
5.4 AddressTranslation
50
werk ligt. Deze functionaliteit wordt bekomen door gebruik te maken van de tool iptables en is dus enkel beschikbaar op linux-gateways. Er worden om de adresvertaling te starten twee regels toegevoegd aan de “nat”-tabel van iptables: iptables -t nat -A PREROUTING -d lokaal_virtueel_subnetwerk -j NETMAP --to lokaal_fysiek_subnetwerk iptables -t nat -A POSTROUTING -d remote_virtueel_subnetwerk -s lokaal_fysiek_subnetwerk -j NETMAP --to lokaal_virtueel_subnetwerk Deze commando’s worden uitgevoerd vanuit Java in een nieuw extern proces. Het eerste commando zal ervoor zorgen dat het doeladres van IP-pakketten gericht aan het lokale virtuele netwerk, vertaald zal worden naar het correcte fysieke IP-adres uit het lokale virtuele netwerk. Aangezien deze regel aan de PREROUTING chain wordt toegevoegd, wil dit zeggen dat deze pakketten naar het lokale netwerk gerouteerd worden (zoals verwacht). Het tweede commando neemt pakketten die afkomstig zijn van het lokale netwerk en bestemd zijn voor het remote virtuele netwerk en vertaalt hun bronadres naar het correcte virtuele adres uit het virtuele lokale subnetwerk. In figuur 5.11 wordt een voorbeeld gegeven van statische remapping met als lokaal fysiek subnetwerk 192.168.0.0/24, lokaal virtueel subnetwerk 192.168.1.0/24, en remote virtueel subnetwerk 192.168.2.0/24. De iptables commando’s zijn in dit geval: iptables -t nat -A PREROUTING -d 192.168.1.0/24 -j NETMAP --to 192.168.0.0/24 iptables -t nat -A POSTROUTING -d 192.168.2.0/24 -s 192.168.0.0/24 -j NETMAP --to 192.168.1.0/24
5.4.2
NegotiatorListener methodes
AddressTranslationImpl implementeert ook de interface NegotiatorListener. Bij het opstarten van de bundle wordt een AddressTranslationImpl-object geregistreerd bij de Negotiator-service voor de parameters: “addressTranslationMethods”, “localRange”, “remoteRange”, “tunnelRange” en “physicalRange”.
5.4 AddressTranslation
51
Figuur 5.11: Voorbeeld van adresvertaling met statische remapping
De betekenis van de parameters is als volgt: addressTranslationMethods de adresvertalingsmethodes die ondersteund worden (“none” en “static-remapping” zijn gedefinieerd) physicalRange het lokale, fysieke subnet van de gateway localRange de virtuele subnetten die gebruikt kunnen worden om het lokale netwerk te adresseren vanaf de andere gateway remoteRange de virtuele subnetten die gebruikt kunnen worden om het remote netwerk te adresseren vanaf de lokale gateway tunnelRange de virtuele subnetten die gebruikt kunnen worden voor de eindpunten van de tunnel (met andere woorden de IP-adressen voor de virtuele tun-netwerkinterfaces op beide gateways) Bij het opstarten van de bundle zal nagegaan worden wat het fysieke subnet is van het lokale netwerk. Aangezien dit onmogelijk te bepalen is met de bestaande Java-API, wordt hiervoor gebruik gemaakt van jNetDev (zie [31]), een open source Java class library voor low level pakketmanipulatie, die ook deze functionaliteit aanbiedt.
5.4 AddressTranslation
52
Wanneer een nieuwe VPN-verbinding aangemaakt wordt op de lokale gateway, zal getParameters() opgeroepen worden. De bundle zal dan nagaan welke adresvertalingsmethodes mogelijk zijn op de gateway (in de huidige implementatie is dit “none” en “static-remapping” voor een linuxgateway, “none” voor een Windowsgateway). Voor de parameter physicalRange wordt het eerder bepaalde fysieke subnet meegegeven. De waarde voor de parameters localRange, remoteRange en tunnelRange is dezelfde: de verzameling private subnetwerken die niet overlappen met het fysieke lokale subnet en niet overlappen met subnetten die reeds gebruikt worden als virtueel subnet bij andere verbindingen. Het algoritme om deze verzameling te bepalen kan in pseudocode beschreven worden: result := lege lijst taken := lijst van subnetwerken die reeds in gebruik zijn subnetwork := subnetwerk 192.168.0.0/16 method addBiggestFreeRanges(subnetwork) { if (grootte subnetwork < 4) // onbruikbaar return if (overlap met een subnetwerk uit taken) splits subnetwork in 2 gelijke delen: s1 en s2 addBiggestFreeRanges(s1) addBiggestFreeRanges(s2) else voeg subnetwork toe aan result } Dit algoritme wordt toegepast voor de 3 subnetwerken die gereserveerd zijn voor privaat gebruik (192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12). Wanneer een nieuwe VPN-verbinding wordt opgezet door een andere gateway, zal negotiateParameters() opgeroepen worden. De bundle zal dan eerst nagaan welke adresvertalingsmethode gebruikt moet worden. Indien het fysieke subnetwerk van de remote gateway (in parameter “physicalRange”) niet overlapt met het lokale fysieke subnetwerk of met een virtueel subnetwerk voor een andere verbinding en het lokale fysieke subnetwerk deel uitmaakt van de verzameling subnetwerken in “remoteRange”, dan kan de verbinding opgezet worden zonder adresvertaling. Indien dit niet het geval is, wordt bekeken of beide gateways adresvertaling ondersteunen.
5.5 VPNInterface
53
Als dit niet zo is, zal de onderhandeling falen. Als dit wel zo is, wordt nagegaan of er compatibele virtuele subnetwerken gevonden kunnen worden. Drie subnetwerken moeten gevonden worden: • een subnetwerk voor het virtuele subnetwerk van de lokale gateway dat compatibel is met de remoteRange parameter van de andere gateway en bovendien nog niet gebruikt wordt op de eigen gateway • een subnetwerk voor het virtuele subnetwerk van de remote gateway dat compatibel is met de localRange parameter van de andere gateway en nog niet gebruikt wordt op de eigen gateway • een subnetwerk voor de tunnel, compatibel met de tunnelRange parameter en de eigen vrije subnetwerken. De methode negotiatedParameters() wordt opgeroepen indien het antwoord van de remote gateway ontvangen is. De bundle zal, op basis van de parameters die de remote gateway gekozen heeft, een AddressTranslationConfig aanmaken en zal dit opslaan in de ConfigurationManager. Figuur 5.12 toont een voorbeeld van een negotiatie, waarbij beide gateways hetzelfde lokaal fysiek netwerk hebben: 192.168.0.0/16.
Figuur 5.12: Voorbeeld van een onderhandeling
5.5
VPNInterface
Figuur 5.13 toont een overzicht van de belangrijkste klassen in de bundle VPNInterface.
5.5 VPNInterface
54
Figuur 5.13: Klassendiagram van relevante klassen voor de bundle VPNInterface
5.5.1
Bundle startup
Bij het opstarten van de bundle wordt de OpenVPN-binary ge¨ınstalleerd op de gateway, meer bepaald in de “bundle storage area”. Dit is een directory op de gateway waar de bundle volgens de OSGi-specificaties bestanden kan opslaan die persistent moeten zijn. Er zal eerst gekeken worden of er reeds een OpenVPN-binary ge¨ınstalleerd is in deze bundle storage area. Indien dit niet het geval is, wordt nagegaan wat het besturingssysteem en de processor van de gateway zijn. Op basis van deze informatie wordt de juiste binary vanuit de JAR gekopieerd naar de bundle storage area. Ook de private key en het certificaat, nodig voor het opzetten van VPNverbindingen, worden in dat geval gekopieerd naar de bundle storage area.
5.5.2
VPNImpl
Wanneer startVPN() opgeroepen wordt, worden de volgende acties ondernomen:
5.6 AutoVPNInterface
55
• Er wordt nagegaan of er nog een vrij tun-device is en indien dit zo is, wordt de naam hiervan (tun0, tun1, ...) meegegeven als parameter aan de daemon • De OpenVPN-daemon kan ingesteld worden om zelf routering in te stellen nadat een VPN-verbinding succesvol aangemaakt is. De bundle vraagt daarom bij de ConfigurationManager de AddressTranslationConfig voor deze verbinding op. Hieruit wordt de virtuele remote range gehaald (bij een NoneAddressTranslationConfig is dit gewoon de fysieke remote range) en deze wordt dan als parameter meegegeven voor de OpenVPN-daemon. • Uit de AddressTranslationConfig wordt ook de tunnelrange gehaald. Uit deze range worden de IP-adressen gekozen voor de tun-devices. De initi¨erende gateway kiest het eerste IPadres uit het netwerk, de gecontacteerde gateway kiest het tweede IP-adres. • Verder kiest de bundle ook nog een vrije poort om de management interface op te laten luisteren. Deze management interface zal gebruikt worden om statusinformatie te verkrijgen van de OpenVPN-daemon. • Ten slotte wordt de OpenVPN-daemon opgestart met al deze parameters. Het resulterende Java-Process wordt bijgehouden om het bij het stopzetten van de verbinding, af te kunnen sluiten. Om het einde van een VPN-verbinding te detecteren, is gebruik gemaakt van een keep-alive systeem. In een actieve verbinding wordt door beide gateways elke 10 seconden een “ping” doorgestuurd naar de andere gateway. Als ´e´en van de gateways 60 seconden lang geen “ping” ontvangt, besluit deze dat de verbinding is afgebroken en sluit de daemon af. Dit wordt gedetecteerd door VPNImpl, die hierop de AutoVPNInterface oproept om de verbinding volledig stop te zetten. Wanneer stopVPN() opgeroepen wordt, wordt de OpenVPN-daemon afgesloten (het is niet nodig om nog een controleboodschap naar de andere gateway te sturen; deze zal het be¨eindigen van de VPN-verbinding detecteren via het keep-alive-mechanisme). Door het afsluiten van de daemon wordt ook de routering weer hersteld.
5.6
AutoVPNInterface
Figuur 5.14 toont alle klassen die gebruikt werden om de AutoVPNInterface te implementeren. Dit is enkel de klasse AutoVPNInterfaceImpl die de drie functies gespecifieerd in de interface
5.7 WebInterface
56
Figuur 5.14: Klassendiagram van relevante klassen voor de bundle AutoVPNInterface
jason.interfaces.AutoVPNInterface implementeert. Het openen van een verbinding wordt ge¨ıllustreerd in figuur 5.15. De naam van de gateway waarmee verbinding dient gemaakt te worden wordt voorgeschoteld aan de GNS, die het IPadres van de gateway teruggeeft. Op basis van deze informatie kan de onderhandeling tussen de twee gateways van start gaan (zie 5.2.2). Als deze onderhandeling faalt, wordt de verbinding afgebroken. Is de onderhandeling gelukt, dan zal de informatie nodig om de volgende stappen tot een goed einde te brengen, opgeslagen zijn in de ConfigurationManager. Vervolgens wordt de effectieve verbinding en adresvertaling opgezet. Aan de serverkant (gateway die een aanvraag voor een onderhandeling krijgt) gebeurt dit nadat een ACK is ontvangen van de gateway die de onderhandeling begonnen is. Het afsluiten van een verbinding gaat als volgt: eerst wordt de adresvertaling teruggedraaid, daarna wordt de VPN-verbinding gesloten en als laatste wordt alle verbindingsspecifieke informatie die is opgeslagen, verwijderd. Dit wordt weergegeven in figuur 5.16
5.7
WebInterface
Voor de implementatie van de webinterface is gekozen voor het gebruik van servlets aangezien hier een raamwerk voor beschikbaar werd gesteld. Er werden twee verschillende servlets gemaakt, ´e´en die de gewone eindgebruiker zal gebruiken en ´e´en voor de netwerkbeheerder. Dit wordt grafisch voorgesteld in figuur 5.17.
5.7 WebInterface
57
Figuur 5.15: Openen verbinding met behulp van AutoVPNInterface
HelperServlet De superklasse van alle servlets in dit systeem is HelperServlet. Hierin worden alle acties ondernomen die nodig zijn om een werkend geheel te krijgen, maar de eigenlijke inhoud wordt overgelaten aan de klassen die overerven van deze superklasse. De eigenlijke business logic bevindt zich dus in respectievelijk VPNServlet en JasonAdminServlet.
VPNServlet De functionaliteit die een gewone eindgebruiker mag gebruiken, is bij deze servlet ondergebracht. Er kan een onderscheid gemaakt worden tussen twee soorten acties. Enerzijds kan er een verbinding opgezet worden met een gateway die vooraf door een netwerkbeheerder als vertrouwd is bestempeld. Anderzijds kunnen er veranderingen gebracht worden aan een reeds opgezette verbinding. Op dit moment is bijvoorbeeld het sluiten van een verbinding en het registreren van een client voor die verbinding ge¨ımplementeerd. Registratie door een eindgebruiker van zijn machine zorgt ervoor dat zijn machine kan worden bereikt via een door hem gekozen naam (zie 5.8).
5.8 GNS
58
Figuur 5.16: Sluiten verbinding met behulp van AutoVPNInterface
JasonAdminServlet De netwerkbeheerder moet in staat zijn de lokale configuratie van het systeem te veranderen. Dit kan hij doen via deze servlet. Omdat enkel de netwerkbeheerder toegang mag hebben tot deze servlet, is er een basisauthenticatie ge¨ımplementeerd. Via deze servlet kan de netwerkbeheerder op dit moment gateways toevoegen en verwijderen uit de lijst van vertrouwde gateways.
5.8
GNS
De bundle GNS wordt voor twee doeleinden gebruikt in het systeem: bij het opstarten van het systeem registreert de GNS een relatie (naam van de gateway, publieke IP-adres van de gateway) bij de GNS-Server, zodat de gateway op naam kan opgezocht worden door andere gateways. Voor bestaande verbindingen wordt de GNS ook gebruikt om relaties tussen hosts op het lokale netwerk en hun virtuele IP-adressen voor die verbinding te registeren bij de GNS-Server, zodat deze op naam kunnen opgezocht worden door hosts uit het remote netwerk. Figuur 5.18 toont een overzicht van de belangrijkste klassen in de bundle GNS.
5.8 GNS
59
Figuur 5.17: Klassendiagram van relevante klassen voor de bundle WebInterface
Figuur 5.18: Klassendiagram van relevante klassen voor de bundlee GNS
5.8.1
Protocol GNS
Het protocol dat gebruikt wordt om deze relaties te registreren is zeer eenvoudig. De gateway maakt een SSL-verbinding aan met de GNS-Server, op poort 4000. Zowel de gateway als de GNS-Server gaan na of de certificaten die uitgewisseld worden ondertekend zijn door de CA. De GNS stuurt dan over deze verbinding de volgend informatie: IP-adres naam De naam kan de gatewaynaam zelf zijn (voor het registreren van een gateway), of kan een string zijn van de vorm host.gatewaynaam (voor het registreren van het virtuele IP-adres van
5.9 GNSServer
60
een host uit het lokale netwerk). De GNS-Server zal nagaan of de gatewaynaam overeenkomt met de naam van het certificaat.
5.8.2
Bundle startup
Bij het opstarten van de bundle wordt een GNSUpdateThread opgestart. Deze thread zal het publieke IP-adres van de gateway opvragen en dit IP-adres bij de GNS-Server registeren. Daarna zal hij om de 60 seconden nagaan of het publieke IP-adres van de gateway veranderd is en indien nodig het IP-adres opnieuw registreren.
5.9
2
GNSServer
De module GNSServer is ge¨ımplementeerd als een standaard Java-applicatie, bestaande uit ´e´en klasse, GNSServer. Verder wordt er gebruik gemaakt van het open source programma BIND.
5.9.1
BIND
Voor het opvragen van IP-adressen wordt gebruik gemaakt van DNS. Dit systeem is welbekend en transparant te gebruiken vanuit Java. Voor het registreren van een relatie wordt gebruik gemaakt van het protocol dat beschreven wordt in sectie 5.8.1. Voor het DNS-gedeelte wordt gebruik gemaakt van het open source programma BIND. Het programma is geconfigureerd zodat het verantwoordelijk is voor het domein “jason.org”. Het is dit programma dat de DNS-query’s zal resolven. Het is ook ingesteld om dynamische updates toe te laten in dit domein.
5.9.2
GNSServer
De klasse GNSServer bevat een main()-methode die wacht op SSL-connecties op poort 4000. Indien een connectie opgezet wordt, wordt nagekeken of het certificaat van de andere partij ondertekend is door de CA. Daarna wordt het IP-adres en de naam (vastgelegd in het protocol) opgeslagen. De naam wordt vergeleken met de naam van het certificaat. Indien alles in orde is, wordt met de tool nsupdate (deel van de BIND-suite) de relatie toegevoegd aan het domein jason.org. Voor een gatewaynaam betekent dit dat er een relatie 2
Een wijziging van het IP-adres van de gateway heeft geen invloed op bestaande VPN-connecties. OpenVPN
kan ingesteld worden om ook pakketten te aanvaarden met een onverwacht bronadres, zolang ze geauthenticeerd zijn.
5.9 GNSServer
61
(gatewaynaam.jason.org, IP-adres) toegevoegd is; voor een hostnaam betekent dit een relatie (hostnaam.gatewaynaam.jason.org, IP-adres).
TESTS EN RESULTATEN
62
Hoofdstuk 6
Tests en resultaten 6.1
Testopstelling
Om het systeem te testen zijn er twee testopstellingen opgezet. E´en testopstelling bevindt zich in de gecontroleerde omgeving van de universiteit en bestaat uit twee computers die dienstdoen als gateways, ´e´en computer die dienstdoet als GNS-server, ´e´en computer die wordt gebruikt als client en een switch. Als besturingssysteem staat er op de gateways en GNS-server Debian, op de client staat een dual boot van Debian en Windows. Wanneer nodig werden laptops gereserveerd om dienst te doen als extra clients. Alle gebruikte machines zijn voorzien van een 10/100Mbps-NIC. Deze testopstelling is schematisch weergegeven in figuur 6.1.
Figuur 6.1: Testopstelling in gecontroleerde omgeving.
6.2 Throughput
63
De tweede testopstelling bevindt zich in een meer realistische omgeving. Twee computers die met een breedbandaansluiting verbonden zijn met het internet doen hier dienst als gateways/clients. Figuur 6.2 toont deze testopstelling schematisch.
Figuur 6.2: Testopstelling in realistische omgeving.
6.2
Throughput
Bij deze test werd een bestand via het HTTP-protocol verstuurd van de ene client naar de andere. Op de gateways werd het verkeer onderschept (aan de onge¨encrypteerde kant) met behulp van tcpdump. Dit verkeer werd dan later geanalyseerd met Ethereal. Deze aanpak werd gekozen omdat het een realistische use-case voorstelt en omdat het TCP-protocol (gebruikt door HTTP), in het geval van ´e´en verbinding, de maximale bandbreedte zal proberen te benutten. Verwacht wordt dat door de tunneling een lagere throughput kan bereikt worden: enerzijds door de overhead van het OpenVPN-protocol, anderzijds doordat OpenVPN de pakketten niet snel genoeg kan encrypteren of decrypteren, waardoor er pakketten gedropt zullen moeten worden op de gateways. Er treedt geen extra overhead op door IP-fragmentatie. Dit zou wel kunnen voorkomen indien de extra headers ervoor zorgen dat de IP-pakketten groter zouden worden dan de Maximum Transmission Unit (MTU) voor de netwerkinterface. OpenVPN voorkomt dit probleem echter door in de SYN- en SYN/ACK-pakketten die verstuurd worden bij het opzetten van de TCPverbinding, de optie Maximum Segment Size (MSS) te verlagen, zodat rekening wordt gehouden met de OpenVPN-headers. Uit de beschrijving van het OpenVPN-protocol in sectie 4.2.3 kan berekend worden wat de overhead is die ge¨ıntroduceerd wordt door het gebruik van OpenVPN. In beide opstellingen werd gebruik gemaakt van Blowfish-encryptie in Cipher Block Chaining (CBC) modus. Aangezien Blowfish werkt in blokken van 8 bytes, kan berekend worden dat de totale overhead van OpenVPN-headers 69 tot 76 bytes is (er kunnen tot 7 bytes padding nodig zijn).
6.3 Delay
64
Tabel 6.1 geeft een overzicht van de gemiddelde throughput in het geval het systeem niet gebruikt wordt, in het geval enkel een VPN-verbinding is opgezet en in het geval zowel een VPN-verbinding als adresvertaling actief zijn.
Tabel 6.1: Throughput
zonder
VPN
VPN + adresvertaling
lab
58,521 Mbps
19,305 Mbps
20,735 Mbps
thuis
472,376 kbps
457,288 kbps
456,560 kbps
In de testopstelling in het lab is duidelijk een serieuze vermindering in throughput merkbaar. De bottleneck is hier duidelijk de processorkracht van de gateways: deze zijn niet in staat de pakketten tijdig te encrypteren en decrypteren. In de thuistestopstelling is de vermindering in throughput veel kleiner: er is slechts een vermindering van ongeveer 3% bij de gevallen met VPN. Doordat de ISP’s de uploadbandbreedte laag houden, is er minder processorkracht nodig en wordt de overhead enkel veroorzaakt door de OpenVPN-headers. Figuren 6.3 en 6.4 geven ten slotte de throughput weer als functie van de tijd. In de testopstelling in het lab zijn op een paar punten dipjes te zien: deze komen overeen met een sleutelonderhandeling door het OpenVPN-protocol (deze sleutelonderhandeling werd ingesteld om om de 60 seconden op te treden).
6.3
Delay
Voor het berekenen van de delay werd gebruik gemaakt van de tool ping, die de roundtrip-time (RTT) meet tussen twee toestellen, gebruik makende van ICMP echo-requests. Tabel 6.2 toont de RTT’s (in ms) gemeten in de testopstelling in het lab (uitgemiddeld over 20 “ping”’s):
Tabel 6.2: RTT (in ms) bij de testopstelling in het lab
zonder
VPN
VPN + Adresvertaling
0,3
0,8
0,8
6.3 Delay
65
(a) Throughput zonder systeem
(b) Throughput met VPN
(c) Throughput met VPN en adresvertaling Figuur 6.3: Throughput bij de testopstelling in het lab (in bytes/s)
Uit deze tabel blijkt dat de RTT met 0.5 ms verhoogd wordt indien de VPN gebruikt wordt. De RTT verhoogt echter niet indien ook adresvertaling gebruikt wordt. Dit ligt in de lijn van verwachtingen: de encryptie die de VPN uitvoert is processorintensief en zorgt dus voor vertraging. De adresvertaling is relatief eenvoudig en wordt in de kernel uitgevoerd; de extra vertraging die hierdoor optreedt is relatief klein. Tabel 6.3 geeft de resultaten met de thuistestopstelling weer. Uit deze tabel zou men kunnen afleiden dat de vertraging ge¨ıntroduceerd door de VPN veel groter is dan in het lab, alhoewel ze werd uitgevoerd door PC’s met meer rekenkracht. Er bleken echter grote uitschieters te zitten in de metingen, waarna ook de standaardafwijking op de metingen is berekend. Aangezien de standaardafwijking zo groot is, is het moeilijk om uitspraken te doen over de vertraging in dit geval. Waarschijnlijk is het zo dat de tussenliggende
6.4 Pakketverlies
66
(a) Throughput zonder systeem
(b) Throughput met VPN
(c) Throughput met VPN en adresvertaling Figuur 6.4: Throughput bij de thuistestopstelling (in bytes/s)
Tabel 6.3: RTT (in ms) bij de thuistestopstelling
zonder
VPN
VPN + Adresvertaling
meetwaarde
21,379
24,714
25,610
standaardafwijking
3,191
2,351
4,212
routers verschillende prioriteiten geven aan ICMP- en UDP-pakketten.
6.4
Pakketverlies
Om het pakketverlies dat mogelijkerwijze optreedt te meten, werd gebruikt gemaakt van IPerf (zie [32]). Allereerst werden er tests gedaan met de testopstelling in het lab. Er werden twee clients gebruikt voor deze tests, ´e´en die dienstdeed als IPerf-server om verbindingen aan te nemen en een andere als IPerf-client. Beide clients bevinden zich logischerwijze in het netwerk van een verschillende gateway zoals weergegeven in figuur 6.5. Voor deze tests werd een UDP-stroom van een opgegeven bandbreedte verstuurd van client
6.4 Pakketverlies
67
Figuur 6.5: Testopstelling voor meten pakketverlies
naar server. Elk van de UDP-pakketten bevatte 1470 bytes data. Zonder VPN-verbinding of adresvertaling is er nooit pakketverlies op de gateways, zelfs als we meer dan 100 Mbps proberen te versturen. Indien we de test uitvoeren met dezelfde machine zoals gebruikt bij de tests in 6.2 wordt een stroom van 75Mbps verstuurd. Testen we echter met een andere machine, wordt een snelheid van 93Mbps gehaald. Dit laat vermoeden dat een 100Mbps-NIC niet altijd exact 100Mbps aankan, alle pakketten die verstuurd worden komen ook effectief aan, maar de netwerkkaart kan niet snel genoeg pakketten versturen om de gewenste throughput te halen. Wanneer een VPN-verbinding tussen de gateways is opgezet, begint er reeds pakketverlies op te treden vanaf een pakketstroom van 33Mbps. Dit is waarschijnlijk het gevolg van het droppen van pakketten omdat de netwerkbuffer niet snel genoeg kan verwerkt worden door de vertraging die de berekeningen van OpenVPN met zich meebrengen. Wanneer naast de VPN-verbinding gebruik gemaakt wordt van adresvertaling treedt er eveneens pakketverlies op vanaf een stroom van 33 Mbps. Adresvertaling blijkt dus geen invloed te hebben op het percentage pakketverlies. De introductie van pakketverlies vanaf 33Mbps kan op zijn minst ongewenst worden genoemd, maar om te testen of dit invloed heeft op de werking van het systeem in een realistische omgeving (een symmetrische upload/downloadbeperking van 100 Mbps is allesbehalve realistisch te noemen voor thuisgebruik) werden de tests opnieuw gedaan op de testopstelling zoals getoond in figuur 6.2. De machine waarop de IPerf-client draait, is verbonden met het internet door een ADSL-verbinding met een uploadbeperking van 512 Kbps. Figuur 6.6 toont de resultaten met gebruik van UDP-pakketten met een payload van 1470 bytes. Zonder VPN-verbinding treedt er bij kleine bandbreedte geen pakketverlies op. Wanneer de uploadbeperking van 512 kbps naderbij komt, begint er pakketverlies op te treden, meer bepaald vanaf ongeveer 400 kbps.
6.4 Pakketverlies
68
Figuur 6.6: Pakketverlies bij gebruik van UDP-datagrammen van 1470 bytes
Het percentage pakketverlies dat optreedt wanneer er een VPN-verbinding tussen beide machines is opgezet is merkbaar hoger. Het is zelfs zo dat zelfs bij kleine bandbreedtes pakketverlies optreedt. Vermoedelijk is dit het geval omdat door de overhead die OpenVPN introduceert, de UDP-pakketten gefragmenteerd raken, waardoor er meer kans is dat een pakket verloren raakt. Dit kan eevnwel niet de enige oorzaak zijn, vermoedelijk worden op het internet gefragmenteerde (UDP-)pakketten behandeld met een lagere prioriteit. Adresvertaling blijkt ook in de realistische omgeving nauwelijks effect te hebben.
Figuur 6.7: Vergelijking pakketverlies tussen situatie met UDP-datagrammen van 1470 bytes ten opzichte van UDP-datagrammen van 1000 bytes
6.5 Jitter
69
Om te testen of de fragmentatie van de UDP-pakketten tot effect heeft dat er altijd pakketten verloren gaan, werden bijkomende tests uitgevoerd met UDP-pakketten met een payload van 1000 bytes. Hierdoor zullen de pakketten niet gefragmenteerd worden. Anderzijds is het wel zo dat om dezelfde bandbreedte te halen er meer pakketten zullen moeten verstuurd worden. In figuur 6.7 worden de resultaten van beide tests naast elkaar gezet. Het is duidelijk dat de fragmentatie een grote rol speelt in het al dan niet optreden van pakketverlies. Wanneer er geen fragmentatie optreedt, is er tot ongeveer 350 kbps geen pakketverlies en wordt het percentage pakketverlies bij hogere bandbreedtes zo goed als gehalveerd. Zolang applicaties die UDP gebruiken hun pakketten niet volledig vullen, zal die applicatie dus geen hinder ondervinden van pakketverlies. Wanneer een applicatie volle UDP-pakketten verstuurt, zal de verbinding niet geheel transparant zijn, er treedt namelijk sowieso pakketverlies op terwijl dit niet zo is zonder deze verbinding.
6.5
Jitter
Voor sommige applicaties kan het verschil in doorzendtijden tussen opeenvolgende pakketten, genaamd jitter, een belangrijke invloed hebben. Denk hierbij bijvoorbeeld aan een videostroom. Om te testen of het systeem een invloed heeft op de jitter werden voor verschillende gevallen metingen gedaan met behulp van IPerf. Er werden enkel resultaten gemeten voor die bandbreedtes waarvoor in alle gevallen een aanvaardbaar percentage pakketverlies optreedt. Wanneer er te veel pakketverlies optreedt, zal die voor de besproken applicaties grotere gevolgen hebben dan jitter. Een andere reden waarom enkel voor zulke bandbreedtes jitter werd gemeten, zijn de onbetrouwbare resultaten die IPerf oplevert voor jitter wanneer er pakketverlies optreedt. Het verschil tussen de doorzendtijden van twee opeenvolgende pakketten kan niet exact berekend worden als ´e´en van deze pakketten verloren gaat. IPerf meet de jitter zoals gespecifieerd in de RFC voor het Real-time Transport Protocol (RTP: zie [33]). Voor elk pakket wordt de doorzendtijd berekend als het verschil tussen de RTP-timestamp van het pakket (ingevuld door de client) en de aankomsttijd op de server. De jitter wordt dan berekend als het gemiddelde van de verschillen in doorzendtijden van opeenvolgende pakketten. Er wordt echter niet gesproken over wat er gebeurt wanneer pakketten verloren gaan. De resultaten worden grafisch weergegeven in figuur 6.8. Er zit geen duidelijke lijn in de meetwaarden: jitter gemeten bij de rechtstreekse verbinding is niet consequent minder dan in het geval er enige vorm van VPN is opgezet. Het is zelfs zo dat voor een bandbreedte van 350
6.5 Jitter
70
Figuur 6.8: Jitter
kbps bij de rechtstreekse verbinding een jitter gemeten wordt die tot vijfmaal zo hoog is als bij de gevallen met VPN. Binnen de gevallen waarbij een VPN-verbinding opgezet is, valt er evenmin een logica te vinden. Bij 100 kbps met adresvertaling is de jitter ongeveer dubbel zo groot als zonder adresvertaling, maar voor 200 kbps is dit dan weer minder dan een vierde. De enige conclusie die kan genomen worden is dat het tussenliggende netwerk meer invloed heeft op de aanwezige jitter dan de situatie op de gateways.
CONCLUSIE
71
Hoofdstuk 7
Conclusie In deze thesis werd een specificatie opgesteld voor een syteem dat een VPN kan opzetten tussen twee netwerken, eenvoudig te gebruiken is voor de eindgebruiker, transparant is en eenvoudigig installeerbaar is op een “intelligente gateway”. Het voorgestelde systeem voldoet aan alle eisen die vooropgesteld werden. Het is eenvoudig te gebruiken door de eindgebruiker: deze hoeft enkel de naam te kennen van de gateway waarmee hij een VPN wil opzetten. Om hosts op het remote netwerk te kunnen contacteren hoeft hij enkel de naam waaronder de gebruiker zijn machine geregistreerd heeft te kennen. Deze naam kan eenvoudig gekozen worden door de gebruiker van de host, het instellen ervan gebeurt via de webinterface van de lokale gateway. Het gebruik van OSGi biedt mogelijkheden voor remote management en een eenvoudige deployment door Service Providers. Het systeem is transparant voor de eindgebruikers: in het site-to-site geval hoeft geen software ge¨ınstalleerd te worden op de clients en worden bestaande verbindingen niet gehinderd. Bovendien worden problemen met overlappende subnetwerken afgehandeld zonder dat tussenkomst van de gebruiker nodig is. In onze implementatie is deze functionaliteit beperkt tot linuxplatformen en is er ook maar ´e´en soort adresseringsstrategie aanwezig (statische remapping), maar deze proof-of-concept toont aan dat het zeker mogelijk is om dit uit te breiden naar andere platformen (en andere adresseringsstrategie¨en). Uit de testresultaten blijkt dat het gebruik van het systeem, bij een realistische situatie voor thuisgebruikers, slechts een kleine impact heeft op throughput, delay, pakketverlies en jitter. Bij een situatie met links met hoge bandbreedte heeft het systeem wel een grote impact op de throughput. Aangezien dit probleem afhankelijk is van de processorsnelheid, kan verwacht
7.1 Verder onderzoek
72
worden dat dit verbetert naarmate processoren sneller worden.
7.1
Verder onderzoek
7.1.1
DNS op de gateway
In de huidige architectuur worden de afbeeldingen van clientnamen op (virtuele) IP-adressen bijgehouden door de GNS-server. De afbeeldingen voor een bepaalde clientnaam worden echter enkel gebruikt in de netwerken waarmee deze client een VPN-verbinding mee heeft. Een alternatief zou zijn om deze functionaliteit van de GNS-server op de gateway zelf te plaatsen. De gateway moet dan ingesteld zijn als standaard DNS-server op de clients en er moet een (eenvoudige) DNS-service draaien op de gateway. Bovendien moet hij ook de relaties zelf bijhouden, in plaats van deze door te sturen naar de GNS. De gateway kan dan de binnenkomende DNS-lookups als volgt afhandelen: indien het gaat om een hostnaam van het eigen netwerk, antwoordt hij met het virtuele IP-adres van de client; indien het gaat om een hostname van een netwerk waarmee een VPN is opgezet, stuurt hij de request door naar de gateway van het andere netwerk; in alle andere gevallen naar een andere, standaard DNS-server. Op deze manier wordt de GNS enkel nog gebruikt om de afbeeldingen van gatewaynamen op IP-adressen bij te houden en zijn de gateways verantwoordelijk voor de DNS-requests van clientnamen.
7.1.2
Broadcasts over de tunnel
Verder onderzoek is nodig naar de mogelijkheid om broadcasts over een opgezette tunnel te sturen. Op deze manier zouden programma’s die gebruik maken van broadcasts (bijvoorbeeld Windows bestandsdeling) de toestellen in het andere netwerk kunnen aanspreken als zaten ze op hetzelfde netwerk. Als eerste oplossing werd gebruik gemaakt van adresvertaling (op linux) van de gebroadcaste pakketten, net zoals bij gewone IP-adressen indien er overlappende netwerken zijn. Het blijkt echter dat de linuxkernel broadcastpakketten dropt indien ze niet op de interface van het juiste netwerk binnenkomen. Een kernelpatch zou dit kunnen verhelpen, maar het is niet echt mogelijk om dit te doen vanuit het OSGi-framework. Een andere oplossing zou zijn om de OpenVPN-daemon te laten opereren in bridgemode (zoals besproken in sectie 4.3.1). In dit geval gedraagt de tunnel zich als een bridge en zullen broadcasts wel over de tunnel geraken. De besproken nadelen van deze methode blijven echter bestaan. Eventueel zou de keuze aan de eindgebruiker kunnen gelaten worden.
7.1 Verder onderzoek
7.1.3
73
Hostnamen op het virtuele netwerk
In het besproken ontwerp worden machines geregistreerd bij het systeem aan de hand van een naam. Deze naam wordt gekozen door een gebruiker in het lokale netwerk. Gebruikers op netwerken die verbonden zijn met het netwerk waar deze machine zich op bevindt, willen deze machine kunnen bereiken. Hiervoor moet de gebruiker de naam via een ander kanaal te weten komen. Nu is het echter zo dat de relaties tussen namen en virtuele IP-adressen gekend zijn bij het systeem. Het zou dus mogelijk zijn om een gebruiker in een bepaald netwerk de namen van de machines in de netwerken waarmee men verbonden is, voor te schotelen. Dit zou een belangrijke bijdrage betekenen voor de gebruiksvriendelijkheid van het systeem. Dit zou echter nog verder uitgebreid kunnen worden. Gebruikers zouden een lijst van services1 op een remote netwerk kunnen opvragen via de webinterface, waarna een service kan gekozen worden. Afhankelijk van de aard van de gekozen service zal het systeem een andere actie ondernemen. Het Service Location Protocol (SLP) ([34, 35, 36]) werd ontworpen om services te ontdekken op een lokaal netwerk. Wegens de schaalbare drie-lagenarchitectuur van SLP zou het geschikt kunnen zijn om te integreren in het huidige systeem. Een vereiste is natuurlijk wel dat de machines in de thuisnetwerken hun services aankondigen overeenkomstig SLP. Hierbij treedt een conflict op tussen enerzijds de gebruiksvriendelijkheid en anderzijds transparantie van het systeem. Een mogelijke aanpak zou zijn om zoveel mogelijk Service Discovery Protocols te ondersteunen en de gebruiker een samengestelde lijst van alle gevonden services te tonen. Zodoende wordt er geen extra vereiste opgelegd aan de clients wat betreft het te gebruiken protocol. Logischerwijze moeten de clients die een service publiek willen maken wel ´e´en van de mogelijke protocollen implementeren. Naast SLP is DNS Service Discovery (DNS-SD) een voorbeeld van een dergelijke protocol.
7.1.4
Uitbreiding naar IPv6
De huidige implementatie is gemaakt voor IPv4, aangezien IPv6 door het grootste deel van het doelpubliek niet ondersteund wordt. In de toekomst zal dit echter veranderen en zal het nodig zijn om de implementatie uit te breiden naar IPv6. Aan de architectuur hoeft hiervoor uiteraard niets gewijzigd te worden. 1
Op Windowscomputers bijvoorbeeld wordt meestal bestandsdeling aangeboden door NetBIOS of CIFS. Denk
bijvoorbeeld ook aan services als FTP, HTTP en SSH.
7.1 Verder onderzoek
74
Qua ontwerp zullen vooral de AddressTranslation-module en de VPNInterface-module aangepast moeten worden om te werken met IPv6. De gekozen VPN-technologie, OpenVPN, kan zowel IPv4- als IPv6-pakketten tunnelen, dus hieraan hoeft niets gewijzigd te worden. Wel moet de code aangepast worden om deze functionaliteit correct in te stellen (de virtuele tun-interface moet een IPv6-adres krijgen en de routering moet correct ingesteld worden). Ook de code in de module AddressTranslation zal moeten aangepast worden om met IPv6-adressen te werken. IPv6-adressen zouden ook het huidige probleem van de kleine adresruimte bij overlappende netwerken kunnen oplossen. Gezien de grote beschikbaarheid van IPv6-adressen, zou een Service Provider een grote range van IPv6-adressen kunnen aanvragen. Deze adressen zouden dan door de Service Provider niet uitgedeeld worden aan fysieke hosts, maar enkel ter beschikking staan om te gebruiken als virtuele IP-adressen. Op deze manier is een nieuwe adresruimte beschikbaar om virtuele IP-adressen uit te putten, die niet overlapt met de adresruimte die gebruikt wordt voor het lokale netwerk. Voor IPv4 is deze strategie niet realistisch, aangezien IPv4-adressen te schaars zijn (en dus te duur). Bij IPv6 is dit een te overwegen optie. Waarschijnlijk zal het zelfs zo zijn dat er geen NAT meer gebruikt zal worden met IPv6. In dat geval is er helemaal geen nood meer aan virtuele IP-adressen: alle hosts hebben een publiek (en dus uniek) IP-adres.
BIBLIOGRAFIE
75
Bibliografie [1] B. Aboba, W. Dixon, “IPsec-Network Address Translation (NAT) Compatibility Requirements”, IETF RFC 3713, March 2004 [2] A. Huttunen, B. Swander, V. Volpe, L. Diburro, M. Stenberg, “UDP Encapsulation of IPsec ESP Packets”, IETF RFC 3948, January 2005 [3] S. Kent, K. Seo, ”Security Architecture for the Internet Protocol”, IETF RFC 4301, December 2005 [4] S. Kent, “IP Encapsulating Security Payload (ESP)”, IETF RFC 4303, December 2005 [5] T. Dierks, C. Allen, “The TLS Protocol Version 1.0”, IETF RFC 2246, January 1999 [6] “IPsec HOWTO”, http://www.ipsec-howto.org/x197.html (June 2006) [7] J. Romkey, “ A Nonstandard For Transmission Of IP Datagrams Over Serial Lines: SLIP”, IETF RFC 1055, June 1988 [8] “High-Level Data Link Control”, http://en.wikipedia.org/wiki/ISO 13239 (June 2006) [9] J. Reynolds, “Assigned Numbers: RFC 1700 is Replaced by an on-line Database”, IETF RFC 3232, January 2002 [10] J. Reynolds, J. Postel, “Assigned Numbers”, IETF 1700, October 1994 [11] “IANA Protocol Numbers”,
http://www.iana.org/assignments/protocol-numbers (June
2006) [12] “IANA Port Numbers”, http://www.iana.org/assignments/port-numbers (June 2006) [13] B. Lloyd, W. Simpson, “PPP Authentication Protocols”, IETF RFC 1334, October 1992
BIBLIOGRAFIE
76
[14] W. Simpson,
“PPP Challenge Handshake Authentication Protocol (CHAP)”,
IETF
RFC 1994, August 1996 [15] G. Meyer, “The PPP Encryption Control Protocol”, IETF RFC 1968, June 1996 [16] G. Pall, G.Zorn,
“Microsoft Point-to-Point Encryption (MPPE) Protocol”,
IETF
RFC 3078, March 2001 [17] B. Schneier, Mudge, (PPTP)”,
“Cryptanalysis of Microsoft’s point-to-point tunneling protocol
in Proceedings of the 5th ACM conference on Computer and communica-
tions security, ACM Press, San Francisco, California, United States, pp: 132 - 141 http://www.counterpane.com/pptp.html (June 2006) ISBN:1-58113-007-4 1998. [18] “FAQ – Microsoft PPTP implementation”, http://www.schneier.com/pptp-faq.html (June 2006) [19] “L0phtcrack
1.5
Lanman
/
NT
password
hash
cracker”,
http://www.insecure.org/sploits/l0phtcrack.lanman.problems.html (June 2006) [20] “Crypto flaw found in Microsoft net product”, http://www.eetimes.com/news/98/1011news/flaw.html (June 2006) [21] “Windows NT Security Under Fire”, http://www.wired.com/news/technology/0,1282,12629,00.html (June 2006) [22] “Cryptographer slams NT security”, http://news.com.com/2100-1023-211807.html (June 2006) [23] “asleap home page”, http://asleap.sourceforge.net (June 2006) [24] “PPTP
VPN
authentication
protocol
proven
very
susceptible
to
attack”,
http://blogs.zdnet.com/Ou/index.php?p=21 (June 2006) [25] Bruce Schneier, Mudge, David Wagner, “Cryptanalysis of Microsoft’s PPTP Authentication Extensions (MS-CHAPv2)” http://www.schneier.com/paper-pptpv2.pdf (June 2006) October 19, 1999 [26] “Microsoft Security Bulletin MS01-009”, http://www.microsoft.com/technet/security/Bulletin/MS01-009.mspx (June 2006)
BIBLIOGRAFIE
77
[27] “Microsoft Security Bulletin MS02-063”, http://www.microsoft.com/technet/security/Bulletin/MS02-063.mspx (June 2006) [28] “SANS Malware FAQ: Microsoft PPTP VPN”, http://www.sans.org/resources/malwarefaq/pptp-vpn.php (June 2006) [29] S. Hanks, T. Li, D. Farinacci, P. Traina,
“Generic Routing Encapsulation”,
IETF
RFC 1701, October 1994 [30] S. Hanks, T. Li, D. Farinacci, P. Traina, “Generic Routing Encapsulation over IPv4 networks”, IETF RFC 1702, October 1994 [31] Peter H. Lutz, “Network Development Software”, http://netdev.it.rit.edu/jNetDev/ (June 2006) [32] “Iperf Version 2.0.2”, http://iperf.sourceforge.net (June 2006) [33] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications”, IETF RFC 1889, January 1996 [34] E. Guttman, C. Perkins, J. Veizades, M. Day, “Service Location Protocol, Version 2”, IETF RFC 2608, June 1999 [35] E. Guttman,
“Vendor Extensions for Service Location Protocol, Version 2”,
IETF
RFC 3224, January 2002 [36] “Service Location Protocol”, (June 2006)
http://en.wikipedia.org/wiki/Service Location Protocol
LIJST VAN TABELLEN
78
Lijst van tabellen 4.2
Vergelijking VPN-technologie¨en . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
4.2
Vergelijking VPN-technologie¨en . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
6.1
Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
6.2
RTT (in ms) bij de testopstelling in het lab . . . . . . . . . . . . . . . . . . . . .
64
6.3
RTT (in ms) bij de thuistestopstelling . . . . . . . . . . . . . . . . . . . . . . . .
66
LIJST VAN FIGUREN
79
Lijst van figuren 2.1
Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2
Use Case: Configureren gateway door netwerkbeheerder . . . . . . . . . . . . . .
6
2.3
Use Case: Starten en stoppen verbinding tussen gateways . . . . . . . . . . . . .
7
3.1
Module view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.2
Deployment view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
4.1
OSGi architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
4.2
Gedeelde klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
4.3
Het verschil tussen tunnel- en transportmode . . . . . . . . . . . . . . . . . . . .
17
4.4
Een authenticated header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.5
Een ESP header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.6
Multiplexen van IP-pakketten bestemd voor de tunnel, met TLS-data. . . . . . .
23
4.7
Gelaagd OSI-model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.8
PPP-frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.9
Fase-overgangen bij het opzetten van een PPP-verbinding . . . . . . . . . . . . .
29
4.10 Werking van PPTP / L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.11 Structuur van een PPTP-pakket . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.12 Structuur van een L2TP/PPP-pakket . . . . . . . . . . . . . . . . . . . . . . . .
34
4.13 Een voorbeeld van adresvertaling met nieuwe subnetwerken. . . . . . . . . . . . .
39
5.1
Klassendiagram van relevante klassen voor de bundle Negotiator . . . . . . . . .
42
5.2
(a) Specificatie van vraag negotiatorprotocol (b) Voorbeeld van een vraag . . . .
43
5.3
(a) Specificatie van antwoord negotiatorprotocol (b) Voorbeeld van een antwoord
43
5.4
Registratiefase generiek onderhandelingsprotocol . . . . . . . . . . . . . . . . . .
44
5.5
Genereren vraag generiek onderhandelingsprotocol . . . . . . . . . . . . . . . . .
45
LIJST VAN FIGUREN
80
5.6
Beslissingsfase generiek onderhandelingsprotocol . . . . . . . . . . . . . . . . . .
45
5.7
Controlefase generiek onderhandelingsprotocol . . . . . . . . . . . . . . . . . . . .
46
5.8
Voorbeeld van een standaardonderhandeling . . . . . . . . . . . . . . . . . . . . .
47
5.9
Klassendiagram van relevante klassen voor de bundle ConfigurationManager . . .
48
5.10 Klassendiagram van relevante klassen voor de bundle AddressTranslation . . . .
49
5.11 Voorbeeld van adresvertaling met statische remapping . . . . . . . . . . . . . . .
51
5.12 Voorbeeld van een onderhandeling . . . . . . . . . . . . . . . . . . . . . . . . . .
53
5.13 Klassendiagram van relevante klassen voor de bundle VPNInterface . . . . . . . .
54
5.14 Klassendiagram van relevante klassen voor de bundle AutoVPNInterface . . . . .
56
5.15 Openen verbinding met behulp van AutoVPNInterface . . . . . . . . . . . . . . .
57
5.16 Sluiten verbinding met behulp van AutoVPNInterface . . . . . . . . . . . . . . .
58
5.17 Klassendiagram van relevante klassen voor de bundle WebInterface . . . . . . . .
59
5.18 Klassendiagram van relevante klassen voor de bundlee GNS . . . . . . . . . . . .
59
6.1
Testopstelling in gecontroleerde omgeving. . . . . . . . . . . . . . . . . . . . . . .
62
6.2
Testopstelling in realistische omgeving. . . . . . . . . . . . . . . . . . . . . . . . .
63
6.3
Throughput bij de testopstelling in het lab (in bytes/s)
. . . . . . . . . . . . . .
65
6.4
Throughput bij de thuistestopstelling (in bytes/s) . . . . . . . . . . . . . . . . . .
66
6.5
Testopstelling voor meten pakketverlies . . . . . . . . . . . . . . . . . . . . . . .
67
6.6
Pakketverlies bij gebruik van UDP-datagrammen van 1470 bytes . . . . . . . . .
68
6.7
Vergelijking pakketverlies tussen situatie met UDP-datagrammen van 1470 bytes
6.8
ten opzichte van UDP-datagrammen van 1000 bytes . . . . . . . . . . . . . . . .
68
Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
