Re: [bess] Mirja Kühlewind's No Objection on draft-ietf-bess-evpn-df-election-framework-07: (with COMMENT)

"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Tue, 15 January 2019 15:56 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C03130E95; Tue, 15 Jan 2019 07:56:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 5C4H5p16sqGv; Tue, 15 Jan 2019 07:56:01 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 4F174130E98; Tue, 15 Jan 2019 07:56:01 -0800 (PST)
Received: from ict-networks-2001-067c-10ec-5785-8000-0000-0000-0430.fwd-v6.ethz.ch ([2001:67c:10ec:5785:8000::430]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1gjR4D-000871-Li; Tue, 15 Jan 2019 16:55:53 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <9E27CDD8-B8F8-4B81-8FA5-430C7D874CF7@nokia.com>
Date: Tue, 15 Jan 2019 16:55:52 +0100
Cc: The IESG <iesg@ietf.org>, "draft-ietf-bess-evpn-df-election-framework@ietf.org" <draft-ietf-bess-evpn-df-election-framework@ietf.org>, Stephane Litkowski <stephane.litkowski@orange.com>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <47819DA3-C02C-42E0-A796-FCA962D026B8@kuehlewind.net>
References: <154711897687.30744.6994568426872803131.idtracker@ietfa.amsl.com> <9E27CDD8-B8F8-4B81-8FA5-430C7D874CF7@nokia.com>
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1547567761;b87abbf0;
X-HE-SMSGID: 1gjR4D-000871-Li
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/ZK0wV4oqXum8CUngUC1lIEBlXMU>
Subject: Re: [bess] Mirja Kühlewind's No Objection on draft-ietf-bess-evpn-df-election-framework-07: (with COMMENT)
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Jan 2019 15:56:15 -0000

Hi Jorge,

thanks! I guess the security consideration could say even more, e.g. that this behavior could be exploited by an attack that relies on the default mechanism. And is there anyway to hinder this attack? That should be discussed as well.

Mirja

 

> Am 15.01.2019 um 16:49 schrieb Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com>:
> 
> Mirja,
> 
> Thank you very much for reviewing.
> Please see in-line with [JORGE].
> Thx
> Jorge
> 
> -----Original Message-----
> From: Mirja Kühlewind <ietf@kuehlewind.net>
> Date: Thursday, January 10, 2019 at 12:16 PM
> To: The IESG <iesg@ietf.org>
> Cc: "draft-ietf-bess-evpn-df-election-framework@ietf.org" <draft-ietf-bess-evpn-df-election-framework@ietf.org>, Stephane Litkowski <stephane.litkowski@orange.com>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, "bess@ietf.org" <bess@ietf.org>
> Subject: Mirja Kühlewind's No Objection on draft-ietf-bess-evpn-df-election-framework-07: (with COMMENT)
> Resent-From: <alias-bounces@ietf.org>
> Resent-To: <jorge.rabadan@nokia.com>, <satyamoh@cisco.com>, <sajassi@cisco.com>, <jdrake@juniper.net>, <kiran.nagaraj@nokia.com>, <senthil.sathappan@nokia.com>
> Resent-Date: Thursday, January 10, 2019 at 12:16 PM
> 
>    Mirja Kühlewind has entered the following ballot position for
>    draft-ietf-bess-evpn-df-election-framework-07: No Objection
> 
>    When responding, please keep the subject line intact and reply to all
>    email addresses included in the To and CC lines. (Feel free to cut this
>    introductory paragraph, however.)
> 
> 
>    Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>    for more information about IESG DISCUSS and COMMENT positions.
> 
> 
>    The document, along with other ballot positions, can be found here:
>    https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-df-election-framework/
> 
> 
> 
>    ----------------------------------------------------------------------
>    COMMENT:
>    ----------------------------------------------------------------------
> 
>    First one minor editorial comment:
>    Sec 3.2 "Otherwise if even a single advertisement for the type-4 route is
>           not received with the locally configured DF Alg and capability,
>           the Default DF Election algorithm (modulus) algorithm MUST be
>           used as in [RFC7432]."
>    I believe you meant a single advertisement is received without the configured
>    DF Alg and capability (or a different one I guess), and not that the
>    advertisement is not received at all (because that might be hard to check),
>    right? Maybe you can rephrase this sentence a bit to make the intention more
>    clear!
> [JORGE] we changed it to the following:
> " - Otherwise if even a single advertisement for the type-4 route is received without the locally configured DF Alg and capability, the Default DF Election..."
> 
>    However, think about this further, I wondering if there is something here that
>    such be discussed in the security considerations, e.g. how easy would it be for
>    an attacker to disturb the algo selection and cause a fallback to the default
>    scheme...?
> [JORGE] yep, good point. We added this in the security section, also based on the comments from another reviewer:
> "Note that the network will not benefit of the new procedures if the DF Election Alg is not consistently configured on all the PEs in the ES (if there is no unanimity among all the PEs, the DF Election Alg falls back to the Default [RFC7432] DF Election)."
> 
> 
> 
> 
> 
>