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

"Alvaro Retana (aretana)" <aretana@cisco.com> Wed, 07 October 2015 21:58 UTC

Return-Path: <aretana@cisco.com>
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 020401ACEED; Wed, 7 Oct 2015 14:58:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 7QsDwrNHDWZ7; Wed, 7 Oct 2015 14:58:39 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ABC31AD2F2; Wed, 7 Oct 2015 14:58:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2678; q=dns/txt; s=iport; t=1444255119; x=1445464719; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=cfyBOB66sLpC9qAxD9r2sJrAHnUzIuQhkbBh1oR8Ssc=; b=iM0whzmtZ5C5kqNEIR3QosW5v5EJAkUjyfzcABvPpRbYwoxB1XbCkWOs jHRSVt2VD7+UWtSs6R1okRuj8lw/Vixr3jdmrrrIXU6IQu/NOKNNK0xdq 1mUJvh4rNGpUmnsknfMKA4P7JrC6L6C5rFkIQ/8O5DDLsr0GyUsPsFg/r g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AkAwB/lBVW/5xdJa1egyeBQga9QAENgVqDE4IKZhkCgUc4FAEBAQEBAQGBCoQnAQEDATpPAgEIDigQMiUCBAESiCYIwkwBAQEBAQEBAwEBAQEBARyGcwGEfYUUhC4BBJJNgzgBjRaBV5Yxg28fAQFCghEdgVRxhmaBBgEBAQ
X-IronPort-AV: E=Sophos;i="5.17,651,1437436800"; d="scan'208";a="195002710"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP; 07 Oct 2015 21:58:38 +0000
Received: from XCH-ALN-009.cisco.com (xch-aln-009.cisco.com [173.36.7.19]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t97LwcSW028294 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Oct 2015 21:58:38 GMT
Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-ALN-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 7 Oct 2015 16:58:38 -0500
Received: from xhc-aln-x10.cisco.com (173.36.12.84) by xch-aln-009.cisco.com (173.36.7.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Wed, 7 Oct 2015 16:58:38 -0500
Received: from xmb-aln-x15.cisco.com ([169.254.9.102]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0248.002; Wed, 7 Oct 2015 16:58:37 -0500
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: Dan Harkins <dharkins@lounge.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-bess-spbm-evpn.all@tools.ietf.org" <draft-ietf-bess-spbm-evpn.all@tools.ietf.org>
Thread-Topic: secdir review of draft-ietf-bess-spbm-evpn-02
Thread-Index: AQHRATev8ke0tsxWhkKa2MLJlJDvYJ5gpPKA
Date: Wed, 7 Oct 2015 21:58:37 +0000
Message-ID: <D23B0CDC.D8DC7%aretana@cisco.com>
References: <28535528a17e73ee9a093c8f86a1de3b.squirrel@www.trepanning.net>
In-Reply-To: <28535528a17e73ee9a093c8f86a1de3b.squirrel@www.trepanning.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [64.101.220.142]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <B6B7EA73B924CE48AAB19E81D76FAFBC@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/gW5NONOLfwQLNSZd1HtvxbO2Kz0>
Subject: Re: [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 21:58:44 -0000

On 10/7/15, 3:37 PM, "Dan Harkins" <dharkins@lounge.org> 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.
>
>