112-storing: hoe voorkomen we zulke problemen op het internet?

▼ Afgelopen maandagmiddag was er een grote storing in het telefonienetwerk van KPN, waarbij ondermeer het alarmnummer 112 zo'n drie uur niet bereikbaar was. Hoe kan het dat een telefoontje op een vaste lijn van KPN naar een meldkamer in de veiligheidsregio Groningen last heeft van dezelfde storing als een telefoontje van een Vodafone-gebruiker naar een meldkamer in de veiligheidsregio Limburg-Zuid? Dinsdag kwam het antwoord: een softwarefout. Het mocht niet baten dat het betreffende systeem viervoudig uitgevoerd was.

Intelligent network

In de telefonie is al vele jaren geleden het zogenaamde intelligent network ingevoerd. Voor die tijd waren vaste nummers gekoppeld aan wijkcentrales en mobiele nummers aan de mobiele operator. Als je dus van de ene kant van de stad naar de andere verhuisde, of van de ene mobiele operator naar de andere, dan kreeg je een nieuw nummer. Met IN was dat niet meer nodig: de telefooncentrale vraag aan een centrale database waar telefoontjes naartoe gerouteerd moeten worden. Probleem is wel dat het telefoonnetwerk nu afhankelijk is van een klein aantal centrale systemen. (En Voice over IP (VoIP) heeft dat versterkt.) Voorheen kon je nog binnen je eigen stadsdeel bellen zolang de wijkcentrale het deed, ook al lag de rest van het telefoonnetwerk plat.

Internetrouters worden afhankelijk van centrale systemen

We zien nu dezelfde ontwikkeling op ons af komen in de internetwereld. Van oudsher zijn we op het internet in het voordeel omdat organisaties zich tegelijk via meerdere service providers aan kunnen sluiten, zolang zij in staat zijn hun eigen BGP-routering te draaien. Maar nieuwe ontwikkelingen zoals SDN, software-defined networking, introduceren afhankelijkheden van centrale systemen. Maar bijvoorbeeld ook RPKI, een systeem om de routering op het internet te beveiligen tegen (onder meer) route leaks. Nu is het zo dat routers van verschillende organisaties routeringsinformatie uitwisselen via BGP, waarbij de routers zelf filters moeten hebben die zorgen dat ze alleen de juiste informatie doorgestuurd wordt. Dat gaat niet altijd goed, waardoor internetverkeer zomaar de verkeerde kant opgestuurd kan worden.

RPKI voorkomt dit door op een centrale plek filters te maken die dan naar de routers gestuurd worden. Aan de ene kant maakt het centraliseren van deze complexe taak en hem uitvoeren op servers die open source software kunnen draaien dit een stuk makkelijker, maar aan de andere kant, als zometeen die filters onmisbaar zijn om het internet te laten functioneren, hebben we het internet afhankelijk gemaakt een klein aantal servers die allemaal gebruik maken van een beperkt aantal softwarevarianten?

Die centrale functies helemaal buiten de deur houden zal niet lukken, want ze hebben enorme toegevoegde waarde en zijn veel makkelijker te implementeren dan regelmatig tientallen, honderden of zelfs duizenden routers van nieuwe functionaliteit te voorzien. Maar: maak je voor kritische functies niet afhankelijk van één softwareversie. En zorg dat routers hun basisfunctie ook op eigen kracht kunnen uitvoeren.

Crisismanagement en wat nu voor 112?

Nog een paar laatste woorden over het crisismanagement bij de 112-storing: dat ging niet bepaald volgens de regelen der kunst. Aan de ene kant begrijpelijk, want als je alles dubbel, driedubbel of zelfs vierdubbel uitvoert met protocollen om automatisch over te schakelen bij uitval, dan kan het eigenlijk niet anders dan dat wanneer het systeem alsnog uitvalt, dit komt door een stomme fout of een totaal niet te voorziene samenloop van omstandigheden. Voor alle te verwachten problemen is immers een backup-lijn/systeem aanwezig.

Aan de andere kant maakt de communicatie over dit incident pijnlijk duidelijk dat er geen enkele rekening gehouden is met mogelijke uitval van 112. Hopelijk wordt hier de juiste les uit getrokken: geen enkel systeem is onfeilbaar, zelfs niet als alle individuele componenten meervoudig uitgevoerd zijn. Als je afhankelijk bent van een softwaresysteem dan is een storing eens per vijf tot tien jaar ongeveer wel het maximaal haalbare. Op hoge toon van de leverancier eisen dat dit nooit meer voorkomt is dus een zinloze exercitie. Meer dan maatregelen om het oplossen van zo'n storing wat te versnellen zit er realistisch gezien niet in.

Het zou dus verstandig zijn als de andere mobiele netwerken de 112-meldkamers kunnen bereiken zonder afhankelijk te zijn van KPN. Daarmee is de kans op een gedeeltelijke 112-storing groter, maar een kans op een volledige 112-storing een stuk kleiner.

En: waarom kunnen we 112 alleen bellen? Voor de meeste gebruikers is hun telefonieaansluiting waarschijnlijk op dit moment (nog) wel betrouwbaarder dan hun internetverbinding, maar als je naast via de telefoon, 112 ook via een website en/of app zou kunnen bereiken, zitten niet langer alle eieren in één mandje.

Permalink - posted 2019-06-25

Be gone, AS_SETs!

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

For those of you who haven't read the BGP specification recently, the idea is that if a BGP router takes a bunch of prefixes and aggregates these into a single prefix, it then adds the AS numbers in the AS paths of the original prefixes to the AS path of the new prefix in the form of an AS_SET. The AS_SET has all the AS numbers in it so loops can be detected, but for the purposes of comparing the AS path length, the AS_SET counts as a single AS hop, regardless of the number of ASes in the AS_SET. (Or the router can leave out one or more ASes and then set the ATOMIC_AGGREGATE attribute instead.)

I think aggregation was added to BGP-4 as a way to start shrinking the BGP table while BGP-3 was still in use. BGP-4 added Classless Inter-Domain Routing (CIDR), allowing it to advertise (for instance) 16 class C networks to be advertised as a /20 prefix.

However, aggregation is the easy part, you also need to get rid of those original unaggregated prefixes (the 16 class C /24s in the above example). As these may also be advertised over other paths, that's very difficult. As such, there's really not much point to this type of aggregation, and thus, no point to using AS_SETs. In fact, I didn't even mention them in my book.

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.

Of course this being the internet, the fact that AS_SETs are of no use doesn't mean people don't use them. This is what I got from RouteViews just now:

>route-views>sh ip bgp | incl {
 *   5.28.128.0/20    203.181.248.168    0 7660 2516 3356 1299 12849 {12849} i
 *   5.28.144.0/22    203.181.248.168    0 7660 2516 3356 1299 12849 {12849} i
 *   5.39.176.0/21    203.181.248.168    0 7660 2516 3356 8530 {198753} i
...

There's currently 377 out of 803582 prefixes with AS_SETs in them in the global IPv4 routing table (0.046%), and 31 of 73138 in the IPv6 BGP table (0.042%).

Note that you can filter on an AS in an AS_SET with a Cisco BGP AS path regular expression like _8111_. The _ also matches the { and } that surround an AS_SET as well as the commas separating AS numbers in an AS_SET. However, if you filter a customer's AS path like this, as I always recommend:

^(65537_)+$

it won't work, as there is nothing to match the { in this regular expression. Which is fine, there's really no good reason to use AS_SETs.

Permalink - posted 2019-06-24

Path validation with RPKI draft

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

I believe deployment will be relatively easy, as it works for the two ASes at both ends even if ASes in the middle don't participate.

There is path filter example code in the appendix to show that this part is easy. 😀

You can see that filter code in action here:

http://bgpexpert.com/pathrpki/

I'm looking forward to hearing feedback. I've started discussions on the RIPE routing-wg mailinglist and the IETF sidrops working group mailinglist. Also feel free to mail me directly or talk to me on Twitter.

Permalink - posted 2019-06-20