[j-nsp] Dynamic blocklists/blacklists...?

[Chris Morrow]

On Tue, 16 Aug 2005, Jeff Aitken wrote:

> On Tue, Aug 16, 2005 at 07:30:10PM +0000, Chris Morrow wrote:
>> 1) setup dsc0 interface with /30 address
>> 2) setup dsc0 interface with output acl content:
>>    filter drop-all-count {
>>      term deny-count {
>>         then count deny-dsc0 discard;
>>      }
>>    }
>> 3) reset nexthop or set nexthop in quagga/bgpd to /30 far-end
>
> Unless I'm missing something, this only works for dst-ip based
> filtering.  If you have a list of bad src-ips (e.g., from
> IDS/Arbor/whatever) and want to throw away traffic from them, you
> need something else due to the aforementioned difference in how
> Cisco & Juniper implement the uRPF check.
>

oh yea... hrm, silly me. I was trying to avoid a dynamic update to the 
config for you :( oh well.

>
>> be happy, don't do 'dynamic' filters....
>
> Agreed; my preference would be for Juniper to mimic the Cisco behavior
> (i.e., it should be possible to configure the box such that the uRPF
> check FAILS if the route to the src-ip of an incoming packet recurses
> to null0) but as I recall they said that this was hard/impossible.
>

I'm not clear as to why it would be 'impossible' for them to do it, but 
I'm just a chemical engineer :)

> However, as Pedro notes, the distributed flow-spec approach gives
> you more granularity such as the ability to filter based on src-ip,
> proto, port, etc.  It probably won't be long before your favorite
> IDS/DDoS detection software will give you the option of injecting
> filters this way... which is scary. :-)
>

for that I'd look at TIDP... which is a 'competitor' (alternative?) to 
flow-spec... TIDP is supposed to give you a daemon-like functionality on 
any end system that could ask for 'help' from the upstream networking 
devices. Oh well, like many things in the networking world, there are more 
than 1 ways to skin the cat.