nanog mailing list archives
Re: engineering --> ddos and flooding
From: "Geoff Zinderdine" <geoffz () mts net>
Date: Mon, 4 Jun 2001 02:36:17 -0500
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 consider 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 a situation 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? 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. Geoff Zinderdine CCNP CCA MCP MTS Communications Inc. ================================================================ The views expressed here are not necessarily those of my employer.
Current thread:
- Re: engineering --> ddos and flooding, (continued)
- Re: engineering --> ddos and flooding Walter Prue (Jun 01)
- Re: engineering --> ddos and flooding lucifer (Jun 01)
- Re: engineering --> ddos and flooding Bill Woodcock (Jun 01)
- Re: engineering --> ddos and flooding Geoff Zinderdine (Jun 01)
- Re: engineering --> ddos and flooding Mark Mentovai (Jun 01)
- Re: engineering --> ddos and flooding Geoff Zinderdine (Jun 01)
- Re: engineering --> ddos and flooding Christopher A. Woodfield (Jun 01)
- Re: engineering --> ddos and flooding Mark Mentovai (Jun 01)
- Re: engineering --> ddos and flooding lucifer (Jun 01)
- Re: engineering --> ddos and flooding Walter Prue (Jun 01)
- Re: engineering --> ddos and flooding Hank Nussbacher (Jun 03)
- Re: engineering --> ddos and flooding Geoff Zinderdine (Jun 04)
- Re: engineering --> ddos and flooding Mark Mentovai (Jun 04)
- Re: engineering --> ddos and flooding Valdis . Kletnieks (Jun 04)
- Re: engineering --> ddos and flooding Dan Hollis (Jun 04)
- RE: engineering --> ddos and flooding Hank Nussbacher (Jun 04)
- RE: engineering --> ddos and flooding Richard A. Steenbergen (Jun 04)