RE: [rohc] Comments on ROHC-over-IPsec

["Pezeshki, Jonah" <pezeshki_jonah at bah.com>]

Pasi,

Thank you for providing comments to our pending Internet Drafts
(draft-ietf-rohc-hcoipsec and
draft-ertekin-rohc-ipsec-extensions-hcoipsec).  Please find our response
to your comments below (comments inline).

Jonah Pezeshki
Consultant
Booz | Allen | Hamilton
(703) 984-0810

-----

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.

>>>The intent of "draft-ietf-rohc-hcoipsec" is to provide a framework
and guide for RoHCoIPsec implementers, while
"draft-ertekin-rohc-ipsec-extensions-hcoipsec" is intended as a proposed
standard for the actual extensions to IPsec.  As such, we want to try to
maintain two separate drafts for these different purposes.  However, to
address your comment, we have edited both drafts to limit the redundant
information.  We will resubmit both updated drafts shortly. 

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

>>>Although traditional RoHC may be susceptible to intentional
reordering events, RoHCoIPsec will utilize the IPsec's sequence number
to enhance RoHC's tolerance to reordering events (intentional and/or
unintentional).  Although this was briefly touched upon in the version
of "draft-ertekin-rohc-ipsec-extensions-hcoipsec" that you commented on,
we have since edited this draft to more clearly define this mechanism
and describe its importance in defending against intended reordering
events. 

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

>>>We now mention this security concern in both Internet Drafts.
However, it should be noted that this security concern may allow an
attacker to use packet size information to selectively block CID update
messages (i.e. monitoring packet size within the black network, and
selectively blocking "long" packets).  If a RoHCoIPsec implementation
reuses CIDs, this type of attack may cause packets to be incorrectly
routed within the destination red network (i.e. a packet's CID value
being misinterpreted as a previously used value, since the destination
RoHC instance never received the update information).  To resolve this
issue, a new RoHC profile (draft-bormann-rohc-shutdown-profile-00) was
drafted by Carsten Bormann.  This profile (ROHC-DOWN) will ensure that a
CID value cannot be reused until the RoHC compressor receives
confirmation that the RoHC decompressor has successfully cleared the
value.  We have also added text to both drafts to indicate that this
profile must be used if a RoHCoIPsec implementation intends to reuse
CIDs.


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

>>>Thank you for catching this oversight.  We have corrected the order
in which IPcomp is applied to packets within RoHCoIPsec. 


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.

>>>We have modified "draft-ertekin-rohc-ipsec-extensions-hcoipsec" to
indicate that the FEEDBACK_FOR parameter is stored in the SAD.  In
addition, we now mention that, ROHC feedback should be used sparingly
(if at all), and that, when possible, RoHC feedback messages should be
piggybacked on traffic normally traversing the SA designated by
FEEDBACK_FOR.


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

>>>Our "draft-ietf-rohc-hcoipsec" draft now notes that RFC4224 is to be
used as a guide when implementing RoHCoIPsec over channels that support
packet reordering.

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