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 Thu, Apr 20, 2017 at 08:36:17AM -0700, Enke Chen wrote:
> Hi, Jared:
> 
> If it is not obvious, let me state the I participate in IDR WG as an individual
> contributor, just like you do I suppose.

	Of course.

	:-)

> Let me rephrase what I said, for a code base with a large and diverse customer base
> I do not foresee any possibility for the default behavior change in this case. Again
> please treat it as my personal opinion.
> 
> I am certainly aware of other cases where the default behavior has been changed. But
> this one is different.  This case seems similar to the default behavior ("permit" or
> "deny") for an empty ACL.  Once the "permit" or "deny" is set in the code and is
> widely deployed for a long time, it is just not possible to make the switch between
> "permit" and "deny".

	I think there is a very distinct issue here, I would of course love
for existing vendors to come in compliance with a "secure-by-default" strategy.
Many othr people with far more devices than BGP speakers have seen this
necessity and made the change, claiming that BGP is somehow unique or that
operators do not deserve this safety is inconsiderate.

	My intent isn't to update 4271, it's Alvaro that has raised that
spectre.

	Cisco (as an example) has many cases where defaults have changed,
the same is true of many pieces of software, either in development or after
deployment.  Sometimes thse are called bugs, sometimes a feature.

	I've outlind my recommendation of how I would like to see 
nvgen function work in Ciscos case, that these devices can simply
expose these defaults, just as config bits often are massively reordered
betwen even minor interims or rebuilds.

	If you take the line-by-line interpreted vs atomic model of
driving configuration, it is not possible to apply policy to a session before
the FSM starts running.  This is unsafe.

	I'm seeing the GROW WG advise what an operational safe default
practice is as there is no codified standard of the behavior.  Operators
value consistent behavior, and it's clear with much of the ongoing work
in IETF around standards based models that the vendors see value as well.

	I suspect many people in IDR have not seen a bank be MITM'ed
for months due to routing leakage.  They would say this must be the
intended policy of 'pass all'.

	With further BGP speakers coming online, we need to address
this technical debt that many of us bear the burden of.

	Re: the draft under discussion, did you look at any of the prior
versions of the text?  I suspect that many people have not.

The pre-GROW-WG text said:

https://tools.ietf.org/html/draft-mauch-bgp-reject-00

-- snip --
3.  Solution Requirements

   The following requirements apply to the solution described in this
   document:

   o  Software MUST NOT accept routes from an eBGP peer without an
      operator configuring a policy

   o  Software MUST NOT require a configuration directive to operate in
      this mode.

   o  Software MUST NOT send routes to an eBGP peer without an operator
      configuring a policy

   o  Software MUST provide protection from internal failures preventing
      the advertisement and acceptance of routes

   o  Software MAY provide a configuration option to disable this
      security capability.
-- snip --


After advisement of BGP implementors, and post-adoption it seemed
an implementor may require a pointer to actually when and how to
reject the routes, as this guidance was seen as unclear.

This is when section 3 was updated:

https://tools.ietf.org/html/draft-ietf-grow-bgp-reject-00

-- snip --
   o  Software MUST mark any routes from an eBGP peer as 'invalid' in
      the Adj-RIB-In, if no explicit policy was configured.
-- snip --

And eventually morphed into something that cited a Informative Reference
and gave detailed guidance:

https://tools.ietf.org/html/draft-ietf-grow-bgp-reject-05

-- snip --

   o  A BGP speaker MUST consider any routes advertised by an EBGP peer
      ineligible for route selection (section 9.1.1 [RFC4271]), if no
      import policy was configured for the peer.

-- snip --

Is one of these previous iterations of the text more acceptable to you
or the IDR WG?

	- Jared

-- 
Jared Mauch  | pgp key available via finger from [e-mail]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.