IPsec Extensions to Support Robust Header Compression over IPsec
Extracted elements (25)
ROHC segmentation is not recommended for ROHCoIPsec because in-order delivery of ROHC segments cannot be guaranteed over IPsec, making reassembly unreliable. The MRRU SHOULD therefore be set to 0 to disable segmentation entirely.
The MRRU parameter SHOULD be set to 0 (disabling ROHC segmentation) because in-order delivery of ROHC packets cannot be guaranteed over IPsec, and allowing segment headers on the channel would risk unrecoverable reassembly failures.
The ROHC channel parameters LARGE_CIDS and FEEDBACK_FOR are omitted from the SPD because they are set implicitly: LARGE_CIDS derives directly from MAX_CID, and FEEDBACK_FOR is always the reverse-direction SA. Including them explicitly would be redundant.
Use of the 'ROHC' protocol identifier (142) outside the context of the Next Header field of IPsec security protocol headers is not currently defined. Future uses would require specification of the logical compression channel and investigation of associated security considerations.
For channels where MRRU is non-zero, the ROHCoIPsec decompressor MUST reassemble ROHC segments. The AH/ESP sequence number SHOULD be used to identify reordered segments. If reconstruction fails, the packet MUST be discarded.
For inbound SAs, the ROHC Data Item MUST specify decompressor channel parameters; for outbound SAs it MUST specify compressor channel parameters. The ROHC Data Item for both directions MUST include the integrity algorithm, its key, and ICV length.
If an outbound packet has a compressed header, the Next Header field of the AH or ESP security protocol header MUST be set to the 'ROHC' protocol identifier. For inbound packets, the Next Header field MUST be checked to determine whether ROHC decompression is required.
If ROHC segmentation is used (MRRU non-zero), it MUST occur before AH or ESP processing. The segmentation process MUST account for IPsec overhead so that final IPsec-processed segments remain within the tunnel MTU.
Outbound processing order: (1) compute ROHC ICV over uncompressed packet, (2) compress headers, (3) append ICV to compressed packet, (4) apply AH/ESP. Inbound order: (1) apply AH/ESP, (2) remove ICV, (3) decompress headers, (4) recompute ICV, (5) compare and drop if mismatch.
Pre-encryption IP fragmentation MUST NOT occur before ROHC processing because current ROHC compression profiles do not support compression of IP packet fragments.
'ROHC Data Item' values in the SAD MAY be initialized manually (for manual SAs) or via a key exchange protocol such as IKEv2 extended to support ROHC parameter signaling per RFC 5857.
The LARGE_CIDS channel parameter MUST be set based on MAX_CID (if MAX_CID <= 15, LARGE_CIDS is 0). The FEEDBACK_FOR parameter MUST be set to the ROHC channel on the reverse SA; if no reverse SA exists, ROHC MUST NOT operate in bi-directional mode.
The ROHC ICV MUST be computed over the uncompressed IP header, higher-layer headers, and packet payload (excluding the authentication data). If the recomputed ICV at the decompressor does not match the appended ICV, the decompressed packet MUST be dropped.
The SPD and SAD MUST be extended to include ROHC-relevant parameters to support ROHCoIPsec. These extensions do not affect existing SPD fields or SAD parameters, preserving backwards compatibility with non-ROHC IPsec implementations.
The SPD must include a ROHC INTEGRITY ALGORITHM field (list of integrity algorithms for header integrity verification) and a ROHC ICV LENGTH field. Authentication algorithms that MUST be supported are those specified in the 'Authentication Algorithms' table of RFC 4835.
When IPComp and ROHCoIPsec are nested, outbound processing order is: (1) compute ROHC ICV and compress headers, (2) apply IPComp, (3) apply IPsec security protocol. Inbound order reverses this: IPsec processing, then IPComp decompression, then ROHC decompression and integrity verification.
When IPsec implementations cannot process unprotected ICMP messages or lack a path MTU estimate, the implementation SHOULD NOT attempt to segment the ROHC-compressed packet, as it lacks full insight into the unprotected-domain path MTU.
When ROHC segmentation is applied, the AH/ESP sequence number MUST be incremented by one for each segment transmitted over the ROHC channel, enabling the remote IPsec implementation to identify segments by a contiguous range of sequence numbers.
A 'ROHC' protocol identifier (IP protocol number 142) is used in the Next Header field of AH or ESP headers to identify header-compressed traffic on a ROHC-enabled SA.
Each SAD entry for a ROHC-enabled SA must contain a 'ROHC Data Item' storing the ROHC channel parameters (MAX_CID, PROFILES, MRRU), plus the integrity algorithm, its key, and the ICV length used by the ROHC process. Inbound SAs must also include a FEEDBACK_FOR parameter referencing the outbound SA.
The SPD PROTECT processing info is extended with ROHC channel parameters: MAX_CID (highest context ID, 0–16383), MRRU (largest reconstructed unit size in octets including CRC and ICV), and PROFILES (list of supported ROHC profiles from the ROHCPROF registry).
IANA allocated protocol number 142 to 'ROHC' in the 'Protocol Numbers' registry. This value is used in the Next Header field of AH/ESP headers to indicate that the next-level protocol header is a ROHC-compressed header.
Implementers should use a strong integrity check algorithm for verifying decompressed headers. A weak algorithm increases the probability that an invalidly decompressed packet will be forwarded into the protected domain undetected.
ROHCoIPsec may increase susceptibility to traffic flow analysis: an attacker monitoring encrypted packet sizes may detect new flows from patterns such as a burst of long packets followed by many short packets. ROHC padding can randomize packet sizes to mitigate this, at the cost of compression efficiency.
A ROHCoIPsec-processed IPv4/TCP tunnel-mode ESP packet has the structure: new IP header | ESP header | compressed header | data | ROHC ICV | ESP Trailer | ESP ICV. The ROHC ICV field is appended after the compressed payload and is not included in its own ICV calculation.