IPsec

En informática, Internet Protocol Security (IPsec) o Seguridad de Protocolos de Internet o Seguridad de IP es un conjunto de protocolos de red segura que autentica y cifra los paquetes de datos para proporcionar una comunicación cifrada segura entre dos ordenadores a través de una red de protocolo de Internet. Se utiliza en redes privadas virtuales (VPN).

IPsec incluye protocolos para establecer autenticación mutua entre agentes al inicio de una sesión y negociación de claves criptográficas a utilizar durante la sesión. IPsec puede proteger los flujos de datos entre un par de hosts (host a host), entre un par de puertas de enlace de seguridad (red a red) o entre una puerta de enlace de seguridad y un host (red a host). IPsec utiliza servicios de seguridad criptográficos para proteger las comunicaciones a través de redes de protocolo de Internet (IP). Admite autenticación de pares a nivel de red, autenticación de origen de datos, integridad de datos, confidencialidad de datos (cifrado) y protección de reproducción (protección contra ataques de reproducción).

La suite IPv4 inicial se desarrolló con pocas disposiciones de seguridad. Como parte de la mejora de IPv4, IPsec es un modelo OSI de capa 3 o un esquema de seguridad de extremo a extremo de la capa de Internet. Por el contrario, mientras que otros sistemas de seguridad de Internet de uso generalizado operan por encima de la capa de red, como Transport Layer Security (TLS) que opera por encima de la capa de transporte y Secure Shell (SSH) que opera en la capa de aplicación, IPsec puede proteger automáticamente las aplicaciones. en la capa de internet.

Historia

A principios de la década de 1970, la Agencia de Proyectos de Investigación Avanzada patrocinó una serie de dispositivos de cifrado ARPANET experimentales, primero para el cifrado nativo de paquetes ARPANET y, posteriormente, para el cifrado de paquetes TCP/IP; algunos de estos fueron certificados y enviados al campo. De 1986 a 1991, la NSA patrocinó el desarrollo de protocolos de seguridad para Internet bajo su programa Secure Data Network Systems (SDNS). Esto reunió a varios proveedores, incluido Motorola, que produjo un dispositivo de cifrado de red en 1988. El NIST publicó abiertamente el trabajo aproximadamente en 1988 y, de estos, el Protocolo de seguridad en la capa 3 (SP3) eventualmente se transformaría en el Protocolo de seguridad de la capa de red estándar ISO. (NLSP).

De 1992 a 1995, varios grupos realizaron investigaciones sobre el cifrado de la capa IP.

• 1. En 1992, el Laboratorio de Investigación Naval de EE. UU. (NRL) inició el proyecto Simple Internet Protocol Plus (SIPP) para investigar e implementar el cifrado de IP.
• 2. En 1993, en la Universidad de Columbia y AT&T Bell Labs, John Ioannidis y otros investigaron el software experimental Software IP Encryption Protocol (swIPe) en SunOS.
• 3. En 1993, con el patrocinio del proyecto de servicio de Internet Whitehouse, Wei Xu de Trusted Information Systems (TIS) investigó más a fondo los protocolos de seguridad IP de software y desarrolló el soporte de hardware para Triple DES, que estaba codificado en el kernel BSD 4.1 y era compatible con x86 y arquitecturas SUNOS. En diciembre de 1994, TIS lanzó su producto Gauntlet Firewall de código abierto patrocinado por DARPA con el cifrado de hardware 3DES integrado a velocidades superiores a T1. Fue la primera vez que se usaron conexiones VPN IPSec entre la costa este y oeste de los Estados Unidos, conocido como el primer producto VPN IPSec comercial.
• 4. Bajo el esfuerzo de investigación financiado por DARPA de NRL, NRL desarrolló las especificaciones de seguimiento de estándares IETF (RFC 1825 a RFC 1827) para IPsec, que se codificó en el kernel BSD 4.4 y admitió arquitecturas de CPU x86 y SPARC. La implementación de IPsec de NRL se describió en su artículo en las actas de la conferencia USENIX de 1996. El MIT puso a disposición en línea la implementación IPsec de código abierto de NRL y se convirtió en la base para la mayoría de las implementaciones comerciales iniciales.

El Grupo de Trabajo de Ingeniería de Internet (IETF) formó el Grupo de Trabajo de Seguridad IP en 1992 para estandarizar las extensiones de seguridad especificadas abiertamente para IP, llamadas IPsec. En 1995, el grupo de trabajo organizó algunos de los talleres con miembros de las cinco empresas (TIS, Cisco, FTP, Checkpoint, etc.). Durante los talleres de IPSec, los estándares de NRL y el software de Cisco y TIS se estandarizan como referencias públicas, publicadas como RFC-1825 a RFC-1827.

Arquitectura de seguridad

El IPsec es un estándar abierto como parte de la suite IPv4. IPsec utiliza los siguientes protocolos para realizar varias funciones:

• Los encabezados de autenticación (AH) brindan integridad de datos sin conexión y autenticación de origen de datos para datagramas IP y brindan protección contra ataques de reproducción.
• Encapsulating Security Payloads (ESP) proporciona confidencialidad, integridad de datos sin conexión, autenticación de origen de datos, un servicio anti-reproducción (una forma de integridad de secuencia parcial) y confidencialidad limitada del flujo de tráfico.
• Internet Security Association and Key Management Protocol (ISAKMP) proporciona un marco para la autenticación y el intercambio de claves, con material de claves autenticado real proporcionado mediante configuración manual con claves precompartidas, Intercambio de claves de Internet (IKE e IKEv2), Negociación de claves de Internet Kerberizado (KINK) o registros DNS IPSECKEY. El propósito es generar las Asociaciones de Seguridad (SA) con el paquete de algoritmos y parámetros necesarios para las operaciones AH y/o ESP.

Encabezado de autenticación

El encabezado de autenticación de seguridad (AH) se desarrolló en el Laboratorio de Investigación Naval de EE. UU. a principios de la década de 1990 y se deriva en parte del trabajo de estándares IETF anteriores para la autenticación del Protocolo simple de administración de redes (SNMP) versión 2. El encabezado de autenticación (AH) es miembro del conjunto de protocolos IPsec. AH garantiza la integridad sin conexión mediante el uso de una función hash y una clave secreta compartida en el algoritmo AH. AH también garantiza el origen de los datos mediante la autenticación de paquetes IP. Opcionalmente, un número de secuencia puede proteger el contenido del paquete IPsec contra ataques de repetición, utilizando la técnica de ventana deslizante y descartando paquetes antiguos.

• En IPv4, AH previene los ataques de inserción de opciones. En IPv6, AH protege contra ataques de inserción de encabezados y ataques de inserción de opciones.
• En IPv4, el AH protege la carga útil de IP y todos los campos de encabezado de un datagrama de IP, excepto los campos mutables (es decir, aquellos que pueden modificarse en tránsito), y también las opciones de IP, como la opción de seguridad de IP (RFC 1108). Los campos de encabezado IPv4 mutables (y por lo tanto no autenticados) son DSCP/ToS, ECN, Flags, Fragment Offset, TTL y Header Checksum.
• En IPv6, el AH protege la mayor parte del encabezado base de IPv6, el propio AH, los encabezados de extensión no mutables después del AH y la carga útil de IP. La protección del encabezado IPv6 excluye los campos mutables: DSCP, ECN, etiqueta de flujo y límite de salto.

AH opera directamente sobre IP, utilizando el protocolo IP número 51.

El siguiente diagrama de paquetes AH muestra cómo se construye e interpreta un paquete AH:

Compensaciones	octeto 16	0	1	2	3
octeto 16	Bit 10	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	dieciséis	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Siguiente encabezado	Longitud de carga útil	Reservado
4	32	Índice de parámetros de seguridad (SPI)
8	64	Secuencia de números
C	96	Valor de verificación de integridad (ICV)...
...	...

Siguiente encabezado (8 bits)Escriba el siguiente encabezado, que indica qué protocolo de capa superior estaba protegido. El valor se toma de la lista de números de protocolo IP.Longitud de carga útil (8 bits)La longitud de este encabezado de autenticación en unidades de 4 octetos, menos 2. Por ejemplo, un valor AH de 4 es igual a 3 × (campos AH de longitud fija de 32 bits) + 3 × (campos ICV de 32 bits) − 2 y, por lo tanto, un valor AH de 4 significa 24 octetos. Aunque el tamaño se mide en unidades de 4 octetos, la longitud de este encabezado debe ser un múltiplo de 8 octetos si se transporta en un paquete IPv6. Esta restricción no se aplica a un encabezado de autenticación transportado en un paquete IPv4.Reservado (16 bits)Reservado para uso futuro (todos ceros hasta entonces).Índice de parámetros de seguridad (32 bits)Valor arbitrario que se utiliza (junto con la dirección IP de destino) para identificar la asociación de seguridad de la parte receptora.Número de secuencia (32 bits)Un número de secuencia monótono estrictamente creciente (incrementado en 1 por cada paquete enviado) para evitar ataques de repetición. Cuando la detección de reproducción está habilitada, los números de secuencia nunca se reutilizan, porque se debe renegociar una nueva asociación de seguridad antes de intentar incrementar el número de secuencia más allá de su valor máximo.Valor de verificación de integridad (múltiplo de 32 bits)Valor de comprobación de longitud variable. Puede contener relleno para alinear el campo con un límite de 8 octetos para IPv6 o un límite de 4 octetos para IPv4.

Carga útil de seguridad encapsulada

La carga útil de seguridad de encapsulación IP (ESP) se desarrolló en el Laboratorio de Investigación Naval a partir de 1992 como parte de un proyecto de investigación patrocinado por DARPA y fue publicada abiertamente por IETF SIPPGrupo de Trabajo redactado en diciembre de 1993 como una extensión de seguridad para SIPP. Este ESP se derivó originalmente del protocolo SP3D del Departamento de Defensa de EE. UU., en lugar de derivarse del Protocolo de seguridad de capa de red (NLSP) de ISO. La especificación del protocolo SP3D fue publicada por NIST a fines de la década de 1980, pero fue diseñada por el proyecto Sistema de red de datos seguros del Departamento de Defensa de EE. UU. Encapsulating Security Payload (ESP) es un miembro del conjunto de protocolos IPsec. Proporciona autenticidad de origen a través de la autenticación de origen, integridad de datos a través de funciones hash y confidencialidad a través de protección de cifrado para paquetes IP. ESP también admite configuraciones de solo cifrado y solo autenticación, pero se desaconseja encarecidamente el uso de cifrado sin autenticación porque es inseguro.

A diferencia del encabezado de autenticación (AH), ESP en el modo de transporte no proporciona integridad ni autenticación para todo el paquete IP. Sin embargo, en el modo de túnel, donde todo el paquete IP original se encapsula con un nuevo encabezado de paquete agregado, la protección ESP se brinda a todo el paquete IP interno (incluido el encabezado interno) mientras que el encabezado externo (incluidas las opciones IPv4 externas o la extensión IPv6). encabezados) permanece desprotegido. ESP opera directamente sobre IP, utilizando el protocolo IP número 50.

El siguiente diagrama de paquetes ESP muestra cómo se construye e interpreta un paquete ESP:

Compensaciones	octeto 16	0	1	2	3
octeto 16	Bit 10	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	dieciséis	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
0	0	Índice de parámetros de seguridad (SPI)
4	32	Secuencia de números
8	64	Datos de carga útil
...	...
...	...
...	...		Relleno (0-255 octetos)
...	...		Longitud de la almohadilla	Siguiente encabezado
...	...	Valor de verificación de integridad (ICV)...
...	...

Índice de parámetros de seguridad (32 bits)Valor arbitrario utilizado (junto con la dirección IP de destino) para identificar la asociación de seguridad de la parte receptora.Número de secuencia (32 bits)Un número de secuencia que aumenta monótonamente (incrementado en 1 por cada paquete enviado) para proteger contra ataques de reproducción. Hay un contador separado para cada asociación de seguridad.Datos de carga útil (variable)Los contenidos protegidos del paquete IP original, incluidos los datos utilizados para proteger los contenidos (por ejemplo, un vector de inicialización para el algoritmo criptográfico). El tipo de contenido que se protegió se indica en el campo Siguiente encabezado.Relleno (0-255 octetos)Relleno para el cifrado, para ampliar los datos de carga útil a un tamaño que se ajuste al tamaño del bloque de cifrado del cifrado y para alinear el siguiente campo.Longitud de la almohadilla (8 bits)Tamaño del relleno (en octetos).Siguiente encabezado (8 bits)Tipo del siguiente encabezado. El valor se toma de la lista de números de protocolo IP.Valor de verificación de integridad (múltiplo de 32 bits)Valor de comprobación de longitud variable. Puede contener relleno para alinear el campo con un límite de 8 octetos para IPv6 o un límite de 4 octetos para IPv4.

Asociación de seguridad

Los protocolos IPsec utilizan una asociación de seguridad, donde las partes que se comunican establecen atributos de seguridad compartidos, como algoritmos y claves. Como tal, IPsec proporciona una variedad de opciones una vez que se ha determinado si se usa AH o ESP. Antes de intercambiar datos, los dos hosts acuerdan qué algoritmo de cifrado simétrico se utiliza para cifrar el paquete IP, por ejemplo, AES o ChaCha20, y qué función hash se utiliza para garantizar la integridad de los datos, como BLAKE2 o SHA256. Estos parámetros se acuerdan para la sesión en particular, para lo cual se debe pactar un tiempo de vida y una clave de sesión.

El algoritmo de autenticación también se acuerda antes de que tenga lugar la transferencia de datos e IPsec admite una variedad de métodos. La autenticación es posible a través de una clave precompartida, donde una clave simétrica ya está en posesión de ambos hosts, y los hosts se envían entre sí hashes de la clave compartida para demostrar que están en posesión de la misma clave. IPsec también es compatible con el cifrado de clave pública, donde cada host tiene una clave pública y una privada, intercambian sus claves públicas y cada host envía al otro un nonce cifrado con la clave pública del otro host. Alternativamente, si ambos hosts tienen un certificado de clave pública de una autoridad de certificación, esto se puede usar para la autenticación de IPsec.

Las asociaciones de seguridad de IPsec se establecen utilizando la Asociación de seguridad de Internet y el Protocolo de administración de claves (ISAKMP). ISAKMP se implementa mediante configuración manual con secretos precompartidos, intercambio de claves de Internet (IKE e IKEv2), negociación de claves de Internet Kerberizada (KINK) y el uso de registros IPSECKEY DNS. RFC 5386 define Better-Than-Nothing Security (BTNS) como un modo no autenticado de IPsec que usa un protocolo IKE extendido. C. Meadows, C. Cremers y otros han utilizado métodos formales para identificar varias anomalías que existen en IKEv1 y también en IKEv2.

Para decidir qué protección se proporcionará a un paquete saliente, IPsec utiliza el índice de parámetros de seguridad (SPI), un índice de la base de datos de asociaciones de seguridad (SADB), junto con la dirección de destino en un encabezado de paquete, que en conjunto identifica de manera única una asociación de seguridad para ese paquete. Se realiza un procedimiento similar para un paquete entrante, donde IPsec recopila claves de descifrado y verificación de la base de datos de la asociación de seguridad.

Para la multidifusión IP, se proporciona una asociación de seguridad para el grupo y se duplica en todos los receptores autorizados del grupo. Puede haber más de una asociación de seguridad para un grupo, utilizando diferentes SPI, lo que permite múltiples niveles y conjuntos de seguridad dentro de un grupo. De hecho, cada remitente puede tener múltiples asociaciones de seguridad, lo que permite la autenticación, ya que un receptor solo puede saber que alguien que conoce las claves envió los datos. Tenga en cuenta que el estándar relevante no describe cómo se elige y duplica la asociación en todo el grupo; se supone que una parte responsable habrá hecho la elección.

Modos de operacion

Los protocolos IPsec AH y ESP se pueden implementar en un modo de transporte de host a host, así como en un modo de tunelización de red.

Modo de transporte

En el modo de transporte, generalmente solo se encripta o autentica la carga útil del paquete IP. El enrutamiento está intacto, ya que el encabezado IP no se modifica ni se cifra; sin embargo, cuando se usa el encabezado de autenticación, las direcciones IP no se pueden modificar mediante la traducción de direcciones de red, ya que esto siempre invalida el valor hash. Las capas de transporte y aplicación siempre están protegidas por un hash, por lo que no se pueden modificar de ninguna manera, por ejemplo, traduciendo los números de puerto.

Los documentos RFC que describen el mecanismo NAT-T han definido un medio para encapsular mensajes IPsec para NAT transversal.

Modo túnel

En modo túnel, todo el paquete IP se cifra y se autentica. Luego se encapsula en un nuevo paquete IP con un nuevo encabezado IP. El modo túnel se utiliza para crear redes privadas virtuales para comunicaciones de red a red (p. ej., entre enrutadores para enlazar sitios), comunicaciones de host a red (p. ej., acceso de usuario remoto) y comunicaciones de host a host (p. ej., chat privado).

El modo de túnel admite NAT transversal.

Algoritmos

Algoritmos de cifrado simétrico

Los algoritmos criptográficos definidos para su uso con IPsec incluyen:

• HMAC-SHA1/SHA2 para protección de integridad y autenticidad.
• TripleDES-CBC por confidencialidad
• AES-CBC y AES-CTR por confidencialidad.
• AES-GCM y ChaCha20-Poly1305 brindan confidencialidad y autenticación juntas de manera eficiente.

Consulte RFC 8221 para obtener más detalles.

Algoritmos de intercambio de claves

• Diffie–Hellman (RFC 3526)
• ECDH (RFC 4753)

Algoritmos de autenticación

• RSA
• ECDSA (RFC 4754)
• PSK (RFC 6617)

Implementaciones

El IPsec se puede implementar en la pila de IP de un sistema operativo, lo que requiere la modificación del código fuente. Este método de implementación se realiza para hosts y puertas de enlace de seguridad. Varias pilas de IP compatibles con IPsec están disponibles en empresas, como HP o IBM.Una alternativa es la denominada implementación bump-in-the-stack (BITS), en la que no es necesario modificar el código fuente del sistema operativo. Aquí se instala IPsec entre la pila de IP y los controladores de red. De esta forma, los sistemas operativos pueden actualizarse con IPsec. Este método de implementación también se usa para hosts y puertas de enlace. Sin embargo, al actualizar IPsec, la encapsulación de paquetes IP puede causar problemas para el descubrimiento automático de MTU de ruta, donde se establece el tamaño máximo de la unidad de transmisión (MTU) en la ruta de red entre dos hosts IP. Si un host o una puerta de enlace tiene un criptoprocesador separado, que es común en el ejército y también se puede encontrar en sistemas comerciales, es posible una implementación de IPsec denominada bump-in-the-wire (BITW).

Cuando se implementa IPsec en el núcleo, la gestión de claves y la negociación ISAKMP/IKE se lleva a cabo desde el espacio del usuario. La "API de administración de claves PF_KEY, versión 2" desarrollada por NRL y especificada abiertamente se usa a menudo para permitir que la aplicación de administración de claves del espacio de la aplicación actualice las asociaciones de seguridad de IPsec almacenadas dentro de la implementación de IPsec del espacio del kernel. Las implementaciones de IPsec existentes generalmente incluyen ESP, AH e IKE versión 2. Las implementaciones de IPsec existentes en sistemas operativos similares a Unix, por ejemplo, Solaris o Linux, generalmente incluyen PF_KEY versión 2.

El IPsec integrado se puede utilizar para garantizar la comunicación segura entre las aplicaciones que se ejecutan en sistemas de recursos limitados con una pequeña sobrecarga.

Estado de las normas

IPsec se desarrolló junto con IPv6 y originalmente se requería que fuera compatible con todas las implementaciones de IPv6 que cumplieran con los estándares antes de que RFC 6434 lo hiciera solo una recomendación. IPsec también es opcional para las implementaciones de IPv4. IPsec se usa más comúnmente para proteger el tráfico IPv4.

Los protocolos IPsec se definieron originalmente en RFC 1825 a RFC 1829, que se publicaron en 1995. En 1998, estos documentos fueron reemplazados por RFC 2401 y RFC 2412 con algunos detalles de ingeniería incompatibles, aunque eran conceptualmente idénticos. Además, se definió un protocolo de autenticación mutua e intercambio de claves Internet Key Exchange (IKE) para crear y administrar asociaciones de seguridad. En diciembre de 2005, se definieron nuevos estándares en RFC 4301 y RFC 4309, que son en gran medida un superconjunto de las ediciones anteriores con una segunda versión del estándar de intercambio de claves de Internet IKEv2. Estos documentos de tercera generación estandarizaron la abreviatura de IPsec a mayúsculas "IP" y minúsculas "sec". "ESP" generalmente se refiere a RFC 4303, que es la versión más reciente de la especificación.

Desde mediados de 2008, un grupo de trabajo de mantenimiento y extensiones de IPsec (ipsecme) está activo en el IETF.

Presunta interferencia de la NSA

En 2013, como parte de las filtraciones de Snowden, se reveló que la Agencia de Seguridad Nacional de EE. UU. había estado trabajando activamente para "insertar vulnerabilidades en sistemas comerciales de encriptación, sistemas de TI, redes y dispositivos de comunicación de punto final utilizados por objetivos" como parte del programa Bullrun.. Hay acusaciones de que IPsec era un sistema de cifrado dirigido.

La pila OpenBSD IPsec llegó más tarde y también fue ampliamente copiada. En una carta que el desarrollador principal de OpenBSD, Theo de Raadt, recibió el 11 de diciembre de 2010 de Gregory Perry, se alega que Jason Wright y otros, que trabajaban para el FBI, insertaron "una serie de puertas traseras y mecanismos de filtración de claves de canales laterales" en la criptografía de OpenBSD. código. En el correo electrónico reenviado de 2010, Theo de Raadt al principio no expresó una posición oficial sobre la validez de los reclamos, aparte del respaldo implícito del reenvío del correo electrónico. La respuesta de Jason Wright a las acusaciones: "Cada leyenda urbana se vuelve más real mediante la inclusión de nombres, fechas y horas reales. El correo electrónico de Gregory Perry entra en esta categoría.Algunos días después, de Raadt comentó que "Creo que probablemente se contrató a NETSEC para escribir backdoors como se alega... Si se escribieron, no creo que hayan llegado a nuestro árbol". Esto fue publicado antes de las filtraciones de Snowden.

Una explicación alternativa presentada por los autores del ataque Logjam sugiere que la NSA comprometió las VPN IPsec al socavar el algoritmo Diffie-Hellman utilizado en el intercambio de claves. En su artículo, alegan que la NSA construyó especialmente un clúster de computación para precalcular subgrupos multiplicativos para primos y generadores específicos, como el segundo grupo de Oakley definido en RFC 2409. En mayo de 2015, el 90 % de las VPN IPsec direccionables admitían el segundo Oakley grupo como parte de IKE. Si una organización precalculara este grupo, podría derivar las claves que se intercambian y descifrar el tráfico sin insertar ninguna puerta trasera de software.

Una segunda explicación alternativa que se presentó fue que Equation Group usó exploits de día cero contra equipos VPN de varios fabricantes que fueron validados por Kaspersky Lab como vinculados a Equation Group y validados por esos fabricantes como exploits reales, algunos de los cuales eran hazañas de día cero en el momento de su exposición. Los cortafuegos Cisco PIX y ASA tenían vulnerabilidades que la NSA utilizaba para realizar escuchas telefónicas.

Además, las VPN con IPsec que utilizan la configuración de "Modo agresivo" envían un hash del PSK sin cifrar. Esto puede ser y aparentemente es el objetivo de la NSA utilizando ataques de diccionario fuera de línea.

Documentación del IETF

Pista de estándares

• RFC 1829: La transformación ESP DES-CBC
• RFC 2403: El uso de HMAC-MD5-96 dentro de ESP y AH
• RFC 2404: El uso de HMAC-SHA-1-96 dentro de ESP y AH
• RFC 2405: El algoritmo de cifrado ESP DES-CBC con IV explícito
• RFC 2410: El algoritmo de cifrado NULL y su uso con IPsec
• RFC 2451: Los algoritmos de cifrado ESP CBC-Mode
• RFC 2857: El uso de HMAC-RIPEMD-160-96 dentro de ESP y AH
• RFC 3526: más grupos modulares exponenciales (MODP) Diffie-Hellman para intercambio de claves de Internet (IKE)
• RFC 3602: El algoritmo de cifrado AES-CBC y su uso con IPsec
• RFC 3686: uso del modo de contador del estándar de cifrado avanzado (AES) con carga útil de seguridad de encapsulamiento (ESP) IPsec
• RFC 3947: Negociación de NAT-Traversal en el IKE
• RFC 3948: Encapsulación UDP de paquetes IPsec ESP
• RFC 4106: El uso de Galois/Modo contador (GCM) en IPsec Encapsulating Security Payload (ESP)
• RFC 4301: Arquitectura de seguridad para el protocolo de Internet
• RFC 4302: encabezado de autenticación de IP
• RFC 4303: Carga útil de seguridad de encapsulación de IP
• RFC 4304: Apéndice del número de secuencia extendida (ESN) al dominio de interpretación (DOI) de IPsec para la asociación de seguridad de Internet y el protocolo de administración de claves (ISAKMP)
• RFC 4307: algoritmos criptográficos para uso en Internet Key Exchange versión 2 (IKEv2)
• RFC 4308: Suites criptográficas para IPsec
• RFC 4309: uso del modo CCM del estándar de cifrado avanzado (AES) con carga útil de seguridad de encapsulamiento (ESP) de IPsec
• RFC 4543: El uso del código de autenticación de mensajes de Galois (GMAC) en IPsec ESP y AH
• RFC 4555: Protocolo de movilidad y host múltiple IKEv2 (MOBIKE)
• RFC 4806: Extensiones del Protocolo de estado de certificado en línea (OCSP) para IKEv2
• RFC 4868: uso de HMAC-SHA-256, HMAC-SHA-384 y HMAC-SHA-512 con IPsec
• RFC 4945: El perfil PKI de seguridad IP de Internet de IKEv1/ISAKMP, IKEv2 y PKIX
• RFC 5280: Certificado de infraestructura de clave pública X.509 de Internet y perfil de lista de revocación de certificados (CRL)
• RFC 5282: uso de algoritmos de cifrado autenticados con la carga útil cifrada del protocolo Internet Key Exchange versión 2 (IKEv2)
• RFC 5386: Seguridad mejor que nada: un modo no autenticado de IPsec
• RFC 5529: Modos de funcionamiento de Camellia para uso con IPsec
• RFC 5685: Mecanismo de redirección para el protocolo de intercambio de claves de Internet versión 2 (IKEv2)
• RFC 5723: Protocolo de intercambio de claves de Internet versión 2 (IKEv2) Reanudación de sesión
• RFC 5857: Extensiones IKEv2 para admitir una compresión robusta de encabezados a través de IPsec
• RFC 5858: Extensiones IPsec para admitir una compresión sólida de encabezados sobre IPsec
• RFC 7296: Protocolo de intercambio de claves de Internet versión 2 (IKEv2)
• RFC 7321: Requisitos de implementación de algoritmos criptográficos y guía de uso para encapsular la carga útil de seguridad (ESP) y el encabezado de autenticación (AH)
• RFC 7383: Fragmentación de mensajes del Protocolo de intercambio de claves de Internet versión 2 (IKEv2)
• RFC 7427: autenticación de firma en Internet Key Exchange versión 2 (IKEv2)
• RFC 7634: ChaCha20, Poly1305 y su uso en el protocolo de intercambio de claves de Internet (IKE) e IPsec

RFC experimentales

• RFC 4478: Protocolo de autenticación repetida en el intercambio de claves de Internet (IKEv2)

RFC informativos

• RFC 2367: interfaz PF_KEY
• RFC 2412: Protocolo de determinación de claves de OAKLEY
• RFC 3706: un método basado en el tráfico para detectar pares de intercambio de claves de Internet (IKE) inactivos
• RFC 3715: Requisitos de compatibilidad de traducción de direcciones de red (NAT) IPsec
• RFC 4621: Diseño del protocolo IKEv2 Mobility and Multihoming (MOBIKE)
• RFC 4809: Requisitos para un perfil de administración de certificados IPsec
• RFC 5387: Declaración de problema y aplicabilidad para seguridad mejor que nada (BTNS)
• RFC 5856: Integración de compresión robusta de encabezado sobre asociaciones de seguridad IPsec
• RFC 5930: uso del modo de contador estándar de cifrado avanzado (AES-CTR) con el protocolo Internet Key Exchange versión 02 (IKEv2)
• RFC 6027: Declaración del problema del clúster IPsec
• RFC 6071: hoja de ruta de documentos IPsec e IKE
• RFC 6379: suites criptográficas Suite B para IPsec
• RFC 6380: perfil de Suite B para seguridad de protocolo de Internet (IPsec)
• RFC 6467: Marco de contraseñas seguras para el intercambio de claves de Internet versión 2 (IKEv2)

RFC de mejores prácticas actuales

• RFC 5406: Directrices para especificar el uso de IPsec versión 2

RFC obsoletos/históricos

• RFC 1825: Arquitectura de seguridad para el Protocolo de Internet (obsoleto por RFC 2401)
• RFC 1826: encabezado de autenticación IP (obsoleto por RFC 2402)
• RFC 1827: Carga útil de seguridad de encapsulación IP (ESP) (obsoleta por RFC 2406)
• RFC 1828: Autenticación de IP usando Keyed MD5 (histórico)
• RFC 2401: arquitectura de seguridad para el protocolo de Internet (descripción general de IPsec) (obsoleto por RFC 4301)
• RFC 2406: Carga útil de seguridad de encapsulación IP (ESP) (obsoleta por RFC 4303 y RFC 4305)
• RFC 2407: El dominio de interpretación de seguridad IP de Internet para ISAKMP (obsoleto por RFC 4306)
• RFC 2409: Intercambio de claves de Internet (obsoleto por RFC 4306)
• RFC 4305: requisitos de implementación de algoritmos criptográficos para encapsular la carga útil de seguridad (ESP) y el encabezado de autenticación (AH) (obsoleto por RFC 4835)
• RFC 4306: Protocolo de intercambio de claves de Internet (IKEv2) (obsoleto por RFC 5996)
• RFC 4718: Aclaraciones de IKEv2 y pautas de implementación (obsoleto por RFC 7296)
• RFC 4835: requisitos de implementación de algoritmos criptográficos para encapsular la carga útil de seguridad (ESP) y el encabezado de autenticación (AH) (obsoleto por RFC 7321)
• RFC 5996: Protocolo de intercambio de claves de Internet versión 2 (IKEv2) (obsoleto por RFC 7296)