Afstudeeronderzoek: De realisering van padselectie op basis van vereisten op applicatieniveau binnen SCION
Path-aware networking (PAN) binnen SCION is een interessante optie, maar de mogelijkheden ervan zouden uitgebreid moeten worden
De oorspronkelijke blogpost is Engelstalig, dit is de Nederlandse vertaling ervan.
De wereld van vandaag is bijna niet voor te stellen zonder het internet, maar toch kent het internet veel beveiligingsproblemen. Sommige van die problemen hebben te maken met een van de essentiële routeringsprotocollen van het internet: het Border Gateway Protocol (BGP). In de loop van de tijd is er met RPKI en BGPsec beveiliging aan BGP toegevoegd. Hoewel BGP hierdoor veiliger is geworden dan daarvoor, kijken sommige onderzoekers naar alternatieve nieuwe internetarchitecturen. Een van die architecturen is SCION (Scalability, Control, and Isolation On Next-generation networks), dat een alternatief biedt voor BGP door gebruik te maken van een nieuw routeringsprotocol en erop gericht is om veel van de huidige problemen op te lossen. Je kunt meer over SCION lezen in een eerdere blog.
Een interessant aspect van SCION is dat het path-aware networking (PAN) mogelijk maakt. Zo kan een applicatie bijvoorbeeld zelf beslissen welk pad pakketten op hun tocht door het netwerk moeten volgen. Dat biedt nieuwe mogelijkheden om de veiligheid en robuustheid van de netwerkcommunicatie te verbeteren, omdat het de transparantie voor eindpunten vergroot en het mogelijk maakt om potentieel onveilige paden te vermijden. Je kunt bijvoorbeeld kiezen voor een pad dat alleen routers met een specifieke beveiligingspatch heeft, of voor een pad dat altijd binnen de EU blijft. De mogelijkheid om een pad te kiezen op basis van een reeks veiligheidseisen is voor veel sectoren een voordeel. In de medische sector kan het bijvoorbeeld nodig zijn dat een pad een uiterst stabiele verbinding garandeert voor gebruik tijdens chirurgie op afstand, of dat paden volledig in vertrouwde landen blijven.
Voor mijn onderzoek heb ik onderzocht hoe path-aware networking op basis van vereisten op applicatieniveau kan worden gerealiseerd op het SCION-netwerk. Hiervoor heb ik literatuuronderzoek gedaan en een applicatieontwerp gemaakt aan de hand van de use case “chirurgie op afstand”. Door deze use case te gebruiken kon ik verschillende soorten vereisten voor de applicatie en het netwerk beter onderzoeken. Verder heb ik een prototype van het ontwerp geïmplementeerd om de haalbaarheid te testen.
Applicatieontwerp
Chirurgie op afstand stelt een aantal eisen aan het netwerk, wat het een interessante use case maakt voor PAN. Ten eerste moet het netwerk altijd beschikbaar zijn, want als de beschikbaarheid tijdens een operatie op afstand wegvalt, kan dat ernstige gevolgen hebben. Ten tweede moet de integriteit van het netwerk gewaarborgd zijn, omdat mogelijke onbevoegde inmenging in de besturing van de chirurgische robot onacceptabel is. Verder moet de vertrouwelijkheid gegarandeerd zijn, gezien de gevoeligheid van medische gegevens. Tot slot moet het netwerk bestand zijn tegen allerlei soorten aanvallen, zoals Denial-of-Service-aanvallen, IP-spoofing en afluisteren.
Om te testen of PAN aan deze eisen kan voldoen, hebben we de volgende applicatie ontwikkeld.
De applicatie is aanwezig op 2 apparaten: een controller die wordt gebruikt door de chirurg op afstand en een ontvanger die is aangesloten op een camera en een chirurgische robot. De controller heeft een aantal elementen: een policy selector waarmee verschillende padvereisten kunnen worden ingesteld, een indicator om aan te geven of het huidige pad aan de vereisten voldoet, en een methode om de ontvanger de opdracht te geven om instructies naar de chirurgische robot te sturen. De ontvanger functioneert zonder menselijke tussenkomst en verwerkt alleen maar de binnenkomende opdrachten.
De controllerapplicatie initialiseert de verbinding door een aantal stappen te doorlopen voordat het eerste datapakket wordt verzonden:
Eerst worden alle mogelijke paden naar de ontvanger geïdentificeerd en diverse padeigenschappen geëxtraheerd.
Aan de hand van het voorkeursbeleid wordt een ranglijst gemaakt van alle paden. Vervolgens wordt het meest geschikte pad gekozen.
Via dat pad wordt een verbinding tot stand gebracht. De geschiktheid van de verbinding wordt actief gemonitord en als er een beter pad beschikbaar komt, schakelt de controller daarnaar over.
Als optie kan de multi-path mode worden ingeschakeld, waarmee transparant een tweede verbinding kan worden opgezet. Als het primaire pad dan prestatieverlies ondervindt, komen datapakketten toch aan op hun bestemming.
Voor het extraheren van de eigenschappen heb ik gekeken naar 4 verschillende eigenschappen: de latency, de bandbreedte, de geolocatie en de firmwareversie van de router. De latency en de bandbreedte waren eenvoudig te meten met actieve methoden. Voor de geolocatie besloten we om te filteren op basis van ISD's, omdat SCION werkt met een logische groepering van de AS'en binnen ISD's, vaak op basis van een sterke locatiegebonden relatie. De firmwareversie van de router vormde een grotere uitdaging. SCION beschikt niet over een ingebouwde methode voor het extraheren of verifiëren van statische informatie die verder reikt dan de geolocatie. Zonder SCION aan te passen konden we deze informatie alleen maar extraheren door gebruik te maken van de metadata van het pad, maar dat is niet ideaal. In een praktijksituatie zouden veel AS'en mogelijk niet bereid zijn om dat soort informatie in hun metadata op te nemen, en als ze dat wel zouden doen, is er op dit moment geen native methode om de juistheid ervan te verifiëren.
Voor de automatische padselectie maakten we gebruik van de Reference Ideal Method (RIM), een methode voor het nemen van beslissingen wanneer er meerdere criteria moeten worden afgewogen. Kort gezegd is het een manier om tot een beslissing te komen als de selectie van het beste alternatief een complexe aangelegenheid is. Met RIM kun je "ideals" instellen, ideaalwaarden die het bereik definiëren waarbinnen je wilt dat je eigenschap zich bevindt. Je kunt bijvoorbeeld opgeven dat de latency van het pad 100ms of minder moet zijn, of dat je alleen paden wilt die door ISD 1, 2 en 4 gaan. Aan de hand van deze gedefinieerde ideaalwaarden kunnen padvereisten worden bepaald. In onze use case is beschikbaarheid belangrijker dan dat aan alle vereisten wordt voldaan, dus als er geen pad bestaat dat aan alle vereisten voldoet, wordt het pad met de hoogste beschikbaarheid geselecteerd.
Omdat beschikbaarheid zo belangrijk is, heb ik ook een multi-path mode toegevoegd. Daarbij moest ik kiezen tussen een redundante multi-path mode en een adaptieve multi-path mode. In de redundante modus wordt het verkeer altijd over 2 paden gestuurd om de beschikbaarheid te garanderen, terwijl bij de adaptieve modus alleen gebruik wordt gemaakt van een tweede pad als de prestatie van het primaire pad onder een drempelwaarde komt. Een aspect waarmee ik rekening moest houden, was dat de beste paden in de RIM-ranglijst waarschijnlijk heel veel op elkaar lijken en misschien maar 1 AS van elkaar verschillen. Als een AS offline gaat, is de kans dus groot dat alle paden offline gaan wanneer de redundante modus gebruikt wordt. Daarom is voor onze use case de adaptieve multi-path mode geschikter, omdat de rangschikking zou veranderen zodra het beste pad prestatieverlies laat zien.
Testopstelling en resultaten
De testopstelling bestond uit 2 laptops waarop de applicatie was geïnstalleerd. Op de clientlaptop draaiden de clientapplicatie, een lokale MongoDB-server waar alle paden werden opgeslagen, en het SCION-AS dat is aangesloten op het attachment point van de Carnegie Mellon University (CMU). Daarnaast werd er een aangepaste versie van de tool van het UPIN Project uitgevoerd om alle paden te verzamelen en de verschillende eigenschappen te extraheren. Op de tweede laptop draaiden de ontvangerapplicatie, een BWTester Server zodat de bandbreedte kon worden getest, en het SCION-AS dat is aangesloten op het attachment point van Magdeburg. Figuur 1 laat de volledige topologie zien.
Figuur 1. Topologie van de testopstelling van het prototype.
Ik heb verschillende tests uitgevoerd om de efficiëntie van de oplossing te meten. Het verzamelen van paden kostte maar 2 tot 3 seconden. Het extraheren van de eigenschappen, waarbij ik informatie verzamelde zoals de latency en de bandbreedte, nam echter veel meer tijd in beslag. In Figuur 2 zie je hoelang het duurde om 1 extractierun uit te voeren, afhankelijk van het aantal paden en het AS van de client. Met 40 paden, het ideale aantal, kan het extraheren van eigenschappen al gauw zo'n 9 minuten in beslag nemen. Dat is niet ideaal, want het betekent dat de status van de kwaliteit van het pad maar eens in de 9 minuten wordt bijgewerkt, terwijl die kwaliteit in die tijd drastisch kan veranderen. Ook liep het systeem tijdens het uitvoeren van de tests soms vast en moest er handmatig worden ingegrepen om het opnieuw op te starten. Ik had het vermoeden dat er een bug zat in een van de meettools die ik gebruikte.
Figuur 2. Een vergelijking van de extractieruns in seconden met het Amerikaanse AS (18 en 40 paden) en het Zwitserse AS (40 paden).
Ik heb ook de efficiëntie van de padselectie zelf getest en dan met name hoelang het duurde om het bestand met het voorkeursbeleid en de verzamelde padeigenschappen te laden en op basis daarvan een ranglijst van de paden te maken. Onze vereisten zijn vastgelegd in een bestand met het voorkeursbeleid. Eerst bepaalde ik een referentiepunt zonder een specifiek beleid, wat een selectietijd van 10 seconden opleverde. Toen we een voorkeursbeleid instelden, duurde het ongeveer 16 seconden om een pad te selecteren. Dat wil zeggen dat het instellen van een voorkeursbeleid en het maken van een ranglijst van de paden ongeveer 6 seconden in beslag nam. Als we een voorkeursbeleid instelden en de multi-path mode inschakelden, was de gemiddelde tijd ongeveer 29 seconden, wat aanzienlijk hoger is. Ik vermoed echter dat die tijden kunnen worden verbeterd door een aantal optimalisaties in de code aan te brengen.
Toekomstig onderzoek
Zoals het er nu voorstaat, is PAN binnen SCION een interessante optie, maar we adviseren om de mogelijkheden ervan uit te breiden, zodat er meer padeigenschappen kunnen worden geëxtraheerd en geverifieerd. Momenteel zijn niet-kwantificeerbare eigenschappen lastig te verifiëren of wordt de verificatie ervan niet ondersteund. Eén mogelijkheid is om FABRID direct in SCION te integreren. Een andere optie is het ontwikkelen van een nieuwe methode door meer onderzoek te doen. Verder adviseer ik om de client in staat te stellen te verifiëren of een verzonden pakket inderdaad het geselecteerde pad heeft genomen. Hoewel SCION is uitgerust met een aantal native validatiefuncties, biedt het geen padvalidatie door eindhosts. Hiervoor zou gebruik kunnen worden gemaakt van EPIC (Every Packet Is Checked), een methode waarmee eindhosts paden wel kunnen valideren. Met deze aanvullende mogelijkheden zou PAN de veiligheid van netwerkcommunicatie aanzienlijk kunnen verbeteren.
