On Fri, Aug 27, 2010 at 2:33 PM, Dave Israel <davei@otd.com> wrote:
On 8/27/2010 3:22 PM, Jared Mauch wrote: [snip] an MD5 hash that can be added to the packet. If the TCP hash checks
Hello, layering violation. If the TCP MD5 option was used, the MD5 checksum was probably correct. Malformed BGP Protocol messages, not malformed TCP messages. The BGP protocol that lives on top of TCP is a non-packetized stream. Dropping the IP packets, would just mean that the IP packets containing the malformed BGP data need to get resent (still containing malformed BGP application protocol data, when resent).
out, then you know the packet wasn't garbled, and just contained information you didn't grok. That seems like enough evidence to be able to shrug and toss the packet without dropping the session.
If the attribute is malformed, and in particular, if the _length_ value is malformed, because more bits have been transmitted as part of an update than indicated in the length, how do you reliably determine exactly where the "junk" ends, and the next attribute starts, and resume the stream without loss of other critical data? Without a valid length of the attribute, you don't know which bit the next attribute starts at, or which bit the next update starts at. If the apparently length of the update is wrong, the rest of your session appears to be malformed. If your guess is wrong, you could wind up interpreting part of the attribute DATA portion as another route update, allowing an adversary to exploit the malformed bug to possibly inject new routes. A "recovery" mechanism could lead to worse problems, or lead to problems not being discovered.
-Dave -- -J