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

[<Black_David at emc.com>]

Emre,

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

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

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

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
 

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