Subject: Re: [rohc] Gen-ART review of draft-ietf-rohc-ikev2-extensions-hcoipsec-09

From: Emre Ertekin <[email-masked]>
Date: Sun, 20 Sep 2009 21:20:18 -0700

Hi David,

Thank you for reviewing our drafts.  Please find our responses below.

> Comments:
>
> The draft does not use RFC 2119 keywords (e.g., MUST), but the
> draft is clearly written with clearly stated requirements, so
> the authors' non-use of RFC 2119 keywords is not a problem.

Thanks for pointing this out--actually, another reviewer requested
that we include these keywords as well.  Therefore, we decided to
include them in the next release of the draft.

> Figure 2 is confusing; it would be better to separate it into
> two ASCII diagrams, one each for the AF=0 and AF=1 cases.  For
> AF=0, tilde (~) characters should be used in the vertical sides
> of the ROHC Attribute Value box to indicate that the value
> is variable length.

I feel that the figures/description provided are pretty
straightforward for IKE implementers, as they are identical to the
figures/description presented in Section 3.3.5 of IKEv2 [RFC 4306] and
the IKEv2bis draft.  However, if you feel that it is necessary to
separate these figures, I'm happy to entertain further discussion
here.

> In Section 2.1.2, the discussion of ROHC Profile neglects to
> say where the profile numbers come from.  It looks like they
> come from the IANA registry for ROHC Profile Identifiers:
> http://www.iana.org/assignments/rohc-pro-ids/rohc-pro-ids.xhtml
> That should be stated.

Sounds good, I can add a statement with this reference.

> Truncating an integrity algorithm's output via use of a
> ROHC_ICV_LEN value that is less than the algorithm's normal
> output size weakens the security protection of that integrity
> algorithm. That needs to be noted as a security consideration
> in Section 3.

Although I agree with the intent of your comment, I do not think that
this causes a security consideration for IKE.  However, I would like
to add text in the companion ROHCoIPsec framework draft
[draft-ietf-rohc-hcoipsec] that speaks to your point.  Is this alright
with you?

> The last sentence of the description of the MRRU attribute is:
>
> 	If MRRU is 0 or if no MRRU attribute is sent, no
>       segment headers are allowed on the ROHCoIPsec channel.
>
> What's a segment header?  Please add a sentence or two to explain.

Sure; I'll add a reference to Section 5.2.5 of RFC 3095.

> idnits 2.11.13 ran clean after correctly guessing that this
> draft is intended for Proposed Standard status.

Ok!  Thanks again.

Best Regards,
Emre

> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [email-masked]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------

---

From: Emre Ertekin <[email-masked]>
Date: Mon, 21 Sep 2009 10:38:03 -0700

Hi David,

> As long as the possibly weak security mechanism is
> addressed in the framework draft and there's text in this draft
> pointing to the framework draft's security considerations, the
> result should be ok.

This sounds like a good way to proceed forward!

Thanks again for your review.

BR,
Emre

> Thanks,
> --David
>
>
>> -----Original Message-----
>> From: Emre Ertekin [mailto:[email-masked]]
>> Sent: Monday, September 21, 2009 12:20 AM
>> To: Black, David; [email-masked]; [email-masked];
>> [email-masked]; [email-masked]; [email-masked]
>> Cc: [email-masked]; [email-masked];
>> [email-masked]
>> Subject: RE: Gen-ART review of
>> draft-ietf-rohc-ikev2-extensions-hcoipsec-09
>>
>> Hi David,
>>

---

From: <[email-masked]>
Date: Mon, 21 Sep 2009 12:50:27 -0400

Emre,

> separate these figures, I'm happy to entertain further discussion

Ok, the figure is close enough to the one in RFC 4306 that it
should not cause problems for implementers.

> [draft-ietf-rohc-hcoipsec] that speaks to your point.  Is this alright

Yes, provided that a general cross-reference to
draft-ietf-rohc-hcoipsec's security considerations is added to
this draft's security considerations section.  At a hair-splitting
level, this draft's current security considerations section is not
correct because the ability to signal a weaker security mechanism
enables its use, and that is a security consideration for the
signaling.  As long as the possibly weak security mechanism is
addressed in the framework draft and there's text in this draft
pointing to the framework draft's security considerations, the
result should be ok.

Thanks,
--David