Hispanopedia Wiki
Articulo de referencia

IPsec

En informática , el protocolo de seguridad de Internet ( IPsec ) es un conjunto de protocolos de red seguros que autentica y cifra los paquetes de datos para proporcionar una co...

Hispanopedia WikiContenido en espanolLectura gratuita

En informática , el protocolo de seguridad de Internet ( IPsec ) es un conjunto de protocolos de red seguros que autentica y cifra los paquetes de datos para proporcionar una comunicación segura y cifrada 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 la autenticación mutua entre agentes al inicio de una sesión y la negociación de claves criptográficas para usar durante la sesión. IPsec puede proteger los flujos de datos entre un par de hosts ( host-to-host ), entre un par de gateways de seguridad ( red-to-red ) o entre un gateway de seguridad y un host ( red-to-host ). [ 1 ] IPsec utiliza servicios de seguridad criptográfica para proteger las comunicaciones sobre redes de protocolo de Internet (IP). Admite la autenticación de pares a nivel de red, la autenticación del origen de los datos , la integridad de los datos , la confidencialidad de los datos ( cifrado ) y la protección contra ataques de repetición .

Historia

A principios de la década de 1970, la Agencia de Proyectos de Investigación Avanzada patrocinó una serie de dispositivos experimentales de cifrado ARPANET , inicialmente para el cifrado nativo de paquetes ARPANET y posteriormente para el cifrado de paquetes TCP/IP ; algunos de estos fueron certificados y desplegados. De 1986 a 1991, la NSA patrocinó el desarrollo de protocolos de seguridad para Internet bajo su programa de Sistemas de Red de Datos Seguros (SDNS). [ 2 ] Esto reunió a varios proveedores, entre ellos 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) se transformaría finalmente en el estándar ISO Protocolo de Seguridad de Capa de Red (NLSP). [ 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 las arquitecturas de CPU SPARC y x86. DARPA puso su implementación a disposición del público de forma gratuita a través del MIT. En el marco del proyecto de investigación financiado por DARPA , el NRL desarrolló las especificaciones de la vía de estándares 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 fue puesta 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 extensiones de seguridad especificadas abiertamente para IP, llamadas IPsec . [ 7 ] Los estándares desarrollados por el NRL fueron publicados por el IETF como RFC 1825 a RFC 1827. [ 8 ]

Arquitectura de seguridad

El conjunto inicial de protocolos IPv4 se desarrolló con pocas medidas de seguridad. Como parte de la mejora de IPv4, IPsec es un esquema de seguridad de extremo a extremo del modelo OSI de capa 3 o capa de Internet . En contraste, mientras que otros sistemas de seguridad de Internet ampliamente utilizados 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 del conjunto IPv4 y utiliza los siguientes protocolos para realizar diversas funciones: [ 9 ] [ 10 ]

Encabezado de autenticación

Uso del formato de encabezado de autenticación IPsec en los modos de 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 previo de estándares 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 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 , [ 17 ] [ 18 ] 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 tanto contra ataques de inserción de encabezados como contra ataques de inserción de opciones.
  • En IPv4 , el AH protege la carga útil IP y todos los campos de encabezado de un datagrama IP, excepto los campos mutables (es decir, aquellos que podrían alterarse en tránsito), y también las opciones IP como la Opción de Seguridad IP. [ 19 ] Los campos de encabezado IPv4 mutables (y por lo tanto no autenticados) son DSCP / ToS , ECN , Flags, Fragment Offset , TTL y Header Checksum . [ 11 ]
  • En IPv6 , el AH protege la mayor parte del encabezado base IPv6, el propio AH, los encabezados de extensión no mutables posteriores al AH y la carga útil IP. La protección del encabezado IPv6 excluye los campos mutables: DSCP , ECN , etiqueta de flujo y límite de saltos. [ 11 ]

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

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

Siguiente encabezado : 8 bits
Tipo del 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 la carga útil : 8 bits
La longitud de este encabezado de autenticación se mide 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, por lo que 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 (todo 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 (que se incrementa en 1 por cada paquete enviado) para prevenir ataques de repetición . Cuando la detección de repetición está habilitada, los números de secuencia nunca se reutilizan, ya que 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 a un límite de 4 octetos para IPv4 .

Carga útil de seguridad encapsulada

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

El IP Encapsulating Security Payload (ESP) [ 21 ] fue desarrollado en el Laboratorio de Investigación Naval a partir de 1992 como parte de un proyecto de investigación patrocinado por DARPA , y fue publicado abiertamente por el Grupo de Trabajo IETF SIPP [ 22 ] 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 finales de la década de 1980, pero fue diseñada por el proyecto Secure Data Network System del Departamento de Defensa de EE . UU . El Encapsulating Security Payload (ESP) es un miembro del conjunto de protocolos IPsec. Proporciona autenticidad de origen mediante autenticación de fuente , integridad de datos mediante funciones hash y confidencialidad mediante protección de cifrado para paquetes IP . ESP también admite configuraciones solo de cifrado y solo de autenticación , pero se desaconseja encarecidamente el uso de cifrado sin autenticación debido a su inseguridad. [ 23 ] [ 24 ] [ 25 ]

A diferencia del encabezado de autenticación (AH) , ESP en modo de transporte no proporciona integridad ni 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, la protección ESP se aplica 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 paquete 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 monótonamente (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 : variable
El contenido protegido del paquete IP original, incluidos los datos utilizados para protegerlo (por ejemplo, un vector de inicialización para el algoritmo criptográfico). El tipo de contenido protegido se indica en el campo Next Header .
Relleno : 0-255 octetos
Opcional. Relleno para el cifrado, para extender los datos de la carga útil a un tamaño que se ajuste al tamaño del bloque de cifrado y para alinear el siguiente campo.
Longitud de la almohadilla : 8 bits
Tamaño del relleno (en octetos).
Siguiente encabezado : 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 , por ejemplo, 6to4 . El valor 59 (que significa: Sin encabezado siguiente ) se utiliza para paquetes ficticios, que pueden insertarse en el flujo y cuyo contenido debe descartarse.
Valor de verificación de integridad  (VCI) : 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 a 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. De esta manera, IPsec ofrece diversas 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 utilizará para cifrar el paquete IP, por ejemplo , AES o ChaCha20 , y qué función hash se utilizará para garantizar la integridad de los datos, como BLAKE2 o SHA256 . Estos parámetros se acuerdan para la sesión en particular, para la cual 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 la transferencia de datos, e IPsec admite diversos métodos. La autenticación es posible mediante clave precompartida , donde ambos hosts ya poseen una clave simétrica y se envían mutuamente hashes de la clave compartida para demostrar que poseen 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 poseen un certificado de clave pública de una autoridad de certificación , este puede utilizarse para la autenticación IPsec. [ 28 ]

Las asociaciones de seguridad de IPsec se establecen mediante 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 la Seguridad Mejor Que Nada (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 determinar la protección que 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 la cabecera del paquete. En conjunto, estos elementos identifican de forma unívoca la asociación de seguridad para dicho paquete. Se realiza un procedimiento similar para los paquetes entrantes, donde IPsec obtiene las 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, la cual se duplica en todos los receptores autorizados del mismo. Un grupo puede tener más de una asociación de seguridad, utilizando diferentes SPI, lo que permite múltiples niveles y conjuntos de seguridad dentro del grupo. De hecho, cada remitente puede tener varias 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. Cabe señalar que el estándar pertinente no describe cómo se elige y duplica la asociación en todo el grupo; se asume que una parte responsable habrá tomado la decisión.

Manténganse vivos

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

La detección de pares inactivos (DPD, por sus siglas en inglés) es un método para detectar pares inactivos en el intercambio de claves de Internet (IKE). Este método utiliza patrones de tráfico IPsec para minimizar la cantidad de mensajes necesarios para confirmar la disponibilidad de un par. La DPD se utiliza para recuperar los recursos perdidos en caso de que se detecte un par inactivo y también para realizar la conmutación por error de pares IKE.

UDP keepalive es una alternativa a DPD.

Modos de funcionamiento

Los protocolos IPsec AH y ESP pueden implementarse tanto en modo de transporte de host a host como en modo de tunelización de red.

Modos IPsec

Modo de transporte

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

Los documentos RFC que describen el mecanismo NAT-T definen un método para encapsular mensajes IPsec para la traducción de direcciones de red (NAT-T).

Modo túnel

En el modo túnel, todo el paquete IP se cifra y autentica. Luego se encapsula en un nuevo paquete IP con una nueva cabecera IP. El modo túnel se utiliza para crear redes privadas virtuales para comunicaciones de red a red (por ejemplo, entre enrutadores para conectar sitios), comunicaciones de host a red (por ejemplo, acceso remoto de usuarios) y comunicaciones de host a host (por ejemplo, chat privado). [ 31 ]

El modo túnel admite el recorrido NAT.

Algoritmos

Algoritmos de cifrado simétrico

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

Consulte el RFC 8221 para obtener más detalles.

Algoritmos de intercambio de claves

Algoritmos de autenticación

  • RSA
  • ECDSA (RFC 4754)
  • PSK (RFC 6617)
  • EdDSA (RFC 8420)
  • ML-DSA y SLH-DSA (borrador-ietf-ipsecme-ikev2-pqc-auth)

Implementaciones

IPsec se puede implementar en la pila IP de un sistema operativo . Este método de implementación se utiliza para hosts y gateways de seguridad. Varias empresas, como HP o IBM, ofrecen pilas IP compatibles con IPsec. [ 32 ] Una alternativa es la implementación denominada bump-in-the-stack (BITS), en la que no es necesario modificar el código fuente del sistema operativo. En este caso, IPsec se instala entre la pila 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 utiliza para hosts y gateways. Sin embargo, al actualizar IPsec, la encapsulación de paquetes IP puede causar problemas para el descubrimiento automático de la MTU de la 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 dispone de un criptoprocesador independiente , común en el ámbito militar y también presente en sistemas comerciales, es posible una implementación denominada bump-in-the-wire (BITW) de IPsec. [ 33 ]

Cuando IPsec se implementa en el kernel , 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 por NRL y especificada abiertamente, 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 en la implementación IPsec del espacio del kernel. [ 34 ] Las implementaciones IPsec existentes suelen incluir ESP, AH e IKE versión 2. Las implementaciones IPsec existentes en sistemas operativos tipo Unix , por ejemplo, Solaris o Linux , suelen incluir PF_KEY versión 2.

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

Estado de los estándares

IPsec se desarrolló junto con IPv6 y, originalmente, su compatibilidad era obligatoria para todas las implementaciones de IPv6 que cumplieran con los estándares, hasta que el RFC 6434 la convirtió en una recomendación. [ 36 ] IPsec también es opcional para las implementaciones de IPv4 . Su uso más común es para proteger el tráfico IPv4.

Los protocolos IPsec se definieron originalmente en los RFC 1825 a 1829, publicados en 1995. En 1998, estos documentos fueron reemplazados por los RFC 2401 y 2412, que presentaban algunos detalles técnicos incompatibles, aunque conceptualmente eran idénticos. Además, se definió el protocolo de autenticación mutua e intercambio de claves (IKE) para crear y gestionar asociaciones de seguridad. En diciembre de 2005, se definieron nuevos estándares en los RFC 4301 y 4309, que constituyen en gran medida un superconjunto de las ediciones anteriores, incluyendo una segunda versión del estándar IKEv2 . Estos documentos de tercera generación estandarizaron la abreviatura de IPsec a "IP" en mayúsculas y "sec" en minúsculas. "ESP" generalmente se refiere al RFC 4303, 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. [ 37 ] [ 38 ]

Supuesta 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 de cifrado comerciales, sistemas de TI, redes y dispositivos de comunicación de punto final utilizados por los objetivos" como parte del programa Bullrun . [ 39 ] Existen alegaciones de que IPsec era un sistema de cifrado objetivo. [ 40 ]

La pila IPsec de OpenBSD surgió 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 "varias puertas traseras y mecanismos de filtración de claves a través de canales laterales " en el código criptográfico de OpenBSD. En el correo electrónico reenviado de 2010, Theo de Raadt no expresó inicialmente 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 al incluir nombres, fechas y horas reales. El correo electrónico de Gregory Perry entra en esta categoría. ... Declararé claramente que no agregué puertas traseras al sistema operativo OpenBSD ni al Marco Criptográfico de OpenBSD (OCF)". [ 42 ] Unos días después, de Raadt comentó que «Creo que NETSEC probablemente fue contratada para escribir puertas traseras como se alega. ... Si se escribieron, no creo que hayan llegado a nuestro árbol». [ 43 ] Esto se publicó 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 debilitar el algoritmo Diffie-Hellman utilizado en el intercambio de claves. En su artículo, [ 44 ] alegan que la NSA construyó un clúster de computación específico para precalcular subgrupos multiplicativos para números primos y generadores específicos, como el segundo grupo Oakley definido en RFC 2409. En 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 intercambiadas y descifrar el tráfico sin insertar puertas traseras de software.

Una segunda explicación alternativa que se propuso fue que el Grupo Equation utilizó exploits de día cero contra equipos VPN de varios fabricantes que fueron validados por Kaspersky Lab como vinculados al Grupo Equation [ 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 interceptar comunicaciones por la NSA [ 49 ] .

Además, las VPN IPsec que utilizan la configuración de "Modo agresivo" envían un hash de la PSK en texto plano. Esto puede ser, y aparentemente es, objetivo de la NSA mediante ataques de diccionario sin conexión . [ 44 ] [ 50 ] [ 51 ]

Véase también

Referencias

  1. 1 2 3 D. Harkins; R. Atkinson (noviembre de 1998). Carga útil de seguridad encapsulada IP (ESP) . Grupo de trabajo de redes. doi : 10.17487/RFC2406 . RFC 2406 .Obsoleto. Obsoleto según RFC 4303 , 4305. Obsoleto según RFC 1827 .  
  2. ↑ Dhall, Hitesh; Dhall, Dolly; Batra, Sonia; Rani, Pooja (2012). "Implementación del protocolo IPSec". Segunda Conferencia Internacional de 2012 sobre Tecnologías Avanzadas de Computación y Comunicación . IEEE . págs. 176–181 . doi : 10.1109/ACCT.2012.64 . ISBN  978-1-4673-0471-9. S2CID 16526652 . 
  3. ↑ Gilmore, John. "Cifrado de red: historia y patentes" . Archivado del original el 3 de septiembre de 2014. Consultado el 18 de febrero de 2014 .
  4. ^ " Página de distribución IPv6 + IPSEC + ISAKMP" . web.mit.edu .
  5. ↑ "CONFERENCIA TÉCNICA ANUAL DE 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 .Estándar propuesto. pág. 4. Sustituye a RFC 2401. Actualizado por RFC 6040 y 7619. Se prefiere la grafía "IPsec" y se utiliza en este y en todos los estándares IPsec relacionados. Se desaconseja el uso de cualquier otra grafía de IPsec [...].  
  8. ↑ "Logros del NRL ITD: IPSec e IPv6" (PDF) . Laboratorios de Investigación Naval de EE . UU. Archivado del original (PDF) 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 de Internet (IKE) . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6071 . ISSN 2070-1721 . RFC 6071 . Informativo. Sustituye a RFC 2411 . 
  10. ↑ P. Hoffman (diciembre de 2005). Conjuntos criptográficos para IPsec . Grupo de trabajo de redes. doi : 10.17487/RFC4308 . RFC 4308 .Norma propuesta.
  11. 1 2 3 4 5 S. Kent (diciembre de 2005). Encabezado de autenticación IP . Grupo de trabajo de redes. doi : 10.17487/RFC4302 . RFC 4302 .Norma propuesta. Sustituye a 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 según RFC 4306. Actualizado según 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. Obsoleto según RFC 5996. Actualizado por RFC 5282. Deja obsoletos los RFC 2407 , 2409 y 2408 .   
  15. ↑ S. Sakane; K. Kamada; M. Thomas; J. Vilhuber (marzo de 2006). Negociación de claves de Internet kerberizada (KINK) . Grupo de trabajo de redes. doi : 10.17487/RFC4430 . RFC 4430 .Norma propuesta.
  16. 1 2 M. Richardson (marzo de 2005). Un método para almacenar material de clave 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 de Internet, versión 2. Grupo de trabajo de redes. doi : 10.17487/RFC4949 . RFC 4949 .Informativo. Sustituye a RFC 2828 . 
  19. ↑ S. Kent (noviembre de 1991). Departamento de Defensa de EE. UU. - 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. 1 2 "Números de protocolo" . IANA . 27 de mayo de 2010. Archivado del original el 29 de mayo de 2010.
  21. ↑ "SIPP Encapsulating Security Payload" . Grupo de trabajo SIPP de la IETF. 1993. Archivado del original el 9 de septiembre de 2016. Consultado el 7 de agosto de 2013 .
  22. ↑ Deering, Steve E. (1993). "Especificación preliminar 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 . Recuperado 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 . Recuperado el 13 de agosto de 2007 . 
  25. ↑ Degabriele, Jean Paul; Paterson, Kenneth G. (2007-08-09). "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 . Recuperado el 13 de agosto de 2007 . 
  26. 1 2 S. Kent (diciembre de 2005). Carga útil de seguridad encapsulada IP . Grupo de trabajo de redes. doi : 10.17487/RFC4303 . RFC 4303 .Norma propuesta. Sustituye a 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–273 . ISBN  9780852969823.
  29. ↑ M. Thomas (junio de 2001). Requisitos para la negociación de claves de Internet con Kerberos . Grupo de trabajo de redes. doi : 10.17487/RFC3129 . RFC 3129 .Informativo.
  30. ↑ C. Cremers (2011). "Intercambio de claves en IPsec revisado: análisis formal de IKEv1 e IKEv2" . Intercambio de claves en IPsec revisado: análisis formal de IKEv1 e IKEv2, ESORICS 2011. Lecture Notes in Computer Science. Vol. 6879. Springer. pp. 315–334 . doi : 10.1007/978-3-642-23822-2_18 . hdl : 20.500.11850/69608 . ISBN   9783642238222. S2CID 18222662 . 
  31. ↑ William, S., & Stallings, W. (2006). Criptografía y seguridad de redes, 4.ª ed. 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 un sistema operativo de microkernel". Simposio Mundial de 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. S2CID 16935000 . 
  36. ↑ E. Jankiewicz; J. Loughney; T. Narten (diciembre de 2011). Requisitos de nodo IPv6 . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6434 . ISSN 2070-1721 . RFC 6434 . Obsoleto. Obsoleto según RFC 8504. Obsoleto según RFC 4294 .  
  37. ↑ "estatutos de ipsecme" . Consultado el 26 de octubre de 2015 .
  38. ↑ "estado de ipsecme" . Consultado el 26 de octubre de 2015 .
  39. ↑ "Documentos secretos revelan la 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. "Acusaciones sobre OpenBSD IPSEC" .
  42. ↑ Jason Wright. "Acusaciones sobre la seguridad IPsec de OpenBSD" .
  43. ↑ Theo de Raadt (22 de diciembre de 2010). "Actualización sobre la acusación de puerta trasera IPSEC de OpenBSD" .
  44. 1 2 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). "Imperfect Forward Secrecy" . 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. S2CID 347988 . 
  45. ↑ Goodin, Dan (16 de agosto de 2016). "Confirmado: la filtración de la herramienta de pirateo 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). "Exploit 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 los pasos de Cisco al confirmar la vulnerabilidad de Shadow Broker" . The Register . Consultado el 16 de septiembre de 2016 .
  49. ↑ "Lo que sabemos sobre los exploits filtrados en el hackeo vinculado a la NSA" . Vice Media. 2016. Archivado del original el 21 de junio de 2023. Consultado el 22 de abril de 2026 .
  50. ↑ "Intercambio de claves: ¿Cuáles son los problemas del modo agresivo de IKEv1 (en comparación con el modo principal de IKEv1 o IKEv2)?" . Cryptography Stack Exchange .
  51. ↑ "No dejes de usar IPsec todavía" . No Hats . 29 de diciembre de 2014.

Lecturas adicionales

Vía de estándares

  • RFC 1829 : La transformación ESP DES-CBC 
  • RFC 2403 : Uso de HMAC-MD5-96 en 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 en modo CBC de ESP 
  • RFC 2857 : Uso de HMAC-RIPEMD-160-96 en ESP y AH 
  • RFC 3526 : Más grupos Diffie-Hellman exponenciales modulares (MODP) para el intercambio de claves de Internet (IKE) 
  • RFC 3602 : El algoritmo de cifrado AES-CBC y su uso con IPsec. 
  • RFC 3686 : Uso del modo contador del estándar de cifrado avanzado (AES) con la carga útil de seguridad encapsulada (ESP) de IPsec. 
  • RFC 3947 : Negociación de NAT-Traversal en IKE 
  • RFC 3948 : Encapsulación UDP de paquetes IPsec ESP 
  • RFC 4106 : Uso del modo Galois/Contador (GCM) en la encapsulación de la carga útil de seguridad (ESP) de IPsec 
  • RFC 4301 : Arquitectura de seguridad para el protocolo de Internet 
  • RFC 4302 : Encabezado de autenticación IP 
  • RFC 4303 : Carga útil de seguridad de encapsulación IP 
  • RFC 4304 : Adenda del número de secuencia extendido (ESN) al dominio de interpretación (DOI) de IPsec para el protocolo de administración de claves y asociación de seguridad de Internet (ISAKMP) 
  • RFC 4307 : Algoritmos criptográficos para su uso en el Intercambio de Claves de Internet versión 2 ( IKEv2 ) 
  • RFC 4308 : Conjuntos criptográficos para IPsec 
  • RFC 4309 : Uso del modo CCM del Estándar de Cifrado Avanzado (AES) con la Carga Útil de Seguridad Encapsulada (ESP) de IPsec 
  • RFC 4543 : Uso del código de autenticación de mensajes de Galois (GMAC) en IPsec ESP y AH 
  • RFC 4555 : Protocolo de movilidad y multiconexión 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 : 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 de intercambio de claves de Internet versión 2 (IKEv2). 
  • RFC 5386 : Seguridad mejor que nada: un modo no autenticado de IPsec 
  • RFC 5529 : Modos de funcionamiento de Camellia para su uso con IPsec. 
  • RFC 5685 : Mecanismo de redirección para el protocolo de intercambio de claves de Internet versión 2 (IKEv2) 
  • RFC 5723 : Reanudación de sesión del Protocolo de Intercambio de Claves de Internet versión 2 (IKEv2) 
  • RFC 5857 : Extensiones de IKEv2 para admitir una compresión de encabezados robusta sobre IPsec. 
  • RFC 5858 : Extensiones de IPsec para admitir una compresión de encabezados robusta 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 la encapsulación de 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 el Intercambio de Claves de Internet 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 : Autenticación repetida en el protocolo de 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 IPsec con la traducción de direcciones de red (NAT) 
  • RFC 4621 : Diseño del protocolo IKEv2 de movilidad y multiconexión (MOBIKE) 
  • RFC 4809 : Requisitos para un perfil de gestión de certificados IPsec 
  • RFC 5387 : Declaración del problema y aplicabilidad de la seguridad mejor que nada (BTNS) 
  • RFC 5856 : Integración de compresión de encabezados robusta sobre asociaciones de seguridad IPsec 
  • RFC 5930 : Uso del modo de contador del estándar de cifrado avanzado (AES-CTR) con el protocolo de intercambio de claves de Internet versión 02 (IKEv2). 
  • RFC 6027 : Declaración del problema del clúster IPsec 
  • RFC 6071 : Hoja de ruta de la documentación de IPsec e IKE 
  • RFC 6379 : Conjunto B de conjuntos criptográficos para IPsec 
  • RFC 6380 : Perfil Suite B para la seguridad del 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 encapsulada IP (ESP) (obsoleta por RFC 2406) 
  • RFC 1828 : Autenticación IP mediante MD5 con clave (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 encapsulada 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 la encapsulación de 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 y directrices de implementación de IKEv2 (obsoleto por RFC 7296) 
  • RFC 4835 : Requisitos de implementación de algoritmos criptográficos para la encapsulación de 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) 
  • Todos los grupos de trabajo activos sobre seguridad del IETF
    • Grupo de trabajo ipsecme de la IETF ("Grupo de trabajo de mantenimiento y extensiones de seguridad IP")
    • Grupo de trabajo IETF btns («Grupo de trabajo de seguridad "Mejor que nada") (encargado de trabajar en IPsec sin autenticación, API de IPsec y bloqueo de conexiones)]
  • Protección de datos en tránsito con IPsec. Archivado el 13/10/2008 en Wayback Machine. Artículo de WindowsSecurity.com por Deb Shinder.
  • IPsec en Microsoft TechNet
    • Herramienta de diagnóstico IPsec de Microsoft en el Centro de descargas de Microsoft
  • Guía ilustrada de IPsec por Steve Friedl
  • Arquitectura de seguridad para comunicaciones de datos IP (IPsec). Conferencias impartidas por Manfred Lindner. Parte IPsec.
  • Creación de VPN con IPsec y SSL/TLS. Artículo de la revista Linux Journal de Rami Rosen.
Lecturas relacionadas
6 articulos
Simulación por computadoraComputaciónLa informática es cualquier actividad orientada a objetivos que requiera, se beneficie o cree maquinaria informática . [1] Incluye el estudio y la ...AutenticaciónAutenticaciónUsuario del cajero automático autenticándose La autenticación (del griego αὐθεντικός authentikos , "real, genuino", de αὐθέντης authentes , "autor"...El texto se convierte en un sinsentido y luego se vuelve a convertir al original.EncriptaciónEn criptografía , el cifrado es el proceso de transformar (más específicamente, codificar ) información de manera que, idealmente, solo las partes ...Paquete de redPaquete de redEn telecomunicaciones y redes informáticas , un paquete de red es una unidad formateada de datos transportados por una red de conmutación de paquet...Protocolo de InternetProtocolo de InternetEl Protocolo de Internet ( IP ) es el protocolo de comunicaciones de la capa de red del conjunto de protocolos de Internet para transmitir datagram...Virtual private networkVirtual private network ( VPN ) is a network architecture for virtually extending a private network (i.e. any computer network which is not the pub...