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

[John Kristoff]

On Wed, 11 Jul 2018 18:22:36 +
Chris Boyd  wrote:

> Team Cymru has a “JunOS Secure Template” that I found a good place to start. 
> It quotes version 4 though.  I think that means it’s well tested?
> 
> http://www.cymru.com/gillsr/documents/junos-template.pdf

That document is old and should be considered unreliable.  I'm speaking
with some authority since I contributed major parts to it, including
the now bad advice of UDP rate rate limits (their demise hastened with
the rise of QUIC/SPDY years ago).

I've been redoing a slew of JUNOS configuration standards and am
documenting them as I go.  I've not finalized new loopback filters yet,
but you might be interested in others and keeping an eye on this repo.
Loopback filters will soon appear within a few weeks.

  

John
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Antti Ristimäki]

- On 13 Jul, 2018, at 11:30, Saku Ytti s...@ytti.fi wrote:

> On Fri, 13 Jul 2018 at 06:19, Antti Ristimäki  wrote:
> 
>> I can see the reasoning behind disabling sub detection, but how would you 
>> then
>> protect e.g. in a peering VLAN a single peer from killing also all the other
>> BGP sessions behind that specific ifl?
> 
> I'm sure you were anticipating my answer, you don't.
> 
> I don't think there is reasonable way to make shared LAN termination
> safe. The sub detection _MIGHT_ work against some unintentional ddos
> vectors in shared LAN, but it can't really work for intentional ddos
> vectors. MX model I was testing against had about 4k policers for
> DDoS, plenty for reasonably protecting protocol*ifl with dynamic
> detection (with static policers, not very reasonable even there). But
> 4k for sub detection? Just use 4k source ports and you congest the
> policers, and when that happens they are compressed to next-level
> (ifl) anyhow.
> But just being able to limit collateral damage to IFL level is huge,
> no other vendor can do it AFAIK.

Right. Also if one has a host in a let's say /64 IPv6 subnet, (s)he can send 
traffic towards the router from quite a many source addresses and thus deplete 
the policers.

Antti



-- 
CSC - Tieteen tietotekniikan keskus Oy:n asiakas- seka sidosryhmarekisterien 
henkilotietojen kasittely kuvataan tietosuojaselosteissa:
https://www.csc.fi/tietosuoja

CSC - IT Center for Science Ltd processes customer and other stakeholder 
personal information in the following way:
https://www.csc.fi/privacy


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [j-nsp] How to maintain scripts

[Jason Healy]

On Jul 13, 2018, at 4:43 AM, amor...@orion.amorsen.dk wrote:
> 
> Maintaining scripts is a bit of a pain.
> 
> Do you have scripts on most of your devices?

We do, but we're a campus not a provider, so:

- we don't upgrade code versions often
- things are pretty homogenous (except for ELS vs non-ELS switches)

We make a lot of use of groups and templating so that the unique part of the 
config stays small.  We reference the scripts from the group config, and use 
version numbers in the script names so we can have multiple versions of the 
same script on the device at the same time and reference them as the config 
changes.

Finally, I crufted up some perl to help with copying and deploying the script 
versions to all the REs in the field so we don't have to do it manually on each 
switch.  I believe we could reference the scripts from a central web server, 
but things don't change often enough and I like having a manual step in the 
process (for the moment) as this is relatively recent.

Jason


___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

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

[Saku Ytti]

On Fri, 13 Jul 2018 at 06:19, Antti Ristimäki  wrote:

> I can see the reasoning behind disabling sub detection, but how would you 
> then protect e.g. in a peering VLAN a single peer from killing also all the 
> other BGP sessions behind that specific ifl?

I'm sure you were anticipating my answer, you don't.

I don't think there is reasonable way to make shared LAN termination
safe. The sub detection _MIGHT_ work against some unintentional ddos
vectors in shared LAN, but it can't really work for intentional ddos
vectors. MX model I was testing against had about 4k policers for
DDoS, plenty for reasonably protecting protocol*ifl with dynamic
detection (with static policers, not very reasonable even there). But
4k for sub detection? Just use 4k source ports and you congest the
policers, and when that happens they are compressed to next-level
(ifl) anyhow.
But just being able to limit collateral damage to IFL level is huge,
no other vendor can do it AFAIK.

Largely the DDoS protection scheme was inspired by ERX, and the whole
sub thing was related to PPPoE subscriber, where amount of keys is far
more finite than in TCP.

As far as I know, Juniper can be control-plane protected better than
any other platform in the market, by large margin, but it's just lot
way harder than what we can realistically expect operators to be able
to do, Schrödinger's control-plane protection, it's there, but it
really isn't.

-- 
  ++ytti
___
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp