Re: [IPsec] Review of the RoHC over IPsec drafts (Robert Stangarone)

[email protected] wrote:
 > Send Rohc mailing list submissions to
 >     [email protected]
 >
 > To subscribe or unsubscribe via the World Wide Web, visit
 >     https://www.ietf.org/mailman/listinfo/rohc
 > or, via email, send a message with subject or body 'help' to
 >     [email protected]
 >
 > You can reach the person managing the list at
 >     [email protected]
 >
 > When replying, please edit your Subject line so it is more specific
 > than "Re: Contents of Rohc digest..."
 >
 >
 > Today's Topics:
 >
 >    1. [IPsec] Review of the RoHC over IPsec drafts (Tero Kivinen)
 >    2. Re: [IPsec]  Review of the RoHC over IPsec drafts (Yaron Sheffer)
 >    3. Re: [IPsec] Review of the RoHC over IPsec drafts (Yoav Nir)
 >
 >
 > ----------------------------------------------------------------------
 >
 > Message: 1
 > Date: Tue, 9 Sep 2008 15:34:55 +0300
 > From: Tero Kivinen <[email protected]>
 > Subject: [rohc] [IPsec] Review of the RoHC over IPsec drafts
 > To: Yoav Nir <[email protected]>
 > Cc: [email protected], [email protected], [email protected],
 >     [email protected],    [email protected], [email protected]
 > Message-ID: <[email protected]>
 > Content-Type: text/plain; charset=us-ascii
 >
 > 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.

If an attacker removes an entire packet, the ROHC decompressor should be 
able to recognize a non incremental increase in the ROHC MSN.

The ROHC decompressor decompresses the packet and calculates the CRC 
according to the packet type, then compares the calculated CRC to the 
transmitted CRC  which was included in the compressed ROHC packet. If 
they don't match it can attempt local repair, or drop the packet. If the 
local packet repair is successful, it gets passed to the upper layers, 
if not it gets dropped.

I don't see why you would use an ICV when ROHCv2 Profiles already 
provide CRCs to validate or verify header decompression operations, and 
the ESP header provides an Authentication Data field which contains an 
ICV that is necessary to authenticate the packet.