Re: [secdir] secdir review of draft-ietf-bess-spbm-evpn-02

["Alvaro Retana (aretana)" <[e-mail]>]

On 10/7/15, 3:37 PM, "Dan Harkins" <[e-mail]> wrote:

Dan:

Hi!

Thanks for your review!

This document was in last week's Telechat and it was already approved for
publication.  We're waiting for the resolution of another point raised
during the IESG review, so while we wait I'll ask the authors to see if
anything can be clarified in the Security Considerations section.

I agree with Barry about the use of rfc2119 language.

Thanks!

Alvaro.

>
>  Greetings,
>
>  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.
>
>  This draft describes how to combine Ethernet Shortest Path Bridging
>MAC mode "islands" with Ethernet virtual private networks to provide
>L2 connectivity between different provider edges. It is extremely
>acronym heavy (e.g. "As with PBB networking the B-VID is local to the
>SPBM network so in SPBM a B-MAC associated with B-VID is advertised
>with the supported I-SIDs at the PBB gateway") and I found myself
>constantly referring to the helpful terminology section.
>
>  After an overview the body of the draft is basically a single
>section  ("4. Elements of Procedure") that states "A PE MUST implement
>and perform the following operations" but none of the following
>subsections contain any normative text. I think some normative
>text is needed in each of the sub-sections, e.g instead of "The
>following is configured..." maybe "The following SHALL be
>configured...").
>
>  Also, the Security Considerations deal with misconfiguration. What
>would happen if there was a bad actor in the mix? A PE appoints
>itself as a designated forwarder (DF). What is the implication of
>such a self-selection being done maliciously? Anything else that
>can happen by intentionally malicious behavior? Is there a potential
>for exposure of the location of MAC addresses of customer equipment?
>Is there some way for something to be put into the EVPN that should
>not be there? If the answer to all this is "nothing" then that's fine
>but it's not clear that malicious behavior was considered when
>writing the Security Considerations.
>
>  I would say the draft is "ready with nits", the nits being my
>request for some normative language in the subsections of section 4,
>and possible added verbage in the Security Considerations if the
>answers above are not "nothing".
>
>  regards,
>
>  Dan.
>
>