[j-nsp] IPv6 RE protection

[Saku Ytti]

On (2015-04-27 02:40 +0800), Amarjeet Singh wrote:

> Hello - Security is all or none thing, if something left open risk is
> always there.

I would describe it less as binary off/on and more as layers. Each layer
adding budget requirements to the attacker, but also are increasingly
OPEX/CAPEX heavy for you to implement and may cause significant customer
dissatisfaction.
Notion that you have 'all' security, is almost certainly false.

It is probably exponential in its nature, cost increasing and amount of
attackers removed decreasing, so you almost certainly never ever will meet the
long tail of NSA/GCHQ and friends.
Often in commercial application you should just do what regulator mandates and
client contracts require, doing more way be business risk.

> You should apply IPv6 filters too.
> Juniper MX series book has very nice example for it, have a peek to it.

My top 5 errors people make:

1) use of 'port' (like port bgp, or anything else) - this allows attacker
reach arbitrary port in our device

2) omit 'destination-address', we may not be able to trust source-address in
every L3 MPLS VPN case, but we can trust that we don't provision
infrastructure addreses to L3 VPN customer interfaces

3) for tcp, don't do shortcuts, allow both directions separately unless you
can guarantee direction (bgp passive). Be familiar with your ephemeral port
range to avoid excessive range

4) be familiar with the protocol, does it impose TTL limits, if so, enforce
them. Does it impose source-port limits? If so, enforce them.

5) policing in junos lo0 filters is not useful or practical (due bps only and
due to build-in unconfigurable NPU => LC_CPU policer). Implement
ddos-protection, it's pps based, unfortunately you need to reconfigure every
protocol, so it's lot of cruft in config ('apply-flags omit' is your friend),
usually 'sub' level is useless, turn it off, I'd recommend turning 'ifl' level
statically on (not auto).

-- 
  ++ytti