[rohc] Comments on ROHC-over-IPsec

[<Pasi.Eronen at nokia.com>]

Some comments about draft-ietf-rohc-hcoipsec and 
draft-ertekin-rohc-ipsec-extensions-hcoipsec:

1) Overall comment: I'd suggest merging the contents of
draft-ertekin-rohc-ipsec-extensions-hcoipsec into
draft-ietf-rohc-hcoipsec. IMHO this would make them easier to 
read: currently there's plenty of copy-pasted text, and
draft-ertekin-... has less than 3 pages of original content.


2) It looks like one very important security consideration 
isn't described in the documents yet.

When using normal IPsec (without ROHC) with integrity protection,
packets that "come out" from an SA are always packets that were 
"sent in" (unless the key is compromised, some hard cryptographic 
problem is broken, or the attacker guesses a correct MAC value).

I've understood that ROHC being "robust" means that it deals "well
enough" with random errors (packets loss, corruption, reordering).
But when combined with IPsec, we need to consider non-random,
intentionally introduced errors as well.

In the current draft, IPsec integrity protection is applied to
compressed packets. The crucial question is thus whether an attacker,
by introducing non-random reordering/packet loss, cause packets to
"come out" that weren't sent in? (Clearly this wouldn't be possible 
if integrity protection was applied to uncompressed packets, but
that would be more complex overall.)

I'm not sure what the answer is, but certainly the document needs at
least a convincing explanation about this issue (and the mechanisms
ROHC uses to mitigate random errors, like 8-bit CRC, are not
necessarily enough against intentional errors).


3) It might also be useful to mention that header compression can
reveal information to traffic analysis (by changing packet lengths in
certain ways) that wouldn't be available without compression. For
example, if the original traffic consists of fixed-size packets, after
ROHCoIPsec it might be easier to count how many separate flows there
are (and when new flows start).


4) I'm not sure if the description of combining RoHCoIPsec and IPcomp
is correct. It seems to assume that IPcomp touches only the payload
but not the IP header (in which case doing ROHC-IP-only after IPcomp
could be useful). However, according to RFC 3173, "In the case of an
encapsulated IP header (e.g., tunnel mode encapsulation in IPsec), the
datagram payload is defined to start immediately after the outer IP
header; accordingly, the inner IP header is considered part of the
payload and is compressed."


5) "Furthermore, the RoHC FEEDBACK_FOR channel parameter is set
implicitly to the RoHC channel associated with the SA in the reverse
direction.  Because both of these RoHC channel parameters are set
implicitly, they are not stored in the SPD or SAD."

This pairing of SAs needs more discussion, as it's probably one of the
biggest changes to RFC 4301. When the SAs are created using IKE, the
FEEDBACK_FOR parameters is indeed set implicitly -- but clearly it
still needs to be stored somewhere (in the SAD).

Feedback also introduces another change to RFC 4301: the possibility
that IPsec implementation might have to originate packets. Normally
feedback would be piggy-backed on ordinary data packets, but if there
is no traffic in other direction, presumably a packet containing only
feedback might need to be sent. The document should discuss this
issue, and provide some guidance.


6) The document should probably cite RFC 4224, and explicitly mention
that some ROHC profiles aren't compatible with reordering channels
(such as ROHCoIPsec).


Best regards,
Pasi

_______________________________________________
Rohc mailing list
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc