Re: ICMP rate limiting on EGRESS (Warning, operational content inside)
On Mon, 17 January 2000, bmanning@vacation.karoshi.com wrote:
Source routing and connection based services are creaping into the Internet, slowly but surely. Both are a far cry from the destination forwarding and connectionless service that I grew up with.
Yes, but as far as I know, none of the new services rely on the ability to spoof the source address outside of local (perhaps VPN extended) network. Even old services such as roaming and redirector applications have switched to using tunnels instead of spoofed source addresses. Are there any real-world applications which have no alternative but to use spoofed source addresses on the Internet at large? Or is this a case, if we had thought about it, we would have prohibited it at the start; but now its in the wild we don't know how to get it back in the barn.
Sean Donelan wrote:
Or is this a case, if we had thought about it, we would have prohibited it at the start; but now its in the wild we don't know how to get it back in the barn.
Mmmm... we got onto this argument by someone implying we wouldn't need this sort of defensive technique (ICMP rate limiting on egress) if source-spoofed weren't transmittable (or weren't widely transmittable). I agree. However as you are demonstrating, whilst getting to this utopia would be great, getting there will take a long time. I'm sure we *might* also fix DoS attacks using some sort of interprovider MPLS or like to provide QoS negotiation (and that'll also give you non-destination based routing) .... and I bet that even if this could be got to work, it would take even longer. In the mean time, ICMP rate limiting is here now and deployable for most people at these exchangepoints today. -- Alex Bligh GX Networks (formerly Xara Networks)
On Mon, Jan 17, 2000 at 04:35:58PM +0000, Alex Bligh wrote:
Sean Donelan wrote:
Or is this a case, if we had thought about it, we would have prohibited it at the start; but now its in the wild we don't know how to get it back in the barn.
Mmmm... we got onto this argument by someone implying we wouldn't need this sort of defensive technique (ICMP rate limiting on egress) if source-spoofed weren't transmittable (or weren't widely transmittable).
if we're getting into an argument, then just forget it. I would much rather see a proper discussion of the matter, with useful solutions.
I agree. However as you are demonstrating, whilst getting to this utopia would be great, getting there will take a long time. I'm sure we *might* also fix DoS attacks using some sort of interprovider MPLS or like to provide QoS negotiation (and that'll also give you non-destination based routing) .... and I bet that even if this could be got to work, it would take even longer.
the point I am trying to make is that ICMP rate limiting is duct-tape, and won't fix the problem long-term. rate-limiting at egress points is a good idea, will plug an immediate leak, make the exchanges safer, and help curb a growing problem, but it is not a long-term solution. we need to make a commitment and determine a correct course of action to get to the "utopia" in the long term. it is my fear that as we focus on installing stop-gaps one after the other, we will eventually break legitimate networking. if nobody is interested in working on things that will take a long time to implement, then we are already doomed to failure.
In the mean time, ICMP rate limiting is here now and deployable for most people at these exchangepoints today.
it is exactly this mode of thinking that prevents folks from focusing on good long-term engineering solutions. it's quick, easy, and fixes the problem until it breaks and we have to come up with yet another clever tape-on hack.
if we're getting into an argument, then just forget it. I would much
I meant 'argument' as in 'topic of discussion'
the point I am trying to make is that ICMP rate limiting is duct-tape... ... but it is not a long-term solution.
Absolutely. Nasty messy sticky horrible duct-tape at that with very little engineering beauty - it does consist, after all, of throwing away arbitrary amounts of control & test traffic.
In the mean time, ICMP rate limiting is here now and deployable for most people at these exchangepoints today.
it is exactly this mode of thinking that prevents folks from focusing on good long-term engineering solutions. it's quick, easy, and fixes the problem until it breaks and we have to come up with yet another clever tape-on hack.
I have seen plenty of horrible nasty duct-tape hacks a classic being the Doran / Partan prefix-length filtering that have little or no engineering beauty but kept the internet alive. This has not prevented router manufacturers from building cleaner, cleverer routers able to cope with larger routing tables. I make no such grand claims for this, but I am reasonably happy it won't dissuade people from working on 'real clean' solutions. If I had one of them now (please any one?), I'd deploy it. -- Alex Bligh GX Networks (formerly Xara Networks)
On Mon, Jan 17, 2000 at 08:07:36AM -0800, Sean Donelan wrote:
Or is this a case, if we had thought about it, we would have prohibited it at the start; but now its in the wild we don't know how to get it back in the barn.
this is my thinking exactly. at least I hope that had the potential for abuse of spoofed-source been thought about in the early days, that it would not be something we're battling with hacks now. clever hacks are nice, but when they are in response to a design problem, they should only last as long as it takes to correct the design problem, and the focus should be on correcting the design problem.
participants (3)
-
Alex Bligh -
Sam Thomas -
Sean Donelan