Subject: [rohc] ROHCoIPsec and shutdown profile.

From: Carl Knutsson <[email-masked]>
Date: Fri, 07 Dec 2007 16:00:15 +0100

Hi Emre, Jonah, Chris Rohan and Carsten,

The ROHCoIPsec requires that the draft-bormann-rohc-shutdown-profile
"ROHC Profile for CID shutdown (ROHC-DOWN)" is included.

Cited from ROHC-DOWN:
  "The objective of this draft is mainly to mitigate a potential attack
   based on confusing the decompressor sufficiently that it accidentally
   forwards information to receivers of packets previously sent on a
   context.  By waiting for positive acknowledgement of channel shutdown
   before re-using a channel, this attack can be effectively prevented."

I cannot really see the why this document is needed. I may be missing
something here, but what is the difference between confusing the
decompressor with a ROHC IR packet compared to send a normal IP packet
for to the receiver for an IPsec connection without ROHC? Please fill me
in here.

If this document is included in ROHCoIPsec, it should be a working group
document.

I think it is a bit early for a working group last-call just yet, I
would like to pass on all the ROHCoIPsec documents together.

I also have a two comments on the ROHCoIPSec document:

Section 5.1

"     *  Support for legacy HC algorithms (e.g.  IPHC, CRTP, ECRTP) over
         IPsec may be provided through the specification of new RoHC
         profiles (e.g.  [ROHC-CRTP])"
	
I think this text should be removed from the draft. Otherwise the WG
commits to do rohc-profiles for legacy schemes.  Even if we do the new
profiles, it is not relevant in a document for ROHC over IPsec tunnels.
 Then there is the fact that we don't have consensus in the WG for the
any new profiles.

Section 6.1.1:

  "Additionally, RoHCoIPsec implementations should minimize the amount
   of feedback sent from the decompressor to the compressor. If a ROHC
   feedback channel is not used sparingly, the overall gains from
   RoHCoIPsec can be significantly reduced."

This part is good.

                                           "For example, assume that
   RoHC is operating in bi-directional Reliable mode (R-mode), and is
   instantiated over an IPsec tunnel mode SA.  In this scenario, any
   feedback sent from the decompressor to the compressor must be
   processed by IPsec, and tunneled back to the compressor (as
   designated by the SA associated with FEEDBACK_FOR)."

I don't think I fully understand what you are trying to say in the text
above. Using the feedback sparsely is always important here and when you
use ROHC in general. Is it extra important for ROHCoIPsec compared to
other protocols that transports ROHC traffic?  What is the R-mode
example illustrating? I guess Reliable-mode generates more feedback than
optimistic-mode. Is it an advise to avoid sending feedback to to
decrease the computation load for reverse IPsec tunnel?

I am a bit confused by the figure and explaination in section 6.1 and
that three is required to tunnel ROHC, but I will get back to that later.

Cheers,

/Calle

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 7 Dec 2007 07:12:35 -0800

On Dec 07 2007, at 07:00, Carl Knutsson wrote:

> I may be missing
> for to the receiver for an IPsec connection without ROHC?

The channel model does not allow the attacker to insert new packets,  
as those are caught by the authentication of ESP.
The only influence an attacker can exert is by selectively suppressing  
or short-term reordering packets, possibly based on the packet size  
signature the attacker can exploit.  ROHC-DOWN is intended to protect  
against an attack where the attacker selectively suppresses large  
packets, which might lead to UO-0 packets being decompressed in an old  
context when a CID has been reused.

We have discussed this issue here at the IETF and have concluded that  
while ROHC-DOWN plugs a hole, this is not the only possible attack.
We may have differences in assessing the severity of other mis- 
decompression attacks possible, but in the end only an integrity check  
value sent to protect the uncompressed packet is going to completely  
prevent all attacks.  Eight to twelve bytes should suffice.

This reduces the compression efficiency (and also makes the CRC in the  
ROHC header itself somewhat redundant), but it retains IPsec's high  
security.
The remaining work to be done is to negotiate the ICV size in IKE and  
to use IKE to obtain keying material.
This will be in the next set of drafts.

Gruesse, Carsten

---

From: Carl Knutsson <[email-masked]>
Date: Tue, 11 Dec 2007 16:29:44 +0100

Hi Carsten,

Carsten Bormann wrote:
> The channel model does not allow the attacker to insert new packets, as
> those are caught by the authentication of ESP.
> We may have differences in assessing the severity of other
> mis-decompression attacks possible, but in the end only an integrity
> check value sent to protect the uncompressed packet is going to
> completely prevent all attacks.  Eight to twelve bytes should suffice.
> 
> The remaining work to be done is to negotiate the ICV size in IKE and to
> use IKE to obtain keying material.
Sound good! Thank you Carsten for explaining the ROHC-DOWN document.
Emre sent me an email (off-list) explaining some of the details of your
suggestion to add a integrity check. It seems like a good idea.

/Calle