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

[<[e-mail]>]

> From: Eric C Rosen  > Sent: Thursday, April 20, 2017 10:01 PM
> 
 > On 4/20/2017 2:24 PM, Tony Przygienda wrote:
 > > Can't miss that food fight ;-)
 > 
 > It did seem to degenerate rapidly into "if you don't agree with my
 > proposal, you don't care about security".  ;-(
 > 
 > I agree with Enke that surprising your customers with a change in
 > behavior due to altered defaults is generally considered to be a big no-no.
 > 
 > When the customers complain about a change in behavior, it is not
 > considered appropriate to respond with "it's not my fault, you should
 > have read the release notes", or "it's not my fault that you don't know
 > how to troubleshoot BGP", or "it's not my fault that you didn't do your
 > due diligence".
 > 
 > Phasing in a change of behavior over several releases is not a practical
 > solution, because:
 > 
 > a) Customers will still be surprised when the default behavior finally
 > changes, and
 > b) Many customers won't deploy all the releases anyway.
 > 
 > >
 > > Having said that, I think this is BCP material at best and if this is
 > > a BCP then
 > >
 > > i) a "backward compatibility a.k.a which end of the stick is sharp"
 > > section is very advisable
 > 
 > I would agree that something more than "figure out how to configure the
 > new release to behave like the old release" would be helpful.
 > 
 > > ii) the BCP should describe which customer segment is best served with
 > > which default
 > >
 > 
 > But then operators from different segments would have to get together to
 > understand each others' requirements, and they'd have to respect each
 > others' opinions as well.   I can't wait to see what happens when the
 > "trust nobody" folks get together with the "zeroconfig plug and play"
 > folks ;-)
 > 
 > The dilemma is that there is a real security problem in certain
 > environments, but the proposed solution seems to have unintended
 > side-effects that are problematic.  Then the question becomes whether
 > the benefits are worth the cost, and this is not really a question that
 > can be resolved by IETF consensus.

Good summary, thanks.

1) As already asked, could the draft states what the problem it aims at solving?
In particular,
- it does not solve the general route leak problem, nor the 3 problems indicated in the first section of the introduction.
- on the list, one author expressed a different, more focused/pragmatic, goal
" The problem is that there are some platforms which _immediately_
activate a line of configuration after you press enter, and a BGP
session may already come up before you get to the configuration line
which restricts what should be announced or accepted."

2) Can the draft document the side-effects, e.g. in a manageability section.


Without those 2 points, IMHO the draft is misleading for the reader/reviewer/voter/user. This trade-off analysis is currently absent in the document up to the point that those drawbacks have not been raised during RTG-DIR and RTG-OPS review. So it's probably fair to assume that this may also have missed by some other IETF contributors.

3) Once the problem that we want to solve has been clarified (cf 1) , then we can start reviewing the solution.
In particular, if the problem is indeed:
" The problem is that there are some platforms which _immediately_
activate a line of configuration after you press enter, and a BGP
session may already come up before you get to the configuration line
which restricts what should be announced or accepted."

Then, there might be other solutions. e.g.
- fixing this CLI issue on those plateforms. In particular, no need to also impact the netconf provisioning which has not this issue, or the implementations which do not have such CLI issue.
- use a 2 step provisioning on both EBGP peers:
   - on the sending side, use a trick for avoid the session to come up until the BGP configuration is complete enough . e.g. interface shut, use the wrong authentication key/TTL hack
   - on the receiving side, use a trick to avoid the session to successfully come up or to accept the routes. Then after allowing for a reasonable time to let the sender finish its config, restore the correct configuration. Obviously this can be automated by a "controller", a local feature, a local event script.
This 2 step provisioning has the benefit of limiting the cost of the solution to the space where the problem is. (vs asking everyone to bear the cost, for a benefit of a few, whatever important is this use case)
- I sure others may find more creative solutions.

4) Regarding the specific solution proposed in the draft,
-  why has it been prefer to silently drop the route, with will surprise people and definitely the EBGP peer, rather than bringing done the BGP session with a reasonable error (sub)code / text to help diagnose the problem.

- the 3rd bullet is debatable to me
"   o  A BGP speaker SHOULD fall back to an "import nothing" and "export nothing" mode following failure of internal components, such as a policy engine."
This is an error handling situation. IMHO https://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error-handling-07 had a better analysis on this point. e.g. at the minimum, rather than calling for silently dropping the route, I would call for closing the BGP session, possibly trying to restart it. Plus if this BGP internal failure also impact IBGP session, we have a bigger problem.

- it's not clear whether this draft is a requirement draft or a solution draft. As per the first sentence of section 2 and its further text, it looks like a requirement draft. But in this case, the requirements should be solution agnostic. Which is definitely not the case. (e.g. above comments are solutions specific)

Thanks,
Regards,
-- Bruno

_________________________________________________________________________________________________________________________

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.