Deze week nam SURF in Manchester deel aan de 54e LHCOPN-LHCONE bijeenkomst, waar wereldwijde experts bijeenkwamen om de evolutie van onderzoeksnetwerken te bespreken. Het was een speciale gelegenheid, want we vierden 20 jaar sinds de eerste LHCOPN bijeenkomst, waarbij we stilstonden bij hoe ver we zijn gekomen in het mogelijk maken van hogesnelheidsgegevensoverdracht van CERN’s Large Hadron Collider (LHC) naar onderzoekers wereldwijd.
SURF organiseert IT-infrastructuur om wetenschap mogelijk te maken – bijvoorbeeld om onderzoekers te helpen de fundamentele natuur van het universum te onderzoeken. Of het nu gaat om LHC-fysici die zoeken naar de bouwstenen van materie of SKA-astronomen die luisteren naar de zwakste signalen uit het vroege heelal, beide velden genereren enorme hoeveelheden gegevens die de grenzen van computers en netwerken opzoeken.
De sessies over de zich ontwikkelende netwerkinfrastructuur van de LHC hebben waardevolle lessen opgeleverd voor de discussie over de ontwikkeling van de datasystemen van het SKA observatorium. Hoewel de schaal en patronen van dataverkeer kunnen verschillen, was het verkennen van synergieën tussen NREN-gebaseerde netwerken voor LHC en SKA bijzonder inzichtelijk.
Natuurlijk is geen bijeenkomst compleet zonder pittige debatten – deze keer over de bredere uitdagingen van het uitbreiden van netwerkmogelijkheden voor grootschalige wetenschappelijke projecten. Het gesprek bracht natuurlijk vragen naar boven over vertrouwen, Acceptable Use Policies (AUP) en de impact op bestaande gemeenschappen. De balans tussen openheid en veiligheid, integratie en specialisatie is een lastige. En zoals de geschiedenis heeft laten zien, komen discussies over gecentraliseerde versus gefedereerde modellen na verloop van tijd weer naar boven – soms verpakt in nieuwe voorstellen, soms in een bekende rode kleur.
Zoals altijd op deze bijeenkomsten vermengden technische discussies zich met bredere vragen over beleid, vertrouwen en bestuur – sommige ontvouwden zich tijdens gestructureerde sessies, andere in die klassieke last-minute deep dives wanneer de tijd drong. Want in onderzoeksnetwerken gaan de grote vragen nooit alleen over technologie.
Dankbaar voor de boeiende discussies, de gedeelde kennis en de mooie openingstocht door het verleden. Genoeg om over na te denken en nog meer om te onderzoeken – laten we de vaart erin houden!
Terug van #APAN59, en wat een fantastische ervaring! Het was een eer om SURF en #NetherLight te vertegenwoordigen en hun impact op internationale onderzoekssamenwerkingen te benadrukken – vooral tussen wetenschappers in Japan en Nederland.
Het was geweldig om collega’s over de hele wereld weer face to face te spreken, nieuwe contacten te leggen en nieuwe inzichten op te doen. Enorme dank aan alle sprekers en moderators voor hun uitstekende werk, inclusief mijn dierbare collega Alexander van den Hil wiens expertise ook als moderator ik zeer bewonder!
En natuurlijk heel veel dank aan iedereen die dit evenement zo waardevol heeft gemaakt, en aan #APAN voor een uitstekende conferentie. Ik kijk uit naar de volgende!
皆さん、本当にありがとうございました！ (Minasan, hontō ni arigatō gozaimashita!) Hartelijk dank allemaal!
Om mogelijke aanvallen en besmettingen beter te kunnen detecteren en opsporen, is het handig om DNS-logging te kunnen doorzoeken. Omdat DNS-logs privacygevoelig zijn, heeft SURF een systeem ontwikkeld waarbij het mogelijk is om DNS-data met zo veel mogelijk behoud van privacy van de eindgebruikers te loggen. In deze blog leg ik uit hoe deze privacyvriendelijke DNS-logging technisch werkt.
Aanleiding privacyvriendelijke DNS-logging
Als een bij SURF aangesloten instelling getroffen is door een cyberaanval, willen andere instellingen weten of de daders mogelijk ook hun infrastructuur zijn binnengedrongen. Een van de bronnen om te raadplegen zijn DNS-logs: overzichten van domeinnamen die door eindgebruikers of systemen zijn opgevraagd. Veel instellingen gebruiken de DNS-servers van SURF via SURFdomeinen en daarvoor werden deze logs eerder niet vastgelegd. Op verzoek van de instellingen heeft SURF een systeem ontwikkeld om dit doen, maar met zo veel mogelijk behoud van privacy van de eindgebruikers.
Privacy-by-design
Hoewel de DNS-verzoeken nuttig kunnen zijn voor het beschermen van de gebruikers van het SURF-netwerk, zijn ze ook privacygevoelig. Ze laten bijvoorbeeld zien welke websites een gebruiker heeft bezocht. Het is daarom belangrijk om zorgvuldig met deze data om te gaan en een privacy-by-design-aanpak te volgen bij het beschikbaar stellen van DNS-logging.
Om beveiligingsproblemen te detecteren hoeven we niet alle DNS-verzoeken van een individuele gebruiker te weten; we hoeven alleen te weten welke gebruikers een kwaadaardige domeinnaam hebben opgevraagd. We hebben daarom een systeem ontwikkeld waarbij we precies dit afdwingen met behulp van cryptografische technieken: het is alleen mogelijk om in de DNS-logging te zoeken op basis van een domeinnaam. We slaan echter niet de opgevraagde domeinnaam op, maar alleen afgeleide informatie hiervan, gebaseerd op een zogenaamde hash. We combineren deze hash met een geheime sleutel, zodat alleen personen met toegang tot deze sleutel de benodigde hash kunnen berekenen (voor de kenners: we gebruiken HMAC-SHA256).
Logdata veilig opgeslagen door middel van hashing Met een hash-algoritme kan voor een gegeven tekst (zoals een domeinnaam) een schijnbaar willekeurige code worden berekend. Dit werkt echter niet de andere kant op: voor een code kan je niet eenvoudig terugrekenen welke tekst hierbij hoort. Je kan dus wel makkelijk berekenen dat voor surf.nl de bijbehorende hash 92A406…683887 is, maar je kan dus niet zomaar achterhalen welke domeinnaam hoort bij de hash C75871…93D2B2.
Het systeem slaat de informatie over de gebruiker versleuteld op – met behulp van het cryptografische algoritme ChaCha20Poly1305. Deze informatie kan alleen worden ontsleuteld als deze gebruiker een domeinnaam heeft opgevraagd waarnaar gezocht wordt in het systeem. De sleutel die wordt gebruikt om de gebruikersinformatie op te slaan, berekenen we namelijk door een geheime sleutel te combineren met de opgevraagde domeinnaam. Als je deze domeinnaam niet weet, kan je de benodigde sleutel niet achterhalen en de gebruikersinformatie dus niet ontsleutelen.
In Figuur 1 zie je een voorbeeld van de informatie die we opslaan. De opgevraagde domeinnaam (malware.evil.nl) en het hoofddomein (evil.nl) worden zodanig opgeslagen dat deze niet meer kunnen worden ontsleuteld (ook niet met de rode respectievelijk groene sleutel) en alleen kunnen worden gebruikt voor het opzoeken van data. Om de informatie over de client (192.0.2.123) die de domeinnaam heeft opgevraagd te kunnen ontsleutelen is zowel de blauwe sleutel als de opgevraagde hoofddomeinnaam (evil.nl) nodig om de benodigde gele sleutel te kunnen berekenen. Het is later dus wel mogelijk om op te zoeken wie malware.evil.nl heeft opgevraagd, maar niet welke domeinnamen de gebruiker met IP-adres 192.0.2.123 allemaal heeft opgevraagd.
Procedurele maatregelen om privacy van eindgebruikers te beschermen
Verder treffen we nog een aantal procedurele maatregelen om de privacy van eindgebruikers zo veel mogelijk te beschermen: alleen leden van SURFcert krijgen toegang tot het systeem, en alle zoekopdrachten in het systeem worden bijgehouden in een auditlog. Dit auditlog zal regelmatig worden nagelopen, waarbij degene die de zoekopdracht heeft uitgevoerd moet verantwoorden waarom deze is uitgevoerd. Verder worden alle logdata maximaal negentig dagen bewaard.
Met deze technische en procedurele maatregelen hebben we een systeem ontwikkeld dat SURFcert de mogelijkheden geeft om beveiligingsproblemen op te sporen, terwijl we tegelijk de privacy van de gebruikers zoveel mogelijk beschermen doordat het gedrag van individuele gebruikers niet kan worden gevolgd.
Meer weten?
Wil je meer weten over dit systeem, neem dan contact met me op via joeri.deruiter@surf.nl.
Wist je dat radiotelescopen tot op de nano seconden (1/1.000.000.000 s) nauwkeuring gesynchroniseerd worden via het SURF Netwerk? En dat de VU het door SURF getransporteerde frequentie signaal gebruikt om het gewicht van een elektron te bepalen?
Via het nieuwe SURF Time&Frequency netwerk wordt de Nederlandse UTC tijd van VSL in Delft met zeer hoge precisie door heel Nederland getransporteerd over het SURF glasvezel netwerk.
Wil je mee weten? Vorige maand nam ik bij SURF een podcast op over Time & Frequency Transfer. Hierin leg ik uit wat deze techniek is en waarvoor het gebruikt wordt.
Sinds de jaren negentig heeft SURF IP Multicast ondersteund binnen haar netwerk. Wat ooit begon als een speciaal netwerk voor deze technologie, groeide uit tot een standaard onderdeel van het SURF-netwerk. Echter, na decennia van gebruik, heeft SURF besloten om IP Multicast uit te faseren. In deze blogpost leg ik uit wat IP Multicast precies is, hoe het in het verleden binnen SURF werd gebruikt, en waarom de technologie nu plaats moet maken voor moderne alternatieven.
Wat is IP Multicast?
IP Multicast is een technologie die het mogelijk maakt om data op een schaalbare manier van een server naar meerdere ontvangers te versturen. De server hoeft de data slechts één keer te verzenden, waarna het netwerk zorgt voor de replicatie naar alle ontvangers.
Een voorbeeld hiervan is het uitzenden van een live college naar verschillende universiteiten in Nederland. In plaats van dat de live videostream meerdere keren vanuit de bron wordt verzonden (één keer voor elke ontvanger), wordt het via IP Multicast slechts één keer verstuurd. Vervolgens zorgt het netwerk ervoor dat de stream naar alle aangesloten universiteiten wordt gedistribueerd. Dit vermindert de benodigde bandbreedte en zorgt voor een efficiënter gebruik van netwerkbronnen.
Gebruik en toepassingen binnen SURF
Door de jaren heen is deze technologie op verschillende manieren getest en gebruikt door aangesloten instellingen. Voorbeelden van toepassingen waren:
Het versturen van televisiekanalen naar studentenhuizen.
Het uitzenden van webcambeelden, zoals die van de kust van Vlissingen.
Het verzenden van satelliet weerbeelden vanuit Duitsland naar het KNMI en universiteiten in verschillende Europese landen.
Waarom wordt IP Multicast tegenwoordig minder gebruikt?
Hoewel IP Multicast ooit veelbelovend was, wordt het tegenwoordig steeds minder toegepast vanwege de complexiteit in het beheer en de beperkingen in moderne netwerken. In cloud-omgevingen, waar netwerken vaak dynamisch en virtueel zijn, kan IP Multicast moeilijk te implementeren zijn. Veel netwerken geven de voorkeur aan unicast streaming en Content Delivery Networks vanwege hun betere schaalbaarheid en flexibiliteit.
Unicast streaming stuurt aparte datastromen naar elke ontvanger, wat meer bandbreedte vereist, maar door de toegenomen capaciteit van moderne netwerken is dit geen groot probleem meer
Waarom stopt SURF met IP Multicast?
Geen van de oude toepassingen van IP Multicast is nog actief, en IP Multicast wordt al geruime tijd niet meer gebruikt op het SURF-netwerk. Het ondersteunen van IP Multicast brengt aanzienlijke protocolcomplexiteit met zich mee, zowel voor SURF als voor de aangesloten instellingen.
Door IP Multicast uit te faseren, vereenvoudigt SURF de netwerkprotocollen. Dit besluit markeert het einde van een tijdperk, maar opent ook de deur naar nieuwe technologieën en maakt een minder complexe migratie naar een volgende generatie netwerk in de toekomst mogelijk.
Per januari 2024 veranderen de namen van de netwerkdiensten. Dit doen we om onze diensten beter aan te laten aansluiten bij de termen en conventies die in de netwerkcommunity gebruikt worden. Hiermee hopen we dat het voor netwerkbeheerders duidelijker is welke diensten er geleverd worden.
Huidige dienstnaam
Nieuwe naam per 1 jan 2024
SURFlichtpad
EVPN – Point-to-point
SURFlichtpad – Redundant
EVPN – Point-to-point Redundant
L2VPN
EVPN – Multipoint
L3VPN
L3VPN – Multipoint
SURFinternet
Internet
Multi Service Poort (MSP)
Service Port
Lichtpad wordt EVPN
De term lichtpad, hoewel goed ingeburgerd binnen het SURF taalgebruik, heeft altijd een zekere verwarring gezaaid. Het betreft hier namelijk geen optisch belicht pad maar een dedicated netwerkverbinding over de servicelaag tussen twee punten. EVPN (Ethernet-VPN) is wat hier geleverd wordt en de toevoeging (Point to point vs Multipoint) geeft aan of deze tussen twee punten of meer dan twee punten is opgezet.
Multi Service Poort wordt Service Port
Onder het nieuwe All-In Netwerktarief, dat per 1 september 2023 is ingegaan, kunnen instellingen naar eigen inzicht hun netwerkpoort configuratie aanpassen. Dit maakt van de netwerkpoorten in feite allemaal “multi” servicepoorten. Daarom heten deze vanaf 2024 gewoon Service Port.
De gewijzigde namen zijn doorgevoerd in het netwerkdashboard, op (mijn)surf.nl en de op facturen.
Al heel lang leveren we SURFlichtpaden. Tot nu toe waren dit altijd ethernet-diensten met twee eindpunten. SURFlichtpaden hadden we in grofweg vier smaken; protected of redundant en op een Single Service Port (SSP, untagged) of Multi Service Port (MSP, tagged). Nu, met het nieuwe SURF-netwerk kunnen we nieuwe mogelijkheden toevoegen aan de SURFlichtpaden. Zo bieden we nu een multipoint-variant (ofwel L2VPN) aan en zijn er meer mogelijkheden op het gebied van redundantie en resiliency. Lees hier wat we tot nu toe hebben gedaan en wat we van plan zijn.
SURFlichtpaden hebben altijd een behoefte ingevuld om instellingen, of dislocaties van een instelling, met elkaar te verbinden. SURFlichtpaden worden dan ook vaak ingezet voor onderzoeksdoeleinden of voor de interne bedrijfsvoering. De laatste jaren zijn daar ook verbindingen met cloudproviders in alle soorten en maten bij gekomen, denk aan IaaS, SaaS, CaaS, DaaS; kortom *aaS. Voor bedrijfsvoering met *aaS-providers is vaak een hoge mate van beschikbaarheid van diensten noodzakelijk. Daarom zijn lichtpaden met dat doel behoorlijk populair geworden.
Maar lichtpaden hebben een aantal beperkingen. Ten eerste zijn ze Point-2-Point. Dat geeft controle, maar kan ook complex worden als je veel locaties of netwerken met elkaar wilt verbinden, omdat er veel individuele lichtpaden nodig zijn. Daarnaast is het lastig wanneer je over dergelijke lichtpaden redundante VLAN’s wilt doortrekken naar een cloudprovider. Dat veroorzaakt een groot risico op ethernet-loops, wat instabiliteit van het netwerk kan veroorzaken. Hier konden we in SURFnet7 geen goede oplossing voor bieden.
Met de migratie van SURFnet7 naar het nieuwe SURF-netwerk zijn we overgestapt van PBB-TE naar EVPN over MPLS. EVPN is een technologie geheel ge-ent op IP en ethernet-netwerken. Hierdoor heeft het ook nieuwe mogelijkheden om onze lichtpad-diensten door te evolueren naar de huidige tijd en behoeften van de aangesloten instellingen.
Wat is er dan nieuw?
Inmiddels is de migratie naar het nieuwe SURF-netwerk bijna afgerond. Heb je MSP’s (Multi Service Ports) die al naar het nieuwe SURF-netwerk zijn gemigreerd, dan kunnen wij daar nu multipoint lichtpaden aanbieden (L2VPN’s). Stel dat je een VLAN over het lichtpad hebt lopen tussen twee locaties, dan kun je er nu eenvoudig een derde locatie aan toevoegen. Zo heb je drie locaties met elkaar verbonden zonder dat dat een hele wirwar aan lichtpaden moet bouwen. Binnen het nieuwe SURF-netwerk netwerk neemt het verkeer ook altijd de meest optimale route door het netwerk.
Om het geheel te visualiseren laten we in het onderstaande voorbeeld zien hoe we drie netwerken met elkaar willen verbinden over een VLAN met de MSP’s. Ieder netwerk (of locatie) is verbonden met één MSP. Er kunnen daardoor geen ethernet-loops ontstaan, omdat elke locatie één koppeling heeft. Maar voor bedrijfskritische toepassingen is er helaas geen redundantie. Wanneer er iets gebeurt in dit scenario kunnen één of meerdere locaties bij een storing of werkzaamheden geïsoleerd raken.
Figuur 1: niet redundant L2VPN
Liefst zouden we natuurlijk ieder netwerk/locatie kunnen aansluiten op 2 MSP’s, voor meer redundantie. Maar wanneer we dit zomaar doen, ontstaan er gegarandeerd ethernet-loops., met verstoringen als gevolg. Zie hiervoor onderstaand voorbeeld. Ethernet heeft uit zichzelf geen looppreventie-mechanisme. Met als gevolg dat wanneer een loop ontstaat, pakketten eindeloos blijven rondzingen tot de loop onderbroken wordt. In SURFnet7 konden we een dergelijk scenario daarom niet aanbieden.
Figuur 2 Ethernet loops in een redundant L2VPN
Binnen EVPN (het protocol wat in het nieuwe SURF-netwerk gebruikt wordt voor lichtpaden en L2VPN’s) bestaan een aantal mechanismen die ervoor zorgen dat ethernet-loops niet meer kunnen ontstaan. Eén daarvan kunnen we nu aanbieden op het nieuwe SURF-netwerk: ‘Single-Active multihoming’ op een VLAN-service. Hiermee kunnen we een VLAN-service configureren op meerdere MSP’s op dezelfde locatie. Deze MSP’s worden gegroepeerd in een ESI (Ethernet Segment Identifier) en in deze ESI is altijd maar 1 poort actief. Wanneer de actieve poort down gaat wordt onmiddellijk de andere poort actief en deze nieuwe poort zal het verkeer forwarden. Bij de instelling zal MAC-learning ervoor zorgen dat alle MAC-adressen verplaatsen naar de nieuwe actieve poort. Dit gebeurt in slechts 1-2 seconden. In onderstaande figuur zie je hoe dat er uit zou zien. Daar zie je dat steeds 1 poort in een ESI-groep actief is en er een loopvrije topologie bestaat.
Figuur 3 Loop preventie mbv single-active multihoming in L2VPN
Mogelijke use cases
Nu is bovenstaande een vrij technisch verhaal. Mogelijk gaat het meer leven wanneer we wat mogelijke use cases toelichten.
EduVPN scenario
eduVPN is een VPN-dienst van SURF om medewerkers en studenten van een instelling thuis of op afstand veilig te laten werken. Op dit moment zijn we aan het testen of we de eduVPN-dienst betrouwbaarder kunnen maken met behulp van multihomed L2VPN, dat meer resiliance toevoegt op de eduVPN dienst. Dit scenario ziet er als volgt uit:
De eduVPN-servers draaien in twee datacenters in Amsterdam en worden met een lichtpad verbonden met de instelling. De eduVPN-dienst kan op dit moment alleen maar met statische routes verkeer uitwisselen tussen de instelling en eduVPN. Hierdoor is het niet mogelijk om met traditionele lichtpaden een redundant scenario te maken van deze dienst. Met gebruik van het ESI-mechanisme in de L2VPN kan dit wel.
Figuur 4 Usecase EduVPN
Bovenstaand scenario laat bovenin de eduVPN-dienst zien. De eduVPN-server kan bij outages verplaatst worden tussen datacentra. Bij de eduVPN -instelling wordt resilience bereikt door het gebruik van VRRP (of een variant hierop, zoals HSRP).
Twin datacenter plus cloud IaaS provider
Wanneer een instelling meerdere datacentra heeft en ook gebruik wil maken van een IaaS-provider, kan het gebruik van een L2VPN redundantie bieden. Dit kan gebruikt worden om bijvoorbeeld services naar de cloud provider te migreren of om bepaalde zaken uit te besteden. Hierdoor kan de behoefte ontstaan om de VLAN’s in de datacentra door te kunnen trekken naar de IaaS provider. Hierdoor kunnen systemen verplaatst worden zonder dat er omgenummerd hoeft te worden. Een dergelijk scenario zou er als volgt uit kunnen zien:
Ieder datacenter is dubbel aangesloten en heeft 2 poorten in een ESI-groep. Hierdoor ontstaan er geen loops en is voldoende redundantie. De L2VPN kan een bundel van VLAN’s bevatten.
Je krijgt dan het scenario in figuur 3. Waarbij 1 van de locaties een cloudprovider kan zijn
Toekomst
Met deze functionaliteit denken we een stap in de goede richting te hebben gezet om functies toe te voegen aan onze lichtpad-diensten die instellingen kunnen helpen.
EVPN kent nog meer mogelijkheden die wij kunnen benutten om, hopelijk, nog beter aan te sluiten bij de behoeften van instellingen.
Binnen de lichtpad-diensten hopen wij in de toekomst ook nog link-bundeling te kunnen doen op basis van LACP over meerdere chassis’ (MC-LAG). Veel instellingen gebruiken al een vorm van Virtual-Chassis of VSS voor redundantie. MC-LAG zou hier mooi op aan kunnen sluiten. Hierdoor kunnen beide interfaces die een ESI vormen tegelijk actief zijn.
Figuur 5 Multi-chassis link aggregation
Daarnaast zijn we bezig met het ontwikkelen van een L3VPN dienst. L3VPN is een virtuele router die op SN8 geconfigureerd kan worden. Deze virtuele router kan bijvoorbeeld gebruikt worden om meerdere cloud providers (MS Azure of Amazon AWS) op efficiënte wijze met een instellingsnetwerk te koppelen.
Figuur 6 L3VPN multicloud voorbeeld
Heb je ideeën of vragen over deze nieuwe mogelijkheden en functionaliteiten? Of heb je suggesties die ons kunnen helpen de dienst verder te ontwikkelen? Neem dan contact met mij op!
