Re: [Idr] IETF LC for IDR-ish document <draft-ietf-grow-bgp-reject-05.txt> (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard

<bruno.decraene@orange.com> Tue, 25 April 2017 10:10 UTC

Return-Path: <bruno.decraene@orange.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA0F12EACB for <idr@ietfa.amsl.com>; Tue, 25 Apr 2017 03:10:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] 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 cFSZKzXgsXRJ for <idr@ietfa.amsl.com>; Tue, 25 Apr 2017 03:10:01 -0700 (PDT)
Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDE85129C1B for <idr@ietf.org>; Tue, 25 Apr 2017 03:10:00 -0700 (PDT)
Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 6B1CE4033C; Tue, 25 Apr 2017 12:09:59 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.72]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 38F5212007B; Tue, 25 Apr 2017 12:09:59 +0200 (CEST)
Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0319.002; Tue, 25 Apr 2017 12:09:58 +0200
From: <bruno.decraene@orange.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>, idr wg <idr@ietf.org>
Thread-Topic: [Idr] IETF LC for IDR-ish document <draft-ietf-grow-bgp-reject-05.txt> (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard
Thread-Index: AQHSvag4/UOdCRuRk06fXrEppErHB6HV1uUg
Date: Tue, 25 Apr 2017 10:09:58 +0000
Message-ID: <6721_1493114999_58FF2077_6721_1006_8_53C29892C857584299CBF5D05346208A31CCB44F@OPEXCLILM21.corporate.adroot.infra.ftgroup>
References: <D4E812E8-AA7B-4EA2-A0AC-034AA8922306@juniper.net> <abe393d3-d1e4-7841-4620-38dab751765b@cisco.com> <CA+b+ERnRz8BEO3mb1fnsDPoiL6Wxjdfw9vQPbyODNEa+xCJdnw@mail.gmail.com> <D51D67E4.A9782%acee@cisco.com> <AF07526F-F08B-4084-937B-A9A2D2DD2813@juniper.net> <D51D6AD2.A9795%acee@cisco.com> <CAL9jLaa1UQ5A1FwRKVw5RJCBQO+0j0BW4vUNaPXHB0_JB0j76Q@mail.gmail.com> <1058_1493105140_58FEF9F4_1058_786_3_53C29892C857584299CBF5D05346208A31CCAD43@OPEXCLILM21.corporate.adroot.infra.ftgroup> <alpine.DEB.2.02.1704250930500.5591@uplift.swm.pp.se> <20393_1493106881_58FF00C1_20393_19903_1_53C29892C857584299CBF5D05346208A31CCAEB1@OPEXCLILM21.corporate.adroot.infra.ftgroup> <alpine.DEB.2.02.1704251000070.5591@uplift.swm.pp.se> <9917_1493109125_58FF0985_9917_13726_10_53C29892C857584299CBF5D05346208A31CCB014@OPEXCLILM21.corporate.adroot.infra.ftgroup> <alpine.DEB.2.02.1704251137160.5591@uplift.swm.pp.se>
In-Reply-To: <alpine.DEB.2.02.1704251137160.5591@uplift.swm.pp.se>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/RUqQJ7JLl-I74hfzJMuSmaUIfX8>
Subject: Re: [Idr] IETF LC for IDR-ish document <draft-ietf-grow-bgp-reject-05.txt> (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Apr 2017 10:10:04 -0000

> From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]  > Sent: Tuesday, April 25, 2017 11:42 AM
> 
 > On Tue, 25 Apr 2017, bruno.decraene@orange.com wrote:
 > 
 > > My reading would be "Implementations which by default advertise all
 > > their BGP routes over an EBGP session plus have a CLI not allowing the
 > > EBGP session and its associated policy to be configured atomically
 > > create frequent involuntary route leaks in the Internet, including in
 > > the absence of any configuration error. Possibly, this may be only one
 > > part of the problem, but here would be a good document to explicit those
 > > operational issues. (rather than complying that IDR do not listen to
 > > operational feedback)
 > 
 > https://tools.ietf.org/html/rfc7908 already documents the problem with
 > "route leaks". What you're asking for is as far as I can tell already
 > documented there.

If the problem is route leak (which is indeed a problem to solve):
- draft-ietf-grow-bgp-reject is unfortunately not a solution to route leak. There is nothing to check/unsure that the route advertised/received are the "right" ones.
-  IDR is already working on solutions which seem to have a better coverage. e.g. latest IDR meeting:

     2) Route Leak Prevention using Roles in Update and Open messages [Alexander Azimov/Randy Bush] (10) 
     https://datatracker.ietf.org/doc/draft-ymbk-idr-bgp-open-policy/
     
     3) Route Leak Detection and Mitigation [Sriram] (10)
     https://tools.ietf.org/html/draft-ietf-idr-route-leak-detection-mitigation-06   


So if the problem is route leak, draft-ymbk-idr-bgp-open-policy seems a better solution to me.
Eventually, it could include some idea from draft-ietf-grow-bgp-reject. .e.g.  by introducing a  "semi-strict mode" or "safe mode": if set, and if the "role" capability is not received from the peer, then EBGP speaker MUST behave has per bgp-reject (i.e. not advertising/receiving routes, unless a policy is explicitly configured)

Thanks,
Regards,
--Bruno

 
 > Perhaps not the *WHY* (as in operator error in configuring things
 > correctly), but that's exactly what draft-ietf-grow-bgp-reject is about.
 > 
 > --
 > Mikael Abrahamsson    email: swmike@swm.pp.se

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.