stringtranslate.com

IPsec

En informática , el protocolo de seguridad de Internet ( IPsec ) es un conjunto de protocolos de red seguros que autentican y cifran paquetes de datos para proporcionar una comunicación cifrada segura entre dos computadoras 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 comienzo de una sesión y la negociación de claves criptográficas para usar durante la sesión. IPsec puede proteger flujos de datos entre un par de hosts ( host-to-host ), entre un par de puertas de enlace de seguridad ( red-to-network ) o entre una puerta de enlace de seguridad y un host ( red-to-host ). [1] IPsec utiliza servicios de seguridad criptográfica 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 ( encriptación ) y protección contra ataques de repetición .

Historia

A principios de los años 1970, la Agencia de Proyectos de Investigación Avanzada patrocinó una serie de dispositivos experimentales de cifrado ARPANET , primero para el cifrado nativo de paquetes ARPANET y luego para el cifrado de paquetes TCP/IP ; algunos de ellos fueron certificados y puestos en práctica. De 1986 a 1991, la NSA patrocinó el desarrollo de protocolos de seguridad para Internet bajo su programa Secure Data Network Systems (SDNS). [2] Esto reunió a varios proveedores, incluido Motorola , que produjo un dispositivo de cifrado de red en 1988. El trabajo fue publicado abiertamente a partir de 1988 por el NIST 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 (NLSP) estándar de la ISO. [3]

En 1992, el Laboratorio de Investigación Naval de los Estados Unidos (NRL) recibió financiación de DARPA CSTO para implementar IPv6 e investigar e implementar el cifrado IP en 4.4 BSD , compatible con arquitecturas de CPU SPARC y x86. DARPA puso su implementación a disposición de forma gratuita a través del MIT. En el marco del esfuerzo de investigación financiado por DARPA del NRL , el NRL desarrolló las especificaciones de la vía de estándares de la IETF (RFC 1825 a RFC 1827) para IPsec. [4] La implementación de IPsec del NRL se describió en su artículo en las Actas de la Conferencia USENIX de 1996. [5] La implementación de IPsec de código abierto del NRL se puso a disposición en línea por el MIT y se convirtió en la base de la mayoría de las implementaciones comerciales iniciales. [4]

El Grupo de Trabajo de Ingeniería de Internet (IETF) formó el Grupo de Trabajo de Seguridad IP en 1992 [6] para estandarizar las extensiones de seguridad especificadas abiertamente para IP, llamadas IPsec . [7] Los estándares desarrollados por NRL fueron publicados por el IETF como RFC 1825 a RFC 1827. [8]

Arquitectura de seguridad

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 .

IPsec es un estándar abierto como parte de la suite IPv4 y utiliza los siguientes protocolos para realizar varias funciones: [9] [10]

Encabezado de autenticación

Uso del formato de encabezado de autenticación IPsec en los modos túnel y transporte

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 anteriores de IETF para la autenticación del Protocolo simple de administración de red (SNMP) versión 2. El encabezado de autenticación (AH) es un miembro del conjunto de protocolos IPsec. AH garantiza la integridad sin conexión mediante el uso de una función hash y una clave compartida secreta 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 , [17] [18] utilizando la técnica de ventana deslizante y descartando paquetes antiguos.

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

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

Encabezado siguiente: 8 bits
Tipo del siguiente encabezado, que indica qué protocolo de capa superior se protegió. 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 equivale 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 incluye en un paquete IPv6. Esta restricción no se aplica a un encabezado de autenticación incluido 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 estrictamente creciente y monótono (que se incrementa en 1 por cada paquete enviado) para evitar ataques de repetición . Cuando la detección de repetició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. [11]
Valor de comprobación de integridad: múltiplo de 32 bits
Valor de comprobación de longitud variable. Puede contener relleno para alinear el campo a un límite de 8 octetos para IPv6 o de 4 octetos para IPv4 .

Encapsulación de la carga útil de seguridad

Uso de la carga útil de seguridad encapsulante (ESP) de IPsec en los modos túnel y transporte

La carga útil de seguridad encapsulante IP (ESP) [21] 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 el Grupo de trabajo SIPP [22] de IETF 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 los 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 diseñada por el proyecto Secure Data Network System del Departamento de Defensa de los EE. UU . La carga útil de seguridad encapsulante (ESP) es un miembro del conjunto de protocolos IPsec. Proporciona autenticidad de origen a través de la autenticación de fuente , 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 enfáticamente el uso de cifrado sin autenticación porque es inseguro. [23] [24] [25]

A diferencia del encabezado de autenticación (AH) , ESP en modo de transporte no proporciona integridad y autenticación para todo el paquete IP . Sin embargo, en modo 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 los encabezados de extensión IPv6) permanece desprotegido.

ESP opera directamente sobre IP, utilizando el protocolo IP número 50. [20]

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

Índice de parámetros de seguridad  (SPI): 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 de forma monótona (se incrementa en 1 por cada paquete enviado) para proteger contra ataques de repetición . Se mantiene un contador independiente para cada asociación de seguridad.
Datos de carga útil: variables
El contenido protegido del paquete IP original, incluidos los datos utilizados para proteger el contenido (por ejemplo, un vector de inicialización para el algoritmo criptográfico). El tipo de contenido que se protegió se indica en el campo Encabezado siguiente .
Relleno: 0-255 octetos
Opcional. Relleno para cifrado, para ampliar los datos de la 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 del pad: 8 bits
Tamaño del relleno (en octetos).
Encabezado siguiente: 8 bits
Indica el tipo de protocolo de los datos de carga útil , [26] : §2.6  como el valor 6 para TCP . Como ESP es un protocolo de encapsulación, también es posible un valor de 4 , que indica IP en IP . Un valor de 41 indica IPv6 encapsulado en IPv4 , p. ej. 6to4 . El valor 59 (que significa: Sin siguiente encabezado ) se utiliza para paquetes ficticios, que pueden insertarse en la secuencia y cuyo contenido debe descartarse.
Valor de verificación de integridad  (ICV): variable
Valor de comprobación de longitud variable. Puede contener relleno para alinear el campo a un límite de 8 octetos para IPv6 o 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 gama de opciones una vez que se ha determinado si se utiliza 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 la que se debe acordar un tiempo de vida y una clave de sesión . [27]

El algoritmo de autenticación también se acuerda antes de que se realice 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 admite 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 utilizar para la autenticación IPsec. [28]

Las asociaciones de seguridad de IPsec se establecen utilizando el Protocolo de administración de claves y asociación de seguridad de Internet (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 DNS IPSECKEY . [16] [1] : §1  [29] RFC 5386 define Better-Than-Nothing Security (BTNS) como un modo no autenticado de IPsec que utiliza 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. [30]

Para decidir qué protección se debe brindar 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 juntos identifican 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 asociaciones de seguridad.

Para la multidifusión IP, se proporciona una asociación de seguridad para el grupo, que 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 la asociación y se duplica en todo el grupo; se supone que una parte responsable habrá tomado la decisión.

Mantiene vivas las señales

Para garantizar que la conexión entre dos puntos finales no se haya interrumpido, los puntos finales intercambian mensajes de mantenimiento de conexión a intervalos regulares, que también pueden usarse para restablecer automáticamente un túnel perdido debido a una interrupción de la conexión.

La detección de pares inactivos (DPD) es un método para detectar un par inactivo de Internet Key Exchange (IKE). El método utiliza patrones de tráfico IPsec para minimizar la cantidad de mensajes necesarios para confirmar la disponibilidad de un par. La detección de pares inactivos se utiliza para recuperar los recursos perdidos en caso de que se encuentre un par inactivo y también se utiliza para realizar una conmutación por error de pares IKE.

UDP keepalive es una alternativa a DPD.

Modos de funcionamiento

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.

Modos IPsec

Modo de transporte

En el modo de transporte, normalmente solo se cifra 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 utiliza 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 han definido un medio para encapsular mensajes IPsec para la travesía NAT {NAT-T} que describe el mecanismo NAT-T.

Modo túnel

En el 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 (por ejemplo, entre enrutadores para vincular sitios), comunicaciones de host a red (por ejemplo, acceso de usuario remoto) y comunicaciones de host a host (por ejemplo, chat privado). [31]

El modo túnel admite la travesía NAT.

Algoritmos

Algoritmos de cifrado simétrico

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

Consulte RFC 8221 para obtener más detalles.

Algoritmos de intercambio de claves

Algoritmos de autenticación

Implementaciones

IPsec se puede implementar en la pila IP de un sistema operativo . Este método de implementación se realiza para hosts y gateways de seguridad. Varias pilas IP con capacidad IPsec están disponibles en empresas, como HP o IBM. [32] Una alternativa es la llamada implementación bump-in-the-stack (BITS), donde el código fuente del sistema operativo no tiene que ser modificado. Aquí IPsec se instala entre la pila IP y los controladores de red . De esta manera los sistemas operativos pueden ser modernizados con IPsec. Este método de implementación también se utiliza tanto para hosts como para gateways. Sin embargo, al modernizar IPsec, la encapsulación de paquetes IP puede causar problemas para el descubrimiento automático de la 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 gateway tiene un criptoprocesador separado , lo cual es común en el ejército y también se puede encontrar en sistemas comerciales, es posible una implementación llamada bump-in-the-wire (BITW) de IPsec. [33]

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

Se puede utilizar IPsec integrado para garantizar la comunicación segura entre aplicaciones que se ejecutan en sistemas con recursos limitados con una pequeña sobrecarga. [35]

Estado de las normas

IPsec se desarrolló en conjunto 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 la RFC 6434 lo convirtiera solo en una recomendación. [36] IPsec también es opcional para las implementaciones de IPv4 . IPsec se usa más comúnmente para proteger el tráfico de IPv4. [ cita requerida ]

Los protocolos IPsec se definieron originalmente en los documentos RFC 1825 a RFC 1829, que se publicaron en 1995. En 1998, estos documentos fueron reemplazados por los documentos RFC 2401 y RFC 2412 con algunos detalles de ingeniería incompatibles, aunque conceptualmente eran idénticos. Además, se definió un protocolo de autenticación mutua e intercambio de claves Internet Key Exchange (IKE) para crear y gestionar asociaciones de seguridad. En diciembre de 2005, se definieron nuevos estándares en los documentos RFC 4301 y RFC 4309 que son en gran medida un superconjunto de las ediciones anteriores con una segunda versión del estándar Internet Key Exchange IKEv2 . Estos documentos de tercera generación estandarizaron la abreviatura de IPsec a “IP” mayúscula y “sec” minúscula. “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 sobre mantenimiento y extensiones de IPsec (ipsecme) está activo en el IETF. [37] [38]

Presunta interferencia de la NSA

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

La pila IPsec de OpenBSD 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 canal lateral " en el código criptográfico de OpenBSD. En el correo electrónico reenviado de 2010, Theo de Raadt no expresó al principio una posición oficial sobre la validez de las afirmaciones, aparte del respaldo implícito al reenviar el correo electrónico. [41] La respuesta de Jason Wright a las acusaciones: "Toda leyenda urbana se vuelve más real con la inclusión de nombres reales, fechas y horas. El correo electrónico de Gregory Perry cae en esta categoría. ... Diré claramente que no añadí puertas traseras al sistema operativo OpenBSD ni al Marco criptográfico OpenBSD (OCF)". [42] Algunos días después, de Raadt comentó: "Creo que NETSEC probablemente fue contratado para escribir puertas traseras como se alega. … Si esas fueron escritas, no creo que hayan llegado a nuestro árbol". [43] Esto fue publicado antes de las filtraciones de Snowden.

Una explicación alternativa propuesta 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, [44] alegan que la NSA construyó especialmente un clúster de computación para precalcular subgrupos multiplicativos para primos y generadores específicos, como para el segundo grupo Oakley definido en RFC 2409. A partir de mayo de 2015, el 90% de las VPN IPsec direccionables admitían el segundo grupo Oakley 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 el Equation Group utilizó exploits de día cero contra equipos VPN de varios fabricantes que fueron validados por Kaspersky Lab como vinculados al Equation Group [45] y validados por esos fabricantes como exploits reales, algunos de los cuales eran exploits de día cero en el momento de su exposición. [46] [47] [48] Los firewalls Cisco PIX y ASA tenían vulnerabilidades que fueron utilizadas para escuchas telefónicas por la NSA [ cita requerida ] .

Además, las VPN IPsec que utilizan configuraciones de "Modo agresivo" envían un hash de la PSK sin cifrar. Esto puede ser, y aparentemente lo es, el objetivo de la NSA mediante ataques de diccionario fuera de línea . [44] [49] [50]

Véase también

Referencias

  1. ^ abc D. Harkins; R. Atkinson (noviembre de 1998). Carga útil de seguridad encapsulante IP (ESP). Grupo de trabajo de redes. doi : 10.17487/RFC2406 . RFC 2406. Obsoleto. Queda obsoleto por RFC 4303, 4305. Queda obsoleto RFC 1827.
  2. ^ Dhall, Hitesh; Dhall, Dolly; Batra, Sonia; Rani, Pooja (2012). "Implementación del protocolo IPSec". Segunda Conferencia Internacional sobre Tecnologías Avanzadas de Computación y Comunicación de 2012. IEEE . págs. 176–181. doi :10.1109/ACCT.2012.64. ISBN . 978-1-4673-0471-9.S2CID16526652  .​
  3. ^ Gilmore, John. «Cifrado de red: historia y patentes». Archivado desde el original el 3 de septiembre de 2014. Consultado el 18 de febrero de 2014 .
  4. ^ ab "Página de distribución IPv6 + IPSEC + ISAKMP". web.mit.edu .
  5. ^ "CONFERENCIA TÉCNICA ANUAL USENIX 1996". www.usenix.org .
  6. ^ "Protocolo de seguridad IP (ipsec) -". datatracker.ietf.org .
  7. ^ S. Kent ; K. Seo (diciembre de 2005). Arquitectura de seguridad para el protocolo de Internet. Grupo de trabajo de redes. doi : 10.17487/RFC4301 . RFC 4301. Norma propuesta. p. 4. Obsoleta la RFC 2401. Actualizada por las RFC 6040 y 7619. Se prefiere la ortografía "IPsec" y se utiliza en esta y todas las normas IPsec relacionadas. Todas las demás mayúsculas de IPsec [...] están obsoletas.
  8. ^ "Logros del NRL ITD: IPSec e IPv6" (PDF) . Laboratorios de Investigación Naval de EE. UU . Archivado (PDF) desde el original el 15 de septiembre de 2015.
  9. ^ S. Frankel; S. Krishnan (febrero de 2011). Hoja de ruta de documentos sobre seguridad IP (IPsec) e intercambio de claves por Internet (IKE). Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487/RFC6071 . ISSN  2070-1721. RFC 6071. Informativo. RFC 2411 obsoleto .
  10. ^ P. Hoffman (diciembre de 2005). Suites criptográficas para IPsec. Grupo de trabajo de redes. doi : 10.17487/RFC4308 . RFC 4308. Norma propuesta.
  11. ^ abcde S. Kent (diciembre de 2005). Encabezado de autenticación IP. Grupo de trabajo de redes. doi : 10.17487/RFC4302 . RFC 4302. Norma propuesta. Deja obsoleta la RFC 2402.
  12. ^ El intercambio de claves de Internet (IKE), RFC 2409, §1 Resumen
  13. ^ S. Kent ; D. Carrel (noviembre de 1998). El intercambio de claves de Internet (IKE). Grupo de trabajo de redes. doi : 10.17487/RFC2409 . RFC 2409. Obsoleto. Obsoleto por RFC 4306. Actualizado por RFC 4109.
  14. ^ C. Kaufman (diciembre de 2005). Protocolo de intercambio de claves de Internet (IKEv2). Grupo de trabajo de redes. doi : 10.17487/RFC4306 . RFC 4306. Obsoleto. Quedó obsoleto según RFC 5996. Actualizado por RFC 5282. Quedan obsoletos RFC 2407, 2409 y 2408.
  15. ^ S. Sakane; K. Kamada; M. Thomas; J. Vilhuber (marzo de 2006). Negociación de claves en Internet kerberizada (KINK). Grupo de trabajo de redes. doi : 10.17487/RFC4430 . RFC 4430. Norma propuesta.
  16. ^ ab M. Richardson (marzo de 2005). Un método para almacenar material de claves IPsec en DNS. Grupo de trabajo de redes. doi : 10.17487/RFC4025 . RFC 4025. Norma propuesta.
  17. ^ Peter Willis (2001). Redes IP a escala de operador: diseño y operación de redes de Internet . IET. pág. 270. ISBN 9780852969823.
  18. ^ R. Shirey (agosto de 2007). Glosario de seguridad en Internet, versión 2. Grupo de trabajo de redes. doi : 10.17487/RFC4949 . RFC 4949. Informativo. RFC 2828 obsoleto .
  19. ^ S. Kent (noviembre de 1991). Departamento de Defensa de los Estados Unidos - Opciones de seguridad para el protocolo de Internet. Grupo de trabajo de redes. doi : 10.17487/RFC1108 . RFC 1108. Histórico. Obsoleto RFC 1038.
  20. ^ ab "Números de protocolo". IANA . 2010-05-27. Archivado desde el original el 2010-05-29.
  21. ^ "SIPP Encapsulating Security Payload". Grupo de trabajo SIPP de la IETF. 1993. Archivado desde el original el 9 de septiembre de 2016. Consultado el 7 de agosto de 2013 .
  22. ^ Deering, Steve E. (1993). "Borrador de la especificación SIPP". IETF. pág. 21.
  23. ^ Bellovin, Steven M. (1996). "Áreas problemáticas para los protocolos de seguridad IP" ( PostScript ) . Actas del Sexto Simposio de Seguridad Unix de Usenix . San José, CA. págs. 1–16 . Consultado el 9 de julio de 2007 .
  24. ^ Paterson, Kenneth G.; Yau, Arnold KL (24 de abril de 2006). "Criptografía en teoría y práctica: el caso del cifrado en IPsec" (PDF) . Eurocrypt 2006, Lecture Notes in Computer Science Vol. 4004. Berlín. pp. 12–29 . Consultado el 13 de agosto de 2007 .
  25. ^ Degabriele, Jean Paul; Paterson, Kenneth G. (9 de agosto de 2007). "Ataque a los estándares IPsec en configuraciones de solo cifrado" (PDF) . Simposio IEEE sobre seguridad y privacidad, IEEE Computer Society . Oakland, CA. págs. 335–349 . Consultado el 13 de agosto de 2007 .
  26. ^ ab S. Kent (diciembre de 2005). Carga útil de seguridad encapsulada IP. Grupo de trabajo de redes. doi : 10.17487/RFC4303 . RFC 4303. Norma propuesta. Deja obsoleta la RFC 2406.
  27. ^ Peter Willis (2001). Redes IP a escala de operador: diseño y operación de redes de Internet . IET. pág. 271. ISBN 9780852969823.
  28. ^ Peter Willis (2001). Redes IP a escala de operador: diseño y operación de redes de Internet . IET. págs. 272-3. ISBN 9780852969823.
  29. ^ M. Thomas (junio de 2001). Requisitos para la negociación de claves en Internet mediante Kerberos. Grupo de trabajo de redes. doi : 10.17487/RFC3129 . RFC 3129. Informativo.
  30. ^ C. Cremers (2011). Intercambio de claves en IPsec revisitado: análisis formal de IKEv1 e IKEv2, ESORICS 2011. Apuntes de clase en informática. Springer. págs. 315–334. doi :10.1007/978-3-642-23822-2_18. hdl :20.500.11850/69608. ISBN . 9783642238222.ID S2C  18222662.
  31. ^ William, S., y Stallings, W. (2006). Criptografía y seguridad de redes, 4/E. Pearson Education India. págs. 492-493
  32. ^ Peter Willis (2001). Redes IP a escala de operador: diseño y operación de redes de Internet . IET. pág. 266. ISBN 9780852969823.
  33. ^ Peter Willis (2001). Redes IP a escala de operador: diseño y operación de redes de Internet . IET. pág. 267. ISBN 9780852969823.
  34. ^ RFC 2367, API de administración de claves PF_KEYv2 , Dan McDonald, Bao Phan y Craig Metz (julio de 1998)
  35. ^ Hamad, Mohammad; Prevelakis, Vassilis (2015). "Implementación y evaluación del rendimiento de IPsec integrado en sistemas operativos con micronúcleo". Simposio mundial sobre redes informáticas y seguridad de la información (WSCNIS) de 2015. IEEE. págs. 1–7. doi :10.1109/wscnis.2015.7368294. ISBN . 9781479999064.S2CID16935000  .​
  36. ^ RFC 6434, "Requisitos del nodo IPv6", E. Jankiewicz, J. Loughney, T. Narten (diciembre de 2011)
  37. ^ "carta ipsecme" . Consultado el 26 de octubre de 2015 .
  38. ^ "estado de ipsecme" . Consultado el 26 de octubre de 2015 .
  39. ^ "Documentos secretos revelan una campaña de la NSA contra el cifrado". New York Times .
  40. ^ John Gilmore. "Re: [Criptografía] Discusión inicial: especulación sobre "BULLRUN"".
  41. ^ Theo de Raadt. "Alegaciones sobre OpenBSD IPSEC".
  42. ^ Jason Wright. "Alegatos sobre IPSEC de OpenBSD".
  43. ^ Theo de Raadt. "Actualización sobre la acusación de puerta trasera IPSEC de OpenBSD".
  44. ^ ab Adrian, David; Bhargavan, Karthikeyan; Durumeric, Zakir; Gaudry, Pierrick; Green, Matthew; Halderman, J. Alex; Heninger, Nadia; Springall, Drew; Thomé, Emmanuel; Valenta, Luke; Vandersloot, Benjamin; Wustrow, Eric; Zanella-Béguelin, Santiago; Zimmermann, Paul (2015). "Secreto de reenvío imperfecto". Actas de la 22.ª Conferencia ACM SIGSAC sobre seguridad informática y de las comunicaciones . págs. 5–17. doi :10.1145/2810103.2813707. ISBN 9781450338325.S2CID347988  .​
  45. ^ Goodin, Dan (16 de agosto de 2016). "Confirmado: la filtración de una herramienta de piratería informática provino de un grupo "omnipotente" vinculado a la NSA". Ars Technica . Consultado el 19 de agosto de 2016 .
  46. ^ Thomson, Iain (17 de agosto de 2016). "Cisco confirma que dos de las vulnerabilidades 'NSA' de Shadow Brokers son reales". The Register . Consultado el 16 de septiembre de 2016 .
  47. ^ Pauli, Darren (24 de agosto de 2016). "Explotación de Equation Group afecta a los nuevos Cisco ASA y Juniper Netscreen". The Register . Consultado el 16 de septiembre de 2016 .
  48. ^ Chirgwin, Richard (18 de agosto de 2016). "Fortinet sigue a Cisco al confirmar la vulnerabilidad de Shadow Broker". The Register . Consultado el 16 de septiembre de 2016 .
  49. ^ "intercambio de claves: ¿Cuáles son los problemas del modo agresivo IKEv1 (en comparación con el modo principal IKEv1 o IKEv2)?". Cryptography Stack Exchange .
  50. ^ "No deje de usar IPsec todavía". No Hats . 29 de diciembre de 2014.

Lectura adicional

Pista de estándares

RFC experimentales

RFC informativos

RFC de mejores prácticas actuales

RFC obsoletos/históricos

Enlaces externos