IPsec

Ten artykuł należy dopracować: od 2012-10 → zweryfikować treść i dodać przypisy, → usunąć/zweryfikować prawdopodobną twórczość własną. Dokładniejsze informacje o tym, co należy poprawić, być może znajdują się w dyskusji tego artykułu. Po wyeliminowaniu niedoskonałości należy usunąć szablon {{Dopracować}} z tego artykułu.

IPsec (ang. Internet Protocol Security, IP Security) – zbiór protokołów służących implementacji bezpiecznych połączeń oraz wymiany kluczy szyfrowania pomiędzy komputerami. Protokoły tej grupy mogą być wykorzystywane do tworzenia Wirtualnej Sieci Prywatnej (ang. VPN).

VPN oparta na IPsec składa się z dwóch kanałów komunikacyjnych pomiędzy połączonymi komputerami: kanał wymiany kluczy, za pośrednictwem którego przekazywane są dane związane z uwierzytelnianiem i szyfrowaniem (klucze), oraz kanału (jednego lub więcej), który niesie pakiety transmitowane poprzez sieć prywatną. Kanał wymiany kluczy jest standardowym protokołem UDP (port 500). Kanały przesyłu danych oparte są na protokole ESP (protokół IP numer 50) opisanym w dokumencie RFC 2406 ↓^[1].

Architektura IPsec

Protokoły wchodzące w skład architektury IPsec służą do bezpiecznego przesyłania przez sieć pakietów IP. Działają one na zasadzie kapsułkowania, tj. oryginalny (zabezpieczany) pakiet IP jest szyfrowany, otrzymuje nowy nagłówek protokołu IPsec i w takiej formie jest przesyłany przez sieć.

Bezpieczeństwo zapewniane przez IPsec może być dwojakie, w zależności od stosowanego protokołu. I tak: pojawia się problem dystrybucji kluczy symetrycznych. Narzuca się zastosowanie kryptografii asymetrycznej, ale jest ona o wiele wolniejsza od szybkich szyfrów symetrycznych i dodanie ich do protokołów niskiego poziomu, jakimi są ESP i AH (Authentication Header), miałoby znaczący wpływ na wydajność. Te dwa protokoły pozostały więc relatywnie prostymi protokołami niskiego poziomu, a do skomplikowanych zadań dystrybucji klucza i uwierzytelniania stron stworzono oddzielny protokół IKE.

Protokół IKE

Protokół IKE (Internet Key Exchange) został zaprojektowany w większości przez NSA (National Security Agency) i jest skomplikowany, głównie ze względu na poziom abstrakcji, na jakim operuje. Wystarczy bowiem włożyć do niego własny zestaw algorytmów kryptograficznych, czy wręcz własną arytmetykę (zestaw ten określa się jako DOI, Domain of Interpretation) by otrzymać zupełnie inny od cywilnego protokół, na przykład na potrzeby wojska.

IKE funkcjonalnie składa się z dwóch części: specyfikacji metod kryptograficznych uwierzytelnienia i negocjacji kluczy Oakley (IKE: RFC 2409 ↓, IKEv1: RFC 4109 ↓, IKEv2: RFC 4306 ↓) oraz specyfikacji formatów pakietów i stanów protokołu ISAKMP. W praktyce nazwy ISAKMP używa się zamiennie z IKE.

Podstawowymi celami IKE są poniższe kroki, wykonywane kolejno:

• uwierzytelnienie obu stron komunikacji wobec siebie za pomocą jednej z poniższych metod (ustalanych przez administratora):
  • hasło znane obu stronom (shared secret)
  • podpisy RSA (konieczna ręczna wymiana kluczy publicznych stron)
  • certyfikaty X.509 (najbardziej uniwersalna)
• nawiązanie bezpiecznego kanału dla potrzeb IKE nazywanego ISAKMP SA (Security Association)
• bezpieczne uzgodnienie kluczy kryptograficznych oraz parametrów tuneli IPsec
• ewentualna ich renegocjacja co określony czas

Po nawiązaniu połączenia przez IKE obie strony mogą już stworzyć właściwe tunele IPsec (ESP lub AH) i rozpocząć komunikację. Jeśli wymagane jest, by klucze kryptograficzne były regularnie (np. co 8 godzin) zmieniane, IKE również to umożliwia.

Praktyczną konsekwencją stosowania IKE jest to, że zamiast ręcznie konfigurować klucze (i wiele innych parametrów) na obu stronach połączenia administrator może w najprostszym przypadku skonfigurować na nich tylko hasło shared secret, by w pełni automatycznie uzyskać tunele IPsec.

Szczegóły IPsec

Istotną cechą ESP i AH jest mała ilość informacji, jakie potencjalny atakujący otrzymuje w wyniku podsłuchiwania szyfrowanej komunikacji. Po włączeniu sniffera zobaczy on tylko zaszyfrowany pakiet opatrzony dwiema liczbami:

• SPI (Security Parameters Index)
• numer sekwencyjny

Wartość SPI jest stała, najczęściej jest generowana losowo i ma kluczowe znaczenie dla stron połączenia, a żadnego dla atakującego. Strony połączenia bowiem na podstawie SPI rozpoznają do jakiej sesji (tunelu) IPsec przynależy dany pakiet i jakie w związku z tym zastosować szyfry oraz klucze do jego rozszyfrowania.

Przykładowo, SPI 0x123456 może oznaczać że dany pakiet należy do kanału IPsec łączącego sieci B i C, szyfrowanego 3DES z kluczem X. Inne SPI mogłoby oznaczać kanał między D i E, szyfrowany AES z kluczem Y. Numer SPI jest ustalany przez strony podczas tworzenia kanału i jest stały podczas jego istnienia.

Numer sekwencyjny jest losowany i zwiększany o 1 z każdym wysłanym przez dany kanał pakietem i służy do rozpoznawania pakietów o kolejności przestawionej podczas wędrówki po sieci oraz chroni przed atakami przez powtórzenie (replay attacks). Ponieważ numer ten jest wartością 32-bitową, po 2^32 wysłanych pakietów kanał musi być zamknięty, a w jego miejsce stworzony nowy, z licznikiem startującym od nowej wylosowanej liczby.

Jednokierunkowość

Kolejną istotną cechą kanałów IPsec jest ich jednokierunkowość – dany kanał obsługuje tylko ruch idący z hosta A do B. Każda pełna łączność wykorzystuje dwa kanały – jeden od A do B, drugi od B do A. Każdy z nich ma inne SPI, osobny licznik sekwencyjny, inne klucze kryptograficzne.

Taki jednokierunkowy kanał IPsec (ESP lub AH) jest określany nazwą Security Association (która nie ma dobrego polskiego tłumaczenia, stąd w artykule używane jest określenie „kanał”). Każde SA charakteryzuje się przez adresy IP początku i końca oraz SPI.

Klucze kryptograficzne

Do pełnej łączności między dwoma hostami potrzebne są dwa kanały IPsec. Jeśli wykorzystany zostanie protokół ESP, to każdy kanał będzie wymagał dwóch kluczy kryptograficznych – jednego do szyfrowania danych, drugiego do ochrony integralności i uwierzytelnienia. Jeśli będzie to AH, to odpadnie pierwszy klucz (szyfrujący). W najbardziej złożonym przypadku ESP do pełnej komunikacji będą potrzebne cztery klucze:

• szyfrujący dla kanału relacji A do B
• uwierzytelniający dla kanału relacji A do B
• szyfrujący dla kanału relacji B do A
• uwierzytelniający dla kanału relacji B do A

Jest to kolejny powód, dla którego ręczna konfiguracja kanałów IPsec jest uciążliwa – w przypadku stosowania IKE wszystkie klucze uzgadniane są automatycznie.

Tryb transportowy i tunelowy

Nagłówek IPsec – ESP można stosować w dwóch trybach: transportowym lub tunelowym. Typowy pakiet IP wygląda następująco (zakładając, że protokołem wyższej warstwy będzie TCP):

+----+-----+--------------------
| IP | TCP | dane użytkownika...
+----+-----+--------------------

Tryb transportowy polega na tym, że pomiędzy nagłówek IP a TCP dokładamy jeszcze dodatkowo nagłówek IPsec (załóżmy że jest to ESP). Część oznaczona podwójną linią jest zaszyfrowana i całkowicie nieprzezroczysta dla ewentualnego podsłuchującego. Podlega ona także ochronie integralności.

+----+-----+==========================
| IP | ESP | TCP | dane użytkownika...
+----+-----+==========================

Jak widać, w trybie transportowym niewidoczne są dane użytkownika, ale nagłówek IP pozostaje widoczny. Atakujący nie wie zatem, o czym się rozmawia, ale wie za to, kto z kim tę konwersację prowadzi.

Tryb tunelowy zapewnia wyższy poziom ochrony – pakiet użytkownika jest w całości enkapsulowany w ESP, a na początek jest dokładany zupełnie nowy nagłówek IPn:

+-----+-----+===============================
| IPn | ESP | IP | TCP | dane użytkownika...
+-----+-----+===============================

Jeśli stacja A i B będą się łączyły bezpośrednio za pomocą trybu tunelowego to nagłówek IPn będzie praktycznie identyczny jak oryginalny IP i całość będzie praktycznie równa trybowi transportowemu. Ale dzięki trybowi tunelowemu jest możliwe tworzenie wirtualnych sieci prywatnych (VPN), które stanowią główne zastosowanie IPsec.

Kluczową cechą VPN jest możliwość stworzenia szyfrowanego tunelu pomiędzy dwiema bramkami (B) łączącymi dwie części sieci korporacyjnej przez sieć publiczną:

10.1.1.0/24 ----- B1 ========= B2 ------ 10.2.2.0/24

Atakujący widzi wówczas wyłącznie zaszyfrowane pakiety przesyłane pomiędzy B1 i B2. Oryginalne pakiety są ukryte w tunelu i podsłuchującemu nie jest znana ani ich treść, ani nawet zastosowana w sieci korporacyjnej adresacja.

Zaletą stosowania trybu tunelowego jest niewielki narzut wielkości pakietu (mniej niż 2% przy MTU 1500 bajtów) wynikający z konieczności dodawania drugiego nagłówka IP. Wadą trybu transportowego jest niemożność tunelowania w nim pakietów dla innych sieci.

IPSec NAT Traversal

W przypadku protokołu AH nie jest możliwa zamiana adresu źródłowego w nagłówku pakietu IP, gdyż cały nagłówek zabezpieczony jest przed zmianą. Do nagłówka dodawany jest skrót kryptograficzny powstały z sumy kontrolnej pakietu oraz tajnego hasła. Jakakolwiek modyfikacja pakietu uznana będzie przez drugą stronę za naruszenie integralności danych. Dla protokołu AH nie jest możliwa translacja adresów.

W przypadku protokołu ESP sprawa wygląda lepiej, ponieważ ochronie integralności nie podlega zewnętrzny nagłówek IP, dlatego możliwa jest zamiana źródłowego adresu IP. Jednak gdy istnieje wielu klientów znajdujących się za tym samym routerem (maskaradą), wtedy pojawia się problem, ponieważ protokół ten nie wykorzystuje portów, tak jak to ma miejsce w przypadku protokołów TCP i UDP, dlatego nie można w prosty sposób odróżnić połączeń IPSec inicjowanych z różnych hostów wewnątrz sieci. Rozwiązaniem problemu jest tzw. NAT Traversal.

NAT Traversal polega na kapsułkowaniu pakietów IP na protokół UDP ze standardowym nagłówkiem UDP który już umożliwia translację NAT poprzez routery i transmisję ramek pomiędzy węzłami sieci. Stąd nazwa NAT-Trawersowanie.

Dokumentacja IETF

Standardowe RFC

• RFC 1829 ↓: The ESP DES-CBC Transform
• RFC 2403 ↓: The Use of HMAC-MD5-96 within ESP and AH
• RFC 2404 ↓: The Use of HMAC-SHA-1-96 within ESP and AH
• RFC 2405 ↓: The ESP DES-CBC Cipher Algorithm With Explicit IV
• RFC 2410 ↓: The NULL Encryption Algorithm and Its Use With IPsec
• RFC 2451 ↓: The ESP CBC-Mode Cipher Algorithms
• RFC 2857 ↓: The Use of HMAC-RIPEMD-160-96 within ESP and AH
• RFC 3526 ↓: More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)
• RFC 3602 ↓: The AES-CBC Cipher Algorithm and Its Use with IPsec
• RFC 3686 ↓: Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)
• RFC 3947 ↓: Negotiation of NAT-Traversal in the IKE
• RFC 3948 ↓: UDP Encapsulation of IPsec ESP Packets
• RFC 4106 ↓: The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
• RFC 4301 ↓: Security Architecture for the Internet Protocol
• RFC 4302 ↓: IP Authentication Header
• RFC 4303 ↓: IP Encapsulating Security Payload
• RFC 4304 ↓: Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)
• RFC 4307 ↓: Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)
• RFC 4308 ↓: Cryptographic Suites for IPsec
• RFC 4309 ↓: Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)
• RFC 4543 ↓: The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH
• RFC 4555 ↓: IKEv2 Mobility and Multihoming Protocol (MOBIKE)
• RFC 4806 ↓: Online Certificate Status Protocol (OCSP) Extensions to IKEv2
• RFC 4868 ↓: Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec
• RFC 4945 ↓: The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX
• RFC 5282 ↓: Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol
• RFC 5386 ↓: Better-Than-Nothing Security: An Unauthenticated Mode of IPsec
• RFC 5529 ↓: Modes of Operation for Camellia for Use with IPsec
• RFC 5685 ↓: Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)
• RFC 5723 ↓: Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption
• RFC 5857 ↓: IKEv2 Extensions to Support Robust Header Compression over IPsec
• RFC 5858 ↓: IPsec Extensions to Support Robust Header Compression over IPsec
• RFC 7296 ↓: Internet Key Exchange Protocol Version 2 (IKEv2)
• RFC 7321 ↓: Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)
• RFC 7383 ↓: Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation
• RFC 7427 ↓: Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)
• RFC 7634 ↓: ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec

Eksperymentalne RFC

• RFC 4478 ↓: Repeated Authentication in Internet Key Exchange (IKEv2) Protocol

Informacyjne RFC

• RFC 2367 ↓: PF_KEY Interface
• RFC 2412 ↓: The OAKLEY Key Determination Protocol
• RFC 3706 ↓: A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers
• RFC 3715 ↓: IPsec-Network Address Translation (NAT) Compatibility Requirements
• RFC 4621 ↓: Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol
• RFC 4809 ↓: Requirements for an IPsec Certificate Management Profile
• RFC 5387 ↓: Problem and Applicability Statement for Better-Than-Nothing Security (BTNS)
• RFC 5856 ↓: Integration of Robust Header Compression over IPsec Security Associations
• RFC 5930 ↓: Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol
• RFC 6027 ↓: IPsec Cluster Problem Statement
• RFC 6071 ↓: IPsec and IKE Document Roadmap
• RFC 6379 ↓: Suite B Cryptographic Suites for IPsec
• RFC 6380 ↓: Suite B Profile for Internet Protocol Security (IPsec)
• RFC 6467 ↓: Secure Password Framework for Internet Key Exchange Version 2 (IKEv2)

RFC zawierające specyfikację

• RFC 5406 ↓: Guidelines for Specifying the Use of IPsec Version 2

Przestarzałe/Historyczne RFC

• RFC 1825 ↓: Security Architecture for the Internet Protocol (zastąpiony przez RFC 2401 ↓)
• RFC 1826 ↓: IP Authentication Header (zastąpiony przez RFC 2402 ↓)
• RFC 1827 ↓: IP Encapsulating Security Payload (ESP) (zastąpiony przez RFC 2406 ↓)
• RFC 1828 ↓: IP Authentication using Keyed MD5 (historic)
• RFC 2401 ↓: Security Architecture for the Internet Protocol (IPsec overview) (zastąpiony przez RFC 4301 ↓)
• RFC 2406 ↓: IP Encapsulating Security Payload (ESP) (zastąpiony przez RFC 4303 ↓ i RFC 4305 ↓)
• RFC 2407 ↓: The Internet IP Security Domain of Interpretation for ISAKMP (zastąpiony przez RFC 4306 ↓)
• RFC 2409 ↓: The Internet Key Exchange (zastąpiony przez RFC 4306 ↓)
• RFC 4305 ↓: Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) (zastąpiony przez RFC 4835 ↓)
• RFC 4306 ↓: Internet Key Exchange (IKEv2) Protocol (zastąpiony przez RFC 5996 ↓)
• RFC 4718 ↓: IKEv2 Clarifications and Implementation Guidelines (zastąpiony przez RFC 7296 ↓)
• RFC 4835 ↓: Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) (zastąpiony przez RFC 7321 ↓)
• RFC 5996 ↓: Internet Key Exchange Protocol Version 2 (IKEv2) (zastąpiony przez RFC 7296 ↓)

Zobacz też

• ESP
• AH

Przypisy

Linki zewnętrzne

• Mechanizmy kryptograficzne w protokołach ISAKMP i IKE
• Struktura i historia protokołu IPSec
• R.R. Atkinson R.R., Security Architecture for the Internet Protocol, RFC 1825, IETF, sierpień 1995, DOI: 10.17487/RFC1825, ISSN 2070-1721, OCLC 943595667  (ang.).
• R.R. Atkinson R.R., IP Authentication Header, RFC 1826, IETF, sierpień 1995, DOI: 10.17487/RFC1826, ISSN 2070-1721, OCLC 943595667  (ang.).
• R.R. Atkinson R.R., IP Encapsulating Security Payload (ESP), RFC 1827, IETF, sierpień 1995, DOI: 10.17487/RFC1827, ISSN 2070-1721, OCLC 943595667  (ang.).
• P.P. Metzger P.P., W.W. Simpson W.W., IP Authentication using Keyed MD5, RFC 1828, IETF, sierpień 1995, DOI: 10.17487/RFC1828, ISSN 2070-1721, OCLC 943595667  (ang.).
• P.P. Karn P.P., P.P. Metzger P.P., W.W. Simpson W.W., The ESP DES-CBC Transform, RFC 1829, IETF, sierpień 1995, DOI: 10.17487/RFC1829, ISSN 2070-1721, OCLC 943595667  (ang.).
• D.D. McDonald D.D., C.C. Metz C.C., B.B. Phan B.B., PF_KEY Key Management API, Version 2, RFC 2367, IETF, lipiec 1998, DOI: 10.17487/RFC2367, ISSN 2070-1721, OCLC 943595667  (ang.).
• S.S. Kent S.S., R.R. Atkinson R.R., Security Architecture for the Internet Protocol, RFC 2401, IETF, listopad 1998, DOI: 10.17487/RFC2401, ISSN 2070-1721, OCLC 943595667  (ang.).
• S.S. Kent S.S., R.R. Atkinson R.R., IP Authentication Header, RFC 2402, IETF, listopad 1998, DOI: 10.17487/RFC2402, ISSN 2070-1721, OCLC 943595667  (ang.).
• C.C. Madson C.C., R.R. Glenn R.R., The Use of HMAC-MD5-96 within ESP and AH, RFC 2403, IETF, listopad 1998, DOI: 10.17487/RFC2403, ISSN 2070-1721, OCLC 943595667  (ang.).
• C.C. Madson C.C., R.R. Glenn R.R., The Use of HMAC-SHA-1-96 within ESP and AH, RFC 2404, IETF, listopad 1998, DOI: 10.17487/RFC2404, ISSN 2070-1721, OCLC 943595667  (ang.).
• C.C. Madson C.C., N.N. Doraswamy N.N., The ESP DES-CBC Cipher Algorithm With Explicit IV, RFC 2405, IETF, listopad 1998, DOI: 10.17487/RFC2405, ISSN 2070-1721, OCLC 943595667  (ang.).
• S.S. Kent S.S., R.R. Atkinson R.R., IP Encapsulating Security Payload (ESP), RFC 2406, IETF, listopad 1998, DOI: 10.17487/RFC2406, ISSN 2070-1721, OCLC 943595667  (ang.).
• D.D. Piper D.D., The Internet IP Security Domain of Interpretation for ISAKMP, RFC 2407, IETF, listopad 1998, DOI: 10.17487/RFC2407, ISSN 2070-1721, OCLC 943595667  (ang.).
• D.D. Harkins D.D., D.D. Carrel D.D., The Internet Key Exchange (IKE), RFC 2409, IETF, listopad 1998, DOI: 10.17487/RFC2409, ISSN 2070-1721, OCLC 943595667  (ang.).
• R.R. Glenn R.R., S.S. Kent S.S., The NULL Encryption Algorithm and Its Use With IPsec, RFC 2410, IETF, listopad 1998, DOI: 10.17487/RFC2410, ISSN 2070-1721, OCLC 943595667  (ang.).
• H.H. Orman H.H., The OAKLEY Key Determination Protocol, RFC 2412, IETF, listopad 1998, DOI: 10.17487/RFC2412, ISSN 2070-1721, OCLC 943595667  (ang.).
• R.R. Pereira R.R., R.R. Adams R.R., The ESP CBC-Mode Cipher Algorithms, RFC 2451, IETF, listopad 1998, DOI: 10.17487/RFC2451, ISSN 2070-1721, OCLC 943595667  (ang.).
• A.A. Keromytis A.A., N.N. Provos N.N., The Use of HMAC-RIPEMD-160-96 within ESP and AH, RFC 2857, IETF, czerwiec 2000, DOI: 10.17487/RFC2857, ISSN 2070-1721, OCLC 943595667  (ang.).
• T.T. Kivinen T.T., M.M. Kojo M.M., More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE), RFC 3526, IETF, maj 2003, DOI: 10.17487/RFC3526, ISSN 2070-1721, OCLC 943595667  (ang.).
• S.S. Frankel S.S., R.R. Glenn R.R., S.S. Kelly S.S., The AES-CBC Cipher Algorithm and Its Use with IPsec, RFC 3602, IETF, wrzesień 2003, DOI: 10.17487/RFC3602, ISSN 2070-1721, OCLC 943595667  (ang.).
• R.R. Housley R.R., Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP), RFC 3686, IETF, styczeń 2004, DOI: 10.17487/RFC3686, ISSN 2070-1721, OCLC 943595667  (ang.).
• G.G. Huang G.G., S.S. Beaulieu S.S., D.D. Rochefort D.D., A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers, RFC 3706, IETF, luty 2004, DOI: 10.17487/RFC3706, ISSN 2070-1721, OCLC 943595667  (ang.).
• B.B. Aboba B.B., W.W. Dixon W.W., IPsec-Network Address Translation (NAT) Compatibility Requirements, RFC 3715, IETF, marzec 2004, DOI: 10.17487/RFC3715, ISSN 2070-1721, OCLC 943595667  (ang.).
• T.T. Kivinen T.T. i inni, Negotiation of NAT-Traversal in the IKE, RFC 3947, IETF, styczeń 2005, DOI: 10.17487/RFC3947, ISSN 2070-1721, OCLC 943595667  (ang.).
• A.A. Huttunen A.A. i inni, UDP Encapsulation of IPsec ESP Packets, RFC 3948, IETF, styczeń 2005, DOI: 10.17487/RFC3948, ISSN 2070-1721, OCLC 943595667  (ang.).
• J.J. Viega J.J., D.D. McGrew D.D., The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP), RFC 4106, IETF, czerwiec 2005, DOI: 10.17487/RFC4106, ISSN 2070-1721, OCLC 943595667  (ang.).
• P.P. Hoffman P.P., Algorithms for Internet Key Exchange version 1 (IKEv1), RFC 4109, IETF, maj 2005, DOI: 10.17487/RFC4109, ISSN 2070-1721, OCLC 943595667  (ang.).
• S.S. Kent S.S., K.K. Seo K.K., Security Architecture for the Internet Protocol, RFC 4301, IETF, grudzień 2005, DOI: 10.17487/RFC4301, ISSN 2070-1721, OCLC 943595667  (ang.).
• S.S. Kent S.S., IP Authentication Header, RFC 4302, IETF, grudzień 2005, DOI: 10.17487/RFC4302, ISSN 2070-1721, OCLC 943595667  (ang.).
• S.S. Kent S.S., IP Encapsulating Security Payload (ESP), RFC 4303, IETF, grudzień 2005, DOI: 10.17487/RFC4303, ISSN 2070-1721, OCLC 943595667  (ang.).
• S.S. Kent S.S., Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP), RFC 4304, IETF, grudzień 2005, DOI: 10.17487/RFC4304, ISSN 2070-1721, OCLC 943595667  (ang.).
• D. Eastlake 3rd, Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH), RFC 4305, IETF, grudzień 2005, DOI: 10.17487/RFC4305, ISSN 2070-1721, OCLC 943595667  (ang.).
• C.C. Kaufman C.C., Internet Key Exchange (IKEv2) Protocol, RFC 4306, IETF, grudzień 2005, DOI: 10.17487/RFC4306, ISSN 2070-1721, OCLC 943595667  (ang.).
• J.J. Schiller J.J., Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2), RFC 4307, IETF, grudzień 2005, DOI: 10.17487/RFC4307, ISSN 2070-1721, OCLC 943595667  (ang.).
• P.P. Hoffman P.P., Cryptographic Suites for IPsec, RFC 4308, IETF, grudzień 2005, DOI: 10.17487/RFC4308, ISSN 2070-1721, OCLC 943595667  (ang.).
• R.R. Housley R.R., Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP), RFC 4309, IETF, grudzień 2005, DOI: 10.17487/RFC4309, ISSN 2070-1721, OCLC 943595667  (ang.).
• Y.Y. Nir Y.Y., Repeated Authentication in Internet Key Exchange (IKEv2) Protocol, RFC 4478, IETF, kwiecień 2006, DOI: 10.17487/RFC4478, ISSN 2070-1721, OCLC 943595667  (ang.).
• D.D. McGrew D.D., J.J. Viega J.J., The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH, RFC 4543, IETF, maj 2006, DOI: 10.17487/RFC4543, ISSN 2070-1721, OCLC 943595667  (ang.).
• P.P. Eronen P.P., IKEv2 Mobility and Multihoming Protocol (MOBIKE), RFC 4555, IETF, czerwiec 2006, DOI: 10.17487/RFC4555, ISSN 2070-1721, OCLC 943595667  (ang.).
• T.T. Kivinen T.T., H.H. Tschofenig H.H., Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol, RFC 4621, IETF, sierpień 2006, DOI: 10.17487/RFC4621, ISSN 2070-1721, OCLC 943595667  (ang.).
• P.P. Eronen P.P., P.P. Hoffman P.P., IKEv2 Clarifications and Implementation Guidelines, RFC 4718, IETF, październik 2006, DOI: 10.17487/RFC4718, ISSN 2070-1721, OCLC 943595667  (ang.).
• M.M. Myers M.M., H.H. Tschofenig H.H., Online Certificate Status Protocol (OCSP) Extensions to IKEv2, RFC 4806, IETF, luty 2007, DOI: 10.17487/RFC4806, ISSN 2070-1721, OCLC 943595667  (ang.).
• C.C. Bonatti C.C., S.S. Turner S.S., G.G. Lebovitz G.G., Requirements for an IPsec Certificate Management Profile, RFC 4809, IETF, luty 2007, DOI: 10.17487/RFC4809, ISSN 2070-1721, OCLC 943595667  (ang.).
• V.V. Manral V.V., Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH), RFC 4835, IETF, kwiecień 2007, DOI: 10.17487/RFC4835, ISSN 2070-1721, OCLC 943595667  (ang.).
• S.S. Kelly S.S., S.S. Frankel S.S., Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec, RFC 4868, IETF, maj 2007, DOI: 10.17487/RFC4868, ISSN 2070-1721, OCLC 943595667  (ang.).
• B.B. Korver B.B., The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX, RFC 4945, IETF, sierpień 2007, DOI: 10.17487/RFC4945, ISSN 2070-1721, OCLC 943595667  (ang.).
• D.D. Black D.D., D.D. McGrew D.D., Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol, RFC 5282, IETF, sierpień 2008, DOI: 10.17487/RFC5282, ISSN 2070-1721, OCLC 943595667  (ang.).
• N.N. Williams N.N., M.M. Richardson M.M., Better-Than-Nothing Security: An Unauthenticated Mode of IPsec, RFC 5386, IETF, listopad 2008, DOI: 10.17487/RFC5386, ISSN 2070-1721, OCLC 943595667  (ang.).
• J.J. Touch J.J., D.D. Black D.D., Y.Y. Wang Y.Y., Problem and Applicability Statement for Better-Than-Nothing Security (BTNS), RFC 5387, IETF, listopad 2008, DOI: 10.17487/RFC5387, ISSN 2070-1721, OCLC 943595667  (ang.).
• S.S. Bellovin S.S., Guidelines for Specifying the Use of IPsec Version 2, BCP 146, RFC 5406, IETF, luty 2009, DOI: 10.17487/RFC5406, ISSN 2070-1721, OCLC 943595667  (ang.).
• A.A. Kato A.A., M.M. Kanda M.M., S.S. Kanno S.S., Modes of Operation for Camellia for Use with IPsec, RFC 5529, IETF, kwiecień 2009, DOI: 10.17487/RFC5529, ISSN 2070-1721, OCLC 943595667  (ang.).
• V.V. Devarapalli V.V., K.K. Weniger K.K., Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2), RFC 5685, IETF, listopad 2009, DOI: 10.17487/RFC5685, ISSN 2070-1721, OCLC 943595667  (ang.).
• Y.Y. Sheffer Y.Y., H.H. Tschofenig H.H., Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption, RFC 5723, IETF, styczeń 2010, DOI: 10.17487/RFC5723, ISSN 2070-1721, OCLC 943595667  (ang.).
• E.E. Ertekin E.E. i inni, Integration of Robust Header Compression over IPsec Security Associations, RFC 5856, IETF, maj 2010, DOI: 10.17487/RFC5856, ISSN 2070-1721, OCLC 943595667  (ang.).
• E.E. Ertekin E.E. i inni, IKEv2 Extensions to Support Robust Header Compression over IPsec, RFC 5857, IETF, maj 2010, DOI: 10.17487/RFC5857, ISSN 2070-1721, OCLC 943595667  (ang.).
• E.E. Ertekin E.E., C.C. Christou C.C., C.C. Bormann C.C., IPsec Extensions to Support Robust Header Compression over IPsec, RFC 5858, IETF, maj 2010, DOI: 10.17487/RFC5858, ISSN 2070-1721, OCLC 943595667  (ang.).
• S.S. Shen S.S., Y.Y. Mao Y.Y., NSS.N. Murthy NSS.N., Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol, RFC 5930, IETF, lipiec 2010, DOI: 10.17487/RFC5930, ISSN 2070-1721, OCLC 943595667  (ang.).
• C.C. Kaufman C.C. i inni, Internet Key Exchange Protocol Version 2 (IKEv2), RFC 5996, IETF, wrzesień 2010, DOI: 10.17487/RFC5996, ISSN 2070-1721, OCLC 943595667  (ang.).
• Y.Y. Nir Y.Y., IPsec Cluster Problem Statement, RFC 6027, IETF, październik 2010, DOI: 10.17487/RFC6027, ISSN 2070-1721, OCLC 943595667  (ang.).
• S.S. Frankel S.S., S.S. Krishnan S.S., IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap, RFC 6071, IETF, luty 2011, DOI: 10.17487/RFC6071, ISSN 2070-1721, OCLC 943595667  (ang.).
• L.L. Law L.L., J.J. Solinas J.J., Suite B Cryptographic Suites for IPsec, RFC 6379, IETF, październik 2011, DOI: 10.17487/RFC6379, ISSN 2070-1721, OCLC 943595667  (ang.).
• K.K. Burgin K.K., M.M. Peck M.M., Suite B Profile for Internet Protocol Security (IPsec), RFC 6380, IETF, październik 2011, DOI: 10.17487/RFC6380, ISSN 2070-1721, OCLC 943595667  (ang.).
• T.T. Kivinen T.T., Secure Password Framework for Internet Key Exchange Version 2 (IKEv2), RFC 6467, IETF, grudzień 2011, DOI: 10.17487/RFC6467, ISSN 2070-1721, OCLC 943595667  (ang.).
• C.C. Kaufman C.C. i inni, Internet Key Exchange Protocol Version 2 (IKEv2), STD 79, RFC 7296, IETF, październik 2014, DOI: 10.17487/RFC7296, ISSN 2070-1721, OCLC 943595667  (ang.).
• D.D. McGrew D.D., P.P. Hoffman P.P., Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH), RFC 7321, IETF, sierpień 2014, DOI: 10.17487/RFC7321, ISSN 2070-1721, OCLC 943595667  (ang.).
• V.V. Smyslov V.V., Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation, RFC 7383, IETF, listopad 2014, DOI: 10.17487/RFC7383, ISSN 2070-1721, OCLC 943595667  (ang.).
• T.T. Kivinen T.T., J.J. Snyder J.J., Signature Authentication in the Internet Key Exchange Version 2 (IKEv2), RFC 7427, IETF, styczeń 2015, DOI: 10.17487/RFC7427, ISSN 2070-1721, OCLC 943595667  (ang.).
• Y.Y. Nir Y.Y., ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec, RFC 7634, IETF, sierpień 2015, DOI: 10.17487/RFC7634, ISSN 2070-1721, OCLC 943595667  (ang.).