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

Jared Mauch <jared@puck.Nether.net> Tue, 25 April 2017 21:09 UTC

Return-Path: <jared@puck.nether.net>
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 E94BA129443 for <idr@ietfa.amsl.com>; Tue, 25 Apr 2017 14:09:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 B6xGzlLINE-o for <idr@ietfa.amsl.com>; Tue, 25 Apr 2017 14:09:46 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id A6B541252BA for <idr@ietf.org>; Tue, 25 Apr 2017 14:09:46 -0700 (PDT)
Received: by puck.nether.net (Postfix, from userid 162) id 69D62540A9D; Tue, 25 Apr 2017 17:09:46 -0400 (EDT)
Date: Tue, 25 Apr 2017 17:09:46 -0400
From: Jared Mauch <jared@puck.Nether.net>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: bruno.decraene@orange.com, idr wg <idr@ietf.org>
Message-ID: <20170425210946.GB17347@puck.nether.net>
References: <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> <6721_1493114999_58FF2077_6721_1006_8_53C29892C857584299CBF5D05346208A31CCB44F@OPEXCLILM21.corporate.adroot.infra.ftgroup> <alpine.DEB.2.02.1704251211420.5591@uplift.swm.pp.se>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.02.1704251211420.5591@uplift.swm.pp.se>
User-Agent: Mutt/1.8.0 (2017-02-23)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/BdroO6gxuriwDV-plkm_NxjtMR0>
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 21:09:48 -0000

On Tue, Apr 25, 2017 at 12:15:34PM +0200, Mikael Abrahamsson wrote:
> On Tue, 25 Apr 2017, bruno.decraene@orange.com wrote:
> 
> > 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.
> 
> Errr... It's a solution to ONE huge glaring reason for some route leaks.
> 
> > There is nothing to check/unsure that the route advertised/received are
> > the "right" ones.
> 
> The problem draft-ietf-grow-bgp-reject tries to solve is when lack of config
> means you're announcing ALL your routes. So yes, you're technically correct,
> but I don't see the relevance.
> 
> > So if the problem is route leak, draft-ymbk-idr-bgp-open-policy seems a better solution to me.
> 
> It's not even an WG document. When will it be done?
> draft-ietf-grow-bgp-reject is short, concise and to the point, and easily
> understandable and can be adopted quickly.
> 
> > 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
> 
> The whole problem draft-ietf-grow-bgp-reject tries to solve is that people
> are leaking routes WITHOUT SETTING ANYTHING. They're just creating the
> neighbor and then *boom* entire BGP table is sent.

	In private at least one vendor has now conceded this is a bad thing
and is trying to fix it, that's progress.

	I'm looking forward to when BGP starts as secure out of the box
as many other protocols, such as SMTP, etc.

	- Jared

-- 
Jared Mauch  | pgp key available via finger from jared@puck.nether.net
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.