Re: Review of the RoHC over IPsec drafts

All true. But CRC should be enough (I know it's not completely kosher 
for crypto purists, but it's so much faster...)


    Yaron


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

_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec