Re: AD comments on draft-ietf-rohc-ikev2-extensions-hcoipsec-08

Hi Magnus,

Thanks for your comments to our IKEv2 Extensions to support ROHC draft.
I aggregated all discussions in the email exchanges, and summarize the
adjudications/way forward for each comment.  Please see below:  
 
> Section 2.1.2
> 
> Maximum Context Identifier (MAX_CID, AF = 1)
>       The MAX_CID attribute is a mandatory attribute.  Exactly one
>       MAX_CID attribute must be sent.  The MAX_CID field indicates the
>       maximum value of a context Identifier supported by the
ROHCoIPsec
>       decompressor.  This attribute value is two octets in length.
The
> 
> Ertekin, et al.          Expires August 6, 2009                 [Page
> 5]
> Internet-Draft   IKEv2 Extensions to Support ROHCoIPsec    February
> 2009
> 
>       range of values for MAX_CID must be at least 0 and at most 16383
>       (the value 0 implies having one context).  The recipient of the
>       MAX_CID Attribute must only use up to MAX_CID context
identifiers
>       for compression.
> 
>       Suggested value: 15
> 
> The suggested value seems to me to be highly variable depending on
> particular usage. Therefore this value should be put in a context on
> where it is suitable. Also, is this a minimal required or simply a
> recommendation.

We recommended this value such that we ROHC can operate within the
boundary of small CIDs.  The value is useful for SAs that are only
carrying a few flows.  

However, I agree with you that this value really depends on the usage
scenario.  For a ROHCoIPsec SA that is compressing traffic for a large
number of flows, a larger MAX_CID value might be more applicable.  We
will add clarifying text to indicate this.

This value wasn't intended to be a minimal required, just a
recommendation--similar to how hop-by-hop doesn't specify a minimal
required value for this channel parameter.

> 2. Section 2.1.2:
> 
> ROHC Profile (ROHC_PROFILE, AF = 1)
>       The ROHC_PROFILE attribute is a mandatory attribute.  At least
> one
>       ROHC_PROFILE attribute(s) must be sent.  A ROHC_PROFILE
attribute
>       contains a two-octet profile supported by the ROHCoIPsec
>       decompressor.  The recipient of a ROHC_PROFILE attribute(s) must
>       only use the profile(s) proposed for compression.
> 
> Unclear formulation regarding the usage of many attributes. To me one
> could be clearer and say something like. One or more ROHC Profile
> attributes provides a list of all supported profiles by the
> decompressor. The order is arbitrary.

OK - we will change the text accordingly.

> 
> 3. Section 2.1.2: Required to support algorithm? Can you please
clarify
> which algorithm are required to be supported for interoperability.

As discussed in our email exchanges, perhaps we can remain consistent
with the AUTH algorithms defined in RFC 4835.

> 4. Section 2.1.2: "
>       1.  The key for this Integrity Algorithm is computed using the
>           same method as is used to compute IPsec's Integrity
Algorithm
>           key ([IKEV2], Section 2.17)."
> 
> If I interpret this text and read 2.17 I get the impression that you
> are
> saying that one should use the same key as the one generated for the
SA
> within one is operating. Is that the correct interpretation?

This comment was addressed by Tero.  We will add some clarifying text,
but the changes will not be too significant. 

> 5. Section 2.1.2: How and when is the ROHC ICV re-keyed? And if not,
> please say so explicitly. If the key i changed, how is that
coordinated
> with the actual datapackets? SPI?

Again, Tero adjudicated this comment.  We can add some clarifying text
that indicates that when the IPsec SA gets rekeyed, the rekeying
procedure will also rekey the ROHC ICV.  We can add such text to both
the IKEv2 extensions and IPsec extensions drafts.


BR,
Emre