Managing ACL exceptions (was Re: Filter NTP traffic by packet size?)

Jay Ashworth jra at
Fri Feb 28 14:04:18 UTC 2014

You mean, like Bcp38(.info)?

On February 28, 2014 9:02:03 AM EST, Ray Soucy <rps at> wrote:
>I'm wondering how many operators don't have systems in place to
>quickly and efficiently filter problem host systems.
>I see a lot of talk of ACL usage, but not much about uRPF and black
>hole filtering.
>There are a few white papers that are worth a read:
>If you have uRPF enabled on all your access routers then you can
>configure routing policy such that advertising a route for a specific
>host system will trigger uRPF to drop the traffic at the first hop, in
>This prevents you from having to maintain ACLs or even give out access
>to routers.  Instead, you can use a small router or daemon that
>disables hosts by advertising them as a route (for example, we just
>use a pair of small ISR 1841 routers for this); this in turn can be
>tied into IPS or a web UI allowing your NOC to disable a problem host
>at the first hop and prevent its traffic from propagating throughout
>the network without having to know the overall architecture of the
>network or determine the best place to apply an ACL.
>I've seen a lot of talk on trying to filter specific protocols, or
>rate-limit, etc. but I really feel that isn't the appropriate action
>to take.  I think disabling a system that is a problem and notifying
>its maintainer that they need to correct the issue is much more
>sustainable.  There are also limitations on how much can be done
>through the use of ACLs.  uRPF and black hole routing scale much
>better, especially in response to a denial of service attack.
>When the NTP problems first started popping up, we saw incoming NTP of
>several Gb, without the ability to quickly identify and filter this
>traffic a lot of our users would have been dead in the water because
>the firewalls they use just can't handle that much traffic; our
>routers, on the other hand, have no problem throwing those packets
>I only comment on this because one of the comments made to me was
>"Can't we just use a firewall to block it?".  It took me over an hour
>to explain that the firewalls in use didn't have the capacity to
>handle this level of traffic -- and when I tried to discuss hardware
>vs. software filtering, I got a deer-in-the-headlights look. :-)
>On Thu, Feb 27, 2014 at 8:57 PM, Keegan Holley <no.spam at>
>> It depends on how many customers you have and what sort of contract
>you have with them if any.  A significant amount of attack traffic
>comes from residential networks where a "one-size-fits-all" policy is
>definitely best.
>> On Feb 26, 2014, at 4:01 PM, Jay Ashworth <jra at> wrote:
>>> ----- Original Message -----
>>>> From: "Brandon Galbraith" <brandon.galbraith at>
>>>> On Wed, Feb 26, 2014 at 6:56 AM, Keegan Holley
><no.spam at>
>>>> wrote:
>>>>> More politely stated, it's not the responsibility of the operator
>>>>> decide what belongs on the network and what doesn't. Users can run
>>>>> services that's not illegal or even reuse ports for other
>>>>> applications.
>>>> Blocking chargen at the edge doesn't seem to be outside of the
>>>> of possibilities.
>>> All of these conversations are variants of "how easy is it to set up
>>> default ACL for loops, and then manage exceptions to it?".
>>> Assuming your gear permits it, I don't personally see all that much
>>> Bad Actorliness in setting a relatively tight bidirectional ACL for
>>> Random Edge Customers, and opening up -- either specific ports, or
>>> just "to a less-/un-filtered ACL" on specific request.
>>> The question is -- as it is with BCP38 -- *can the edge gear handle
>>> And if not: why not?  (Protip: because buyers of that gear aren't
>>> agitating for it)
>>> Cheers,
>>> -- jra
>>> --
>>> Jay R. Ashworth                  Baylink                      
>jra at
>>> Designer                     The Things I Think                     
> RFC 2100
>>> Ashworth & Associates          2000 Land
>Rover DII
>>> St Petersburg FL USA      BCP38: Ask For It By Name!           +1
>727 647 1274
>Ray Patrick Soucy
>Network Engineer
>University of Maine System
>T: 207-561-3526
>F: 207-561-3531
>MaineREN, Maine's Research and Education Network

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

More information about the NANOG mailing list