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

"Dan Harkins" <dharkins@lounge.org> Wed, 07 October 2015 19:38 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C63B1B2F6A; Wed, 7 Oct 2015 12:38:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.167
X-Spam-Level:
X-Spam-Status: No, score=-1.167 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUPztJQAOTnr; Wed, 7 Oct 2015 12:37:59 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2C01B2F67; Wed, 7 Oct 2015 12:37:59 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id C0A881022404C; Wed, 7 Oct 2015 12:37:58 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 7 Oct 2015 12:37:58 -0700 (PDT)
Message-ID: <28535528a17e73ee9a093c8f86a1de3b.squirrel@www.trepanning.net>
Date: Wed, 07 Oct 2015 12:37:58 -0700
From: Dan Harkins <dharkins@lounge.org>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-bess-spbm-evpn.all@tools.ietf.org
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/c54SsY7hx9ojOcz7TfTF-zrlH8E>
Subject: [secdir] secdir review of draft-ietf-bess-spbm-evpn-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Oct 2015 19:38:00 -0000

  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.