2.22. IPComp
2.22. IPComp
Die Nutzung von IP-Kompression [IP-COMP] kann beim Aufbau einer Child SA ausgehandelt werden. IP-Kompression fügt pro Paket einen zusätzlichen Header und einen Compression Parameter Index (CPI) hinzu; die virtuelle „Kompressionsassoziation“ existiert nur innerhalb der sie enthaltenden ESP- oder AH-SA und verschwindet mit dieser, ohne explizite Erwähnung in Delete-Nutzlasten.
Die IPComp-Aushandlung ist getrennt von kryptografischen Parametern. Ein Kind-SA-anfordernder Knoten KANN einen oder mehrere unterstützte Kompressionsalgorithmen über Notify IPCOMP_SUPPORTED ankündigen, nur in Nachrichten mit SA-Nutzlast zur Child-SA-Aushandlung. Die Antwort KANN mit einer IPCOMP_SUPPORTED einen Algorithmus akzeptieren. Diese Nutzlasten DÜRFEN nicht ohne SA vorkommen.
Die zugehörigen Daten: zwei Oktette IPComp-CPI, ein Oktett Transform-ID, optional Attribute. Mehrere IPCOMP_SUPPORTED in Vorschlägen möglich; in der Annahme höchstens eine.
Transform-IDs (Stand RFC 4306; aktuell [IKEV2IANA]):
| Name | Number | Defined In |
|---|---|---|
| IPCOMP_OUI | 1 | (UNSPECIFIED) |
| IPCOMP_DEFLATE | 2 | RFC 2394 |
| IPCOMP_LZS | 3 | RFC 2395 |
| IPCOMP_LZJH | 4 | RFC 3051 |
Implementierungen dieser Spezifikation DÜRFEN keinen nicht vorgeschlagenen IPComp-Algorithmus akzeptieren, nicht mehr als einen und nicht mit anderem Algorithmus komprimieren als vorgeschlagen und akzeptiert.
Nebenwirkung: Mehrere kryptografische Suites mit selektivem IPComp sind nicht möglich.
In manchen Fällen ist ROHC geeigneter. [ROHCV2] definiert ROHC mit IKEv2 und IPsec.