Re: [rohc] AD comments on draft-ietf-rohc-ipsec-extensions-hcoipsec-04

["Ertekin, Emre [USA]" <[e-mail]>]

Hi Magnus,

Please find our responses to your comments on the IPsec extensions
draft.

> Section 3.1:
> 
> Shouldn't it be discussed when this protocol number is appropriate to
> be
> used. To me it appears that some requirements need to be fulfilled
> before one uses it on a particular layer. Running ROHC straight on top
> of IPv6 for example seems like a bad idea in most case due to such
> considerations as security and denial of service for the decompressor,
> the multi-hop environment, and lack of clear logical channel.

This is good idea.  At the end of the section, we can add a paragraph
that describes usage considerations of the ROHC protocol number.  

However, we would like to craft the paragraph such that it doesn't
preclude the ROHC protocol number use in other scenarios.  Rather, the
text will identify considerations that need to be accounted for if the
ROHC protocol number is used for some other purpose.

> 
> Section 3.2.1:
> 
> I think the language in this section could be benefit from being
> written
> in active tense saying what to do, rather than what happens.
Especially
> when we comes to bullets like:
> 
>       The decompressed packet is used with the integrity algorithm
(and
>       its respective key) to compute a ROHC ICV that is compared to
the
>       appended ICV (if these two values differ, the packet is dropped)
> 
> The second parenthesis seems to be a very hard requirement because
> otherwise the ROHCoIPsec solution doesn't have a clear integrity
> preserving property.

OK - I will clean up the text in this section (and section 3.3.) based
on your comment.

> Section 3.2.1:
> 
> What ICV algorithms and key lengths must be supported in the
> implementations? This is to ensure that there are at least one
> algorithm
>  and key length that are supported by everyone.

This was discussed in a separate email thread.  I would recommend that
we remain consistent the AUTH algorithm requirements defined in RFC
4835:  

	 Requirement    Algorithm
       -----------    ----------------
       MUST           HMAC-SHA1-96 
       SHOULD+        AES-XCBC-MAC-96 
       MAY            HMAC-MD5-96 

Note, however, that this does not necessarily mean that HMAC-SHA1-96
must be negotiated for any particular ROHC-enabled SA.  What is actually
negotiated depends on depends on policy.  Specification of the above
provides a "common denominator" for the AUTH algorithm that is available
for use across all ROHCoIPsec implementations.

BR,
Emre