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

Jared Mauch <jared@puck.nether.net> Thu, 20 April 2017 13:49 UTC

Return-Path: <jared@puck.nether.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 901CE131456 for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 06:49:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.203
X-Spam-Level:
X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 dY4ZYCEpOaWt for <idr@ietfa.amsl.com>; Thu, 20 Apr 2017 06:49:20 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id 5066712954D for <idr@ietf.org>; Thu, 20 Apr 2017 06:49:20 -0700 (PDT)
Received: from [IPv6:2603:3015:3603:8e00:25c2:4c02:5849:c73d] (unknown [IPv6:2603:3015:3603:8e00:25c2:4c02:5849:c73d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id EF818540BA1; Thu, 20 Apr 2017 09:49:18 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <8a242116-e17b-9c3f-00d4-a2e606a0c5b4@cisco.com>
Date: Thu, 20 Apr 2017 09:49:01 -0400
Cc: Brian Dickson <brian.peter.dickson@gmail.com>, Hares Susan <shares@ndzh.com>, idr wg <idr@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2993DCCB-1BB0-4699-8231-5FDAFF682D34@puck.nether.net>
References: <D4E812E8-AA7B-4EA2-A0AC-034AA8922306@juniper.net> <abe393d3-d1e4-7841-4620-38dab751765b@cisco.com> <CA+b+ERnRz8BEO3mb1fnsDPoiL6Wxjdfw9vQPbyODNEa+xCJdnw@mail.gmail.com> <D51D67E4.A9782%acee@cisco.com> <AF07526F-F08B-4084-937B-A9A2D2DD2813@juniper.net> <2b8a94bb-4f40-6c1d-05ff-9cf11ad93646@cisco.com> <CAH1iCirFhb3HuREBDuuDbC-fuiinSFW6UuSk61MrEj9GEaHtsw@mail.gmail.com> <8a242116-e17b-9c3f-00d4-a2e606a0c5b4@cisco.com>
To: Enke Chen <enkechen@cisco.com>, "Acee Lindem (acee)" <acee@cisco.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/BS9KaMUZptEeUTxFKqBKx2dO1Go>
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, 20 Apr 2017 13:49:21 -0000

> On Apr 19, 2017, at 11:36 PM, Enke Chen <enkechen@cisco.com>; wrote:
> 
> Hi, Brian:
> 
> I think that the backward compatibility concern is more about existing
> deployment. For example, say an existing router does not have an inbound
> policy and just accepts whatever routes from its provider, but it does 
> have an outbound policy.  Let us further assume that the default behavior
> in the software is to accept updates from a neighbor without an inbound
> policy. 
> 
> Assume in the new code the default behavior is changed to drop updates from
> a neighbor without an inbound policy.  Then as soon as the new software
> is deployed on that router, the updates from the provider would be dropped
> without any config changes.

Vendors have changed defaults before and incrementally done so, take for example
a well known vendor that had problems that arose during an IETF meeting regarding
configuration options like “service tcp-small-servers” and “service udp-small-servers”
which eventually became a) exposed and b) non-default.

Surely there is precedent for a vendor to identify a release strategy that resolves
the operational concerns without an IETF document and IDR dictating to the vendor how
exactly to perform their release cycle.  I think we all know that’s infeasible and is
entirely a straw man argument for not addressing the well documented operational insecurity
introduced by clinging to an exploitable practice.

Let me reiterate, it’s not even like all vendors are internally consistent across their
releases here, this is codifying a safe default, such as not running an open relay for
delivery of SPAM or “ip directed-broadcast” for things like the SMURF attacks.

- Jared