2.6. Next Header (Header successivo)

Il Next Header è un campo obbligatorio a 8 bit che identifica il tipo di dati contenuti nel campo Payload Data, ad esempio un pacchetto IPv4 o IPv6, o un header e dati del livello successivo. Il valore di questo campo è scelto dall'insieme dei numeri di protocollo IP definiti sulla pagina web dell'IANA, ad esempio un valore di 4 indica IPv4, un valore di 41 indica IPv6 e un valore di 6 indica TCP.

Per facilitare la rapida generazione e lo scarto del traffico di padding a supporto della riservatezza del flusso di traffico (vedere sezione 2.4), il valore di protocollo 59 (che significa "nessun header successivo") DEVE essere utilizzato per designare un pacchetto "fittizio". Un trasmettitore DEVE essere in grado di generare pacchetti fittizi contrassegnati con questo valore nel campo del protocollo successivo, e un ricevitore DEVE essere preparato a scartare tali pacchetti, senza indicare un errore. Tutti gli altri campi di header e trailer ESP (SPI, Sequence Number, Padding, Pad Length, Next Header e ICV) DEVONO essere presenti nei pacchetti fittizi, ma la porzione in chiaro del payload, diversa da questo campo Next Header, non deve essere ben formata, ad esempio il resto dei Payload Data può consistere solo di byte casuali. I pacchetti fittizi vengono scartati senza pregiudizio.

Le implementazioni DOVREBBERO fornire controlli di gestione locali per abilitare l'uso di questa capacità su base per SA. I controlli dovrebbero consentire all'utente di specificare se questa funzionalità deve essere utilizzata e fornire anche controlli parametrici; ad esempio, i controlli potrebbero consentire a un amministratore di generare pacchetti fittizi di lunghezza casuale o di lunghezza fissa.

DISCUSSIONE: I pacchetti fittizi possono essere inseriti a intervalli casuali per mascherare l'assenza di traffico effettivo. Si può anche "modellare" il traffico effettivo per corrispondere a una certa distribuzione alla quale viene aggiunto traffico fittizio come dettato dai parametri di distribuzione. Come con la funzionalità di padding della lunghezza dei pacchetti per Traffic Flow Security (TFS), l'approccio più sicuro sarebbe generare pacchetti fittizi al tasso necessario per mantenere un tasso costante su una SA. Se i pacchetti sono tutti della stessa dimensione, allora la SA presenta l'aspetto di un flusso di dati a velocità di bit costante, analogo a ciò che una crittografia di collegamento offrirebbe al livello 1 o 2. Tuttavia, questo è improbabile che sia pratico in molti contesti, ad esempio quando ci sono più SA attive, perché implicherebbe ridurre la larghezza di banda consentita per un sito, in base al numero di SA, e ciò minerebbe i benefici della commutazione di pacchetti. Le implementazioni DOVREBBERO fornire controlli per consentire agli amministratori locali di gestire la generazione di pacchetti fittizi per scopi TFC.