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

Warren Kumari <> Wed, 26 April 2017 19:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 423C81289C3 for <>; Wed, 26 Apr 2017 12:18:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id boiP-oBB4YSd for <>; Wed, 26 Apr 2017 12:18:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7CABA1205F1 for <>; Wed, 26 Apr 2017 12:18:30 -0700 (PDT)
Received: by with SMTP id y63so9779963qkd.1 for <>; Wed, 26 Apr 2017 12:18:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4M4e9J6mmy25RWkWDpTi+h8Vv6LPYrf30J1syA+l/DE=; b=WozoF5yWypKx1T04FmJJ9ME9gyKfHdMx+7RhL8RVyfz9WZG2EN/AXOVqSDzj3hJWHI GG25/DkliCzubksDYCTVOj4ebaW2Uyu2JXx+L71q9Vn1MUs7nP+FLvbTGLbNPQU2dZLF ZZcCxclQBqVmJnELz7v+k6okfFJLpk5+mMpKyxrfb5Q5zmbDYh4W8f4yd1OsmS9BlhKm NSZD6eLupMt7IRcAwEC6/SarHGknNDmC+8LjCdIQ5rCpGUms8s867pSahRmXeHb2jHW4 rhX6fXaQN7GGK09/K+Vq91ClQo7VjMs7H7EXyjdieIakZ4QZNZ9QT1t+Y1J03qHr7VqY w1AA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4M4e9J6mmy25RWkWDpTi+h8Vv6LPYrf30J1syA+l/DE=; b=R6xY4MDEf2L9hGOcdFua9eMEGjrnm5ti3ix3QcFSgzEfRFZPFPHs6RJVrsdXovbAcT 50v3dUpw5flqJzGY1ZWE6N4R1kH0iHhQiH0zgJJJMRoeKalbLwfPZWGA21upSQ4mz1JE qkzLoPBvHlkahHDon/M0/2YT/k0KrRiDMLeVF0PWc60xxTOwJy5g/byRs1LzMq8YX9Ap icIwvLv2oCY92lGMLsA4+ZGnzqckW1LcAxI6Vt44pO9cIbA6HWx2vKr3cPV+sqYxlo8u r9b98cPpIpR5KDEMzQDdD+qyOnPuEEQ6yN0GW6oIu/4KH+N32YROxuPFYS6X0AWbYmFE 6j9Q==
X-Gm-Message-State: AN3rC/4A5oOUV763d9hkhx76UONko2A4T1FGHASW5QXQmVlR0bqvBUNn sGT0oZZPHbJ+8XHhDnCKxPd8CNRw9I4SrPg=
X-Received: by with SMTP id q129mr1495797qka.21.1493234309352; Wed, 26 Apr 2017 12:18:29 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 26 Apr 2017 12:17:48 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <023e01d2be72$031ac180$> <20170426095547.GP25069@Space.Net> <> <> <> <20170426125417.GU25069@Space.Net> <> <>
From: Warren Kumari <>
Date: Wed, 26 Apr 2017 15:17:48 -0400
Message-ID: <>
To: Christopher Morrow <>
Cc: Robert Raszuk <>, idr wg <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
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-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Apr 2017 19:18:32 -0000

On Wed, Apr 26, 2017 at 10:08 AM, Christopher Morrow
<> wrote:
> On Wed, Apr 26, 2017 at 9:56 AM, 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.
> origin validation doesn't protect against 'accidentally i became transit,
> whoops!' mistakes.

... and I suspect that basically everyone who actually run networks
have done this (and probably more than once.)

My first time was in around 1997 or so - I managed to become transit
(on my Cisco AGS+!) between Global Naps and (IIRC) PSI.

I was turning up Global Naps as a peer, so I log on and type:
router bgp 8120
neighbor peer-as 1784

... and, as I press enter, one of the sysadmin folk turns around and
asks me to hand him a sharpie. While doing so I bump my coffee mug,
spilling 3 week old coffee (and a very cool mold colony I was
culturing) all over my desk. What with the cursing and running to find
paper towels and similar I don't come back to the router for a minute
or two... by which time I can mysteriously no longer reach it. Turns
out that becoming transit between 2 (at the time) large providers over
a T1 makes your router unavailable. Eventually BGP falls down (because
keepalives get starved), and then, before you are able to login again,
it comes up.

Stuff like this happens all the time - bringing peers up without
policy is a: really easy to accidentally do and b: hurts both the
person doing it, and everyone caught in the collateral damage.

> bgpsec also doesn't protect against this scenario.
> There have been a few years worth of papers/analysis out of academia (and at
> least 2 drafts in the ietf) talking about the above.
>> 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.
> are you suggesting that the router build it's filtering directly (on it's
> own) from an IRRdb? that seems interesting, but also fraught with peril...
> I also see problems in setting up the configuration parts for this, for a
> single network it probably isn't rough, but for a more generic solution it's
> going to involve more configuration toggling than just enabling a policy on
> the peerings. At least you'd need to account for:
>   1) which irrdb to pull content from
>   2) which protocol to use to do that pulling
>   3) authentication?
>   4) results qualifications (larger than X, smaller than Y, general content
> sanity)
>   5) how to match/query the irrdb for the particular peerings on this device
>   6) timeouts for operations
>   7) scheduling of operations
>   8) security bits around the new 'service' enabled on this device
> there are other things to account for as well...

   9) making sure that you have announced just enough (and received)
just enough that you can actually reach the irrdb

I'm saddened that something which is basically a trigger safety to
make it harder to shoot myself in the foot is this hard....


> that's very vendor specific :(
>> 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".
> vendors who sold gear could probably offer solutions in this space.
>> 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 ?
> 'how often does this data change?'
> 'how often do I want to refresh peering data on devices (from neighbors)'
> 'what is the sla for this part of the service'
> Some folk do it more 'dynamically' (some providers update 4 or 6 times day),
> some folk do it 'less dynamically' (email .. data updated
> in 24hrs)
> 'why not do it more!' has lots of reasons in both directions, but really
> that's not the point of this draft anyway.
> _______________________________________________
> Idr mailing list

I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.