submarinecablemap.com - I just love looking at this stuff.
Read the article - posted 2019-03-08
Geoff Huston has written a post on the APNIC blog congratulating BGP with its 30th birthday. BGP version 1 was published as RFC 1105 in June of 1989. Five years later, the BGP version 4 was published as RFC 1654. And we're still using BGP-4 today, 25 years later! Lots of things, including IPv6 support, were added later in backward compatible ways.
As usual, Geoff's story is comprehensive with lots of interesting details. For instance:
From time to time we see proposals to use geo-based addressing schemes and gain aggregation efficiencies through routing these geo-summaries rather than fine-grained prefixes.
Sorry about that. 😀 I still think it could work, though.
Well worth a read.
Read the article - posted 2019-06-10
Last week, there was a large route leak that involved Swiss hosting company Safe Host and China Telecom. The route leak made internet traffic for European telecoms operators KPN, Swisscom and Bouygues Telecom, among others, flow through Safe Host and China Telecom against the wishes of the telecom operators involved. See this Ars Technica story for more details.
In this post, I'm going to explain how the interaction between the technical and business aspects of internet routing have made this issue so difficult to fix. At the end I'll briefly describe a proposal that I think can actually make that happen.
Read the article - posted 2019-06-13
Last week, I suggested it's time fix those BGP route leaks. I live by the words everybody complains about the weather, but nobody does anything about it, so as such I wrote an Internet-Draft with the protocol changes necessary:
draft-van-beijnum-sidrops-pathrpki-00
I think we can stop these route leaks with a relatively modest change to RPKI: by combining the ASes the origin trusts and the ASes the operator of an RPKI relying party server trusts, we have a list of all the ASes that may legitimately appear in the AS path as seen from this particular vantage point.
Read the article - posted 2019-06-20
As I was writing my RPKI path validation draft last week, I considered the issue of filtering BGP AS paths with AS_SETs in them.
Turns out that I'm not the only one who feels AS_SETs are unnecessary: there's an RFC saying the exact same thing: RFC 6472.
Read the article - posted 2019-06-24
Slides from my presentation about validating the BGP AS path with RPKI at the Euro-IX Route Server Workshop Amsterdam, 18 July 2019.
Permalink - posted 2019-07-18
Mijn presentatie bij NiVo Network Architects over BGP-beveiliging en route leaks, 10 september 2019 in Weesp.
Permalink - posted 2019-09-10
In this month's edition of The ISP Column Why is Securing BGP just so Damn Hard? Geoff Huston asks himself exactly this question. He lists ten reasons. I don't agree with most of them: this is a solvable problem.
Read the article - posted 2019-09-20
During his talk about 30 years of BGP, Geoff Huston said something along the lines of "someone should come up with another type of routing protocol besides distance vector and link state". That is of course too delicious a challenge to ignore...
Read the article - posted 2019-10-15
There are some advantages to filtering out packets with invalid addresses in them. That would be a packet with a private source or destination address, for instance. Those never have any business traveling across the internet. (Not to be confused with BCP 38 filtering.) For instance, there have been instances where spammers grab an unused prefix, start announcing it in BGP, do a spam run and then drop the prefix. When packets with private addresses enter your network, bad things may happen if you use those addresses yourself. And these invalid "martian" packets are just an annoyance, using up traffic and generating log entries.
Read the article - posted 2019-11-28
Presentation slides from my lightning talk "AS paths: long, longer, longest" at the RIPE-79 meeting in Rotterdam, 18 October 2019.
Permalink - posted 2019-11-29
In a paper for the HotNets'19, seven researchers admit that "beating BGP is harder than we thought". (Discovered through Aaron '0x88cc' Glenn.) The researchers looked at techniques used by big content delivery networks, including Google, Microsoft and Facebook, to deliver content to users as quickly as possible. This varies from using DNS redirects to PoPs (points of presence) close to the user, using BGP anycast to route requests to a PoP closeby and keeping data within the CDN's network as long as possible ("late exit" or "colt potato" routing).
Turns out, all this extra effort only manages to beat BGP as deployed on the public internet a small fraction of the time.
Read the article - posted 2019-12-30