2.6. Next Header (Nächster Header)
Das Next Header ist ein obligatorisches 8-Bit-Feld, das den Typ der im Payload Data-Feld enthaltenen Daten identifiziert, z.B. ein IPv4- oder IPv6-Paket oder einen Header und Daten der nächsten Schicht. Der Wert dieses Feldes wird aus der Menge der auf der Webseite der IANA definierten IP-Protokollnummern gewählt, z.B. zeigt ein Wert von 4 IPv4 an, ein Wert von 41 zeigt IPv6 an und ein Wert von 6 zeigt TCP an.
Um die schnelle Generierung und Verwerfung des Padding-Verkehrs zur Unterstützung der Verkehrsfluss-Vertraulichkeit zu erleichtern (siehe Abschnitt 2.4), MUSS der Protokollwert 59 (der "kein nächster Header" bedeutet) verwendet werden, um ein "Dummy"-Paket zu bezeichnen. Ein Sender MUSS in der Lage sein, Dummy-Pakete zu erzeugen, die mit diesem Wert im nächsten Protokollfeld markiert sind, und ein Empfänger MUSS darauf vorbereitet sein, solche Pakete zu verwerfen, ohne einen Fehler anzuzeigen. Alle anderen ESP-Header- und Trailer-Felder (SPI, Sequence Number, Padding, Pad Length, Next Header und ICV) MÜSSEN in Dummy-Paketen vorhanden sein, aber der Klartextanteil der Nutzlast außer diesem Next Header-Feld muss nicht wohlgeformt sein, z.B. kann der Rest der Payload Data nur aus zufälligen Bytes bestehen. Dummy-Pakete werden ohne Vorurteil verworfen.
Implementierungen SOLLTEN lokale Verwaltungssteuerungen bereitstellen, um die Verwendung dieser Funktion auf SA-Basis zu ermöglichen. Die Steuerungen sollten es dem Benutzer ermöglichen anzugeben, ob diese Funktion verwendet werden soll, und auch parametrische Steuerungen bereitstellen; beispielsweise könnten die Steuerungen einem Administrator ermöglichen, Dummy-Pakete mit zufälliger Länge oder fester Länge zu erzeugen.
DISKUSSION: Dummy-Pakete können in zufälligen Intervallen eingefügt werden, um das Fehlen von tatsächlichem Verkehr zu maskieren. Man kann auch den tatsächlichen Verkehr "formen", um einer bestimmten Verteilung zu entsprechen, zu der Dummy-Verkehr hinzugefügt wird, wie durch die Verteilungsparameter vorgegeben. Wie bei der Paketlängen-Padding-Einrichtung für Traffic Flow Security (TFS) wäre der sicherste Ansatz, Dummy-Pakete mit der Rate zu erzeugen, die erforderlich ist, um eine konstante Rate auf einer SA aufrechtzuerhalten. Wenn alle Pakete die gleiche Größe haben, präsentiert die SA das Erscheinungsbild eines Datenstroms mit konstanter Bitrate, analog zu dem, was eine Link-Verschlüsselung auf Schicht 1 oder 2 bieten würde. Dies ist jedoch in vielen Kontexten unwahrscheinlich praktikabel, z.B. wenn mehrere SAs aktiv sind, da dies bedeuten würde, die zulässige Bandbreite für eine Site basierend auf der Anzahl der SAs zu reduzieren, was die Vorteile der Paketvermittlung untergraben würde. Implementierungen SOLLTEN Steuerungen bereitstellen, um lokalen Administratoren zu ermöglichen, die Generierung von Dummy-Paketen für TFC-Zwecke zu verwalten.