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:tgondrom(_at_)opentext(_dot_)com]
Sent: Friday, November 09, 2007 6:02 PM
To: secdir(_at_)mit(_dot_)edu; iesg(_at_)ietf(_dot_)org
Cc: ietf(_at_)ietf(_dot_)org; Mohan, Dinesh (CAR:NP02);
sajassi(_at_)cisco(_dot_)com; sdelord(_at_)uecomm(_dot_)com(_dot_)au;
philippe(_dot_)niger(_at_)francetelecom(_dot_)com
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.
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.
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.
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.
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.
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.
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.
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.
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: +49 (0) 89 4629-1816
Mobile: +49 (0) 173 5942987
Telefax: +49 (0) 89 4629-33-1816
eMail: mailto:tobias(_dot_)gondrom(_at_)opentext(_dot_)com
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: +49 (0) 89 4629 1199 | 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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf