-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry but IMESHO null routing a /32 during a DoS attacck doesn't exactly strike me as engineering. It is more like dealing with the attack in real-time. To mean engineering would mean desinging networks to be resistant to DDoS and flooding in the first plsce. To that end no NSP should ever allow spoofed IP addresses outside of their network. (not just RFC 1918 addresses but valid IPs that don't belong to that NSP) e.e if I'm have a circut from C&W nd I try to spoof a packet eith a source address of 216.35.172.135 it should be dropped as close to the edge of C&W's network as possible. note on RFC 1918 addresses: These should never get past customer edge routers IMESHO. Two NSPs should rate limit DoS traffic (ICMP & SYNs) within their networks in such a way that it can never DoS a T-1 (or E-1 if you are not in the US). [note: I'm not sure if ciso's are up for this workload since I primarily work with Juniper.] Three NSPs should lock down their gear so it can't be used for DoS amplification. I mean a clueless customer getting burned is one thing but we should expect & demand more from NSPs. [note: my primary responsiblity in life is security not networking.I know just enough networking to be dangerous and annoying to our Networking dept. :-) ] On Mon, 4 Jun 2001, Geoff Zinderdine wrote:
Assuming not adding the extra connection, this means that upstream prefix filtering, so that one can't mistakenly inject 255 /24s rather than a single /16, would go out the window. Now think about /32s and what the routing tables will start to look like. Now onsider that the upstream would also want to send to its upstream Tier-1 the NULLROUTE /32 as well so that his bandwidth is not eaten up as well and we have asituation whereby routing table size will triple in size every year.
This is a stop gap measure for customer networks. Those null routed /32s are not meant to be permanently advertised, they are meant to free the customer's pipe from smurf/fraggle until the SP can do something about it. What would be the point of permanently blackholing a host on your network?
One more problem...what if your mail/web server is the target of the attack you have just taken that resource effectively off-line. No need to continue the DoS you've done the work of the attacker.
I would imagine that most tier 1's are going to filter anything longer than a /24 whether you advertise it or not. The question isn't about route table size, it is whether your SP will go the extra mile to give you a proactive option to deal with attack and has someone clueful to implement it that will take responsibility for it (not that it is hard).
This is a very limited measure that only helps in a very particular situation for a small subset of customer networks. I think it is a very useful tool for that particular situation... it is not meant as a principle that SP networks should apply to their upstream as well.
Paul Johnson Ratoath, Co. Meath Republic of Ireland - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: pgpenvelope - http://www.uiuc.edu/ph/www/ftobin/resources.html iD8DBQE7G7QUEn8vUhkIGTURAuuFAJ0Ub5lBQWG4r/WisSOTaOPNPm0/nACg8fY3 qcEayLo0vyDGlVDSFbWMKlE= =K9Xz - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (GNU/Linux) Comment: pgpenvelope - http://www.uiuc.edu/ph/www/ftobin/resources.html iD8DBQE7G7VeEn8vUhkIGTURAkd3AJ48V+C40i0noy+kij4xi470yly6WwCfT1UX o9Eq24paIFAJsSAU7JvuqNw= =D2SE -----END PGP SIGNATURE-----
Paul Johnson wrote:
To that end no NSP should ever allow spoofed IP addresses outside of their network. (not just RFC 1918 addresses but valid IPs that don't belong to that NSP)
Agreed, RFC 2827 should be the norm. Maybe some day it will be.
This is a stop gap measure for customer networks. Those null routed /32s are not meant to be permanently advertised, they are meant to free the customer's pipe from smurf/fraggle until the SP can do something about it. What would be the point of permanently blackholing a host on your network?
One more problem...what if your mail/web server is the target of the attack you have just taken that resource effectively off-line. No need to continue the DoS you've done the work of the attacker.
You've got to balance how badly the attack hurts against how badly this method of stopping the attack hurts. If someone launches a distributed attack against my mail server, and it eats up all of the bandwidth I've bought from my upstreams, then I've got zero connectivity. You can be sure I'd be in favor of taking my mail service offline to keep the rest of the network running while I pursue the issue with the upstreams. Ditto if someone launches a massive attack against one of my customers and it has the unfortunate side effect of destroying my connectivity (and that of all of my other customers.) A filter of this type is never a long-term solution, but if it can get me even partially online, that's better than nothing. Mark
On Mon, 04 Jun 2001 12:20:41 EDT, Paul Johnson <pjohnson@bosconet.org> said:
Two NSPs should rate limit DoS traffic (ICMP & SYNs) within their networks in such a way that it can never DoS a T-1 (or E-1 if you are not in the US). [note: I'm not sure if ciso's are up for this workload since I primarily work with Juniper.]
Hmm.. I'd be *REALLY* unhappy if our upstream decided to rate-limit SYN packets to prevent a DoS of a T-1, since the smallest pipe we have deployed is in the OC-3 category. The problem is that a *distributed* DOS effectively bypasses this sort of check - you have (for instance) 1000 zombie machines, each contributing only a few packets per second. So none of THEM gets filtered. Each ISP may have only 3-4 zombies, so even aggregated they don't trigger a filter. Nothing trips a filter, until it gets loose inside a Tier-1, with traffic converging on one outbound pipe to the victim from 8 or 10 different peering points. And at THAT point, it's too late. Valdis Kletnieks Operating Systems Analyst Virginia Tech
participants (4)
-
Dan Hollis -
Mark Mentovai -
Paul Johnson -
Valdis.Kletnieks＠vt.edu