4. Attribut-Wert-Paare für Kontrollnachrichten
Um die Erweiterbarkeit zu maximieren und gleichzeitig die Interoperabilität zu ermöglichen, wird in L2TP durchgehend eine einheitliche Methode zur Codierung von Nachrichtentypen und -körpern verwendet. Diese Codierung wird im Rest dieses Dokuments als AVP (Attribute-Value Pair, Attribut-Wert-Paar) bezeichnet.
4.1 AVP-Format
Jedes AVP wird wie folgt codiert:
0 1 2 3
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 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute Type | Attribute Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[bis Length erreicht ist]... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Die ersten sechs Bits sind eine Bitmaske, die die allgemeinen Attribute des AVP beschreibt.
Zwei Bits sind in diesem Dokument definiert, die übrigen sind für zukünftige Erweiterungen reserviert. Reservierte Bits MÜSSEN auf 0 gesetzt werden. Ein empfangenes AVP mit einem auf 1 gesetzten reservierten Bit MUSS als nicht erkanntes AVP behandelt werden.
Mandatory (M) Bit: Steuert das erforderliche Verhalten einer Implementierung, die ein AVP empfängt, das sie nicht erkennt. Wenn das M-Bit bei einem nicht erkannten AVP innerhalb einer Nachricht, die mit einer bestimmten Sitzung verbunden ist, gesetzt ist, MUSS die mit dieser Nachricht verbundene Sitzung beendet werden. Wenn das M-Bit bei einem nicht erkannten AVP innerhalb einer Nachricht, die mit dem gesamten Tunnel verbunden ist, gesetzt ist, MUSS der gesamte Tunnel (und alle darin enthaltenen Sitzungen) beendet werden. Wenn das M-Bit nicht gesetzt ist, MUSS ein nicht erkanntes AVP ignoriert werden. Die Kontrollnachricht muss dann weiterverarbeitet werden, als ob das AVP nicht vorhanden gewesen wäre.
Hidden (H) Bit: Identifiziert das Verstecken von Daten im Attribute Value-Feld eines AVP. Diese Fähigkeit kann verwendet werden, um die Weitergabe sensibler Daten wie Benutzerkennwörter als Klartext in einem AVP zu vermeiden. Abschnitt 4.3 beschreibt das Verfahren zum Verstecken von AVPs.
Length: Codiert die Anzahl der Oktette (einschließlich der Felder Overall Length und Bitmaske), die in diesem AVP enthalten sind. Die Länge kann als 6 + die Länge des Attribute Value-Feldes in Oktetten berechnet werden. Das Feld selbst ist 10 Bit groß und erlaubt maximal 1023 Oktette Daten in einem einzelnen AVP. Die Mindestlänge eines AVP beträgt 6. Wenn die Länge 6 beträgt, ist das Attribute Value-Feld nicht vorhanden.
Vendor ID: Der von der IANA zugewiesene Wert "SMI Network Management Private Enterprise Codes" [RFC1700]. Der Wert 0, entsprechend den von der IETF übernommenen Attributwerten, wird für alle in diesem Dokument definierten AVPs verwendet. Jeder Anbieter, der seine eigenen L2TP-Erweiterungen implementieren möchte, kann seine eigene Vendor ID zusammen mit privaten Attributwerten verwenden und so garantieren, dass sie nicht mit den Erweiterungen anderer Anbieter oder zukünftigen IETF-Erweiterungen kollidieren. Beachten Sie, dass 16 Bits für die Vendor ID zugewiesen sind, wodurch diese Funktion auf die ersten 65.535 Unternehmen beschränkt ist.
Attribute Type: Ein 2-Oktett-Wert mit einer eindeutigen Interpretation über alle unter einer bestimmten Vendor ID definierten AVPs hinweg.
Attribute Value: Dies ist der tatsächliche Wert, wie durch die Vendor ID und den Attribute Type angegeben. Es folgt unmittelbar nach dem Attribute Type-Feld und läuft über die in Length angegebenen verbleibenden Oktette (d. h. Length minus 6 Oktette Header). Dieses Feld ist nicht vorhanden, wenn Length 6 beträgt.
4.2 Obligatorische AVPs
Der Empfang eines unbekannten AVP mit gesetztem M-Bit ist katastrophal für die Sitzung oder den Tunnel, mit dem es verbunden ist. Daher sollte das M-Bit nur für AVPs definiert werden, die für den ordnungsgemäßen Betrieb der Sitzung oder des Tunnels absolut entscheidend sind. Darüber hinaus liegt es in dem Fall, dass der LAC oder LNS ein unbekanntes AVP mit gesetztem M-Bit empfängt und die Sitzung oder den Tunnel entsprechend herunterfährt, in der vollen Verantwortung des Peers, der das obligatorische AVP sendet, die Schuld für die Verursachung einer nicht interoperablen Situation zu akzeptieren. Bevor Sie ein AVP mit gesetztem M-Bit definieren, insbesondere ein herstellerspezifisches AVP, stellen Sie sicher, dass dies die beabsichtigte Konsequenz ist.
Wenn eine angemessene Alternative zur Verwendung des M-Bits existiert, sollte sie genutzt werden. Anstatt beispielsweise einfach ein AVP mit gesetztem M-Bit zu senden, um festzustellen, ob eine bestimmte Erweiterung vorhanden ist, kann die Verfügbarkeit identifiziert werden, indem ein AVP in einer Anforderungsnachricht gesendet und ein entsprechendes AVP in einer Antwortnachricht erwartet wird.
Die Verwendung des M-Bits mit neuen AVPs (solche, die nicht in diesem Dokument definiert sind) MUSS die Möglichkeit bieten, die zugehörige Funktion zu deaktivieren, sodass das AVP entweder nicht gesendet wird oder mit nicht gesetztem M-Bit gesendet wird.
4.3 Verstecken von AVP-Attributwerten
Das H-Bit im Header jedes AVP bietet einen Mechanismus, um dem empfangenden Peer anzuzeigen, ob der Inhalt des AVP versteckt oder im Klartext vorhanden ist. Diese Funktion kann verwendet werden, um sensible Kontrollnachrichtendaten wie Benutzerkennwörter oder Benutzer-IDs zu verbergen.
Das H-Bit DARF nur gesetzt werden, wenn zwischen LAC und LNS ein gemeinsames Geheimnis existiert. Das gemeinsame Geheimnis ist dasselbe Geheimnis, das für die Tunnel-Authentifizierung verwendet wird (siehe Abschnitt 5.1.1). Wenn das H-Bit in einem oder mehreren AVPs in einer bestimmten Kontrollnachricht gesetzt ist, MUSS auch ein Random Vector AVP in der Nachricht vorhanden sein und MUSS dem ersten AVP mit einem H-Bit von 1 vorausgehen.
Das Verstecken eines AVP-Werts erfolgt in mehreren Schritten. Der erste Schritt besteht darin, die Längen- und Wertfelder des ursprünglichen (Klartext-) AVP zu nehmen und sie wie folgt in ein verstecktes AVP-Unterformat zu codieren:
0 1 2 3
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 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of Original Value | Original Attribute Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Padding ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length of Original Attribute Value: Dies ist die Länge des zu verschleiernden ursprünglichen Attributwerts in Oktetten. Dies ist notwendig, um die ursprüngliche Länge des Attributwerts zu bestimmen, die verloren geht, wenn zusätzliches Padding hinzugefügt wird.
Original Attribute Value: Attributwert, der verschleiert werden soll.
Padding: Zufällige zusätzliche Oktette, die verwendet werden, um die Länge des zu verbergenden Attributwerts zu verschleiern.
Um die Größe der versteckten Daten zu maskieren, KANN das resultierende Unterformat wie oben gezeigt aufgefüllt werden. Padding ändert NICHT den im Feld Length of Original Attribute Value platzierten Wert, ändert aber die Länge des resultierenden AVP, das erstellt wird.
Als nächstes wird ein MD5-Hash über die Verkettung von durchgeführt:
- der 2-Oktett-Attributnummer des AVP
- dem gemeinsamen Geheimnis
- einem Zufallsvektor beliebiger Länge
Der Wert des in diesem Hash verwendeten Zufallsvektors wird im Wertfeld eines Random Vector AVP übergeben. Dieses Random Vector AVP muss vom Sender in der Nachricht vor versteckten AVPs platziert werden.
Der MD5-Hashwert wird dann mit dem ersten 16-Oktett- (oder kürzeren) Segment des versteckten AVP-Unterformats XORiert und im Attribute Value-Feld des versteckten AVP platziert.
Wenn das Unterformat länger als 16 Oktette ist, wird ein zweiter Einweg-MD5-Hash über einen Oktett-Strom berechnet, der aus dem gemeinsamen Geheimnis gefolgt vom Ergebnis des ersten XOR besteht. Dieser Hash wird mit dem zweiten 16-Oktett- (oder kürzeren) Segment des Unterformats XORiert und in den entsprechenden Oktetten des Wertfelds des versteckten AVP platziert.
Falls erforderlich, wird dieser Vorgang wiederholt, wobei das gemeinsame Geheimnis zusammen mit jedem XOR-Ergebnis verwendet wird, um den nächsten Hash zu generieren, um das nächste Segment des Werts zu XORieren.
Die Versteckmethode wurde aus RFC 2138 [RFC2138] adaptiert, das aus dem Abschnitt "Mixing in the Plaintext" im Buch "Network Security" von Kaufman, Perlman und Speciner [KPS] entnommen wurde. Eine detaillierte Erklärung der Methode folgt:
Nennen wir das gemeinsame Geheimnis S, den Zufallsvektor RV und den Attributwert AV. Teilen Sie das Wertfeld in 16-Oktett-Blöcke p1, p2 usw., wobei der letzte am Ende mit Zufallsdaten auf eine 16-Oktett-Grenze aufgefüllt wird. Nennen wir die Chiffretextblöcke c(1), c(2) usw. Wir definieren auch Zwischenwerte b1, b2 usw.
b1 = MD5(AV + S + RV) c(1) = p1 xor b1
b2 = MD5(S + c(1)) c(2) = p2 xor b2
. .
. .
. .
bi = MD5(S + c(i-1)) c(i) = pi xor bi
Die Zeichenfolge enthält c(1)+c(2)+...+c(i), wobei + die Verkettung bezeichnet.
Beim Empfang wird der Zufallsvektor aus dem letzten Random Vector AVP entnommen, das in der Nachricht vor dem zu entschleiernden AVP angetroffen wurde. Der obige Prozess wird dann umgekehrt, um den ursprünglichen Wert zu erhalten.
4.4 AVP-Übersicht
Die folgenden Abschnitte enthalten eine Liste aller in diesem Dokument definierten L2TP-AVPs.
Nach dem Namen des AVP folgt eine Liste, die die Nachrichtentypen angibt, die jedes AVP verwenden. Nach jedem AVP-Titel folgt eine kurze Beschreibung des Zwecks des AVP, eine Detailansicht (einschließlich einer Grafik) des Formats für den Attributwert und alle zusätzlichen Informationen, die für die ordnungsgemäße Verwendung des AVP erforderlich sind.
4.4.1 AVPs, die auf alle Kontrollnachrichten anwendbar sind
Message Type (Alle Nachrichten)
Das Message Type AVP, Attribute Type 0, identifiziert die Kontrollnachricht hierin und definiert den Kontext, in dem die genaue Bedeutung der folgenden AVPs bestimmt wird.
Das Attribute Value-Feld für dieses AVP hat das folgende Format:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Der Message Type ist eine 2-Oktett-Ganzzahl ohne Vorzeichen.
Das Message Type AVP MUSS das erste AVP in einer Nachricht sein, unmittelbar nach dem Kontrollnachrichten-Header (definiert in Abschnitt 3.1). Siehe Abschnitt 3.2 für die Liste der definierten Kontrollnachrichtentypen und deren Identifikatoren.
Das Mandatory (M) Bit innerhalb des Message Type AVP hat eine besondere Bedeutung. Anstatt eine Angabe darüber zu sein, ob das AVP selbst ignoriert werden sollte, wenn es nicht erkannt wird, ist es eine Angabe darüber, ob die Kontrollnachricht selbst ignoriert werden sollte. Wenn also das M-Bit innerhalb des Message Type AVP gesetzt ist und der Message Type der Implementierung unbekannt ist, MUSS der Tunnel gelöscht werden. Wenn das M-Bit nicht gesetzt ist, kann die Implementierung einen unbekannten Nachrichtentyp ignorieren. Das M-Bit MUSS für alle in diesem Dokument definierten Nachrichtentypen auf 1 gesetzt werden. Dieses AVP darf nicht versteckt werden (das H-Bit MUSS 0 sein). Die Länge dieses AVP beträgt 8.
Random Vector (Alle Nachrichten)
Das Random Vector AVP, Attribute Type 36, wird verwendet, um das Verstecken des Attribute Value beliebiger AVPs zu ermöglichen.
Das Attribute Value-Feld für dieses AVP hat das folgende Format:
0 1 2 3
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 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random Octet String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Die zufällige Oktettfolge kann beliebiger Länge sein, obwohl ein Zufallsvektor von mindestens 16 Oktetten empfohlen wird. Die Zeichenfolge enthält den Zufallsvektor zur Verwendung bei der Berechnung des MD5-Hashes zum Abrufen oder Verstecken des Attribute Value eines versteckten AVP (siehe Abschnitt 4.2).
In einer Nachricht kann mehr als ein Random Vector AVP erscheinen. In diesem Fall verwendet ein verstecktes AVP das Random Vector AVP, das ihm am nächsten vorausgeht. Dieses AVP MUSS dem ersten AVP mit gesetztem H-Bit vorausgehen.
Das M-Bit für dieses AVP MUSS auf 1 gesetzt werden. Dieses AVP DARF NICHT versteckt werden (das H-Bit MUSS 0 sein). Die Länge dieses AVP beträgt 6 plus die Länge der zufälligen Oktettfolge.
(Fortsetzung: Weitere AVP-Definitionen folgen...)