On 12/29/2013 04:00 AM, Dobbins, Roland wrote:
On Dec 29, 2013, at 2:00 AM, MIke <[email protected]> wrote:

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.
Causing users to use your recursors by default, plus Open DNS and Google DNS, 
and with an opt-out proviso, does not in any way inhibit their ability to 
access the Internet, while doing so materially contributes to the security of 
your user base.

A default policy exists to deny outbound smtp except to my relays, which the option to__turn it off for any customer who asks. This stops dead cold the infected spamming zombies. I don't feel the same about dns however. Perhaps in the future I would in fact implement something like that with lots of other filtering and so forth as a value added service. But back to the main point, the controls I have to deal with this particular issue are coarse grained and I have a chokepoint in the network that is - in our system - the right place to do this.

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.
In that case, unfortunately, nothing you do is going to matter, anyways, as 
even a very small DDoS attack can take those boxes down completely.



Not true. I've seen more than 600mbps of traffic and, while not in the league of what you see, is still a sizable total of my transit and we kept chunking along. More than that and there is no filtering / qos / mitigation I could do on my side which would be effective since the pipe TO ME would be filled regardless. My upstream doesn't have any blackhole community or other magic available other than panicked phone call to their noc. So while we certainly could get blown off the air, theres a middle ground here where we can fight and remain operational, so thats what this thread is about really.

Mike-
_______________________________________________
cisco-nsp mailing list  [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Reply via email to