Last Call Review of draft-ietf-bess-spbm-evpn-01
review-ietf-bess-spbm-evpn-01-secdir-lc-harkins-2015-10-08-00

Request Review of draft-ietf-bess-spbm-evpn
Requested rev. no specific revision (document currently at 02)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-09-29
Requested 2015-09-17
Draft last updated 2015-10-08
Completed reviews Genart Last Call review of -01 by Francis Dupont (diff)
Secdir Last Call review of -01 by Dan Harkins (diff)
Opsdir Last Call review of -01 by Sarah Banks (diff)
Assignment Reviewer Dan Harkins
State Completed
Review review-ietf-bess-spbm-evpn-01-secdir-lc-harkins-2015-10-08
Reviewed rev. 01 (document currently at 02)
Review result Has Nits
Review completed: 2015-10-08

Review
review-ietf-bess-spbm-evpn-01-secdir-lc-harkins-2015-10-08

  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.