Toekomstig internet met terabitsnelheden: SCION in P4

SCION

SCION maakt path-aware networking mogelijk. Dat houdt in dat de afzender op het niveau van autonome systemen (AS’en) het pad selecteert dat het verkeer door het internet aflegt. Dit geselecteerde pad, het forwarding path of doorstuurpad genoemd, wordt in elk pakket opgenomen. Het doorstuurpad bevat zogenoemde hop fields. Een hop field bevat instructies voor één specifiek AS over hoe een pakket moet worden doorgestuurd. Verder is het hop field beveiligd met een cryptografische message authentication code (MAC) om ervoor te zorgen dat alleen geautoriseerde paden worden gebruikt. Zoals uitgelegd in ons vorige blog, kan een pad uit maximaal drie padsegmenten bestaan, waarbij elk segment een combinatie van hop fields is. De hop fields in de verschillende padsegmenten bepalen samen welk pad wordt gevolgd. Als gevolg hiervan hoeven routers niet langer enorme tabellen op te slaan over waar pakketten met bepaalde IP-prefixen naartoe moeten worden doorgestuurd. In plaats daarvan hoeven de routers alleen maar te kijken naar het huidige hop field in een pakket om zo te kunnen bepalen waar het pakket naartoe moet.

P4

P4 is een domeinspecifieke taal voor pakketverwerking op netwerkapparaten zoals switches en netwerkkaarten. Met deze taal kan ondersteuning voor nieuwe protocollen aan netwerkapparaten worden toegevoegd. Dit heeft het voordeel dat het niet langer nodig is om te wachten tot fabrikanten nieuwe protocollen implementeren en maakt het mogelijk om nieuwe protocollen gemakkelijk op hardware uit te proberen. P4 kan worden gebruikt om bijvoorbeeld softwareswitches te programmeren, maar wij hebben het gebruikt om SCION te implementeren voor switches op basis van de Intel Tofino ASIC.

Een belangrijk concept in P4 is het gebruik van match-action tabellen. Aan de hand van deze tabellen kunnen we een bepaalde actie uitvoeren op basis van een waarde in het pakket dat we op dat moment verwerken. Bij Ethernet matchen we bijvoorbeeld op het MAC-bestemmingsadres in het pakket. Afhankelijk van het resultaat van de tabelzoekopdracht, sturen we het pakket naar een bepaalde uitgaande poort (als die in de tabel is gevonden) of sturen we het pakket naar alle poorten. Matchen kan worden gedaan op lijnsnelheid in het data plane. Tabelingangen toevoegen en verwijderen gaat echter minder snel en wordt gedaan via het control plane.

SCION implementeren

Cryptografische uitdagingen

Op basis van de protocolspecificaties voor SCION ontwikkelden we een SCION-grensrouter, die verantwoordelijk is voor het doorsturen van pakketten tussen naburige AS’en. Onze implementatie bestaat uit meerdere componenten: de P4-implementatie zelf en een aantal control plane-componenten (zie Figuur 1). Bij de implementatie van het SCION-protocol voor de Tofino was de grootste uitdaging het gebrek aan ondersteuning voor cryptografische bewerkingen op de Tofino-chip. Omdat de hop fields een cryptografische MAC bevatten, moeten we voor elk pakket dat we verwerken, een cryptografische bewerking uitvoeren. Eén manier om dat te bereiken is door de pakketten ter verificatie door te sturen naar het control plane. Dat zou de prestatie echter behoorlijk drukken, want het neemt veel tijd in beslag. Gelukkig worden hop fields in het SCION-basisprotocol gebruikt voor meerdere pakketten. Daardoor kunnen we het gebrek aan cryptografische ondersteuning omzeilen door gebruik te maken van een tabel in onze implementatie die alle hop fields bevat die op dat moment geldig zijn. Met behulp van deze tabel kunnen we de hop fields van inkomende pakketten verifiëren. Staat een hop field in de tabel, dan is het geldig. Zo niet, dan is het veld niet geldig en wordt het pakket gedropt. Om dit te ondersteunen, pasten we de SCION-beheerserver, die de hop fields genereert, zodanig aan dat de gegenereerde hop fields worden geregistreerd op de switch. We moesten ook ondersteuning toevoegen voor zogenoemde one-hop paths, paden met maar één hop, die worden gebruikt om te communiceren met directe buren waar nog geen pad naartoe bestaat. Als een verbinding voor het eerst wordt gebruikt, bevat het eerste pakket geen geldig hop field voor het ontvangende netwerk en moet dit worden toegevoegd door de grensrouter. Omdat we het hop field niet kunnen genereren in het data plane, sturen we inkomende pakketten met een one-hop-pad door naar het control plane op de switch. Daar wordt een correct hop field berekend en aan de tabel toegevoegd, voordat het bijgewerkte pakket teruggestuurd wordt naar het data plane en op de gebruikelijke manier wordt verwerkt. Ten slotte is er een proces dat regelmatig controleert op verlopen hop fields in de tabel en deze verwijdert. We verwijderen verlopen hop fields via het control plane, omdat het niet eenvoudig is om de timestamp of tijdstempel van de hop fields in het data plane te controleren.

Figuur 1: Het control plane van onze implementatie en de interacties met het data plane.

Als we de standaard beaconing-instellingen van SCION nemen, d.w.z. beacons met een interval van 5 seconden en een geldigheidsduur van ongeveer 6 uur, moeten we ongeveer 4.250 hop fields per combinatie van upstream-pad en downstream-interface opslaan. Met ondersteuning voor zowel IPv4 als IPv6 kunnen we momenteel ongeveer 160.000 hop fields opslaan en met ondersteuning voor een van beide ongeveer 200.000. In het laatste geval zouden we bijvoorbeeld 3 upstream-paden en 15 downstream-interfaces kunnen ondersteunen. In de praktijk is dit afhankelijk van welk beacon-beleid en welke instellingen er precies worden gebruikt. Hierbij moet worden opgemerkt dat er mogelijk nog ruimte voor verbetering is, aangezien we de implementatie nog niet hebben geoptimaliseerd om de capaciteit van de MAC-verificatietabel te maximaliseren. Daarnaast zou het aantal ondersteunde hop fields hoger kunnen zijn als er meer dan één grensrouter in het AS aanwezig is. Nog een kanttekening is dat we hier de one-hop-paden buiten beschouwing hebben gelaten, maar het is onwaarschijnlijk dat er daar veel van zijn, en we zouden een relatief korte verlooptijd voor hun hop fields kunnen instellen.

Wijzigingen in de SCION-headers

Toen we het protocol gingen implementeren, stuitten we op verschillende problemen met de headerindeling van het SCION-protocol, waardoor het lastig of inefficiënt op onze hardware te implementeren was. Het doorstuurpad was bijvoorbeeld op een tamelijk complexe manier gestructureerd en bestond uit een geneste lijst: de lijsten op het eerste niveau bevatten een informatieveld en elk van deze informatievelden werd gevolgd door nog een lijst, die de hop fields bevatte. Vervolgens werd deze structuur voor elk padsegment herhaald. Zo'n structuur is redelijk eenvoudig te programmeren in software, maar vormt een uitdaging bij rechtstreekse implementatie op hardware, waar alle resources statisch moeten worden toegewezen.

Een ander voorbeeld is dat de headers een veld bevatten dat aangaf welke adrestypen werden gebruikt voor de eindhosts. Voorbeelden van zulke adrestypen zijn IPv4- en IPv6-adressen. Deze adrestypen hebben verschillende lengtes. Het feit dat alleen het type, en niet de lengte, van deze adressen in het pakket werd vermeld, betekende dat elk knooppunt tussen de eindhosts op de hoogte moest zijn van de adrestypen. Terwijl tussenliggende knooppunten eigenlijk alleen maar de lengte van de adressen hoeven te weten, omdat ze de adressen zelf niet verwerken. We koppelden deze en andere observaties terug naar het SCION-team, samen met voorstellen voor oplossingen. De oplossingen werden vervolgens opgenomen in een nieuwe versie van de SCION-headers. Het probleem met de structuur van het doorstuurpad werd bijvoorbeeld opgelost door eerst alle algemene informatievelden voor de verschillende segmenten te vermelden, gevolgd door een lijst van alle hop fields. Hierdoor kunnen we SCION efficiënter implementeren en een groter aantal hop fields binnen een pad ondersteunen. In Figuur 2 zie je het oude en het nieuwe ontwerp voor de padindeling.

Figuur 2: Oude en nieuwe indeling van het doorstuurpad in de SCION-header

Geïmplementeerde functionaliteit in ons prototype

We hebben de elementaire doorstuurfuncties van SCION geïmplementeerd, maar ondersteunen nog niet alle SCION-functionaliteit. Zo hebben we bijvoorbeeld nog geen ondersteuning toegevoegd voor peering of voor het retourneren van SCMP-foutberichten. Met de uitbreidingen EPIC en COLIBRI voor SCION, die extra beveiliging en QoS bieden, zullen de cryptografische MAC’s in de hop fields bovendien worden gebonden aan afzonderlijke pakketten. Dat betekent dat we voor die pakketten niet langer gebruik zullen kunnen maken van de aanpak waarbij we alle hop fields opslaan in een verificatietabel. Afhankelijk van hoeveel pakketten die uitbreidingen gebruiken, kan het een oplossing zijn om ze ter verificatie door te sturen naar het control plane op de switch of naar een extern knooppunt dat cryptografische ondersteuning op hardware biedt.

Ons prototype draaien

We begonnen met het testen van de implementatie op het Tofino-softwaremodel om de functionaliteit te controleren. Toen dat eenmaal in orde was, wisten we dat de implementatie ook zonder wezenlijke problemen zou werken op de daadwerkelijke hardware. Om onze implementatie in de praktijk uit te proberen, maakten we gebruik van het 2STiC-testbed, dat bestaat uit P4-programmeerbare apparatuur bij verschillende 2STiC-consortiumpartners in Nederland. Voor onze tests gebruikten we drie Edgecore Wedge 100BF-32X, die 32 QSFP28-poorten hebben die tot 100 Gbit/sec per poort ondersteunen. In totaal heeft elke switch een maximale doorvoer van 3,2 Tbit/sec. Daarnaast zijn we bezig met het aansluiten van één APS Networks BF2556X-1T switch, die met 48 SFP28- en 8 QSFP28-poorten een maximale doorvoer heeft van 2,0 Tbit/s.

We draaiden onze implementatie op een kleine topologie bestaande uit drie SCION-AS’en op verschillende locaties van het 2STiC-testbed en zijn bezig met het aansluiten van een vierde AS (weergegeven in Figuur 3 hieronder). Elk SCION-AS in onze test bestaat uit een van de hierboven genoemde programmeerbare switches die fungeert als de grensrouter en een op de switch aangesloten server die de overige SCION-diensten levert. Met deze opstelling hebben we laten zien dat de implementatie functioneert in een praktisch scenario. In de toekomst zal een meer gedetailleerde evaluatie worden uitgevoerd, met daarbij ook een prestatieanalyse.

Figuur 3: De topologie waarmee we onze implementatie testten op het 2STiC-testbed, inclusief extra nog aan te sluiten AS. In deze topologie is AS 112 de kern van het isolatiedomein, dat alle AS’en bevat.

Conclusie

Met onze implementatie hebben we de kracht en flexibiliteit van P4 en programmeerbare netwerkapparatuur laten zien, want daardoor konden we een implementatie van het SCION-protocol rechtstreeks op een ASIC draaien. Tegelijkertijd hebben we aangetoond dat we SCION op hardware kunnen draaien met hoge snelheden.

Onze implementatie is nu beschikbaar als opensource. Ideeën voor toekomstig onderzoek zijn onder meer optimalisatie van de implementatie om nog hogere prestaties te bereiken, het toevoegen van aanvullende functionaliteit en het experimenteren met ondersteuning voor uitbreidingen op SCION, zoals EPIC en COLIBRI. We zijn van plan om onze implementatie en de geleerde lessen in meer detail te bespreken in een komende publicatie.

Met dank aan

Wij bedanken SURF voor het leveren van de fysieke infrastructuur voor het 2STiC-testbed. Dit werk maakt deel uit van het 2STiC-onderzoeksprogramma (https://www.2stic.nl/), een samenwerking van AMS-IX, Technische Universiteit Delft, NDIX, NLnet Labs, SIDN Labs, SURF, Universiteit van Amsterdam en Universiteit van Twente.