Nieuwe internetinfrastructuren: een inleiding tot SCION

Isolatiedomeinen

Momenteel is het internet, zoals de naam al suggereert, een systeem van onderling verbonden netwerken, ook wel autonome systemen (AS’en) genoemd. Met SCION bestaat het internet nog steeds uit autonome systemen. Er wordt alleen een extra hiërarchische laag toegevoegd door autonome systemen te groeperen in zogenaamde isolatiedomeinen (ISD’s). Meestal hebben de AS’en in een ISD bepaalde eigenschappen gemeen. Ze kunnen bijvoorbeeld een jurisdictie of geografische locatie delen. Elke ISD heeft zijn eigen Public Key Infrastructure (PKI), die bijvoorbeeld wordt gebruikt om de routering binnen SCION te beveiligen. De PKI van een ISD kan alleen certificaten verstrekken voor systemen in het eigen isolatiedomein. In het geval van een beveiligingsincident blijven de gevolgen dus beperkt tot het gecompromitteerde isolatiedomein. Het beheer van een isolatiedomein is in handen van de ISD-kern, een groep van meerdere autonome systemen die kern-AS’en worden genoemd. Aangezien de kern-AS’en verantwoordelijk zijn voor het beheer van het ISD, zullen deze doorgaans worden gerund door partijen die door alle andere AS’en in het ISD worden vertrouwd. De ISD-kern speelt ook een belangrijke rol in de inter-domeinroutering. Dit leggen we verderop uit. Figuur 1 toont de verschillende ISD’s en enkele van de AS’en (in september 2020) in het SCIONLab-netwerk, een wereldwijd onderzoeksnetwerk dat experimenten met SCION mogelijk maakt.

Figuur 1: De topologie van SCIONLab in september 2020, met autonome systemen in verschillende isolatiedomeinen (bron: SCIONLab).

Routering

Voor de routering op het internet vertrouwen we momenteel op BGP, het Border Gateway Protocol. Aangezien het internet op niet-hiërarchische basis is georganiseerd, als ‘plat’ netwerk, bepalen routers aan de hand van enorme tabellen hoe pakketten op basis van het doeladres worden doorgestuurd. In SCION werkt dit iets anders: het doorsturen is gebaseerd op de zogenaamde Packet Carried Forwarding State. Dat betekent dat elk pakket het pad bevat dat het moet afleggen (op AS-niveau), waardoor we geen enorme tabellen op de routers meer nodig hebben. Daardoor kunnen routers efficiënter werken qua geheugengebruik, maar bovenal geeft het afzenders de mogelijkheid om te bepalen hoe hun netwerkverkeer door het internet moet reizen. Hiervoor moeten de afzenders weten welke paden naar het beoogde ontvangende AS beschikbaar zijn. Dat is niet veel anders dan de manier waarop we momenteel domeinnamen opzoeken om de bijbehorende IP-adressen op te halen, zodat we kunnen communiceren met andere hosts. Bij het bepalen van de paden onderscheiden we 2 scenario's: verkeer binnen een ISD (intra-ISD) en tussen ISD’s (inter-ISD).

In elk ISD zijn de AS’en hiërarchisch georganiseerd op basis van hun verbindingen in een gerichte acyclische graaf met de ISD-kern als de wortel. Hierdoor is het mogelijk om op simpele en efficiënte manier de mogelijke paden te bepalen. De kern-AS’en starten het proces, ook wel beaconing genoemd, door Path-segment Construction Beacons (PCB’s) downstream naar naburige niet-kern-AS’en te sturen. Als een niet-kern-AS een PCB ontvangt, voegt dit zijn eigen identiteit en enkele aanvullende gegevens toe. Die zijn later nodig bij de constructie van de paden in de pakketheaders. Vervolgens stuurt het AS het PCB door naar alle buren downstream, die dezelfde procedure volgen. Een PCB bevat dus informatie over het pad dat is afgelegd vanaf de ISD-kern tot aan het huidige AS. Uiteindelijk bereiken de PCB’s de uiterste AS’en en kennen alle AS’en op basis van de informatie in de PCB’s minimaal één pad waarmee de kern van het ISD kan worden bereikt. Naast het doorsturen van het PCB slaat elk AS het zojuist geleerde pad lokaal op en wordt aan de ISD-kern doorgegeven over welk pad (of welke paden) het bij voorkeur wordt bereikt. Het resultaat is dat de kern weet hoe elk AS kan worden bereikt en dat elk AS weet hoe de kern kan worden bereikt.

Figuur 2: Een voorbeeld van een SCION-topologie met een enkel ISD. De knooppunten in het ISD vertegenwoordigen AS’en.

Stel nu dat AS D (in Figuur 2) wil communiceren met AS E (en geen van beide kern-AS’en zijn) en dus aan de kern vraagt hoe AS E kan worden bereikt vanuit de kern (we noemen dit deel van het pad het down-segment). AS D weet al hoe het de kern kan bereiken (dit deel van het pad noemen we het up-segment) en kan zo de 2 segmenten combineren om een pad van zichzelf naar AS E te construeren. Dit pad wordt opgenomen in de SCION-pakketheader, zodat elk AS op het pad weet hoe het pakket moet worden doorgestuurd. Het pad kan worden ingekort als 2 segmenten elkaar kruisen, d.w.z. als de up- en down-segmenten van het pad door hetzelfde niet-kern-AS lopen. In zo'n geval zou het niet zinvol zijn om het pakket eerst door te sturen naar de kern om het vervolgens via dezelfde route terug te laten keren. Direct peering kan ook nog steeds, tussen AS’en in hetzelfde ISD of in verschillende ISD’s.

We weten nu hoe we een ander AS in hetzelfde ISD kunnen bereiken, zolang beide padsegmenten bij hetzelfde kern-AS beginnen/eindigen. We hebben alleen nog steeds niet het hele pad dat nodig is om een AS te bereiken in een ander ISD of via een pad waarvan de up- en down-segmenten niet eindigen/beginnen bij hetzelfde kern-AS. Dat probleem wordt opgevangen door inter-ISD routering, waaraan alle kern-AS’en deelnemen. De aanpak die wordt gehanteerd bij inter-ISD routering is vergelijkbaar met die van het BGP: er worden PCB's naar naburige AS’en gestuurd, die hun respectievelijke informatie toevoegen en het nieuwe PCB weer doorsturen naar hun buren. Dat klinkt hetzelfde als wat er bij intra-ISD routering gebeurt, maar bij inter-ISD routering is er geen sprake van directionaliteit. Dat betekent dat het proces niet zo efficiënt is als de intra-ISD aanpak en minder schaalbaar is.

Figuur 3: Een voorbeeld van een SCION-topologie met 3 verschillende ISD's. De knooppunten in de ISD's vertegenwoordigen AS’en.

Aan de hand van de resultaten van de bovenstaande processen kunnen AS’en communiceren met andere AS’en, zowel in hun eigen ISD als in andere ISD's, door bij de constructie van het pad de volgende recursieve aanpak te hanteren. Deze keer wil AS G communiceren met AS Q (in Figuur 3), dat zich in een ander ISD bevindt. Door het intra-ISD-beaconingproces weet G hoe de kern van zijn ISD kan worden bereikt (het up-segment). G vraagt de kern hoe Q kan worden bereikt. Door de inter-ISD routering weet de kern van het ISD van G hoe de kern van het ISD van Q kan worden bereikt. Dit deel van het pad wordt het kernsegment genoemd. De ISD-kern van G vraagt de ISD-kern van Q hoe Q kan worden bereikt vanuit zijn ISD-kern (het down-segment). De ISD-kern van G retourneert vervolgens het kernsegment en het down-segment naar G. G kan nu een compleet pad naar Q bepalen door de up-, kern- en down-segmenten te combineren.

Aangezien er per segment diverse opties kunnen zijn, kunnen er meerdere paden beschikbaar zijn en kunnen verschillende pakketten verschillende paden volgen. Het kan natuurlijk voorkomen dat een pad niet meer werkt, bijvoorbeeld door een fout met een netwerkverbinding. In dat geval moet G de verloren pakketten en de pakketten erna (opnieuw) verzenden via een ander pad. Problemen met een pad kunnen ofwel door het netwerk bij de afzender worden gemeld (vergelijkbaar met hoe dat nu gebeurt met ICMP) ofwel afgeleid worden uit het feit dat pakketten niet worden ontvangen. Aangezien de paden worden gedefinieerd op AS-niveau en in het pakket worden opgenomen, moeten we weten in welk AS en ISD een host waarmee we willen communiceren, is gevestigd. Die 2 aanvullende gegevens moeten dus in het adres van een host worden opgenomen. Vandaar dat een adres nu uit 3 delen bestaat: het ISD, AS en lokale adres van de host. Het adres van de host wordt in geen van de bovenstaande processen gebruikt en wordt alleen gebruikt voor lokale aflevering binnen het AS.

Bij de ontwikkeling van SCION stond veiligheid voorop, dus in alle hierboven beschreven processen worden de betrokken gegevens geauthenticeerd, zodat routekapingen worden voorkomen.

Verhoogde veiligheid en hoge beschikbaarheid

Tot nu toe hebben we het gehad over wat de basisvariant van SCION zou kunnen worden genoemd. Hoewel deze variant al voordelen biedt op het vlak van veiligheid en beschikbaarheid, zijn er ook nog 2 uitgebreidere varianten van SCION die extra eigenschappen toevoegen aan de inter-domeinroutering. Deze varianten heten EPIC en COLIBRI. Hieronder geven we een kort overzicht van EPIC en COLIBRI en hoe hun eigenschappen kunnen worden ingezet om de veiligheid te verhogen en een hoge beschikbaarheid te bereiken.

EPIC

EPIC staat voor Every Packet Is Checked en biedt extra beveiliging en transparantie met granulariteit op pakketniveau in het gegevensvlak. Terwijl in de basisvariant van SCION dezelfde padinformatie wordt gebruikt voor meerdere pakketten en deze informatie losstaat van de pakketinhoud, is de padinformatie in EPIC wel gekoppeld aan de pakketinhoud. Er zijn meerdere variaties van EPIC, die verschillende beveiligingsniveaus bieden. Het kan worden gebruikt ter authenticatie van een pakketbron bij alle tussenliggende hops en ter authenticatie van de payload bij de bestemming. Hierop voortbouwend kan het zelfs worden gebruikt om ervoor te zorgen dat zowel de bron als de bestemming verificatie ontvangen van het pad dat een pakket heeft afgelegd. Om dit mogelijk te maken voegt elke hop cryptografisch bewijs toe aan het pakket, zodat de verwerking wordt geregistreerd. Deze functionaliteit vereist echter aanvullende cryptografische bewerkingen tijdens de pakketverwerking, waardoor er extra sleutels moeten worden uitgewisseld tussen een host en de afzonderlijke hops op het pad. Dat kan efficiënt worden bewerkstelligd met een systeem met de naam DRKey, dat we hier niet in detail gaan bespreken, maar waarover je meer informatie kunt vinden in het boek over SCION (paragraaf 12.5). Een belangrijk kenmerk van DRKey is dat de sleutels in realtime kunnen worden berekend, waardoor de cryptografie van EPIC sneller verloopt dan wanneer er in het geheugen naar moet worden gezocht. Pakketten worden op standaard x86-hardware in minder dan 100ns verwerkt. Dit zorgt voor zeer snelle pakketauthenticatie en dus zeer snelle gegevensoverdracht, omdat geauthenticeerde pakketten niet meer door traditionele firewalls hoeven te worden gecontroleerd. Dit principe is gedemonstreerd in LightningFilter, dat in een experimentele opstelling snelheden van 120 Gbps bereikte op een x86-gebaseerde server.

COLIBRI

Waar EPIC extra authenticatie en verificatie toevoegt, biedt COLIBRI inter-domain bandwith reservation, wat het mogelijk maakt om een minimumbandbreedte te reserveren voor een pad tussen 2 eindhosts. Als dit wordt gecombineerd met LightningFilter voor het op hoge snelheid filteren van geauthenticeerde pakketten, kunnen vitale aanbieders hoge beschikbaarheidsniveaus behalen, zelfs bij een DDoS-aanval.

Gebruik van SCION op huidige IP-netwerken

Hoewel volledig gebruik van SCION binnen een AS de beste manier kan zijn om SCION optimaal te benutten, kan dat moeilijk te bewerkstelligen zijn. Als een netwerk volledig overgaat op SCION, moet elk verbonden apparaat in staat zijn om de SCION-protocollen te hanteren. SCION laten implementeren op alle verschillende apparaten en in alle toepassingen kan een lastige, zo niet onmogelijke opgave blijken te zijn.

Gelukkig is er een manier waarop we SCION kunnen inzetten die ons in staat stelt om een groot aantal van de voordelen ervan te benutten en tegelijkertijd de noodzaak wegneemt om de toepassingen of hosts in het netwerk aan te passen. In dit scenario (zoals weergegeven in Figuur 4) wordt de inter-domein SCION-communicatie afgehandeld door het netwerk in plaats van de hosts. Alle eindhosts blijven IP gebruiken zoals ze dat nu doen. Dit is mogelijk door een SCION-IP Gateway (SIG) in een netwerk op te nemen. Een SIG tunnelt inkomende IP-pakketten door het SCION-netwerk en bepaalt daarbij bijvoorbeeld welke paden worden geselecteerd. Vervolgens levert een SIG in het netwerk van de ontvanger het IP-pakket af bij de ontvangende host. Zo kunnen we bestaande IP-netwerken integreren met SCION en direct profiteren van de eigenschappen van SCION.

Figuur 4: 2 traditionele IP-netwerken die via SCION met elkaar verbonden zijn. De SCION-IP Gateways (SIG’s) tunnelen de IP-pakketten door het SCION-netwerk naar hun bestemmingen.

Tot slot

In deze blogpost hebben we een inleiding gegeven tot de SCION-architectuur. We kunnen in een artikel als dit niet meer dan een vluchtige indruk geven, maar hopelijk is het toch enigszins duidelijk geworden hoe SCION werkt. Meer informatie vind je op de SCION-website en in het boek over SCION.

SCION is nu al meer dan alleen een onderzoeksproject, want het spin-off bedrijf Anapaya werkt aan een commerciële implementatie van de technologie. Zo overweegt de Swiss National Bank om SCION te gebruiken voor haar interbancaire communicatie, een project waarbij ook de grote Zwitserse ISP's betrokken zijn, en zijn diverse universiteiten in Zwitserland bezig met het opzetten van een SCION-netwerk om hun netwerken met elkaar te verbinden.

In de toekomst houden we je op de hoogte van de ontwikkelingen bij SIDN Labs met betrekking tot SCION en andere toekomstige internetarchitecturen die we in het kader van het 2STiC-programma onder de loep nemen.