Bild 72 - DHBW Stuttgart

Download Report

Transcript Bild 72 - DHBW Stuttgart

WAN – Wide Area Network
1.6.2 Tunneling
Tunneling Protokolle
 RFC 2784 GRE Einkapselung eines Protokolls auf der
Internetschicht
 RFC 2516 Point-to-Point over Ethernet (PPPoE)
 RFC 2637 Point-to-Point Tunneling Protocol (PPTP)
 RFC 2661 Layer Two Tunneling Protocol (L2TP)
 RFC 4380 IP v.4 Host hinter NAT über IP v.6 Teredo
 RFC 5246 TLS
 WinScP
Tabelle 16 Tunneling Protokolle
W. Schulte
1
Lernziele:




Die verschiedenen Protokolle fürs Tunneling kennen
Den Protokollstapel für die Tunneling-Protokolle
benennen
Die Anwendungen für das Tunneling kennen
Die entsprechenden Traces analysieren
W. Schulte
2
TLS
PPTP
Teredo
L2TP
Port 443
Port 1723
Port 3544
Port 1701
TCP
UDP
PID 6
PID 17
Protokoll
X
PID 115
GRE
PID 47
IP mit Ethertype 0x0800
MPLS mit Ethertype 0x8847/48
PPPoE mit Ethertype 0/x8863/64
CSMA/CD
Ethernet
Andere
Teilnetze
Bild 72 Der Protokollstapel
W. Schulte
3
IP v.4
Paket
Header
PID 47
Frame Header
DA
SA
Bit
Type
x0800
0
C
7
8
GRE
Header
15
Reserviert
Vers
Prüfsumme
16
23
Nutzlast
24
31
Protokoll Typ
Reserviert
Bild 73 Das Frame-Format für GRE
W. Schulte
4
2001:12:12:12::2/64 Tunnel
10.20.20.20/30
2001:12:12:12::1/64
10.20.20.21/30 Interface
R2
T0
T0
R1
R3
Bild 74 Tunnel-Beispiel zwischen zwei Netzen
W. Schulte
5
R2 mit Tunnel Destination Adresse für IPv-6 Adresse
#interface Tunnel 0
if)#ip address 2001:12:12:12::2/64
 Tunnel Adresse
if)#tunnel source GigabitEthernet 0/0
if)#tunnel destination 10.20.20.21 255.255.255.252
if)#tunnel mode gre IPv6
#interface GigabitEthernet 0/0
if)#ip address 10.20.20.20 255.255.255.252  Interface Adresse
W. Schulte
6
IP v.4
Paket
Header
PID 47
Frame Header
DA
SA
Bit
Type
x0800
0
7
8
C
Reserviert
GRE
Header
15
Vers
Prüfsumme
16
23
Nutzlast
IPv.4
24
31
Protokoll Typ
X0800 = IPv.4
Reserviert
Bild 75 Das Frame-Format für GRE
W. Schulte
7
No. Time
1 0.000000
Traceanalyse GRE mit IP-ICMP
Source
192.168.0.2
Destination
192.168.0.4
Protocol Length Info
GRE mit ICMP 138 Echo (ping) request
Ethernet II, Src: c2:02:37:97:00:00 (c2:02:37:97:00:00), Dst: c2:05:37:c9:f1:02
Destination: c2:05:37:c9:f1:02 (c2:05:37:c9:f1:02)
Source: c2:02:37:97:00:00 (c2:02:37:97:00:00)
Type: IP (0x0800)
Internet Protocol Version 4, Src: 172.16.25.2 (172.16.25.2), Dst: 172.16.15.2
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT )
Total Length: 124
Identification: 0x001c (28)
Flags: 0x00
Fragment offset: 0
Time to live: 255
Protocol: GRE (47)
Header checksum: 0x3b12 [correct]
Source: 172.16.25.2 (172.16.25.2)
Destination: 172.16.15.2 (172.16.15.2)
Generic Routing Encapsulation (IP)
Flags and Version: 0x0000
Protocol Type: IP (0x0800)
Internet Protocol Version 4, Src: 192.168.0.2 (192.168.0.2), Dst: 192.168.0.4
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT )
Total Length: 100
Identification: 0x001e (30)
Flags: 0x00
Fragment offset: 0
Time to live: 255
Protocol: ICMP (1)
Header checksum: 0x3a24 [correct]
Source: 192.168.0.2 (192.168.0.2)
Destination: 192.168.0.4 (192.168.0.4)
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0
Checksum: 0x03d4 [correct]
Identifier (BE): 6 (0x0006)
Identifier (LE): 1536 (0x0600)
Sequence number (BE): 0 (0x0000)
Sequence number (LE): 0 (0x0000)
[Response In: 3]
Data (72 bytes)
Data: 0000000000187a58abcdabcdabcdabcdabcdabcdabcdabcd...
[Length: 72]
PID=GRE
MAC-Header
Adr.
DA
SA
Type
0000
c2 05 37 c9 f1 02 c2 02 37 97 00 00 08 00 45 00
0010
00 7c 00 1c 00 00 ff 2f 3b 12 ac 10 19 02 ac 10
0020
0f 02 00 00 08 00 45 00 00 64 00 1e 00 00 ff 01
0030
3a 24 c0 a8 00 02 c0 a8 00 04 08 00 03 d4 00 06
0040
00 00 00 00 00 00 00 18 7a 58 ab cd ab cd ab cd
0050
ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd
0060
ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd
0070
0080
cd ab cd
W.abSchulte
ab cd ab cd ab cd ab cd ab cd ab cd
ab cd ab cd ab cd ab cd ab cd
MAC-Header
äußerer
IPv.4-Header
GRE-Header
IPv.4-Header
ICMP-Header
äußerer
IP-Header
innerer
IP-Header
PID=ICMP
ICMP Request
GRE-Header
8
Teredo (RFC 4380) ist eine Tunnel-Technik von
Microsoft, die IPv6-Datenpakete in IPv4-UDPDatenpakete kapselt, damit Windows-PCs und
die XBox (Spielekonsole) die NAT-Schranke von
Teilnehmer-Router von innen überwinden und
so miteinander reden können. Teredo kommt
dabei ohne Anwendereingriffe aus. Als IPv6Tunnelmechanismus soll Teredo den Übergang
von IPv4 auf IPv6 vereinfachen und an Rechnern
in lokalen (IPv4-)Netzen eine global gültige IPv6Adresse vergeben. Dazu baut Teredo einen IPv6Tunnel über eine IPv4-Sitzung auf.
W. Schulte
9
RS-Router Solicitation
Teredo Server
Privates Netz
IP v.4
IP v.6
 RS
 RA
Host C
NAT
T-Client A
Öffentliches Netz
T-Client B
RA-Router Advertisement
Teredo Relay
Bild 76 Komponenten eines Teredo-Tunnels
W. Schulte
10
Teredo ist ein IPv6-Übergangsmechanismus. Dieses
Kommunikationsprotokoll für den Datenverkehr mit dem
Internet ist gemäß RFC 4380 Teredo: Tunneling IPv6 over UDP
through Network Address Translations (NATs) spezifiziert.
Implementierungen existieren insbesondere als Bestandteil
von Microsoft Windows (Teredo) und für Unix-Systeme
(Miredo).
W. Schulte
11
0
7
0x00
Frame Header
D
A
S
A
Type
x0800
IP v.4
Paket
Header
PID 11
UDP
Segment
Header
Port 3544
Bit
0
Router Solicitation
15
16
23
24
31
CID-Len
0x01
Au-Len
Client ID
Authentication
Nonce
8 octets (Zufallswert)
Conf
TEREDO
Auth. Hdr
7
Type
Type = 133
8
8
IP v.6
NH x3a
15
16
23
ICMP
v.6
24
31
Code
Prüfsumme
Reserviert
Optionen
Bild 77 Router Anfrage Nachricht
W. Schulte
12
Teredo Server
IP v.4

Request
IP
v.6



NAT
T-Client A
T-Client B
Host C
Reply
Teredo Relay
Bild 80 Bildung des Tunnels
W. Schulte
13
Point-to-Point Protokoll
• Das Point-to-Point Protocol (PPP) ist ein Teil der „Internet
Official Protocol Standards“ der ISOC und ist beschrieben
in RFC 1661 (7/94) und 1570 LCP Extension.
• Es sind mehrere Protokolle für die Übertragung von
Paketen zwischen „Peers“ über RS-232-/V.24Verbindungen bzw. zwischen Routern notwendig.
• Das PPP ersetzt das ältere, einfachere SLIP (Serial Lines
IP) von 1988.
W. Schulte
14
Point-to-Point (PPP) Übersicht
WAN
MODEM
MODEM
Server
Wählleitung
Hayes Befehle
Wählpulse
PPP Protokoll
Bild 84 PPP über Wählleitungen
W. Schulte
15
Bild 85 HDLC-Rahmenformat
W. Schulte
16
Allg. PPP
Rahmenformat
g
HDLC Rahmenformat
Bild 91
Detailliertes Rahmenformat
für PPP
Protocol
|
Packet Format für LCP, IPCP und CCP
1
1
1
2
Flag
x'7E'
Addr.
x'FF'
Ctrl.
x'03'
Protocol
|
Link
Control
Protocol
x'C021' = LCP
Authentication
Protocols
x'C023' = PAP
x'C223' = CHAP
x'8021' = IPCP
Network
Control
Protocols
Padding
Information
x'80FD' = CCP
Multi protocol x’8281’ = MPLSCP
label switching
control protocol
MPLSCP
1
Code
1
2
Length
|
ID
LCP / IPCP/ CCP
1 = Config. Req.
(Opt)
2 = Config. ACK (Opt)
3 = Config. NACK (Opt)
4 = Config. Rej.
(Opt)
5 = Term. Req.
(Data)
6 = Term. ACK
(Data)
8 = Protocol Reject (LCP)
C = Identification (LCP)Data
E = Reset Req.
F = Reset ACK
CHAP
(CCP)
(CCP)
| PAP
1 = Challenge
2 = Response
3 = Succeed
4 = Failure
| REQ
| ACK
| NACK
|
Data or Options or
Rej. Packet Info
HDLC
2/4
1
FCS
Flag
x'7E'
Type Length x Data
Type Length x Data
Optionsformat
1
1
LCP
0 = Reserved
1 = Max. Rec. Unit
x=(MRU)
2 = Asyn.Ctrl.Char.Map
3 = Auth. Protocol
x=x'C023' PAP
x=x'C2235' CHAP+MD5
5 = Magic Number
x=Magic Number
7 = Protocol Field Compression 1 or 2 Byte
8 = Addr. & Ctrl. Field Compression
F = Compound Frame
IPCP
1 = IP-Addresses (nicht mehr benutzen)
2 = IP-Compress Protoc. x= x'2d'=VJ compr.
3 = IP-Address
der TCP/IP Header
4 = Mobile IP
x81=129= Prim. DNS x83=131= Sec. DNS
x82=130=Prim NetBios WIN Server RFC1877
x84=132=Sev. NetNios WIN Server
CCP
0 = OUI
11 = Stac Electronics LZS
CHAP
PAP
W. Schulte
Size
Value
Name
Peer Length Peer ID PW Length
PW
17
PPP over Ethernet (PPPoE)
Motivation für die Entwicklung von PPPoE war, die
Möglichkeiten von PPP wie Authentifizierung und
Netzkonfiguration (IP-Adresse, Gateway) auf dem
schnelleren Ethernet zur Verfügung zu stellen. PPPoE
ist die Standardisierung des Netzprotokolls Point-toPoint Protocol (PPP) über eine Ethernet-Verbindung.
Das Protokoll definiert zwei Phasen:
 PPPoE Discovery und
 PPP Session
und ist in RFC 2516 beschrieben.
W. Schulte
18
Server
(not selected)
Server
(selected)
Client
Initialisierung
INITIATION
Bild 92 Kommunikation
bei PPPoE
Konfigurationsbestimmung




PADI
INITIATION
Broadcast
Konfigurationsbestimmung
PADO
OFFER
OFFER

Zeit
PADR
REQUEST
Unicast
REQUEST
Übertragung der
Konfigurationsparameter

PADS
Confirmation
Initialisierung beendet
PPP Session 0x8864
Abbau der Verbindung

PADT
Terminate
W. Schulte
19
 PADI steht für PPPoE Active Discovery Initiation
Möchte sich ein Internetnutzer über DSL einwählen, so
muss sein Rechner erst einmal feststellen, ob ein PoP Pointof Presence (DSL-AC) vorhanden ist. Eine Kommunikation ist
nur über die MAC-Adressen möglich. Da aber der Rechner
des Nutzers die MAC-Adresse des PoP nicht kennt, sendet er
das PADI-Paket über einen Ethernet-Broadcast (MAC:
ff:ff:ff:ff:ff:ff).
 PADO steht für PPPoE Active Discovery Offer.
 PADR steht für PPPoE Active Discovery Request.
 PADS steht für PPPoE Active Discovery Session-confirmation.
 PADT steht für PPPoE Active Discovery Termination.
W. Schulte
20
Point-to-Point Tunneling Protocol (PPTP)
Der RFC 2637 PPTP wurde 7/1996 vom PPTP-Forum
entwickelt. Es kommt hauptsächlich in MicrosoftBetriebssystemen zum Einsatz und ist jetzt weitgehend von
RFC 2661 L2TP abgelöst worden. Es stellt eine Erweiterung
des Point-to-Point-Protokolls (PPP) dar, und zwar wird das
PPP durch ein IP Netz getunnelt und bietet darüber hinaus
Verfahren zur Authentifizierung, Komprimierung und
Verschlüsselung an.
PPTP ist ausschließlich für die Übertragung von IP, IPX und
NetBEUI über IP vorgesehen.
W. Schulte
21
PPTP Network Server
(PNS)
PPTP Access Concentrator
(PAC)
PPTP-Verbindung
Lokales Netz
PAC-Client
Datenverkehr
PSTN / ISDN

TCP 3-Wege Handshake
Start Control Connection Req.
Start Control Connection Reply
PPTP Control Message
PPTP Call Mgmt
Outgoing Call Request
 Outgoing Call Reply

PPTP Session Control
Set Link Info.
 PPP Protokoll Req./Reply
Erstellung des
PPP Tunnels
 IP-GRE Datenübertragung
Bild 94 PPTP Kommunikation
W. Schulte
22
Layer-2-Tunneling-Protocol (L2TP)
Mit dem RFC 2661 (RFC 3931 v.3) Layer-2-Tunneling-Protocol (L2TP) wurde die
Aufgabe der Erstellung einer PPP-Verbindung über ein IP-Netz zwischen zwei NetzStationen gegenüber dem PPTP-Protokoll erweitert.
Nicht nur IP, IPX und Net BEUI, sondern jedes beliebige Protokoll sollte jetzt den
Tunnel benutzen können. Anstelle einer reellen Punkt-zu-Punkt-Verbindung, z. B.
über PSTN oder ISDN, besteht die Übertragungsstrecke aus mehreren Routern, die
miteinander verbunden sind.
Für dieses Szenario gibt es zwei Protokolle:
• L2F – Layer-2-Forwarding (RFC 2341)
• PPTP – Point-to-Point Tunneling Protocol (RFC 2637)
Diese beiden Protokolle bilden die Basis für das Layer-2-Tunneling Protocol. L2TP
bietet selbst
Authentifizierungs-, Integritäts- und
Verschlüsselungsmechanismus.
Ein Schutz der zu übertragenden, getunnelten Daten sollte z. B. mit IPsec erfolgen.
W. Schulte
23
PSTN / ISDN
L2TP Network Server
(LNS)
Lokales Netz
L2TP Access Concentrator
(LAC)
Internet
Client
Tunnel
PSTN / ISDN mit PPP
Frame Relay
LAC-Client
PPP
L2TP Control Message
L2TP Data Message
L2TP Control Channel
L2TP Data Channel
Paket Transport IP, UDP Port 1701 oder FR
Bild 97 L2TP Kommunikation
W. Schulte
24
L2TP-Architektur
Die L2TP-Architektur definiert zwei logische Systeme:
1. Den L2TP Access Concentrator (LAC) und
2. Den L2TP Network Server (LNS).
Der LAC verwaltet die Verbindungen und stellt diese zum LNS her.
Der LNS ist für das Routing und die Kontrolle der vom LAC
empfangenen Pakete zuständig. Das L2TP definiert die Kontrollund Datenpakete zur Kommunikation zwischen dem LAC und
dem LNS. Ein Network Access Server (NAS) stellt einen
temporären Zugang für Remote-Systeme zur Verfügung. Der NAS
kann alternativ im LAC oder im LNS implementiert sein.
W. Schulte
25
No. Time Source
2 0.158 3.3.3.3
Destination
2.2.2.2
Protocol Length Info
0x001c 98
Frame 2: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)
Ethernet II, Src: ca:02:10:78:00:1c, Dst: ca:01:17:6c:00:38
Destination: ca:01:17:6c:00:38 (ca:01:17:6c:00:38)
Source: ca:02:10:78:00:1c (ca:02:10:78:00:1c)
Type: IP (0x0800)
Traceanalyse L2TP
Internet Protocol Version 4, Src: 3.3.3.3 (3.3.3.3), Dst: 2.2.2.2 (2.2.2.2)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00:
Total Length: 84
Identification: 0x0a7c (2684)
Flags: 0x00
Fragment offset: 0
Time to live: 254
Protocol: Layer 2 Tunneling (115)
Header checksum: 0xa7b1 [correct]
Source: 3.3.3.3 (3.3.3.3)
Destination: 2.2.2.2 (2.2.2.2)
Layer 2 Tunneling Protocol version 3
Packet Type: Data Message Session Id=38482
Session ID: 38482
Cookie: ca031078
Default L2-Specific Sublayer
.0.. .... = S-bit: False
Sequence Number: 1886723
MAC-Header
IP-Header
L2TP-Header
Cisco HDLC
Address: Unknown (0x10)
Protocol: Unknown (0x001c)
Data (48 bytes)
Data: 900000000100000000000000000000000000000000000000...
[Length: 48]
HDLC
IP-Header
MAC-Header
Adr.
DA
SA
Type
0000
ca 01 17 6c 00 38 ca 02 10 78 00 1c 08 00 45 00
0010
00 54 0a 7c 00 00 fe 73 a7 b1 03 03 03 03 02 02
0020
0030
02 02 00 00 96 52 ca 03 10 78 00 1c ca 03 10 78
00 1c 90 00 00 00 01 00 00 00 00 00 00 00 00PID
00x73=d115= L2TP
0040
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0050
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0060
00 00
W. Schulte
..
26
Transport Layer Security (TLS) v. 1.2
Das Protokoll Secure Sockets Layer (SSL) wurde als Vorgänger von Transport
Layer Security (TLS) von der Firma Netscape entwickelt. Die Version 3 von
SSL wurde von der IETF als TLS Version 1 spezifiziert. Der aktuelle Standard
in der Version 1.2 ist in RFC 5246 beschrieben und im Jahr 2008
herausgegeben.
TSL ist eine Client-Server-Anwendung, d. h., ein Client oder Webbrowser
versucht mit einem Webserver eine sichere Verbindung über TCP
aufzubauen. TSL wird hauptsächlich bei HTTP-Anwendungen eingesetzt die
TSL zur Sicherung der Daten benutzen. Mit TSL wird aus http:// ein https://,
d. h. „HTTP over TLS“.
W. Schulte
27
MAC Header
DA
SA
Type
0x0800
IP
Header
PID
x6
Bit
Beispiel für das Frameformat
einer Client- Handshake
Hello-Nachricht.
Handshake
TCP
Header
Port #
443
0
TLS
7
Content
Type = 22
Länge
8
Cipher
Spec
Alert Appl. HTTPS
Data
Record Layer
15
16
Major / Minor
Version
23
24
31
Länge
Handshake Protokoll
Session ID / Cipher Protocol / Server Name
Bild 98 Schichtenstruktur von SSL/TLS
W. Schulte
28
Tabelle 21
Ablaufdiagramm von TLS
ohne Certificate von Client
Client
Server
169.254.255.66
169.254.100.98
169.254.255.66
169.254.255.66
169.254.100.98
Protokoll Information
[SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=2
TCP
Client eröffnet eine sichere TCP-Verbindung mit
1
Destination Port 443  HTTPS
[SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0
MSS=1460 WS=8
Server bestätigt den TCP-Verbindungsaufbau
[ACK] Seq=1 Ack=1 Win=65700 Len=0
169.254.100.98
TCP-Verbindung ist aufgebaut
169.254.255.66
169.254.100.98
169.254.255.66
169.254.100.98
169.254.255.66
169.254.100.98
169.254.255.66
169.254.100.98
Change Cipher Spec, Encrypted Handshake Message
TLS Record Layer: Change Cipher Spec Protocol:
Change Cipher Spec
169.254.255.66
169.254.100.98
Application Data
TLS Record Layer: Application Data Protocol: http
169.254.255.66
169.254.100.98
Application Data
TLS Record Layer: Application Data Protocol: http
TLSv1
W. Schulte
Client sendet:
Im Record Layer ein TLSV Client Hello
Im Handshake die Cipher und Compression
Information
Server antwortet mit Hello, Certificate, Server Hello
Done
TLS Record Layer: Handshake Protocol: Multiple
Handshake Messages z. B. Certificate, Cipher Suite
Client Key Exchange, Change Cipher Spec, Encrypted
Handshake Message
Ohne Certificate
29
Tunneling Protokolle
Protokoll Stapel
Zusammenfassung Tunneling
TLS
PPTP
Teredo
L2TP
Port 443
Port 1723
Port 3544
Port 1701
TCP
UDP
PID 6
PID 17
Protokoll
X
PID 115
GRE
PID 47
IP mit Ethertype 0x0800
MPLS mit Ethertype 0x8847/48
PPPoE mit Ethertype 0/x8863/64
CSMA/CD
Ethernet
GRE
TEREDO
PPPoE
PPTP
L2TP
TLS
MPLS
Andere
Teilnetze
Begriffe
Tunneling Beispiel GRE
2001:12:12:12:::2/64
R2
10.20.20.20/32
Lo0
R3
2001:12:12:12:::1/64
R1
10.20.20.10
Lo0
OSPF mit GRE getunnelt
Sender
Empfänger
4 GRE
OSPF
GRE
OSPf
3 IP IP
IP IP
2
Ethernet
1
W. Schulte
Generic Routing Encapsulation
Vom Microsoft IPv.4  IPv.6
PPP over Ethernet
P-to-P Tunneling Protocol
Layer 2 Tunneling Protocol
Transport Layer Security
Multi Protocol Label Switching
2 unterschiedliche Protokolle auf
der gleichen Schicht (2 oder 3)
Tunnel
werden paarweise zusammen
übertragen.
Network Bei PPTP und L2TP der Server auf
Server
der Empfangsseite.
Zur Erstellung und Wartung eines
Access
Tunnels zum NS bei PPTP und
Concentr.
L2TP
ISDN
30
Noch Fragen?
W. Schulte
31