Hacker News new | past | comments | ask | show | jobs | submit login

BGP route/prefix leaks. BGP is the protocol that deals with routing across the various internet backbones (known in the protocol as "autonomous systems", identified by an AS number).

On that protocol, the various systems broadcast what prefixes they can route, which then affects the rest of the networks' routing decisions.

By error or malice, a system can report a prefix they cannot or should not route, causing other systems to start routing traffic across it. This will either just cause weird routes (such as ones going through certain suspicious countries), cause poor performance for those routed, or no connection at all for those routed.

At 3-4 major leaks per year it seems like we should probably fix BGP one of these days...

We'll get right on that after everyone has IPv6 deployed.

I think the pressure to implement better ROA checking and something like RPKI will be much stronger than the push to IPv6 was if we keep having major route leaks multiple times a year.

Eventually some governments will have to get involved...

The way I understand it it's not BGP, it's mostly human error, or malicious intent.

The protocol is fine.

An unauthenticated protocol that allows unsigned routes to be blindly accepted is not a good protocol, that's why Cloudflare has been pushing RPKI for a while https://blog.cloudflare.com/rpki/ https://blog.cloudflare.com/rpki-details/

It has authentication and requires explicit configuration to form a neighbor relationship.

BGP was designed for operators to implement a routing policy. In most implementations it allows everything by default with no modifications to route metadata, so if you do not set up your policy correctly you'll have issues like this.

It has authentication for only one hop, if routes propagated all the way up the chain with signatures, it would be much easier to block/limit bad AS behavior.

Your peering relationship is only for one hop. What it lacks is prefix/path validation, not authentication.

But authentication of every advertised range all the way up the chain would allow upstream providers to easily differentiate valid large prefix announcements that were done intentionally (e.g. big ISP announcing some routes) from crazy nonsense done by an unknown party that isn't a big ISP. We definitely need prefix filtering, but there needs to be some easily verifiable source of identity tied to each announcement to be able to automate the process of accepting and rejecting large prefix announcements.

A protocol that allows "human error" or "malicious intent" to take down entire swathes of the internet due to being entirely unauthenticated, is not "fine".

What you are describing is a protocol problem.

Malicious intent could likely be mitigated with cryptography. E.g., publishing a prefix requiring a signature from its owner.

Such system would also contain human error to a smaller set of possible faults.

No system failure is ever "human error". It's faulty system design.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact