Virtuelle Private Nettverk Lars Kr. Hallingstad Jon Kolstad Bjørn Næss Christian A. Nøkleby Tommy Rafos Øyvind S. Aasbrenn

Dagsorden Generell intro (definisjoner og terminologi) VPN teknologier Sikkerhet Lag 2 Lag 3 VPN og mobilitet VPN i praksis - eksempel fra VPN løsningen ved NTNU

Et privat datanettverk ved bruk av offentlig infrastruktur VPN Hva? Et privat datanettverk ved bruk av offentlig infrastruktur

Senke kostnadene for private nettverk VPN Hvorfor? Senke kostnadene for private nettverk SPLEISE

Brukeren ”ser” et lokalt nettverk VPN Virtuelle Brukeren ”ser” et lokalt nettverk

Konfidensialitet og integritet av data og autentisering av brukere VPN Private Konfidensialitet og integritet av data og autentisering av brukere

Nettverk VPN Intranett VPN - Geografisk spredte noder Ekstranett VPN - Business-to-business Aksess VPN - Roadwarriors

Fjern aksess før VPN ©2001 ADTRAN, Inc. Oppringing for mobile brukere til ikke-lokal takst Oppsett av aksess server/modemparker

Fjern aksess med VPN ©2001 ADTRAN, Inc.

Intra/Ekstra nett før VPN ©2001 ADTRAN, Inc. Leide linjer – høy investering,lite efffektivt Lite fleksibel/skalerbart

VPN Full mesh - leide linjer

VPN Full mesh - leide linjer

VPN Full mesh - leide linjer (n)x(n - 1)/2 10 noder = 45 linjer

Intra-/Ekstranett med VPN ©2001 ADTRAN, Inc. Transportnettet er ”gratis” Skalerbart/Fleksibelt

VPN - Terminologi Tunnelering – Hjertet i et VPN Oppretter en punkt-til-punkt forbindelse ”Innpakking” skjuler opprinnelige avsender/mottaker adresser som ikke vil være gyldige på backbone-nettet Kryptering av data (inkludert addresser) Signaleringsprotokoller oppkobling og vedlikehold

VPN - Terminologi ©OpenReach, Inc.

VPN Lav kostnad Enkel implementasjon Skreddersøm Fleksibelt Skalerbart

Typer av VPN Tiltrodd VPN Sikker VPN Hybrid VPN Kunden stoler på at tilbyderen sørger for integritet på sambandssløyfen, og at han sikrer nettverkstrafikken mot spionering Sikker VPN Sikrer trafikken ved å kryptere dataene ved kanten av nettverket eller ved avsenderens datamaskin, en spion kan ikke lese eller endre dataene uten at mottakeren merker det Hybrid VPN Et sikkert VPN som kjøres over et tiltrodd VPN Kunden kan ha kontroll over sikkerheten eller overlate dette til en tiltrodd nettleverandør Denne inndelingen er grei å ta med seg når man går nærmere inn på teknologiene Kilde: VPN Consortium

Generelle krav til et VPN For alle Administratoren må vite omfanget av VPN’et Sikkert VPN All trafikk over et sikkert VPN må være kryptert og autentisert Sikkerhetsegenskapene må være besluttet av alle partene i VPN Ingen utenfor VPN kan påvirke sikkerhetsegenskapene til VPN Tiltrodd VPN Ingen andre enn den tiltrodde VPN tilbyderen kan påvirke opprettelsen eller endringen av stier i VPN’et Ingen andre enn den tiltrodde VPN tilbyderen kan endre, sette inn eller slette data langs stien i VPN’et Ruting og adressering må være etablert før VPN opprettes Hybrid VPN Adressegrensene for et sikkert VPN, innefor et tiltrodd VPN, må være bestemt Genrelt Administratoren må vite omfanget av VPN’et Uansett VPN type er det meningen at et VPN skal har egenskaper som et ”vanlig” nettverk ikke har. Administratoren må derfor til enhver tid vite hvilke data som tilhører VPN’et og hvilke som ikke tilhører VPN’et. Sikkert VPN All trafikk over et sikkert VPN må være kryptert og autentisert Mange av protokollene for sikkert VPN tilbyr muligheten til autentisering uten kryptering. Dette er sikrere enn et nettverk uten kryptering, men det er ikke VPN fordi det ikke er noe hemmeligholdelse av dataene Sikkerhetsegenskapene må være besluttet av alle partene i VPN Administratorene på hver side av en tunnel må ha muligheten til å bli enige om sikkerhetsegenskapene for tunnelen. Ingen utenfor VPN kan påvirke sikkerhetsegenskapene til VPN Ingen må kunne endre f.eks. slik at kravene til kryptering svekkes eller at andre nøkler enn de bestemte brukes Tiltrodd VPN Ingen andre enn den tiltrodde VPN tilbyderen kan påvirker opprettelsen eller endringen av stier i VPN’et Verdien i et tiltrodd VPN ligger i tilliten til tilbyderen. Ingen andre enn den tiltrodde VPN tilbyderen kan endre, sette inn eller slette data langs stien i VPN’et Et tiltrodd VPN er mer enn bare et sett med stier gjennom nettet. Det er også dataene som flyter gjennom det. Stiene deles typisk med flere kunder, men stien må være spesifikk for VPN’et slik at ingen andre kan påvirke dataene langs stien. En slik forandring ville endre på stiens karakteristikk, f.eks. Datamengden langs stien. Ruting og adressering må være etablert før VPN opprettes Kunden må vite hva som forventes av kunden og hva som er forventet fra tilbyderen, slik at de kan planlegge hvordan de skal holde vedlike nettverket de skal kjøpe. Hybrid VPN Adressegrensene for det sikre VPN’et innefor det tiltrodde VPN’et må være bestemt

Bare VPN eller IP VPN ? Private nettverk har generelt vært Dedikerte WAN Leide linjer eller dedikerte kretser , som FrameRelay, ATM Opprings nettverk Ved behov; forbindelse gjennom PSTN til Nettverk Aksess Tjenere Bedre og billigere tilgang til Internett har gitt økt interesse for privat kommunikasjon over Internett Først i det siste har vi fått mekanismer i IP-nettet som møter kundenes krav Existing private networks can be generally categorized into two types - dedicated WANs that permanently connect together multiple sites, and dial networks, that allow on-demand connections through the Public Switched Telephone Network (PSTN) to one or more sites in the private network. WANs are typically implemented using leased lines or dedicated circuits - for instance, Frame Relay or ATM connections - between the multiple sites. CPE routers or switches at the various sites connect these dedicated facilities together and allow for connectivity across the network. Given the cost and complexity of such dedicated facilities and the complexity of CPE device configuration, such networks are generally not fully meshed, but instead have some form of hierarchical topology. For example remote offices could be connected directly to the nearest regional office, with the regional offices connected together in some form of full or partial mesh. Private dial networks are used to allow remote users to connect into an enterprise network using PSTN or Integrated Services Digital Network (ISDN) links. Typically, this is done through the deployment of Network Access Servers (NASs) at one or more central sites. Users dial into such NASs, which interact with Authentication, Authorization, and Accounting (AAA) servers to verify the identity of the user, and the set of services that the user is authorized to receive. In recent times, as more businesses have found the need for high speed Internet connections to their private corporate networks, there has been significant interest in the deployment of CPE based VPNs running across the Internet. This has been driven typically by the ubiquity and distance insensitive pricing of current Internet services, that can result in significantly lower costs than typical dedicated or leased line services. The notion of using the Internet for private communications is not new, and many techniques, such as controlled route leaking, have been used for this purpose [3]. Only in recent times, however, have the appropriate IP mechanisms needed to meet customer requirements for VPNs all come together. These requirements include the following:

Kravene til IP VPN Skjult pakketransport Datasikkerhet Trafikken innen et VPN har ingen relasjon til trafikken i IP-nettet (multiprotokoll, adressering) Datasikkerhet Tiltrodd nettverk Ikke-tiltrodd (brannmurer, kryptering) Garantier om tjenestekvalitet Grad av tjenestekvalitet for hvert VPN eller innen et VPN Avhengig av underliggende teknologi og bruken av denne I dag: ATM virtuell krets eller MPLS blir ofte brukt for å tilby QoS nivå til det enkelte VPN Mekanismer for tunnelering 2.1.1 Opaque Packet Transport: The traffic carried within a VPN may have no relation to the traffic on the IP backbone, either because the traffic is multiprotocol, or because the customer's IP network may use IP addressing unrelated to that of the IP backbone on which the traffic is transported. In particular, the customer's IP network may use non-unique, private IP addressing [4] 2.1.2 Data Security In general customers using VPNs require some form of data security. There are different trust models applicable to the use of VPNs. One such model is where the customer does not trust the service provider to provide any form of security, and instead implements a VPN using CPE devices that implement firewall functionality and that are connected together using secure tunnels. In this case the service provider is used solely for IP packet transport. An alternative model is where the customer trusts the service provider to provide a secure managed VPN service. This is similar to the trust involved when a customer utilizes a public switched Frame Relay or ATM service, in that the customer trusts that packets will not be misdirected, injected into the network in an unauthorized manner, snooped on, modified in transit, or subjected to traffic analysis by unauthorized parties. With this model providing firewall functionality and secure packet transport services is the responsibility of the service provider. Different levels of security may be needed within the provider backbone, depending on the deployment scenario used. If the VPN traffic is contained within a single provider's IP backbone then strong security mechanisms, such as those provided by the IP Security protocol suite (IPSec) [5], may not be necessary for tunnels between backbone nodes. If the VPN traffic traverses networks or equipment owned by multiple administrations then strong security mechanisms may be appropriate. Also a strong level of security may be applied by a provider to customer traffic to address a customer perception that IP networks, and particularly the Internet, are insecure. Whether or not this perception is correct it is one that must be addressed by the VPN implementation. 2.1.3 Quality of Service Guarantees In addition to ensuring communication privacy, existing private networking techniques, building upon physical or link layer mechanisms, also offer various types of quality of service guarantees. In particular, leased and dial up lines offer both bandwidth and latency guarantees, while dedicated connection technologies like ATM and Frame Relay have extensive mechanisms for similar guarantees. As IP based VPNs become more widely deployed, there will be market demand for similar guarantees, in order to ensure end to end application transparency. While the ability of IP based VPNs to offer such guarantees will depend greatly upon the commensurate capabilities of the underlying IP backbones, a VPN framework must also address the means by which VPN systems can utilize such capabilities, as they evolve. 2.1.4 Tunneling Mechanism Together, the first two of the requirements listed above imply that VPNs must be implemented through some form of IP tunneling mechanism, where the packet formats and/or the addressing used within the VPN can be unrelated to that used to route the tunneled packets across the IP backbone. Such tunnels, depending upon their form, can provide some level of intrinsic data security, or this can also be enhanced using other mechanisms (e.g., IPSec). Furthermore, as discussed later, such tunneling mechanisms can also be mapped into evolving IP traffic management mechanisms. There are already defined a large number of IP tunneling mechanisms. Some of these are well suited to VPN applications, as discussed in section 3.0. 3.0 VPN Tunneling As noted above in section 2.1, VPNs must be implemented using some form of tunneling mechanism. This section looks at the generic requirements for such VPN tunneling mechanisms. A number of characteristics and aspects common to any link layer protocol are taken and compared with the features offered by existing tunneling protocols. This provides a basis for comparing different protocols and is also useful to highlight areas where existing tunneling protocols could benefit from extensions to better support their operation in a VPN environment. An IP tunnel connecting two VPN endpoints is a basic building block from which a variety of different VPN services can be constructed. An IP tunnel operates as an overlay across the IP backbone, and the traffic sent through the tunnel is opaque to the underlying IP backbone. In effect the IP backbone is being used as a link layer technology, and the tunnel forms a point-to-point link. A VPN device may terminate multiple IP tunnels and forward packets between these tunnels and other network interfaces in different ways. In the discussion of different types of VPNs, in later sections of this document, the primary distinguishing characteristic of these different types is the manner in which packets are forwarded between interfaces (e.g., bridged or routed). There is a direct analogy with how existing networking devices are characterized today. A two-port repeater just forwards packets between its ports, and does not examine the contents of the packet. A bridge forwards packets using Media Access Control (MAC) layer information contained in the packet, while a router forwards packets using layer 3 addressing information contained in the packet. Each of these three scenarios has a direct VPN analogue, as discussed later. Note that an IP tunnel is viewed as just another sort of link, which can be concatenated with another link, bound to a bridge forwarding table, or bound to an IP forwarding table, depending on the type of VPN. The following sections look at the requirements for a generic IP tunneling protocol that can be used as a basic building block to construct different types of VPNs. 3.1 Tunneling Protocol Requirements for VPNs There are numerous IP tunneling mechanisms, including IP/IP [6], Generic Routing Encapsulation (GRE) tunnels [7], Layer 2 Tunneling Protocol (L2TP) [8], IPSec [5], and Multiprotocol Label Switching (MPLS) [9]. Note that while some of these protocols are not often thought of as tunneling protocols, they do each allow for opaque transport of frames as packet payload across an IP network, with forwarding disjoint from the address fields of the encapsulated packets.

Generelle VPN begrep Grense mellom kunde og leverandør Utstyr på kundens flanke Grense mellom kunde og leverandør Utstyr på leverandørens flanke

Ordforklaring Utstyr på kundens flanke Utstyr på leverandørens flanke utstyr som er plassert innenfor kundens domene de fleste VPN implementasjoner er basert på utstyr av denne typen eks.: brannmurer, WAN kantrutere, spesialiserte termineringsenheter for VPN Utstyr på leverandørens flanke utstyr som er plassert i tjenesteleverandørens domene Utstyr på kanten av VPN enhet som er plassert både i VPN ryggradsnettet og kundens nettverk. Utstyret utfører VPN-spesifikke funksjoner for et nettverksbasert VPN er dette utstyr på leverandørens flanke for et kundestyrt VPN er dette utstyr på kundens flanke Utstyr på kundens flanke Grense mellom kunde og leverandør Utstyr på leverandørens flanke Most current VPN implementations are based on CPE equipment. VPN capabilities are being integrated into a wide variety of CPE devices, ranging from firewalls to WAN edge routers and specialized VPN termination devices. Such equipment may be bought and deployed by customers, or may be deployed (and often remotely managed) by service providers in an outsourcing service. There is also significant interest in 'network based VPNs', where the operation of the VPN is outsourced to an Internet Service Provider (ISP), and is implemented on network as opposed to CPE equipment. There is significant interest in such solutions both by customers seeking to reduce support costs and by ISPs seeking new revenue sources. Supporting VPNs in the network allows the use of particular mechanisms which may lead to highly efficient and cost effective VPN solutions, with common equipment and operations support amortized across large numbers of customers.

Kundestyrt VPN Nettverket vet ikke om VPN Alt. 1: Kunden skaffer VPN utstyr selv IP ruting gjøres via kundens rutere og håndteres av private nettverks administratorer Tilyders kant vet ikke noe om kundens nettverk Alt. 2:Tilbyder anskaffer og fjernstyrer kundens enheter Krever mye pass fra tjeneste leverandør installering, testing, integrasjon, vedlikehold og teknisk støtte

VPN styrt av nettleverandøren Nettverksnoder støtter en VPN tjeneste som blir aktivt styrt av nettleverandør Nettleverandør drifter VPN tjenesten Fellesutstyr og drifts støtte blir avskrevet på et stort antall kunder draft-ietf-l3vpn-vpn-vr-01.txt: This draft describes a network-based Virtual Private Network (VPN) architecture using the virtual router (VR) concept. Multiple VRs can exist in a single physical device. A VR emulates all the functionality of a physical router, and therefore inherits all existing mechanisms and tools for configuration, operation, accounting, and maintenance. Any routing protocol can be used to distribute VPN reachability information among VRs, and no VPN- related modifications or extensions are needed to the routing protocol for achieving VPN reachability. Direct VR-to-VR connectivity may be configured through layer-2 links or through IP- or MPLS-based tunnels. Traffic from VRs belonging to different VPNs may be aggregated over a "backbone VR" network, which greatly simplifies VPN provisioning. This architecture accommodates various

Sammendrag IP VPN Kilde: Kjersti Moldeklev

Sikkerhet (1) VPNer må kunne tilby følgende fire kritiske funksjoner for å ivareta sikkerheten for data. Autentisering – forsikring om at data originerer fra kilden som det hevdes. Aksess Kontroll – Å hindre uatoriserte brukere adgang til nettverket. Konfidensialitet – Å hindre noen fra å lese eller kopiere data under transport. Data Integritet – Forsikre seg om at ingen endrer data under transport.

Sikkerhet (2) VPN nettverk sørger for at informasjon forblir konfidensielt gjennom bruk av kryptering. Klar-tekst blir dermed kryptert til cipher tekst. Sendt over nettet, og dekryptert hos mottaker igjen. Brukte krypteringsmetoder er bl.a Data Encryption Standard (DES), Triple DES (3DES) og Blowfish. Siden alle disse krypteringsalgoritmene er videns kjent og godt utprøvd brukes de med kryptonøkler for å kunne produsere unike cipher tekster. Graden av sikkerhet avhenger mye av lengden på nøkkelen, og tidsintervallene, Re-Keying Intervals, mellom utskifting av nøkler. Nye nøkler kan f.eks bli brukt hver gang en VPN tunnell settes opp, og igjen automatisk regenerert etter et par timer.

Sikkerhet (3) Kryptering garanterer for sikring av innholdet under transport over internett. Autentiseringsteknologien garanterer identiteten til VPN deltakerne, samt at informasjonen som kommer frem har integritet (dvs ikke har blitt endret under veis). Den vanligste autentiseringsmåten er brukernavn og passord. Mens bruk av digitale sertifikater lar mennesker og systemer autentifisere og identifisere hverandre uten memorisering av brukernavn og passord. I VPN blir sertifikater brukt som et pass for å identifisere personen eller systemet som prøver å koble seg til VPN’et, og som et middel for distribusjon av offentlige nøkler. For å hindre forfalskning benyttes digitale signaturer. Dette er en to trinns prosess hvor en melding krypteres ved hjelp av en enveis krypto-algoritme kjent som en hash funksjon og videre ved bruk av ens private nøkkel. Digitale sertifikater tilbyr den beste formen for autentisering man har i dag.

Sikkerhet (4) Kryptering, nøkler, sertifikater og digitale signaturer er alle sikkerhets mekanismer som tilbyr ”P”en i VPN. Men fordi man bl.a ønsker å sende informasjon mellom private adresser benyttes en mekanisme kalt tunnellering.

VPN lag 2 tjenester Forwarding basert på innkommende link og lag 2 informasjon i ramme header PPP, FR/ATM, ethernet Integrert med eksisterende aksess teknologier

Lag 2 typer Virtuelle leide linjer (VLL) Virtuelle private LAN segmenter (VPLS) Virtuelle private oppringte nett (VPDN)

Lag 2 Virtuelle leide linjer Kunden benytter point-to-point linker ATM Frame relay Lag 2 rammer pakkes inn i en IP tunnel Kunden ser lag-2 CPE utstyr Virtuell tunnel må kanskje benytte sekvensering

Lag 2 Virtuelle private LAN segmenter Emulering av LAN segmenter ved hjelp av Internet fasiliteter - Transparent LAN tjeneste ved CPE sammenkoblinger - Benytter broadcast, som for eksempel ARP Protokoll transparent - VPLS ende nodene implementerer link lag bridging (ikke routing)

Lag 2 Virtuelle private oppringte nett Tillater brukere å koble seg opp via en ad-hoc tunnel til et annet nett ved hjelp av Oppringt (Dial-up, PSTN eller ISDN) PPP (point-to-point protocol) L2TP Bruker autentisering Brukeren tildeles en IP adresse fra bedriftens nett

Lag 2 Virtuelle private oppringte nett

Tunneling PPP over IP L2TP Er en kontrollprotokoll for å sette opp, vedlikeholde og ta ned flere lag 2-tunneller mellom to logiske endepunkter. PPP endepunkter kan finnes på ulike enheter som er koblet sammen av et pakkesvitsjet nett. Pakker kan leveres i sekvens PPP definerer en innkapslingsmekanisme for å transportere multiprotokoll-pakker over punkt til punkt forbindelser på lag 2 En innkapslingsmetode for å tunnelere PPP rammer mellom endepunkter. Dette inkluderer mulitpleksing av flere PPP strømmer.

Lag 3 Teknologier IP/IP IPsec Spesifisert ruting Transport mode Tunneling mode Spesifisert ruting MPLS (Ligger mellom lag 2 og lag 3)

IP/IP Innkapsulerer en ip-pakke i en annen Kan brukes til å knytte to private ip-nett sammen IP over IP er en tunnellerings måte som krever at IP pakker er kryptert, og så innkapsulert i ny ip-pakke

IPsec “Transport Mode” “Tunneling Mode” To modi: Encapsulated Security Payload (ESP) Krypterer kun informasjonsfeltet i pakken. Dette kan dekrypteres hos “gateway” eller hos bruker Fordeler: Hindrer at noen leser informasjonen. “Tunneling Mode” Authentication Header (AH ) og (ESP) Krypterer hele pakken, og setter på en ekstra ip-header som er adressert til “gateway” på mottakende side. Denne har en checksum som mottakeren kan kontrollere ved mottak Fordeler: Skjuler avsender og mottakers identiet Skjuler informasjonen (Konfidensialietet) Hindrer endring (Integritet) Hindrer spoofing (autentifikasjon) Ulemper: Mer overhead og prosessering

IPsec – Transport Mode Internet Plaintext: Encrypted: Payload Header

IPsec – Tunneling Mode Internet Plaintext: Encrypted: Payload Header Hdr1 Hdr2 Internet Plaintext: Encrypted: Payload Header

Spesifiert Ruting Muliggjør en form for VPN Brukere kan på denne måten bruke betrodde nett og rutere Tiltrodd Tilbyder

Spesifisert ruting IPv4 To typer: Loose Source Routing Strict Source Routing Settes i “options”-feltet i header på IP-pakken. Konstant lengde gjennom alle noder. Pointer inkrementeres med fire, og kilderute erstattes med faktisk rute +--------+--------+--------+---------//--------+ |10000011| length | pointer| route data | Type=131 /137

Spesifisert Ruting i IPv6 1 Version 2 Traffic Class 3 Flowlabel 4 Payload Length 5 Next Header 6 Hop Limit 7 Source Address 8 Destination Address 1 2 3 4 5 6 7 8 IPv6 Header 1 Next Header 2 Hdr Ext Length 3 Routing Type = 0 4 Segments left 5 Reserved 6 Address[1] 7 Address[2] 8 Address[n] 1 2 3 4 5 6 7 8 Routing Hdr

MPLS – Multi Protocol Label Switching Videresending og kontroll Eksplisitt ruting Er en skalerbar støtte for VPN Støtter forskjellige QoS klasser FEC – Forwarding Equivalence Class Settes kun når pakken kommer inn i nettet

VPN og Mobilitet VPN tilbyr ikke mobilitet direkte Dagens løsninger er lite fleksible Terminalmobilitet VPN tilbyr mobilitet på diskret form Underliggende teknologier legger føringer for hvilke typer mobilitet som er oppnåelig Oppgradering til kontinuerlig terminalmobilitet

VPN i praksis (1) Implementert ved NTNU gjennom Du trenger Cisco VPN Klient Movade Du trenger Gruppeinformasjon Dette er informasjon som identifiserer IPSec-gruppen du er fordelt til. Avhengig av gruppetilhørighet styres oppsett av feks aksessretter, autentiseringsmetode og IPSec-algoritmer som skal brukes. Dette er brukernavn:alle passord:passord Bruker på stud

VPN i praksis (2) Oppsett av tunnelen Tunnelen kan settes opp på to måter IPSec over UDP Bedre egenskaper ved NAT IPSec over TCP Bedre egenskaper ved tilstandsbaserte brannmurer IPSec settes opp basert på gruppeinformasjon Benytter Internet Security Association and Key Management Protocol, ISAKMP Rammeverk for autentisering og nøkkelutveksling uavhengig av de respektives typer

ISAKMP (1) ISAKMP har definert 2 forskjellige faser Fase 1 Oppsett av ISAKMP SA, sikker, autentisert kanal. Benyttes videre i fase2 Fase 2 Protokoll SA, selve tunnelen IPSec eller annen tjeneste som trenger forhandling av nøkkel(-materiale) eller andre parametre.

ISAKMP (2) Anti-Clogging (Denial of Service) Bruk av cookie for hver SA Initiator Cookie / Responder Cookie Keep-alive funksjon for opprettholdelse av forbindelse Informational Exchange sendes fra klient hvert 20. sek. Exchange Types used Fase 1 Agressive Informational Fase 2 Transaction (Config Mode) Quick Mode

ISAKMP (3) Agressive Informational Utveksling av relevant sikkerhetsinfo for fase 1. Nøkkelutveksling og autentisering. Ingen Message ID, Ingen god sikkerhet, kun temporær kanal Informational Utveksling av kontrollmeldinger og feilmeldinger, feks lastdeling og videresending

ISAKMP (4) Transaction (Config Mode) Quick Mode Utveksling av informasjon for leverandør spesifikt oppsett Quick Mode Utveksling av informasjon og sluttføring av fase 2, bytte til Protokoll SA

ISAKMP Header 7 15 23 31 INITIATOR COOKIE RESPONDER COOKIE NEXT PAYLOAD VERSION EXCHANGE TYPE FLAGS MESSAGE ID LENGTH

ISAKMP Aggressive Mode

Spørsmål?

Referanser ISAKMP IKE Internet Key Exchange (IKEv2) Protocol http://www.ietf.org/rfc/rfc2408.txt IKE http://www.faqs.org/rfcs/rfc2409.html Internet Key Exchange (IKEv2) Protocol http://www.securitytechnet.com/resource/ietf/wg-draft/draft-ietf-ipsec-ikev2-03.txt Proposed Configuration payload for IKEv2 http://www.vpnc.org/ietf-mode-cfg/mail-archive/msg00016.html Virtual Private Networks, Coping with Complexity. Andreas Steffen http://security.zhwin.ch/DFN_VPN.pdf

http://www.iec.org/online/tutorials/vpn http://www.vpnc.org/vpn-technologies.html IEFT, IPv6 Spesification: ftp://ftp.rfc-editor.org/in-notes/rfc2460.txt