Re: [secdir] SECDIR review of draft-ietf- bess-evpn-usage-07

Alvaro Retana <aretana.ietf@gmail.com> Fri, 02 February 2018 21:22 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1431276AF for <secdir@ietfa.amsl.com>; Fri, 2 Feb 2018 13:22:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 tjuTcf1EQEtf for <secdir@ietfa.amsl.com>; Fri, 2 Feb 2018 13:22:02 -0800 (PST)
Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 528951243FE for <secdir@ietf.org>; Fri, 2 Feb 2018 13:22:02 -0800 (PST)
Received: by mail-ot0-x22c.google.com with SMTP id e64so1755556ote.4 for <secdir@ietf.org>; Fri, 02 Feb 2018 13:22:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=YDhxgViUbeKa7GSv4pzApprDm9j/JrKT62GHJcXe+S8=; b=XfLhQc/izWQs2KT1EaMmPOq1fbH9DeqzLdLNI3wboWWKue+2R0hdmRLLfKeipueWj1 ulVtfeeqMzs6LVWXwix6yGUtknX0emZymLJeyvrTFtFzA+VyqYoWHehYBR4TV0FrGnGr pcsfxcodxvtDMjQ1v+cceLjbUlKg1rkWJa2FdJ94rNIu/QRHPWkkToI4UEkIikAIdJQ9 ejOlocqerdSpb7I9/PojqZgMwnki0OYLVkssDYrMhhgaEXo3TpY4ypglw6lnbcyUEJeR i4wxPBGhQlenn/WKM6pGQaj5YV8e9OifEo7URB1Vb9XNFqvmtm6aadi6SrAPtX/culb8 lQ2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=YDhxgViUbeKa7GSv4pzApprDm9j/JrKT62GHJcXe+S8=; b=WkqfYibZ8+emf9E8hLXSsKP042qYfpCQmNglrY3qTfQyZz3YvL87SipFrwc21Ai73o 0LvLz2dZNz7NODxxoHMvjaPjIgtKAy+siACCqQeLLyYGQpudbsuEz9BSaLmlPWEJ2ZFD kUPCd1Z2Ea4pif6WoECHPhpWqBzZG1U3cPRT0JN3hMitB+Lt1QaWFSX6S3GUJ2XyvWS4 LO5PD70AWS42FgWESBalIQcwb2c79Vl5kocFBrGhvxpT/K5hf3uk0cSR0Q2Z2bMqBBf2 7f/TzUcwgZrthQ5Jk9agxHRDK2IIpGgVP9s74YRDKLzAmHU6EfQwvvoKivL7bBeP3FxR 7mzQ==
X-Gm-Message-State: APf1xPAVTcSLJqMEDsZmrwVi+m28yBbS7o9JS+I/ZcCzovMU7LlwAK7L Sp4KtOOB5b65V/ceqI4YFETusQp+GRDCg+RuzC4=
X-Google-Smtp-Source: AH8x224KaTsKpPaNUmDRpYr9F0Nmjx0T3ff0o5gzkCQJHjbnnk2ePgzyyPIT98TCDntnPUrU8qhA3c51WBrNJbBhS1g=
X-Received: by 10.157.114.150 with SMTP id t22mr3101717otj.164.1517606521773; Fri, 02 Feb 2018 13:22:01 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 2 Feb 2018 16:22:01 -0500
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <e507416e-202b-defb-b8e9-cd3cb75c877a@verizon.net>
References: <e507416e-202b-defb-b8e9-cd3cb75c877a@verizon.net>
X-Mailer: Airmail (467)
MIME-Version: 1.0
Date: Fri, 2 Feb 2018 16:22:01 -0500
Message-ID: <CAMMESsyfe=NL-HwMES5yCUgDhSzkdrN6cpycV3WjNKEJscPo3w@mail.gmail.com>
To: Stephen Kent <stkent@verizon.net>, wim.henderickx@nokia.com, sajassi@cisco.com, uttaro@att.com, jorge.rabadan@nokia.com, stephane.litkowski@orange.com, martin.vigoureux@nokia.com, secdir@ietf.org, senad.palislamovic@nokia.com
Content-Type: multipart/alternative; boundary="94eb2c137f4ea3a17d0564414d1a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/wQh7HZwcjlbLGVGxxo7bxI2IvEE>
Subject: Re: [secdir] SECDIR review of draft-ietf- bess-evpn-usage-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 02 Feb 2018 21:22:04 -0000

On February 2, 2018 at 1:16:28 PM, Stephen Kent (stkent@verizon.net) wrote:

Steve:

Hi!  How are you?

...

Section 10 (Security Considerations) consists of only one sentence, which
refers to the corresponding discussion in RFC 7432. Additional text should
be provided here to explain why this document does not add any new security
considerations. Presumably the rationale is that the provisioning model and
initialization procedures described here are a subset of the more general
discussion in 7432 and thus no new security concerns arise as a result of
this more detailed information. I am not in a position to judge whether
that potential rationale is true.

Fair enough.

I reviewed the Security Considerations section of RFC 7432. It contains
about 1.5 pages of text. The first paragraph there cites security
considerations text in RFCs 4761, 4762, and 4364 and the text there is
generally well-written. However, there is a significant omission, one that
should have been noted in the SECDIR review of that document. Specifically,
7432 cites NONE of the BGP security RFCs produced by the SIDR WG (e.g.,
RFCs 6480-93 et al), even though they preceded publication of that RFC.
Since those documents represented the latest proposals for improving BGP
security at the time, they ought to have been cited and a very brief
discussion of their relevance to EVPN BGP MPLS deployments. I suggest that
this document rectify this omission, i.e., cite several of the BGP secure
origin authentication RFCs, and the recent BGPSec RFCs (8205-11), and note
the relevance of those standards to EVPN BGP MPLS deployments.

The work from sidr doesn’t directly apply to EVPN simply because the ROAs
and BGPSec have been specified only for IPv4/IPv6 and not for the Address
Family used by EVPN.

Maybe a statement like that is what you’re looking for — but I don’t think
it is appropriate to go any further in this document.
Thanks!

Alvaro.