[Fwd: Re: Rohc Digest, Vol 53, Issue 4 - ICV discussion]

[Robert Stangarone]

rohc-request@... wrote:

> Send Rohc mailing list submissions to
> rohc@...
>
> 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
> rohc-request@...
>
> You can reach the person managing the list at
> rohc-owner@...
>
> 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 <kivinen@...>
> Subject: [rohc] [IPsec] Review of the RoHC over IPsec drafts
> To: Yoav Nir <ynir@...>
> Cc: rohc@..., pezeshki_jonah@..., jasani_rohan@...,
> ipsec@..., christou_chris@..., cabo@...
> Message-ID: <18630.28015.487667.355981@...>
> 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.

Removing packets _may_ affect the state of the decompressor. Depending
on what types of packets are removed (i.e. IR or some type of CO) the
affect may or may not be recoverable at the decompressor depending on
how the fields are encoded.

If the state of the decompressor's context does not match the state of
the compressed header how will it be decompressed correctly? Isn't that
the point of the CRC?

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

Above you talk about an attacker removing packets, but here you say that
we need authentication "to make sure the packet matches the packet that
was sent". If the attacker is removing packets, how can we authenticate
them? They'll never arrive.


_______________________________________________
Rohc mailing list
Rohc@...
https://www.ietf.org/mailman/listinfo/rohc