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

Tero Kivinen skrev:
> Magnus Westerlund writes:
>> 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
> 
> 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).

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.


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

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.

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

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

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