[j-nsp] RE filter BCP
jason-jnsp at lixfeld.ca
Thu Jan 3 15:23:34 EST 2019
> On Jan 3, 2019, at 2:47 PM, Saku Ytti <saku at ytti.fi> wrote:
>> 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?
More information about the juniper-nsp