Re: Review of the RoHC over IPsec drafts

On Sep 9, 2008, at 3:34 PM, Tero Kivinen wrote:

> 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.

I agree, but I'm not saying that we don't need an ICV for the  
decompression, just that we don't need HMAC-SHA1. CRC is good enough  
to detect a mismatched decompressor state.