2.22. IPComp
2.22. IPComp
L'utilisation de la compression IP [IP-COMP] peut être négociée lors de la création d'une Child SA. La compression IP ajoute un en-tête et un CPI par paquet, mais l'« association de compression » virtuelle n'existe qu'à l'intérieur de la SA ESP ou AH qui la contient. Elle disparaît avec cette SA et n'est pas mentionnée dans un Delete.
La négociation IPComp est distincte de celle des paramètres cryptographiques. Un nœud demandant une Child SA PEUT annoncer une ou plusieurs algorithmes via une ou plusieurs Notify IPCOMP_SUPPORTED, uniquement dans un message contenant une SA négociant une Child SA, indiquant la volonté d'utiliser IPComp sur cette SA. La réponse PEUT accepter un algorithme avec une Notify IPCOMP_SUPPORTED. Ces charges NE DOIVENT PAS apparaître sans charge SA.
Les données associées comprennent un CPI IPComp sur deux octets, un Transform ID sur un octet, puis des attributs optionnels. Une proposition peut contenir plusieurs IPCOMP_SUPPORTED; une acceptation au plus une.
Les Transform ID sont listés ci-dessous. Les valeurs ne sont à jour qu'à la date de RFC 4306; consulter [IKEV2IANA] pour les valeurs actuelles.
| Name | Number | Defined In |
|---|---|---|
| IPCOMP_OUI | 1 | (UNSPECIFIED) |
| IPCOMP_DEFLATE | 2 | RFC 2394 |
| IPCOMP_LZS | 3 | RFC 2395 |
| IPCOMP_LZJH | 4 | RFC 3051 |
Malgré les discussions sur plusieurs algorithmes ou des algorithmes différents par direction, les implémentations de cette spécification NE DOIVENT PAS accepter un algorithme IPComp non proposé, NE DOIVENT PAS en accepter plus d'un, et NE DOIVENT PAS compresser avec autre chose que l'algorithme proposé et accepté.
Effet secondaire: on ne peut pas proposer plusieurs suites cryptographiques avec IPComp seulement pour certaines.
Dans certains cas ROHC peut convenir mieux. [ROHCV2] définit ROHC avec IKEv2 et IPsec.