Saku Ytti <s...@ytti.fi> writes: > I think best compromise would be, that JNPR would offer good filter, > dynamically built based on data available in config and referring to > empty prefix-lists when not possible to infer and customer can fill > those prefix-lists if needed. And also have functional ddos-protection > configuration out-of-the-box. People who want and can could override > and configure themselves.
That would be really wonderful. A great start would be if there was a way to get just the /32 (or /128) interface IP addresses in apply-groups. Another great thing would be if you could match, in interface filters other than lo0, "is destined for the RP" or the opposite. In most cases, traffic that is destined for the router itself has completely different security requirements to passthrough-traffic, which is also completely different from router-generated traffic. It is a pain to use IP-addresses to guess which category the traffic is. Linux (and therefore RouterOS) does this by having THREE filters, input, output, and forward. On router platforms you only get input and output. In practice JunOS attaches filters to interfaces, so that kind of design would lead to 4 filters: inputlocal, input, output, outputlocal. Having "src-local", "dst-local", and "local" as terms instead would keep it at 2 filters. The challenge might be that the input filter does not yet know whether it is going to forward the traffic to the RP, since input filtering necessarily happens before routing. It would definitely work for output filters. /Benny _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
