Upload
hatruc
View
224
Download
3
Embed Size (px)
Citation preview
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 kopieren voor persoonlijk gebruik.
Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrek-
king 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-gatewaysdoor
Bas BOONEJelle NELIS
Scriptie ingediend tot het behalen van de academische graad vanburgerlijk ingenieur in de computerwetenschappen
Academiejaar 2005–2006
Promotor: prof. dr. ir. F. GIELENCo-Promotor: prof. dr. ir. F. DE TURCK
Scriptiebegeleiders: R. HENS en J. HOLLEZ
Faculteit IngenieurswetenschappenUniversiteit Gent
Vakgroep InformatietechnologieVoorzitter: prof. dr. ir. P. LAGASSE
Samenvatting
In deze thesis wordt een systeem besproken dat toelaat een site-to-site VPN op te zetten tussentwee netwerken die met het internet verbonden zijn via een OSGi-gateway. Dit gebeurt op eenvoor de gebruiker transparante en gebruiksvriendelijke manier.
Allereerst wordt er een specificatie opgesteld over wat er verwacht wordt van het systeem enwordt de architectuur voorgesteld.
Vervolgens worden een aantal VPN-technologieen worden besproken en vergeleken, alsook eenaantal adresseringsstrategieen, die het mogelijk maken netwerken te verbinden die overlappendesubnetwerken gebruiken.
Wanneer beslist is van welke technologieen gebruik zal gemaakt worden, worden een aantalontwerpbeslissingen toegelicht.
Uit de testresultaten blijkt dat het systeem bij hoge bandbreedtes (100 Mbps) een significantenegatieve impact heeft op de throughput, maar bij lagere bandbreedtes een zeer kleine impactheeft op throughput, vertraging en pakketverlies. Thuisgebruikers en zelfs kleine bedrijvenmaken gebruik van breedbandverbindingen waar de bandbreedtes (vooral qua upload) beperktzijn. De negatieve effecten van het systeem op de eigenschappen van de verbinding zijn in dezegevallen miniem.
Tot slot worden een aantal mogelijke uitbreidingen en mogelijkheden voor verder onderzoekbesproken.
Trefwoorden
OSGi, VPN, veiligheid
Automatic VPN tunneling between OSGi gatewaysBas Boone, Jelle Nelis
Supervisor(s): Frank Gielen, Filip De Turck
Abstract— This article describes an architecture and implementationfor automatic VPN tunneling between OSGi gateways, aiming for a user-friendly, transparent solution to set up a secure tunnel between home net-works.
Keywords—VPN, OSGi
I. INTRODUCTION
MANY home users have a small home network, which canbe used to share files and printers, play games, etc. Since
these networks are usually connected to the Internet, they wouldalso like to be able to connect to devices on other networks.Of course, security is important: access to a network should belimited to trusted networks, and all network traffic should besafe from eavesdroppers.
A similar situation exists for companies: they would like theiremployees 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 PrivateNetworks (VPN’s). These solutions exist in hardware or insoftware. For client-to-site connections (where clients need tobe connected to a network), these solutions usually suffice, al-though they require some technical competence on the network-side. For site-to-site connections (where two or more networksneed to be connected), additional problems can arise: the gate-ways 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 prob-lems, so that an authenticated, confidential and integer site-to-site VPN can be set up by non-technical users. The system iscompletely transparent for the client, meaning that no additionalsoftware must be installed on the client (only on the gateways)and existing connections are not hindered. The target users forthis system are home users, and small companies looking foran easy-to-set-up VPN solution which does not require a lot oftechnical knowhow.
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.
II. DESIGN
To address these problems, several technologies, which aredescribed further in the following subsections, are used.
A. OpenVPN
OpenVPN is used to set up a secure tunnel between gateways.OpenVPN is an SSL-based VPN solution which works by in-stalling a virtual network interface. All traffic sent to this virtualnetwork interface will then be authenticated, encrypted, encap-sulated in UDP-packets, and sent to the remote gateway. Sinceit is SSL-based, X.509 certifcates are used for authentication.
B. Address translation
If two networks use overlapping subnetworks, address trans-lation is used to prevent conflicts. Traffic destined for the remotenetwork has its source address changed to a non-conflicting ad-dress, and incoming traffic from the remote network has its des-tination 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 partici-pating networks overlap, a negotiation is performed before theactual VPN setup. During this negotiation, the gateways decidewhich overlay networks to use. The design uses a listener pat-tern, so that new items that need to be negotiated (i.e. encryptionalgorithm 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 acomponent-oriented computing environment for networked de-vices. It is used in residential gateways, but also in digital mo-bile phones and embedded appliances. The main benefit of usingOSGi is the ability of doing remote management of the applica-tions. This allows for easy deployment and life cycle manage-ment.
E. Naming system
To address the problem of gateways with dynamically as-signed IP-addresses, each gateway is given a unique name. Thisname corresponds with the name in the X.509 certificate men-tioned in section II-A. Gateways register their IP-address witha Gateway Naming System Server (GNS-server). Users can setup a VPN-connection by specifying the name of the gatewaythey want to connect to. Gateway names are also used by theuser to specify a list of trusted gateways that can set up a VPNconnection with them.
This naming system is also used to name individual hosts,so they can be looked up by other hosts, even though addresstranslation is in effect (therefore using the original IP-addresseswould not work). Every host can specify its desired name; itwill be suffixed with the gateway name.
III. TEST RESULTS
Throughput and delay were measured for two setups: one us-ing high bandwidth links (100 Mbps), and one using lower band-width links (effectively employing a home broadband Internetconnection). If the system was employed, throughput sufferedin the high bandwidth situation, because encryption on the gate-ways was executed slower than the rate of arriving packets. Inthe lower bandwidth situation, throughput was only 3% lower,which corresponds with the OpenVPN header overhead. Theincrease in delay was in both cases negligable.
IV. CONCLUSION
The described system offers a userfriendly, transparent sys-tem 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.
REFERENCES
[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 8
3.1 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
3.2 Deployment view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.1 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.2 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.3 Serverpark Service Provider . . . . . . . . . . . . . . . . . . . . . . . . . . 12
INHOUDSOPGAVE ii
4 Technologiestudie 13
4.1 OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.1 Motivatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.2 Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.3 Architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 VPN-technologieen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
4.3 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
5.5 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
5.9 GNSServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
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 71
7.1 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 iv
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
INHOUDSOPGAVE v
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
INHOUDSOPGAVE vi
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
INHOUDSOPGAVE vii
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
INHOUDSOPGAVE viii
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
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 geogra-
fische 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 bepaal-
de, 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 ge-
bruiken. 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 bedrijfs-
informatie 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.
Een 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 creeren 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, om-
wille 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 creeren, waarbij een absoluut minimum aan
configuratie nodig is en waarbij geen technische kennis vereist is bij de gebruikers. Deze VPN-
oplossing 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 VPN-
oplossing 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 ga-
teways 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 architec-
tuur kan worden geımplementeerd, moeten de benodigde technologieen onderzocht worden. In
hoofdstuk 4 worden de belangrijkste VPN-technologieen besproken en vergeleken. Verder wordt
ook het probleem van de adresseringsstrategie onderzocht en wordt OSGi besproken.
Na het besluit over de te gebruiken technologieen wordt in hoofdstuk 5 de concrete imple-
mentatie 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 mo-
dule ConfigurationManager wordt door elke module die configuratie wil opslaan, gebruikt. De
modules worden elk apart besproken in de volgende secties.
3.1 Module view 9
3.1.1 Negotiator
Bij het opstellen van een verbinding tussen twee gateways zijn er verschillende zaken die veran-
derlijk 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 infor-
matie 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 op-
geslagen. 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 mo-
dule AddressTranslation de beslissingen neemt over het al dan niet gebruiken van adresvertaling
en de eventuele parameters van de adresvertaling.
3.1 Module view 10
3.1.4 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
geencrypteerd).
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, IP-
adres 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: Configuration-
Manager, AddressTranslation, Policing en AutoVPNInterface.
Figuur 3.2: Deployment view
3.2 Deployment view 12
3.2.1 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 OSGi
4.1.1 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 commerciele 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 compo-
nenten, 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 geupdatet worden.
Het systeem is service-georienteerd: componenten kunnen dynamisch elkaars services ont-
dekken en gebruiken.
4.1 OSGi 14
4.1.3 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 tegenstel-
ling 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 moe-
ten zijn in het Manifest-bestand van de JAR, waaronder de geımporteerde en geexporteerde
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 initiele 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 pack-
ages) 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-technologieen 16
• objecten registreren bij de Service Registry; deze objecten worden services genoemd. Ser-
vices 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 re-
sources 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 geexporteerd 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-technologieen
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-technologieen 17
dat deze implementatie in userspace 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 vertrouwelijk-
heid van communicatie te verzekeren. Verder zijn er ook nog twee mogelijke modi: tunnelmode
of transportmode. Bij tunnelmode wordt elk IP-pakket volledig geencrypteerd en/of geauthen-
ticeerd en geencapsuleerd in een nieuw IP pakket. Bij transportmode wordt enkel de IP-data
geencrypteerd 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 Authen-
tication Codes (HMAC). De HMAC van een pakket wordt berekend door de hash te berekenen1Userspace 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-technologieen 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-technologieen 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 geencapsuleerd pakket wordt
grafisch weergegeven in figuur 4.5.
Figuur 4.5: Een ESP header
4.2 VPN-technologieen 20
• SPI: zoals bij AH.
• Sequence Number: zoals bij AH.
• Data: geencrypteerde data. In transportmode is dit de data in het IP-pakket; in tunnel-
mode 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 com-
municatie wordt beschermd met de ISAKMP SA.
Normaal onderhandelen de twee peers slechts een 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-technologieen 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 geencapsuleerde 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-technologieen 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 par-
tijen moeten hierbij een certificaat hebben, ondertekend door een Certificate Authority (CA).
Als de authenticatie slaagt, worden encryptie/decryptie en HMAC sleutels gegenereerd, waar-
bij beide partijen random materiaal leveren. In deze mode worden de sleutels niet bidirectio-
neel 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-commu-
nicatie 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 data-
boodschap.
• Key-id: (3 bit) de key-id verwijst naar een reeds onderhandelde TLS-sessie.
4.2 VPN-technologieen 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
geencrypteerd 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 TLS-
protocol 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 geencapsuleerd. 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 efficientieredenen.
• 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-technologieen 24
• ACK packet id array length (1 byte); indien aankomst van andere pakketten wordt beves-
tigd.
• 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 onder-
handelen:
• 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 gebrui-
kersnaam en wachtwoord om aan authenticatie op basis van gebruikersnaam/wachtwoord-
paren 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-technologieen 25
De plaintext van de data-boodschappen bevat ten slotte een packet id (4 bytes) en de plain-
text zelf (IP-pakket of ethernetpakket).
De data-boodschappen bevatten geen reliability layer. Dit komt omdat de geencapsuleerde
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 net-
werkinterface. 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, FreeBSD-
kernels, 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-technologieen 26
Figuur 4.7: Gelaagd OSI-model
fouten en het effectief verzenden van de geencapsuleerde 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 een van de meest bekende protocollen die bo-
venstaand 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 seriele 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 IP-
pakketten 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 seriele verbinding. In [7] wordt de werking besproken, maar vooral
4.2 VPN-technologieen 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 Point-
to-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 Protocols, verzorgt de inter-
face 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 pro-
tocollen 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-technologieen 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 een 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 een van deze modes, namelijk een best-effort service.
• Protocol: twee bytes die het geencapsuleerde protocol aanduiden. Zie [9, 10, 11] voor de
mogelijke waarden.
• Data: Geencapsuleerde data.
• FCS: Frame Check Sequence, gebruikt voor foutdetectie.
De velden Protocol en FCS zorgen al voor twee extra services ten opzichte van SLIP: res-
pectievelijk de mogelijkheid van encapsulatie van meerdere protocollen en foutdetectie.
PPP: Link Control Protocol Voor elke fysieke link kan maximum een 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 LCP-
verbinding.
4.2 VPN-technologieen 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 een 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 Con-
trol Protocol (IPCP), voor IPX bestaat het Internetworking Packet Exchange Control Protocol
4.2 VPN-technologieen 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 een LCP-verbinding meerdere NCP-verbindingen gestart worden om meer-
dere 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 waar-
in 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 officiele ondersteuning voor PPTP in de Linux-kernel. SuSE 10 was de allereerste Linux-
distributie met een volledig werkende PPTP-client. Ook voor MacOS zijn er PPTP-clients
beschikbaar.
4.2 VPN-technologieen 31
Veiligheid 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 on-
derzocht 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 on-
dernomen 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 een 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-technologieen 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 gebrui-
kers verbonden met verschillende PACs (client-to-site VPN). Het is eveneens mogelijk om voor
eenzelfde virtueel netwerk verschillende PNSs te gebruiken.
PPTP is verbindingsgeorienteerd. 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 Encap-
sulation (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 een enkele tunnel.
De pakketten die over deze tunnel lopen zijn PPP-pakketten geencapsuleerd in GRE, ver-
zonden over IP zoals te zien in figuur 4.11.
4.2 VPN-technologieen 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 encryp-
tie 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 encapsule-
ren 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-technologieen 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/PPP-
pakketten worden geencapsuleerd 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-technologieen
IPSec OpenVPN PPTP L2TP/PPP L2TP/IPSec
Authenticatie PSK, RSA,
X.509
PSK,
X.509,
user/pass
MS-
CHAPv2,
CISCO
LEAP
PPP IPSec, PPP
Key exchange IKE TLS/SSL Geen Geen IKE
Standaard onder-
steunde encryptie-
algoritmen
AES, DES,
3DES, RC5,
IDEA,
3IDEA,
CAST,
Blowfish
Alle in
OpenSSL
(3DES,
AES, Blow-
fish, ...)
PPP2 PPP IPSec, PPP
Kernelspace of
userspace
Kernelspace Userspace Kernelspace Kernelspace Kernelspace
Bridging Nee Ja Ja Ja Nee
23DESE (RFC2420), DESE (RFC1969), MPPE (RFC3078), maar men kan voor elk encryptie-algoritme een
ECP schrijven.
4.2 VPN-technologieen 35
Tabel 4.2: Vergelijking VPN-technologieen
IPSec OpenVPN PPTP L2TP/PPP L2TP/IPSec
Platform Beschikbaar
voor bij-
na alle
platformen
Windows,
Unix,
*BSD, Mac
OSX
Windows,
Linux,
*BSD,
meeste
Unices
Windows,
Linux,
*BSD,
meeste
Unices
Windows,
Linux,
*BSD,
meeste
Unices
NAT-traversal Nee Ja Ja Ja Nee
Aanspreekbaar in
Java op algemene
manier
Nee Ja Nee Nee Nee
4.2.5 Vergelijking
Tabel 4.2 toont de eigenschappen van de verschillende VPN-technologieen waarop deze vergelij-
king is gebaseerd.
Allereerst zullen we PPTP en L2TP/PPP bespreken aangezien beide technologieen gelijk-
aardig 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 geencapsuleerd 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 protocol-
len 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 authen-
ticatie 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 recht-
streeks 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 da-
tapakketten worden geauthenticeerd en geencrypteerd met de meest recente cryptografi-
sche algoritmen uit de OpenSSL-bibliotheek.
4.3 Adresseringsstrategie
Een 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 subnet-
werk 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 hetzelf-
de 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.3De CIDR-notatie wordt hier gebruikt om de netwerken aan te duiden.
4.3 Adresseringsstrategie 37
4.3.1 Netwerken samenvoegen
De meest voor de hand liggende oplossing is om de twee overlappende netwerken proberen samen
te voegen tot een 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 een 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 een van de gateways gekozen worden als
DHCP-server, die dan niet-conflicterende IP-adressen kan uitdelen aan de hosts op beide net-
werken. 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 gecreeerd. 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 geconfigu-
reerd 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 gere-
serveerde 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 bestem-
mingsadres 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 een 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 be-
treft 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 voor-
deel 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 el-
kaar 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 pro-1Een 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 platfor-
men. 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 een 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 onderhandelings-
partners natuurlijk eenzelfde taal spreken. Deze taal wordt hieronder besproken.
Bij het starten van de onderhandeling gaat de Negotiator van de gateway die de onderhande-
ling 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 <Name> en <Choice> 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 een van de volgende waarden aan:
• een 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 listener-
architectuur. Alle bundles die de onderhandeling van een 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 een 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 een
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 NegotiatorListeners een geordende lijst van keu-
zes 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 verantwoor-
delijk 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 een 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 verkrij-
gen.
• 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 ver-
antwoordelijk 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 een 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 ConfigurationMa-
nager.
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 voor-
zien om verbindingen in het systeem te onderhouden. Een om een verbinding aan te maken in
het systeem en een 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 klas-
sen 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 Static-
RemappingAddressTranslationConfig.
NoneAddressTranslationConfig voert geen adresvertaling uit en houdt dus enkel de informa-
tie 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 sub-
netwerk 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”, “tunnelRan-
ge” 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 adres-
seren 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 pakket-
manipulatie, die ook deze functionaliteit aanbiedt.
5.4 AddressTranslation 52
Wanneer een nieuwe VPN-verbinding aangemaakt wordt op de lokale gateway, zal getPara-
meters() 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, remo-
teRange 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 negotiate-
Parameters() opgeroepen worden. De bundle zal dan eerst nagaan welke adresvertalingsmetho-
de 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 VPN-
verbindingen, 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 Configuration-
Manager 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 initierende gateway kiest het eerste IP-
adres 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 luis-
teren. 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 een van de gateways 60 seconden lang geen “ping”
ontvangt, besluit deze dat de verbinding is afgebroken en sluit de daemon af. Dit wordt gedetec-
teerd 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 beeindigen
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 IP-
adres 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 (ga-
teway 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 infor-
matie 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, een die de gewone eindgebruiker zal gebruiken
en een 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 on-
dernomen 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 net-
werkbeheerder 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<CRLF>
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. 2
5.9 GNSServer
De module GNSServer is geımplementeerd als een standaard Java-applicatie, bestaande uit een
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 relatie2Een 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.
Een testopstelling bevindt zich in de gecontroleerde omgeving van de universiteit en bestaat
uit twee computers die dienstdoen als gateways, een computer die dienstdoet als GNS-server,
een 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 gate-
ways/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 ongeencrypteerde 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 een verbinding, de maximale bandbreedte zal proberen te benutten.
Verwacht wordt dat door de tunneling een lagere throughput kan bereikt worden: ener-
zijds 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 TCP-
verbinding, 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. Aan-
gezien 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 testop-
stelling in het lab zijn op een paar punten dipjes te zien: deze komen overeen met een sleutel-
onderhandeling 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, een 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 even-
eens 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 ge-
noemd, 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 realis-
tisch 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 ma-
chines 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 op-
zichte 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 bandbreed-
tes 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 een 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 door-
zendtijd 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 adres-
vertaling, 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 soft-
ware geınstalleerd te worden op de clients en worden bestaande verbindingen niet gehinderd.
Bovendien worden problemen met overlappende subnetwerken afgehandeld zonder dat tussen-
komst van de gebruiker nodig is. In onze implementatie is deze functionaliteit beperkt tot
linuxplatformen en is er ook maar een soort adresseringsstrategie aanwezig (statische remap-
ping), maar deze proof-of-concept toont aan dat het zeker mogelijk is om dit uit te breiden naar
andere platformen (en andere adresseringsstrategieen).
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 73
7.1.3 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 ser-
vices1 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 ac-
tie 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 een 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.1Op 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 Require-
ments”, 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, “Cryptanalysis of Microsoft’s point-to-point tunneling protocol
(PPTP)”, 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 Authentica-
tion 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 net-
works”, 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”, http://en.wikipedia.org/wiki/Service Location Protocol
(June 2006)
LIJST VAN TABELLEN 78
Lijst van tabellen
4.2 Vergelijking VPN-technologieen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2 Vergelijking VPN-technologieen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
ten opzichte van UDP-datagrammen van 1000 bytes . . . . . . . . . . . . . . . . 68
6.8 Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70