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

Hi,

Here are some comments on this spec.

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.


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.


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

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?


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?


Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email protected]
----------------------------------------------------------------------