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

From: "Dan Harkins" <[email-masked]>
Date: Wed, 7 Oct 2015 12:37:58 -0700 (PDT)

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.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 7 Oct 2015 13:02:44 -0700

Hi, Dan, and thanks for the SecDir review.

> following is configured..." maybe "The following SHALL be

I've seen similar comments about other documents, and I find it
troubling that we often consider that the only statements that are
normative are ones that include 2119 key words.  I think that is not
at all so, and that what we say in a standards document *is* normative
unless we say otherwise.

I have not yet reviewed this document, so I might see it differently
when I do, but I've just taken a look at Section 4.1 to see Dan's
example.  I don't see why anything needs to be changed: the text, as
it is, is clear that the specified items have to be configured.  What
would adding "SHALL" or "MUST" change here?  Does the existing text
seem to give anyone any options here?  As I read the current text, if
I fail to include a route target or an SPSourceID in the
configuration, I am not complying with this specification.

Now, I generally think we overuse 2119 key words, so that's where I'm
starting from.  But honestly: how does adding 2119 key words to
Section 4.1 improve it?

Barry

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 7 Oct 2015 21:58:37 +0000

On 10/7/15, 3:37 PM, "Dan Harkins" <[email-masked]> 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.

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 8 Oct 2015 00:08:43 -0700 (PDT)

Hi Barry,

> at all so, and that what we say in a standards document *is* normative

  The problem is the passive voice does not instruct implementations
properly.

> configuration, I am not complying with this specification.

  The _overview_ (which is arguably informative) has more normative
statements than the body of the draft that is supposed to instruct
implementations in how to behave! And the body of the draft says that
implementations MUST do a collection of passive-voiced and conditional
behavior.

> starting from.  But honestly: how does adding 2119 key words to

  It alerts an implementer to something he or she needs to pay
attention to because it has interoperability implications.

  If nothing in subsections 4.1 to 4.8 need normative text then get
rid of the RFC 2119 word in section 4 that compels an implementation
to behavior that is passive-voiced and conditional.

  Overuse of RFC 2119 key words may be attracting your attention
but the issue here is not an overuse but a dearth of them. On the
other hand, if you're so concerned about overuse of RFC 2119 words
then maybe you should make a comment on this draft that putting
such normative statements in something like an informative overview
is not appropriate. If RFC 2119 words are not necessary when describing
the protocol behavior then they are certainly not necessary in an
informative overview. And therefore there is no reason to reference
RFC 2119 in this Standards Track RFC.

  Dan.