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 <[e-mail]>]

> On Apr 19, 2017, at 11:36 PM, Enke Chen <[e-mail]> 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