IPsec beveiligt IP-verkeer op pakketniveau
Bij de implementatie van een IPv6-netwerk raden we aan om ook IPsec mee te nemen
Vint Cerf had 50 jaar geleden bij het bedenken van het TCP/IP-protocol meer aandacht moeten besteden aan de beveiliging ervan. Daarnaast had hij in een grotere adresruimte moeten voorzien. Zo vertelde hij onlangs in een interview met IEEE Spectrum.
Dat IPv6 de adresruimte van IPv4 uitbreidt van 32 naar 128 bits is de meesten wel bekend. Die grotere adresruimte is immers de belangrijkste reden waarom we naar IPv6 overstappen. Dat IPv6 ook de versleuteling van verbindingen met IPsec standaard ondersteunt is minder bekend.
"IPsec maakt gebruik van de Extension Headers van IPv6, terwijl dit protocol er destijds bij IPv4 toch min-of-meer ingehackt moest worden." Zo vertelt Paul Wouters, nu Senior Security Architect by Aiven, een van de 2 Security Area Directors bij de IETF, auteur van diverse RFC's, en long-time ontwikkelaar van Libreswan en zijn voorgangers. "IPsec is niet heel zichtbaar voor de eindgebruiker, maar het zit echt overal in: datacenters, clusters, militaire netwerken en gevirtualiseerde omgevingen hangen aan elkaar met IPsec. Het zit in mobiele en internettelefonie. Zorginstellingen zijn vaak wetmatig verplicht om IPsec te gebruiken. En de Airbus gebruikt IPsec om te voorkomen dat passagiers ooit op het interne vliegtuignetwerk kunnen komen. IPsec is dan ook onderdeel van een enorm aantal IETF-protocollen."
IPsec is de jaren '90 ontwikkeld door de IP Security Working Group van de IETF, waarbij verschillende Amerikaanse overheidsorganisaties als meewerkende sponsor fungeerden. Het protocol (gedefinieerd in RFC 4301) beveiligt zowel de headers als de inhoud (payload) van de IP-netwerkpakketten (datagrammen). Daarmee bevindt IPsec zich tussen het Internet Protocol en daarboven liggende transportprotocollen als TCP, UDP en SCTP.
Figuur 1: IPsec bevindt zich tussen het Internet Protocol en daarboven liggende transportprotocollen.
IPv6
IPsec is ontwikkeld parallel aan IPv6 en was in eerste instantie zelfs een verplicht onderdeel daarvan. RFC 6434 (nu RFC 8504) veranderde deze verplichting echter in een aanbeveling.
Een oud gerucht zegt dat de NSA destijds de ontwikkeling en implementatie van een veilige IPsec-standaard heeft gefrustreerd, maar volgens Wouters is dat zwaar overtrokken. Uit onder andere de onthullingen van Snowden bleek in ieder geval wel dat de IPsec-beveiliging een doelwit is van de NSA.
Ondanks dat de implementatie uiteindelijk toch geen verplichting is geworden, wordt IPsec inmiddels standaard ondersteund door vrijwel alle actuele netwerkapparatuur en besturingssystemen. Dat je als eindgebruiker weinig ziet van IPsec, komt omdat het protocol zich op een lager niveau in de netwerkstack bevindt. IPsec is vooral zichtbaar bij gebruik voor Virtual Private Networks (VPN's), maar het wordt ook ingezet tussen datacenters, als onderdeel van mobiele en internettelefonie, en in cloudomgevingen. Hoewel de versleuteling van IPsec op IP-pakketniveau gebeurt, vinden sleutel- en sessiemanagement wel op hoger niveau plaats. Daarmee werkt het protocol ook goed voor verbindingen met veranderende IP-adressen (mobiele gebruikers).
Verschillende beschermingsniveaus en -modi
IPsec biedt van origine 2 beschermingsniveaus: de Authentication Header (AH) en Encapsulating Security Payload (ESP). Beide technieken kunnen elk weer in transportmodus of in tunnelmodus gebruikt worden. Om met dat laatste tweetal te beginnen: in transportmodus blijft de originele header van de datagrammen gebruikt worden, terwijl in tunnelmodus het oorspronkelijke datagram (bestaande uit header en payload) in een hele nieuwe header wordt verpakt (afgeleid van het recht-toe-recht-aan 'IP Encapsulation within IP'-protocol gedefinieerd in RFC 2003).
Daarmee is transportmodus bedoeld voor host-to-host-verbindingen (point-to-point), terwijl tunnelmodus vooral voor host-gateway- (remote access) en gateway-gatewayverbindingen (site-to-site) wordt ingezet. Bij dat laatste kun je denken aan LAN-to-LAN VPN's om verschillende bedrijfsvestigingen met elkaar te verbinden.
In alle gevallen wordt op de interface van de host/gateway besloten (naar aanleiding van de ingestelde policy’s) of pakketten worden versleuteld, gedropt of onversleuteld doorgestuurd (vergelijk een packet filter).
ESP en AH
Dan het verschil tussen AH en ESP: AH (gedefinieerd in RFC 4302) gebruikt een HMAC/digitale handtekening om niet alleen de integriteit van de payload te beschermen, maar ook die van de onveranderlijke onderdelen van de packet header. Bij dat laatste moet je denken aan de vaste source- en destination-adressen, terwijl de TTL/hop-limiet en het ToS-veld (de Traffic Class in IPv6) daarentegen onderweg kunnen worden aangepast en dus niet op deze manier beschermd kunnen worden.
ESP (gedefinieerd in RFC 4303) beschermt niet de headers zoals AH dat doet, maar beperkt zich tot de payload van de IP-pakketten. Het belangrijkste onderscheid is echter dat ESP de payload ook compleet versleutelt. Daarmee is niet alleen de integriteit maar ook de vertrouwelijkheid van de berichten beschermd.
Voor de duidelijkheid: Gebruik je ESP in tunnelmodus – veruit de meest gebruikte toepassing van IPsec – dan zijn zowel de payload als de volledige header van het ingekapselde pakket beschermd. Gebruik je AH in tunnelmodus, dan worden ook de onveranderlijke onderdelen van de buitenste header meegenomen. Dat laatste doet echter niemand: die enkele keer dat je het oudere AH-protocol in de praktijk nog tegenkomt, gaat het om host-to-host-verbindingen waarbij AH in transportmodus wordt gecombineerd met pure IP-in-IP-tunneling (gedefinieerd in RFC 1853).
Figuur 2: IPsec biedt van origine 2 beschermingsniveaus en 2 gebruiksmodi.
Meer beveiligingsfeatures
Wat AH en ESP delen, is dat ze allebei de bron authentiseren – in dit geval niet expliciet, maar simpelweg doordat alleen de afzender de geheime sleutel heeft waarmee het betreffende bericht ondertekend/versleuteld is.
Forward secrecy wordt bereikt door de sessiesleutels elk uur te vervangen. Wil je het helemaal goed doen, dan baseer je de volgende sessiesleutel niet op de huidige seed, maar doe je telkens een nieuwe sleuteluitwisseling op basis van DH (perfect forward secrecy).
Andere beschermingsmogelijkheid is de verhindering van verkeersanalyse door in tunnel-modus alle pakketten even lang te maken (middels padding) of zelfs "lege" pakketten (bestaande uit alleen maar padding) tussendoor te sturen.
Daarnaast kan de ontvanger zich beschermen tegen replayaanvallen door ook het (IPsec-)volgnummer van het pakket (meegenomen in de hashberekening) te valideren. Maar deze bescherming is eigenlijk overbodig: UDP is pakketgebaseerd, wat betekent dat de applicatielaag daarboven retransmits sowieso veilig moet kunnen afhandelen. En TCP bevat al zijn eigen volgnummer (de basis onder de betrouwbare end-to-end-verbindingen).
De laatste mogelijkheid die we hier moeten noemen is IPComp, een datacompressietechniek (gedefinieerd in RFC 3173) die uitgevoerd wordt vóór de ESP-versleuteling. Dat laatste is belangrijk omdat het comprimeren van versleutelde berichten zinloos is: kenmerk van een goede versleuteling is immers dat er geen informatie meer uit de cyphertekst te destilleren is. IPComp wordt echter nog maar weinig toegepast, omdat compressie vaak al op applicatieniveau plaatsvindt.
ESP als vervanger van AH
Waar je voorheen AH en ESP ook nog tegelijkertijd (of ingekapseld) kon inzetten om zowel de integriteit van de header als de vertrouwelijkheid van de payload te beschermen, is dat sinds IPsec versie 3 niet meer nodig. De huidige versie van ESP (inmiddels ondersteund door alle implementaties) heeft de bescherming van de header geïncorporeerd, waarmee het gebruik van AH voor nieuwe installaties nu afgeraden wordt.
Voor apparatuur of software die IPsec ondersteunt, is de implementatie van ESP nu ook verplicht en die van AH optioneel. Wil je om wat voor reden dan ook de encryptie toch weglaten, dan kan dat door ESP met de NULL-versleuteling te gebruiken.
Voor wie zich afvraagt waarom AH en ESP zo veel op elkaar lijken: AH is ietsje ouder, maar in dezelfde periode ontwikkeld als ESP. Omdat (sterke) cryptografie in die tijd niet uit de VS geëxporteerd mocht worden, zijn er toen 2 verschillende technieken naast elkaar gezet.
Internet Key Exchange
Voor de instelling van IPsec en de onderlinge afstemming en uitwisseling van sleutelmateriaal maken de betrokken hosts en gateways gebruik van IKEv2, een 'key management'-protocol gedefinieerd in RFC 7296. Uitgangspunt zijn IPsec-policy’s voor elke deelnemende host en gateway.
Bij het opzetten van verbindingen gaan systemen eerst te rade bij hun IKEv2-server. Op die manier worden de te gebruiken encryptieprotocollen en sleutels overeengekomen (de zogenaamde Security Associations).
Waar IPsec zelf zich op de internetlaag bevindt en onderdeel is van de netwerk-stack (in kernel space), is IKE een apart protocol dat gebruikmaakt van een daemon draaiend op UDP-poort 500 (in userland).
Het IPSECKEY-record
De algoritmen beschikbaar voor hashing, versleuteling en compressie door ESP en AH zijn gedefinieerd in RFC 8221. Die voor IKEv2 in RFC 8247. De laatste updates op deze twee documenten vind je in RFC 9395.
Naast gedeelde sleutels kunnen bij het opzetten van IPsec-verbindingen ook PKI-certificaten (X.509) of rauwe publieke sleutels worden gebruikt. Voor dat laatste is het IPSECKEY-record bedacht (in RFC 4025), waarbij de bescherming met DNSSEC onontbeerlijk is.
Merk op dat systemen op het laagste niveau vaak niet de naam maar alleen het IP-adres van de andere partij kennen, wat IKE/IPSECKEY een use case maakt voor de implementatie van DNSSEC op Reverse DNS (rDNS).
Problemen met NAT
Hoewel de veranderlijke onderdelen van de headers niet worden meegenomen in de hashberekening van AH/ESP, blijken ook de onveranderlijke onderdelen in sommige gevallen problemen op te leveren. Zo verandert NAT – dat wij niet voor niets regelmatig een ongewenst lapmiddel hebben genoemd – de ooit onveranderlijk geachte source- en destination-adressen van een IP-pakket.
Zit er een NAT-gateway in de weg, dan kun je alleen ESP-tunnels gebruiken in combinatie met NAT Traversal. RFC 3947 en 3948 beschrijven hoe je ESP- en IKE-verkeer inkapselt in UDP (voorzien van een eigen onbeschermde header) en over poort 4500 geleidt (ESPinUDP). Als je netwerk-stack ook ESPinTCP (gedefinieerd in RFC 8229) ondersteunt, dan kun je dat gebruiken om firewalls (die UDP-verkeer vaak blokkeren) te passeren via een wel bereikbare TCP-poort (denk aan TLS over poort 443 of zelfs HTTPS-encapsulatie).
Gaten in de perimeter
Tegelijkertijd willen we hier waarschuwen voor het gebruik van tunnels om firewalls en gateways te passeren. Ze zijn een bekende bron van gaten in de perimeter. Dan is een betere strategie om NAT onderdeel te maken van de IPsec-gateway (of het NAT-systeem direct voor het IPsec-systeem te plaatsen).
"Op het originele internet konden alle hosts elkaar direct op hun publieke IP-adres bereiken," vertelt Wouters. "Maar toen kwam eerst NAT en daarna CGNAT. Wat we nu kunnen met ESPinTCP kon vroeger niet. Vandaar de opkomst destijds van een protocol als OpenVPN, dat noodgedwongen in userland draait en daardoor veel trager is dan een netwerkprotocol dat in kernel space draait. Het moderne Wireguard draait wel in kernel space en het pakketformaat lijkt ook erg op dat van ESP, maar het protocol is minder volwassen dan IPsec en bevat verschillende inefficiënties die het trager maken. Daarnaast ontbreekt bijvoorbeeld ondersteuning van DHCP en DNS, die wel onderdeel zijn van IKEv2. Hetzelfde geldt voor AES-GCM (gedefinieerd in RFC 8452), dat tegenwoordig in bijna elke processor zit ingebakken."
Geen eenvoudig protocol
Zoals je ziet, is IPsec bepaald geen eenvoudig protocol. Sterker nog, destijds werd gezegd dat meewerkende Amerikaanse overheidsdiensten deze standaarden expres zo ingewikkeld maakten, om later hopelijk gaten in de implementaties te kunnen exploiteren. RFC 4301 is ook bepaald niet toegankelijk en daarmee ongeschikt om de basisconcepten van IPsec te begrijpen.
Het meest leesbare en uitgebreide document over IPsec dat we hebben gezien, is NIST's 'Guide to IPsec VPNs', waarvan Wouters de hoofdauteur is. Behalve dat deze publicatie de techniek goed uitlegt, biedt het ook belangrijke informatie voor de planning en toepassing van IPsec. Met name bij de implementatie of opwaardering van een IPv6-netwerk zouden we je aanraden om IPsec in je ontwerp mee te nemen.