2.22. IPComp
2.22. IPComp
L'utilisation de la compression IP [IP-COMP] peut être négociée dans le cadre de la configuration d'une Child SA. Bien que la compression IP implique un en-tête supplémentaire dans chaque paquet et un indice de paramètre de compression (CPI), l'« association de compression » virtuelle n'a pas d'existence en dehors de la SA ESP ou AH qui la contient. Les associations de compression disparaissent lorsque la SA ESP ou AH correspondante disparaît. Elle n'est mentionnée explicitement dans aucun payload Delete.
La négociation de la compression IP est séparée de la négociation des paramètres cryptographiques associés à une Child SA. Un nœud demandant une Child SA PEUT annoncer son support pour un ou plusieurs algorithmes de compression à travers un ou plusieurs payloads Notify de type IPCOMP_SUPPORTED. Ce message Notify ne peut être inclus que dans un message contenant un payload SA négociant une Child SA et indique la volonté de son émetteur d'utiliser IPComp sur cette SA. La réponse PEUT indiquer l'acceptation d'un seul algorithme de compression avec un payload Notify de type IPCOMP_SUPPORTED. Ces payloads NE DOIVENT PAS apparaître dans des messages qui ne contiennent pas de payloads SA.
Les données associées à ce message Notify incluent un CPI IPComp de deux octets suivi d'un ID de transformation d'un octet suivi optionnellement d'attributs dont la longueur et le format sont définis par cet ID de transformation. Un message proposant une SA peut contenir plusieurs notifications IPCOMP_SUPPORTED pour indiquer plusieurs algorithmes supportés. Un message acceptant une SA ne peut en contenir qu'une seule.
Les ID de transformation sont listés ici. Les valeurs dans le tableau suivant ne sont actuelles qu'à la date de publication de la RFC 4306. D'autres valeurs peuvent avoir été ajoutées depuis ou seront ajoutées après la publication de ce document. Les lecteurs devraient se référer à [IKEV2IANA] pour les dernières valeurs.
Nom Numéro Défini dans
IPCOMP_OUI 1 IPCOMP_DEFLATE 2 RFC 2394 IPCOMP_LZS 3 RFC 2395 IPCOMP_LZJH 4 RFC 3051
Bien qu'il y ait eu discussion pour permettre l'acceptation de multiples algorithmes de compression et d'avoir différents algorithmes de compression disponibles pour les deux directions d'une Child SA, les implémentations de cette spécification NE DOIVENT PAS accepter un algorithme IPComp qui n'a pas été proposé, NE DOIVENT PAS en accepter plus d'un, et NE DOIVENT PAS compresser en utilisant un algorithme autre que celui proposé et accepté dans la configuration de la Child SA.
Un effet de bord de la séparation de la négociation d'IPComp des paramètres cryptographiques est qu'il n'est pas possible de proposer plusieurs suites cryptographiques et de proposer la compression IP avec certaines d'entre elles mais pas d'autres.
Dans certains cas, la compression de tête robuste (ROHC) peut être plus appropriée que la compression IP. [ROHCV2] définit l'utilisation de ROHC avec IKEv2 et IPsec.