Inzicht in het IPsec IKEv1-protocol

Inleiding

Dit document beschrijft het protocolproces voor Internet Key Exchange (IKEv1) voor een Virtual Private Network (VPN)-instelling.

Voorwaarden

Vereisten

Cisco raadt u aan kennis te hebben van basisbeveiligingsconcepten:

• Verificatie
• Vertrouwelijkheid
• Integriteit
• IPSEC

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Achtergrondinformatie

Het proces van Internet Key Exchange (IKEv1)-protocollen voor een VPN-installatie (Virtual Private Network) is belangrijk om de pakketuitwisseling te begrijpen voor een eenvoudiger probleemoplossing en elk type IPsec-probleem (Internet Protocol Security) met IKEv1.

IPSEC

IPsec is een reeks protocollen die beveiliging biedt voor internetcommunicatie op de IP-laag. Het meest gebruikelijke gebruik van IPsec is om een Virtual Private Network (VPN) te bieden, tussen twee locaties (gateway-to-gateway) of tussen een externe gebruiker en een ondernemingsnetwerk (host-to-gateway).

IKE-protocol

IPsec gebruikt het IKE-protocol om beveiligde site-to-site of externe VPN-tunnels (Virtual Private Network) te onderhandelen en tot stand te brengen. Het IKE-protocol wordt ook wel de Internet Security Association en Key Management Protocol (ISAKMP) genoemd (Alleen in Cisco).

Er zijn twee versies van IKE:

• IKEv1: gedefinieerd in RFC 2409, de Internet Key Exchange
• IKE versie 2 (IKEv2): gedefinieerd in RFC 4306, Internet Key Exchange (IKEv2)-protocol

IKE-fasen

ISAKMP scheidt onderhandeling in twee fasen:

• Fase 1: De twee ISAKMP-peers creëren een beveiligde en geverifieerde tunnel, die ISAKMP-onderhandelingsberichten beschermt. Deze tunnel staat bekend als de ISAKMP SA. Er zijn twee modi die door ISAKMP zijn gedefinieerd: Hoofdmodus (MM) en Agressieve modus.
• Fase 2: Het onderhandelt over de belangrijkste materialen en algoritmen voor de encryptie (SAs) van de gegevens die over de IPsec-tunnel moeten worden overgebracht. Deze fase wordt de Snelle modus genoemd.

Om alle abstracte concepten te materialiseren, is de fase 1 tunnel de Oudertunnel en fase 2 is een subtunnel. Dit beeld illustreert de twee fasen als tunnels:

Opmerking: fase 1 (ISAKMP)-tunnel beschermt het VPN-verkeer van besturingsplante tussen de twee gateways. Het verkeer van het controlevliegtuig kan Onderhandelingspakketten, informatiepakketten, DPD, keepalives, rekey, etc. zijn. ISAKMP-onderhandeling maakt gebruik van de UDP 500- en 4500-poorten om een veilig kanaal tot stand te brengen.

Opmerking: fase 2 (IPsec) tunnel beschermt het verkeer van het gegevensplane dat via VPN tussen de twee gateways wordt doorgegeven. De algoritmen die worden gebruikt om de gegevens te beveiligen, worden in fase 2 geconfigureerd en zijn onafhankelijk van de in fase 1 gespecificeerde algoritmen.
Het protocol dat wordt gebruikt om deze pakketten in te kapselen en te versleutelen is de Encapsulation Security Payload (ESP).

IKE-modi (fase 1)

Hoofdmodus

Een IKE-sessie begint wanneer de initiatiefnemer een voorstel of voorstel naar de respondent stuurt. De eerste uitwisseling tussen knooppunten bepaalt het basisveiligheidsbeleid; de initiatiefnemer stelt de te gebruiken encryptie en authentificatiealgoritmen voor. De respondent kiest het juiste voorstel (ervan uitgaande dat een voorstel is gekozen) en stuurt het naar de initiatiefnemer. De volgende uitwisseling passeert Diffie-Hellman openbare sleutels en andere data. Alle verdere onderhandeling wordt versleuteld binnen de IKE SA. De derde uitwisseling verifieert de ISAKMP-sessie. Zodra IKE SA wordt gevestigd, begint de onderhandeling IPSec (Snelle modus).

Agressieve modus

De agressieve modus perst de IKE SA-onderhandeling in drie pakketten, waarbij alle gegevens die vereist zijn voor de SA doorgegeven worden door de initiator. De respondent verzendt het voorstel, het belangrijkste materiaal en de ID en verifieert de sessie in het volgende pakket. De initiatiefnemer antwoordt en verifieert de sessie. De onderhandeling verloopt sneller en de initiator en het antwoord-ID gaan in de spatie door.

IPsec-modus (fase 2)

Snelmodus

IPsec-onderhandeling, of Quick Mode, is vergelijkbaar met een agressieve IKE-onderhandeling, behalve onderhandeling, die moet worden beschermd binnen een IKE SA. Quick Mode bespreekt de SA voor de gegevenscodering en beheert de sleuteluitwisseling voor die IPSec SA.

IKE-woordenlijst

• Een security association (SA) is de oprichting van gedeelde beveiligingskenmerken tussen twee netwerkentiteiten ter ondersteuning van beveiligde communicatie. Een SA bevat attributen zoals cryptografisch algoritme en modus, verkeerscoderingssleutel en parameters voor de netwerkgegevens die over de verbinding moeten worden doorgegeven.
• De verkoper-ID's (VID) worden verwerkt om te bepalen of de peer de functie NAT-Traversal, Dead Peer Detection, Fragmentation, enzovoort ondersteunt.
• Nonce: een willekeurig gegenereerd nummer dat de initiator verzendt. Deze eens wordt gehakt samen met de andere items met de overeengekomen gebruikte sleutel en wordt teruggestuurd. De initiatiefnemer controleert het cookie en de nonce en verwerpt alle berichten die niet het recht hebben. Dit helpt herhaling voorkomen aangezien geen enkele derde partij kan voorspellen wat de willekeurig gegenereerde nonce is.
• Key-exchange (KE) informatie voor het Diffie-Hellman (DH) beveiligde key-exchange proces.
• Identity Initiator/Responder (IDi/IDr.) wordt gebruikt om authenticatie-informatie naar de peer te sturen. Deze informatie wordt doorgegeven onder de bescherming van het gemeenschappelijk gedeeld geheim.
• Diffie-Hellman (DH) sleuteluitwisseling is een veilige methode van cryptografische algoritmen-uitwisseling via een openbaar kanaal.
  
• De IPSec gedeelde sleutel kan worden afgeleid met de DH die opnieuw wordt gebruikt om Perfect Forward Secrecy (PFS) te verzekeren of de originele DH-uitwisseling die aan het gedeelde eerder afgeleide geheim wordt verfrist.

Main Mode Packet Exchange

Elk ISAKMP-pakket bevat payloadinformatie voor de tunnelinstelling. De IKE-woordenlijst legt de IKE-afkortingen uit als onderdeel van de payloadinhoud voor de pakketuitwisseling in de hoofdmodus zoals in deze afbeelding.

Hoofdmodus 1 (MM1)

Om de voorwaarden van de ISAKMP-onderhandelingen te bepalen, maakt u een ISAKMP-beleid dat het volgende omvat:

• Een verificatiemethode om de identiteit van de peers te garanderen.
• Een coderingsmethode om de gegevens te beschermen en de privacy te waarborgen.
• Een Hashed Message Verification Codes (HMAC) methode om de identiteit van de afzender te controleren en om ervoor te zorgen dat het bericht niet is gewijzigd tijdens het transport.
• Een Diffie-Hellman groep om de sterkte van het encryptie-sleutel-bepalingsalgoritme te bepalen. Het security apparaat gebruikt dit algoritme om de encryptie en hash sleutels af te leiden.
• Een tijdslimiet voor het vervangen van het security apparaat door een coderingssleutel.

Het eerste pakket wordt verzonden door de Initiator van de IKE-onderhandeling zoals in de afbeelding wordt getoond:

 

Opmerking: de hoofdmodus 1 is het eerste pakket van de IKE-onderhandeling. Daarom wordt de Initiator SPI ingesteld op een willekeurige waarde terwijl de Responder SPI op 0 is ingesteld. In het tweede pakket (MM2) moet op de Responder SPI worden geantwoord met een nieuwe waarde en de gehele onderhandeling behoudt dezelfde SPI-waarden.

Als de MM1 wordt opgenomen en een Wireshark-netwerkprotocolanalyzer wordt gebruikt, bevindt de SPI-waarde zich in de inhoud van de Internet Security Association en Key Management Protocol zoals in de afbeelding:

Opmerking: in het geval dat het MM1-pakket verdwaalt in het pad of er geen MM2-antwoord is, houdt de IKE-onderhandeling de MM1-heruitzendingen tot het maximum aantal heruitzendingen is bereikt. Op dit punt, houdt de Initiator de zelfde SPI tot de volgende onderhandeling opnieuw wordt teweeggebracht.

Tip: de identificatie van SPI's van initiator en responder is zeer nuttig om meerdere onderhandelingen voor dezelfde VPN te identificeren en een aantal onderhandelingskwesties op te lossen.

Identificeer twee gelijktijdige onderhandelingen

Op de Cisco IOS® XE-platforms kunnen de debugs per tunnel worden gefilterd en kan een voorwaardelijk wachtwoord worden ingesteld voor het externe IP-adres dat is geconfigureerd. De gelijktijdige onderhandelingen worden echter op de logboeken weergegeven en er is geen manier om ze te filteren. Het is nodig om het handmatig te doen. Zoals eerder vermeld, houdt de gehele onderhandeling dezelfde SPI-waarden voor Initiator en Responder. Indien een pakket wordt ontvangen van hetzelfde peer IP-adres, maar de SPI niet overeenkomt met de vorige waarde die wordt bijgehouden voordat de onderhandeling het maximale aantal wederuitzendingen bereikt, is het een andere onderhandeling voor dezelfde peer zoals in de afbeelding wordt getoond:

Opmerking: Het voorbeeld toont gelijktijdige onderhandeling voor het eerste pakket in de onderhandeling (MM1). Dit kan echter op elk onderhandelingspunt gebeuren. Alle volgende pakketten moeten een waarde bevatten die afwijkt van 0 op de responder SPI.

Hoofdmodus 2 (MM2)

In het Main Mode 2 pakket verstuurt de respondent het geselecteerde beleid voor de gematchte voorstellen en de responder SPI wordt ingesteld op een willekeurige waarde. De gehele onderhandeling behoudt dezelfde SPI-waarden. De MM2 antwoordt op MM1 en de SPI-responder is ingesteld op een andere waarde dan 0 zoals in het beeld wordt weergegeven:

Als de MM2 wordt opgenomen en een Wireshark-netwerkprotocolanalyzer wordt gebruikt, bevinden de SPI-waarden van Initiator en Responder zich in de inhoud van de Internet Security Association en Key Management Protocol zoals in de afbeelding:

Hoofdmodus 3 en 4 (M3-M4)

De M3 en M4 pakketten zijn nog steeds niet versleuteld en niet geverifieerd en de geheime sleuteluitwisseling vindt plaats. In het beeld worden de volgende waarden voor M3 en M4 aangegeven:

Hoofdmodus 5 en 6 (M5-M6)

De M5- en M6-pakketten zijn al versleuteld maar nog niet geverifieerd. Op deze pakketten vindt de verificatie plaats zoals in de afbeelding:

Snelle modus (QM1, QM2 en QM3)

De snelmodus komt voor nadat de Main-modus en de IKE de beveiligde tunnel in fase 1 heeft ingesteld. De Quick Mode bespreekt het gedeelde IPSec-beleid, voor de IPSec-beveiligingsalgoritmen en beheert de sleuteluitwisseling voor de IPSec SA-vestiging. De nonces worden gebruikt om nieuw gedeeld geheim zeer belangrijk materiaal te produceren en terugspelen aanvallen van valse geproduceerde SAs te verhinderen.

In deze fase worden drie pakketten uitgewisseld zoals in de afbeelding:

Agressieve modus voor pakketuitwisseling

 De agressieve modus perst de IKE SA-onderhandeling in drie pakketten, waarbij alle gegevens die vereist zijn voor de SA doorgegeven worden door de initiator.

• De respondent verzendt het voorstel, het belangrijkste materiaal en de ID en verifieert de sessie in het volgende pakket.
• De initiatiefnemer antwoordt en verifieert de sessie.
• De onderhandeling verloopt sneller en de initiator en het antwoord-ID gaan in de spatie door.

Het beeld toont de payload-inhoud voor de drie pakketten die worden uitgewisseld in Aggressieve modus:

Hoofdmodus vs Aggressieve modus

Vergeleken met de Main Mode, Aggressive Mode komt neer op drie pakketten:

• AM 1 absorbeert M1 en M3.
• AM 2 absorbeert MM2, MM4 en een deel van de M6. Dit is waar de kwetsbaarheid van Aggressive Mode van komt. AM 2 maakt de IDr en verificatie unencrypted. In tegenstelling tot de hoofdmodus wordt deze informatie versleuteld.
• AM 3 biedt de IDi en de verificatie. Die waarden zijn versleuteld.

IKEv2 tegen IKEv1 Packet Exchange

In de IKEv2-onderhandeling worden minder berichten uitgewisseld om een tunnel tot stand te brengen. IKEv2 gebruikt vier berichten; IKEv1 gebruikt ofwel zes berichten (in de hoofdmodus) of drie berichten (in agressieve modus).

De IKEv2 berichttypes worden gedefinieerd als Vraag en Antwoord paren. De afbeelding toont de pakketvergelijking en de payloadinhoud van IKEv2 ten opzichte van IKEv1:

Opmerking: dit document gaat niet dieper in op de IKEv2 Packet exchange. Voor meer verwijzingen, navigeer naar IKEv2 Packet Exchange en Protocol Level Debugging.

Op beleid gebaseerd vs. routegebaseerd

Op beleid gebaseerde VPN

Zoals de naam aangeeft, is een op beleid gebaseerde VPN een IPsec VPN-tunnel met een beleidsactie voor het transitverkeer die voldoet aan de matchcriteria van het beleid. In het geval van Cisco-apparaten wordt een toegangslijst (ACL) geconfigureerd en aan een crypto-kaart gekoppeld om het verkeer op te geven dat naar de VPN moet worden omgeleid en versleuteld.

De traffic selectors zijn de subnetten of hosts die op het beleid zijn gespecificeerd zoals in de afbeelding:

Routegebaseerde VPN

Een beleid is niet nodig. Het verkeer wordt omgeleid naar de tunnels met routes, en het ondersteunt dynamische routing via de tunnelinterface. De traffic selectors (verkeer dat via VPN is versleuteld) worden standaard van 0.0.0.0 tot 0.0.0.0 ingesteld, zoals in de afbeelding:

Opmerking: vanwege de Traffic selectors zijn 0.0.0.0, elke host of subnetverbinding is inbegrepen in. Daarom wordt slechts één SA opgericht. Er is een uitzondering voor Dynamische tunnel. Dit document beschrijft geen dynamische tunnels.

Het beleid en de op route gebaseerde VPN kunnen worden gematerialiseerd zoals in de afbeelding:

Opmerking: in tegenstelling tot routegebaseerde VPN waarbij slechts één SA is gemaakt, kan de op beleid gebaseerde VPN multiples SA maken. Aangezien ACL wordt gevormd, leidt elke verklaring over ACL (als zij tussen hen) verschillend zijn tot een sub-tunnel.

Gemeenschappelijke problemen voor verkeer worden niet via VPN ontvangen

ISP blokkeert UDP 500/4500

Het is een zeer algemene kwestie dat de Internet Services Provider (ISP) de UDP 500/4500-poorten blokkeert. Voor een IPsec-tunnelinstelling kunnen twee verschillende ISP’s worden ingeschakeld. De ene kan de poorten blokkeren, de andere kan ze blokkeren.

Het beeld toont de twee scenario's waar een ISP de UDP 500/4500-poorten in slechts één richting kan blokkeren:

Opmerking: poort UDP 500 wordt gebruikt door de Internet Key Exchange (IKE) voor het opzetten van beveiligde VPN-tunnels. UDP 4500 wordt gebruikt wanneer NAT in één VPN-eindpunt aanwezig is.

Opmerking: wanneer de ISP UDP 500/4500 blokkeert, wordt de IPsec-tunnelinstelling beïnvloed en staat deze niet op.

ISP blokkeert ESP

Een ander veel voorkomend probleem bij IPsec-tunnels is de ISP die het ESP-verkeer blokkeert; deze maakt echter de UDP 500/4500-poorten mogelijk. De UDP 500/4500-poorten zijn bijvoorbeeld toegestaan op bidirectionele manieren. Daarom wordt de tunnel met succes opgezet, maar de ESP-pakketten worden door de ISP of ISP’s in beide richtingen geblokkeerd. Dit zorgt ervoor dat het versleutelde verkeer via VPN mislukt zoals in de afbeelding:

Opmerking: wanneer de ISP ESP-pakketten blokkeert, is de IPsec-tunnelinstelling succesvol, maar wordt het verkeer versleuteld beïnvloed. Het kan worden weergegeven met de VPN omhoog, maar het verkeer werkt er niet over. 

Tip: het scenario waarin het ESP-verkeer slechts in één richting is geblokkeerd, kan ook aanwezig zijn. De symptomen zijn hetzelfde, maar het kan gemakkelijk worden gevonden met de tunnelstatistieken informatie, inkapseling, decapsulation tellers, of RX- en TX-tellers.

Gerelateerde informatie

• KEv2-pakketuitwisseling en debuggen op protocolniveau
• De Internet Key Exchange (IKE) - RFC 2409
• Internet Key Exchange (IKEv2)-protocol
• Technische ondersteuning en documentatie – Cisco Systems