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

Hi Tero,

Thanks for the answers. See inline.

Tero Kivinen skrev:
> 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.

Ok

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

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.

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

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

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