Not announcing (to the greater internet) loopbacks/PTP/infra - how ?
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. -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 0641 D285 A36F 533A 73E5 2541 4920 533C C616 703A "For thousands of years men dreamed of pacts with demons. Only now are such things possible."
Le jeu. 4 oct. 2018 à 21:12, Brandon Applegate <brandon@burn.net> a écrit :
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.
- Use public block that is allocated to you (i.e. PI) - but not announced.
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.
On Thu, Oct 4, 2018 at 3:10 PM Brandon Applegate <brandon@burn.net> wrote:
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 -- William Herrin ................ herrin@dirtside.com bill@herrin.us Dirtside Systems ......... Web: <http://www.dirtside.com/>
William Herrin wrote on 04/10/2018 20:53:
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.
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
On Thu, Oct 4, 2018, at 21:53, William Herrin wrote:
On Thu, Oct 4, 2018 at 3:10 PM Brandon Applegate <brandon@burn.net> wrote:
- Traceroutes are miserable.
Also breaks PMTUD which can break TCP for everybody whose packets transit your router. So don't do this.
... 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.
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 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ *From:* Brandon Applegate [mailto:brandon@burn.net] *Sent:* Thu, Oct 4, 2018 9:07 PM CEST *To:* NANOG mailing list *Subject:* Not announcing (to the greater internet) loopbacks/PTP/infra - how ?
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.
-- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 0641 D285 A36F 533A 73E5 2541 4920 533C C616 703A "For thousands of years men dreamed of pacts with demons. Only now are such things possible."
participants (8)
-
adamv0025＠netconsultings.com -
Brandon Applegate -
Jason Lixfeld -
Karl Gerhard -
Nick Hilliard -
Pierre Emeriaud -
Radu-Adrian Feurdean -
William Herrin