[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Not announcing (to the greater internet) loopbacks/PTP/infra - how ?
- Subject: Not announcing (to the greater internet) loopbacks/PTP/infra - how ?
- From: karl_gerh at gmx.at (Karl Gerhard)
- Date: Thu, 4 Oct 2018 21:59:44 +0200
- In-reply-to: <[email protected]>
- References: <[email protected]>
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 at 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."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20181004/640745f8/attachment.html>