3.3.3. Integrity Check Value Calculation (Integritätsprüfwertberechnung)

Der AH-ICV wird berechnet über:

• IP- oder Erweiterungsheader-Felder vor dem AH-Header, die entweder während der Übertragung unveränderlich sind oder deren Wert bei Ankunft am Endpunkt der AH-SA vorhersagbar ist
• den AH-Header (Next Header, Payload Len, Reserved, SPI, Sequence Number (niederwertige 32 Bits) und den ICV (der für diese Berechnung auf Null gesetzt wird) sowie explizite Padding-Bytes (falls vorhanden))
• alles nach AH wird als während der Übertragung unveränderlich angenommen
• die höherwertigen Bits der ESN (falls verwendet) und jedes implizite Padding, das vom Integritätsalgorithmus erforderlich ist

3.3.3.1. Behandlung veränderlicher Felder

Wenn ein Feld während der Übertragung modifiziert werden kann, wird der Wert des Feldes für Zwecke der ICV-Berechnung auf Null gesetzt. Wenn ein Feld veränderlich ist, aber sein Wert beim (IPsec-)Empfänger vorhersagbar ist, dann wird dieser Wert in das Feld für Zwecke der ICV-Berechnung eingefügt. Das Integrity Check Value-Feld wird ebenfalls auf Null gesetzt in Vorbereitung auf diese Berechnung. Beachten Sie, dass durch Ersetzen des Wertes jedes Feldes durch Null, anstatt das Feld wegzulassen, die Ausrichtung für die ICV-Berechnung erhalten bleibt. Außerdem stellt der Null-Füllungsansatz sicher, dass die Länge der Felder, die so behandelt werden, während der Übertragung nicht geändert werden kann, obwohl ihr Inhalt nicht explizit vom ICV abgedeckt wird.

Wenn ein neuer Erweiterungsheader oder eine IPv4-Option erstellt wird, wird sie in ihrem eigenen RFC definiert und SOLLTE (im Abschnitt Security Considerations) Anweisungen enthalten, wie sie bei der Berechnung des AH-ICV behandelt werden sollte. Wenn die IP-(v4 oder v6-)Implementierung auf einen Erweiterungsheader trifft, den sie nicht erkennt, wird sie das Paket verwerfen und eine ICMP-Nachricht senden. IPsec wird das Paket nie sehen. Wenn die IPsec-Implementierung auf eine IPv4-Option trifft, die sie nicht erkennt, sollte sie die gesamte Option auf Null setzen, wobei sie das zweite Byte der Option als Länge verwendet. IPv6-Optionen (in Destination Extension Headers oder im Hop-by-Hop Extension Header) enthalten ein Flag, das Veränderlichkeit anzeigt, das die angemessene Verarbeitung für solche Optionen bestimmt.

3.3.3.1.1. ICV-Berechnung für IPv4

3.3.3.1.1.1. Basis-Header-Felder

Die IPv4-Basis-Header-Felder werden wie folgt klassifiziert:

Immutable (Unveränderlich):

• Version
• Internet Header Length
• Total Length
• Identification
• Protocol (Dies sollte der Wert für AH sein.)
• Source Address
• Destination Address (ohne Loose oder Strict Source Routing)

Mutable but predictable (Veränderlich aber vorhersagbar):

• Destination Address (mit Loose oder Strict Source Routing)

Mutable (Veränderlich, vor ICV-Berechnung auf Null gesetzt):

• Differentiated Services Code Point (DSCP) (6 Bits, siehe RFC 2474 [NBBB98])
• Explicit Congestion Notification (ECN) (2 Bits, siehe RFC 3168 [RFB01])
• Flags
• Fragment Offset
• Time to Live (TTL)
• Header Checksum

DSCP - Router können das DS-Feld nach Bedarf umschreiben, um einen gewünschten lokalen oder End-to-End-Dienst bereitzustellen, daher kann sein Wert beim Empfang nicht vom Sender vorhergesagt werden.

ECN - Dies wird sich ändern, wenn ein Router entlang der Route Überlastung erfährt, und daher kann sein Wert beim Empfang nicht vom Sender vorhergesagt werden.

Flags - Dieses Feld ist ausgeschlossen, weil ein Zwischenrouter das DF-Bit setzen könnte, auch wenn die Quelle es nicht ausgewählt hat.

Fragment Offset - Da AH nur auf nicht-fragmentierte IP-Pakete angewendet wird, muss das Offset-Feld immer Null sein, und daher ist es ausgeschlossen (obwohl es vorhersagbar ist).

TTL - Dies wird unterwegs als normaler Verarbeitungsverlauf durch Router geändert, und daher ist sein Wert beim Empfänger nicht vom Sender vorhersagbar.

Header Checksum - Dies wird sich ändern, wenn sich eines dieser anderen Felder ändert, und daher kann sein Wert beim Empfang nicht vom Sender vorhergesagt werden.

3.3.3.1.1.2. Optionen

Für IPv4 (im Gegensatz zu IPv6) gibt es keinen Mechanismus zum Markieren von Optionen als während der Übertragung veränderlich. Daher sind die IPv4-Optionen in Anhang A explizit aufgelistet und als unveränderlich, veränderlich aber vorhersagbar oder veränderlich klassifiziert. Für IPv4 wird die gesamte Option als Einheit betrachtet; selbst wenn die Typ- und Längenfelder innerhalb der meisten Optionen während der Übertragung unveränderlich sind, wird, wenn eine Option als veränderlich klassifiziert ist, die gesamte Option für ICV-Berechnungszwecke auf Null gesetzt.

3.3.3.1.2. ICV-Berechnung für IPv6

3.3.3.1.2.1. Basis-Header-Felder

Die IPv6-Basis-Header-Felder werden wie folgt klassifiziert:

Immutable (Unveränderlich):

• Version
• Payload Length
• Next Header
• Source Address
• Destination Address (ohne Routing Extension Header)

Mutable but predictable (Veränderlich aber vorhersagbar):

• Destination Address (mit Routing Extension Header)

Mutable (Veränderlich, vor ICV-Berechnung auf Null gesetzt):

• DSCP (6 Bits, siehe RFC2474 [NBBB98])
• ECN (2 Bits, siehe RFC3168 [RFB01])
• Flow Label (*)
• Hop Limit

(*) Das in AHv1 beschriebene Flow Label war veränderlich, und in RFC 2460 [DH98] war es potenziell veränderlich. Um die Kompatibilität mit bestehenden AH-Implementierungen zu erhalten, ist das Flow Label in AHv2 nicht im ICV enthalten.

3.3.3.1.2.2. Erweiterungsheader mit Optionen

IPv6-Optionen in den Hop-by-Hop- und Destination Extension Headers enthalten ein Bit, das anzeigt, ob sich die Option während der Übertragung (unvorhersehbar) ändern könnte. Für jede Option, deren Inhalt sich unterwegs ändern kann, muss das gesamte "Option Data"-Feld als auf Null gesetzte Oktette behandelt werden, wenn der ICV berechnet oder überprüft wird. Der Option Type und Opt Data Len sind in die ICV-Berechnung einbezogen. Alle Optionen, für die das Bit Unveränderlichkeit anzeigt, sind in die ICV-Berechnung einbezogen. Siehe die IPv6-Spezifikation [DH98] für weitere Informationen.

3.3.3.1.2.3. Erweiterungsheader ohne Optionen

Die IPv6-Erweiterungsheader, die keine Optionen enthalten, sind in Anhang A explizit aufgelistet und als unveränderlich, veränderlich aber vorhersagbar oder veränderlich klassifiziert.

3.3.3.2. Padding und erweiterte Sequenznummern

3.3.3.2.1. ICV-Padding

Wie in Abschnitt 2.6 erwähnt, kann das ICV-Feld explizites Padding enthalten, falls erforderlich, um sicherzustellen, dass der AH-Header ein Vielfaches von 32 Bits (IPv4) oder 64 Bits (IPv6) ist. Wenn Padding erforderlich ist, wird seine Länge durch zwei Faktoren bestimmt:

• die Länge des ICV
• die IP-Protokollversion (v4 oder v6)

Wenn beispielsweise die Ausgabe des ausgewählten Algorithmus 96 Bits beträgt, ist kein Padding für IPv4 oder IPv6 erforderlich. Wenn jedoch ein ICV unterschiedlicher Länge generiert wird, aufgrund der Verwendung eines anderen Algorithmus, kann Padding erforderlich sein, abhängig von der Länge und der IP-Protokollversion. Der Inhalt des Padding-Feldes wird vom Sender willkürlich ausgewählt. (Das Padding ist willkürlich, muss aber nicht zufällig sein, um Sicherheit zu erreichen.) Diese Padding-Bytes sind in die ICV-Berechnung einbezogen, werden als Teil der Payload Length gezählt und am Ende des ICV-Feldes übertragen, um dem Empfänger zu ermöglichen, die ICV-Berechnung durchzuführen. Die Einbeziehung von Padding über die Mindestmenge hinaus, die erforderlich ist, um IPv4/IPv6-Ausrichtungsanforderungen zu erfüllen, ist verboten.

3.3.3.2.2. Implizites Paket-Padding und ESN

Wenn die ESN-Option für eine SA gewählt wird, dann müssen die höherwertigen 32 Bits der ESN in die ICV-Berechnung einbezogen werden. Für Zwecke der ICV-Berechnung werden diese Bits (implizit) unmittelbar nach dem Ende der Nutzlast und vor jedem impliziten Paket-Padding angehängt.

Für einige Integritätsalgorithmen muss die Byte-Zeichenfolge, über die die ICV-Berechnung durchgeführt wird, ein Vielfaches einer vom Algorithmus spezifizierten Blockgröße sein. Wenn die IP-Paketlänge (einschließlich AH und der 32 höherwertigen Bits der ESN, falls aktiviert) nicht den Blockgrößenanforderungen für den Algorithmus entspricht, MUSS implizites Padding am Ende des Pakets vor der ICV-Berechnung angehängt werden. Die Padding-Oktette MÜSSEN einen Wert von Null haben. Die Blockgröße (und damit die Länge des Paddings) wird von der Algorithmusspezifikation angegeben. Dieses Padding wird nicht mit dem Paket übertragen. Das Dokument, das einen Integritätsalgorithmus definiert, MUSS konsultiert werden, um zu bestimmen, ob implizites Padding wie oben beschrieben erforderlich ist. Wenn das Dokument keine Antwort darauf spezifiziert, dann ist die Standardannahme, dass implizites Padding erforderlich ist (wie benötigt, um die Paketlänge an die Blockgröße des Algorithmus anzupassen). Wenn Padding-Bytes benötigt werden, der Algorithmus aber den Padding-Inhalt nicht spezifiziert, dann MÜSSEN die Padding-Oktette einen Wert von Null haben.