[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [rohc] 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:emreertekin.ietf at gmail.com]
>> Sent: Monday, September 21, 2009 12:20 AM
>> To: Black, David; ro at breakcheck.com; kivinen at safenet-inc.com;
>> cabo at tzi.org; gen-art at ietf.org; christou_chris at bah.com
>> Cc: carl.knutsson at effnet.com; magnus.westerlund at ericsson.com;
>> rohc at ietf.org
>> 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
>> > black_david at emc.com Mobile: +1 (978) 394-7754
>> > ----------------------------------------------------
>>
>>
>