BGPexpert.com - Your friendly neighborhood BGP expert is now IPv6 enabled

Interdomain Routing & IPv6 News

Has BGP routing security failed (yet)? (posted 2022-12-13)

In the thorough style we've come to expect from him, Geoff Huston tries to answer the question Is Secured Routing a Market Failure? Please read about the market aspect (and the limitations imposed on the IETF by big router vendors) in that article. His final conclusion is broader, through:

But mostly it's a failure because it does not deliver. Security solutions that offer only a thin veneer of the appearance of improvement while offering little in the way of improved defence against determined attack are perhaps worse than a placebo.

20 years ago I went to my first IETF meeting and there I learned about S-BGP and soBGP. It would take another almost ten years for RPKI to be standardized and fifteen years for the BGPSEC specification (which is largely S-BGP with the RPKI functionality removed) to be published. RPKI is gaining some traction but hasn't been able to stop at least some determined attackers. There are no production level implementations of BGPSEC after five years.

So why is that? True, if people would be prepared to pay extra for secure routing, we'd have it by now.

But I think the bigger issue is failure to understand the problem.

Looking at the valley-free model, we can observe that the right hand part of the network hierarchy is trusted by the sender of the routing updates / receiver of the packets, while the left hand side is trusted by the receiver of the routing updates / sender of the packets.

This hierarchy is pretty flat, so there's usually only a handful of networks on each side. So telling the world that those are networks you trust should be something we can do reasonably efficiently. Then, the only thing is to make sure that there are no network hops in the path that aren't trusted by either side.

Earlier this year, RFC 9234 "Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages" was published. This adds some information to BGP that lets it detect paths that aren't valley-free. The nice thing about this mechanism is that it protects two networks that implement the mechanism against mistakes made by networks that don't implement the mechanism.

We still need better mechanisms to thwart determined, purposeful attackers, but the good news is that we've made life a lot harder for those already. So even though we're not there yet when it comes to secured routing, it's not so much that we've failed, but that we are taking too much time to succeed.

→ What can be learned from BGP hijacks targeting cryptocurrency services? (posted 2022-11-24)

Interesting blog post on the APNIC blog by Doug Madory:

On 17 August 2022, an attacker was able to steal approximately USD 235,000 in cryptocurrency by employing a BGP hijack against the Celer Bridge, a service that allows users to convert between cryptocurrencies.
In this blog post, I discuss this and previous infrastructure attacks against cryptocurrency services. While these episodes revolve around the theft of cryptocurrency, the underlying attacks hold lessons for securing the BGP routing of any organization that conducts business on the Internet.

Using BGP to steal cryptocurrency is happening with some regularity now...

The important lesson comes at the end: Amazon shouldn't have RPKI ROAs for a /10 and a /11 with a maximum prefix limit of /24.

This way, the attacker, thanks to an ISP that didn't properly filter its customer's BGP announcements, was able to advertise a /24 out of Amazon's address space and have that announcement be labeled "valid" by RPKI route origin validation.

Amazon advertises a /11, and if the maximum prefix length in the ROA for that /11 had been just /11, the attacker wouldn't have been able to "shoplift" just that /24, but they'd have to go head-to-head against Amazon for that entire /11. That would have had a much lower chance of success and much higher chance of being noticed quickly.

(Shameless plug: if all that RPKI and ROA talk is gibberish to you, my new BGP e-book has a section on what RPKI is and how it works.)

Read the whole article

New e-book: Internet Routing with BGP (posted 2022-11-18)

I did it again... I wrote another book.

20 years ago O'Reilly published my first book, titled simply “BGP”. My goal with that book was to write the book that I would have liked to have read when I started my journey with the Border Gateway Protocol, the internet's routing protocol.

Although amazingly, we still use the same version 4 of the BGP protocol as in 1994, a lot has changed. As updating my previous book was not in the cards, I decided to write a completely new book about BGP. It's called “Internet Routing with BGP” and it's now available as an e-book. See the end of the article for details and links.

What is BGP and what does it do?

The super short version is that BGP lets routers make IP packets finder their way across the internet. You need BGP to be able to use connections to two or more ISPs.

What makes BGP so fascinating: scale and business

There are several other routing protocols, and on a technical level, BGP is not the most interesting or even the most complex one. I think (and have written about how) OSPF is a strong contender in that race.

One thing that makes BGP fascinating is that it connects together something like a million routers in about 100,000 networks from different organizations. All these routers talk to each other in real time. Actions by one have consequences for all the others.

But the real 🤯-moment comes when you realize that if you're an ISP, BGP runs your business. For instance, BGP's hot potato routing means that traffic is handed off to the next network as soon as possible. The implication is that the receiving network has to carry the traffic most of the distance. Which is why internet service for consumers is relatively expensive (vast majority of traffic is incoming and thus high long distance costs) while hosting services are relatively cheap (mostly outgoing traffic so low long distance costs).

Valleys are costly

As BGP runs a service provider's business, it's important that BGP knows about the business relationship between two networks that connect together. In the figure below, networks 600 and 700 at the bottom are customers of networks 30, 40 and 50. Those are in turn customers of networks 1 and 2. The arrows show in which direction the money flows.

Valley-free and thus valid paths

The blue ellipse shows the part of the internet that gets paid to handle traffic to and from network 600. The pink ellipse shows the part of the internet that gets paid to handle traffic to and from network 700. Network 1 gets paid by both. Some networks have a peer relationship, where they exchange traffic without money changing hands. (Shown as arcs here.)

This means that all the green paths in sub-figures 2 to 5 are valid paths between 600 and 700, where all the service providers involved get paid. The path in 2 is the shortest, so that is the best one. But what if 700 is not a customer of 40:

Invalid paths with valleys

There are still several paths possible through network 40, but as 40 is paid by neither 600 nor 700, handling traffic between those network would be giving away service for free. So BGP needs to know about the business relationships between connecting networks in order to avoid the red, invalid paths.

Interestingly, all the invalid paths have a “valley”, while none of the valid paths have such a valley. The valleys happen when traffic moves up the service provider hierarchy, then starts moving down or sideways, but then doesn't continue to move down, but instead moves up or sideways again. These valleys indicate that someone doesn't get paid. Note that the earlier green path number four is still a valid path here.

In practice, paths that aren't valley-free indicate that someone made a mistake with their BGP setup, causing a “route leak”. Those leaks attract traffic that then usually doesn't make it to the intended recipient. Or perhaps only after the leaker eavesdropped on it.

So, please BGP: no valleys.

A bit more about the book

I believe this is one of the first books that covers the RPKI BGP security mechanism, with several examples showing how to apply RPKI and how it works. Most of the book shows configuration examples and the resulting output and then discussing what happens when and why.

The book is available from Amazon (Kindle format), from Apple (EPUB format / Apple Books) or from Google (PDF and EPUB formats). You can also get a site license directly from me (PDF and EPUB formats). And you can get sample chapters if you follow that link. If you want to see the example configurations in action (before or after getting the book), download the BGP minilab. This contains scripts and router configurations to run the examples on your own computer under Docker.

And after slowing down the past few years for pandemic reasons, I'll be doing my BGP training courses again in the near future, based on the new book.

My BGP minilab (posted 2022-11-11)

When I wrote my first BGP book I painstakingly made the config examples on actual Cisco routers. In my opinion, it's crucial to make sure that configuration examples that go in a book actually work.

So when I started writing my new BGP book, I did the same. But this time, I used open source routing software (FRRouting) running in Docker containers. Basically, those containers are very light-weight virtual machines.

This makes it possible to run a dozen virtual routers that start up and shut down in just a few seconds. So it's very easy to run different examples by starting the required virtual routers with the configuration for that example.

This was super useful when I was writing the book.

So I thought it would also be very useful for people reading the book.

So I'm making the "BGP minilab" with all the config examples from the book available to my readers. Download version 2022-11 of the minilab that goes with the first version of the book here.

You can also run the examples in the minilab if you don't have the book. And you can create your own labs based on these scripts.

The minilab consist of four scripts:

start: to start an example or lab
connectrouter: connect to an already running virtual router
stoprouters: to stop all running routers
run-gortr: runs the GoRTR RPKI cache

There are Mac/Linux shell script and Windows Powershell versions of each script.

BGP Security

good

Session hijacking is hard to do for someone who can't see the TCP sequence number for the TCP session the BGP protocol runs over, and if there are good anti-spoofing filters it is even impossible. And of course using the TCP MD5 password option (RFC 2385) makes all of this nearly impossible even for someone who can sniff the BGP traffic.

Nearly all ISPs filter BGP information from customers, so in most cases it isn't possible to successfully inject false information. However, filtering on peering sessions between ISPs isn't as widespread, although some networks do this. A rogue ISP could do some real damage here.

There are now two efforts underway to better secure BGP:

Secure BGP (S-BGP) is developed by Bolt, Beranek and Newman (BBN). It has been around for several years and there is a proof-of-concept implementation. S-BGP tries to secure all aspects of the BGP protocol, and subsequently needs several signature checks for each BGP update, making the protocol relatively heavy-weight. You can see my earlier rants on S-BGP at the top of this page. Note that I'm not as anti-S-BGP as I used to be any more, although I still think implementing the protocol will be expensive because routers will need lots of extra memory (up to four times as much) and CPU power (possibly dedicated crypto hardware) and this aspect deserves some serious attention.

Secure BGP (S-BGP) index at BBN.

Secure Origin BGP (soBGP) has surfaced fairly recently and hails from Cisco. There are no implementations so far. soBGP mainly focusses on securing the relationship between prefixes and the source AS number, and doesn't need as many computationally expensive checks as S-BGP. However, the protocol can easily be expanded to perform more checks.

draft-ng-sobgp-bgp-extensions-00.txt (main soBGP draft)
draft-white-sobgp-bgp-extensions-00.txt (deployment considerations)

(If the links don't work, the drafts have expired; you'll have to use a search engine to find them.)

what I wrote about this

Working Around BGP: An Incremental Approach to Improving Security and Accuracy of Interdomain Routing

The IETF RPSEC (routing protocol security) working group is active in this area.

BGP and Multihoming

This sounds simple enough, but as always, there is a catch. For regular customers, it's the Internet Service Provider who makes sure the rest of the Internet knows where packets have to be sent to reach their customer. If you are multihomed, you can't let your ISP do this, because then you would have to depend on a single ISP again. This is where the BGP protocol comes in: this is the protocol used to carry this information from ISP to ISP. By announcing reachability information for your network to two ISPs, you can make sure everybody still knows how to reach you if one of those ISPs has an outage.

Want to know more? Read A Look at Multihoming and BGP, an article about multihoming I wrote for the O'Reilly Network.

For those of you interested in multihoming in IPv6 (which is pretty much impossible at the moment), have a look at the "IPv6 multihoming solutions" page.

Table of contents (for this page):

inet⁶ consult

BGP routing courses

Interdomain Routing & IPv6 News

What is BGP and what does it do?

What makes BGP so fascinating: scale and business

Valleys are costly

A bit more about the book

My Books: "BGP" and "Running IPv6"

BGP Security

What is BGPexpert.com?

Ok, but what is BGP?

BGP and Multihoming

Are you a BGP expert? Take the test to find out!


Home · BGP Expert Test · What is BGP? · BGP Vendors · Links · Archives · Books · My New BGP Book
(advertisement)