[j-nsp] RE filter BCP

[Jason Lixfeld]

Hi,

> On Jan 3, 2019, at 2:47 PM, Saku Ytti <saku at ytti.fi> wrote:
> 
> Hey,
> 
>> I’ve noticed that publication is a little more liberal in it's RE filtering suggestions vs. say, Juniper MX Series, O’Reilly.
>> 
>> Having dug through both, the Juniper guide seems more platform agnostic, which probably contributes to why it’s more liberal (variations in cross-platform feature support).
> 
> At least the O'Reilly RE filter example is not only poor design but
> also broken, for using stuff like 'match port bgp’.

If you match on specific source (and presumably specific destination) addresses, why is a directionally agnostic port match bad?  Or is it not so much bad as it is being too lazy to create a second term or an established filter/term?

> General strategy
> 
> a) allow as specifically as RFC allows what you must, no broad permits
> b) always match destination-port
> c) always match destination-address if you're running L3 MPLS VPNs

I must be misunderstanding because I’m sure you’re not suggesting that in the absence of L3VPNs, omitting destination address matching is acceptable?

> d) TCP when either end can initiate requires two terms

As opposed to another filter or a single term matching established for already specifically configured allow terms?

> e) have ultimate deny all rule
> 
> On top of that, configure _every_ ddos-protection protocol.

Assuming a policer falls into the category of ddos-protection protocol, what sorts of others are you referring to?

> -- 
>  ++ytti