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