Subject: [rohc] AD comments on draft-ietf-rohc-ikev2-extensions-hcoipsec-08

From: Magnus Westerlund <[email-masked]>
Date: Thu, 14 May 2009 18:09:05 +0200

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-masked]
----------------------------------------------------------------------

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 18 May 2009 15:46:27 +0300

> which algorithm are required to be supported for interoperability.

I would expect they would be same as in IKEv2 in general i.e. RFC
4307 (MUST for AUTH_HMAC_SHA1_96, SHOULD+ for AUTH_AES_XCBC_96, and
MAY for AUTH_HMAC_MD5_96). I think this probably should be explictly
mentioned.

> within one is operating. Is that the correct interpretation?

Same keying material, different parts of it. Section 2.17 defines that
keying material is generated as follows:

      KEYMAT = prf+(SK_d, Ni | Nr)

(or slightly different way if Diffie-Hellman was done).

Then it says that this KEYMAT is split to different keys used for the
child SA and gives explicit rules how the key is split:
----------------------------------------------------------------------
   Keying material MUST be taken from the expanded KEYMAT in the
   following order:

      All keys for SAs carrying data from the initiator to the responder
      are taken before SAs going in the reverse direction.

      If multiple IPsec protocols are negotiated, keying material is
      taken in the order in which the protocol headers will appear in
      the encapsulated packet.

      If a single protocol has both encryption and authentication keys,
      the encryption key is taken from the first octets of KEYMAT and
      the authentication key is taken from the next octets.
----------------------------------------------------------------------

I.e. the KEYMAT used to generate the keys are same, but different
bytes are used for the different keys in for example following order:

	* initiator -> responder ESP encryption key
	* initiator -> responder ESP authentication key
	* initiator -> responder ROHC authentication key
	* responder -> initiator ESP encryption key
	* responder -> initiator ESP authentication key
	* responder -> initiator ROHC authentication key

> with the actual datapackets? SPI?

I would expect it to be same way as IPsec SA is generally rekeyed,
i.e. when the IPsec SA is rekeyed, it gets new SPI and new keying
material.
-- 
[email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 May 2009 15:05:41 +0200

Hi Tero,

Thanks for the answers. See inline.

> MAY for AUTH_HMAC_MD5_96). I think this probably should be explictly

Ok

> child SA and gives explicit rules how the key is split:

Okay, that makes it clear. But as for one not experienced in the
technology I didn't understand when reading ROHCoIPsec text and the
above quotation from IKE how the KEYMAT is split. It wasn't clear to me
if the ROHC auth key is another IPsec protocol. That seems to most
logical fit but not explicit mentioned in the reference.

> i.e. when the IPsec SA is rekeyed, it gets new SPI and new keying

Okay, makes sense, but does that really work as ROHC is stating that it
is ignoring the SPI. There might be need for additional text on this to
make it clear.

Cheers

Magnus Westerlund

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 18 May 2009 16:21:15 +0300

> > MAY for AUTH_HMAC_MD5_96). I think this probably should be explictly

Actually now when I tought more about this, I think we should not
refer to the "RFC4307 Cryptographic Algorithms for Use in the Internet
Key Exchange Version 2 (IKEv2)".

ROHC is more like ESP than IKE, so it might be closer to refer to "RFC
4835 Cryptographic Algorithm Implementation Requirements for
Encapsulating Security Payload (ESP) and Authentication Header (AH)".

On the other hand that document talks strictly about ESP and AH, so
referencing that might be misleading.

So I suggest this document either to explictly mandate algorithms or
even create separate short documents for defining mandatory algorithms
(as is done for IKEv2 and ESP/AH).

> logical fit but not explicit mentioned in the reference.

I would expect it to be quite clear for someone who is actually
implementing the IKEv2 and then adding ROHC, as he has already done
the KEYMAT splitting and ROHC is just one more protocol added to the
IPsec processing just like AH, ESP, or IPcomp.

> is ignoring the SPI. There might be need for additional text on this to

The decryption key for the ROHC ICV is coming from the SA anyways
which is found by the SPI, so I do not really see any problem there.
I.e. if you look the draft-ietf-rohc-hcoipsec-10 processing model
figure 2 at section 6.1 (page 7) you see that the first thing it does
is to do the block A where it finds the SAD entry by SPI and then
checks whether ROHC is enabled or disabled. If it is enabled then it
needs to give the ROHC ICV keying material to the ROHC module.

Also the draft-ietf-rohc-ipsec-exteions-hcoipsec-04 explictily
mentions that ROHC ICV algorithm and key are part of the SAD entry
(section 2.2 page 5).

It seems that the information is there but it is bit split over in
different documents so adding some more text to documents might help. 
-- 
[email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 18 May 2009 15:40:05 +0200

> (as is done for IKEv2 and ESP/AH).

I don't have any real view on what the WG should do here. The argument
for a separate document is so that when the list of what algorithms to
support needs updating one doesn't have to push the main spec back to
proposed standard, only the algorithm specification one.

> IPsec processing just like AH, ESP, or IPcomp.

Okay, as long it is clear in which order the keying material should be
taken. To me it doesn't appear so. But if you say so I am fine with it.

> different documents so adding some more text to documents might help. 

I see how this will work. Some informational text about rekeying would
be good. Might not belong in this document either, maybe belongs to the
framework doc.

Cheers

Magnus Westerlund

---

From: "Ertekin, Emre [USA]" <[email-masked]>
Date: Tue, 19 May 2009 18:25:26 -0400

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
 
> where it is suitable. Also, is this a minimal required or simply a

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.

> decompressor. The order is arbitrary.

OK - we will change the text accordingly.

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

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

> 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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 26 May 2009 11:09:55 +0200

> required value for this channel parameter.

Okay, no problem when you add the discussion about other values in other
usage scenarios.

For the rest it seems that they are being solved.

Cheers

Magnus Westerlund