2013 – ISO OSI Referenzmodell und Protokolle - RFC 791

rfc791.de

2013 – ISO OSI Referenzmodell und Protokolle - RFC 791

fc791.de | Christian Book

ISO OSI Referenzmodell

und Protokolle

Whitepaper

Autor:

Christian Book

Kontakt:

security@christian-book.de

Veröffentlichung: 29. April 2013

Quelle:

http://rfc791.de/whitepaper


Whitepaper ISO OSI Referenzmodell und Protokolle 29. April 2013

Inhaltsverzeichnis

1. OSI Referenzmodell .......................................................................................................... 2

2. Ausgewählte Protokolle ................................................................................................... 4

2.1. Ethernet ...................................................................................................................... 4

2.2. Internet Protocol Version 4 IPv4 ............................................................................ 6

2.3. Internet Protocol Version 6 IPv6 .......................................................................... 11

2.4. IPsec .......................................................................................................................... 13

2.5. Transmission Control Protocol TCP ..................................................................... 17

2.6. User Datagram Protocol UDP ............................................................................. 19

2.7. Internet Control Message Protocol ICMP ......................................................... 20

3. Über den Autor ............................................................................................................... 22

4. Literaturverzeichnis ......................................................................................................... 23

Abbildungen

Abbildung 1: OSI Referenzmodell .......................................................................................... 3

Abbildung 2: Ethernet-Rahmen ............................................................................................. 5

Abbildung 3: Ethernet Rahmen mit VLAN-Tag .................................................................... 6

Abbildung 4: IP Header ........................................................................................................... 7

Abbildung 5: IPv6 Header ..................................................................................................... 11

Abbildung 6: IPSec-AH-Header ............................................................................................ 14

Abbildung 7: IPSec-ESP-Header ........................................................................................... 14

Abbildung 8: IPsec ESP im transport mode ........................................................................ 15

Abbildung 9: : IPsec AH im transport mode ....................................................................... 15

Abbildung 10: IPsec ESP im tunnel mode ........................................................................... 16

Abbildung 11: IPsec AH im tunnel mode ............................................................................ 16

Abbildung 12: TCP Header ................................................................................................... 17

Abbildung 13: TCP-Verbindungsaufbau ............................................................................. 18

Abbildung 14: TCP-Verbindungsabbau .............................................................................. 19

Abbildung 15: UDP Header .................................................................................................. 20

Abbildung 16: ICMP Header ................................................................................................ 21

Weitere interessante Whitepaper zu den

Themen IT-Sicherheit und Netzwerken finden Sie unter

HTTP://RFC791.DE/WHITEPAPER

Christian Book

http://rfc791.de/whitepaper 1/24


Whitepaper ISO OSI Referenzmodell und Protokolle 29. April 2013

1. OSI Referenzmodell

Das OSI Referenzmodell 1 (Open Systems Interconnection Reference Model) ist ein

Schichtenmodell der Internationalen Standardisierungsorganisation (ISO). Es wurde

als Designgrundlage von Kommunikationsprotokollen entwickelt und hilft, die Abhängigkeiten

verschiedener Technologien zu verstehen.

Beginnend bei der Bitübertragungsschicht bis hin zur Anwendungsschicht umfasst

das OSI Referenzmodell insgesamt sieben Schichten. Diese Schichten bauen dabei

aufeinander auf, d. h. sollen auf Schicht 7 Daten zwischen zwei Systemen ausgetauscht

werden, so sind auf beiden Systemen jeweils auch die Schichten 1 bis 6 beteiligt.

Alle Protokolle, die zur Kommunikation in Netzwerken verwendet werden, lassen

sich in eine der sieben Schichten einordnen.

Bitübertragungsschicht

Die Bitübertragungsschicht stellt mechanische, elektrische und weitere funktionale

Hilfsmittel zur Verfügung, um physikalische Verbindungen zu steuern und Bits darüber

zu übertragen. Dies können neben elektrischen Signalen auch optische Signale,

elektromagnetische Wellen oder Schall sein. Wichtige Protokolle auf der Bitübertragungsschicht

sind V.24, X.21 und RS 232. Als Hardware kommen Hubs, Modems und

Repeater auf der Bitübertragungsschicht zum Einsatz.

Sicherungsschicht

Aufgabe der Sicherungsschicht ist die Bereitstellung einer zuverlässigen Übertragung

sowie die Steuerung des Zugriffs auf das Übertragungsmedium. Dazu wird der Bitdatenstrom

in Rahmen unterteilt. Durch den Einsatz von Prüfsummen wird die Integrität

der Daten sichergestellt. Die Datenflusskontrolle ermöglicht eine dynamische Steuerung

der Geschwindigkeit, mit der die Gegenseite Rahmen senden darf. Die Sicherungsschicht

ist in zwei Unter-Schichten unterteilt: Logical Link Control (LLC) und Media

Access Control (MAC). Bedeutende Protokolle der Sicherungsschicht sind unter

anderem Ethernet, ARP, und das Spanning Tree Protocol (STP). Switche und Bridges

stellen die Hardware der Sicherungsschicht dar.

Vermittlungsschicht

Die Vermittlungsschicht stellt bei paketorientierten Diensten die Weitervermittlung

von Datenpaketen bereit. Für leitungsorientierte Dienste wird das Schalten der jeweiligen

Verbindungen durch die Vermittlungsschicht durchgeführt. Eine der wichtigsten

Aufgaben der Vermittlungsschicht ist das Routing sowie die Pflege von Routingtabellen.

Wichtige Protokolle der Vermittlungsschicht sind IP, IPsec und ICMP. Router sind

die der Vermittlungsschicht zugeordneten Hardware.

Transportschicht

Die Transportschicht stellt den anwendungsorientierten Schichten 5 bis 7 einen standardisierten

Zugriff auf das Netzwerk bereit. Damit müssen die höheren Schichten die

spezifischen Eigenschaften der Kommunikationsnetze nicht berücksichtigen. Zudem

implementiert die Transportschicht Mechanismen zur Segmentierung des Daten-

1 (Zimmermann, 1980)

Christian Book

http://rfc791.de/whitepaper 2/24


Whitepaper ISO OSI Referenzmodell und Protokolle 29. April 2013

stroms und zur Vermeidung von Datenstaus. Die beiden häufigsten Prokotolle dieser

Schicht sind TCP und UDP.

Sitzungsschicht

Die Sitzungsschicht steuert die Prozesskommunikation zwischen zwei IT-Systemen. Dazu

implementiert die Sitzungsschicht Dienste für einen organisierten und synchronisierten

Datenaustausch. Das Protokoll Remote Procedure Call (RPC) ist eines der bekanntesten

Protokolle dieser Schicht.

Darstellungsschicht

Die Darstellungsschicht überführt die systemabhängige Darstellung von Daten in eine

unabhängige Form. Dies ermöglicht den Datenaustausch zwischen unterschiedlichen

IT-Systemen. Zudem werden auch Datenkompression und die Verschlüsselung

auf dieser Schicht durchgeführt.

Anwendungsschicht

Die Anwendungsschicht ist die oberste der sieben hierarchischen Schichten im OSI-

Referenzmodell. Die Anwendungen erhalten den Zugriff auf das Netzwerk auf dieser

Ebene. Populäre Protokolle der Anwendungsschicht sind http, SSH, FTP und SMTP.

Die nachfolgende Abbildung illustriert den Aufbau des OSI Referenzmodells.

Schicht 7

Schicht 6

Schicht 5

Schicht 4

Schicht 3

Schicht 2

Schicht 1

• Anwendungsschicht

• (engl. Application Layer)

• Darstellungsschicht

• (engl. Presentation Layer)

• Sitzungsschicht

• (engl. Session Layer)

• Transportschicht

• (engl. Transport Layer)

• Vermittlungsschicht

• (engl. Transport Layer)

• Sicherungsschicht

• (engl. Data Link Layer)

• Bitübertragungsschicht

• (engl. Physical Layer)

Abbildung 1: OSI Referenzmodell

Christian Book

http://rfc791.de/whitepaper 3/24


Whitepaper ISO OSI Referenzmodell und Protokolle 29. April 2013

2. Ausgewählte Protokolle

Innerhalb des OSI Referenzmodells sind einige Protokolle von besonderer Bedeutung.

Insbesondere die im Rahmen der Informationssicherheit relevanten Protokolle werden

im Folgenden kurz vorgestellt.

2.1. Ethernet

Ethernet spezifiziert Protokolle sowie Hardware für kabelgebundene Datennetze. Ursprünglich

wurde Ethernet für lokale Datennetze (LANs) konzipiert. Die Ethernet-

Protokolle enthalten neben Definitionen für Kabeltypen und Stecker insbesondere

die Standardisierung der eingesetzten Signale auf der Bitübertragungsschicht und

dem Aufbau des Ethernet-Rahmens. Im OSI-Referenzmodell bildet Ethernet sowohl

die physikalische Schicht als auch die Sicherungsschicht ab. Ethernet entspricht weitestgehend

der Norm IEEE 802.3. Alle Teilnehmer eines lokalen Ethernet-Netzwerks

übertragen Nachrichten mittels Hochfrequenz innerhalb des gemeinsamen Leitungsnetzes.

Jede Netzwerkschnittstelle wird über einen (global) eindeutigen 48-Bit-

Schlüssel - der MAC-Adresse - identifiziert. Aktuell sind Übertragungsraten von 10, 100

und 1000 MBit/s bis hin zu 10 GBit/s spezifiziert.

Durch das Verfahren „Carrier Sense Multiple Access with Collision Detection“

(CSMA/CD) wird der Zugriff der Systeme auf das gemeinsame Medium kontrolliert.

Der Teilnehmer, der Daten über das Netzwerk übertragen möchte, lauscht auf dem

Medium (Carrier Sense) und stellt so fest, ob es bereits belegt ist. Die Datenübertragung

beginnt erst dann, wenn die Leitung frei ist. Da zwei Teilnehmer gleichzeitig zu

senden anfangen können, kann es trotz CSMA/CD zu Kollisionen kommen. Diese wird

dann im Rahmen der Kollisionserkennung (Collision Detection) festgestellt, woraufhin

beide Teilnehmer das Senden umgehend unterbrechen. Beide warten einige Zeit,

bevor sie mit der erneuten Übertragung beginnen. Da die meisten Netzwerke heute

im Vollduplexmodus betrieben, bei dem durch den Switches Kollisionen mehr entstehen

können, ist die Kollisionserkennung in modernen Netzwerken kaum noch relevant.

Die ersten Implementierungen von Ethernet-Netzwerken erfolgten in Bus-Topologien.

Jede Information, die von einem Teilnehmer über das Netzwerk übertragen wurde,

wurde von allen anderen Teilnehmern empfangen. Alle angebunden Teilnehmer

müssen daher stets die Informationen selektieren und verwerfen, die nicht für sie bestimmt

sind. Diese Eigenschaft wird bei Broadcast-Nachrichten genutzt, bei denen

alle Teilnehmer gleichzeitig angesprochen werden sollen. Gleichzeitig stellt diese Eigenschaft

jedoch auch ein Sicherheitsrisiko dar, da ein Angreifer den gesamten Datenverkehr

auf der Leitung mitprotokollieren kann. Durch den Einsatz von Hubs zur

Ablösung der Bus-Topologie durch Multi-Segment-Ethernet-Netze kann dies nicht behoben

werden, da auch hier weiterhin alle Ethernet-Rahmen in alle Segmente repliziert

werden.

In moderneren Netzen auf Basis von Ethernet werden heute zur Segmentierung der

Kollisions-Domänen Switches eingesetzt. In der Regel werden Ethernet-Rahmen über

Switches direkt vom Sender zum Empfänger transportiert, unbeteiligte Teilnehmer

Christian Book

http://rfc791.de/whitepaper 4/24


Whitepaper ISO OSI Referenzmodell und Protokolle 29. April 2013

erhalten das Paket nicht. Broadcast- und Multicast-Nachrichten können jedoch explizit

definiert werden, sodass ausgewählte Informationen an alle angeschlossenen

Teilnehmer gesendet werden. Dazu halten Switches CAM-Tabellen (Content Addressable

Memory) vor, in denen zu jeder Schnittstelle die dort bekanntermaßen verfügbaren

MAC-Adressen gespeichert sind. Ist ein Ethernet-Rahmen an eine MAC-

Adresse adressiert, die dem Switch nicht bekannt ist, wird der Ethernet-Rahmen über

alle nahezu Schnittstellen gesendet. Um Schleifen (Layer-2-Loops) zu verhindern,

werden Ethernet-Rahmen niemals über die Schnittstelle gesendet, über die sie empfangen

wurden. Dieses Verhalten kann auch böswillig durch MAC-Flooding provoziert

werden. Durch MAC-Spoofing können Ethernet-Rahmen zudem umgeleitet bzw.

abgefangen werden.

Ethernet zeichnet sich durch eine schlanke Rahmenstruktur aus, in deren Inneren die

Nutzlast (Payload) transportiert wird. Die Nutzlast pro Rahmen ist auf 1500 Byte begrenzt.

Die nachfolgende Grafik zeigt den Ethernet-Rahmen.

Abbildung 2: Ethernet-Rahmen

Durch den Einsatz von Virtual Local Area Networks (VLAN) können physische Netze in

logische Teilnetze untergliedert werden. Dabei kann ein VLAN innerhalb eines einzelnen

Switches oder eines gesamten physischen Netzwerks bereitgestellt werden. Die

Trennung der virtuellen Netzwerke geschieht auf der Sicherungsschicht des OSI-

Referenzmodells.

Die Zuordnung zu einem VLAN kann sowohl statisch über Zuordnung der Schnittstellen

an den Switches, als auch über spezielle Markierungen an den Paketen (Tags)

realisiert werden. Zudem kann die Zuordnung dynamisch erfolgen, als Kriterien eignen

sich dabei beispielsweise MAC- und IP-Adressen, aber auch TCP- und UDP-Ports

und höhere Protokolle. Jedes VLAN bildet eine eigene Broadcast-Domäne. Zur Vermittlung

zwischen einzelnen VLANs werden Router eingesetzt, jedoch stellen moderne

Switches (sog. Layer-3-Switches)diese Funktion intern bereit.

Neben der hohen Flexibilität bei der Zuordnung von Endgeräten zu Netzwerksegmenten,

die beim Einsatz von VLAN unabhängig vom Standort erfolgen kann, gibt es

deutliche Vorteile bei der Performanz. Neben der Möglichkeit, eigene Netzwerke für

anspruchsvolle Anwendungen wie Sprach- und Videoübertragung zu schaffen und

diese entsprechend zu priorisieren, kann insbesondere durch die Verkleinerung von

Broadcast-Domänen eine deutliche Leistungssteigerung realisiert werden.

Zudem kann durch den Einsatz von VLANs das unbefugte Mitlesen und Manipulieren

von Datenströmen besser verhindert werden. Insbesondere gegen MAC-Flooding

und MAC-Spoofing sind VLAN-basierte Netzwerke durch den Einsatz von Routern zur

Verbindung von Netzwerken besser geschützt.

Christian Book

http://rfc791.de/whitepaper 5/24


Whitepaper ISO OSI Referenzmodell und Protokolle 29. April 2013

Für Port-basierte VLANs findet die Zuordnung der Schnittstellen zu einem VLAN in der

Konfiguration des jeweiligen Switches statt. Jeder Ethernet-Rahmen, der über die definierte

Schnittstelle am Switch eintrifft, wird innerhalb dieses VLANs transportiert. Flexibler

sind hingegen Tag-basierte VLANs. Im Standard IEEE 802.1Q sind Datenfelder für

das VLAN-Tagging definiert, die in den Datenbereich eines Ethernet-Rahmens eingefügt

werden. Dadurch können in der Regel auch ältere Switches solche Pakete weiterleiten.

Der eingefügte Tag verfügt über vier Felder mit einer Gesamtlänge von 32

Bit. Die nachfolgende Grafik zeigt den Ethernet-Rahmen.

Abbildung 3: Ethernet Rahmen mit VLAN-Tag

2.2. Internet Protocol Version 4 IPv4

Das Internet Protocol in der Version 4 (IPv4) war die erste weltweit verbreitete Version

des Internet Protocols. Heute stellt IPv4 eine bedeutende technische Grundlage des

Internets dar. Das RFC 791 2 aus dem Jahre 1981 definiert die technischen Eigenschaften

dieses Protokolls, das für den Datenaustausch in paketvermittelnden Rechnernetzen

konzipiert wurde. In Netzen dieser Art werden die Daten in Paketen transportiert,

die nach einem Schichtenmodell geschachtelte Steuerinformationen unterschiedlicher

Protokolle um die Nutzdaten herum übertragen. IPv4 ist auf der Vermittlungsschicht

des OSI-Referenzmodells angesiedelt.

Ein IP-Paket besteht aus einem Header und den zu übertragenden Nutzdaten. Dabei

sind die Nutzdaten gewöhnlich in ein weiteres Protokoll wie TCP, UDP oder ICMP gekapselt.

Die maximale Länge eines IP-Pakets beträgt 2 16 −1 = 65535 Bytes. Dabei verwendet

der Header mindestens 20 Byte, sodass maximal 65515 Bytes als Nutzdaten

übertragen werden können.

Der Header eines IPv4-Pakets ist in der nachfolgenden Grafik dargestellt.

2 (Postel, RFC 791 - Internet Protocol, 1981)

Christian Book

http://rfc791.de/whitepaper 6/24


Whitepaper ISO OSI Referenzmodell und Protokolle 29. April 2013

Abbildung 4: IP Header

IPv4 benutzt zur Adressierung IP-Adressen mit 32-Bit. Diese Adressen werden dezimal

in vier Blöcken notiert, wobei jeder Block 8 Bit zusammenfasst. Jedes Oktett verfügt

somit über einen Wertebereich von 0 bis 255.

Die IP-Adresse gliedert sich in einen Netzwerkteil und einen Host-Adressteil. IT-Systeme

befinden sich im selben IP-Netz, wenn der Netzwerkteil ihrer Adresse identisch ist. In

jedem Netzwerk müssen die IP-Adressen eindeutig einem IT-System zugeordnet werden.

Die maximale Anzahl verfügbaren Host-Adressen in einem Netz ergibt sich aus

2 Anzahl Bits der Hostadresse 2, da die niederwertigste Adresse als Netz-Adresse und die jeweils

höchstwertige Adresse als Broadcast-Adresse definiert ist.

Die Subnetzmaske bestimmt die Aufteilung zwischen Netzteil und Adressteil. Analog

zu den IP-Adressen besteht die Subnetzmaske aus 32 Bit, die in vier Oktetten notiert

werden.

Die früher vorgeschriebene Einteilungen für Netzwerkklassen mit einer festen Länge

1993 überwiegend abgeschafft und durch das Classless Inter-Domain Routing (CIDR)

ersetzt. Dieses Verfahren bietet durch bitvariable Netzmasken eine deutliche höhere

Flexibilität in der Subnetierung von IP-Netzen. In der Classless Inter-Domain Routing

Notation wird dies als 192.168.0.1/24 notiert, wobei der Wert 24 anzeigt, dass die ersten

24 Bits der Subnetzmaske den binären Wert 1 besitzen und damit zum Netzanteil

der IP-Adresse gehören. In der klassischen Notation entspricht dies der Subnetzmaske

255.255.255.0.

Die nachfolgende Tabelle zeigt eine Übersicht über spezielle IP-Adressbereiche, die

für dedizierte Zwecke vorgesehen und nicht an beliebige Hosts im Internet vergeben

werden.

Christian Book

http://rfc791.de/whitepaper 7/24


Whitepaper ISO OSI Referenzmodell und Protokolle 29. April 2013

Tabelle 1: Reservierte IP-Adresskreise bei IPv4

CIDR-

Adressblock

0.0.0.0/8

10.0.0.0/8

127.0.0.0/8

169.254.0.0/16

172.16.0.0/12

192.0.0.0/24

192.0.2.0/24

192.88.99.0/24

192.168.0.0/16

198.18.0.0/15

198.51.100.0/24

203.0.113.0/24

223.255.255.0/24

224.0.0.0/4

Adressbereich Beschreibung Spezifikation

0.0.0.0 bis

0.255.255.255

10.0.0.0 bis

10.255.255.255

127.0.0.0 bis

127.255.255.255

169.254.0.0 bis

169.254.255.255

172.16.0.0 bis

172.31.255.255

192.0.0.0 bis

192.0.0.255

192.0.2.0 bis

192.0.2.255

192.88.99.0 bis

192.88.99.255

192.168.0.0 bis

192.168.255.255

198.18.0.0 bis

198.19.255.255

198.51.100.0 bis

198.51.100.255

203.0.113.0 bis

203.0.113.255

223.255.255.0 bis

223.255.255.255

224.0.0.0 bis

239.255.255.255

RFC

Aktuelles Netz (nur als

3232 (ersetzt

Quelladresse gültig)

RFC 1700)

Netzwerk für den privaten

Gebrauch

RFC 1918

Loopback-Adresse RFC 3330

Zeroconf RFC 3927

Netzwerk für den privaten

Gebrauch

RFC 1918

Reserviert aber zur Vergabe

vorgesehen

Dokumentation und Beispielcode

(TEST-NET)

RFC 3330

6to4-Anycast-

Weiterleitungspräfix

RFC 3068

Netzwerk für den privaten

Gebrauch

RFC 1918

Netz-Benchmark-Tests RFC 2544

Dokumentation RFC 5735

Dokumentation RFC 5735

Reserviert aber zur Vergabe

vorgesehen

RFC 3330

Multicast RFC 3171

Christian Book

http://rfc791.de/whitepaper 8/24


Whitepaper ISO OSI Referenzmodell und Protokolle 29. April 2013

CIDR-

Adressblock

240.0.0.0/4

Adressbereich Beschreibung Spezifikation

240.0.0.0 bis

255.255.255.255

255.255.255.255 255.255.255.255 Broadcast

von der IETF reserviert

RFC

3232 (ersetzt

RFC 1700)

Die nachfolgende Tabelle hilft bei der Subnetierung eines IP-Netzes und zeigt, wie

viele IP-Adressen in einem Subnetz zur Verfügung stehen. Zudem enthält sie eine

Übersicht über Subnetzmasken in der Oktett-Darstellung und in CIDR Notation.

Tabelle 2: Subnetze mit CIDR-Notation

IP-Adressen im Netz Subnetzmaske CIDR Classful

4294967296 0.0.0.0 /0

2147483648 128.0.0.0 /1

1073741824 192.0.0.0 /2

536870912 224.0.0.0 /3

268435456 240.0.0.0 /4

134217728 248.0.0.0 /5

67108864 252.0.0.0 /6

33554432 254.0.0.0 /7

16777216 255.0.0.0 /8 Class A-Netz

8388608 255.128.0.0 /9 Class A-Netz

4194304 255.192.0.0 /10 Class A-Netz

2097152 255.224.0.0 /11 Class A-Netz

1048576 255.240.0.0 /12 Class A-Netz

524288 255.248.0.0 /13 Class A-Netz

262144 255.252.0.0 /14 Class A-Netz

131072 255.254.0.0 /15 Class A-Netz

65536 255.255.0.0 /16 Class B-Netz

32768 255.255.128.0 /17 Class B-Netz

16384 255.255.192.0 /18 Class B-Netz

8192 255.255.224.0 /19 Class B-Netz

4096 255.255.240.0 /20 Class B-Netz

2048 255.255.248.0 /21 Class B-Netz

Christian Book

http://rfc791.de/whitepaper 9/24


Whitepaper ISO OSI Referenzmodell und Protokolle 29. April 2013

IP-Adressen im Netz Subnetzmaske CIDR Classful

1024 255.255.252.0 /22 Class B-Netz

512 255.255.254.0 /23 Class B-Netz

256 255.255.255.0 /24 Class C-Netz

128 255.255.255.128 /25 Class C-Netz

64 255.255.255.192 /26 Class C-Netz

32 255.255.255.224 /27 Class C-Netz

16 255.255.255.240 /28 Class C-Netz

8 255.255.255.248 /29 Class C-Netz

4 255.255.255.252 /30 Class C-Netz

2 255.255.255.254 /31 Class C-Netz

1 255.255.255.255 /32 Class C-Netz

IPv4 eignet sich für den Einsatz in LANs und WANs gleichermaßen. Der Datenaustausch

zwischen unterschiedlichen Netzen erfolgt über Router, während innerhalb

eines Netzes die Computer direkt über Hubs, Switches oder Cross-Link-Verbindungen

kommunizieren können. Sofern verschiedene Netzwerke durch Router verbunden

sind, kann ein IP-Paket diese Netzwerke durchlaufen. Anhand von Routingtabellen

wird dabei der Netzwerkteil dem jeweiligen Zielnetzwerk zugeordnet. Die Einträge in

die Routing-Tabelle können statisch oder dynamisch durch den Einsatz Routing-

Protokolle erfolgen. Dabei wird jedes IP-Paket einzeln geroutet.

Gewöhnlich beschränkt der Sender die Paketlänge auf die Maximum Transmission

Unit (MTU) des zugrundeliegenden Mediums. So beträgt die MTU bei Ethernet 1500

Bytes, da laut Spezifikation ein Ethernet-Rahmen eine Maximalgröße von 1518 Bytes

nicht überschreiten darf und dabei 18 Bytes vom Ethernet-Header belegt werden. Für

das zu transportierende IP-Paket stehen demnach lediglich 1500 Bytes zur Verfügung.

Während des Transports vom Sender zum Empfänger muss das IP-Paket eventuell ein

Netz durchlaufen, das nur kleinere IP-Pakete unterstützt. Jedes IP-Paket erhält vom

Sender eine Kennung (Identification). Stellt ein Router auf dem Weg zum Ziel fest,

dass das IP-Netz für das nächste Teilnetz zu groß ist, so kann er es in Fragmente aufteilen.

Um ein IP-Paket wieder zusammenzusetzen, kombiniert der Empfänger die Fragmente

wieder. Dazu werden Fragmente mit gleicher Kennung (Identifikation), dem

gleichen Absender, Empfänger und dem gleichen Protokoll ermittelt und zusammengefügt.

Das erste Fragment trägt zur Erkennung im Feld Fragment-Offset den

Wert 0. Das jeweils folgende Fragment verfügt ebenfalls über den Fragment-Offset,

während das letzte Fragment im Feld more-fragments den Wert 0 besitzt.

Christian Book

http://rfc791.de/whitepaper 10/24


Whitepaper ISO OSI Referenzmodell und Protokolle 29. April 2013

2.3. Internet Protocol Version 6 IPv6

Das Internet Protocol in der Version 6 (IPv6) ist ein seit 1998 im RFC 2460 3 standardisiertes

Verfahren zur Übertragung von Daten in paketvermittelnden Rechnernetzen. Wie

IPv4 ist IPv6 auf der Vermittlungsschicht angesiedelt und stellt eine über Teilnetze hinweg

gültige Adressierung der beteiligten IT-Systeme im Netzwerke bereit.

Die wesentlichen neuen Eigenschaften von IPv6 sind neben der Vergrößerung des

Adressraums von IPv4 mit 23 2 = 4,3 Milliarden Adressen auf 2 128 = 340 Sextillionen Adressen

bei IPv6 insbesondere die Vereinfachung und Verbesserung des Protokollrahmens.

Zudem unterstützt IPv6 die zustandslose automatische Konfiguration von IPv6-

Adressen, sodass zustandsbehaftete Verfahren wie DHCP in vielen Anwendungsfällen

obsolet werden. Wichtige technische Entwicklungen wie Quality of Service und Multicast

sind im Standard IPv6 implementiert. Während für IPv4 ist die Unterstützung von

IPsec optional war, wird durch die Implementierung von IPsec im IPv6-Standard die

Verschlüsselung und die Überprüfung der Authentizität von IP-Paketen in den Standard

integriert.

Der Header eines IPv6-Pakets ist in der nachfolgenden Grafik dargestellt.

Abbildung 5: IPv6 Header

Die Notation von IPv6-Adressen wird im RFC 4291 beschrieben. Demnach werden

IPv6-Adressen in der Regel hexadezimal notiert, wobei die IP-Adresse in acht durch

Doppelpunkte separierte Blöcke zu jeweils 16 Bit unterteilt wird. Netzwerke werden

bei IPv6 ausschließlich in der CIDR-Notation dargestellt.

3 (Deering & Hinden, 1998)

Christian Book

http://rfc791.de/whitepaper 11/24


Whitepaper ISO OSI Referenzmodell und Protokolle 29. April 2013

Die nachfolgende Tabelle zeigt eine Übersicht über spezielle IP-Adressbereiche, die

für dedizierte Zwecke vorgesehen und nicht an beliebige Hosts im Internet vergeben

werden.

Tabelle 3: Reservierte IP-Adresskreise bei IPv6

CIDR-Adressblock Beschreibung Spezifikation

0:0:0:0:0:0:0:0

oder ::/128:

0:0:0:0:0:0:0:1

oder ::1/128:

0:0:0:0:0:FFFF:a.b.c.d/96

oder ::FFFF:a.b.c.d/96:

0000::/8

Nicht spezifizierte IPv6-Adresse, die unter

IPv4 dem Wert 0.0.0.0 entspricht.

Loopback-Adresse

RFC 4291

RFC 4291

IPv4-als-IPv6-Adresse RFC 4030

von der IETF reserviert; Ausnahme sind

Adressen mit dem Format

0:0:0:0:0:0:a.b.c.d/96 oder ::a.b.c.d/96.

0100::/8 von der IETF reserviert

0200::/7 von der IETF reserviert

0400::/6 von der IETF reserviert

0800::/5 von der IETF reserviert

1000::/4 von der IETF reserviert

2000::/3

Global Unicast; global gültige und eindeutige

Unicast-Adressen, die im Internet

geroutet werden

2001:DB8::/32 Reserviert für Dokumentationszwecke RFC 3849

2001:0000::/32 Toredo-Tunneling RFC 4380

2001:10::/28

Keine IPv6-Adressen, sondern “Overlay

Routable Cryptographic Hash IDentifiers”

(ORCHID). Diese Pseudo-Adressen sind

nicht route-bar uns sollten nicht im öffentlichen

Netzwerk eingesetzt werden.

RFC 4843

2002::/16 6to4-Tunneling RFC 3056

4000::/3 von der IETF reserviert

6000::/3 von der IETF reserviert

8000::/3 von der IETF reserviert

A000::/3

von der IETF reserviert

Christian Book

http://rfc791.de/whitepaper 12/24


Whitepaper ISO OSI Referenzmodell und Protokolle 29. April 2013

CIDR-Adressblock Beschreibung Spezifikation

C000::/3

von der IETF reserviert

4000::/3 von der IETF reserviert

6000::/3 von der IETF reserviert

8000::/3 von der IETF reserviert

A000::/3

C000::/3

E000::/4

von der IETF reserviert

von der IETF reserviert

von der IETF reserviert

F000::/5

von der IETF reserviert

F800::/6

FC00::/7

FE00::/9

FE80::/10

von der IETF reserviert

Unique Local Unicast; eindeutige, lokale

Unicast-Adressen, die jedoch im Internet

nicht geroutet werden.

von der IETF reserviert

Link Local Unicast;

RFC 4193

RFC 4291

FE00::/8 Multicast RFC 4291

2.4. IPsec

IPsec ist die Kurzform für Internet Protocol Security. Das Sicherheitsprotokoll wurde für

die Implementierung der Schutzziele Vertraulichkeit, Authentizität und Integrität bei

der Kommunikation in IP-Netzen definiert. Im RFC 4301 4 ist die Architektur von IPsec

beschrieben. IPsec nuztz die Protokolle Authentication Header (AH) 5 , Encapsulated

Security Payload (ESP) 6 sowie Internet Key Exchange (IKE) 7 , welches zum Austausch

der Schlüssel eingesetzt wird.

Anders als Verschlüsselungsprotokollen wie etwa dem Secure Sockets Layer (SSL) 8

arbeitet IPsec direkt auf der Vermittlungsschicht des OSI-Referenzmodells und kann

zum Aufbau virtueller privater Netzwerke (VPN) auf Netzwerkebene verwendet werden.

4 (Kent & Seo, RFC 4301 - Security Architecture for the Internet Protocol, 2005)

5 (Kent, RFC 4302 - IP Authentication Header, 2005)

6 (Eastlake, RFC 4305 - Cryptographic Algorithm Implementation Requirements for

Encapsulating Security Payload (ESP) and Authentication Header (AH), 2005)

7 (Kaufman, 2005)

8 (Dierks & Rescorla, 2008)

Christian Book

http://rfc791.de/whitepaper 13/24


Whitepaper ISO OSI Referenzmodell und Protokolle 29. April 2013

IPsec verwaltet Verbindungen und kann neben der Verschlüsselung auch Datenintegrität

garantieren. Dabei stellt der transport mode eine Punkt-zu-Punkt-

Kommunikation zwischen zwei Endpunkten her. Der tunnel mode verbindet hingegen

zwei IP-Netze über zwei Router miteinander.

Der Authentication Header (AH) stellt die Authentizität und Integrität der übertragenen

Pakete sicher und kann dabei den Sender authentisieren. Der AH schützt die

invarianten Bestandteile des IP-Pakets, während die Bereiche des IP-Headers, die von

Routern verändert werden können, nicht berücksichtigt werden. Die Nutzdaten werden

bei AH nicht verschlüsselt; es wird lediglich die Authentizität sichergestellt. Problematisch

ist der Einsatz von Network Address Translation (NAT), da dabei eigentlich

invariante Bestandteile des IP-Pakets verändert werden und eine Authentisierung so

unmöglich wird. Die Verfahren NAT und AH sind daher designbedingt inkompatibel,

während NAT und ESP kombinierbar 9 sind. Authentication Header basiert direkt auf

dem Internet Protocol und verwendet die IP-Protokoll Nummer 51.

Der Header eines IPSec -AH-Pakets ist in der nachfolgenden Grafik dargestellt.

Abbildung 6: IPSec-AH-Header

Encapsulating Security Payload (ESP) soll neben der Authentisierung und Integrität

auch Vertraulichkeit von IP-Paketen sicherstellen. Anders als beim Authentication

Header wird der Header des IP-Paketes vom Integrity Check Value (ICV) nicht berücksichtigt.

Jedoch werden bei ESP die Nutzdaten verschlüsselt übertragen, sodass

eine unberechtigte Einsicht oder Manipulation verhindert wird. Wie AH basiert auch

ESP direkt auf dem Internet Protocol. ESP verwendet die IP-Protokoll Nummer 50.

Der Header eines IPSec -ESP-Pakets ist in der nachfolgenden Grafik dargestellt.

Abbildung 7: IPSec-ESP-Header

9 (Huttunen, Swander, Volpe, DiBurro, & Stenberg, 2005)

Christian Book

http://rfc791.de/whitepaper 14/24


Whitepaper ISO OSI Referenzmodell und Protokolle 29. April 2013

Im transport mode wird der IPsec-Header zwischen dem IP-Header und den Nutzdaten

eingefügt. Da der IP-Header unverändert bleibt, kann er weiterhin für das Routing

des Pakets vom Sender zum Empfänger verwendet werden. Der transport mode wird

eingesetzt, wenn die kryptographischen Endpunkte auch die Kommunikations-

Endpunkte der Verbindung sind; die Verschlüsselung also von Ende zu Ende durchgeführt

wird. Der Empfänger eines IPsec-Paketes extrahiert die ursprünglichen Nutzdaten

und leitet sie an die höher liegenden Schichten.

Die nachfolgende Abbildung zeigt den geschachtelten Aufbau der Header-

Informationen im IPsec ESP transport mode.

Abbildung 8: IPsec ESP im transport mode

Die nachfolgende Abbildung zeigt den geschachtelten Aufbau der Header-

Informationen im IPsec AH transport mode.

Abbildung 9: : IPsec AH im transport mode

Im tunnel mode wird das ursprüngliche IP-Paket gekapselt und die von IPsec bereitgestellten

Funktionen auf das gesamte IP-Paket angewandt. Der so neu erzeugte,

äußere IP-Header dient der Adressierung der kryptografischen Endpunkte des Tunnels.

Die Adressen der eigentlichen Kommunikationsendpunkte werden im inneren IP-

Header transportiert. Dieser innere IP-Header wird auf während des Transports zwischen

den Tunnelenden nur Nutzlast angesehen. Er wird erst wieder verwendet,

nachdem der Empfänger die IPsec-Kapselung entfernt hat und das ursprüngliche IP-

Paket dem eigentlichen Empfänger zustellt.

Christian Book

http://rfc791.de/whitepaper 15/24


Whitepaper ISO OSI Referenzmodell und Protokolle 29. April 2013

Die nachfolgende Abbildung zeigt den geschachtelten Aufbau der Header-

Informationen im IPsec ESP tunnel mode.

Abbildung 10: IPsec ESP im tunnel mode

Die nachfolgende Abbildung zeigt den geschachtelten Aufbau der Header-

Informationen im IPsec AH tunnel mode.

Abbildung 11: IPsec AH im tunnel mode

Wesentliche Vorteile von IPsec gegenüber anderen VPN-Verfahren wie L2TP oder

PPTP ist die Transparenz gegenüber Applikationen, die gute Integrationsfähigkeit in

bestehende Netze sowie die Architektur, die unabhängige Protokolle zur Authentifizierung

und Verschlüsselung vorsieht. IPsec stellt jedoch hohe Anforderungen an die

Hardware-Ressourcen und ist ausschließlich für IP-basierte Dienste nutzbar.

Bruce Schneier und Niels Ferguson evaluierten das ursprüngliche IPsec-Protokoll 10

mehrfach und kritisieren insbesondere die hohe Komplexität und die damit verbundene

Fehleranfälligkeit. Dennoch bestätigen die beiden Experten, dass IPsec die

derzeit beste Absicherung für IP-Kommunikation darstellt. „IPsec was a great disappointment

to us. Given the quality of the people that worked on it and the time that

was spent on it, we expected a much better result.” 11

10 (Kent & Atkinson, RFC 2401 - Security Architecture for the Internet Protocol, 1998)

11 (Ferguson & Schneier, 2003)

Christian Book

http://rfc791.de/whitepaper 16/24


Whitepaper ISO OSI Referenzmodell und Protokolle 29. April 2013

2.5. Transmission Control Protocol TCP

Das Transmission Control Protocol (TCP) ist im RFC 793 12 definiert und beschreibt ein

zuverlässiges, verbindungsorientiertes, paketvermittelndes Transportprotokoll zum Datenaustausch.

Eine TCP-Verbindung wird eindeutig durch zwei - aus IP-Adresse und Port eindeutig

definierte - Endpunkte identifiziert. Ein solches Paar wird als Socket bezeichnet. Dabei

werden durch die IP-Adressen die beteiligten Rechner identifiziert, während durch

die Ports die auf den beiden beteiligten Rechnern kommunizierenden Prozesse identifiziert

werden.

Ein Server wartet auf einem definierten Port auf eingehende Verbindungen und setzt

bei einem Verbindungsaufbau durch einen Client die Verbindung auf einem anderen

Socket fort. Dies ermöglicht dem Webserver mehrere Verbindungen zu verschiedenen

Rechnern parallel zu verwenden.

Für die Angabe des Ports stehen im TCP-Header 16-Bit zur Verfügung. Die Port-

Nummern befinden sich daher im Wertebereich von 0 bis 65535. Dabei sind die Ports

0 bis 1023 für ausgewählte Anwendungen reserviert. Diese Well-Known Ports werden

von der IANA 13 vergeben. Im Bereich von 1024 bis 49151 befinden sich die Registered

Ports, die Anwendungshersteller bei Bedarf für eigene Protokolle registrieren lassen

können. Die Ports 49152 bis 65535 sind als Dynamic / Private Ports variabel einsetzbar.

Sie sind nicht registriert und damit keiner Anwendung zugeordnet.

Der Header eines TCP-Segments ist in der nachfolgenden Grafik dargestellt.

Abbildung 12: TCP Header

Ein wichtiger Bestandteil des Transmission Control Protocol ist der Three-Way-

Handshake. Er dient dem Verbindungsaufbau und besteht aus drei TCP-Segmenten,

12 (Postel, RFC 793 - Transmission Control Protocol, 1981)

13 http://www.iana.org/assignments/service-names-port-numbers/service-names-portnumbers.xml

Christian Book

http://rfc791.de/whitepaper 17/24


Whitepaper ISO OSI Referenzmodell und Protokolle 29. April 2013

die zwischen Client und Server vor der Übertragung der Nutzdaten ausgetauscht

werden.

Der Client sendet initial SYN-Segment mit einer Sequenznummer x an den Server. Die

Sequenznummer stellt die vollständige Übertragung aller TCP-Segmente in der korrekten

Reihenfolge und ohne Duplikate sicher. Dabei ist Start-Sequenznummer beliebt,

ihre Generierung ist der jeweiligen TCP-Implementierung abhängig.

Der Server empfängt das Paket und antwortet mit einem RST-Segment, um zu signalisieren,

dass der angesprochene Port geschlossen ist und daher keine Verbindung

aufgebaut werden kann. Bei einem geöffneten Port bestätigt der Server den Erhalt

des SYN-Segments und setzt den Verbindungsaufbau fort, indem er ein SYN/ACK-

Segment an den Client sendet. Dabei ist das ACK-Flag im TCP-Header gesetzt, der

ACK-Wert entspricht der Sequenznummer x+1 des SYN-Segments. Zusätzlich sendet

der Server eine eigene Start-Sequenznummer y.

Abschließend bestätigt der Client den Erhalt des SYN/ACK-Segments durch ein eigenes

ACK-Segment mit der Sequenznummer x+1 und dem ACK-Wert y+1. Die Verbindung

ist damit erfolgreich hergestellt. Nach dem Aufbau der TCP-Sitzung sind beide

Kommunikationspartner gleichberechtigt.

Die nachfolgende Grafik zeigt den schematischen Ablauf eines TCP Three-Way-

Handshake zum Aufbau einer Verbindung.

Abbildung 13: TCP-Verbindungsaufbau

Der geregelte Verbindungsabbau erfolgt ähnlich dem Verbindungsaufbau. Das gesetzte

FIN Flag des TCP-Segments zeigt an, dass der Sender keine weiteren Daten

schicken wird. Der Client bestätigt den Erhalt des FYN-Segments mit einem ACK. Der

Empfänger des FIN-Segments sendet zudem ebenfalls ein FIN-Segment. Auch dieses

wird durch ein ACK bestätigt.

Ein verkürztes Verfahren zum Verbindungsabbau ist ebenfalls definiert. Dabei werden

FIN und ACK anlog zum Verbindungsaufbau im Segment übertragen.

Die nachfolgende Grafik zeigt den schematischen Ablauf des Verbindungsabbaus

einer TCP-Verbindung.

Christian Book

http://rfc791.de/whitepaper 18/24


Whitepaper ISO OSI Referenzmodell und Protokolle 29. April 2013

Abbildung 14: TCP-Verbindungsabbau

Der Three-Way-Handshake des TCP-Protokolls wird für einige Port-Scanning-Techniken

missbraucht, um anhand des Verhaltens der Gegenseite festzustellen, ob ein Port

geöffnet, geschlossen und durch eine Firewall blockiert wird.

2.6. User Datagram Protocol UDP

Das User Datagram Protocol (UDP) ist ein verbindungsloses Netzwerkprotokoll. Das im

RFC 768 14 definierte Protokoll ist Transportschicht des OSI Referenzmodells zuzuordnen.

UDP ist ein verbindungsloser, nicht-zuverlässiger und ungesicherter sowie ungeschützter

Übertragungsdienst.

UDP wurde ab 1977 als Alternative für das verbindungsorientierte Protokoll TCP entwickelt.

Speziell für die Übertragung von Sprache wurde Protokoll benötigt, das lediglich

die Adressierung vornimmt. Auf die Sicherung der Datenübertragung sollte verzichtet

werden, da dies zu Verzögerungen bei der Sprachübertragung führt.

Da vor Übertragungsbeginn keine Verbindung aufgebaut wird und somit auf einen

Three-Way-Handshake verzichtet werden kann, können die Kommunikationspartner

schneller als bei TCP mit dem Datenaustausch beginnen. Insbesondere einfache Protokolle

wie beispielsweise das Domain Name System verwenden UDP, um die Belastung

des Netzwerks zu minimieren und den Datendurchsatz zu steigern.

Die maximale Größe eines UDP-Segments beträgt 65.535 Bytes, jedoch werden derart

große Segmente im Internet Protocol fragmentiert übertragen. Neben den zu

übertragenden Nutzdaten enthält das UDP-Segment einen Header. Der UDP-Header

besteht aus vier jeweils 16 Bit großen Datenfeldern. Der Quell-Port definiert den Port

des sendenden Prozesses. Diese Information wird benötigt, damit der Empfänger auf

das Paket antworten kann. Sofern keine Antwortpakete erwartet werden und nur

Pakete zum Empfänger gesendet werden sollen, ist der Quell-Port optional. Der Ziel-

Port definiert, welcher Prozess das Paket empfangen soll. Im Längenfeld wird die Gesamtlänge

des UDP-Segments in Oktetten hinterlegt. Der kleinstmögliche Wert sind 8

Oktette. Das Prüfsummenfeld kann eine 16 Bit große Prüfsumme enthalten. Diese

Prüfsumme wird über den Pseudo-Header, den UDP Header und die Daten gebildet.

Obwohl die Prüfsumme optional ist, wird sie jedoch in der Praxis nahezu immer benutzt.

Der Header eines UDP-Segments ist in der nachfolgenden Grafik dargestellt.

14 (Postel, RFC 768 - User Datagram Protocol, 1980)

Christian Book

http://rfc791.de/whitepaper 19/24


Whitepaper ISO OSI Referenzmodell und Protokolle 29. April 2013

Abbildung 15: UDP Header

2.7. Internet Control Message Protocol ICMP

Das RFC 792 15 aus dem Jahr 1981 definiert unter der Bezeichnung Internet Control

Message Protocol - kurz ICMP - ein Protokoll spezifiziert, das dem Austausch von Informations-

und Fehlermeldungen über das Internet-Protokoll dient. ICMP ist nach

Definition vorgeschriebener Bestandteil von IPv4-Implementationen, wird aber als

eigenständiges Protokoll behandelt.

ICMP ist spezifiziert für die Version 4 des Internet Protocol (IPv4). Das Protokoll Internet

Control Message Protocol for the Internet Protocol Version 6 (ICMPv6) 16 ist das Gegenstück

in IPv6-Umgebungen und in.

ICMP-Nachrichten werden als Nutzlast in IP-Datagramme eingekapselt. Dabei werden

im IP-Header der Servicetyp 0 und die Protokollnummer 1 gesetzt. Im Fall von

ICMPv6 lautet die Protokollnummer 58. Um verschiedene Aufgaben und Zustände

übermitteln zu können, bietet ICMP verschiedene Typen und Codes. Zu jedem Typ

kann es mehrere Codes geben, die den Typ genauer spezifizieren.

Die nachfolgende Tabelle zeigt die wichtigsten Typen und Codes von ICMP (in Version

4), eine vollständige Liste 17 wird von der IANA gepflegt.

Tabelle 4: ICMP ausgewählte Typen und Codes

Typ Typ-Name

Code Interpretation

0 Echo Antwort 0 Echo-Antwort

3 Ziel nicht erreichbar 0 Netzwerk nicht erreichbar

1 Host nicht erreichbar

2 Protokoll nicht erreichbar

3 Port nicht erreichbar

4 Fragmentierung nötig, Don’t Fragment aber gesetzt

5 Route nicht möglich (die Richtung in IP-Header-

Feld Option falsch angegeben)

6 Ziel-Netzwerk unbekannt

8 Quell-Host isoliert

15 (Postel, RFC 792 - Internet Control Message Protocol, 1981)

16 (Conta, Deering, & Gupta, 2006)

17 http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xml

Christian Book

http://rfc791.de/whitepaper 20/24


Whitepaper ISO OSI Referenzmodell und Protokolle 29. April 2013

Typ Typ-Name

Code Interpretation

9 Kommunikation mit Ziel-Netzwerk administrativ

verboten

10 Kommunikation mit Ziel-Host administrativ verboten

11 Ziel-Netzwerk für Service-Typ nicht erreichbar

12 Ziel-Host für Service-Typ nicht erreichbar

13 Kommunikation administrativ verboten (Ursache:

Packet wird von der Firewall des Empfängers

geblockt)

4 Entlasten der Quelle

0 Datagramm verworfen, da Warteschlange voll

5 Umleitung 0 Datagramm umleiten

8 Echo Anfrage 0 Echo-Anfrage („Ping“)

11 Zeitlimit überschritten

0 Lebensdauer (TTL) abgelaufen

1 Zeitlimit während der Defragmentierung überschritten

13 Zeitstempel Anfrage

0 Anforderungen der aktuellen Systemzeit

14 Zeitstempel Antwort 0 Meldung der aktuellen Systemzeit

17 Subnetz Anfrage 0 Anforderungen der aktuellen Subnetz-Maske

18 Subnetz Antwort 0 Meldung der aktuellen Systemzeit

30 Traceroute 0 Traceroute

Die bekannteste Anwendung von ICMP ist die Applikation “Ping”. Dabei wird ein

ICMP-Paket vom Typ 8 Code 0 (Echo Anfrage) an ein entferntes Gerät verschickt.

Erhält der Absender ein ICMP-Paket vom Typ 0 Code 0 zurück, ist das entsprechende

Gerät auf Netzwerk-Ebene (Layer 3) erreichbar. Bleibt dieses Paket aus, gibt es Probleme

in der IP-Kommunikation. Ping wird daher häufig als erstes Hilfsmittel im Debugging

von IP-Netzwerken eingesetzt.

Der Aufbau eines ICMP-Headers ist in der nachfolgenden Grafik dargestellt.

Abbildung 16: ICMP Header

Christian Book

http://rfc791.de/whitepaper 21/24


Whitepaper ISO OSI Referenzmodell und Protokolle 29. April 2013

3. Über den Autor

CHRISTIAN BOOK studierte Wirtschaftsinformatik in Oldenburg und beschäftigt sich seit

einigen Jahren als Consultant im Bereich Informationssicherheit vorwiegend mit der

IT-Sicherheit in "Kritischen Infrastrukturen" wie Netzleitsystemen, Smart Grids und im

Umfeld von Smart Metering. Zudem führt er Penetrationstests gegen IT-Systeme und

insbesondere Web-Applikation durch und berät branchenübergreifend bei der sicheren

Konzeption und Implementierung von komplexen IT-Infrastrukturen. Im Rahmen

von Incident Response unterstützt er bei der Aufdeckung, Bewältigung und

Analyse von akuten Informationssicherheitsvorfällen, beispielsweise bei großflächiger

Beeinträchtigung durch Schadsoftware oder Denial-of-Service-Angriffen.

Für den TÜV InterCert Saar und den TÜV Hessen überprüft und zertifiziert Christian

Book als Auditor und Fachexperte unter anderem Web-Applikation.

Als aktives Mitglied des International Council of Electronic Commerce Consultants

(EC Council) verfügt Christian Book derzeit über Zertifizierungen als Certified Ethical

Hacker (CEH), Licensed Penetration Tester (LPT) und EC Council Certified Security

Analyst (ECSA). Daneben hält er Zertifizierungen als WatchGuard Certified System

Professional (WCSP XTM) sowie als Cisco Certified Network Associate (CCNA). Seit

2012 ist er darüber hinaus als Certified Information Systems Security Professional

(CISSP) aktives Mitglied von (isc)².

Weiterführende Informationen zum Autor dieses Whitepapers finden Sie unter

HTTP://CHRISTIAN-BOOK.DE

Christian Book

http://rfc791.de/whitepaper 22/24


Whitepaper ISO OSI Referenzmodell und Protokolle 29. April 2013

4. Literaturverzeichnis

Conta, A., Deering, S., & Gupta, M. (März 2006). RFC 4443 - Internet Control Message

Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification.

Abgerufen am 12. Oktober 2011 von The Internet Engineering Task Force (IETF):

http://tools.ietf.org/html/rfc4443

Deering, S. E., & Hinden, R. M. (Dezember 1998). RFC 2460 - Internet Protocol, Version

6 (IPv6). Abgerufen am 12. Oktober 2011 von The Internet Engineering Task

Force (IETF): http://tools.ietf.org/html/rfc2460

Dierks, T., & Rescorla, E. (August 2008). RFC 5246 - The Transport Layer Security (TLS)

Protocol Version 1.2. Abgerufen am 21. Oktober 2011 von The Internet

Engineering Task Force (IETF): http://tools.ietf.org/html/rfc5246

Eastlake, D. E. (Dezember 2005). RFC 4305 - Cryptographic Algorithm Implementation

Requirements for Encapsulating Security Payload (ESP) and Authentication

Header (AH). Abgerufen am 30. Oktober 2011 von The Internet Engineering

Task Force (IETF): http://tools.ietf.org/html/rfc4305

Ferguson, N., & Schneier, B. (Dezember 2003). A Cryptographic Evaluation of IPsec.

Abgerufen am 28. Oktober 2011 von Schneier on Security:

http://www.schneier.com/paper-ipsec.html

Huttunen, A., Swander, B., Volpe, V., DiBurro, L., & Stenberg, M. (Januar 2005). RFC

3948 - UDP Encapsulation of IPsec ESP Packets. Abgerufen am 04. November

2011 von The Internet Engineering Task Force (IETF):

http://tools.ietf.org/html/rfc3948

Kaufman, C. (Dezember 2005). RFC 4306 - Internet Key Exchange (IKEv2) Protocol.

Abgerufen am 28. Oktober 2011 von The Internet Engineering Task Force (IETF):

http://tools.ietf.org/html/rfc4306

Kent, S. (Dezember 2005). RFC 4302 - IP Authentication Header. Abgerufen am 02.

Oktober 2011 von The Internet Engineering Task Force (IETF):

http://tools.ietf.org/html/rfc4302

Kent, S., & Atkinson, R. (November 1998). RFC 2401 - Security Architecture for the

Internet Protocol. Abgerufen am 12. September 2011 von The Internet

Engineering Task Force (IETF): http://tools.ietf.org/html/rfc2401

Kent, S., & Seo, K. (Dezember 2005). RFC 4301 - Security Architecture for the Internet

Protocol. Abgerufen am 12. September 2011 von The Internet Engineering Task

Force (IETF): http://tools.ietf.org/html/rfc4301

Postel, J. B. (August 1980). RFC 768 - User Datagram Protocol. Abgerufen am 21.

September 2011 von The Internet Engineering Task Force (IETF):

http://tools.ietf.org/html/rfc768

Christian Book

http://rfc791.de/whitepaper 23/24


Whitepaper ISO OSI Referenzmodell und Protokolle 29. April 2013

Postel, J. B. (September 1981). RFC 791 - Internet Protocol. Abgerufen am 03.

September 2011 von The Internet Engineering Task Force (IETF):

http://www.ietf.org/rfc/rfc0791.txt

Postel, J. B. (September 1981). RFC 792 - Internet Control Message Protocol.

Abgerufen am 21. September 2011 von http://tools.ietf.org/html/rfc792

Postel, J. B. (September 1981). RFC 793 - Transmission Control Protocol. Abgerufen am

28. September 2011 von The Internet Engineering Task Force (IETF):

http://tools.ietf.org/html/rfc793

Zimmermann, H. (1980). OSI Reference Model—The ISO Model of Architecture for

Open Systems Interconnection. IEEE Transactions on Communications(28).

Weitere interessante Whitepaper zu den

Themen IT-Sicherheit und Netzwerken finden Sie unter

HTTP://RFC791.DE/WHITEPAPER

Christian Book

http://rfc791.de/whitepaper 24/24

Weitere Magazine dieses Users
Ähnliche Magazine