[j-nsp] Core network design for an ISP

Saku Ytti saku at ytti.fi
Tue Mar 29 09:46:46 EDT 2016


On 29 March 2016 at 16:05, Mark Tees <marktees at gmail.com> wrote:
> There is a very nice example in the Doug Hanks MX book of what a
> comprehensive lo0 filter looks like. Complete with instructions on how to
> roll it out from memory.

I arrogantly stand behind my statement that all lo filters I've seen
are fundamentally broken.

It's very hard to read, due to unjustifiiable level of abstraction.
I'll only quickly glance through IPv4 and quicker IPv6.

1. example treats internal and external ICMP the same, causing false
positives for ICMP monitoring during attack
2. ICMP ND is not limited to TTL 255, meaning anyone from Internet can
congest your next-hop resolution, not just connected attacker
3. it treats 'tcp-established' as magic toggle without verifying
source-address, allowing anyone to inject potentially 0day
packet-of-death parsing bugs abusing packets
4. it does not consistently verify daddr, allowing l3 mpls vpn
customer potentially to hammer control-plane
5. it does not discriminate various BFD modes, which have different
security posture (singlehop can limit ttl=255, multihop cant, echo and
control are different)
6. it uses 'port' match, allowing crafted source port to reach any
destination port (bgp peers can reach ssh port)
7. it does not discriminate different OSPF operations, your most
likely OSPF will work with TTL==1, which is additional hurdle for
attacker
8. it does not limit VRRP to ttl 255
9. it does not limit copy protocols (http, https,...) to
connected/establlished state
10.  it does not discriminate between basic and extended LDP discovery
11. it uses 'next-header' as discard match, you should only use it as
permit match, because it's easy to circumvent

That is just 10min look. It's very complicated approach yet not
particularly secure one. But at least it's less broken than Cymru
secure template.


Few basic principles
a) never use 'port', all bidir TCP needs 'active' and 'passive' rule separately
b) never use prefix-list, always directional source/desination
c) if you run l3 mpls vpn, always verify 'destination-address'
d) have long list of permit/allow, then single discard at the end
e) if standard makes statement about TTL/hop-limit, use it, it's super
critical for ICMPv6 ND particularly
f) only use 'tcp-established' to make rule more strict, not to have
some handy catch-all return traffic permitter
g) avoid high level of abstraction, people will need to be able to
review it, preferably fast, bitrot is serious problem


-- 
  ++ytti


More information about the juniper-nsp mailing list