[j-nsp] SCU / flows for ingress traffic filtering.

Thomas Mangin thomas.mangin at exa-networks.co.uk
Tue Oct 18 19:05:25 EDT 2005


Pedro,

Thank you for your answer.

> You can indeed use SCU to do source-based filtering that is propagated
> via routing. And DCU for destination-based filtering...

As long as you make sure that you do not have conflicts between them :p

> Flow routes however allow you specify any criteria that you can
> configure in a (stateless firewall) and that is not "hop" specific (e.g.
> ttl).

Reading your comment, I was wondering if flow feature needed any
specific PIC and JunOS to work or if they could be used "out of the box".

> Also, the inet flow address family implies a given validation procedure
> (which can be turned off). Essentially "flow" advertisements are only
> accepted if they have been advertised by the unicast next-hop of the
> destination prefix. The hope is that this will allow for automated
> filtering in a inter-as scenario.

For what I can see from your example it can be turned off per neighbour,
so I guess that this validation will only be used for ebgp peers.

However it seems that I am not imaginative enough to see how the
automation you are speaking about was thought off. Are you saying that
the idea is to replace the current RADB filters being built ? You lost me.

> SCU and rpf-check are useful tools for a given set of applications.

rpf is way insufficient when it comes to filter incoming traffic.
Turning strict mode with feaseable path will knock down a good part of
the net. So strict mode can only be used for :
1 - known peers with symetrical routes
2 - customer single home or multi-home with symetrical routes
3 - all your "gateway interfaces"
For anything else you have to use loose mode which is no much better
than maintaining a list of bogon, or better getting it through team cymru.
This is why I used SCU via tags to limit what can enter my network
without having to maintain stupid acl/firewall prefix-list on every router.

> imho, inetflow has a slightly different application set.

I would be interrested in hearing about you think how one and the other
should be used (if you do not care). I never encountered this feature
before today and I must admit that I am interrested.

>From what you are saying it look like flows had been designed to do
"nicely" what I achieved with SCU/DCU and could be easier to maintain.

(I will take no offence to be told that what I done is not the "best"
way possible, it is to be expected with only few months of Juniper
experience).

Regards,

Thomas
-- 
Exa Networks Limited - UK - AS30740 - www.exa-networks.co.uk
nic-handle : MANG-RIPE   website  : thomas.mangin.me.uk
GPG key ID : 0xFB8B81A1  PGP key  : /pgp.html
Inoc-DBA # : 30740*TOM   Office # : +44 (0) 845 145 1234


More information about the juniper-nsp mailing list