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 12:54 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 1CDA0129B7F for <idr@ietfa.amsl.com>; Wed, 26 Apr 2017 05:54:31 -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 QXZ0WVBDc9jE for <idr@ietfa.amsl.com>; Wed, 26 Apr 2017 05:54:29 -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 BEA68129B8C for <idr@ietf.org>; Wed, 26 Apr 2017 05:54:22 -0700 (PDT)
X-Original-To: idr@ietf.org
Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 487D760B93 for <idr@ietf.org>; Wed, 26 Apr 2017 14:54:18 +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 15DAC602C8; Wed, 26 Apr 2017 14:54:18 +0200 (CEST)
Received: by moebius4.space.net (Postfix, from userid 1007) id 08077311A5; Wed, 26 Apr 2017 14:54:18 +0200 (CEST)
Date: Wed, 26 Apr 2017 14:54:17 +0200
From: Gert Doering <gert@space.net>
To: Robert Raszuk <robert@raszuk.net>
Cc: Jared Mauch <jared@puck.nether.net>, Gert Doering <gert@space.net>, idr wg <idr@ietf.org>
Message-ID: <20170426125417.GU25069@Space.Net>
References: <0A49219D-E721-4DA8-B9BF-A55C2FA36FBE@puck.nether.net> <D95C67A4-AEBF-400B-A360-61C342FD6E4A@arrcus.com> <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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="Av0raCf5Q1JxibrL"
Content-Disposition: inline
In-Reply-To: <CA+b+ER=Ej7G1EEOQ7uBU-z7LeBAGNSfPkE5yGmo+z52ncKhVdg@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/ksSvF_2UdBdUCIa5ZggukFYjDN8>
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 12:54:31 -0000

Hi,

On Wed, Apr 26, 2017 at 02:00:45PM +0200, Robert Raszuk wrote:
> So let's talk examples ... for my own education.
> 
> If you are provider and have 1000 multihomed customers with v4/v6 PI space.
> 
> Imagine you want to apply granular policy better then permit all on your
> inbound.
> 
> How practically (considering that your customers get address block all the
> time) you wilk track and adjust policy o  a daily basis ?
> 
> You need offline machinery when unless they log in and inform you their
> routes will be denied. Moreover your backend must be able to check if
> prefix does not belong to someone else .... Oh wait what if someone else
> just sold it to them ?
> 
> With PA blocks policy works well ... with PI I think not so.

We do IRRDB lookups twice a day and build prefix- and as-path filters from 
there.  Filters get uploaded to routers if something changes (with some
safety net for "the tool hickupped, and the result is empty").

As do all my upstreams, as we're not buying from networks that cannot
be bothered to do such basic network hygiene.

I consider this industry best practice, even if some large transit ISPs
consider this "too much work" (which is the other end of the BGP leak
problem).

> 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.

"Shooting" would sound like an alternative and very american way to solve 
the issue, but I'm sure that many IETF members would frown on this.

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