IETF Logo Mail Archive

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

Gert Doering <gert@space.net> Wed, 26 April 2017 14:33 UTC

Return-Path: <gert@space.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 2855312EAC0 for <idr@ietfa.amsl.com>; Wed, 26 Apr 2017 07:33:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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 ttH-qqIOUZIL for <idr@ietfa.amsl.com>; Wed, 26 Apr 2017 07:33:37 -0700 (PDT)
Received: from mobil.space.net (mobil.space.net [195.30.115.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DF3412EB57 for <idr@ietf.org>; Wed, 26 Apr 2017 07:28:38 -0700 (PDT)
X-Original-To: idr@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 6141F60BC7 for <idr@ietf.org>; Wed, 26 Apr 2017 16:28:37 +0200 (CEST)
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
X-SpaceNet-Relay: true
Received: from moebius4.space.net (moebius4.space.net [IPv6:2001:608:2:2::251]) by mobil.space.net (Postfix) with ESMTP id 25C3760A24; Wed, 26 Apr 2017 16:28:37 +0200 (CEST)
Received: by moebius4.space.net (Postfix, from userid 1007) id 17DE931D1D; Wed, 26 Apr 2017 16:28:37 +0200 (CEST)
Date: Wed, 26 Apr 2017 16:28:37 +0200
From: Gert Doering <gert@space.net>
To: Robert Raszuk <robert@raszuk.net>
Cc: Gert Doering <gert@space.net>, Jared Mauch <jared@puck.nether.net>, idr wg <idr@ietf.org>
Message-ID: <20170426142836.GV25069@Space.Net>
References: <CA+b+ER=hq0=JNRfF8VA76_aqeRMBCeyQm5aTbapysXGTgaGS_g@mail.gmail.com> <50353B76-1323-4828-88D6-25954DA1E344@puck.nether.net> <20170425221104.GS30063@pfrc.org> <023e01d2be72$031ac180$4001a8c0@gateway.2wire.net> <20170426095547.GP25069@Space.Net> <CA+b+ERk4FxB4KQ3N0xtjV6uaQptd=EGKdpbKcpoL2TH41fVSYg@mail.gmail.com> <20170426113954.GA18318@puck.nether.net> <CA+b+ER=Ej7G1EEOQ7uBU-z7LeBAGNSfPkE5yGmo+z52ncKhVdg@mail.gmail.com> <20170426125417.GU25069@Space.Net> <CA+b+ERm1iDv3+GNk+N_gqjDWsd+E4QjmfhmwDN4vQVQVZ1EMpw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="UkOY2grXPhhol9RY"
Content-Disposition: inline
In-Reply-To: <CA+b+ERm1iDv3+GNk+N_gqjDWsd+E4QjmfhmwDN4vQVQVZ1EMpw@mail.gmail.com>
X-NCC-RegID: de.space
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/LHm42NEqn5VaP2XgyFrkSEXipzo>
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: Wed, 26 Apr 2017 14:33:40 -0000

Hi,

On Wed, Apr 26, 2017 at 03:56:25PM +0200, Robert Raszuk wrote:
> >
> > > And if you are customer and have 4 prefixes in BGP table thing are fine.
> > If
> > > you by accident become transit and advertise fulm table around I think we
> > > can do better in BGP to protect from it then mandate policy.
> >
> > Evidence shows that, as of today, we can not.
> 
> ???Have anyone actually tried ????
> 
> The BGP origin validation was at least one attempt.

How exactly does "BGP origin validation" protect against people leaking
paths they should not?  All the origin ASes are as valid as they were
originally.

("BGP->IGP->BGP redistribution" is not the most common case - in that
latter case, origin validation plus drop invalid would indeed help)

> The other one could be as simple as *"ebgp policy auto"* where based in the
> IRRDB and your peer's AS router can build a policy automagically using say
> BGPQ3.
> 
> http://snar.spb.ru/prog/bgpq3/
> 
> Otherwise while Jared, you and perhaps most folks on this list already have
> automated ways to build nice and accurate policies I suspect they are those
> which do not. And those would either put "allow all" or will now start
> looking for hints "what do I put in".
> 
> And if the end result is what you are doing twice a day why router's can't
> do it themselves assuming IRRDB or any other src of truth is accurate ?

The router certainly could.  But that's a much more sophisticated requirement
than "do not announce anything at all, unless explicitely being told to".

(And then, there's the question of "truth", as soon as certain IRRDBs 
are involved)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

v2.23.0 | Report a Bug | By Email