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

Robert Raszuk <robert@raszuk.net> Fri, 21 April 2017 12:34 UTC

Return-Path: <rraszuk@gmail.com>
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 CC92E1293F3 for <idr@ietfa.amsl.com>; Fri, 21 Apr 2017 05:34:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level:
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 D3_N_cPiu9BK for <idr@ietfa.amsl.com>; Fri, 21 Apr 2017 05:34:00 -0700 (PDT)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 D1751126DCA for <idr@ietf.org>; Fri, 21 Apr 2017 05:33:59 -0700 (PDT)
Received: by mail-io0-x235.google.com with SMTP id a103so118586979ioj.1 for <idr@ietf.org>; Fri, 21 Apr 2017 05:33:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=QJNDaZKqbTdtN9obkdjkcFzLW+jl8tp/m7e6JZuQ2Ig=; b=ZpPYdDr70e0YRy9uA8km9j8EMLTt7e+NSRWbH14La8pUK2FQJqmh00YpaHFPSE9QMm QpLHaARvaouPORDEOojsEgCvnwoXaQYz6Epc6Jlmyhj9JBAoraqMIqtSgn3i2KEqFviB iLeoKXSsMljLMuxrCaErZ5kjcFUqvE2AZ/SWVfstGC4GiZrz6jn2x2gmi0G30OjFfosM 43TUq1IzH88peu7kEZXzaLgMoubquU98ckRNHJt1EiW6jelohBo9tY8w1Uz8H5buINBn r/9TnPWEneGUvLkhNKg8EDAyO1TMkUYI7oytlU58BilzLrTeNvAz3FCrYbpWTbDpjIN+ pszQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=QJNDaZKqbTdtN9obkdjkcFzLW+jl8tp/m7e6JZuQ2Ig=; b=HS6fsNu+CH7olGEjvJSfJy0SH6FOgjWm0F5qU6PvdjtCEb2qgggXThWdGoX7/rWJFL n5PEM3XVVtbtNZ/Wr8RUZCoiKfV3U/OwiF1tdH7xvNM1m1fk9IxZ1c/kLpFRC5f4eQDW I0tppcr9VIP8yJ0hMLLL1ATClGMl86GLZIdef6jR0Y+mf21odAPKWBEUrMVVgLFXDa1r kxfn08x11AjiW5KgRduLCThWXvmyMwkCzzY7FiGtISJVZCXFGD1wB0F5tu+krE+PQ8D3 iwTbmYOqUSb0GgoBd7ekK6mk4NdogIYHQYUsqcM45eGSK71SjOG3ZBswznW87HTYBLO8 R0lg==
X-Gm-Message-State: AN3rC/74ff+BBirbJpbbW5YO1DEbw9NdmJ8CS6By8tl308WZPZqKyqbN AGkLM5qRKU1i6qqmig0h2HHbnWphDQ==
X-Received: by 10.36.80.194 with SMTP id m185mr4576208itb.24.1492778003584; Fri, 21 Apr 2017 05:33:23 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.170.4 with HTTP; Fri, 21 Apr 2017 05:33:22 -0700 (PDT)
Received: by 10.79.170.4 with HTTP; Fri, 21 Apr 2017 05:33:22 -0700 (PDT)
In-Reply-To: <20170421095839.sralcy7aos5mzzic@Vurt.local>
References: <68B29403-9AD9-4F06-9FE4-3F077E793D9F@puck.nether.net> <275cf744-1f64-bcbc-dabe-a47479921230@cisco.com> <20170420154142.lacvtplusepy3qcf@hanna.meerval.net> <b57162ec-f806-6e86-7713-58608f72c468@cisco.com> <32C0B4EE-6241-49F9-97F2-7107AC68678D@juniper.net> <e513849d-f895-0499-7bf4-5ecb24cadab7@cisco.com> <4CE4AF1E-0C80-423E-B19D-5750FCAFAD89@juniper.net> <23283_1492759950_58F9B58E_23283_375_1_53C29892C857584299CBF5D05346208A31CC352B@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20170421084638.l6pbvtznfsxnq2wy@Vurt.local> <23291_1492766305_58F9CE61_23291_9725_1_53C29892C857584299CBF5D05346208A31CC399E@OPEXCLILM21.corporate.adroot.infra.ftgroup> <20170421095839.sralcy7aos5mzzic@Vurt.local>
From: Robert Raszuk <robert@raszuk.net>
Date: Fri, 21 Apr 2017 14:33:22 +0200
X-Google-Sender-Auth: XZzYBD-foxreJCmOPihiK0ZuvaQ
Message-ID: <CA+b+ERmxaa99tpUSfbp7Nk4-x6SXtX-W0-pbt-ZY=Vym_NFGPg@mail.gmail.com>
To: Job Snijders <job@instituut.net>
Cc: bruno.decraene@orange.com, idr wg <idr@ietf.org>, Hares Susan <shares@ndzh.com>
Content-Type: multipart/alternative; boundary=001a11449730a1dda3054dac761a
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/lGqQimETNGzN6ZfcjIm8aEPuvt0>
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: Fri, 21 Apr 2017 12:34:02 -0000

Job,

Let's face it ... your proposal in spite of all claims you are making does
nothing to prevent outages or route leaks.

Your examples of "accept all" or "send all" are clear prove of it.

Forcing any policy != forcing correct policy.

If someone cares about Internet stability he will implement correct policy
today without being forced by a vendor. If someone care less he will send
all and accept all just line it is today.

So let's not try to sell/sneak someting here under completely wrong label.
All this draft is about it is forcefull education for those customers who
do not know that bgp policy exist.

Kind regards,
R.

On Apr 21, 2017 11:58, "Job Snijders" <job@instituut.net>; wrote:

> On Fri, Apr 21, 2017 at 09:18:24AM +0000, bruno.decraene@orange.com wrote:
> >  >
> >  > So, going forward, any IDR proposal that requires a change to any
> >  > provision system is a no-go?
> >
> > It's not about a no-go. It's about understanding and considering the
> > tradeoffs.
>
> Bruno, through this thread I have learned:
>
>     - Release notes are not read, and it is unreasonable to expect
>       people to read them.
>     - Software will not be tested prior to deployment, not even to see
>       whether it boots.
>     - We cannot expected staggered software deployments, people will
>       upgrade all their BGP speakers at the same time (again, without
>       testing the software).
>     - Any change to a provisioning system is an insurmountable
>       imposition.
>
> I'm sure you appreciate how these new insights will affect all future
> IDR work. I assure you that if such weak rethoric continues to be
> admitted as valid justifications for lethargy, this will affect IDR's
> productivty the coming years.
>
> If you want to play the game of 'tradeoffs have to be made', I have not
> seen any appreciation in this thread for the cost on the Internet as a
> whole resulting from insecure defaults. Robert Raszuk even went as far
> to argue that we'd be doing the "little guys" (surely that was not meant
> in a belligerent way) a favor by allowing insecure defaults to persist.
>
> I theorize that for instance this outage was the result of a 'fail open'
> rather then 'fail closed' (as proposed in bgp-reject) implmentation
> choice. See https://www.theregister.co.uk/2015/06/12/level_3_down_after_
> routing_through_malaysia_like_idiots/
> or https://bgpmon.net/massive-route-leak-cause-internet-slowdown/
>
> Outages like these affect everyone, whether they were a directly
> involved party or indirectly involved. Did you notice this event in your
> own network? Or perhaps you did notice it because payment terminals in
> some countries stopped working?
>
> The BGP Default-Free Zone is composed of roughly 55,000 autonomous
> systems operated by as many organisations, who are densily
> interconnected with each other through milions of EBGP sessions. When DC
> equipment is connected to Internet, or when a CLI-style makes accidents
> easy, or when a lack of education results in a common misconfiguration,
> there should be checks and balances in place to dampen the negative
> effects on the Internet as a whole. The Internet Engineering Task Force
> (notice the 'Internet' in IETF) has a responsiblity to promote and
> define safe and secure default behaviours.
>
> Kind regards,
>
> Job
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>