8. Backward-Compatibility Considerations (Considerazioni sulla retrocompatibilità)
8. Backward-Compatibility Considerations (Considerazioni sulla retrocompatibilità)
Non esiste un numero di versione in ESP e nessun meccanismo che consenta ai peer IPsec di scoprire o negoziare quale versione di ESP ciascuno sta utilizzando o dovrebbe utilizzare. Questa sezione discute le conseguenti questioni di retrocompatibilità.
Innanzitutto, se nessuna delle nuove funzionalità disponibili in ESP v3 viene impiegata, allora il formato di un pacchetto ESP è identico in ESP v2 e v3. Se viene impiegato un algoritmo di crittografia in modalità combinata, una funzionalità supportata solo in ESP v3, allora il formato del pacchetto risultante può differire dalla specifica ESP v2. Tuttavia, un peer che implementa solo ESP v2 non negozierebbe mai tale algoritmo, poiché sono definiti per l'uso solo nel contesto ESP v3.
La negoziazione del numero di sequenza esteso (ESN) è supportata da IKE v2 ed è stata affrontata per IKE v1 dall'addendum ESN al dominio di interpretazione (DOI) di IKE v1.
Nel nuovo ESP (v3), facciamo due disposizioni per supportare meglio la confidenzialità del flusso di traffico (TFC):
- padding arbitrario dopo la fine di un pacchetto IP
- una convenzione di scarto utilizzando Next Header = 59
La prima funzionalità non dovrebbe causare problemi per un ricevitore, poiché il campo di lunghezza totale IP indica dove termina il pacchetto IP. Pertanto, tutti i byte di padding TFC dopo la fine del pacchetto dovrebbero essere rimossi in qualche punto durante l'elaborazione del pacchetto IP, dopo l'elaborazione ESP, anche se il software IPsec non rimuove tale padding. Quindi, questa è una funzionalità ESP v3 che un mittente può utilizzare indipendentemente dal fatto che un ricevitore implementi ESP v2 o ESP v3.
La seconda funzionalità consente a un mittente di inviare un payload che è una stringa arbitraria di byte che non costituisce necessariamente un pacchetto IP ben formato, all'interno di un tunnel, per scopi TFC. È una questione aperta cosa farà un ricevitore ESP v2 quando il campo Next Header in un pacchetto ESP contiene il valore "59". Potrebbe scartare il pacchetto quando trova un header IP malformato, e registrare questo evento, ma certamente non dovrebbe bloccarsi, perché tale comportamento costituirebbe una vulnerabilità DoS rispetto al traffico ricevuto da peer autenticati. Pertanto questa funzionalità è un'ottimizzazione che un mittente ESP v3 può utilizzare indipendentemente dal fatto che un ricevitore implementi ESP v2 o ESP v3.