Re: [IPsec] Review of the RoHC over IPsec drafts

[<Pasi.Eronen at nokia.com>]

Yoav Nir wrote:
>
> Tero Kivinen wrote:
>
> > 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.

As noted in RFC 4995, ROHC already uses CRC is detect mismatched
decompressor state. Depending on the situation, either 3-bit CRC or
7-bit CRC... so even assuming CRC worked perfectly in this context,
it's clearly too short to give us the kinds of probabilities we'd
expect when doing cryptographic per-packet authentication.

Would a longer CRC work? That's a tough question. It might work, or
it might not -- it's very difficult to analyze the situation and be
sure.  CRCs were designed to catch random bit errors, but the "errors"
here are intentional -- and even a long CRC (say, 64 bits) doesn't 
behave the same way a cryptographic hash (say, SHA-256 truncated 
to 64 bits) does.

Since this second value (calculated over the uncompressed packet) is
covered by the MAC in ESP (calculated over the compressed packet),
it's possible that a non-keyed cryptographic hash would be enough.
But since we can easily get a key, using a MAC seems safer (typically,
MAC tags are also truncated to shorter lengths, like 96 bits, than
is used for non-keyed hashes), and gives us better algorithm agility 
(e.g., you can use AES-based algorithms for everything, without needing
the SHA-* family at all).

(BTW, Tero and I have discussed this topic extensively with the
authors earlier :-)

Best regards,
Pasi


_______________________________________________
IPsec mailing list
IPsec at ietf.org
https://www.ietf.org/mailman/listinfo/ipsec