Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt

[<[e-mail]>]

>From: [e-mail] [mailto:[e-mail]] On Behalf Of Jeff
>Wheeler
>
>On Sun, Dec 9, 2012 at 6:44 PM, Chris Hall <[e-mail]> wrote:
>> end.  However, forming these attributes is very simple, well
>> exercised, and easily tested code.  It seems to me that this sort of
>> anomaly is more likely to be symptomatic of a framing issue than it is
>> to be a well-formed attribute which the sender has, for reasons
>> unknown, decided to send with unexpected Flags and/or Length.
>
>Here is an example from two weeks ago of some routes injected to the
>DFZ with malformed attribute flags.  The result was that everyone
>running OpenBGPd more than a few months old, and some networks with
>Alcatel routers, and who knows what else, had their BGP sessions
>resetting endlessly.
>http://mailman.nanog.org/pipermail/nanog/2012-November/053754.html

In that specific case, it was not a BGP protocol error, but a bug in the router receiving the UPDATE. i.e. draft-ietf-idr-error-handling would not change this.
However, this is an example that error in flags, including in well known attributes, may happen.

And in general, I agree with Jeff & Rob: BGP is mission critical to networks. Shutting it down for a wrong flag/bit should not be the first option.

>
>BGP continues to be extended for purposes it was not intended to
>serve.  MBGP is really terrible, and I am sure we all know that.
>Capabilities have some caveats.  Secure BGP is genuinely scary.  Soon,
>BGP will be used for MAC learning in datacenter and WAN networks.
>
>Sadly there is no improved, more robust BGP, with better sanity checks
>and/or more flexibility when handling faulty messages or buggy
>software.  BGP must become more robust because people continue to
>extend its use with more code, and more bugs.
>
>On Sun, Dec 9, 2012 at 6:46 PM, Rob Shakir <[e-mail]> wrote:
>> It strikes me that your analysis is aiming to ensure 100% consistency at the
>device level - which I think is something that we have to accept is
>incompatible with overall network system robustness.
>
>I agree.  I hope vendors will think hard about what default
>configurations they ship, but giving operators some knobs may save
>them a lot of money and stress when things go bad at 2am and they have
>got to find a work-around to their problem until their vendor TAC or
>in-house experts can find out what is wrong.
>
>BGP is mission-critical for everyone.  If it stops working, you start
>losing money, instantly.  The BGP protocol is the single point of
>failure that we all live with.  Increasing its robustness is highly
>important.  It should be done with the goal of allowing operators,
>without much knowledge, to potentially work around problems until they
>can actually be solved.  This should be true whether malformed updates
>are the result of wrong flags, length/type errors, or ascii-art
>unicorns dancing in RPKI signatures.
>
>--
>Jeff S Wheeler <[e-mail]>
>Sr Network Operator  /  Innovative Network Concepts
>_______________________________________________
>Idr mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/idr

_________________________________________________________________________________________________________________________

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,
France Telecom - 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, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.