Peer-to-Peer NAT Traversal for IPsecsecurity.hsr.ch/theses/DA_2006_IKEv2-P2P-NAT-T.pdf · 2006. 12. 15. · Diplomarbeit Informatik Peer-to-Peer NAT Traversal for IPsec Tobias Brunner

Diplomarbeit Informatik

Peer-to-Peer NAT Traversal for IPsec

Tobias BrunnerDaniel Röthlisberger

Wintersemester 2006/200714. Dezember 2006

Betreut durch:Prof. Dr. Andreas Steffen

Martin Willi

H S RH O C H S C H U L E F Ü R T E C H N I KR A P P E R S W I L

I N F O R M AT I K

Institute forInternet Technologiesand Applications

“Some of us feel NAT boxes are sort of anabomination because they really do mess about with

the basic protocol architecture of the Internet.”

– Vint Cerf.

Abstract

Internet Protocol Security (IPsec) ist ein Standard für Virtual Private Networks (VPNs) auf IP- ZielsetzungBasis. Internet Key Exchange, Version 2 (IKEv2) ist die neue Generation des verwendeten Schlüs-selaustausch-Protokolls.

Unter dem Sammelbegriff Network Address Translation (NAT) versteht man Verfahren, wel-che die Sender- und/oder Empfängeradressen von IP-Paketen unterwegs verändern. Im heutigenInternet ist NAT weit verbreitet. Lokale Netzwerke sind häufig über eine einzige öffentliche IP-Adresse eines NAT-Routers mit dem Internet verbunden. Verbindungen sind im Allgemeinennur von innen nach aussen möglich. Die Traversierung von NAT ist insbesondere für verschlüs-selte Protokolle problematisch. IPsec erlaubt mit NAT Traversal zwar das Überqueren von einfa-chen NAT von innen nach aussen, nicht aber Direktverbindungen in Situationen, in denen sichbeide Peers je hinter NAT befinden. Hole Punching ist eine Technik für die direkte UDP/TCP-Kommunikation in solchen Double-NAT-Situationen.

Im Rahmen dieser Diplomarbeit war das Ziel, mit Hilfe von Hole Punching auf der Basisvon IPsec und IKEv2 VPN-Direktverbindungen zwischen Hosts herzustellen, welche sich beidehinter NAT befinden, ohne dazu die NAT-Router speziell konfigurieren zu müssen. Zusätzlichwar eine Proof-of-Concept-Implementation zu entwickeln.

Als Resultat unserer Arbeit ist mit Peer-to-Peer NAT Traversal (P2P-NAT-T) eine Erweiterung Ergebnisvon IPsec entstanden, welche es ermöglicht, Verbindungen auch in Double-NAT-Situationendirekt End-zu-End aufzubauen. Wir definieren zu diesem Zweck ein auf IKEv2 basierendes Pro-tokoll zur Kommunikation der Peers mit einem Mediation Server.

Je nach Verhalten der NAT-Router ist es möglich, dass keine Direktverbindung zustande kom-men kann. Für diesen Fall definieren wir zusätzlich eine Relay-Erweiterung, welche es erlaubt,IPsec-Verbindungen unter Beibehaltung der vollen End-zu-End-Sicherheit über den MediationServer umzuleiten.

Als Proof-of-Concept-Implementation haben wir die freie, linuxbasierte IPsec-Lösung strong-Swan mit P2P-NAT-T-Unterstützung (ohne Relay) ausgestattet.

Unsere Arbeit ist in Form eines Branches bereits in das strongSwan-Projekt eingeflossen und Ausblickwird dort von Martin Willi und Prof. Dr. Andreas Steffen weiterentwickelt werden. Es ist geplant,unsere Protokollerweiterung als Internet Draft zu publizieren, um allenfalls eine Standardisie-rung in Form eines RFC anzustreben.

v

Inhaltsverzeichnis

Abstract v

1. Aufgabenstellung 1

2. Management Summary 3

3. Einleitung 53.1. Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.2. Mediation-Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.3. strongSwan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.4. Gliederung der Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . 73.5. Danksagung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4. Grundlagen 94.1. Network Address Translation (NAT) . . . . . . . . . . . . . . . . . . . . . . . . 9

4.1.1. Entstehungsgeschichte . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.1.2. Beispiel Masquerading/NAPT . . . . . . . . . . . . . . . . . . . . . . . 104.1.3. Andere Formen von NAT . . . . . . . . . . . . . . . . . . . . . . . . . 124.1.4. Probleme für Protokolle und Anwendungen . . . . . . . . . . . . . . . 134.1.5. Klassifizierung von NAT-Varianten . . . . . . . . . . . . . . . . . . . . 14

4.2. UDP Hole Punching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.3. Simple Traversal of UDP through NATs (STUN) . . . . . . . . . . . . . . . . . 17

4.3.1. Shared Secret Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.3.2. Binding Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.3.3. Ablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.4. Traversal Using Relay NAT (TURN) . . . . . . . . . . . . . . . . . . . . . . . . 204.5. Interactive Connectivity Establishment (ICE) . . . . . . . . . . . . . . . . . . . 214.6. Internet Protocol Security (IPsec) . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.6.1. AH, ESP, Tunnel und Transport Mode . . . . . . . . . . . . . . . . . . 224.6.2. Security Associations, Policies, SPI . . . . . . . . . . . . . . . . . . . . 234.6.3. Internet Key Exchange Version 2 (IKEv2) . . . . . . . . . . . . . . . . . 244.6.4. NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . . . . . . . . . . 25

vii

Inhaltsverzeichnis

4.6.5. Dead Peer Detection (DPD) . . . . . . . . . . . . . . . . . . . . . . . . 28

5. Analyse 295.1. STUN in Ruby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1.1. Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1.2. Ablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.2. Verhalten von NAT-Implementationen . . . . . . . . . . . . . . . . . . . . . . 35

5.2.1. Hole Punching Kompatibilität . . . . . . . . . . . . . . . . . . . . . . . 36

5.3. Protokoll-Prototyp in Ruby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6. Peer-to-Peer NAT Traversal for IPsec 396.1. Begriffsdefinitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.2. Protokollablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.2.1. Mediation Server und Identity Management . . . . . . . . . . . . . . . 41

6.2.2. Mediation Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6.2.3. Mediated Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.2.4. P2P Relay Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.3. Neue Protokoll-Elemente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.3.1. Vendor-ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6.3.2. Exchange Type P2P_IKE_AUTH . . . . . . . . . . . . . . . . . . . . . . 49

6.3.3. Exchange Type P2P_PEERS . . . . . . . . . . . . . . . . . . . . . . . . 50

6.3.4. Exchange Type P2P_CONNECT . . . . . . . . . . . . . . . . . . . . . . . 51

6.3.5. Exchange Type P2P_RELAY . . . . . . . . . . . . . . . . . . . . . . . . 52

6.3.6. Payload Type Peer-ID IDp . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.3.7. Notify Type P2P_CONNECT_FAILED . . . . . . . . . . . . . . . . . . . . 53

6.3.8. Notify Type P2P_RELAY_FAILED . . . . . . . . . . . . . . . . . . . . . 55

6.3.9. Notify Type WANT_P2P . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.3.10. Notify Type P2P_IPV4_ADDR . . . . . . . . . . . . . . . . . . . . . . . 55

6.3.11. Notify Type P2P_IPV6_ADDR . . . . . . . . . . . . . . . . . . . . . . . 56

6.3.12. Notify Type WANT_P2P_RELAY . . . . . . . . . . . . . . . . . . . . . . 56

6.4. Design-Entscheide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.4.1. Mediation via Drittprotokolle oder IKEv2 . . . . . . . . . . . . . . . . . 57

6.4.2. Identity Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.4.3. Protokolldesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.4.4. P2P Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

7. Implementation 617.1. Methodik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

7.1.1. Programmierrichtlinien . . . . . . . . . . . . . . . . . . . . . . . . . . 61

viii Peer-to-Peer NAT Traversal for IPsec

Inhaltsverzeichnis

7.1.2. Source Code Management . . . . . . . . . . . . . . . . . . . . . . . . . 62

7.2. Architektur im Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

7.3. Grundsätzliches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.3.1. Bedienung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.3.2. Rollen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

7.4. Klassendokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

7.4.1. Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.4.2. Datenstrukturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7.4.3. Stroke Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7.4.4. Transaktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7.4.5. Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

7.4.6. IKE-SA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

7.4.7. IKE-SA-Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

7.4.8. Socket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

7.5. Limitationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

7.6. Sonstige Resultate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

7.7. Angeregte Verbesserungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

8. Tests 89

8.1. Methodik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

8.1.1. Reale Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

8.1.2. UML Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

8.2. Testfälle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

8.2.1. Mediation Connection (p2p-mediation) . . . . . . . . . . . . . . . . . 91

8.2.2. Mediated Connection (p2p-mediated) . . . . . . . . . . . . . . . . . . 91

8.2.3. Rekey (p2p-rekey) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

8.2.4. DPD (p2p-dpd-mn) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

8.2.5. DPD (p2p-dpd-md) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

8.2.6. Roadwarrior (p2p-dpd-rw) . . . . . . . . . . . . . . . . . . . . . . . . 93

8.2.7. Erweiterte Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

9. Konfiguration 95

9.1. Konfigurationsparameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

9.1.1. Globale Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

9.1.2. Verbindungsspezifische Konfiguration . . . . . . . . . . . . . . . . . . 96

9.2. Beispielkonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Peer-to-Peer NAT Traversal for IPsec ix

Inhaltsverzeichnis

10. Projektstand 10110.1. Zukunftsvisionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

10.1.1. Publikation als Internet Draft im Rahmen der IETF . . . . . . . . . . . 10210.1.2. Netzwerktopologie im UML Test Framework . . . . . . . . . . . . . . . 10210.1.3. STUN als optionale Komponente miteinbeziehen . . . . . . . . . . . . 10310.1.4. Mediation über Gruppen-ID/Passwort . . . . . . . . . . . . . . . . . . 103

A. NAT-Konfigurationen 105A.1. Linux Netfilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

A.1.1. MASQUERADE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106A.1.2. SNAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

A.2. OpenBSD/FreeBSD PF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106A.3. Cisco IOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106A.4. Cisco PIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

B. Projektmanagement 109B.1. Projektplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109B.2. Zeitabrechnung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110B.3. Qualitätssicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

B.3.1. Massnahmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110B.3.2. Effektivität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

B.4. Protokolle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112B.4.1. Kick Off Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112B.4.2. Sitzung Woche 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114B.4.3. Sitzung Woche 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115B.4.4. Sitzung Woche 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116B.4.5. Sitzung Woche 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117B.4.6. Sitzung Woche 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118B.4.7. Sitzung Woche 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120B.4.8. Sitzung Woche 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122B.4.9. Sitzung Woche 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

C. Erfahrungsberichte 127C.1. Tobias Brunner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127C.2. Daniel Röthlisberger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Abkürzungsverzeichnis 129

x Peer-to-Peer NAT Traversal for IPsec

1. Aufgabenstellung

Einführung

Häufig wollen Unternehmen netzwerkfähige Geräte und Systeme sicher via Internet der Fern-wartung zugänglich machen. Dazu werden heute meistens Accounts auf einem VPN Gatewayeingerichtet oder aber Löcher in die Firewalls konfiguriert, um von “Aussen” auf einzelne Syste-me zu gelangen. Beide Methoden bergen aber beträchtliche Sicherheitsrisiken. Deshalb wird eineHard- und Software basierte Lösung gesucht, die, in einem privaten Firmennetz platziert, vomInternet her via IPsec erreichbar sein soll, ohne dass die firmeninterne Firewall speziell konfigu-riert werden muss. Es soll einzig vorausgesetzt werden, dass eine IPsec Verbindung von Innenüber einen NAT Router nach Aussen aufgebaut werden kann. Da der Fernzugriff auch von einerprivaten IP Adresse aus möglich sein soll, die sich ebenfalls hinter einem NAT Router befindet,muss die zu entwickelnde IPsec Box eine Double NAT Fähigkeit besitzen. Um unter diesen Um-ständen mittels IKE eine Verbindung aufbauen zu können, kann falls notwendig, die Diensteeines Mediation Servers in Anspruch genommen werden. Verschlüsselte ESP Pakete sollen aberdirekt “End-to-End” transportiert werden.

Aufgabenstellung

• Erarbeitung eines Grundkonzepts für die Double-NAT IPsec Funktionalität. Anleihen kön-nen z.B. bei den STUN und ICE Mechanismen gemacht werden, die im Umfeld des SessionInitiation Protocols (SIP) zur Überwindung von Double NAT Situationen eingesetzt wer-den. Falls technisch möglich, sollte auch eine Linux Netfilter Firewall durchquert werdenkönnen.

• Implementierung der Double NAT IPsec Funktionalität auf der Basis der Linux strongSwan-4.x Distribution. Dabei kann vom Standard NAT-Traversal Floating Port 4500 abgewichenwerden, wie er durch den IKEv2 RFC 4306 definiert wird.

• Proof-of-Concept mittels eines Double NAT IPsec Prototypen, lauffähig auf einem Stan-dard PC unter dem Linux Betriebsystem.

1

1. Aufgabenstellung

Links

• strongSwan Projekt:http://www.strongswan.org/

• Internet Key Exchange (IKEv2) Protocol:http://www.ietf.org/rfc/rfc4306.txt

• STUN - Simple Traversal of UDP through NAThttp://tools.ietf.org/html/rfc3489

• ICE - Interactive Connectivity Establishmenthttp://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-11.txt

Rapperswil, 23. Oktober 2006

Prof. Dr. Andreas Steffen

2 Peer-to-Peer NAT Traversal for IPsec

2. Management Summary

Internet Protocol Security (IPsec) ist ein Standard für Virtual Private Networks (VPNs) auf IP- ProjektauftragBasis. Internet Key Exchange, Version 2 (IKEv2) ist die neue Generation des verwendeten Schlüs-selaustausch-Protokolls.

Unter dem Sammelbegriff Network Address Translation (NAT) versteht man Verfahren, wel-che die Sender- und/oder Empfängeradressen von IP-Paketen unterwegs verändern. Im heutigenInternet ist NAT weit verbreitet. Lokale Netzwerke sind häufig über eine einzige öffentliche IP-Adresse eines NAT-Routers mit dem Internet verbunden. Verbindungen sind im Allgemeinennur von innen nach aussen möglich. Die Traversierung von NAT ist insbesondere für verschlüs-selte Protokolle problematisch. IPsec erlaubt mit NAT Traversal zwar das Überqueren von einfa-chen NAT von innen nach aussen, nicht aber Direktverbindungen in Situationen, in denen sichbeide Peers je hinter NAT befinden. Hole Punching ist eine Technik für die direkte UDP/TCP-Kommunikation in solchen Double-NAT-Situationen.

Im Rahmen dieser Diplomarbeit war das Ziel, mit Hilfe von Hole Punching auf der Basisvon IPsec und IKEv2 VPN-Direktverbindungen zwischen Hosts herzustellen, welche sich beidehinter NAT befinden, ohne dazu die NAT-Router speziell konfigurieren zu müssen. Zusätzlichwar eine Proof-of-Concept-Implementation zu entwickeln.

Als Resultat unserer Arbeit ist mit Peer-to-Peer NAT Traversal (P2P-NAT-T) eine Erweiterung Das Ergebnisvon IPsec entstanden, welche es ermöglicht, Verbindungen auch in Double-NAT-Situationendirekt End-zu-End aufzubauen. Wir definieren zu diesem Zweck ein auf IKEv2 basierendes Pro-tokoll zur Kommunikation der Peers mit einem Mediation Server.

Je nach Verhalten der NAT-Router ist es möglich, dass keine Direktverbindung zustande kom-men kann. Für diesen Fall definieren wir zusätzlich eine Relay-Erweiterung, welche es erlaubt,IPsec-Verbindungen unter Beibehaltung der vollen End-zu-End-Sicherheit über den MediationServer umzuleiten.

Als Proof-of-Concept-Implementation haben wir die freie, linuxbasierte IPsec-Lösung strong-Swan mit P2P-NAT-T-Unterstützung (ohne Relay) ausgestattet.

Im Zusammenhang mit Hole Punching unterscheidet man zwischen den vier folgenden Typen NAT-Verhaltenvon NAT-Implementationen:

• Full Cone NAT,

• Restricted Cone NAT,

3

2. Management Summary

• Port Restricted Cone NAT,

• Symmetric NAT.

Davon sind die ersten drei Hole Punching freundlich, während symmetrisches NAT Hole Pun-ching im Allgemeinen verunmöglicht. Es existieren auch unterschiedliche Mischformen. Wirhaben diverse NAT-Implementationen in Soft- und Hardware nach diesen und weiteren für Ho-le Punching relevanten Kriterien untersucht und analysiert, unter welchen Bedingungen HolePunching erfolgreich sein kann.

Basierend auf diesen Resultaten haben wir Peer-to-Peer NAT Traversal entwickelt. P2P-NAT-P2P-NAT-TT definiert die folgenden Rollen:

• Clients (Peers), welche direkte Verbindungen mittels Hole Punching erstellen möchtenund zu diesem Zweck die Dienste eines Mediation Servers in Anspruch nehmen, und

• Mediation Server, welche Direktverbindungen zwischen Clients vermitteln und als Out-of-Band-Kommunikationskanal zwischen den Clients dienen, bis diese eine Direktverbin-dung aufgebaut haben. Im Relay-Fall werden UDP-Pakete der Direktverbindungen überden Mediation Server geleitet, ohne die End-zu-En d-Sicherheit aufzugeben.

Zur Kommunikation der Peers mit einem Mediation Server haben wir Protokoll-Elemente fürden Austausch von Adress/Port-Tupeln und die Identifikation der Peers entwickelt. Zusätzlichhaben wir Methoden entwickelt, um Hole Punching effizienter und auch in ungünstigen NAT-Situationen einsetzbar zu machen. Die Vermittlung der Verbindungen findet unter dem Schutzvon IKEv2 statt, wodurch ein bestehendes Sicherheitsframework genutzt werden kann. IdentityManagement geschieht auf Basis der normalen IDs von IKEv2, was eine optimale Integration indie IPsec-Welt ermöglicht.

Um die Praxistauglichkeit unseres Protokolls unter Beweis zu stellen, haben wir P2P-NAT-Proof of ConceptT im Rahmen von strongSwan erfolgreich implementiert. strongSwan ist nun in der Lage, alsMediation Server zu fungieren oder als Client Direktverbindungen auch in Double-NAT-Situa-tionen über Hole Punching herzustellen. Wenn eine derart vermittelte Verbindung gestartet wird,so initiiert strongSwan automatisch eine Verbindung mit dem entsprechenden Mediation Serverund startet die Vermittlung mittels P2P-NAT-T. Die Verbindung zum Mediation Server wird nurso lange aufrecht erhalten, wie sie für die Vermittlung benötigt wird.

Unsere Arbeit ist in Form eines Branches bereits in das strongSwan-Projekt eingeflossen undAusblickwird dort von Martin Willi und Prof. Dr. Andreas Steffen weiterentwickelt werden. Es ist geplant,unsere Protokollerweiterung als Internet Draft zu publizieren, um allenfalls eine Standardisie-rung in Form eines RFC anzustreben.


3. Einleitung

3.1. Problemstellung

Die Zielsetzung dieser Diplomarbeit war im Wesentlichen die Entwicklung einer Protokoller-weiterung zu IKEv2, welche das Betreiben von IPsec-Direktverbindungen zwischen zwei Clientserlaubt, welche sich beide hinter Network Address Translation befinden, was herkömmliche Di-rektverbindungen verunmöglicht. Hierbei war davon auszugehen, dass man keinerlei Kontrolleüber die NAT-Konfiguration hat, diese also über Hole Punching Techniken traversieren muss.

Im heutigen Internet ist ein grosser Anteil der Benutzer über NAT in irgend einer Ausprägungangeschlossen. Die Fähigkeit, ungeachtet der NAT-Situation IPsec-Direktverbindungen erzeugenzu können, wird deshalb immer wichtiger. Bisher war dies nur möglich, wenn man die Kontrolleüber die NAT-Router-Konfiguration hatte und so mittels statischen Weiterleitungen Direktver-bindungen ermöglichen konnte.

?

?

10.0.0.0/8

Client A192.168.1.2

Client B192.168.2.2

192.168.1.1

10.1.1.1 10.2.2.1

192.168.2.1Verbindung zu B Verbindung zu A

?

?

Abbildung 3.1.: Double NAT Problematik

Wie in Abbildung 3.1 illustriert, existiert noch ein viel grundsätzlicheres Problem. Da die bei-den Clients nicht wissen, über welche Endpunkte sie nach aussen hin sichtbar sind, gibt es auchkeine IP-Adressen, zu welchen hin sie eine Direktverbindung initiieren könnten. Somit ist mitSicherheit externe Hilfe irgend einer Art und Weise notwendig.

5

3. Einleitung

Natürlich liegt der naive Lösungsansatz nahe, einfach zwei herkömmliche IPsec-Tunnels mitHilfe von NAT Traversal (NAT-T) zu einem Drittserver aufzubauen, und den Nutzverkehr ein-fach über diesen Drittserver zu routen. Nur ist es aus Sicherheitsgründen unerwünscht, die Datenauf einem Drittserver zu entschlüsseln, weil damit die End-zu-End-Sicherheit aufgegeben würde.Abgesehen davon ist dies auch aus Performance-Gründen nicht sinnvoll.

Zusätzlich zum Protokolldesign war eine Proof-of-Concept-Implementation im Rahmen vonstrongSwan zu realisieren. Als Resultat unserer Studienarbeit [BR06] war Unterstützung für her-kömmliches NAT-T bereits vorhanden. Für erfolgreiche Direktverbindungen von Peer zu Peer inDouble-NAT-Situationen hingegen ist NAT-T aber natürlich ebenfalls Voraussetzung.

3.2. Mediation-Protokoll

Von dieser Ausgangslage ausgehend, lag es auf der Hand, einen Mediation Server zu Hilfe zu neh-men, über welchen die beiden Peers hinter NAT die für eine Direktverbindung vorgängig nötigeKommunikation abwickeln. Die aus dem VoIP-Umfeld entstandenen Protokolle STUN, TURNrespektive ICE verwenden zu diesem Zweck SIP/SDP. Diese haben wir in Kapitel 4 erläutert.

Es ging also darum, nach einer Lösung zu suchen, welche die Ideen aus diesen Protokollen aufunsere Situation bei IPsec anwenden lässt. Insbesondere war die Möglichkeit von Erweiterungenzum Schlüsselaustauschprotokoll IKEv2 zu untersuchen, um diesen Out-of-Band-Kommunika-tionskanal zu schaffen.

3.3. strongSwan

strongSwan II ist der interne Projektname der IKEv2-Implementation von strongSwan. Diese istim Rahmen der Diplomarbeit [HW05] von Jan Hutter und Martin Willi entstanden.

strongSwan ist eine Open Source, auf IPsec basierende VPN-Lösung mit Fokus auf X.509-Zer-tifikaten. Entstanden ist strongSwan als Fork von FreeS/WAN sowie dem von Prof. Dr. AndreasSteffen entwickelten X.509 Patch. FreeS/WAN war die erste komplette Implementation von IPsecfür Linux, ursprünglich auf die Initiative von John Gilmore hin entstanden. Die Entwicklungvon FreeS/WAN wurde 2003 eingestellt. Neben dem ebenfalls von FreeS/WAN abstammendenOpenswan ist strongSwan heute eine der zwei bedeutendsten IPsec-Lösungen für Linux.

strongSwan besteht aus folgenden Komponenten:

• Der Daemon pluto implementiert IKEv1, während

• charon IKEv2 in einem separaten Daemon implementiert.

• whack ist das Kontrolltool zu pluto, und

• stroke das Pendant bei charon.


3.4. Gliederung der Dokumentation

• Der starter startet, konfiguriert und überwacht die Daemons, und mit

• KLIPS ist der IPsec Kernel-Patch zu Linux 2.4 weiterhin verfügbar.

Ein Teil der gemeinsamen Funktionalität ist dabei in shared Libraries ausgelagert. Für weiterge-hende Informationen zum Kernel und seiner Schnittstelle zu Userland-Daemons wie pluto undcharon verweisen wir auf unsere Studienarbeit [BR06].

3.4. Gliederung der Dokumentation

Die Dokumentation unserer Diplomarbeit ist in folgende Teile gegliedert:

• Im Kapitel Grundlagen erläutern wir technische Grundlagen, welche für das Verständnisder Arbeit relevant sind.

• Im Kapitel Analyse halten wir unser Vorgehen bei der Analyse der NAT-Verhalten undHole-Punching-Problematik fest und zeigen Resultate auf.

• Im Kapitel Peer-to-Peer NAT Traversal for IPsec definieren wir die von uns entwickelteProtokollerweiterung und erläutern Designentscheide.

• Im Kapitel Implementation befassen wir uns mit unserer Proof-of-Concept-Implementa-tion im Rahmen von strongSwan.

• Im Kapitel Tests zeigen wir auf, wie wir unsere Proof-of-Concept-Implementation getestethaben, sowohl im Labor-Setup mit physikalischer Hardware als auch im virtuellen UML-Testing-Framework.

• Im Kapitel Konfiguration haben wir die Konfiguration unserer Implementation dokumen-tiert und Beispielkonfigurationen dargestellt.

• Im Kapitel Projektstand analysieren wir das Resultat und zeigen Möglichkeiten der Weiter-entwicklung auf.

Weitere Unterlagen wie die Konfigurationen der von uns getesteten NAT-Router, das Projekt-und Qualitätsmanagement oder die persönlichen Berichte haben wir im Anhang gesammelt.

3.5. Danksagung

Wir möchten uns an dieser Stelle bei all jenen bedanken, welche uns im Rahmen unserer Diplom-arbeit unterstützt haben. Insbesondere danken wir Prof. Dr. Andreas Steffen und Martin Willifür die souveräne Betreuung und die konstruktiven Inputs. Ebenfalls gebührt unser Dank der

Peer-to-Peer NAT Traversal for IPsec 7

3. Einleitung

suXessNet AG, Thalwil, welche uns grosszügigerweise eine nach unseren Wünschen vorkonfigu-rierte SonicWALL für Testzwecke zu Verfügung gestellt hat. Ferner danken wir dem Institut fürvernetzte Systeme (INS) und dem Institut für Internet-Technologien und Anwendungen (ITA)für die uns als Leihgabe überlassene Cisco-Hardware.


4. Grundlagen

In diesem Kapitel beschreiben wir die wichtigsten technischen Grundlagen, welche für das Ver-ständnis der folgenden Kapitel notwendig sind. Wir beschränken uns hierbei auf das Notwendigeund verweisen für eine weitergehende Beschreibung auf die jeweiligen Standards oder Original-dokumente.

Dieses Kapitel kann bei entsprechendem Vorwissen auch gut übersprungen werden, um spä-ter bei Bedarf auf einzelne Abschnitte zurückzukommen. Wir empfehlen aber die Lektüre desAbschnittes 4.1.5 über die NAT-Verhalten sowie dem Abschnitt 4.2 zu Hole Punching, da dieseessentiell für das Verständnis der weiteren Teile der Arbeit sind.

Teile dieses Kapitels basieren auf unserer Studienarbeit [BR06]. Der Abschnitt zu NAT (4.1) isteine überarbeitete und erweiterte Fassung des gleichnamigen Abschnitts der Studienarbeit, unddie Kurzeinführung zu IPsec (4.6) haben wir in einer leicht überarbeiteten Version vollständigübernommen. Alle anderen Teile dieses Kapitels sind komplett im Rahmen der Diplomarbeitentstanden.

4.1. Network Address Translation (NAT)

Unter dem Sammelbegriff Network Address Translation (NAT) versteht man Verfahren, welchedie Sender- und/oder Empfängeradressen von IP-Paketen unterwegs verändern. In der häufig-sten Anwendungsform wird NAT verwendet, um Client-Rechner in einem lokalen Netzwerk übereine oder mehrere öffentliche IP-Adresse(n) mit einem externen Netz zu verbinden — in der Re-gel mit dem Internet. Andere Anwendungsformen machen eine 1:1 Zuordnung von Adressenaus einem Adressblock auf Adressen in einem anderen Adressblock oder machen einen Server ineinem internen Netzwerk unter einer externen IP-Adresse sichtbar.

Man unterscheidet grundsätzlich zwischen einfacher Network Address Translation, auch BasicNAT genannt, wo nur die IP-Adressen modifiziert werden, und Network Address/Port Translation(NAPT), auch Hiding NAT, IP Masquerading (Linux), Port Address Translation (PAT) (Cisco)oder NAT Overloading (Cisco IOS) genannt, wo auch die Ports verändert werden, damit mehrereinterne Adressen auf die gleiche externe Adresse gemappt werden können.

9

4. Grundlagen

4.1.1. Entstehungsgeschichte

Entwickelt wurde NAT ursprünglich infolge der Adressknappheit des Internet Protocol, Versi-on 4 (IPv4). IP-Adressen sind 32 Bit gross, somit gäbe es theoretisch 232 ≈ 4.3 Mia. möglicheAdressen. In den Anfängen des Internet wurden IP-Adressen jedoch regelrecht verschwendet. Ur-sprünglich wurden die ersten 8 Bit als Netzwerknummer verwendet, der Rest zur Identifikationdes Hosts. Um eine grössere Anzahl von Netzen zu ermöglichen, hat man später mit Classful Ad-dressing [RFC791] die Länge der Netznummer abhängig gemacht vom Wert der ersten 1–4 Bit: jenach Wert dieser Bits wurden die Adressen in die Klassen A (8 Bit Netznummer), B (16 Bit Netz-nummer) und C (24 Bit Netznummer) eingeteilt (und einige Adressen für spezielle Zwecke wieMulticast reserviert). Doch auch dies reichte nicht aus, weshalb man mit Classless Inter-DomainRouting (CIDR) [RFC1518; RFC1519] schliesslich die Länge der Netzwerknummer komplett va-riabel gemacht hat, indem neben den Adressen immer eine sogenannte Netzmaske angegebenwird, welche spezifiziert, welche Bits der Adresse die Netzwerkidentifikation repräsentieren.

Doch mit der explosionsartigen Verbreitung des Internet stiess man auch hier bald an Gren-zen. Heute weist man schon lange nicht mehr jedem ans Internet angeschlossenen Rechner eineeigene Adresse fix zu. Stattdessen werden z.B. den Kunden eines Internet Service Providers (ISPs)Adressen aus einem kleinen Pool von öffentlichen IP-Adressen dynamisch zugewiesen.

Während CIDR als kurzfristige Lösung für die Probleme von IPv4 angesehen wurde und mitInternet Protocol, Version 6 (IPv6) gleichzeitig an der langfristigen Lösung gearbeitet wurde,hat man als weitere kurzfristige Überbrückungslösung Network Address Translation entwickelt[RFC1631; RFC3022], um lokale Netze unter einer oder mehrerer öffentlichen IP-Adressen ansInternet anzuschliessen, ohne für das lokale Netz einen eigenen öffentlichen Adressblock undsomit viele öffentliche Adressen zu verbrauchen.

4.1.2. Beispiel Masquerading/NAPT

Am Beispiel des häufigsten Falles möchten wir die Funktionsweise von NAT im Detail aufzei-gen. In dieser Anwendungsform wird ein internes Netzwerk über einen NAT-Router mit einereinzigen vom ISP zugewiesenen öffentlichen IP-Adresse mit dem Internet verbunden. Diese Aus-gangslage ist in Abbildung 4.1 dargestellt. Diese Form von NAT wird auch PAT, NAPT, HidingNAT und NAT Overloading genannt. Anstelle des Internets könnte das interne Netz natürlichanalog zu der hier dargestellten Situation auch mit einem anderen Wide Area Network (WAN)verbunden werden.

Der Gateway (NAT-Router) schreibt hierzu die Source-Adressen von Paketen, welche das lo-kale Netz verlassen, auf die externe IP-Adresse um. Nach aussen hin ist also nur die externe IP-Adresse des NAT-Routers sichtbar. Wenn der Client von seiner lokalen Adresse 192.168.0.2aus eine HTTP-Verbindung zum Server 1.2.3.4 startet, so sieht der Server eine eingehendeVerbindung von der Adresse 123.21.12.3, also der externen IP-Adresse des NAT-Routers. DerSource-Port wurde vom NAT-Router auf eine eindeutige Port-Nummer umgeschrieben, so dass



192.168.0.0/24

Client A

Internet192.168.0.2 192.168.0.1 123.21.12.3 1.2.3.4

192.168.0.3

Client B

ServerNAT Router

Abbildung 4.1.: NAT in der Übersicht

er die Antwortpakete des Servers wieder dem richtigen internen Host zuordnen kann. Zu die-sem Zweck führt der NAT-Router eine Tabelle, in der er sich die Source-Adress und -Port Tupelaller laufenden Verbindungen1 speichert. Der Vorgang ist in Abbildung 4.2 nochmals genauerdargestellt.

Client A

Internet192.168.0.2 192.168.0.1 123.21.12.3 1.2.3.4

192.168.0.3

Client B

src: 123.21.12.3:53263dst: 1.2.3.4:80

src: 1.2.3.4:80dst: 123.21.12.3:53263 inside src

192.168.0.2 1076192.168.0.2 1078192.168.0.3 2144192.168.0.3 2157

outside src

123.21.12.3 53259123.21.12.3 53263123.21.12.3 53271123.21.12.3 53272

src: 1.2.3.4:80dst: 192.168.0.2:1078

src: 192.168.0.2:1078dst: 1.2.3.4:80

Abbildung 4.2.: NAT: Beispiel

Masquerading/NAPT als Sicherheitsfeature?

Aufgrund der Tatsache, dass Hosts im lokalen Netz hinter dem NAT-Router nicht direkt vonaussen erreichbar sind, gelten NAT dieser Art heute auch als Sicherheitsfeature. Auch wenn dieAussage berechtigt ist, dass ein Client hinter einem solchen NAT-Router vor vielen aktiven An-griffen aus dem Internet geschützt ist, so muss man sich aber vor Augen halten, dass NAT nichtprimär der Sicherheit dient, und den Client sowieso nur vor einer eingeschränkten Angriffsklas-se “schützt”. Angriffe z.B. über den Web-Browser oder via E-Mail können damit nicht verhindertwerden und sind wesentlich gefährlicher, als “nur” von der eigenen Personal Firewall geschützt di-

1Eine Verbindung ist in diesem Zusammenhang nicht auf verbindungsorientierte Protokolle wie TCP beschränkt,sondern bezieht sich auch auf verbindungslose Protokolle wie UDP und ICMP. Als UDP-Verbindung bezeich-net man hier alle Datagramme, welche zwischen zwei konkreten Host:Port-Kombinationen ausgetauscht werden.ICMP-Pakete werden je nach Typ der zugehörigen UDP- oder TCP-Verbindung zugeordnet (z.B. Host / PortUnreachable, Source Quench), oder als eigene Verbindung behandelt (z.B. Echo / Echo Reply).


4. Grundlagen

rekt und ohne NAT ans Internet angeschlossen zu sein. Schutzmassnahmen auf Netzwerk-Ebenekönnen effektiver und sinnvoller mit Firewalls realisiert werden, ohne NAT einsetzen zu müssen.

4.1.3. Andere Formen von NAT

Es existieren diverse andere Arten von NAT. Einige der bei der Beschreibung von NAT-Szenarienverwendeten Begriffe möchten wir hier erklären.

Source NAT vs Destination NAT

Mit Source NAT (SNAT) bezeichnet man eine Network Address Translation, welche die Quell-adresse und/oder der Quellport verändert wird, während bei Destination NAT (DNAT) analogdazu die Zieladresse und/oder der Zielport modifiziert wird.

Implizit wird dadurch auch eine Richtung vorgegeben — bei Source NAT werden Verbindun-gen von innen nach aussen 2 vom NAT erfasst, bei Destination NAT werden Verbindungen vonaussen nach innen erfasst.

Port Forwarding ist eine Form von Destination NAT, während Masquerading eine Form vonSource NAT darstellt.

Statisches NAT

Bei statischem NAT wird eine Adresse aus dem internen Netz fix auf eine Adresse des externenNetzes gemappt. Es findet keine Wiederverwendung oder Mehrfachbelegung (Overloading) vonAdressen statt.

Diese Form von NAT wird beispielsweise verwendet, wenn man zwei Firmennetze miteinan-der komplett verbinden will, ohne eines der Netze komplett mit neuen Nummern auszustatten.Stattdessen findet auf den verbindenden Gateways eine 1:1 Umsetzung von einem Adressbereichin einen anderen Adressbereich statt.

Diese Form von NAT ist zugleich am wenigsten problematisch für Protokolle auf höherenSchichten, weil die Internet Protocol (IP) End-zu-End-Semantik beibehalten wird.

Port Forwarding

Unter Port Forwarding wird gemeinhin das Weiterleiten von Verbindungen an einen oder meh-rere Ports eines NAT-Routers an eine Drittmaschine verstanden. In der Regel befindet sich dieseDrittmaschine im internen Netz hinter Masquerading und könnte ohne Port Forwarding nichtvon aussen her erreicht werden. Durch das Weiterleiten von Ports können so auch Server hinter

2Die Begriffe “innen” und “aussen” machen nur dann so Sinn, wenn es sich um ein Setup wie in Abbildung 4.1handelt, was natürlich nicht zwingenderweise gegeben ist.



einem solchen NAT-Router betrieben werden. Port Forwarding ist somit eine spezielle Form vonDestination NAT.

Port Forwarding wird von einigen Herstellern von Enduser-Produkten ziemlich seltsam be-zeichnet. ZyXEL beispielsweise nennt Port Forwarding “SUA Server”, wobei SUA für Single UserAccount steht, was daher rührt, dass nur eine IP-Adresse vom ISP bezogen wird (Single User),und daher NAT notwendig ist.

Einzeladressen vs Adresspools

Bei den meisten Formen von NAT ist es prinzipiell möglich, anstelle einer einzelnen Adresseeinen Pool von mehreren Adressen zu verwenden. So ist beispielsweise Masquerading anstelleauf nur eine externe Adresse auch auf einen Pool von n externen Adressen möglich. Oder PortForwarding an mehrere anstatt nur eine interne Adresse, wodurch eine Form von Load Balancingerreicht werden kann (Verteilung der Last auf mehrere physikalische Server, welche Anfragen aneine virtuelle IP-Adresse beantworten).

4.1.4. Probleme für Protokolle und Anwendungen

Während NAT auf der Ebene der Network und Transport Layer Sinn machen kann und span-nende Lösungen für komplexe Probleme bietet, bereitet es darüberliegenden Layern unter Um-ständen grosse Probleme. Protokolle, welche auf die ursprüngliche End-zu-End-Semantik vonIP angewiesen sind, funktionieren plötzlich über NAT hinweg nicht mehr. Protokolle, welche IP-Adressen als Teil des Protokolls austauschen und darauf basierend weitere Verbindungen öffnen,versagen kläglich, wenn die Kommunikation über einen oder mehrere NAT-Router läuft, diebeim Gegenüber sichtbare Adresse also von der effektiven Adresse eines Peers abweicht. Oder,anders ausgedrückt, kann ein Host nicht mehr ohne fremde Hilfe herausfinden, unter welcherAdresse er erreichbar ist, ja diese Adresse kann gar varieren, je nachdem von woher er erreichtwerden soll.

Als konkretes Beispiel sei hier das File Transfer Protocol (FTP) genannt. Dieses verwendet zweigetrennte Verbindungen: eine Steuerverbindung (Control), und eine Datenverbindung (Data).Der Client baut zuerst eine Steuerverbindung zum Server auf. Über diesen Steuerkanal meldetder Client schliesslich dem Server seine Adresse und Port, wo er auf den Verbindungsaufbaufür die Datenverbindung wartet. Der Server baut dann die Datenverbindung zu der vom Clientgenannten Adresse und Port auf.

Wenn hier jetzt ein NAT ins Spiel kommt, sendet der Client dem Server eine “falsche” Adresse,sprich eine, welche nach aussen hin nicht erreichbar ist. Der Versuch des Servers, die Datenver-bindung aufzubauen, wird also fehlschlagen.

Grundsätzlich gibt es für derartige Probleme immer zwei Lösungen: entweder wird das Proto-koll angepasst oder dem NAT-Router wird Unterstützung für das Protokoll beigebracht. Im Falle


4. Grundlagen

von FTP sieht die Lösung auf Protokollebene so aus, dass es einen sogenannten Passive Modegibt, in welchem die Datenverbindung ebenfalls vom Client zum Server hin aufgebaut wird. Dieandere Lösung würde bedeuten, dass der NAT-Router den Inhalt der FTP-Pakete analysiert, dieübermittelte interne Adress/Port-Kombination des Clients on-the-fly durch eine externe Adres-s/Port-Kombination ersetzt und die Datenverbindung später an den Client weiterleitet. Auch daswird heute von den meisten NAT-Routern unterstützt, wobei die Qualität dieser Implementatio-nen sehr stark variiert und oft die protokollspezifische Unterstützung für neuere oder wenigerpopuläre Protokolle fehlt.

Mit diesem zweiten Lösungsansatz bestehen mehrere Probleme. Das Inspizieren und Verän-dern von Daten höherliegender Schichten stellt eine Verletzung des OSI-Schichtenmodells dar.Ein Router arbeitet eigentlich nur auf der Netzwerkschicht, womit er sich aus Gründen der Ab-straktion und der Robustheit nicht für die Daten der höherliegenden Schichten zu interessierenhat.3 Mit der Notwendigkeit, dass der NAT-Router ein konkretes Protokoll höherer Schichtenunterstützen muss, reicht es plötzlich nicht mehr, wenn die beiden Endpunkte einer Verbindungsich über das Protokoll einig sind — der NAT-Router muss das Protokoll ebenfalls kennen und(korrekt) unterstützen. Ein besonderes Problem stellen verschlüsselte Verbindungen dar, derenInhalte vom NAT-Router folglich weder inspiziert noch kontrolliert verändert werden können.

4.1.5. Klassifizierung von NAT-Varianten

Das Protokoll STUN, welches wir in Abschnitt 4.3 genauer vorstellen, teilt NAT-Implementatio-nen entsprechend ihrer Behandlung von UDP-Verkehr in vier Gruppen ein. Diese Klassifizierungist für jene Anwendungsfälle von grosser Bedeutung, bei denen kompliziertere Protokolle übermöglicherweise mehrere NAT hinweg betrieben werden sollen.

Auch wenn wir nur von “NAT” sprechen, gehen wir in den folgenden Ausführungen vomrelevantesten Fall eines NAPT aus. Die Aussagen können sinngemäss aber ebenso auf andereArten von NAT übertragen werden.

In den Abbildungen sind jeweils folgende drei Anwendungsfälle illustriert:

1. Eine Verbindung von Client A zu Client B und die Möglichkeiten von B, darauf zu antwor-ten.

2. Den Versuch von Client C eine Verbindung zu Client A über dessen öffentlichen Endpunktaufzubauen. Wichtig dabei ist, dass A bislang noch keine Pakete an C gesendet hat.

3. Eine zusätzliche Verbindung von Client A zu Client D und die Reaktion des NAT darauf.

3So gesehen ist NAT an sich schon eine Verletzung der Schichtenarchitektur.



Client A

Client B

Client C

Client D

Verbindung zu Client B

Verbindung zu Client D

von beliebigem Port

NAT Router

Abbildung 4.3.: Full Cone NAT

Full Cone Ein Full Cone NAT liegt vor, wenn alle Requests von derselben internen IP-Adres-se und demselben Port auf das gleiche externe Adress/Port-Tupel gemappt werden. Dasfür die Verbindung zu Client B erzeugte Mapping wird also auch für die Verbindung zuClient D verwendet. Des Weiteren kann, wie in der Abbildung für Client C gezeigt, jederbeliebige externe Host dem internen Host ein Paket senden, indem er dieses auf den exter-nen Endpunkt schickt. Ausserdem können Pakete von externen Host von beliebigen Portsversendet werden.

Client A

Client B

Client C

Client D



von beliebigem Port

NAT Router

Abbildung 4.4.: Restricted Cone NAT

Restricted Cone Ein Restricted Cone NAT schränkt die Eigenschaften des Full Cone NATs da-hingehend ein, dass ein externer Host mit der IP-Adresse X nur Pakete an den internenHost senden kann, wenn dieser vorher ein Paket an die IP-Adresse X geschickt hat. ImBeispiel verhindert dies, dass Client C weiterhin direkt Pakete an Client A versenden kann.Da A bereits Pakete an B gesendet hat, kann B weiterhin von beliebigen Ports antworten.Für die Verbindung zu Client D ändert sich das Mapping nicht.

Client A

Client B

Client C

Client D



von beliebigem Port

NAT Router

von ursprünglichem Port

Abbildung 4.5.: Port Restricted Cone NAT


4. Grundlagen

Port Restricted Cone Zusätzlich zu den Einschränkungen des Restricted Cone NATs kommthier noch eine Restriktion bezüglich der Portnummer hinzu. So kann ein externer Hostvon der IP-Adresse X und dem Port P nur Pakete an den internen Host senden, wenndieser vorher ein Paket an dieses Adress/Port-Tupel gesendet hat. Dies trifft nun nebenClient C auch Client B, welcher nur noch von Ports antworten kann, auf denen er bereitsPakete von Client A erhalten hat. Das Mapping bleibt weiterhin konstant.

Client A

Client B

Client C

Client D



von beliebigem Port

NAT Router

von ursprünglichem Port

Abbildung 4.6.: Symmetric NAT

Symmetric Liegt ein Symmetric NAT vor, so werden alle Requests von derselben IP-Adresseund demselben Port zu einem spezifischen Endpunkt auf das gleiche Adress/Port-Tupel ge-mappt. Ein Paket vom gleichen internen Endpunkt an einen anderen Host erzeugt jeweilsein neues Mapping. Ein externer Client kann nur von einem Endpunkt antworten, an dender interne Client bereits ein Paket gesendet hat. Im Beispiel wird nun für die Verbindungzu Client D ein neues Mapping erzeugt.

Mittlerweile sind neben diesen Varianten auch Mischformen entstanden, welche wir in Ab-schnitt 5.1 näher erläutern. Im Rahmen unserer Analyse haben wir ferner untersucht, welcheKombinationen von NAT-Verhalten Hole Punching zulassen. Unsere Resultate haben wir in Ab-schnitt 5.2.1 festgehalten.

4.2. UDP Hole Punching

Unter Hole Punching versteht man eine Technik, um zwischen Clients hinter verschiedenenNATs direkte Punkt-zu-Punkt-Verbindungen herzustellen. Hole Punching funktioniert grund-sätzlich sowohl mit UDP als auch TCP, wobei ersteres etwas robuster und weiter verbreitet ist.Da in unserem Kontext nur UDP relevant ist, beschränken wir uns auf die Beschreibung vonHole Punching mit UDP.

Die grundsätzliche Idee bei Hole Punching ist, dass ein Client ein Paket an eine direkt erreich-bare Adresse im öffentlichen Internet sendet, damit also auf den NAT-Routern ein Mappingerzeugt, und der andere Client dann Pakete direkt an den externen Endpunkt dieses Mappingsschickt. Da dieser Endpunkt grundsätzlich schwierig zu erraten ist, da weder IP-Adresse noch


4.3. Simple Traversal of UDP through NATs (STUN)

UDP-Port bekannt sind, wird ein Mediation Server zu Hilfe genommen. An diesen schickt dererste Client sein erstes UDP-Datagramm.

Dieser Mediation Server befindet sich im öffentlichen Internet und muss von den Clients di-rekt erreichbar sein. Der Mediation Server analysiert das eingehende UDP-Datagramm des Cli-ents und kommuniziert dem anderen Client den Endpunkt (Quell-Adress-Port-Tupel) des erstenClients über einen nicht definierten, beliebigen Kommunikationskanal4.

Hole Punching funktioniert grundsätzlich nur bei Cone NATs. Bei (Port) Restricted ConeNATs ist es notwendig, dass beide Clients einander UDP-Datagramme auf den externen End-punkt des Gegenübers senden, um das NAT-Mapping auf den NAT-Routern für den externenEndpunkt des Gegenübers freizuschalten. Erst wenn diese NAT-Router ein Paket von innen nachaussen gesehen haben, welches für den anderen Endpunkt bestimmt ist, lassen sie Pakete desanderen Endpunktes in eingehender Richtung zu.

Die Klassifizierung von NAT-Varianten sind in Abschnitt 4.1.5 definiert. Hole Punching so-wohl mit UDP als auch TCP ist in [FKS05] ausführlicher beschrieben. Wir befassen uns in Ab-schnitt 5.2 ausführlicher mit den Voraussetzungen für Hole Punching in der Praxis.


Simple Traversal of UDP through NATs (STUN) ist ein einfaches Client/Server-Protokoll, das esClients ermöglicht, sowohl die Anwesenheit als auch den Typ von NATs und Firewalls zwischenihnen und dem öffentlichen Netz zu bestimmen. Die hierbei erkannten NAT-Varianten habenwir bereits in Abschnitt 4.1.5 beschrieben. Ausserdem kann ein Client über STUN eine Adress/-Port-Kombination ermitteln, unter der er potentiell aus dem öffentlichen Netz erreichbar ist.

Um die gewünschten Informationen zu erhalten, ist der Client auf die Hilfe eines öffentlicherreichbaren STUN-Servers angewiesen. Um alle vorgestellten NAT-Varianten abzudecken ver-langt das Protokoll, dass der Server auf vier öffentlichen Adress/Port-Kombinationen erreichbarist (zwei IP-Adressen und jeweils zwei Ports). Dem Client muss allerdings nur eine davon be-kannt sein — die anderen werden ihm falls erforderlich vom Server mitgeteilt.

Es gibt zwei Arten von Nachrichten die ausgetauscht werden. Erstens dienen dem Client Sha-red Secret Requests dazu, vom Server einen temporären Benutzernamen und ein zugehörigesPasswort zu beziehen. Zweitens nutzt der Client Binding Requests um die NAT-Situation zu er-mitteln. Die folgenden beiden Abschnitte beschreiben diese Nachrichtentypen und die entspre-chenden Protokollabläufe etwas genauer.

4Durch die NAT-Situation gegeben, muss dieser Kommunikationskanal vom Client initiert werden. Faktisch handeltes sich also um eine Abfrage des anderen Endpunktes durch den Client beim Mediation Server, beispielsweise überHTTP oder SIP/SDP.


4. Grundlagen

10.0.0.0/8

Client A192.168.1.2

Mediation Server10.10.10.10

Client B192.168.2.2

192.168.1.1

10.1.1.1 10.2.2.1

192.168.2.1A-MS:10.10.10.10:4500192.168.1.2:3456

A-MS:10.10.10.10:4500

10.1.1.1:25000

B-MS:10.10.10.10:4500192.168.2.2:3456

B-MS:10.10.10.10:450010.2.2.1:1026

10.0.0.0/8

Client A192.168.1.2

Client B192.168.2.2

Verbindung zu B anfordern.

1

Vermittlung von B’s Endpunkt:10.2.2.1:1026

2 2 Vermittlung von A’s Endpunkt:10.1.1.1:25000

Paket an A3Paket an B

10.0.0.0/8

Client A192.168.1.2

Mediation Server10.10.10.10

Client B192.168.2.2

192.168.1.1

10.1.1.1 10.2.2.1

192.168.2.1A-B:10.2.2.1:1026

192.168.1.2:3456

B-A:10.1.1.1:25000192.168.2.2:3456

A-B: 10.1.1.1:2500010.2.2.1:1026

Abbildung 4.7.: Hole Punching

4.3.1. Shared Secret Requests

Shared Secret Requests werden über eine mittels Transport Layer Security (TLS) geschützte TCP-Verbindung ausgetauscht. Wie erwähnt, erhält der Client damit temporäre Benutzerdaten diedazu dienen, die folgenden Binding Requests mit einem Keyed-Hash Message AuthenticationCode (HMAC) zu signieren. STUN wurde extra so gestaltet, dass der Server beinahe statelessimplementiert werden kann. Demzufolge wird empfohlen, dass sich die vergebenen Passwör-ter vom Server — und aus naheliegenden Gründen nur von ihm — jederzeit aus dem offenübermittelten Benutzernamen generieren lassen sollen (z.B. mittels eines weiteren HMAC). DieSignierung von Paketen ist optional, wird zur Vermeidung von möglichen Attacken aber empfoh-len. Prinzipiell erlaubt STUN auch, dass die Benutzerdaten über irgendeinen beliebigen anderenWeg ausgetauscht werden. Ein konformer STUN-Server muss allerdings die eben beschriebene



Methode mit TLS unterstützen.

4.3.2. Binding Requests

Binding Requests werden mittels UDP an den Server gesendet. Wenn ein Binding Request beimSTUN-Server eintrifft, hat dieser Request möglicherweise bereits eines oder mehrere NATs zwi-schen Client und Server traversiert. Als Resultat entspricht die Source-Adresse des vom Serverempfangenen Requests demjenigen Mapping, welches das dem Server am nächsten gelegene NATerstellt hat. Im einfachsten Fall wird der Server diese IP-Adresse und den Port in eine Binding Re-sponse verpacken und dem Client an dieselbe Adresse zurücksenden. Diese Antwort wird für allevorgestellten Klassifizierung von NAT-Varianten vom Client empfangen. Über Flags und Attribu-te im Binding Request kann der Server angewiesen werden, sein Verhalten leicht zu variieren undbeispielsweise von einer anderen IP-Adresse zu antworten. Der Server teilt dem Client in jederBinding Response mit, von welcher Adresse und welchem Port er geantwortet hätte, falls derClient eine Änderung derselben angefordert hätte.

4.3.3. Ablauf

Das Protokoll ist recht flexibel. Ein typischer Ablauf sieht etwa wie folgt aus. Der Client sendetwie oben beschrieben einen Binding Request an den Server. Sobald der Client die vom Serverreflektierte Binding Response erhält, vergleicht er die Adresse und den Port im Paket mit derlokalen Adresse und dem Port, von denen aus er seinen Request gesendet hat. Falls diese nichtübereinstimmen, weiss der Client, dass er hinter mindestens einem NAT liegt. Hinter welchemTyp NAT steht jedoch noch nicht fest. Um dies festzustellen sendet der Client weitere BindingRequests.

Der Client wird also einen zweiten Binding Request absetzen, diesmal allerdings an eine andereIP-Adresse als zuvor — jedoch vom selben lokalen Endpunkt. Falls sich die Adresse oder der Portin der Antwort von derjenigen unterscheiden, die er in der ersten Binding Response erhalten hat,weiss der Client, dass er hinter einem symmetrischen NAT liegt.

Um festzustellen, ob der Client hinter einem Full-Cone-NAT liegt, kann er einen Binding Re-quest mit entsprechenden Flags senden, die den Server anweisen, die Antwort von einer anderenAdresse und einem anderen Port zu senden als der Request empfangen wurde. Falls der Clientdie Antwort erhält, weiss er, dass er hinter einem Full-Cone-NAT liegt. Des Weiteren kann derClient den Server anweisen, nur den Port, nicht aber die Adresse zu ändern, auf der er den Re-quest empfangen hat. Damit kann ein Client herausfinden, ob er hinter einem Port-Restricted-NAT oder nur hinter einem Restricted-NAT liegt.

Damit sind die Möglichkeiten des Protokolls noch nicht erschöpft. So ist es dem Client bei-spielsweise auch möglich, den Server anzuweisen, seine Antwort nicht nur von einer anderenAdresse sondern auch an eine andere Adresse, zu senden. Ausführliche Informationen zu STUNkönnen [RFC3489] entnommen werden.


4. Grundlagen

In Abschnitt 5.1 beschreiben wir eine einfache Variante von STUN die wir in Ruby implemen-tiert haben.

4.4. Traversal Using Relay NAT (TURN)

Wie im vorhergehenden Abschnitt beschrieben, ermöglicht STUN einem Client eine Transport-adresse zu ermitteln, unter der er aus dem öffentlichen Netz erreichbar ist. Wie bereits erwähnt,kann dieses Mapping allerdings nicht in jedem Fall direkt verwendet werden (siehe dazu auchAbschnitt 5.2.1).

Traversal Using Relay NAT (TURN) ist nun ein Protokoll, welches auch einem Client hinter ei-nem symmetrischen NAT oder einer Firewall erlaubt, eingehende Daten zu empfangen. Das Zielvon TURN ist es, dem Client auch in diesen Situationen ein öffentlich erreichbares Adress/Port-Tupel zu vermitteln. Die einzige Möglichkeit dies in jedem Fall zu erreichen ist, die Daten übereinen im öffentlichen Netz erreichbaren TURN-Server zu leiten. Dazu kann ein Client auf demTURN-Server einen Endpunkt verlangen unter dem er dann öffentlich erreichbar sein wird. DerServer wird die Pakete dann jeweils zum Client weiterleiten.

Die Sicherheitsfunktionen von NATs und Firewalls werden dabei nicht unterlaufen, dennTURN verhält sich wie ein Port-Restricted-NAT. Für den Client, der via TURN einen Endpunktauf dem Server alloziert hat, bedeutet dies, dass er erst ein Paket an diejenigen Clients sendenmuss, von denen er Pakete empfangen möchte. Der Betrieb von Servern auf Well-Known-Portshinter einem NAT ist damit also nicht möglich. Im Übrigen funktioniert TURN sowohl mit UDPals auch TCP.

Das Protokoll basiert auf STUN, teilt mit ihm die Nachrichtenstruktur und die grundlegen-den Mechanismen. Dies ist mit der Absicht verbunden, den Aufwand eine bestehende STUN-Implementation um TURN zu erweitern, möglichst gering zu halten.

Ursprünglich wurde TURN im Draft [RMH05] veröffentlicht. Mittlerweile wurde es mit demneuen Draft [RMH06] komplett in STUN integriert. Weitere Details können besagtem Draftentnommen werden.

Limitationen

TURN ermöglicht zwar immer eine Verbindung herzustellen, durch die Umleitung des gesamtenVerkehrs über den TURN-Server wird dieser jedoch stark belastet. Somit sollte TURN nur als al-lerletzte Möglichkeit angesehen werden, falls also andere Methoden wie STUN nicht zum Erfolgführen. Das im folgenden Abschnitt beschriebene ICE-Protokoll soll genau hier einspringen unddie jeweils beste Verbindungsmethode ermitteln.


4.5. Interactive Connectivity Establishment (ICE)

4.5. Interactive Connectivity Establishment (ICE)

Interactive Connectivity Establishment (ICE) ist ein Protokoll, welches aufbauend auf STUNund TURN (vgl. Abschnitte 4.3 und 4.4) die direkte Kommunikation zwischen Session Initia-tion Protocol (SIP) Clients ermöglicht. ICE spezifiziert im Wesentlichen, wie zwei SIP-Clientsvorgehen müssen, damit sie eine möglichst optimale Direktverbindung zwischeneinander auf-bauen können. Zu diesem Zweck tauschen die Clients vorgängig Informationen in Form vonErweiterungen zu Session Description Protocol (SDP) über die SIP-Serverinfrastruktur aus.

Zwar ist ICE nicht nur für SIP konzipiert, sondern wäre grundsätzlich für alle Anwendungengeeignet, welche über einen Kontrollkanal via Drittserver (Mediation Server) Direktverbindun-gen zwischen Endknoten hinter NAT herstellen. Doch der momentan vorliegende Draft der Mul-tiparty Multimedia Session Control (MMUSIC) Working Group (WG) der Internet EngineeringTask Force (IETF) baut sehr spezifisch auf SIP auf und ist eng mit SDP [RFC3264] verknüpft, sodass er sich nur bedingt für andere Anwendungsgebiete adaptieren lässt.

Der Ablauf von ICE lässt sich wie folgt zusammenfassen:

1. Beide Clients erzeugen eine Liste all ihrer Adress-Port-Tupel, über welche sie potentiellerreichbar sein könnten. Dies beinhaltet:

• Adress-Port-Kombinationen aller lokalen Interfaces,

• Über STUN in Erfahrung gebrachte externe Adress-Port-Tupel, sowie

• Über TURN erzeugte Adress-Port-Tupel, welche als Relay dienen könnten.

2. Beide Clients sortieren ihre Listen nach genau definierten Kriterien. Lokale Endpunktewerden gegenüber STUN präferiert, und TURN besitzt die tiefste Priorität.

3. Die Clients tauschen ihre Listen über den Kontrollkanal (SIP) aus.

4. Beide Clients versuchen nun nach definierten Regeln, ihren Peer über alle möglichen Kom-binationen von eigenen und fremden Endpunkten zu erreichen, in Reihenfolge der verge-benen Prioritäten. 5 Die erste Kombination, welche erfolgreich zu einer Verbindung führt,wird verwendet. Für diese Verbindungsaufnahme wird eine Modifikation von STUN ver-wendet.

Es sind im Draft zu ICE alle Aspekte dieses Vorgangs genau spezifiziert. Für weitere Detailsverweisen wir auf [Ros06].

5Durch die sukzessiven Verbindungsversuche an die nach genauen Regeln sortierten Listen wird implizit auch UDPHole Punching praktiziert (siehe Abschnitt 4.2).


4. Grundlagen

4.6. Internet Protocol Security (IPsec)

Internet Protocol Security (IPsec) ist eine umfassende Sicherheitsarchitektur für IP-basierte Netz-werke. IPsec ist die Lösung, welche von der IETF entwickelt wurde, um der mangelnden Sicher-heit im Internet-Protokoll zu begegnen. IPsec ist zwingender Bestandteil von IPv6, bei IPv4 abernoch optionaler Zusatz.

Eine häufige Anwendung von IPsec sind VPNs. Ein VPN ist ein virtuelles sicheres Netzwerk,dessen Datenpakete anstelle eines physikalischen Mediums über ein anderes, öffentliches undgrundsätzlich nicht vertrauenswürdiges Netz transportiert wird.

IPsec arbeitet im Gegensatz zu SSL/TLS, SSH, PGP und anderen Lösungen direkt auf demNetwork Layer und stattet diesen unter Verwendung von starker Kryptographie mit Sicherheits-attributen wie Vertraulichkeit, Integrität und Authentizität aus. Realisiert wird das auf dieser Ebe-ne mit den Protokollen Encapsulating Security Payload (ESP) und Authentication Header (AH),welche sich zwischen dem Link und dem Network Layer einfügen, also im heute häufigsten Fallzwischen Ethernet und IP. [wik]

Die kryptographischen Parameter (verwendete Algorithmen und Schlüssel) können entwederstatisch konfiguriert oder dynamisch über einen Schlüssel- und Konfigurationsparameteraus-tausch zwischen miteinander kommunizierenden Hosts abgemacht werden. Dieser Austauschgeschieht über das Protokoll Internet Key Exchange (IKE), welches ebenfalls zur IPsec-Gesamtar-chitektur gehört.

Für eine weitergehende Dokumentation von Internet Protocol Security als Gesamtsystem ver-weisen wir auf [RFC2401].

4.6.1. AH, ESP, Tunnel und Transport Mode

Authentication Header (AH) bietet Authentizität, Integrität und Schutz vor Replay-Attacken, ver-schlüsselt die Daten aber nicht. AH schützt alle invarianten Header-Felder sowie die Nutzdaten.AH ist in [RFC2402] ausführlich dokumentiert.

Encapsulating Security Payload (ESP) bietet Vertraulichkeit, Authentizität, Integrität sowieSchutz vor Replay-Attacken. Der Schutz deckt aber nicht wie bei AH auch Header-Felder ab,sondern nur die Nutzdaten. ESP ist in [RFC2406] ausführlich dokumentiert.

Pad

IP Daten

IP AH Daten

authentisiert

IP Daten

IP ESP Daten

authentisiert

ESP-Tr.

verschlüsselt

ESP-Auth

Abbildung 4.8.: AH/ESP in Transport Mode

Beide Protokolle können in zwei unterschiedlichen Anwendungsmodi betrieben werden: Trans-



port Mode (Abb. 4.8) und Tunnel Mode (Abb. 4.9). Wie aus den Abbildungen ersichtlich ist,wird beim Transport Mode direkt das Nutzpaket mit AH und/oder ESP ausgestattet, d.h. derursprüngliche IP-Header bleibt erhalten, während im Tunnel Mode das komplette Paket inklu-sive IP-Header in ein AH- oder ESP-Paket verpackt und dieses mit einem neuen, äusseren IP-Header versehen wird. Tunnel Mode eignet sich deshalb, um Virtual Private Networks mit vir-tueller Adressierung zu implementieren, während Transport Mode mit weniger Overhead direktdie normale Host-Host-Kommunikation schützen kann. Man kann aber sagen, dass der Trans-port Mode eigentlich überflüssig ist, weil man die gleiche Funktionalität auch mit dem TunnelMode erreichen kann. Mit derselben Argumentation wird oft auch AH für überflüssig erklärt, damit ESP in Tunnel Mode die gleiche Sicherheit erreicht werden kann und AH ohne ESP in derPraxis praktisch nicht eingesetzt wird.

PadIP

Daten

IPneu AH Daten

authentisiert

IP Daten

IPneu ESP Daten

authentisiert

ESP-Tr.

verschlüsselt

IP

IP ESP-Auth

Abbildung 4.9.: AH/ESP in Tunnel Mode

4.6.2. Security Associations, Policies, SPI

Der IPsec-Standard definiert eine Security Association (SA) als die Parameter, welche eine IPsec-Verbindung beschreiben. Eine SA wird lokal durch das Tripel Security Parameter Index (SPI), IP-Adresse des Ziels sowie das verwendete Protokoll (AH oder ESP) eindeutig identifiziert. Zur SAgehören neben diesem Tripel auch alle Konfigurationsparameter, also Eigenschaften wie verwen-dete kryptographische Algorithmen und Schlüssel.

Jeder Host speichert die SAs in einer sogenannten Security Association Database (SADB) ab.Dies ist im Grunde genommen lediglich ein in der Regel auf Kernelebene implementierter Spei-cher, in welchem alle auf einer Maschine aktiven SAs abgelegt sind. Zugriff erfolgt über denPrimärschlüssel (SPI, Destination Address, Protocol).

Der Security Parameter Index (SPI) ist ein zufälliger Wert, der zur Identifikation einer ESP-,AH- oder IKE-SA dient. Dieser Wert muss lokal eindeutig sein und wird in sämtlichen Paketenübermittelt, damit die Gegenseite das Paket einer Verbindung zuordnen kann.

Es wird ferner im Kontext von IKEv2 unterschieden zwischen einer IKE-SA und einer Child-SA. Die IKE-SA schützt die IKE-Verbindung selber, während die Child-SA die eigentlichen SAsder Nutzverbindungen darstellen.

Während eine SA alle Informationen beinhaltet, um eine IPsec-Verbindung zu nutzen und Pa-kete entsprechend zu sichern, ist in der SA aber noch nicht definiert, welcher IP-Verkehr über eine


4. Grundlagen

IPsec-Verbindung geleitet werden soll. Diese Information ist in der sogenannten IPsec-Policy de-finiert. Eine solche Policy legt beispielsweise fest, dass jeglicher Datenverkehr von 192.168.0.1nach 192.168.1.7 durch die IPsec-SA 1 geschützt werden soll. Policies können auch pro SocketRegeln definieren, um beispielsweise die Pakete eines Sockets speziell zu behandeln.

Diese Konzepte sind in [RFC2401] ausführlicher beschrieben. Die Zuordnung von Policies zuSecurity Association geschieht in der IPsec-Implementierung von Linux 2.6 über die sogenanntereqid.

4.6.3. Internet Key Exchange Version 2 (IKEv2)

Das Internet Key Exchange (IKE) Protokoll dient der automatischen Verwaltung von SecurityAssociations. Es tauscht zwischen Peers alle nötigen Parameter aus, damit diese untereinanderIPsec-Verbindungen aufbauen können. Es führt zu diesem Zweck eine Authentisierung der Ver-bindungsteilnehmer durch, erzeugt eine IKE-SA, um die IKE-Verbindung selber zu schützen undkann anschliessend für die Aushandlung von neuen IPsec-Nutzverbindungen verwendet werden(Child-SAs).

IKEv1 basiert auf einem Framework mit dem Namen Internet Security Association and KeyManagement Protocol (ISAKMP) und ist in den zwei Standards ISAKMP [RFC2408] und derIPsec Domain of Interpretation (DOI) für ISAKMP [RFC2407] definiert. IKEv2 ist die neue,verbesserte Generation des Protokolls, definiert in [RFC4306]. IKE basiert in beiden Versionenauf UDP-Datagrammen auf dem dafür vorgesehenen Port 500.

Gegenüber IKEv1 besitzt IKEv2 einige Vorteile. So ist es weniger komplex, flexibler und durchnur einen einzigen Standard komplett beschrieben. Wir stellen die Funktionsweise von IKEv2 imFolgenden ganz kurz vor, soweit es für das Verständnis von NAT-T, Dead Peer Detection (DPD)sowie unserer Erweiterungen im Rahmen von P2P-NAT-T notwendig ist, und verweisen für dievollständige Beschreibung des Protokolls neben dem bereits erwähnten RFC auf die hervorran-gende Diplomarbeit von Jan Hutter und Martin Willi [HW05].

Derjenige Host, welcher die IKE-Verbindung initiert, wird in Bezug auf diese IKE-VerbindungInitiator genannt, die andere Seite Responder.

Der Verbindungsaufbau geschieht über die zwei Exchanges IKE_SA_INIT und IKE_AUTH.IKE_SA_INIT dient zur Erzeugung der IKE-SA, also dazu, den Schutz der IKE-Verbindungzu initialisieren. Ab IKE_AUTH findet der Meldungsaustausch verschlüsselt und geschützt statt.IKE_AUTH dient primär der gegenseitigen Authentifizierung, sekundär wird aber auch gleichnoch eine erste Child-SA ausgehandelt. Ab dann gilt die Verbindung als zustande gekommen(established). Mit dem Austausch CREATE_CHILD_SAwerden dann bei Bedarf weitere Child-SAserzeugt. In Fehlersituationen oder für Zusatzfunktionalität wie automatische Mode Config findetein INFORMATIONAL-Exchange statt. Beispielhaft für verschiedene mögliche INFORMATIONAL-Exchanges ist in Abbildung 4.10 ein Austausch eines Notify-Payloads dargestellt. So werden mitINFORMATIONAL-Exchanges beispielsweise Ausnahmesituationen signalisiert, SAs gelöscht oder



Rekeying initiert.

HDR SAi1 KEi Ni

IKE_SA_INIT Request

HDR SAr1 KEr Nr

IKE_SA_INIT Response

CertReq

HDR IDi Cert CertReq

IKE_AUTH Request

IDr AUTH SAi2 TSi TSr

HDR IDr Cert AUTH

IKE_AUTH Response

SAr2 TSi TSr

HDR Ni

KEi

CREATE_CHILD_SA Request

TSi TSr

HDR N

INFORMATIONAL Request (Notify)

HDR N

INFORMATIONAL Response (Notify)

HDR SA Nr

CREATE_CHILD_SA Response

TSi TSr

SA

KEr

Initiator Responder

verschlüsselt

Abbildung 4.10.: IKEv2 Meldungsaustausch mit Payloads

4.6.4. NAT Traversal (NAT-T)

NAT Traversal (NAT-T) ist bei IKEv2 im Gegensatz zu IKEv1 nicht mehr ein separater Standard(vgl. [RFC3947]) sondern integrierter Bestandteil. NAT-T besteht im Wesentlichen aus einemVerfahren, ein NAT zu detektieren (NAT Detection (NAT-D)), eine Methode, die IKE-, ESP- undAH-Pakete in einem UDP-Paket zu verpacken, um sie “NAT-kompatibel” zu machen (UDP En-capsulation), und dem Senden von speziellen Paketen, um Timeouts von Verbindungsdaten aufNAT-Routern zu verhindern (NAT Keepalives).

Weil beim ursprünglichen Design von IPsec nicht damit gerechnet wurde, dass IP-Adressenund UDP/TCP-Ports unterwegs verändert werden, treten hier grosse Probleme auf. Bei AH isthier sofort Schluss, weil die durch NAT veränderten Daten durch den HMAC kryptographischgesichert sind. Bei ESP hingegen ist der UDP- oder TCP-Header für den NAT-Router gar nichtunverschlüsselt sichtbar. Es kann also gar kein NAPT stattfinden.

Primitive Lösungen beinhalten in der Regel einfach die fixe Weiterleitung von AH, ESP undIKE (Passthrough) an einen fixen Host hinter NAT. Was automatisch bedeutet, dass nur eineinziger Host hinter einem NAT-Router per IPsec kommunizieren kann. Weil für IKEv1 derQuellport zwingend auch Port 500 sein musste, beinhaltet diese IPsec-Passthrough-Funktiona-lität auch, dass IKE nicht dem normalen NAT unterzogen wird. Bei IKEv2 ist dies jedoch eherhinderlich als förderlich, denn IKEv2 würde auf Port 500 normal funktionieren, wenn die Paketevom NAT-Router normal genattet würden. Deshalb benötigt auch IKEv2 selber Massnahmen fürNAT Traversal.


4. Grundlagen

Ein wichtiges Merkmal von NAT Traversal ist die Notwendigkeit, IKEv2-Pakete mit beliebi-gen Source Ports zu akzeptieren, und die Source-Adressen und -Ports einer IKE-Verbindung zuaktualisieren, wenn sie während der Lebenszeit der Verbindung ändern. Source-Adressen und -Ports können beispielsweise ändern, wenn ein NAT-Router neu gestartet wird.

NAT Detection (NAT-D)

Um erkennen zu können, ob sich die eigene oder die andere Seite hinter einem NAT irgendwel-cher Art befindet, werden mit im IKE_SA_INIT-Request und der Antwort darauf spezielle NATDetection (NAT-D) Payloads mitübertragen. Diese erlauben der Gegenseite herauszufinden, obdas IP-Paket von der Gegenseite mit den gleichen IP-Adressen und UDP-Ports empfangen wur-de wie es losgeschickt wurde. Man will also erkennen, ob die Source und/oder die Destination IP-Adressen und UDP-Ports unterwegs durch ein NAT verändert worden sind. Diese NAT-D-Pay-loads werden in den IKE_SA_INIT-Messages unmittelbar nach dem Nonce-Payload eingefügt,wie in Abbildung 4.11 ersichtlich.

HDR SAi1 KEi Ni

IKE_SA_INIT Request

HDR SAr1 KEr Nr

IKE_SA_INIT Response

CertReq

N NAT-D SRC N NAT-D SRC N NAT-D SRC

N NAT-D SRC N NAT-D DST

N NAT-D DST

Abbildung 4.11.: NAT-Detection Payloads

Für diese NAT-D Payloads verwendet man die Notify-Payloads der Typen NAT_DETECTION_SOURCE_IP und NAT_DETECTION_DESTINATION_IP. Der Aufbau eines solchen Payloads ist inAbbildung 4.12 dargestellt. Im Datenfeld der Notify-Payloads wird ein NAT-D-Hash übertragen,der aus dem SHA-1-Hash der beiden SPIs, der IP-Adresse sowie dem UDP-Port gebildet wird:

NAT-D-Hash = HSHA-1(SPIi||SPIr ||IP-Adresse||UDP-Port)

Da der Initiator nicht in jedem Fall weiss, welche seiner unter Umständen mehrerer IP-Adres-sen als Absender-Adresse verwendet werden wird, beispielsweise im Falle von mehreren Netz-werk-Interfaces, darf der Initiator mehrere NAT-D-Payloads des Typs NAT_DETECTION_SOURCE_IP senden. Der Responder muss dann jedes dieser Payloads auf Übereinstimmung prüfen. Istkeines mit dem Hash identisch, der sich aus der Adress/Port-Kombination des erhaltenen Paketsberechnet, so steckt der Initiator hinter einem NAT.

UDP Encapsulation

Wird ein NAT detektiert, so wird in IKEv2 sofort auf Port 4500 gewechselt, und anstatt ESP-Pakete direkt zu verschicken, werden sie mit einem zusätzlichen UDP-Header versehen, ebenfalls



nicht verwendet

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 11 2 3

Next Payload Payload Length

Protocol ID Notify Message Type

C Reserved

SPI Size

Security Parameter Index (SPI)

Notification Data

xxx xxx

0 NAT_DETECTION_SOURCE_IP

x xxx

0

NAT-D Hash

Abbildung 4.12.: Aufbau Notify-Payload für NAT-Detection

mit Source und Destination Port 4500. Diesen Vorgang nennt man UDP Encapsulation. DamitESP und IKE-Pakete auf Port 4500 unterschieden werden können, wird IKE-Paketen ein Non-ESP-Marker vorangestellt, welcher aus 4 Null-Bytes besteht. Den Paketaufbau dieser Pakete mitUDP Encapsulation haben wir in Abbildung 4.13 dargestellt, während Abbildung 4.14 den Non-ESP Marker veranschaulicht.

PadIPneu ESP Daten ESP-Tr.IP ESP-AuthUDP

PadIPneu ESP Daten ESP-Tr.IP ESP-Auth

PadIP ESP Daten ESP-Tr. ESP-Auth

PadIP ESP Daten ESP-Tr. ESP-AuthUDP

Transport Mode

Tunnel Mode

IKE

IP UDP IKE

IP UDP IKE0

Abbildung 4.13.: UDP-Encapsulation

IPneu ESPUDP

IP UDP 0000 IKE

SPI . . .

. . .

Abbildung 4.14.: Non-ESP Marker

Dieser Wechsel auf Port 4500, auch Port Float genannt, ist erst seit Draft 06 von [RFC3948]im Standard. Der Non-ESP-Marker wurde in Draft 00/01 von [RFC3947] erstmals definiert. Esexistieren auch Implementationen von älteren Standards, wie z.B. die Cisco-Variante mit ESP inUDP auf Port 10000.


4. Grundlagen

NAT Keepalives

Wie wir in Abschnitt 4.1.2 erläutert haben, führen NAT-Router eine Tabelle über alle aktivenVerbindungen. Diese Tabelleneinträge werden nach einer gewissen Zeit der Inaktivität gelöscht.Damit diese Mappings nicht gelöscht werden, wird von einem Peer hinter einem NAT periodischalle 20 Sekunden ein NAT Keepalive Paket gesendet. Das ist ein nach den im Abschnitt 4.6.4beschriebenen Regeln verpacktes Datenbyte 0xFF, ohne vorangestelltem Non-ESP Marker. Einsolches Paket haben wir in Abbildung 4.15 dargestellt.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 11 2 3

Source Port Destination Port

Length Checksum

0xFF

UDP Header

Data

Abbildung 4.15.: NAT-Keepalive

4.6.5. Dead Peer Detection (DPD)

Wie NAT Traversal auch ist Dead Peer Detection (DPD) ein integraler Bestandteil von IKEv2geworden, was bei IKEv1 noch nicht der Fall war (vgl. [RFC3706]).

IKE ist ein UDP basiertes Protokoll, das sehr wenig Pakete über sehr lange Zeit austauscht.Ohne spezielle Massnahmen zu ergreifen, würde man erst Stunden später erkennen, wenn derHost am anderen Ende einer IKE-Verbindung nicht mehr aktiv ist.

Da es aber wünschenswert ist, auf den Ausfall einer IKE-Verbindung innert nützlicher Fristreagieren zu können, möchte man mit Hilfe von Dead Peer Detection periodisch Meldungenaustauschen. Wird ein solcher DPD-Request nicht beantwortet, wird angenommen, der Peer seinicht mehr aktiv, und entsprechend reagiert. Möglichkeiten sind beispielsweise die Verbindungneu zu initieren, die Verbindung zu löschen, oder auf Wartestatus (“hold”) zu setzen.

Auf Protokollebene wird hierfür ein leerer INFORMATIONAL-Exchange verwendet, wenn für ei-ne festgelegte Zeit keine IKE-Messages mehr empfangen wurden. Wenn dieser INFORMATIONAL-Request ohne Payloads trotz Resends nicht quittiert wird, wird angenommen, dass die Gegen-stelle nicht mehr aktiv ist, und entsprechend reagiert. Grundsätzlich ist DPD symmetrisch undfreiwillig, es ist also möglich, dass nur eine Seite DPD verwendet, die andere nicht, oder dassbeide Seiten DPD verwenden.


5. Analyse

Um die Problemstellung zu analysieren und Lösungsansätze auf ihre Tauglichkeit hin zu überprü-fen, haben wir mit Hilfe von rasch und unkompliziert implementierbaren Prototypen gearbeitet,welche wir in der objektorientierten Script-Sprache Ruby entwickelt haben. Ruby eignet sich auf-grund seiner Eigenschaften sehr gut für derartige Prototypen. Für weitere Informationen überRuby verweisen wir auf [TH00].

5.1. STUN in Ruby

Um verschiedene NAT-Implementationen auf ihre Eigenschaften hin zu prüfen, haben wir ei-ne stark vereinfachte Variante von STUN in Ruby implementiert. Wir haben nicht das gesamteProtokoll implementiert, sondern nur die grundsätzlichen Ideen übernommen. Den bereits inAbschnitt 4.3 vorgestellten grundsätzlichen Ablauf von STUN haben wir etwas erweitert, umauch zwei speziellere NAT-Implementationen (Cisco IOS, Netfilter) zu erkennen. Im Folgendenstellen wir zuerst das vereinfachte Protokoll und anschliessend den Ablauf vor.

5.1.1. Protokoll

Das von uns implementierte Protokoll basiert wie STUN auf UDP. Die ausgetauschten Nachrich-ten selbst sind einfache Zeichenfolgen. Es gibt vier mögliche Requests, die ein Client dem Serversenden kann: “”, “a”, “p” und “b”. Sie teilen dem Server mit, von welchem Endpunkt er antwortensoll. Entsprechend [RFC3489] ist ein STUN-Server auf vier öffentlichen Endpunkten erreichbar.Zwei IP-Adressen, D1 und D2, und jeweils zwei Ports, P1 und P2, ergeben die Endpunkte: D1:P1,D1:P2, D2:P1 und D2:P2. Erhält der Server beispielsweise eine Nachricht auf D1:P1, so antworteter wie folgt auf die verschiedenen Anfragen hin: “”→D1:P1, “a”→D2:P1, “p”→D1:P2 und “b”→ D2:P2. Dem Client ist nur der erste dieser Endpunkte bekannt — die Alternativen teilt ihmder Server mit.

Die Antwort des Servers besteht aus zwei Endpunkten, die der Server mit einem “|” getrenntaneinander fügt. Der erste Endpunkt ist derjenige von dem der Server den Request erhalten hat,also der externe Endpunkt, falls sich der Client hinter einem NAT befindet. Der zweite ist deralternative Endpunkt auf dem der Server erreichbar ist (D2:P2). Eine solche Antwort könnte wiefolgt aussehen: “10.0.2.1:35212|10.0.10.12:4478”.

29

5. Analyse

Wie gesehen ist das Protokoll wirklich sehr einfach und auf das Nötigste reduziert. Aber eserfüllt seinen Zweck, den wir im folgenden Abschnitt erläutern.

5.1.2. Ablauf

Um alle möglichen NAT-Varianten zu bestimmen, führen wir eine Reihe von Tests durch. Wirversenden nacheinander Requests an den Server und analysieren die Antworten — falls wir wel-che erhalten.

Um die Tests durchführen zu können, muss der Server, wie erwähnt, über zwei öffentlich er-reichbare IP-Adressen verfügen. Damit lassen sich alle in Abschnitt 4.1.5 vorgestellten NAT-Va-rianten detektieren. Um auch zwei speziellere Implementationen zu erkennen, ist es zusätzlichnötig, dass auch der Client über zwei IP-Adressen verfügen kann.

Ein Überblick über den kompletten Ablauf bietet Abbildung 5.1. Jede rechteckige Box stelltdabei eine versandte Nachricht dar. Je nachdem ob wir eine Antwort erhalten oder nicht fahrenwir unterschiedlich fort. Kommen wir zu einem Resultat (abgerundete Boxen), wird dieses aufder Konsole ausgegeben. Sehen wir uns den Ablauf aus der Sicht des Clients Schritt für Schrittan:

Wir beginnen mit einem initialen Paket an den einzigen uns bekannten Endpunkt D1:P1. Be-kommen wir schon auf dieses Paket keine Antwort, ist es sehr wahrscheinlich, dass entweder derServer nicht erreichbar ist oder aus- bzw. eingehende UDP-Pakete von einer Firewall blockiertwerden.

Kommt die Antwort an, merken wir uns den vom Server retournierten Endpunkt und ver-gleichen ihn mit demjenigen, über welchen wir den Request abgeschickt haben. Falls sich dieEndpunkte nicht unterscheiden, steht fest, dass wir uns nicht hinter einem NAT befinden. Eskann jedoch sein, dass wir durch eine Stateful Firewall geschützt sind. Diese würde nur Paketedurchlassen, welche von Endpunkten kommen, an die wir unsererseits bereits Pakete gesendethaben. Um dies zu prüfen, veranlassen wir den Server mit einer zweiten Nachricht von D2:P2zu antworten. Kommt dieses Paket nicht an, liegt eine Firewall zwischen uns und dem Server,andernfalls sind wir direkt erreichbar.

Hat sich der Endpunkt geändert, wissen wir, dass wir uns hinter einem NAT befinden. Wir te-sten zuerst, ob wir uns hinter einem Full-Cone-NAT befinden. Dies lässt sich mit demselben Testverifizieren, den wir eben beschrieben haben. Wir lassen also den Server von D2:P2 antworten.Erhalten wir die Antwort, steht fest, dass wir für einen beliebigen Host über diesen öffentlichenEndpunkt erreichbar sind. Falls wir die Antwort nicht erhalten, fahren wir wie folgt fort.

Wir senden ein leeres Paket an den Endpunkt D2:P2. Da unsere erste Anfrage an D1:P1 be-antwortet wurde, erwarten wir auch in diesem Fall eine Antwort zu bekommen. Wir vergleichenden erhaltenen Endpunkt mit dem zuvor gemerkten reflektierten Endpunkt. Unterscheiden sichdiese, liegt es nahe, ein symmetrisches NAT zu vermuten. Im anderen Fall vermuten wir ein re-striktives NAT, wobei der genaue Typ noch zu bestimmen ist. Ob wir nur ein Restricted-NAT


5.1. STUN in Ruby

S1 => D1:P1 UDP blockiert?

NeinEndpunkt geändert?

Nein

S1 => D1:P1 (B)

S1 => D1:P1 (B)

Nein

Ja

Ja Kein NAT

Stateful Firewall

Full Cone NAT

Nein

Ja

S1 => D2:P2 Fehler!!!

Ja

Nein


S2 => D2:P1

S1 => D1:P1 (P)

Ja

Ja


Ja

Netfilter-like NAT

Symmetric NAT

Restricted NATJa

S2 => D2:P2

Nein

Ja


Ja

Port Restricted NAT

Cisco-like NAT

Ja

Wechsel aufzweite IP Adresse

S2 => D1:P1S2 => D1:P1

Ja Ja

Fehler!!!Nein Fehler!!!Nein

EndpunkteS1 Source IP 1S2 Source IP 2D1 Destination IP 1D2 Destination IP 2P1 Port 1P2 Port 2

Anforderung an den Server:B wechsle IP-Adresse and PortP wechsle Port

Notation:S1 => D1:P1 (B)Paket von Endpunkt S1 an den Endpunkt D1:P1 wobei der Server aufgefordert wird von D2:P2 zu antworten.

Legende

Nein Nein

Abbildung 5.1.: STUN in Ruby


5. Analyse

vorliegen haben, lässt sich mit folgendem Test einfach bestimmen: Wir senden erneut eine Nach-richt an D1:P1, lassen den Server nun aber von D1:P2 antworten. Kommt die Antwort an, scheintdie NAT-Implementation lediglich bezüglich der IP-Adresse Restriktionen zu haben — es liegtalso ein Restricted-NAT vor. Erhalten wir keine Antwort, deutet dies auf ein Port-Restricted-NAThin. In diesem Fall, wie auch im symmetrischen, lassen sich mit erweiterten Tests noch zwei wei-tere Implementationen unterscheiden. Diese stellen wir in den folgenden Unterabschnitten vorund sehen danach, wie wir sie erkennen können.

Netfilter

Die NAT-Implementation der Linux-Firewall (Netfilter) lässt sich prinzipiell in die Klasse derPort-Restricted-NATs einordnen. Dies mag erstaunen, wenn man sich das Diagramm in Abbil-dung 5.1 ansieht Es sind denn auch zwei Eigenschaften, die Netfilter etwas von anderen Expo-nenten dieser Klasse unterscheiden.

Sehen wir uns zuerst den Algorithmus an, den Netfilter zur Erzeugung von NAT-Mappingsverwendet. Für unsere Zwecke zwar unproblematisch, kann sein Ergebnis doch für Verwirrungsorgen, weshalb wir ihn nicht undokumentiert lassen wollten (als Quelle diente uns [Rus04]):

1. Suche nach einer benutzerdefinierten Regel, welche definiert, in welcher Adress- bzw. Port-Range die durch NAT umgeschriebenen Adressen/Ports liegen sollen.

2. Suche in einer Hashtabelle aufgrund von (PROTO, SRC IP, SRC Port) nach einem beste-henden Mapping von dieser Quelle. Wird eines gefunden, welches in obigem Range liegt,wird dieses wie folgt getestet. Falls auf dieses Mapping eindeutig geantwortet werden kann,falls also (PROTO, DST IP, DST Port, mapped SRC IP, mapped SRC Port) nicht bereitsin der Connection Tracking Table (Conntrack-Table) eingetragen ist, ist der Algorithmusfertig und dieses Mapping wird genommen.

3. Als nächstes wird versucht ein Mapping zu finden, welches den Source Port nicht ändert.Es wird also SRC IP mit jeder IP-Adresse im Range ersetzt und nach obigem Prinzip gete-stet. Ist dieser Test erfolgreich, wird dieses Mapping genommen und der Algorithmus istfertig.

4. Nun wird auch versucht, den Source Port zu variieren. privilegierte Ports werden hierbeigetrennt von den hohen, unprivilegierten Ports behandelt. Klappt dies nicht, wird alsokein passender Source Port gefunden, wird die Verbindung zurückgewiesen.

An einem Beispiel lassen sich diese Regeln leicht nachvollziehen: Wir gehen von zwei Hosts Aund B aus, welche durch NAT N die Web-Server Sa, Sb und Sc erreichen wollen.

Erst die vierte Verbindung erzeugt nach obigen Regeln ein neues externes Mapping. Als Be-gründung für diesen Designentscheid werden von Rusty Russel zwei Motive angeführt: Erstens


5.1. STUN in Ruby

A:55000 → Sa:80 ⇔ N:55000 → Sa:80 (Regel 3)B:55000 → Sb:80 ⇔ N:55000 → Sb:80 (Regel 3)A:55000 → Sc:80 ⇔ N:55000 → Sc:80 (Regel 2)B:55000 → Sc:80 ⇔ N:55001 → Sc:80 (Regel 2, Kollision, Regel 4)

lässt sich durch dieses Verhalten möglichst lange verhindern, dass sich der Source Port verändert(was seiner Aussage nach einige Protokolle in Mitleidenschaft ziehen würde). Zweitens lassen sichso einiges mehr als [65535 * Anzahl externer IP-Adressen] Verbindungen erlauben. Wie bereitseingangs erwähnt, stellt dieses Verhalten kein grundsätzliches Problem dar. Massiven Einfluss aufdas gelingen von Hole Punching hat hingegen eine zweite Eigenschaft von Netfilter.

Wird auf dem externen Interface ein Paket empfangen, für das noch kein NAT-Mapping vor-handen ist, so wird dieses den TCP/IP-Stack hochgereicht. Erst von Code in höherliegendenSchichten wird es als Paket an einen lokalen, geschlossenen Port behandelt. Zu diesem Zeitpunkhat Netfilter aber bereits einen Eintrag in der Conntrack-Tabelle gemacht. Später folgende aus-gehende Pakete können deshalb nicht das gleiche Mapping erhalten. Dies ist auch

Documents

Peer-to-Peer NAT Traversal for IPsecsecurity.hsr.ch/theses/DA_2006_IKEv2-P2P-NAT-T.pdf · 2006. 12. 15. · Diplomarbeit Informatik Peer-to-Peer NAT Traversal for IPsec Tobias Brunner