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
participants (2)
-
Craig A. Huegen
-
Michael Dillon