PPP

PPP, das sogenannte Point-to-Point-Protocol, ist nicht etwa nur eines, sondern eine ganze Gruppe von Protokollen für P2P-Verbindungen, die in RFC 1661 definiert ist und in verschiedenen weiteren RFCs (RFC1662, RFC1663) weiter ausgeführt wird.

Die drei wichtigsten Merkmale sind:

Eine Rahmenformat das Anfang und Ende eindeutig kennzeichnet und eine Möglichkeit zur Fehlerkorrektur bietet.
Ein Verbindungssteuerungsprotokoll namens Link Control Protocol (LCP) um Leitungen zu testen, Verbindungen auf- und abzubauen und Übertragungsoptionen auszuhandeln
Die Möglichkeit auf der Vermittlungsschicht Optionen auszuhandeln, die von dem auf der Vermittlungsschicht gewählten Protokoll abhängen. Dabei läuft für jedes auf der Vermittlungsschicht gewählte Protokoll ein eigenes Network Control Protocol
Authentifizierungsmöglichkeiten um sicherzugehen, das man mit dem richtigen Partner verbunden ist.
Möglichkeiten zur Kompression von Header und Nutzdaten um die verfügbare Bandbreite möglichst optimal auszunutzen.

Philosophie von PPP

Bei PPP sind beide Partner gleichberechtigt, es kann also nicht eindeutig einem Partner die Rolle des Servers und dem anderen die Rolle des Clients zugeordnet werden. Die offizielle Dokumentation, die RFCs sprechen deshalb auch immer von »Peers« (Ebenbürtigen).

Die Einzelheiten einer PPP-Session werden deshalb auch nicht von einem Rechner vorgegeben und dann vom anderen übernommen, sondern es wird alles ausgehandelt, d.h. die eine Seite macht einen Vorschlag und die andere Seite stimmt zu, lehnt ab oder macht einen Gegenvorschlag. Kommt es zu keiner Einigung, so wird die PPP-Sitzung abgebrochen. Bei den meisten PPP-Implementierungen kann man dann in einer Protokolldatei nachlesen, woran die Verbindung gescheitert ist. So ist es zum Beispiel üblich, das eine Verbindung zu einem Internet Server Provider abgelehnt wird, wenn der einwählende Rechner die Authentifizierung verweigert, dagegen wird es meistens toleriert, wenn die PPP-Implementierung des einwählenden Rechners die Komprimierung ablehnt.

Authentifizierung unter PPP

Mit PPP stehen 2 Möglichkeiten zur Authentifizierung zur Verfügung: Zum Ersten

PAP

das Password Authentification Protocol, bei dem Passworte unverschlüsselt über die Leitung übertragen werden. Dieses Verfahren ist anfällig für Lauschangriffe auf die Leitung und sollte deshalb vermieden werden. Eine wesentlich sicherere Methode ist

CHAP

das Challenge Handshake Authentification Protocol, bei dem das Passwort selbst überhaupt nicht übertragen wird. Stattdessen sendet der Rechner gegenüber dem die Authentifizierung erfolgen soll eine einmalige Zeichenfolge, die sogenannte »Challenge« (Herausforderung). Der authentifizierende Rechner empfängt diese Challenge und verquickt diese Challenge mit mit einem MD5-Hash (einer nicht umkehrbaren aber eindeutigen Verschlüsselung) des Passworts und sendet das Ergebnis zurück. Stimmt das Ergebnis des authentifizierenden Rechners mit dem Ergebnis des Rechners gegen den die Authentifizierung erfolgen soll überein, so ist die Authentifizierung erfolgt. Da der MD5-Hash nicht umkehrbar ist kann aus den abgehörten Daten nicht das Passwort rekonstruiert werden und da die Challenge für jede Session eine andere ist, kann auch durch einfaches Wiedersenden der abgehörten Informationen kein Zugang erworben werden.

Eine dritte Variante der PPP-Authentifizierung wurde von Microsoft entwickelt und hört auf den Namen

MS-CHAP

Diese Variante wird vom RAS-Dienst von Windows NT verwendet und funktioniert nur zwischen Windows-Rechnern. Es gibt zwar Implementierungen für freie UNIX-Systeme, aber sie stellt keinen gültigen Standard dar. Die Auswahl dieser Option erlaubt zusätzlich noch den Datenstrom zu verschlüsseln.

Beispiel einer PPP-Session

Ernst Förster möchte eine PPP-Verbindung zu seinem Internet-Provider aufbauen um sich über die neuesten Angebote für jagdlich nutzbare Mittelstreckenraketen zu informieren.
Der PC ruft nun also den Einwahlknoten des Providers an, und wartet bis sich das gegnerische Modem, beziehungsweise der gegnerische ISDN-Router meldet. und eine physikalische Verbindung aufgebaut hat.

Nachdem die Verbindung aufgebaut wurde sendet der PC dem gegnerischen Router eine Reihe von LCP-Pakten im Nutzdatenfeld von einem oder mehreren PPP-Rahmen. Diese Pakete und ihre Antworten wählen die zu verwendenden Optionen. Die RFC 1661 definiert 11 Sorten LCP-Pakete mit denen über die Leitung verhandelt werden kann: Der aufbauende PC ist Initiator, der Router der Reagierende

Bezeichnung Richtung Zweck

Configure Request zum Reagierenden Liste der gewünschten Optionen

Configure-ack zum Initiierende Alle Optionen angenommen

Configure-nack zum Initiierenden Einige Optionen nicht angenommen

Configure-reject zum Initiierenden Einige Optionen sind nicht verhandelbar

Terminate-Request zum Reagierenden Anforderung die Verbindung zu trennen

Terminate-ack zum Initiierenden Verbindung trennen bestätigt

Code-Reject zum Initiierenden Unbekannte Anforderung erhalten

Protocol-reject zum Initiierenden Unbekanntes Protokoll erhalten

Echo-Request zum Reagierenden Anforderung den Frame zurückzuschicken

Echo-Reply zum Initiierenden Frame zurück

Discard-Request zum Reagierenden Anforderung den Frame zu ignorieren

Zu den verhandelbaren Optionen gehören z.B. die maximale Größe von Datenrahmen ( Maximum Transfer Unit (MTU), das zu verwendende Protokoll, wie man sich authentifiziert, verschiedene Verfahren der Header-Kompression und was sonst noch so anfällt.

Nach dem die beiden Rechner den LCP-Teil abgehandelt haben, werden mehrere NCP (Network Core Protocol)-Pakete ausgetauscht. Hier wird z.B. festgelegt was für eine IP-Adresse Foersters PC von seinem Provider bekommt. Außerdem wird auf dieser Ebene auch noch eine eventuelle Authentifizierung durchgeführt.
Ist auch das abgehandelt, kann Ernst Foerster seine (in diesem Fall wohl IP-) Pakete senden und empfangen um zur Seite seines Waffenhändlers zu surfen und sich zu informieren
Ist er fertig, so beendet er diese Verbindung. Dabei wird das NCP benutzt um die Verbindung auf der Vermittlungsschicht abzubauen, dann wird über LCP die Verbindung auf der Sicherungsschicht beendet und schließlich bekommt auf der Transportschicht das zuständige Gerät den Befehl aufzulegen.

Der PPP-Frame

Bytes	1	1	1	1 oder 2	variabel	2 oder 4	1
	Flag (01111110)	Adresse (11111111)	Steuerung (11111111)	Protokoll (11111111)	Nutzdaten (11111111)	Prüfsumme (11111111)	Flag (01111110)

Alle PPP-Frames beginnen und Enden mit einem Flag, das Anfang und Ende markiert. Wenn dieses Flag in den Nutzdaten auftaucht, dann wird es natürlich gestopft.
Als nächstes kommt das Adressfeld, das immer auf den Wert 255 gesetzt ist, und damit anzeigt, das alle Stationen den Frame akzeptieren. RFC 1662 empfiehlt Frames mit einer anderen Adresse einfach wegzuwerfen.
Darauf folgt das Feld Steuerung mit dem Vorgabewert 00000011. Das bezeichnet einen unnummerierten Frame und damit eine unzuverlässige Verbindung , aber das kann über LCP noch verhandelt werden.
Nachdem in Adresse und Steuerung sowieso immer das Gleiche steht kann auch eine Protokollvariante ausgehandelt werden, die diese beiden Felder einfach weglässt
Feld Nummer 4 ist das Protokollfeld, das angibt, welche Art von Paketen sich im Nutzdatenfeld befindet. Es gibt definierte Codes für LCP, NCP, IP, IPX, .... Protokolle die mit einem 0-Bit beginnen sind Protokolle der Vermittlungsschicht, solche die mit einem 1-Bit beginne sind Protokolle der Sicherungsschicht.
Die Länge des Nutzdatenfeldes wird mit LCP ausgehandelt. Wird keine Länge ausgehandelt, so sind es 1500 Bytes. Sind weniger Daten zu übertragen, als der Länge des Nutzdatenfeldes entspricht, dann wird es aufgefüllt. Man spricht hier von Padding
Als vorletztes kommt eine Prüfsumme, die über ein CRC-Verfahren berechnet wird