IKEv2 Extensions to Support Robust Header Compression over IPsec
Extracted elements (25)
LARGE_CIDS and FEEDBACK_FOR are implicitly derived rather than explicitly signaled to reduce negotiation overhead: LARGE_CIDS is fully determined by the MAX_CID value, and FEEDBACK_FOR always refers to the reverse SA of a bidirectional SA pair.
The restriction against signaling two versions of the same ROHC profile exists because ROHC-compressed packets only carry the 8 least-significant bits of the profile identifier; the 8 LSBs of corresponding ROHCv1 and ROHCv2 profiles are identical, so the decompressor cannot determine which version was used.
MAX_CID, ROHC_PROFILE, ROHC_ICV_LEN, and MRRU are one-way notifications; each endpoint independently announces what it can handle, so different values may be in use for each traffic direction on an SA pair.
A ROHCoIPsec initiator MAY signal ROHC_INTEG value zero (0x0000, 'NONE'), and the responder MAY select it; in that scenario, no integrity algorithm is applied in either direction.
Exactly one MAX_CID attribute MUST be sent in the ROHC_SUPPORTED Notify message. The recipient of the MAX_CID attribute MUST only use context identifiers up to MAX_CID for compression.
If an unknown ROHC Attribute Type Value is received, it MUST be silently ignored.
If multiple Notify payloads containing ROHC parameters are received, all but the first MUST be dropped. If the initiator does not receive a Notify payload with the responder's ROHC channel parameters, ROHC MUST NOT be enabled on the Child SA.
In the ROHC_SUPPORTED Notify payload, the Critical bit MUST be set to zero, Protocol ID MUST be set to zero, SPI Size MUST be set to zero, and the Notify Message Type MUST be set to ROHC_SUPPORTED.
Keys for the ROHC integrity algorithm (one per direction) are derived from the IKEv2 KEYMAT, treating ROHC as an IPsec protocol. When a ROHC-enabled CHILD_SA is rekeyed, the integrity algorithm key MUST also be rekeyed.
LARGE_CIDS and FEEDBACK_FOR ROHC channel parameters MUST NOT be signaled via IKEv2; they are set implicitly. LARGE_CIDS is determined by MAX_CID (0 if MAX_CID <= 15), and FEEDBACK_FOR MUST be set to the paired SA in the reverse direction.
ROHC channel parameters MUST be signaled separately for each ROHC-enabled IPsec SA. A new ROHC_SUPPORTED Notify message MUST be included in the IKE_AUTH and CREATE_CHILD_SA exchanges whenever a new ROHC-enabled SA is created or rekeyed.
The Notification Data field of the ROHC_SUPPORTED Notify payload MUST contain at least three ROHC Attributes: MAX_CID, ROHC_PROFILE, and ROHC_INTEG.
The recipient of ROHC_ICV_LEN MUST truncate the ICV to the announced length. If no ROHC_ICV_LEN attribute is sent, or if the value exceeds the full ICV length of the selected algorithm, the full ICV MUST be sent.
The responder MUST select exactly one ROHC_INTEG algorithm from the initiator's proposals and send it back. If the responder does not accept any proposed algorithm, ROHC MUST NOT be enabled on the SA. The selected integrity algorithm MUST be used in both directions.
Two versions of the same ROHC profile MUST NOT be signaled simultaneously (e.g., ROHCv1 UDP 0x0002 and ROHCv2 UDP 0x0102), because compressed packets only express the 8 least-significant bits of the profile identifier, making the version indistinguishable at the decompressor.
MAX_CID (AF=1) is a mandatory 2-octet attribute indicating the maximum context identifier value supported by the decompressor. Its value MUST be between 0 and 16383, and the compressor MUST only use context identifiers up to MAX_CID.
MRRU (Maximum Reconstructed Reception Unit, AF=1) is an optional 2-octet attribute specifying the largest unit (in octets) the decompressor can reassemble from ROHC segments, including CRC and ROHC ICV. If MRRU is 0 or absent, segment headers MUST NOT be transmitted.
ROHC_ICV_LEN (AF=1) is an optional attribute specifying the number of ICV octets the sender expects on incoming ROHC packets. The negotiated ROHC_INTEG ICV MUST be truncated to this length by taking its first ROHC_ICV_LEN bytes; if zero, no ICV is sent.
ROHC_INTEG (AF=1) is a mandatory attribute carrying a 2-octet integrity algorithm identifier (from the IKEv2 'Transform Type 3' registry) used to verify decompressed packet header integrity. The responder MUST select exactly one proposed algorithm, which applies in both directions.
ROHC_PROFILE (AF=1) is a mandatory 4-octet attribute (2-octet Profile Identifier value) identifying a ROHC profile to use. There MUST be at least one in the Notify message; the recipient MUST only compress using the proposed profile(s).
IANA allocated one value from the 'IKEv2 Notify Message Types' registry for ROHC_SUPPORTED, identifying Notify payloads that carry ROHC channel parameters.
IANA created a new 'ROHC Attribute Types' registry under 'IKEv2 Parameters', with values: 0 (RESERVED), 1 (MAX_CID, TV), 2 (ROHC_PROFILE, TV), 3 (ROHC_INTEG, TV), 4 (ROHC_ICV_LEN, TV), 5 (MRRU, TV), 6–16383 (Unassigned), 16384–32767 (Private use). New assignments require Expert Review.
Negotiating a short ROHC ICV length via ROHC_ICV_LEN may introduce vulnerabilities: a short ICV can allow erroneous (or malicious) packets to pass header integrity checks and be forwarded into the protected domain. This is a trade-off against the bandwidth overhead of longer ICVs.
A ROHC Attribute is encoded with a 1-bit Attribute Format (AF) flag, 15-bit Attribute Type, and either a 2-octet Length followed by variable Value (AF=0, TLV format) or a 2-octet Value directly (AF=1, TV format).
The ROHC_SUPPORTED Notify payload reuses the IKEv2 Notify payload format (RFC 4306): 1-octet Next Payload, 1-bit Critical flag, 1-octet Protocol ID, 1-octet SPI Size, 2-octet Notify Message Type, variable SPI and Notification Data fields.