On 12/27/2013 12:24 AM, Dobbins, Roland wrote:
On Dec 27, 2013, at 10:55 AM, Mike<[email protected]> wrote:Can anyone suggest how we might tighten this up and either have a seperate rate limit list or somehow exclude my small list of resolver IP's from the above limiting?Using any QoS mechanism, let alone an old, obsolete, unmaintained one like CAR, to deal with DDoS isn't a good idea - programmatically-generated attack traffic can 'crowd out' legitimate traffic.
I am reasonably sure that for this one application - dropping floods of dns traffic - is a reasonable step. The only mechanisiam I think I have at the moment, is to assert that dns from the internet to my subscribers on my network is likely to have a reasonable peak flow of about 1mbps and that if I see 15mbps or more it's likely an attack. My customers _should use_ my resolvers, which I would exclude from this limiting, and anyone who has trouble with off-network resolvers during these floods are well-advised to use my resolvers instead.
Why are you allowing DNS responses from outside your network to your subscribers at all, excepting Google DNS, OpenDNS, and anything specifically arranged for specific customers (the assumption is that you're running a consumer broadband access network)?
Open internet. I don't want to dictate to anyone which port numbers or protocols they are limited in using, and I want to impose only the absolute minimum of controls in order to deliver as much of an unfiltered / unrestricted service as I can. I try to find reasonable compromises. Hell, I myself run an openvpn server listening on udp port 53 for exactly the reason of being able to vpn thru restrictive firewalls because it's important to me.
Also, you should have sufficient layer-3 hierarchy in your network to have the ability deploy policies/mitigation tools at your transit edge which do not affect your customer aggregation edge, and vice versa. If you don't currently have separation of these topological roles, then implementing same should be a priority.
That may be a wonderful design goal in theory, but our 'transit edge' as you call it, is a pair of linux boxen that do not have any effective interface for implementing policies or mitigation tools. Since the broadband aggregation is just one hop away from the transit edge , I think it makes sense to implement the controls here anyways. My real goal is to protect the interior network from 400+mbps floods when those links themselves don't have more than 100mbps each, which would result in wider problems as they got saturated. There is no other way for internet sourced traffic to hit these links with that level of traffic anyways since there's no internet facing ip addresses other than customer point to point addresses. If I really had my druthers, I would be limiting customer rates at the broadband aggregation point but that would take a lot more work.
Mike- _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
