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

Job Snijders <job@instituut.net> Mon, 01 May 2017 18:40 UTC

Return-Path: <job@instituut.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 BE69612EAF2 for <idr@ietfa.amsl.com>; Mon, 1 May 2017 11:40:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-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 JlYQbBcF2xww for <idr@ietfa.amsl.com>; Mon, 1 May 2017 11:40:35 -0700 (PDT)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 9B7DA129C6A for <idr@ietf.org>; Mon, 1 May 2017 11:37:30 -0700 (PDT)
Received: by mail-wm0-x234.google.com with SMTP id u65so93360901wmu.1 for <idr@ietf.org>; Mon, 01 May 2017 11:37:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=gwB0lydl2QRaK9Lx4sqoFK4LpQYKRCoPgb/yWGxZexs=; b=hMGa2zqjOLqTRA5xe2kFJ/sKY/Zyp8kXahF0IUcqu9/0+e+xgEBUJzAtUe2WVYZ7w6 QMohcuguk4YaJCD8dEyZ+yn95OFGimtHsBTxwFTcdKnJEhge9WQzo8ATowYn2LTy7J26 m4iKJT7BmW0MoKonF3Q4y4RjZii/Vwyfsm3QvJHEOvuDbYuR9R8Ep1ExkHNL4GKeKY/U 1YTU0fokEb5ydBO6dpwwslGQ+GCvbiKCsofmgJ0h4jK+fTn+7GG8ZvCAc/VpP4uYU4ko iba1VnlbzSIKKNtmA2+en/BmJJMdfSSjzvEJxumfVRacz2mt2VrB4aFuEmEv9ePBGVYj 2P7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=gwB0lydl2QRaK9Lx4sqoFK4LpQYKRCoPgb/yWGxZexs=; b=A8QgW9eblC9sjzIBKsN7f/CuCA5Ad1jsahrHYsUr0WbpEkhd16Vl+5jkr5+M9RbFkG ArMM6kYr2eycQTHEh17Zj25huKkrSpwxBeMhhEWmMLIq2v8t+bMsmDHy72OK4i5JaQ4f MmTIuyFWHUmFCr6gIHJqTl3wT+98ZMw6mEIA6oSVDzwjoEQdcTfifihuDUI6rr+YE+l8 uWtIz+6xVC41BhY0mQot5QVioIbZf8qrDCo5Cm92htGtRkEQNnDdzwYACPTH2vEfcE4C shgWeXwgMdCwlk0oydCJJysrfHYxYAcR2iPfddAJn9m3P30ErVkn6Sz+3cO8TiHAfPLW pVgA==
X-Gm-Message-State: AN3rC/517NUsa9FqYl9SUWpiZCbN3as/T7SyoVRBRptGI+Ns7mOfjEWe gDrCU83twYxokg==
X-Received: by 10.80.148.123 with SMTP id q56mr20894305eda.58.1493663848919; Mon, 01 May 2017 11:37:28 -0700 (PDT)
Received: from localhost ([2001:67c:208c:10:9d8e:1399:5d1e:e878]) by smtp.gmail.com with ESMTPSA id z34sm4999306edz.57.2017.05.01.11.37.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 May 2017 11:37:28 -0700 (PDT)
Date: Mon, 1 May 2017 20:37:27 +0200
From: Job Snijders <job@instituut.net>
To: Robert Raszuk <robert@raszuk.net>
Cc: Randy Bush <randy@psg.com>, idr wg <idr@ietf.org>
Message-ID: <20170501183727.axqmnxdomwc5ti3e@hanna.meerval.net>
References: <CA+b+ER=hq0=JNRfF8VA76_aqeRMBCeyQm5aTbapysXGTgaGS_g@mail.gmail.com> <CAL9jLaakVACiZKjk6XUi9mwkrCRsPqONUQmrTBCN7V43y+RtrQ@mail.gmail.com> <m2y3uk7h8p.wl-randy@psg.com> <CAL9jLaZXqA8-LnAdNOfhCQA+pq1fh1site_shSH+-gH0hCNeqQ@mail.gmail.com> <m2o9vg6snc.wl-randy@psg.com> <CAH1iCirW2qnmXyGQb5Db0UYjKhODhbeRxdZEGCWfiQRjWnkn5w@mail.gmail.com> <m27f246ovd.wl-randy@psg.com> <CA+b+ER=Dj=F6rCmZVtOuYmGQyO5fBZx0=18MdbuOhj3fB=XVKA@mail.gmail.com> <m24lx76djx.wl-randy@psg.com> <CA+b+ERm6LuJv+psrE9+DJSgfMSnSHO1LXsFt274J+Btz3WH_1A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+b+ERm6LuJv+psrE9+DJSgfMSnSHO1LXsFt274J+Btz3WH_1A@mail.gmail.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: NeoMutt/20170306 (1.8.0)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/S8y4zGWvneDdSTrb2B_ySt11ewk>
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: Mon, 01 May 2017 18:40:37 -0000

On Sat, Apr 29, 2017 at 05:20:25AM -0400, Robert Raszuk wrote:
> > but vendors should do their best to ameliorate the risks with loud
> > warnings.
> 
> Indeed ...
> 
> There is also proposed option to significantly reduce the risk by
> changing this default only to protect from becomig an accidental
> transit I suggested in this thread already.
> 
> It is simple to implement by vendors, does not require any protocol
> change and does not affect in any way stub guys which today advertise
> their PI prefix out and get default in.

draft-ietf-grow-bgp-reject is just as simple (or as hard) to implement. 

More to this point of allowing ^$ and nothing else, it does not help
against origin-washing (EBGP->IGP->EBGP), and it does not provide for a
consistent experience like the current proposals do. I would also like
to note that while some people may have just their supernets in BGP,
others might have hundreds of thousands of /32s for VMs. There is no
justification as to why it is more desirable to make it easy for someone
to spill their internal guts rather then project them. The very same
arguments apply for both the 'dont accidentally become transit' as 'dont
accidentally announce things you didnt explicitly want to announce'.
There is no new argument here.

You can keep mangling the bgp-reject idea, but in the end we do not know
what all use-cases are, so we cannot accomodate one and not the other,
therefore the only logical outcome is that you ensure that in all cases
there is consistent and safe behavior.

> Which btw they must already explicitely enumerate either in "network"
> statement or "route/prefix-map" during redistribution. Why to enforce
> same thing to be configured multiple times in your config ? That is
> always error prone.

Yes, the platform you are referring to has more then one pitfall. Please
talk to your vendor's account manager to help build a case for this
enhancement request.

Kind regards,

Job