Did your BGP crash today?

Sun Aug 29 16:43:18 UTC 2010

On 8/29/10 3:23 AM, Mikael Abrahamsson wrote:
> On Sat, 28 Aug 2010, Brett Frankenberger wrote:
>
>> The implementor is to blame becuase the code he wrote send out BGP messages which were not properly formed.
>
> People talk about not dropping sessions but instead dropping malformed messages. This is not safe. We've seen ISIS (which is TLV based and *can* drop individual messages) been wrongly implemented and platforms drop the entire ISIS *packet* instead of the
> individual message when seeing something malformed (or rather in this case, ISIS multi topology which the implementation didn't understand), and this made the link state database go out of sync and miss information for things it actually should have
> understood.
>
Reminder: TCP itself has also "been wrongly implemented" with horrid consequences.

Unknown TCP options are supposed to be silently discarded.  Instead, some
middlebox vendors simply copy them into the return packet.

There are some circumstances where it makes sense to silently discard one TLV
option, and others where it makes sense to discard the whole packet, and still
others where it makes sense to drop the session.

A problem is that many of the early designers (BGP is a fairly early design)
used one-size-fits-all error handling.

There's not much anybody can do about bad implementation (as in this case)
that corrupts data.  But a lot more thought needs to go into error recovery!

> This was *silent* error/corruption. I'm not sure I prefer to have silent problems instead of tearing down the session which is definitely noticable.
>
Personally, I've usually advocated returning an error message.  Many of the
protocols I've developed use this approach.

(Please forgive RADIUS, which for some odd reason is my most frequently cited
work according to Google.  My original draft had a Reject, subsequent WG
activity took it away.  All I could do is throw up my hands and walk away.)