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.
