Re: [secdir] secdir review of draft-li-pwe3-ms-pw-pon-04

[Stewart Bryant <[e-mail]>]

Glen

Thank you for the review.

On 28/08/2011 13:38, Glen Zorn wrote:
> 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 have virtually no knowledge of MPLS and no desire to acquire any.  I
> do know a little bit about PON, probably enough to be dangerous.  For
> these reasons I will not comment upon the technical aspects of the
> document, instead limiting my comments to editorial issues and the
> Security Considerations section.  I do have one general question,
> though: just out of curiosity, why is this not a pwe3 WG document?
>
>
> EDITORIAL
>
> Abstract
>
> The acronym "MPLS" should be expanded on first use
>
> s/an MPLS Packet Switched Network/a MPLS Packet Switched Network/
"MPLS" is an IETF "well known term" hence expansion is  not mandatory.
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt

> It is sometimes lamented that the people writing the IETF standards are
> most often not the people implementing said standards.  I think that
> this may actually be a blessing in disguise, however: if the people
> writing the standards really don't know the difference between a pointer
> to an object (e.g, "[RFC3985]") and the object itself (RFC 3985), I
> don't want them writing code!
Actually I just cross checked this with a random recent RFC and it
conforms to the current style. I think we need to leave it to the
RFC editor to decide.
>
> Section 7.1
>
> The references to  G.987 and G.987.3 are formatted differently from
> those for the other ITU-T documents
Yes, perhaps the authors can pick this up on the next pass.
> The references for RFC 3031, RFC 4447 and RFC 5036 are formatted
> incorrectly (leading '"' and trailing '".' characters).
Yes, perhaps the authors can pick this up on the next pass.
>
> SECURITY CONSIDERATIONS
>
> This section seems woefully inadequate to me.  It is a single paragraph,
> reproduced in full (with interspersed commentary) below.
>
>     G-PON/XG-PON has its own security mechanism to guarantee each ONU is
>     isolated on the G-PON/XG-PON link layer.
>
> Where is the G-PON security mechanism defined?  Presumably in one of the
> 6 ITU-T standards referenced, but which one?
See below I propose a couple of references.
>
>     Other security issues are
>     unchanged from those applying as standard to PWs and MS-PWs.  Please
>     refer to the referenced architectures and protocol specifications for
>     further details.
>
> One of the referenced architectures, specified in RFC 3895, says
>
>     It is outside the scope of this
>     specification to fully analyze and review the risks of PWE3,
>     particularly as these risks will depend on the PSN.  An example
>     should make the concern clear.  A number of IETF standards employ
>     relatively weak security mechanisms when communicating nodes are
>     expected to be connected to the same local area network.  The Virtual
>     Router Redundancy Protocol [RFC3768] is one instance.  The relatively
>     weak security mechanisms represent a greater vulnerability in an
>     emulated Ethernet connected via a PW.
>
> This seems to me to specifically assign risk analysis and review of
> novel pseudowires (which this would seem to be) to the designers of
> such, but this draft does not show any evidence of that analysis.
>
This draft is not describing a PW type, but a method
of using a new PSN type in a MS-PW. The security issues
associated  with a specific PW type is dealt with in the
PW encapsulation spec for that PW type. These are
out of scope of this draft.

Thus the focus of the security section needs to be on any
increased risk associated with using a PON rather than
an MPLS segment. Looking at the references provided by
the author, PON seems to be at least as good as MPLS
when running over a secure datalink.

Can propose the following revised security section:
This document describes a variation of a multi-segment pseudowire
running over an MPLS PSN, in which one or both of the MPLS PSNs
that provide connectivity between a T-PE and its associated S-PE
is replaced by a G-PON/XG-PON PSN. The security considerations that
apply to the PW itself[RFC3985][RFC4385] are unchanged by this
change in PSN type. For further considerations of PW security
see the security considerations section of the specific
PW type being deployed.

G-PON/XG-PON [G.987.3][G.984.3]includes security mechanisms
that are as good as those provided in a well
secured MPLS PSN. The use of a G-PON/XG-PON PSN in
place of an MPLS PSN therefore does not increase the
security risk of a multi-segmnet pseudowire.

- Stewart