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

[Pedro Roque Marques]

Thomas Mangin wrote:

> 
> 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".
> 
No. It is supported on all m/t/j series.

> 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.

For ebgp routes, essentially.

> 
> 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.

RADB has routing policy. We are talking about traffic filters.

The number one app is DDoS attacks... currently it is not uncommon to 
have DDoS traffic that ammounts to several Gbps. Many ASes cannot sink 
such ammounts of traffic w/o serious performance degradation... when 
attacked they need help.

They need to be able to ask their peers to block traffic that is 
destinated to them.

This is currently done w/ <destination>/32 granularity using blackhole 
communities that most transit providers support.

The idea behind flow routes is to address 2 issues:
  - <destination>/32 is not really granular enought... i.e. the attacker 
is happy in the end given that the destination is offline for all traffic.
  - <destination>/32 are tricky to handle... given that they are more 
specific they will block that destination... even if the guy injecting 
the more specific shouldn't be doing so.

> 
> 
> 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.

Why is that ? "feasible-path" should allow you to deal w/ assymetrical 
paths... i.e. MED prefers exit point such and such. It sort of requires 
a consistent set of advertisements... i.e. for preference to be 
expressed via MED and not by not advertising a least preferred route.

> 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.

Agree... loose mode is pointless. I used to have this discussion w/ 
Jared when he was asking us for "loose mode"... i kept telling him that 
it would be easier for us to provide the script kids w/ a library that 
check if a randomly assigned address is allocated or not ;-)


> 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.

inet flow is ment to deal w/ specific know "flow" patterns you want to 
intercept (you can choose to do stuff w/ traffic other than drop).

For "proactive" filtering, you want solutions like rpf-check w/ are 
trying to apply a level of sanity checking of your data patterns w/ the 
control information.

You could also sample some packets and deliver that to an IDS system. 
This IDS can then generate specific pattern of traffic currently known 
to be bad or suspicious...

You may need a combination of all the methods above :-)

   Pedro.