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

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

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

> >> 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. 
-- 
[email protected]