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

Magnus Westerlund writes:
> 3. Section 2.1.2: Required to support algorithm? Can you please clarify
> 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.

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

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

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

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