Hi, > On Jan 3, 2019, at 2:47 PM, Saku Ytti <[email protected]> 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 _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
