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

"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com> Wed, 16 January 2019 06:49 UTC

Return-Path: <jorge.rabadan@nokia.com>
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 F01F11310E4; Tue, 15 Jan 2019 22:49:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.453
X-Spam-Level:
X-Spam-Status: No, score=-6.453 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 OboTFCSr1DbK; Tue, 15 Jan 2019 22:49:54 -0800 (PST)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on071d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::71d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3FB012F1AC; Tue, 15 Jan 2019 22:49:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PK25L0kxAamq1Ch/1MYV+fxgPnXy+sdviniS2jS+BKg=; b=daFTdc34Cu44w41EumMbIqgRojGLgvvO6jb4gpIN0sLUHb+1z7U1T/NzHwrJqmUjxdPWEg6TDbKcGy3k8APo1JL9DkNa30ZC6pLC+A21FKDGIssHhxVw30dtrDEhlwxmp0Z35dFam83bqGaP+55KlopErkmk0Q4SGKYeojSP7Ls=
Received: from AM0PR07MB3844.eurprd07.prod.outlook.com (52.134.82.20) by AM0PR07MB5155.eurprd07.prod.outlook.com (20.178.19.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1537.18; Wed, 16 Jan 2019 06:49:50 +0000
Received: from AM0PR07MB3844.eurprd07.prod.outlook.com ([fe80::a043:32e8:b786:3486]) by AM0PR07MB3844.eurprd07.prod.outlook.com ([fe80::a043:32e8:b786:3486%5]) with mapi id 15.20.1537.018; Wed, 16 Jan 2019 06:49:50 +0000
From: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>
To: "Luc Andre Burdet (lburdet)" <lburdet@cisco.com>, "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
CC: Stephane Litkowski <stephane.litkowski@orange.com>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, The IESG <iesg@ietf.org>, "bess@ietf.org" <bess@ietf.org>, "draft-ietf-bess-evpn-df-election-framework@ietf.org" <draft-ietf-bess-evpn-df-election-framework@ietf.org>
Thread-Topic: [bess] Mirja Kühlewind's No Objection on draft-ietf-bess-evpn-df-election-framework-07: (with COMMENT)
Thread-Index: AQHUqNXpNXzO3DF7MEGEF5HUTuJwLKWwSc4AgAA6GwCAAAlFgIABAUQA
Date: Wed, 16 Jan 2019 06:49:50 +0000
Message-ID: <47D96460-C10B-430A-9761-9D77201D8C5B@nokia.com>
References: <154711897687.30744.6994568426872803131.idtracker@ietfa.amsl.com> <9E27CDD8-B8F8-4B81-8FA5-430C7D874CF7@nokia.com> <47819DA3-C02C-42E0-A796-FCA962D026B8@kuehlewind.net> <2E5E9EEA-652C-44DE-8357-3AEA7C4045E6@cisco.com>
In-Reply-To: <2E5E9EEA-652C-44DE-8357-3AEA7C4045E6@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.15.0.190115
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jorge.rabadan@nokia.com;
x-originating-ip: [83.51.41.76]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR07MB5155; 6:NCmT+ruK1pDMoIk87FhTKyMYYeoZRjbUafbx4+y0pB7OeFEAsyYA1l0TwG5+K/jtRh0aFPGlwX9NCGKb1ZXe4m949FHkzIRP1ok14EEV2PJ5W84ChJ2TM2MO+HohhuRtw+Tdajo1IBHj0hDsr9SY4ScelZDy7n3rxVoV0/h7ntaq8Gm9uVL4WtVpQ/19rn4i82Q6VGX9tvuutgdQG3vXVFRnFzYpTPA8mQy6WjyoEO79Y84TgFQ9FULIxdrx7kC6A1XiP4snsuK6wpBn0J9sj3w/qSv9l+ignJ89FZ6BbF/nJmTZC+ouWjjivgpngk1tDm5KHpoZmjnBRv3yT9BnjHbF3bYMSIqi2pYt6fsq4NVuOFAd3odaZZg0HOo1W2O/NBJYYY16AbuwRqYK5ce4FJY0/cw0fqh++wJ5ORi5Dgi8iS1IIlAZP/sYTnM4yrH+r0M71qNLxbLCNExdCVDK5A==; 5:Y0el2ArmDRGZeGEwcXUSJNpD/GIJ0RvkMXbgd/+Gn7ZUTt2cbH6C5qn53DOAw2YXuN1YzUZRYrJRbEczvVUTIfTCfxkSe8zSEcYmlk2gPhWTv/ueNSUdLj5v/JhEml7rWvu9PGN6ouYgzEZfUm9setDbILvIMT2qjS3zMeHHJjEK+YTCisngCKfdQfZZ/GNx4N4RL0wr0feYCgeM5mMqow==; 7:heh+ahICZjB6viLB4Z/UBq+lWmhnnZu4XckNZuqWoaqXRAAwnBMF1Ts9ppWtcF2crJsGMmQbDOD5mxPeN2sJZnFWqo0oqczyixSK+GHGo5S5It715N4GBtEEICUy/mYjDN9q2qsddslEGZn1oOV0Uw==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 76e037b0-3fd6-4aac-4695-08d67b7ed020
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600109)(711020)(4618075)(2017052603328)(7193020); SRVR:AM0PR07MB5155;
x-ms-traffictypediagnostic: AM0PR07MB5155:
x-microsoft-antispam-prvs: <AM0PR07MB5155DDDB0A3F06E6182F946CF7820@AM0PR07MB5155.eurprd07.prod.outlook.com>
x-forefront-prvs: 091949432C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(396003)(366004)(346002)(136003)(189003)(199004)(13464003)(53936002)(6486002)(54906003)(14454004)(58126008)(106356001)(6436002)(71190400001)(229853002)(966005)(316002)(71200400001)(83716004)(6512007)(478600001)(6116002)(110136005)(86362001)(6246003)(105586002)(6306002)(68736007)(93886005)(3846002)(66574012)(81156014)(224303003)(81166006)(8936002)(33656002)(14444005)(99286004)(256004)(486006)(224313004)(76176011)(6506007)(4326008)(82746002)(36756003)(186003)(25786009)(7736002)(2906002)(476003)(5660300001)(11346002)(2616005)(53546011)(102836004)(97736004)(66066001)(305945005)(26005)(446003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB5155; H:AM0PR07MB3844.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: CH82pyf13QvLCVgtgljdiCnISi529WF/DebZbHpWHYlwtjqQCLS4vEQtY0/Xr/KpRBdn5w3KGNPoVen+/Trqgq7bFwfw9IifSbCsk2V6RzEhYgmWOI8lWG5nWxjSlGG5C68UkIiUkwIqXA06uj9XdgW6VVpCZvX9s/Yrc2o/WQoWo6u8gstUDgbSg+KpraUZSA7G4kz3/R6hWmEDS9wkZ0+7DnUB9iV83MzflwT4kDFw0m/WESXfRqjSw0Xvfex/goL34CfQR/kj/FpbaGuC6GxAA6rK7hsdXpz7ulRMRzWmP8RM5N2U4TR9GRVL5HeQ+wzLaHxX2c5xx+Ni3wuwTtjWjZl4EmMUH5ezcpO26ikpPCzG34lDymB3wo3RI2N0qwAbbqL/S4pIxJRgy9J0EBGAt+ljYY63cqT4hKKHLnE=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <05A1B16C5E005540ABCE1938A1B767FF@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 76e037b0-3fd6-4aac-4695-08d67b7ed020
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Jan 2019 06:49:50.6515 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB5155
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/KIbI0GZIOjyfcAJ9mcSwj2OFMgg>
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: Wed, 16 Jan 2019 06:49:57 -0000

Hi Mirja and Luc,

Mirja, I added this in the security section:

"...This behavior could be exploited by an attacker that manages to modify the configuration of one PE in the Ethernet Segment so that the DF Election Alg and capabilities in all the PEs in the Ethernet Segment fall back to the Default DF Election. If that is the case, the PEs will be exposed to the unfair load-balancing, service disruption and black-holing that were mentioned earlier."

Other than that I agree with Luc that the injection of a malicious route type 4 in the network is not specific to this document, so I think we should be ok since we are also referring to the security considerations in RFC7432.

Thanks.
Jorge


-----Original Message-----
From: "Luc Andre Burdet (lburdet)" <lburdet@cisco.com>
Date: Tuesday, January 15, 2019 at 5:29 PM
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>
Cc: Stephane Litkowski <stephane.litkowski@orange.com>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, The IESG <iesg@ietf.org>, "bess@ietf.org" <bess@ietf.org>, "draft-ietf-bess-evpn-df-election-framework@ietf.org" <draft-ietf-bess-evpn-df-election-framework@ietf.org>
Subject: Re: [bess]  Mirja Kühlewind's No Objection on draft-ietf-bess-evpn-df-election-framework-07: (with COMMENT)

    That's an interesting point Mirja.
    
    A rogue PE/agent could foreseeably inject via BGP an ES Route Type 4 with no DF Alg extended community and "bring down" a peering group to the default DF election (common denominator). Repetitive inject-delete could cause considerable churn and disruption as the target peers repetitively accept, and remove this rogue PE/nexthop from the forwarding determination and flip-flop DF Alg.
    
    The only way to prevent this, would be for the "federation of peers" to (independently) come to a unanimous conclusion to accept, or reject, this new peer into their peering group (based on.. peer's reputation? Or?) In the end, however, ...this also applies to 7432 as-is with default algorithm.
    The net effect of such an attack would be no different than RFC7432 where a rogue PE injecting/deleting itself (its nexthop) from the DF election is causing churn and disruption.
    
    The other attack vector is not new to this draft, but from 7432. A rogue PE with knowledge of the {VLAN/VPN, ESI and peers-list} can conceivably advertise in BGP the correct IP/nexthop value, leveraging the default DF Alg to steer/attract VPN traffic towards himself. But this is a 7432 attack vector, not new/introduced by this draft.
    
    I think if the draft reflects similar to 7432 (peers must be consistently configured), then parallels to the security aspect of 7432 are sufficient?
    
    Thanks,
    
    Luc André Burdet
    lburdet@cisco.com
    Tel: +1 613 254 4814
    Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE
    Cisco.com <http://www.cisco.com/web/CA/>
     
    
    On 2019-01-15, 10:57, "BESS on behalf of Mirja Kuehlewind (IETF)" <bess-bounces@ietf.org on behalf of ietf@kuehlewind.net> wrote:
    
        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)."
        > 
        > 
        > 
        > 
        > 
        > 
        
        _______________________________________________
        BESS mailing list
        BESS@ietf.org
        https://www.ietf.org/mailman/listinfo/bess