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

From: Magnus Westerlund <[email-masked]>
Date: Thu, 14 May 2009 18:09:00 +0200

Hi

My comments on the IPsec extensions.

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.

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.

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.

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

---

From: "Ertekin, Emre [USA]" <[email-masked]>
Date: Tue, 19 May 2009 18:25:25 -0400

Hi Magnus,

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

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

> otherwise the ROHCoIPsec solution doesn't have a clear integrity

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

>  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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 26 May 2009 11:08:03 +0200

> ROHC protocol number is used for some other purpose.

Yes, fully agreed. I simply want some explicit mention on when this may
be considered suitable.

> we remain consistent the AUTH algorithm requirements defined in RFC

Understood, it is all about enabling interoperability points. If policy
doesn't allow them, that is another question.

Cheers

Magnus Westerlund