Mailing List Archive: Re: SYN floods continue (fwd)

Is this practical on a global scale?

---------- Forwarded message ----------
Date: Wed, 11 Sep 96 14:06:05 CDT
From: Andrew Molitor <amolitor@anubis.network.com>
To: firewalls@greatcircle.com, michael@memra.com
Subject: Re: SYN floods continue (fwd)

With fine NSC routers all over the place, one could insert a
RR option into all the SYN packets flowing through them. The enclosed
filter fragment will insert a RR option capable of recording the
first 7 routers after this one that the packet goes through. It won't
work on all our stuff, and (realistically) is enclosed for reference only.
I can dream, though, eh?

A little additional checking could be added to make it hard or
impossible to spoof this by inserting your own RR option at the source.
Basically, if you're deploying this, you strip out options on packets
arriving from 'little leaf nodes that might be bad guys' before you add
yours in.

It would be relatively trivial to add this to, say, the freely
available IP filtering in Linux. The performance hit in the core routers
would only be taken for SYN packets, which are some modest percentage
(less that 10?) of all packets. They'd feel it, but would probably not
topple right over.

With this option present, the problem or tracing it back to the
source begins to look like backtracing usenet headers -- it's not easy,
but it often/usually provides some useful information. It also would
require lots of co-operation among ISPs.

Andrew

filter syn_tracking
not ip_protocol in (6) break; # Get outta here if it's not TCP
not ip_fo in (0) break; # or if the header's not here
not tl_byte (13) mask 0x02 in (0x02) break; # if SYN not set, get out
ip_option_present 0x07 break; # Get out if RR option already here

# Otherwise insert a 7 hop RR option.
stamp_option
0x071f0400000000000000000000000000000000000000000000000000000000;
end

- - - - - - - - - - - - - - - - -

On Wed, 11 Sep 1996, Michael Dillon wrote:

==>
==>Is this practical on a global scale?

[post regarding recorded routes deleted]

While it could help, it still falls to the same problem we have today:

Cooperation between providers.

A lot of providers are happy to go through the legwork for their CUSTOMERS
and find which other network the packets are sourced from. Most of the
time, they are happy to trace it to a border router, find out which other
network it's coming from, and pass it on to that ISP.

Other providers refuse to acknowledge that (if their customers are the
culprits) their customers are doing anything wrong--probably because they
like their customers' money and will ignore anything else in reference to
that customer. They'll claim mis-configuration or ignorance. I haven't
seen this with network-level services, but I have seen it with a
well-known infamous Chicago-based service provider on a systems level.

Unfortunately, many times, an ISP won't be responsible enough to act on
problems not related to their customers. It's a shame, but it happens.

/cah

- - - - - - - - - - - - - - - - -