2.22. IPComp
2.22. IPComp
Die Verwendung von IP-Kompression [IP-COMP] kann als Teil des Setups einer Child-SA ausgehandelt werden. Während IP-Kompression in jedem Paket einen zusätzlichen Header und einen Compression Parameter Index (CPI) umfasst, hat die virtuelle „Kompressionsassoziation" kein Eigenleben außerhalb der ESP- oder AH-SA, die sie enthält. Kompressionsassoziationen verschwinden, wenn die entsprechende ESP- oder AH-SA verschwindet. Sie werden in keinem Delete-Payload explizit erwähnt.
Die Aushandlung der IP-Kompression ist getrennt von der Aushandlung der kryptographischen Parameter, die mit einer Child-SA verbunden sind. Ein Knoten, der eine Child-SA anfordert, KANN seine Unterstützung für einen oder mehrere Kompressionsalgorithmen über einen oder mehrere Notify-Payloads des Typs IPCOMP_SUPPORTED bekanntgeben. Diese Notify-Nachricht darf nur in einer Nachricht enthalten sein, die einen SA-Payload enthält, der eine Child-SA aushandelt, und zeigt die Bereitschaft ihres Senders an, IPComp auf dieser SA zu verwenden. Die Antwort KANN die Annahme eines einzelnen Kompressionsalgorithmus mit einem Notify-Payload des Typs IPCOMP_SUPPORTED anzeigen. Diese Payloads DÜRFEN NICHT in Nachrichten auftreten, die keine SA-Payloads enthalten.
Die mit dieser Notify-Nachricht verbundenen Daten umfassen einen zwei Oktett großen IPComp-CPI, gefolgt von einer Transformations-ID von einem Oktett, optional gefolgt von Attributen, deren Länge und Format durch diese Transformations-ID definiert sind. Eine SA vorschlagende Nachricht kann mehrere IPCOMP_SUPPORTED-Benachrichtigungen enthalten, um mehrere unterstützte Algorithmen anzuzeigen. Eine SA annehmende Nachricht darf höchstens eine enthalten.
Die Transformations-IDs sind hier aufgelistet. Die Werte in der folgenden Tabelle sind nur zum Zeitpunkt der Veröffentlichung von RFC 4306 aktuell. Andere Werte wurden möglicherweise seitdem hinzugefügt oder werden nach der Veröffentlichung dieses Dokuments hinzugefügt. Leser sollten für die neuesten Werte auf [IKEV2IANA] verweisen.
Name Nummer Definiert in
IPCOMP_OUI 1 IPCOMP_DEFLATE 2 RFC 2394 IPCOMP_LZS 3 RFC 2395 IPCOMP_LZJH 4 RFC 3051
Obwohl es Diskussionen darüber gab, mehrere Kompressionsalgorithmen zu akzeptieren und für die beiden Richtungen einer Child-SA unterschiedliche Kompressionsalgorithmen verfügbar zu haben, MÜSSEN Implementierungen dieser Spezifikation keinen IPComp-Algorithmus akzeptieren, der nicht vorgeschlagen wurde, DÜRFEN nicht mehr als einen akzeptieren, und DÜRFEN nicht mit einem anderen als dem bei der Einrichtung der Child-SA vorgeschlagenen und akzeptierten Algorithmus komprimieren.
Ein Nebeneffekt der Trennung der Aushandlung von IPComp von den kryptographischen Parametern ist, dass es nicht möglich ist, mehrere kryptographische Suits vorzuschlagen und IP-Kompression mit einigen von ihnen, aber nicht mit anderen vorzuschlagen.
In einigen Fällen kann Robust Header Compression (ROHC) angemessener sein als IP-Kompression. [ROHCV2] definiert die Verwendung von ROHC mit IKEv2 und IPsec.