automatische vpn-tunneling tussen...

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 starten 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


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 tunnelen 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.


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.


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


• 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-


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].


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.


• 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


• 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


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


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


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).


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.


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


(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.


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


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.


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.


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.


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.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:


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


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.


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-


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”.


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.


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


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.


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.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.


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 tunnelen 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

automatische vpn-tunneling tussen...

Documents