Hello,
I’ve seen mention on this list and other places about keeping one’s PTPs / loopbacks out of routing tables for security reasons. Totally get this and am on board with it. What I don’t get - is how. I’m going to list some of my ideas below and the pros/cons/problems (that I can think of at least) for them.
- RFC 1918 for loopbacks and PTP
- Immediately “protects” from the internet at large, as they aren’t routable.
- Traceroutes are miserable.
- Use public block that is allocated to you (i.e. PI) - but not announced.
- So would this be a totally separate (from user/customer prefixes) announcement and allocation ? In other words, let’s say you were a small ISP getting started. You manage to get a /20 from a broker (IPv6 should be “easy”). Do you also now go out and get a /23 (I’m making these sizes up, obviously all of these will vary based on ISP size, growth plan, etc.). You have the /23 registered to you (with proper rDNS delegation, WHOIS, etc.). But you simply don’t announce it ? I’d say I need this /23 day one to even build my network before it’s ready for customers.
- On the IPv6 front - would a RIR give you your /32 and then also a /48 (for loop/PTP) ?
- Deaggregate and not announce your infra
- Bad net behavior out of the gate with this method. The opposite of elegant.
- Keeping with previously made up / arbitrary prefixes - for your /20 - you’d end up announcing 2 x /23, 1 x /22 and 1 x /21. I’m too lazy to enumerate the IPv6 gymnastics, but with IPv6 you could “waste” a bit more to get to boundaries that are a bit easier to work with I suppose.
Thanks in advance for insights on this.
this is what we do. We are lucky enough to have plenty of address
space which was quite correctly assigned in the first place. This is
nice, except for one thing: other networks having urpf towards us. It
makes traceroutes from their side to ours useless.
Other than that, we use bgpmon to monitor for the absence of
advertisements /leaks for those internal prefixes. Works really well.
If you’re MPLS enabled, one implementation could see place the loop/infra/p2p in the global table and customer/internet traffic inside a VRF.
I’ve seen mention on this list and other places about keeping one’s PTPs / loopbacks out of routing tables for security reasons. Totally get this and am on board with it. What I don’t get - is how. I’m going to list some of my ideas below and the pros/cons/problems (that I can think of at least) for them.
- RFC 1918 for loopbacks and PTP
- Immediately “protects” from the internet at large, as they aren’t routable.
- Traceroutes are miserable.
Also breaks PMTUD which can break TCP for everybody whose packets
transit your router. So don't do this.
- Use public block that is allocated to you (i.e. PI) - but not announced.
This works.
- Deaggregate and not announce your infra
Not great.
Another option is to let it be announced but filter the packets at your border.
I wonder if it would be useful to ask the IETF to assign a block of
"origination-only" IP addresses... IP addresses which by standard are
permitted to be the source of ICMP packets but which should be
unreachable by forward routing.
Regards,
Bill Herrin
Hello Brandon,
instead of not announcing it you can send it to your upstream and tag it with no-export.
That way you can still see your router in traceroutes if the source ASN of the traceroute doesn’t do uRPF.
If you don’t have a separate range from which you assign PTP/loopback addresses, but your upstream offers a BGP blackhole community you can permanently blackhole your PTPs/loopbacks/infra at your upstream if you want to increase your security. Another way to keep your traceroutes pretty. However, if it’s thousands of /32s then you should probably talk to your upstream before doing that. 
Regards
Karl
no - this would be abused for ddos.
Nick
From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of William
Herrin
Sent: Thursday, October 04, 2018 8:53 PM
> - RFC 1918 for loopbacks and PTP
> - Immediately “protects” from the internet at large, as they aren’t
routable.
> - Traceroutes are miserable.
Also breaks PMTUD which can break TCP for everybody whose packets
transit your router. So don't do this.
Only if you have lower MTU on your core links than on your edge -which is a huge design flaw.
Also most of the internet backbones out there are MPLS based meaning the traceroutes are well "sparse" to say at least, so I wouldn't worry about this that much.
Another option is to let it be announced but filter the packets at your border.
That defeats the whole purpose of this exercise.
Yes we all use infrastructure ACLs to protect our infrastructure, but if the infra-block is advertised the DDoS is still delivered to your doorstep even if you filter it at the edge interfaces the damage has been done already -as your upstream pipes are full.
If your infra-ranges are not advertised your infrastructure simply can't be targeted by any DDoS attack.
adam
... unless you happen to provide a "MTU1500" service over a jumboframe (more than 9100) backbone, which you can very easily do these days. In which case fragmentation/packet too big should never occur.
Traceroutes remain miserable, at least from outside towards your network.