2.22. IPComp
2.22. IPComp
L'uso della compressione IP [IP-COMP] può essere negoziato come parte del setup di una Child SA. Sebbene la compressione IP implichi un header aggiuntivo in ogni pacchetto e un Compression Parameter Index (CPI), l'« associazione di compressione » virtuale non ha vita al di fuori della SA ESP o AH che la contiene. Le associazioni di compressione scompaiono quando la corrispondente SA ESP o AH scompare. Non è menzionata esplicitamente in alcun payload Delete.
La negoziazione della compressione IP è separata dalla negoziazione dei parametri crittografici associati a una Child SA. Un nodo che richiede una Child SA PUÒ pubblicizzare il suo supporto per uno o più algoritmi di compressione tramite uno o più payload Notify di tipo IPCOMP_SUPPORTED. Questo messaggio Notify può essere incluso solo in un messaggio contenente un payload SA che negozia una Child SA e indica la disponibilità del suo mittente a usare IPComp su questa SA. La risposta PUÒ indicare l'accettazione di un singolo algoritmo di compressione con un payload Notify di tipo IPCOMP_SUPPORTED. Questi payload NON DEVONO apparire in messaggi che non contengono payload SA.
I dati associati a questo messaggio Notify includono un CPI IPComp di due ottetti seguito da un ID di trasformazione di un ottetto opzionalmente seguito da attributi la cui lunghezza e formato sono definiti da quell'ID di trasformazione. Un messaggio che propone una SA può contenere multiple notifiche IPCOMP_SUPPORTED per indicare multipli algoritmi supportati. Un messaggio che accetta una SA può contenerne al massimo una.
Gli ID di trasformazione sono elencati qui. I valori nella tabella seguente sono attuali solo alla data di pubblicazione della RFC 4306. Altri valori possono essere stati aggiunti da allora o saranno aggiunti dopo la pubblicazione di questo documento. I lettori dovrebbero fare riferimento a [IKEV2IANA] per i valori più recenti.
Nome Numero Definito in
IPCOMP_OUI 1 IPCOMP_DEFLATE 2 RFC 2394 IPCOMP_LZS 3 RFC 2395 IPCOMP_LZJH 4 RFC 3051
Sebbene ci sia stata discussione sull'ammettere l'accettazione di multipli algoritmi di compressione e sull'avere diversi algoritmi di compressione disponibili per le due direzioni di una Child SA, le implementazioni di questa specifica NON DEVONO accettare un algoritmo IPComp che non è stato proposto, NON DEVONO accettarne più di uno, e NON DEVONO comprimere usando un algoritmo diverso da quello proposto e accettato nel setup della Child SA.
Un effetto collaterale della separazione della negoziazione di IPComp dai parametri crittografici è che non è possibile proporre multipli suite crittografici e proporre la compressione IP con alcuni di essi ma non con altri.
In alcuni casi, Robust Header Compression (ROHC) può essere più appropriata della compressione IP. [ROHCV2] definisce l'uso di ROHC con IKEv2 e IPsec.