Review of the RoHC over IPsec drafts

Yoav Nir writes:
> The IKE & IPsec drafts talk about the use of integrity algorithms to  
> verify that decompression was successful. According to section 2.1 of  
> the IKEv2 draft, these algorithms are the same algorithms (with  
> associated keys) as those used in IPsec. I can't figure out why you  
> would want this. The entire packet, compressed header and data  
> included, is already integrity protected by IPsec. An attacker can't  
> flip any bits because of the ESP ICV, so the RoHC ICV is simply there  
> to detect decompression errors. I don't see why we need to exceed the  
> recommendation in RFC 4995 to use CRC. Even if you have decided that  
> you want to upgrade error-detection ICV to a cryptographically strong  
> one, HMAC doesn't offer any benefit that I can see - you could use  
> straight MD5 or SHA-1 without any key, but I still don't see why CRC  
> is not good enough.

Attacker cannot flip bits, but it can remove entire packets. As the
rohc is statefull compression, removing packets will affect the state
of the decompressor, thus by removing selected packets from the stream
attacker can cause some future packets to be authenticated and
decrypted correctly, but decompressed after that by using wrong state,
thus causing the end packets to be different from the original packet.
As the IPsec is there to protect that there cannot be any
modifications to the packets, this implies that we also want to detect
this kind of attacks. Because of this we do need some kind of message
authentication code after the decompression to make sure the packet
matches the packet that was sent.
-- 
[email protected]