[j-nsp] ACL for lo0 template/example comprehensive list of 'things to think about'?

[Saku Ytti]

Hey,

> And there don't seem to be a way in Junos how to restrict management-plane
> protocols only to certain interfaces no matter what RE filter says.
> In XR it's as easy as specifying a list of OOB or in-band interfaces against
> a list of management protocols,

In practical life IOS-XR control-plane is better protected than JunOS,
as configuring JunOS securely is very involved, considering that MX
book gets it wrong, offering horrible lo0 filter as does Cymru, what
chance the rest of us have?

But IOS-XR also cannot be configured very securely, JunOS can. Main
problems in IOS-XR:

a) Policers are per protocol, one BGP customer having L2 loop, and all
BGP customers in NPU suffer (excessive flow trap may alleviate, but
it's not turn-key and it can be configured perfectly)

b) LPTS packets are not subject to MQC, so you cannot complement LPTS
with MQC. Imagine one customer congesting specific LPTS policer, and
you want to add MQC policer to interface, to relieve the LPTS policer
from trash generated by this customer, not possible

c) IOS-XR does not guarantee that packets not dropped by LPTS are not
dropped later, JunOS technically does not, but in practice it's
extremely rare to drop packets once punted from NPU. After LPTS punt,
TCP packets are hashed to 8 TCP workers, in lab situation single TCP
worker can handle lot more than what single NPU LPTS protocol policer
can admit, but in production environment TCP worker performance may
degrade so much that your XIPC workers are dropping before there are
any LPTS drops, meaning you'll lose 1/8th of your BGP sessions.

Both A and C are being fixed, thanks CSCO. But I'm not very happy how
they chose to fix it.


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.

Of course this cannot happen, because you can't just randomly kill
people new breaking default configs. Which is another issue I think
vendors should address, so that they could evolve out-of-the-box
defaults over time. I  think this would be quite easily solvable, if
in configurations you could declare which standards version you want
to use, and if nothing is declared, it'll use what ever standard the
image defaults to. This way Juniper could keep introducing new
standard config versions, and people could choose to stay in any
specific standard version as long as they want. Keeping backward
compatibility while allowing more sensible defaults.




-- 
  ++ytti