Een self-hosted aanpak om de AS-transparantie te vergroten en toekomstige internettoepassingen te ondersteunen

Autonome systemen en hun metagegevens

Het internet transporteert gegevens via een netwerk van onafhankelijk beheerde autonome systemen (AS'en) die elk bestaan uit de netwerken, routers, switches en andere infrastructuur die eigendom is van en beheerd wordt door een bepaalde administratieve entiteit ('een manifestatie van eigendom van infrastructuur en de behoefte aan autonome administratieve controle', zoals deze SIGCOMM-paper het verwoordt).

Een AS kondigt de bereikbaarheid voor een of meer IP-adresblokken waarvoor het autoritatief is aan met behulp van het Border Gateway Protocol (BGP). BGP verspreidt deze informatie over het internet, zodat AS'en op dynamische wijze paden kunnen instellen die via tussenliggende AS'en van een AS van herkomst naar een AS van bestemming lopen. Deze AS-paden brengen uiteindelijk het verkeer van de hosts die zijn verbonden met het AS van herkomst naar hosts in het AS van bestemming.

Behalve het delen van bereikbaarheidsinformatie met behulp van BGP publiceren AS-beheerders ook connectiviteitsattributen via Internet Routing Registries (IRR's) en door gebruik te maken van PeeringDB. Met behulp van de inhoud van deze databases kunnen AS'en en andere entiteiten bijvoorbeeld controleren voor welke internetroutes een AS autoritatief is, contact opnemen met de beheerders van een AS en achterhalen waar ze met het AS kunnen peeren. Beide zijn logisch gecentraliseerde systemen, waarbij IRR's worden beheerd door Regional Internet Registries, zoals RIPE NCC. Het is echter een bekend probleem dat de gegevens in IRR's vaak verouderd zijn.

Gebruiksscenario's en internetroutering voor kritieke infrastructuur

We voorzien dat het internet van de toekomst niet alleen dient voor de toepassingen van vandaag, zoals e-mail, contentdistributie en videoconferenties, maar ook het communicatiesubstraat wordt voor het beheren van gedistribueerde kritieke infrastructuren zoals elektriciteitsnetten, het aansturen van telerobots en het op afstand besturen van vrachtwagens. Onze hypothese is dat dit nieuwe beveiligingseisen stelt aan de kerncomponenten van het internet, zoals het routeringssysteem en IRR's.

Een van de nieuwe gebruiksscenario's die we voorzien, is dat beheerders van kritieke infrastructuren meer controle over hun AS-paden willen, zodat ze verkeer kunnen routeren via AS'en die ze betrouwbaar achten. We kunnen ons bijvoorbeeld indenken dat de beheerder van een toekomstig slim energienetwerk schakelinstructies voor elektrische leidingen vanuit de controlekamer naar een afgelegen veldstation wil versturen via een of meer AS-ketens die met goed gevolg zijn gecontroleerd op veiligheid, eigendom zijn van organisaties die staan ingeschreven bij lokale of regionale Kamers van Koophandel en kunnen aantonen dat hun routers in veilige staat verkeren. Deze manier van beheren van AS-paden zou je kunnen vergelijken met de manier waarop organisaties zoals Boeing hun meerlaagse toeleveringsketens beheren, waarbij in ons geval elk AS vergelijkbaar is met een laag in de communicatieve toeleveringsketen (de 'communications supply chain') van een serviceprovider.

We stellen ons zo voor dat de implementatie van deze functies en beleidsregels voor padbeveiliging plaatsvindt via zogenaamde 'trust zones', vertrouwde zones. Vertrouwde zones zijn MANRS-achtige coalities van AS'en die in samenwerkingsverband beveiligingsbeleid implementeren op regionale schaal in plaats van wereldwijd. Een vertrouwde zone kan bijvoorbeeld de AS'en vragen om hun routeringsbeleid zo in te stellen dat verkeer veilig tussen de leden van de vertrouwde zone wordt gerouteerd, en om de benodigde audit trails bij te houden zodat men kan aantonen dat dit ook echt gebeurt. Het vergt echter een aanzienlijke hoeveelheid onderzoek en implementatiewerk om te bepalen of het haalbaar is om AS'en op die manier te laten samenwerken. Sommige van deze uitdagingen worden onderzocht binnen het CATRIN-project.

Vereisten voor een uitgebreide AS-informatieservice

Om in de toekomst vertrouwensgevoelige partijen zoals beheerders van energienetwerken in staat te stellen om de betrouwbaarheid van de AS'en langs een AS-pad te beoordelen, hebben we een 'AS Information Service' (ASIS) nodig die hen voorziet van gedetailleerde beveiligings- en administratieve attributen van AS'en die verder gaan dan de connectiviteitsattributen in IRR's en PeeringDB. Voorbeelden van dit soort attributen zijn de veiligheidscertificering van een AS, cryptografisch verifieerbare gegevens over de eigenaar van het AS, beveiligingscontactinformatie ('AS-wide security.txt'), welke gegevenswetten van toepassing zijn en operationele informatie (apparatuurtypen, softwareversies, netwerktopologie).

We hebben 4 vereisten (R1 t/m R4) voor zo'n ASIS geïdentificeerd:

R1. Self-hosted

Een ASIS moet self-hosted zijn, wat inhoudt dat elke AS-beheerder zijn eigen ASIS-instantie beheert. Dit is belangrijk omdat de AS-beheerder dan eigenaar is van de ASIS en verantwoordelijk is voor de gegevens die erin zijn opgenomen. Daarnaast leidde de discussie rondom een eerder voorstel om attributen voor naleving van AVG-wetgeving en eerbiediging van de mensenrechten toe te voegen aan IRR's tot de conclusie dat dergelijke informatie buiten connectiviteitsdatabases moet worden gehouden. Vanwege het gedecentraliseerde karakter van de ASIS zullen clients een manier nodig hebben om de locatie van de ASIS van een bepaald AS te achterhalen.

R2. Granulair toegangsbeheer

Om de balans te vinden tussen veiligheid, de privacy van eindgebruikers en transparantie, moet een ASIS een AS-beheerder zelf laten bepalen welke AS-attributen aan wie worden vrijgegeven en in welke mate van granulariteit. Een AS kan bijvoorbeeld bereid zijn om gegevens over de routerleverancier die het gebruikt te delen met andere AS-beheerders die lid zijn van dezelfde vertrouwde zone (zie hierboven) en juridische overeenkomsten hebben getekend over het ontvangen van dat soort informatie. Op z'n minst zou een ASIS de connectiviteitsattributen vrij moeten geven, lokaal of via een verwijzing naar een IRR of naar PeeringDB.

R3. Koppeling met netwerkmanagementsystemen

Een ASIS moet gekoppeld zijn aan de netwerkmanagementsystemen van een AS, zodat de AS-beheerder de service (min of meer) automatisch kan bijwerken. De ASIS-gegevens kunnen dan gemakkelijk up-to-date worden gehouden, wat de praktische waarde ervan vergroot. Verouderde informatie over AS'en is een bekend probleem van centrale databases zoals IRR's, misschien wel omdat die het zonder zulke koppelingen moeten stellen. Een AS-beheerder zou via zijn ASIS ook informatie van derden kunnen publiceren, zoals prestatiemetingen en bereikbaarheidsgegevens die met behulp van RIPE ATLAS zijn verzameld van netwerken over de hele wereld.

R4. Gebruik van gangbare gegevensindelingen

Met het oog op interoperabiliteit en machineleesbaarheid moet een ASIS de beveiligings- en administratieve attributen aanbieden in een welomschreven en bij voorkeur IETF-gestandaardiseerde indeling, zoals de indeling RPSL (Routing Policy Specification Language) voor connectiviteitsattributen in IRR's.

Bestaande systemen voor AS-metagegevens

Bestaande systemen, zoals IRR's en PeeringDB, voldoen niet aan de vereisten voor een ASIS, bijvoorbeeld wat betreft granulair toegangsbeheer en omdat ze logisch gecentraliseerd zijn. Hetzelfde geldt voor meetsystemen van derden die alternatieve bronnen van AS-metagegevens vormen, zoals RIPE ATLAS, OpenINTEL en ALTO-servers. Andere bronnen zijn weblogs (zoals die van CloudFlare) en mailinglijsten (bijvoorbeeld NANOG en NLNOG), maar deze leveren ongestructureerde AS-gegevens, die moeilijker te interpreteren zijn.

In een eerdere etnografische studie werd voorgesteld om attributen voor naleving van AVG-wetgeving en eerbiediging van de mensenrechten aan IRR's toe te voegen. Het voorstel stuitte op weerstand vanuit de routeringscommunity en de auteur heeft een interessant inzicht gegeven in waarom de community het voorstel afwees. We verwachten dat een grassroots-aanpak met kleine community's van AS-en (vertrouwde zones) die op regionale schaal extra AS-informatie met elkaar delen meer kans van slagen heeft dan het zoeken naar consensus binnen de wereldwijde routeringscommunity.

High-level ontwerp van de AS-informatieservice

Figuur 1 toont ons high-level ontwerp voor de ASIS. Elk AS is verantwoordelijk voor het beheren van zijn eigen ASIS-instantie (vereiste R1). Informatie in de ASIS kan handmatig door een beheerder worden ingevoerd of automatisch door middel van een geautomatiseerde koppeling met een netwerkmanagementsysteem (NMS) of configuratiemanagementdatabase (CMDB), zoals weergegeven in stap 1 van Figuur 1 (vereiste R3). De ASIS kan ook worden gebruikt als tool voor het bijwerken van logisch gecentraliseerde databases, zoals RIR's (stap 2).

Figuur 1. High-level ASIS-ontwerp.

Om gegevens over een AS te verkrijgen, moet een client eerst de ASIS van dat AS opzoeken, bijvoorbeeld met behulp van een IP-adres uit de ranges waarvoor het AS autoritatief is (stap 3). Vervolgens kan er een verzoek worden verzonden om de AS-metagegevens op te halen. Als de gebruiker of service geautoriseerd is om de gegevens in te zien (vereiste R2), stuurt de ASIS deze terug in een geschikte open standaardindeling (vereiste R4).

Een eerste ASIS-prototype

Om een idee te krijgen van de haalbaarheid en toegevoegde waarde van een ASIS voor AS'en en netwerkbeheerders, bouwden we een eenvoudig prototype.

We concentreerden ons op vereiste R1 (self-hosting). Dit gaf ons de mogelijkheid om met stakeholders te bespreken welke soorten gegevens zij via hun ASIS zouden willen delen en van andere AS'en zouden willen krijgen, en de gewenste mate van granulariteit voor het toegangsbeheer te bepalen. Ons prototype kan ook worden gebruikt om het ophalen van informatie uit meerdere domeinen voor een bepaald AS-pad te demonstreren door het te integreren met onze visualiseringstool PathVis.

Om het simpel te houden, kozen we voor de ASIS voor een op HTTPS gebaseerde implementatie en voor het delen van gegevens voor het gebruik van statische JSON-bestanden. Te zijner tijd kan er ondersteuning voor andere documentindelingen en voor dynamische gegevensinvoer vanuit andere systemen worden toegevoegd. HTTP ondersteunt ook authenticatie, wat ons opties geeft om in de toekomst te voldoen aan vereiste R2 (granulair toegangsbeheer).

Aangezien elk domein zijn eigen ASIS-instantie beheert, hebben we een opzoekservice nodig om de ASIS te vinden die bij een AS hoort.

Op DNS gebaseerde ASIS-opzoekservice

We gebruiken het Domain Name System (DNS) als opzoekservice voor de ASIS. We maken met name gebruik van reverse zones, die een IP-adres terugkoppelen aan een hostnaam. We gebruiken dit mechanisme zodat clients de ASIS van een AS kunnen vinden door een query naar het DNS te sturen voor een van de IP-adressen waarvoor het AS autoritatief is. De client krijgt dan een door ons gedefinieerd ASIS TXT-record retour (in een indeling in overeenstemming met RFC 6763, Section 6) dat verwijst naar de ASIS.

Laten we eens kijken naar een voorbeeld (Figuur 2). Een client zoekt de reverse zone van IP-adres 203.0.113.0 op (interactie A) en krijgt vervolgens van het DNS het ASIS TXT-record (B), namelijk:

TXT IN v=ASISv1 ep=https://asis.example.nl/asis/v1

Het veld 'ep=' (voor 'ASIS end point') verwijst naar de ASIS en het veld 'v=' is de versie van het ASIS-protocol, dat we voor dit voorbeeld hadden ingesteld op v1.

Tot slot kan de client via de URL in het veld 'ep' contact opnemen met de ASIS (C), die zal antwoorden met de beveiligings- en administratieve attributen (D). Interactie (D) kan te maken krijgen met toegangsbeheer, afhankelijk van het beleid van de AS-beheerder.

Figuur 2. Voorbeeld van het achterhalen van een ASIS.

Het opzoeken van ASIS-instanties door gebruik te maken van het DNS legt een administratieve verantwoordelijkheid bij de beheerders van reverse zones. Handmatig voor elk IP-adres ASIS TXT-records toevoegen zou foutgevoelig en niet gemakkelijk schaalbaar zijn. Deze problemen kunnen worden opgelost door automatisering en door ondersteuning toe te voegen aan de software voor autoritatieve DNS-servers.

Samenvatting en toekomstig werk

We zijn van mening dat een transparanter internet belangrijk is voor de kritieke toepassingen van de toekomst en hun communicatietoeleveringsketen, omdat een tranparanter internet deze toepassingen in staat stelt om meer inzicht in en controle over de beveiligings- en administratieve eigenschappen van AS-paden te krijgen. Het concept van een ASIS is een manier om een dergelijke AS-padtransparantie te realiseren. Grootschalige implementatie zal een grote uitdaging zijn, maar zou kunnen slagen als groepen AS'en (vertrouwde zones) gezamenlijk de ASIS adopteren, waardoor er eerste 'eilandjes' van AS-padtransparantie zouden ontstaan.

We hebben een reeks initiële vereisten voor de ASIS voorgesteld en een eenvoudig prototype van het systeem ontworpen en geïmplementeerd, gebaseerd op een HTTP-server, maar er moet nog veel werk worden verzet. Om bijvoorbeeld te voldoen aan de vereisten R2 t/m R4 moeten we eerst de community raadplegen over welke informatie netwerkbeheerders zouden willen delen en met wie (vereiste R2). Van daaruit kunnen we bepalen met welke netwerkmanagementsystemen een ASIS moet worden gekoppeld (R3) en welke standaarden kunnen worden gebruikt om de metagegevens in een ASIS te beschrijven (R4).

Welke AS-gegevens zou jij willen delen via de ASIS en onder welke voorwaarden? Laat het ons weten op sidnlabs@sidn.nl.

Met dank aan

Dit werk is uitgevoerd in het kader van het CATRIN-project (www.catrin.nl), dat financiering ontving van de Nederlandse Organisatie voor Wetenschappelijk Onderzoek (NWO).