Well I imagine it would only be a portion of traffic. I wouldn't think a router in the UK would capture any US to US traffic through this method, for example. Is that what you mean?

BGP hops are actually AS (autonomous system) numbers, which are not closely correlated with routers or distance.

If an ISP in Los Angeles transits five autonomous systems to reach an ISP in New York, but four to reach an ISP in London, and the London ISP suddenly starts advertising the New York ISP's IP addresses, oops, your packets are now headed to the UK.

Great care is taken to avoid bizarre physical routes for packets, but it still happens constantly. One DSL connection I used in Santa Clara had a propensity for routing packets through Seattle to get to Dallas for a while.

Also the smallest advertisement wins.

if an isp in india advertises all of amazons AWS ranges as /24 or even smaller the routes will go there even if the bigger ranges are closer.

I added some clarification, but that's the general idea. The routers update their routing tables based on the advertisements they get from/through peers networks (as I understand it).

From the perspective of a router trying to route packets, you basically make choices based on what your peer networks are advertising that they can (directly or indirectly -- e.g. route through) service.

[Disclaimer: This is all stuff that I "know" but I've never worked directly with BGP so I'm open to correction.]

So, in summary, when I connect to an IP the only assurance I have (putting aside the application layer e.g. HTTPS) that I'm connecting to the right box is the fact that I made it to some machine with an interface configured to that address? Oh dear.

> when I connect to an IP ...

It is useful to remember that IP is connectionless protocol. The role if IP is just to shuffle packets around from node to node (where many of the nodes are not the source or final intended destination of the packets) in a fairly simplistic way.

> ... to some machine with an interface configured to that address

Technically, the other endpoint does not even need to have an interface configured with that address. You can quite easily configure a box to send replies for any packets that happen to end up to it.

> Oh dear.

There is a good reason why IPsec (etc) was invented.

The problem with end-to-end crypto is that we often think of its security properties mathematically and neglect its practical performance. Obviously this is increasingly not true (Heartbleed probably did more to educate the world on crypto than anything else in history) but if you think of crypto as what it so often turns out to be - something waiting to be broken in semi-spectacular fashion - then I don't think it's so out of line to wish for additional assurances from complementary systems.

Yes, because your computer doesn't know anything about the destination besides its address. So it's not possible for your computer to verify anything else about the host.

Edit: I guess you could use IPSec. It's not perfect, but it's pretty cool that we could have end-to-end crypto at the IP layer. https://en.wikipedia.org/wiki/IPsec#Security_architecture

Well yes, that's obviously true, which is why it's (idealistically speaking) important to verify the routing mechanism.

Of course most of this is mitigated by end-to-end crypto but given that we see all too frequently how fallible that can be, this topic remains of interest. I mean if crypto fails and leaks your private key (a la heartbleed) and it falls into the hands of an attacker who can hijack some BGP routes then that attacker is potentially in a very powerful position. We've seen BGP hijacking by spammers needing clean IPs in the past, so this isn't a totally implausible situation.