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

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 protected]]
>> Sent: Monday, September 21, 2009 12:20 AM
>> To: Black, David; [email protected]; [email protected];
>> [email protected]; [email protected]; [email protected]
>> Cc: [email protected]; [email protected];
>> [email protected]
>> Subject: RE: Gen-ART review of
>> draft-ietf-rohc-ikev2-extensions-hcoipsec-09
>>
>> 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 protected]        Mobile: +1 (978) 394-7754
>> > ----------------------------------------------------
>>
>>
>