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

["Ertekin, Emre [USA]" <ertekin_emre at bah.com>]

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
IPsec at ietf.org
https://www.ietf.org/mailman/listinfo/ipsec