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

[Jeff Wheeler <[e-mail]>]

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

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