Mailing List Archive

Hi

Any comments on this? @Saku Ytti you probably have good opinions and inside
knowledge?

I cannot be the only one exploring this.

The main objective is to drop anything not explicitly permitted, i.e. set
udp and tcp default policers to zero. With Juniper its easy if you know
what you're doing



On Friday, May 28, 2021, Mark Smith <markrefresh12@gmail.com> wrote:
> Hi list
>
> I'm trying to harden ASR9k box with LPTS. I have read lots of interesting
discussions on the list, e.g. this thread:
https://puck.nether.net/pipermail/cisco-nsp/2016-August/103532.html
>
> I have been testing following lpts configuration. It seems to work fine.
I know it's not necessarily following Cisco's best practices and
recommendations but I dont know exactly why.
>
> Has anybody used this kind of config with or without success? Which kind
of problems should I expect if any?
>
> lpts pifib hardware police
> flow fragment rate 0
> flow bgp default rate 0
> flow udp default rate 0
> flow tcp default rate 0
> flow multicast default rate 0
>
> I welcome all real-world hardened lpts configuration examples.
>
> Naturally I'm also implementing the iACL. But as I come from the world of
Juniper using very strict CoPP is attactive approach. Layered protection.
"Permit what you need and deny everything else".
>
> You never know when things like JSA11147 pop up.
>
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Hey Mark,

> Any comments on this? @Saku Ytti you probably have good opinions and inside
> knowledge?

Sorry, not really. LPTS is quite a blockbox and there is not much you
can do to improve if you have actual control-plane issues after LPTS.
Unlike in Junos where you can have multiple levels of policers (flow
=> ifl => ifd => npu => aggregate) ASR9k has just npu level LPTS
policer, this means if the LPTS policers are being violated there is
collateral damage shared by all ports on NPU. We've had several
outages due to this, the typical reason is the customer has maybe an
L2 loop, and gives us a large rate of say ND/ARP, and all ports
experience L2 cache expiring and total outage.

You can protect yourself from this scenario to a degree with 'lpts
punt excessive-flow-trap' but it is very poorly documented and
understood by everyone, including Cisco. Infact whole LPTS is
extremely poorly understood by Cisco. We recently had an problem on
injection path which caused PE-CE BGP to time out, Cisco spent good
month trying to review our MQC config, even though we kept telling
them LPTS packets are not subject to MQC in either punt or inject
path, but they wouldn't have any of it.
But because LPTS is not subject to MQC you can't put MQC policy to
your customer QoS in, where you police arp/nd/bgp to avoid collateral
damage, as this MQC policy won't be consulted for LPTS punt.

As far as I am aware JNPR Trio is the only networking platform which
actually is possible to protect against motivated attackers, but it is
far too hard to configure correctly.

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Hi

On Friday, June 4, 2021, Saku Ytti <saku@ytti.fi> wrote:
> Sorry, not really. LPTS is quite a blockbox and there is not much you
> can do to improve if you have actual control-plane issues after LPTS.

Thanks for comments. This is very valuable info. What are your thoughts
about:
flow udp default rate 0
flow tcp default rate 0

Are they safe to use? Cisco did not recommend them but I dont understand
why. And they failed to explain. Maybe because they dont understand
themselves either ;)

According to my tests without those configs e.g. unauthorized [1] ssh is
probably punted because router replies with tcp rst (actually multiple rst
packets). After tcp default 0 router does not send response which is better

[1] control-plane management-plane ... allow ssh peer
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

On Fri, 4 Jun 2021 at 17:19, Mark Smith <markrefresh12@gmail.com> wrote:

> Thanks for comments. This is very valuable info. What are your thoughts about:
> flow udp default rate 0
> flow tcp default rate 0
>
> Are they safe to use? Cisco did not recommend them but I dont understand why. And they failed to explain. Maybe because they dont understand themselves either

As LPTS is never going to be particularly safe for attackers but
mostly will work for accidental congestion I would personally not
change anything, until you have realised risk, at least then I will
have some confidence that the change improves availability.

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/