RE: [secdir] Review of draft-ietf-l2vpn-oam-req-frmk-09

["Tobias Gondrom" <[e-mail]>]

Hello Dinesh,

no problem.
Answers inline.

Dinesh Mohan wrote:
> Tobias,
>
> Once again, thank you for your comments and apologies for the delay in the
> response back. Please see inline responses:
>
> Regards,
>
> ----
> Dinesh Mohan
>
>
> ________________________________
>
> From: Tobias Gondrom [mailto:[e-mail]]
> Sent: Friday, November 09, 2007 6:02 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; Mohan, Dinesh (CAR:NP02); [e-mail];
> [e-mail]; [e-mail]
> Subject: [secdir] Review of draft-ietf-l2vpn-oam-req-frmk-09
>
>
>
> Hello,
>
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG.
> These comments were written primarily for the benefit of the security area
> directors.  Document editors and WG chairs should treat these comments
> just like any other last call comments.
>
>
> I studied the draft and a have the following COMMENTS and leave it at the
> discretion of the ADs whether they want to raise any DISCUSS based on
> these COMMENTS:
>
>
> 1. a few editorial:
>
> Section 1:
>
> s/relationship between two layered networks; Fault Detection at the
> server/ relationship between two layered networks, Fault Detection at the
> server
>
> s/associated Pseudowires (PWs)/ associated Pseudo Wires (PWs)
>
> DM>> Agree with both comments regarding editorial updates.

Ok.

>
> unclear statements:
>
> Section 1:
>
> I found the following sentence imprecise and hard to understand:
>
> "Performance Management deals with mechanism(s) that allow
>
> determining and measuring the performance of network/services under
>
> consideration and notification of them."
>
> DM>> For the sake of removing this ambiguity that you seem to be
> encountering, the authors are willing to make the following editorial
> change:
>
> s/Performance Management deals with mechanism(s) that allow determining
> and measuring the performance of network/services under consideration and
> notification of them/Performance Management deals with mechanism(s) that
> allow determining and measuring the performance of network/services under
> consideration.

Ok.

>
> Section 1.1: I would suggest to add CE and PE to the terminology of this
> document. It can only be derived from following a two-step indirect
> reference (via RFC4664 and then the reference mentioned there, which is
> stated as "work in progress"). For improved convenience the terminology
> should be referred directly from the document, or even better and more
> simple just add those two (CE and PE) to its Terminology.
>
> DM>> Though the authors are not opposed to adding more terminology in this
> document, however, this typically becomes a challenge since we have
> multiple places where the same terms get defined. RFC4026 is the reference
> used for most terms that are a common place in L2VPN work. I am not sure
> where you are seeing the reference to "work in progress". The authors feel
> that no change is required for this given the references are in place,
> however, please let us know if this satisfies your comment.

Hm, I have no problem with using some terminology from referenced
documents, but RFC4026 is not listed as a reference in this document?
(Although I would prefer to see abbreviations that are vital for the
understanding of a draft (i.e. in this case CE and PE) to be at least
shortly associated with their meaning in the draft itself, I do recognize
that there may be different opinions about that.)
Still, if you want to use terminology from RFC4026, you should explicitly
list it in your reference section and not only implicitly via other
documents.

> 2. the document does not state its intended status: based on its content
> and its relationship to the two other referred RFCs 4664 and 4665, I would
> assume it is Informational.
>
> If this assumption is wrong, the intended status should be clarified ASAP.
>
> DM>> Your assumption is correct. This is meant to be Informational.

Please note: there exists a field for this in the header of the I-D
template. with your next next (and last revision) you should revisit your
header and include:
"Intended status: Informational"

> 3. The document does not seem to use RFC-2119 coherently. Throughout the
> document there are numerous places where I do not understand why authors
> use "must" instead of "MUST". One example:
>
> Section 6.10:
>
> Security implies that an OAM domain must be capable of filtering OAM
> frames.
>
> => should be: "Security implies that an OAM domain MUST be capable of
> filtering OAM frames."
>
> And:
>
> "Also, OAM frames from outside the OAM domains should be either discarded
> (when such OAM frames belong to same or lower-level OAM domain) or
> transparently passed (when such OAM frames belong to a higher-level OAM
> domain)."
>
> => Should be at least:
>
> "Also, OAM frames from outside the OAM domains SHOULD be either discarded
> (when such OAM frames belong to same or lower-level OAM domain) or
> transparently passed (when such OAM frames belong to a higher-level OAM
> domain)."
>
> In the context of the sentence I even wonder if "MUST" isn't more precise,
> as it MUST either be the first or the second.
>
> Equivalent in Section 7.10.:
>
> "Security implies that an OAM domain must be capable of filtering OAM
> frames."
>
> => should become: ""Security implies that an OAM domain MUST be capable of
> filtering OAM frames."
>
> And: "Also,VPWS OAM frames from outside the OAM domains should be either
> discarded"
>
> => should become: "Also,VPWS OAM frames from outside the OAM domains MUST
> be either discarded"
>
>
> Please note, my personal opinion is that RFC-2119-language usage seems
> incoherently throughout large parts of the document and not only in these
> two sections. But maybe my personal expectation is not correct for an
> Informational Draft in the context of this area.
>
> DM>> Please note that the document explicitly states the requirements
> which are called out as Rxx. There requirements are meant to be coherent
> with RFC-2119 language and these are indeed covered as such. The text
> prior to the individual requirements is meant to provide context,
> justification as to why the requirement is needed. Therefore the authors
> feel that no changes are needed since the requirements' text is coherent
> with RFC-2119. Please let us know if this satisfies your comment.

Hm, an interesting point of view on RFC-2119-usage.
I can agree with your explanation as all important information is covered
in RFC-2119 language and only redundant statements were made in
non-RFC-2119.

Personal note: my fear was that the fact of two equivalent statements in
the text (one time in RFC-2119 (in the Rxx) and one not using RFC-2119
might lead to confusion in the interpretation. Especially as the
explanaition you just gave in this email may not be obvious from the text
of the draft.
(e.g. I misread this as well.) However, this is only a minor disagreement
and so does not absolutely need mitigation.

>
>
> 4. The security Considerations (section 11) states that it does not need
> further security considerations as it only imposes requirements to
> solutions but does not describe the solutions themselves. In fact I
> believe this statement to be wrong in even two ways:
>
> 1. the initial abstract declares this draft is about the requirements AND
> a framework
>
> 2. even if the document would only be talking about requirements (and not
> about any implications on a framework), it should still clearly include
> security considerations for the requirements as they are already partially
> done in section 6.10 and section 7.10.
>
> DM>> The current text in section 11 states that "This document does not
> impose any security concerns since it imposes requirements on solutions to
> prevent OAM messages from leaking outside the OAM domains."  This
> statement does not imply that no security concerns are imposed since it is
> about requirements and no solutions. Rather, this states that no security
> concerns are imposed since the document imposes requirements on solutions
> to prevent OAM messages from leaking. And as you rightly point out, these
> requirements are indeed covered in section 6.10 and 7.10. Do you think an
> explicit reference to 6.10 and 7.10 in the above statement would help?
> Otherwise, the authors feel that no change may be required. Please let us
> know accordingly.

Yes it might be good to refer to section 6.10 and 7.10 from the documents
security considerations section. Plus two further suggestions:
1. Maybe you should limit the statement in the abstract that this ID is
about the requirements AND the framework and limit it to ~ it's about the
requirements
2. let me put this as a question: do you believe that only section 6 and 7
need to have security considerations? (and the rest of the ID not) - which
seems to me equivalent to what the current text states.
>From what I understand, I am not so sure about this, whether all of the
other sections do not need considerations. E.g. maybe section 8?
However, at the moment I can not point my finger at a specific thing
missing, it just feels a bit odd. So maybe it's all right.

>
> Last but not least, if the authors would still like to keep this section
> (11) as it is - which I would not recommend - they should consider to
> correct the following spelling errors:
>
> s/ For additional levels of security, the solutions may be required deploy
> to encrypt and/or authenticate OAM frames inside an OAM domain however
> solutions are out of the scope of this draft./For additional levels of
> security, the solutions may be required to deploy encryption and/or
> authentication of OAM frames inside an OAM domain, however solutions are
> out of the scope of this draft.
>
> DM>> We will modify this statement as:
> s/ For additional levels of security, the solutions may be required deploy
> to encrypt and/or authenticate OAM frames inside an OAM domain however
> solutions are out of the scope of this draft./For additional levels of
> security, the solutions may be required to encrypt and/or authenticate OAM
> frames inside an OAM domain, however solutions are out of the scope of
> this draft.

Ok.

>
> 5. Question: as the draft is heavily based on RFC4664 and 4665, I wonder
> whether they should not better be normative references instead of
> informative ones?
>
> DM>> The authors are open to moving the two references to normative
> section, however, the rationale had been that both 4664 and 4665 are
> informational therefore could well be in either of the two locations.
> Please let us know if you feel strongly about this editorial change in
> this document.

I do not feel strongly about this. This was just a suggestion, which I
would have also given as advice to authors in my own WG as well.

>
>
> Best regards, Tobias
>
>
> __________________________________________
> Tobias Gondrom
> Head of Open Text Security Team
> Director, Product Security
>
> Open Text
> Technopark 2
> Werner-von-Siemens-Ring 20
> D-85630 Grasbrunn
>
>
> Phone: [phone]
> Mobile: [phone]
> Telefax: [phone]
> eMail: mailto:[e-mail]
> Internet: http://www.opentext.com/
>
> Place of Incorporation / Sitz der Gesellschaft: Open Text GmbH,
> Werner-von-Siemens-Ring 20, 85630 Grasbrunn, Germany | Phone: +49 (0) 89
> 4629 0 | Fax: [phone] | Register Court / Registergericht:
> München, Germany | Trade Register Number / HRB: 168364 | VAT ID Number
> /USt-ID: DE 114 169 819 | Managing Director / Geschäftsführer: John
> Shackleton, Walter Köhler
>
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ietf
>


_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf