Subject: Re: [IPsec] Comments on current RoHC over IPSec draft

From: "Ertekin, Emre [USA]" <[email-masked]>
Date: Sun, 21 Sep 2008 20:13:30 -0400

Hi, Robert,

Thanks for reviewing our drafts, and providing comments.  Please find
our responses inline:

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

This has been discussed in significant detail before.  Please see Pasi's
email below for further clarification:

http://www.ietf.org/mail-archive/web/rohc/current/msg05374.html

To summarize the discussion, the ROHC CRC may not be good enough to
provide the levels of authentication that we need with IPsec.  

Having said this, I would like to note that a RoHCoIPsec implementation
may choose to negotiate a value of "0" in Integrity Algorithms field
(i.e., NONE, as defined in the Integrity Algorithm Transform ID
registry), and instead implement the ROHC CRC as you suggest.  

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

We adopted this framework because we wanted to remain consistent with
previous RFCs (e.g., RoHC/PPP defined RFC 3241) which indicates that
these parameters are "negotiated".  

In our case, the initiator sends a Notify Payload with the ROHC
parameters that the compressor supports.  Based on this Notify payload,
the Responder confirms the parameters that are active for the RoHC
channel.

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

Nowhere in the IKEv2 extensions draft do we state that the LARGE_CID
parameter is sent.  In our draft, we state the following:

"     Note: The value of LARGE_CIDS will be implicitly determined by
      this value (i.e. if MAX_CID is <= 15, LARGE_CIDS will be assumed
      to be 0)."

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

Although I agree that the decompressor's context storage space limits
how many contexts will be used, I don't think that this is a good
approach.  

In case (3) above, without knowledge of what the compressor can support,
a decompressor instance may default to supporting the maximum number of
CIDs per SA (2^14-1) -- this means that for every decompressor instance
that is established, the implementation may allocate resources (e.g.,
memory) for 2^14-1 CIDs per decompressor instance (e.g., per SA).  This
allocation would be wasteful if each compressor only requires a few
(e.g., 1-2) CIDs per instance.

This is why there is benefit for the decompressor to have some sort of
knowledge about the compressor's MAX_CID. 

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

I'm not sure if this is a good approach either.  Take, for example, the
following case: compressor only supports Profiles A,B,C, decompressor
only supports Profiles D,E.  Upon creation of the RoHC-enabled SA, the
decompressor instance will be active, with profiles D,E.  But the
compressor neither supports D, or E.  This is again a wasteful
instantiation of a decompresor instance at the IPsec implementation.

This is why we think there is benefit to having the decompressor know
about the compressor's PROFILES (and in general, the compressor's
channel parameters).

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

We are not negotiating this parameter.  In the IKEv2 draft, we state the
following:

"  When a pair of SAs are created (one in each direction), the RoHC
   channel parameter FEEDBACK_FOR is set implicitly to the other SA of
   the pair (i.e. the SA pointing in the reverse direction)."

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

Fair comment.  We'll remove this parameter.

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

Correct.

> 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 field is not missing -- we didn't describe the field since it is
consistent with the description provided in RFC 4306.  

To avoid confusion, we'll include an illustration of the Notify header
in the next revision of the draft, and a description of all Notify
header fields.

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

Please see RFC 3241 for the reasoning behind including the MAX_HEADER
field.

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

Fair comment -- we can reduce this to 1 byte.

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

Again, please see previous discussions on this:

http://www.ietf.org/mail-archive/web/rohc/current/msg05374.html

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

Negotiation of the MRRU parameter will be removed on the next revision
of the draft.

> Why
> include the MAX_HEADER parameter that is not used by ROHCv2 (nor RFC
> 3095) profiles?

Please see our response above regarding MAX_HEADER.

<snip> 

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

Again, please see the previous mailer discussions on why we need the
integrity algorithm. 

Thanks,
Emre
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Robert A. Stangarone Jr." <[email-masked]>
Date: Sun, 21 Sep 2008 13:07:10 -0700

Hello Author and working group,

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.

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?

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

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.

[email-masked] wrote:
> Send Rohc mailing list submissions to
> 	[email-masked]
> 
> 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
> 	[email-masked]
> 
> You can reach the person managing the list at
> 	[email-masked]
> 
> 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]" <[email-masked]>
> Subject: Re: [rohc] Review of the RoHC over IPsec drafts
> To: "Yoav Nir" <[email-masked]>,	"Christou, Christos [USA]"
> 	<[email-masked]>, <[email-masked]>
> Cc: [email-masked], [email-masked], Yaron Sheffer
> 	<[email-masked]>
> Message-ID:
> 	<[email-masked]>
> 	
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rohc
> 
> 
> End of Rohc Digest, Vol 53, Issue 7
> ***********************************

---

From: "Kristofer Sandlund" <[email-masked]>
Date: Mon, 22 Sep 2008 09:46:44 +0200

Ertekin, Emre wrote on :

>> RFC 5225) allow for the use of MRRU, so why use it?
> 

Hi,

I haven't read the drafts in question nor the entire mail I'm
replying to, I'd just like to point out that the statement above is 
incorrect. The following is a quote from 5225:

   The compressor MUST NOT use ROHC segmentation (see Section 5.2.5 of
   [RFC4995]), i.e., the Maximum Reconstructed Reception Unit (MRRU)
   MUST be set to 0, if the configuration of the ROHC channel contains
   at least one ROHCv2 profile in the list of supported profiles (i.e.,
   the PROFILES parameter) and if the channel cannot guarantee in-order
   delivery of packets between compression endpoints.

Therefore, it *is* allowed to use ROHC segmentation in v2, it is only
disallowed if you have a reordering channel with v2 profiles.
I'm not saying that ROHC segmentation is a very useful feature or that
you have to allow it, I'd just like to avoid you making decisions 
based on an assumption that v2 *always* disallows segmentation.

/k

---

From: "Carl Knutsson" <[email-masked]>
Date: Mon, 22 Sep 2008 12:49:05 +0200

Emre,

I believe MRRU should stay. I think we should have very good reasons
before we remove it. We should not make any assumptions about the link
layer. For some users it may more be convenient to use the ROHC
segmentation instead of fragmentation in other layers. Why would we
not allow it? Both the ROHCoIPSec draft and the framework already
discusses ROHC segmentation. The ROHCoIPSec drafts is quite clear
about the disadvantages with ROHC segmentation.

I agree with Robert that the MAX_HEADER parameter should be removed.
We have agreed on a set of negotiation parameters for the ROHC
framework (RFC 3095 and RFC 4995). All other parameters must be
negotiated within the protocol. If the MAX_HEADER parameter is really
needed, it should be included in the ROHC framework and not in
ROHCoIPSec drafts. If it becomes a problem for future ROHC profiles,
it could be solved by something similar to CONTEXT_MEMORY feedback
option for v2.

/Calle

---

From: "Carl Knutsson" <[email-masked]>
Date: Tue, 30 Sep 2008 14:38:50 +0200

Chris, Emre,

On Mon, Sep 29, 2008 at 5:45 PM, Christou, Christos [USA]
<[email-masked]> wrote:

-----8<---------
> As you have pointed out, the overhead varies based on profiles. Although
> it might not be as ideal, the overhead we would account for PMTU could
> be profile dependent. In other words, there will be an entry in the SPD
> for the profiles we would like to compress over particular SA's.
> Therefore, depending on the profiles identified, we could account for
> the maximum possible RoHC overhead in the PMTU calculation based on the
> profiles listed in the SPD.
>
agreed

> We will not include the MAX_HEADER parameter in our drafts.
>
agreed

/Calle