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

On Fri, Apr 21, 2017 at 02:32:01PM +0000, [e-mail] wrote:
>  > From: Job Snijders [mailto:[e-mail]]  > Sent: Friday, April 21, 2017 2:40 PM
> > EBGP Route Propagation Behavior Without Policies) to Proposed Standard
>  > 
>  > On Fri, Apr 21, 2017 at 11:58:18AM +0000, [e-mail] wrote:
>  > > > From: Job Snijders [mailto:[e-mail]]  > Sent: Friday, April 21, 2017 11:02 AM
>  > >  > You create a false dilemma stating that it is not clear to you
>  > >  > whether this is a "requirement draft or a solution draft",
>  > >
>  > > That editorial point should be easy to address.
>  > >
>  > > > and that those need to be separate.
>  > >
>  > > I've not said that.
>  > 
>  > The use of the word 'or' in your sentence """it's not clear whether this
>  > draft is a requirement draft or a solution draft.""" led me to believe
>  > that you assert the two are mutually exclusive. Furthermore, from the
>  > context it appears that you recommend to abandon 'bgp-reject', start
>  > over with a requirements document, and then see what happens. If this is
>  > not the case please elaborate, and accept my apologies for interpreting
>  > it as I did.
> 
> Thanks for the clarification. 
> On my side, I don't think that there is a need for a dedicated problem
> statement document. IMHO the place for this problem statement is in
> the Introduction section of you document.
>  
>  > >  > Did you review Alvaro's suggested changes which prompted the third IDR
>  > >  > consultation on this topic? They are viewable here:
>  > >  >
>  > >  >     http://htmlpreview.github.io/?https://github.com/jaredmauch/draft-mauch-bgp-reject/blob/alvaro/draft-ietf-grow-bgp-reject-06-from-5.diff.html
>  > >
>  > > I was discussing the current version of the draft and comments sent on
>  > > the mailing list (e.g less than 24 hours ago, one author commented
>  > > that it does not believe that this document should be changed to
>  > > update RFC 4271: " I believe that Alvaro is wrong in the presumption
>  > > this document updates 4271. ".
>  > > I was not aware of this private repository. Indeed, this candidate
>  > > version is significantly different than the public one.
>  > 
>  > The link to the publicly available private repository was meant as a
>  > convenience to you and the WG. It is a verbatim repetition of Alvaro's
>  > suggestions which were emailed to idr@ on April 18th. I hoped to make
>  > Alvaro's comments easier to read by creating the HTML rfcdiff. Did you
>  > perhaps miss that message?
>  > 
>  >     https://mailarchive.ietf.org/arch/msg/idr/gU6sk8yrC3uF7aLERwnDh2cuFP4
>  
> I had read Alvaro's email.
> What I had missed is the link to the private repository, and then its meaning. I had though (apparently incorrectly, sorry for this) that this were the candidate -06 that authors were working on. i.e. the latest "current" status of the draft. From your above clarification, this is not, and -05 is the latest version.
>  
>  > >  > I'm disappointed that you've taken a CLI example I've provided as
>  > >  > the sole driver behind this effort. I did not mean to offer the CLI
>  > >  > example as an exhaustive list of reasons.
>  > >
>  > > That this incorrect: I've commented on this driver, plus the ones
>  > > indicated in the draft. What's missing has been authors' answer for
>  > > those requests for clarification.  For the third time, could authors
>  > > please document in the draft the drivers and the goal(s) that this
>  > > document aims at achieving. Then we'll be able to take into account
>  > > all drivers, plus authors will get IDR attention to their operational
>  > > feedback. Should be win-win.
>  > 
>  > Please review the Introduction section of draft-ietf-grow-bgp-reject-05.
>  > 
>  > Should you fail to identify drivers and goals in that section, can you
>  > elaborate what it is you do read in that section?
> 
> I had tried in https://mailarchive.ietf.org/arch/msg/idr/9Qn2bHQw1QIruWMCJIoEN0Z-qC4 but can try again below
> 
> 
> "   There are BGP routing security issues that need to be addressed to make the Internet more stable."
> Agreed, but not very specific. At least this does not present the specific points that this document wants to address/solve. (believe me, I wish you would address all BGP routing security issues but we probably do not want to put the bar too high, as it would be too hard to succeed)
> 
> "  Route leaks [RFC7908] are part of the  problem, but software defects or operator misconfigurations can  contribute too."
> - I agree that route leak is an important issue. But they seem to be already worked on by draft-ymbk-idr-bgp-open-policy or draft-ietf-idr-route-leak-detection-mitigation. Plus this document is not a general solution to route leak, so this is also not the point that this document wants to address (because otherwise, it failed)
> - Software defect won't probably be addressed by this proposal.
> - Misconfiguration won't probably be addressed by this proposal. In particular no effort is made to ensure that the export/import policy is good/correct.
> 
> "   Many deployed BGP speakers send and accept any and all route
>    announcements between their BGP neighbors by default.  This practice
>    dates back to the early days of the Internet, where operators were
>    permissive in sending routing information to allow all networks to
>    reach each other.  As the Internet has become more densely
>    interconnected, the risk of a misbehaving BGP speaker poses
>    significant risks to Internet routing."
> 
> Ok, this is a statement of facts. But:
> All BGP speakers requires configuration to establish an EBGP session. When doing this configuration, the operator needs to apply the right policy.
> But this draft is not helping to solve "the right" policy issue. All it requires is an additional configuration key word. This is an improvement but:
> - This does not cover configuration mistakes.
> - An operator is likely to blindly copy paste the new key word (enable policy "no filtering")  as part of configuring the session. In which case the gain would be minimal
>  
> It's also not clear to me if we can assume that the operator is a reasonable guy which wants to do the good thing, but failed because of a mistake or an improper configuration tool; or if this operator just does not give a damn.
> IMHO, given that the guy/company is an operator doing this to get money, I would personally opt for the former. In which case, he could be asked and should be happy to add one single configuration line to enable those new default behaviors. This alone would address my concern. In addition, as this document requires a software upgrade, one could signal this new behavior in the BGP Open, such that you could check by yourself.
> 
> 
> "   This specification intends to improve this situation by requiring the
>    explicit configuration of a BGP import and export policy for any
>    External BGP (EBGP) session such as customers, peers, or
>    confederation boundaries for all enabled address families.  When this
>    solution is implemented, BGP speakers do not accept or send routes
>    without policies configured on EBGP sessions."
> 
> That is not part of the problem statement but a summary of the solution. (yet, a useful summary as part of the Introduction)
> 
>  
>  > I find it hard to believe that the Introduction passed through SECDIR,
>  > RTGDIR, GENART, OPSDIR, and GROW Last Call, and was clear to those
>  > involved, yet you indicate that drivers & goals are not clear, I am not
>  > sure what I can do to further your understanding in that regard.
> 
> I find it equally hard that nobody complains on the impact/cost in term of existing EBGP configuration missing the new required policy, and impact on service provisioning tools (while they are notoriously heavy, expensive and not very flexible).
> Plus I'm not saying that this document has no benefit. I'm saying that it also has cost. And by carefully considering both, we could probably find a tradeoff satisfying all parties (that's my optimistic side, but just like anybody I can be wrong)
> 
> Given my vision of the cost/benefit, in term of solution I think that the below change would be reasonable tradeoff. At least it would address my main concern:
> 
> OLD:  A BGP speaker MAY provide a configuration option to disable the preceding behaviors, but it MUST implement them by default.
> NEW: A BGP speaker MUST provide a configuration option to enable the preceding behaviors. Until network/service provisioning are upgraded, it SHOULD be disabled by default. Such provisioning tools should be upgraded soon is order to prepare for the future new default behavior.

Your comments are helpful. While I think I understand the intent of the
NEW text I have trouble envisioning how this would work for all vendors,
and as such so far the authors have been consistent in leaving out
implementation guidance and implementation specific procedures. I
believe that each vendor will have its own path towards compliance,
should they choose to conform.

However, through this thread it has become clear some representatives of
some vendors lack the creativity to formulate a path towards compliance,
and we'll take this lack of imagination as a plea for help. I will take
this suggestion under advisement and try to improve upon it.

The risk here is that an already compliant implementation, or an
implementation that intends to become compliant through a major version
bump in the release notes, may feel that the suggested path towards
compliance does not conform to their path, and therefor reject the
suggestion. 

BTW, did you mean to use the draft-farrel-soon-05 definition of "soon"
in the NEW text? ;-)

> Optionally, on the solution side:
> - I would also support the addition of a BGP capability to signal
> whether this behavior is enabled or not. This would allow an EBGP peer
> to reject the EBGP session if the configuration is not acceptable to
> them. But I can live without.

Introducing a new capability for this specific seems to impose
additional work on implementations which are already compliant. Perhaps
a more generalised mechanism should be introduced that stands apart from
this draft, one where the BGP speaker signals the version of the
software it is running, or sends a list of all RFCs it is compliant
with. 

> - I would prefer that the BGP session be closed, rather than keeping
> it up and not considering the received routes/not sending routes.

I can see how different people would have different preferences in that
regard, however I'd like to add to the context that a 'session up and
not using received routes / not announcing routes' is a very common
debugging tool in itself. I myself have often times reduced a neighbor's
configuration to the bare minimum to debug issues. If you ask around in
GROW I think you'll find that 'up + reject' is a better starting point
for most operators then 'down'.

Kind regards,

Job