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

[Robert Raszuk <[e-mail]>]

One final point ...

> - 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

Exactly !

The draft assumes that there are operators managing those 55000 ASes who
already do know today what to put in their BGP policy and they are not
doing
it only because they are lazy and their vendor does not enforce them to do
it.

Are we really that bad in Internet NOCs ? Do we need configuration
enforcement
and RFCs like this ?

Wouldn't it be a much better to instead share a pointer to Best Practices
for EBGP
Policy Configuration wiki and even include such URL in deployment section
of the draft
under discussion ?

Thx,
r.


On Fri, Apr 21, 2017 at 4:32 PM, <[e-mail]> wrote:

> Job,
>
>  > 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.
>
> 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.
> - I would prefer that the BGP session be closed, rather than keeping it up
> and not considering the received routes/not sending routes.
>
> Thanks,
> Kind regards,
> --Bruno
>
>  > Kind regards,
>  >
>  > Job
>
> ____________________________________________________________
> _____________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>