Alternate and/or hidden infrastructure addresses (BGP/TCP RST/SYN vulnerability)

Thu Apr 22 23:28:58 UTC 2004

On Apr 22, 2004, at 6:36 PM, Lane Patterson wrote:

> 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.

-- 
TTFN,
patrick