[69894] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: TCP/BGP vulnerability - easier than you think

daemon@ATHENA.MIT.EDU (Iljitsch van Beijnum)
Wed Apr 21 08:10:40 2004

Date: Wed, 21 Apr 2004 14:10:05 +0200 (CEST)
From: Iljitsch van Beijnum <iljitsch@muada.com>
To: Daniel Roesen <dr@cluenet.de>
Cc: <nanog@merit.edu>
In-Reply-To: <20040421132742.B20340@homebase.cluenet.de>
Errors-To: owner-nanog-outgoing@merit.edu


On Wed, 21 Apr 2004, Daniel Roesen wrote:

> > > > The general ignorance to the fact that SYN works as well is
> > > astonishing. :-)

> > What are you talking about?

> http://www.uniras.gov.uk/vuls/2004/236929/index.htm

> First paragraph of the summary:

> "The issue described in this advisory is the practicability of resetting
> an established TCP connection by sending suitable TCP packets with the
> RST (Reset) or SYN (Synchronise) flags set."

And:

"It is also possible to perform the same attack with SYN (synchronise)
packets. An established connection will abort by sending a RST if it
receives a duplicate SYN packet with initial sequence number within the
TCP window."

So the attacker sends a spoofed SYN to router A, and router A sends an
RST to router B and router B terminates the BGP session.

I don't see anything in RFC 793 that suggests that "connections in a
synchronized state" should be terminated because of a SYN. Hopefully our
favorite vendors didn't either...

The good part here is that filtering RSTs should still work. The
advantage of that approach is that it moves the problem from the control
plane to the data plane.


home help back first fref pref prev next nref lref last post