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 <warren@kumari.net> Thu, 27 April 2017 19:30 UTC

Return-Path: <warren@kumari.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 23CDD129C26 for <idr@ietfa.amsl.com>; Thu, 27 Apr 2017 12:30:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 onUBbkEpNlqq for <idr@ietfa.amsl.com>; Thu, 27 Apr 2017 12:30:01 -0700 (PDT)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E1A7129477 for <idr@ietf.org>; Thu, 27 Apr 2017 12:26:53 -0700 (PDT)
Received: by mail-qk0-x229.google.com with SMTP id h123so36280775qke.0 for <idr@ietf.org>; Thu, 27 Apr 2017 12:26:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q1pviIH8yw0ihQzWZ657WYAB5FmzN9Ix5+pDNIZU+aY=; b=Yu4a0ZxenPocNEUaeXNACu2l2QUdHDdypvZ3aSTsW40qDkrYZkM0f5ltAuCXbx6pIH v00nTUzarbE08A8N2rerBvrVeilOmCFCopdDFnktUbk5mPjG7p4Gc5WQu8iXebSgaOS/ 7oEl8ttABtu64rZZ2mFipquvytqu32lCzZXMnTUEHGK+tHTeZ8zSCbQWMMA7yLVlm4AM oKt0lOAhtgYxoWvQ0TruW1//QesBHZoYPCzrn1l1wOUKNgNu8oMHFP6iSYNQa2mH2K5j RMdqg/OlWaeTfeIiPtZvai6T3Imlro0aiwWuuQH7K4c5bxZJwO2KQ0befRnpZYwbK2nj 3yWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q1pviIH8yw0ihQzWZ657WYAB5FmzN9Ix5+pDNIZU+aY=; b=k3z0/kwwBjwfpeXHke1NAaD0s0lbkgq/xe8Ef5nBLOdcfAeYhrpdNeUg1NKMsPRI/2 AY/aPFXMLDE9d2CZ566UNLg1Am5YfdKHzkLmUqFY6mMVBtqjnjPxTJe0F/iHI9KY95G7 9l1ecCZ1WyYGwlgRa1kIYInZ8EX2cuILcwpRt9IU6odsrFYwH4GTv4B++wmEGfvYvI3c golmzvLTpVSV1GrGNujiqL9fUZlsMmDaRvZo237YKud+R/r5mlqS/iGEtMC/F7NfNJ1b ry1Z9MtKBVLumOb329Ti1HoALN6fF043GwT2I7fUL1tKgvL3BcpoIL5PTUkJsKMGe3qt 89UQ==
X-Gm-Message-State: AN3rC/5zxGgv9kvOOAa4XmI9CbPuuAZBnx+f0FfD12qYEzAk24qhjjh+ aWfcQpVDLJDweGpWSrJ11J0InCdNPSTP
X-Received: by 10.233.223.134 with SMTP id t128mr7023471qkf.64.1493321212068; Thu, 27 Apr 2017 12:26:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.189.164 with HTTP; Thu, 27 Apr 2017 12:26:11 -0700 (PDT)
In-Reply-To: <CAHgCvCNRYyH9wyT=vtVk34_Wc_rqrX0z1D9FCx+cZzLBOXmFLw@mail.gmail.com>
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> <20170426125417.GU25069@Space.Net> <CA+b+ERm1iDv3+GNk+N_gqjDWsd+E4QjmfhmwDN4vQVQVZ1EMpw@mail.gmail.com> <CAL9jLaabkYUO+7jsRbfZg1fXXLHXaWr88AxGyNF+AVTLquyxTQ@mail.gmail.com> <CAHw9_iKhRQpEGigqvqYoF0ca9D=-2VmESO8Fp4P_p1tZqpJgXQ@mail.gmail.com> <CAHgCvCNRYyH9wyT=vtVk34_Wc_rqrX0z1D9FCx+cZzLBOXmFLw@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
Date: Thu, 27 Apr 2017 15:26:11 -0400
Message-ID: <CAHw9_i+1HA=o+Lh7NgUxzD-OFq8u6kR5Se5z=tHttkVQ_QaSzg@mail.gmail.com>
To: Alexander Azimov <aa@qrator.net>
Cc: Christopher Morrow <morrowc.lists@gmail.com>, idr wg <idr@ietf.org>, Robert Raszuk <robert@raszuk.net>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/UmGXHKeYKXjTX7AeoW3F9Os4K3c>
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: Thu, 27 Apr 2017 19:30:04 -0000

On Wed, Apr 26, 2017 at 5:52 PM, Alexander Azimov <aa@qrator.net>; wrote:
> Hi all,
>
>
> While I do like idea of making simple fix to avoid leaks of full table (this
> how I understand the goal of this document) I'm afraid that this will only
> result in change from absence of policy to empty policy.

Empty policy is fine -- I have a number of sessions where I
intentionally have no policy. What I don't want to have happen is
*accidental* sessions without policy -- because, Murphy's law says
that that will happen wherever it is most likely to hurt / just as I
get onto a plane / right before a RIPE / NANOG meeting, so all my
closest friends can point and jeer.


> This requirement of
> policy existence will not automatically result in requirement of
> understanding of its purpose.

Yup, 'tis a well known adage that you can't fix stupid. I don't think
of this as forcing people to design perfect (or even sane) policy; I
think that it is more like the covers on electrical outlets. Sure, I
can find a screwdriver and wiggle it about in the socket[0], but the
holes are small enough that I shouldn't accidentally electrocute
myself while plugging in my laptop....

>
>
>
> Additionally, I would like to argue that full table leaks are still common
> now. They do exist, but they are rare, thanks to policies at upstream
> providers, or, at least prefix limit.

They are rarer these days -- but they do still happen. This doesn't
only stop full table leaks though -- it also stops the stupid "whoops,
I just announced all my networks to provider X, I only meant to
announce this /24, but I didn't get a chance to apply policy yet..."

W

>
>
> 2017-04-26 22:17 GMT+03:00 Warren Kumari <warren@kumari.net>;:
>>
>> On Wed, Apr 26, 2017 at 10:08 AM, Christopher Morrow
>> <morrowc.lists@gmail.com>; wrote:
>> >
>> >
>> > On Wed, Apr 26, 2017 at 9:56 AM, Robert Raszuk <robert@raszuk.net>;
>> > 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 192.0.2.1 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....
>>
>> W
>>
>> >
>> >>
>> >> http://snar.spb.ru/prog/bgpq3/
>> >>
>> >
>> > 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 nacr-list@uu.net .. 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
>> > Idr@ietf.org
>> > https://www.ietf.org/mailman/listinfo/idr
>> >
>>
>>
>>
>> --
>> 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.
>>    ---maf
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>
>
>
>
> --
> | Alexander Azimov  | HLL l QRATOR
> | tel.: +7 499 241 81 92
> | mob.: +7 915 360 08 86
> | skype: mitradir
> | mailto: aa@qrator.net
> | visit: www.qrator.net



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