[secdir] Secdir review of draft-ietf-l2vpn-pbb-vpls-interop-05

[Matthew Lepinski <[e-mail]>]

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.

Summary: With the exception of the minor editorial issues below, I believe
this document is ready to publish

This is an informational document that describes how to use Hierarchical
Virtual Private LAN Service (H-VPLS) [RFC 4762] with the IEEE's 802.1ah
specification for Provider Backbone Bridging. In particular, the document
lays out four deployment scenarios and describes how the two
technologies inter-operate in each scenario (to achieve better scaling
propertires than one would get without use of 802.1ah).

The authors claim that the use of 802.1ah introduces no security concerns
beyond the general considerations in any H-VPLS deployment, which are
documented in RFC 4762 (and RFC 4111). I am inclined to agree. Although I
don't have a deep enough knowledge of H-VPLS to be certain, I think that
some of the security concerns documents in RFC 4762 (e.g., traffic
isolation and certain kinds of denial of service attacks) are actually
somewhat alleviated through the use of Provider Backbone Bridging.

EDITORIAL COMMENTS:
As someone who does not ordinarily read L2VPN documents, I would find it
very helpful if you could expand each acronym the first time it is used. In
particular, I would have found it very helpful if you had expanded VPLS
when it appears in the first sentence of the introduction. (I also would
have found it quite helpful to include a reference to 4762 early in the
introduction as well.)

Additionally, In understanding the security considerations for this
document, I personally found it very useful to read portions of RFC 4111.
RFC 4111 is referenced by RFC 4762, but I think it would be helpful to
provide a direct reference to RFC 4111 in the security considerations for
this document. (As opposed to just referencing RFC 4762.) This is a small
editorial point, but as a reader, I would prefer a direct link to a
document that is likely to be of interest, as opposed to following a
sequence of references.