Although someone mentioned using non-routable /30 or /31's on private eBGP peers, there hasn't been much broad-ranging discussion of keeping internal infrastructure addresses non-routable. I am thinking of a couple different things here:
1. Backbone addresses: ISPs that hide interface addresses and/or primary loopback addresses, and best practices for doing so? (e.g. traceroutes don't break, but the router uses say Loopback1 address to respond to them, while iBGP uses Loopback0. All Loopback0 address blocks can be filtered at borders.)
2. Public IX addresses: ISPs that do not redistribute the IX prefix into their iBGP or IGP and do not use external next-hops (except local to the connected border router), but instead use the loopback of the border router when propogating these routes within their iBGP mesh. This should not break traceroutes "through" the exchange, but will break any traffic such as ping, spoofed packets, etc. to the exchange from a non-connected router.
Can anyone provide pro/con, better description of config templates for doing this, and/or discussion of major networks that choose to do this, or not do this?
1. Backbone addresses: ISPs that hide interface addresses and/or primary loopback addresses, and best practices for doing so? (e.g. traceroutes don't break, but the router uses say Loopback1 address to respond to them, while iBGP uses Loopback0. All Loopback0 address blocks can be filtered at borders.)
since ibgp's should be peered w/ loopbacks, loopback protection is all
needed as as far as this bgp hysteria goes.
so loopback0 with "secret" addresses for ibgp peering, use a loopback1
to publish router ip addrs to public via looking glass, etc.
next thing to protect is customer ebgp sessions. some providers don't even
route the p2p /30 links used between cust and their backbone (i.e. Sprint).
so that's up to you.
some backbones even filter all traffic destined to backbone prefixes at
ingress points (border routers, cust edge routers)... for example.. att
being one. for example, here comes random test:
starbucks blahdy $ traceroute -M 8 12.123.205.65
traceroute to 12.123.205.65 (12.123.205.65), 64 hops max, 44 byte packets
8 jfk-brdr-02.inet.qwest.net (205.171.230.21) 6.404 ms 6.138 ms 6.145 ms
9 * qwest-gw.n54ny.ip.att.net (192.205.32.169) 6.465 ms !X *
all above options don't necessarily break traceroute as long as you implement
it with care...
Although someone mentioned using non-routable /30 or /31's on private eBGP peers, there hasn't been much broad-ranging discussion of keeping internal infrastructure addresses non-routable. I am thinking of a couple different things here:
1. Backbone addresses: ISPs that hide interface addresses and/or primary loopback addresses, and best practices for doing so? (e.g. traceroutes don't break, but the router uses say Loopback1 address to respond to them, while iBGP uses Loopback0. All Loopback0 address blocks can be filtered at borders.)
If you use multi-hop peering with loopback0, why bother changing the traceroute replies? Alternatively, if you make all traceroute replies from loopback1, then why bother turning on multi-hop BGP?
Hrmmm, would the GTSM work with loopback peering? ISTR it allowed a TTL of 254, which should make it to the loopback interface.
2. Public IX addresses: ISPs that do not redistribute the IX prefix into their iBGP or IGP and do not use external next-hops (except local to the connected border router), but instead use the loopback of the border router when propogating these routes within their iBGP mesh. This should not break traceroutes "through" the exchange, but will break any traffic such as ping, spoofed packets, etc. to the exchange from a non-connected router.
Excellent idea. And one which is, I believe, being used by several people already. Perhaps more wide spread use would help?
I like the second one more than the first since the first is more of a security-through-obscurity than anything else. But even obscurity is better security than nothing.
OTOH, the best security measure right now would be to do something like OpenBSD's random ephemeral port algorithm into the router OSes. Then this "vulnerability" would be far, far less vulnerable.
next thing to protect is customer ebgp sessions. some providers don't even
route the p2p /30 links used between cust and their backbone (i.e. Sprint).
so that's up to you.
some backbones even filter all traffic destined to backbone prefixes at
ingress points (border routers, cust edge routers)... for example.. att
being one. for example, here comes random test:
Couldn't we use 2 /30 subnets on PtP links? 1 /30 with real IPs for ICMP, MTU, reachability etc. and one RFC1918 /30 as secondary for eBGP sessions. I know when a router originates a packet (like with BGP) it sets the source IP to the IP of the interface the packet leaves. Is BGP smart enough when setting up BGP neighbors to use an IP in the same subnet as the neighbor (the secondary interface IP)?
> 1. Backbone addresses: ISPs that hide interface addresses and/or primary loopback addresses, and best practices for doing so? (e.g. traceroutes don't break, but the router uses say Loopback1 address to respond to them, while iBGP uses Loopback0. All Loopback0 address blocks can be filtered at borders.)
since ibgp's should be peered w/ loopbacks, loopback protection is all
needed as as far as this bgp hysteria goes.
no! these are so easy to find!!!!
$ host 65.116.132.145
145.132.116.65.in-addr.arpa domain name pointer lo0.b1.box2.twdx.net.
Couldn't we use 2 /30 subnets on PtP links? 1 /30 with real IPs for
ICMP, MTU, reachability etc. and one RFC1918 /30 as secondary for eBGP
sessions. I know when a router originates a packet (like with BGP) it
sets the source IP to the IP of the interface the packet leaves. Is
BGP smart enough when setting up BGP neighbors to use an IP in the same
subnet as the neighbor (the secondary interface IP)?
in IOS bgp will bind source ip that is relevant to the subnet it is being peered
with, even if it is a secondary ip. i am not sure if it binds the ip to primary
ip for the first time, then fall back to secondary ip as primary fails though..
all i know is that when i've tried it by putting a bogus ip as primary, bgp
session did turn up, but took a little longer than usual.. didn't investigate
any further however.
Only flawed implementations have to use TTL of 254 when you have a
session between two adjacent loopbacks. But I think those still
exist...
(TTL should only be decremented when _forwarding_, and I don't think
you could argue that you need to _forward_ a packet from your ingress
interface to your _loopback_ interface..)
> (TTL should only be decremented when _forwarding_, and I don't think
> you could argue that you need to _forward_ a packet from your ingress
> interface to your _loopback_ interface..)
Well, if that were the case, then you wouldn't need multi-hop to do
loopback peering.
Different issue (directly connected interfaces vs not directly
connected).
Easy test: Connect two routers (I used Ciscos) to the same Ethernet
switch, sniff the traffic between them. Ping from one router to the
other on the directly connected interfaces, observe TTL with sniffer.
Ping from loopback on one router to loopback on the other, observe TTL
again. I see the *same* TTL in both cases, which means that at least
for the IOS version I was testing, TTL is not decremented when sending
from the loopback interface.
(TTL should only be decremented when _forwarding_, and I don't think
you could argue that you need to _forward_ a packet from your ingress
interface to your _loopback_ interface..)
Well, if that were the case, then you wouldn't need multi-hop to do
loopback peering.
Um, only if there were no intervening hops: i.e. where the
physical mesh is
A---B
> >
C---D
Then A<->D, and B<->C peering requires multihop anyway.
heh