[IPsec] Comments on current RoHC over IPSec draft

Hello Author and working group,

I have the following comments on the current versions of the RoHC over
IPsec drafts:

draft-ietf-rohc-hcoipsec-08 -

This document refers to the use of an Integrity Check Value
(ICV) [section 6.1, Block B] to verify successful decompression of a 
ROHC packet. ROHC already provides CRC fields for this function.

draft-ietf-rohc-ikev2-extensions-hcoipsec-06 -

The authors are asserting that the ROHC Channel parameters much be
negotiated, not signaled. A simpler approach would be for the device 
which will decompress traffic to signal to the device compressing the 
traffic its RoHC abilities.

For example, from RFC 4995, section 5.1.2:

LARGE_CIDS - Why is this even sent? The value given for MAX_CID should 
allow a device to determine the value of this RoHC Channel parameter. 
This parameter should not need to be negotiated, or signaled.

MAX_CID - This parameter should be signaled by the end which will 
decompress the RoHC traffic. Ultimately, the decompressor's context 
storage space will limit how many contexts will be used. To support this 
assertion I  provide the following MAX_CID cases:

1) The compressor has a larger MAX_CID than the decompresor. In this 
case the decompressor is the limiting factor on the MAX_CID. The 
compressor's MAX_CID will never be reached, and therefore is not important.

2) The compressor and decompressor have the same MAX_CID value. In this 
case the compressor's MAX_CID also does not matter because it is equal 
to the decompressor's MAX_CID.

3)  The compressor has a smaller MAX_CID than the decompressor. In this 
case the compressor will never have a CID that is equal to the 
decompressor's MAX_CID, and therefore the decompressor does not need to 
know anything about the compressor's MAX_CID. The compressor will stop 
compressing flows once its MAX_CID is reached.

PROFILES - This parameter should be signaled by the end which will 
decompress the RoHC traffic. By doing this the end which will compress 
the traffic knows what PROFILES may be used for compression. If the 
compressor supports PROFILES that the decompressor does not, it will 
never be able to use them with that decompressor anyway. If the 
decompressor supports PROFILES the compressor does not, the compressor 
will never use them either.

FEEBACK_FOR - This should be signaled by the end doing decompression 
(and optionally sending feedback) to the end doing the decompression to 
indicate for which flow the feedback is sent. This is in agreement with 
the RFC.

MRRU - This parameter is unnecessary. The external interface of the 
IPSec device should be able to determine the MTU of its link and 
fragment as needed/necessary. None of the RoHCv2 PROFILES (found in RFC 
5225) allow for the use of MRRU, so why use it?

The IKEv2 Notify Message Type [section 2.1] should only be sent once by 
each end during the IKE_AUTH and CREATE_CHILD_SA exchanges signaling the 
RoHC parameters.

The standard Notify Payload header fields appear to be the same as those 
specified for IKEv2, but the Next Payload field is missing for some 
reason? Why?

The fields specified to be included in the Notification Data field of 
the Notify Payload are as follows:

MAX_CID

MRRU - Why include MRRU field when ROHCv2 Profiles prohibit the use of 
segmentation (which is why you specify MRRU)? See MRRU comment above.
MAX_HEADER - Only used for Profiles found in RFC 2507 (IPCOMP). None of 
the ROHCv2 Profiles utilize this value, why include it?

PROFILE_LENGTH - Why do you need 16 bits to express the number of 
Profiles when the IETF has only allocated less than 20 Profile 
                        Identifiers? You can only use one variant of any 
Profile on a ROHC
Channel per RFC 4995, section 5.1.2 (Per-Channel Parameters).

PROFILES

INTEGRITY ALGORITHMS - Why have Integrity Algorithms to "ensure the 
integrity of the decompressed packets" when you have ROHC CRCs 
                    to verify the decompression of packets?

draft-ietf-rohc-ipsec-extensions-hcoipsec-02 -

This document specifies the inclusion of ROHC Channel parameters into
the SPD, including: MAX_CID, PROFILES, MRRU, MAX_HEADER. As ROHCv2
Profiles cannot use ROHC Segmentation, why have a MRRU parameter? Why
include the MAX_HEADER parameter that is not used by ROHCv2 (nor RFC
3095) profiles?

The document also specifies the inclusion of Integrity Algorithms into
the SPD. See comment above on why these values don't appear to be useful.

The SAD parameters specified include those specified for the SPD above,
and also include the FEEDBACK_FOR parameter. The HAIPE IS draft spec and
the IETF draft match on their approach on this parameter in both manual
and dynamic SA creation cases.

An argument is made in section 4 that the integrity check algorithm
provides protection against the "...possibility of an invalidly
decompressed packet to be forwarded ... into a protected domain." 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.

rohc-request@ietf.org wrote:
> Send Rohc mailing list submissions to
> 	rohc@ietf.org
> 
> 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@ietf.org
> 
> You can reach the person managing the list at
> 	rohc-owner@ietf.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Rohc digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Review of the RoHC over IPsec drafts (Ertekin, Emre [USA])
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Sun, 14 Sep 2008 23:40:53 -0400
> From: "Ertekin, Emre [USA]" <ertekin_emre@bah.com>
> Subject: Re: [rohc] Review of the RoHC over IPsec drafts
> To: "Yoav Nir" <ynir@checkpoint.com>,	"Christou, Christos [USA]"
> 	<christou_chris@bah.com>, <cabo@tzi.org>
> Cc: ipsec@ietf.org, rohc@ietf.org, Yaron Sheffer
> 	<yaronf@checkpoint.com>
> Message-ID:
> 	<37BDD2FAF2AEAE459C6C70FDC2892E4E03457938@MCLNEXVS05.resource.ds.bah.com>
> 	
> Content-Type: text/plain;	charset="us-ascii"
> 
> Hi, Yoav,
> 
> Thanks for your comments and review of our drafts.  Please find our
> responses below.
> 
>> The three drafts are:
>>
>> *	draft-ietf-rohc-hcoipsec - integration of RoHC over IPsec SAs
>> *	draft-ietf-rohc-ikev2-extensions-hcoipsec - IKEv2 extensions to
>> negotiate RoHC over IPsec
>> *	draft-ietf-rohc-ipsec-extensions-hcoipsec - IPsec extenstions
>>
>>
>>
>> Overall the drafts drafts seem good, and in my opinion could offer a
>> substantial benefit for IPsec tunnels, especially where the bandwidth
> to
>> one or both endpoints is constrained. Here's my comments.
> 
> Thanks!
> 
>> *	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 reason for this additional integrity-check is to mitigate scenarios
> where intentional (severe) packet reordering or packet loss in the
> unprotected network can cause the decompressor to invalidly decompress
> packet headers (incorrectly reconstruct fields of a packet header), and
> forward them into the protected domain.  
> 
> To mitigate this, we add the additional integrity algorithm to verify
> that the decompression operation is successful.  
> 
> Note that since we are adding an additional ICV, the overall efficiency
> gain of header compression is reduced.  It may be desired not to
> negotiate this additional RoHC integrity algorithm for the RoHC-enabled
> SA, but this comes with the risk that compressed headers may be
> invalidly decompressed and forwarded into the protected domain.
>  
>> 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.
> 
> I think that Pasi responded to this in his email.  We want to be able to
> ensure (potentially to the level of the cryptographic strength
> negotiated for IPsec) the integrity of all bits in the decompressed
> header.  
> 
> Note, however, that the values negotiated for the integrity-check are
> based on Integrity Algorithms defined in the Transform Type 3 registry.
> Therefore, an implementation could negotiate the value of "0" (no
> integrity-algorithm), and as you mentioned, rely on the built-in RoHC
> CRC.  
> 
>> *	The introduction to draft-ietf-rohc-hcoipsec-08 says that
> "However,
>> since current specifications for RoHC detail its operation on a
> hop-by-hop
>> basis, it may require extensions to enable its operation over IPsec
> SAs.".
>> This is not explained later. An IPsec tunnel is very much like a
> single
>> hop (for the tunneled traffic), so I don't see why special extensions
>> would be needed.
> 
> We'll clarify the introduction based on your comment.
> 
> What we intended to indicate was that for RoHCoIPsec, there may be
> multiple physical hops between compressor and decompressor (even though
> it looks like a single hop from the IPsec perspective).   Therefore,
> RoHCv2 profiles that are tolerant to packet reordering/loss should be
> used. 
> 
> Initial profiles of RoHC did not necessarily account for significant
> packet reordering scenarios, since RoHC was initially designed to
> operate over a single physical hop.
> 
>> *	Section 4 of draft-ietf-rohc-hcoipsec-08 needs some rewording.
> Is
>> the second sentence about the TFC feature of IPsec? About the padding
>> feature of RoHC? About the problem in general? You might want to add
>> discussion about whether it is recommended to use RoHC padding or
> IPsec
>> TFC to avoid the problem.
> 
> It's about the problem in general.  The second sentence was intended to
> indicate that an ESP tunnel mode SA provides partial traffic flow
> confidentiality, but that tunneling incurs additional packet overhead.
> 
> I'm inclined to leave the text as-is; let me know if you still think it
> needs to be modified.
> 
>> *	Section 5.2 of draft-ietf-rohc-hcoipsec (last paragraph) has
> some
>> strange text about ESP-NULL, which I don't understand. Why should
> ESP-NULL
>> be any different than any other ESP method?
> 
> Fair comment.  We'll delete this paragraph.
> 
>> *	There is, however, something to consider about ESP-NULL. Some
>> middleboxes may want to inspect traffic that is encrypted with
> ESP-NULL
>> (see draft-grewal-ipsec-traffic-visibility-00). It's possible that
> RoHC
>> will cause those middleboxes to drop all traffic that is compressed,
>> because they won't be able to parse the compressed headers.
> 
> This is more of a question of policy rather than functionality.  For
> example, the middlebox may have a policy to drop ESP-NULL encrypted
> packets whose inner-headers cannot be parsed.  On the other hand, the
> middlebox could have a policy that says inspect all ESP-NULL encrypted
> packets, drop packets whose inner headers cannot be parsed, except for
> those packets whose the NextHeader field is set to "RoHC".
> 
>> *	Section 6.1.2 says "f the RoHC protocol requires bi-directional
>> communications, two SAs must be instantiated between the IPsec
>> implementations." This is a non-issue, since IKE creates SAs in pairs
>> anyways. So I don't see the point in the recommendation to use only
> non-
>> feedback profiles. You may want to mention that the decompressor needs
> to
>> relay feedback to the appropriate compressor
> 
> Agreed.  Later in the paragraph, we indicate:
> 
> "  Note that the requirement
>    for two SAs aligns with the operation of IKE, which creates SAs in
>    pairs by default."
> 
> We'll modify the last sentence of the paragraph to indicate that the
> decompressor associated with an inbound SA will relay feedback to the
> compressor associated with the corresponding outbound SA.
> 
>> Regarding the IKEv2 draft, I only have several comments about section
> 2.1:
>> *	It's common for IKEv2 drafts to have at the beginning a figure
> of
>> the entire payload and then explain the various fields.
> 
> Sure, we can add a figure illustrating the Notify payload.  We actually
> had this illustration in the -02 version of the draft, and then removed
> it since it was identical to Figure 16 of RFC 4306.  But, we'll add it
> back. 
> 
>> *	The explanation of the "Critical" bit is incorrect. It does not
>> refer to the content of the payload, only to the type of the payload,
> in
>> this case "Notify". The bit MUST be off for Notify payloads, because
> all
>> IKEv2 implementations must support it. Similarly, there's not reason
> to
>> define the content of the reserved bits, because they're the same as
> for
>> any payload.
> 
> Agreed--we have updated the draft to indicate that this bit if off.  We
> also removed the definition of the content of the reserved field.  
> 
>> *	Protocol ID field: According to the first paragraph of 2.1, the
>> notification is only in CCSA and IKE_AUTH. So there's no case where
> this
>> notification is used outside of the creation of the child SA, and
> there's
>> no need to ever set the protocol ID.
> 
> Agreed--this is fixed.
> 
> Best Regards,
> Emre 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www.ietf.org/mailman/listinfo/rohc
> 
> 
> End of Rohc Digest, Vol 53, Issue 7
> ***********************************

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec