Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Conceptos básicos de IPsec

Descripción general de IPsec

IPsec es un conjunto de protocolos relacionados para proteger criptográficamente las comunicaciones en la capa de paquetes IP. IPsec también proporciona métodos para la negociación manual y automática de asociaciones de seguridad (SA) y distribución de claves, todos los atributos para los cuales se recopilan en un dominio de interpretación (DOI). El DOI de IPsec es un documento que contiene definiciones de todos los parámetros de seguridad necesarios para la negociación exitosa de un túnel VPN; básicamente, todos los atributos necesarios para las negociaciones de SA e IKE. Consulte RFC 2407 y RFC 2408 para obtener más información.

Para usar los servicios de seguridad de IPsec, cree SA entre hosts. Una SA es una conexión simplex que permite que dos hosts se comuniquen entre sí de manera segura mediante IPsec. Hay dos tipos de SA: manuales y dinámicos.

IPsec admite dos modos de seguridad (modo de transporte y modo de túnel).

Asociaciones de seguridad

Una asociación de seguridad (SA) es un acuerdo unidireccional entre los participantes de la VPN con respecto a los métodos y parámetros que se deben usar para proteger un canal de comunicación. La comunicación bidireccional completa requiere al menos dos SA, una para cada dirección. Mediante la SA, un túnel IPsec puede proporcionar las siguientes funciones de seguridad:

  • Privacidad (mediante cifrado)

  • Integridad de contenido (mediante autenticación de datos)

  • Autenticación de remitente y,si utiliza certificados, no rechazo (mediante autenticación de origen de datos)

Las funciones de seguridad que emplee dependen de sus necesidades. Si solo necesita autenticar el origen del paquete IP y la integridad del contenido, puede autenticarlo sin aplicar ningún cifrado. Por otro lado, si solo le preocupa conservar la privacidad, puede cifrar el paquete sin aplicar ningún mecanismo de autenticación. Opcionalmente, puede cifrar y autenticar el paquete. La mayoría de los diseñadores de seguridad de red eligen cifrar, autenticar y volver a proteger su tráfico VPN.

Un túnel IPsec consta de un par de SA unidireccionales (una SA para cada dirección del túnel) que especifican el índice de parámetros de seguridad (SPI), la dirección IP de destino y el protocolo de seguridad (encabezado de autenticación [AH] o carga de seguridad de encapsulación [ESP] empleados. Una SA agrupa los siguientes componentes para proteger las comunicaciones:

  • Claves y algoritmos de seguridad.

  • Modo de protocolo, ya sea de transporte o túnel. Los dispositivos Junos OS siempre usan el modo de túnel. (Consulte Procesamiento de paquetes en modo de túnel.)

  • Método de administración de claves, ya sea clave manual o IKE de clave automática.

  • Vida útil de SA.

Para el tráfico entrante, Junos OS busca la SA mediante el siguiente triplete:

  • Dirección IP de destino.

  • Protocolo de seguridad, ya sea AH o ESP.

  • Valor del índice de parámetros de seguridad (SPI).

Para el tráfico vpn saliente, la política invoca la SA asociada con el túnel VPN.

Administración de claves IPsec

La distribución y la administración de claves son fundamentales para usar correctamente las VPN. Junos OS admite la tecnología IPsec para crear túneles VPN con tres tipos de mecanismos de creación de claves:

  • Clave manual

  • IKE de clave automática con una clave previamente compartida o un certificado

Puede elegir el mecanismo de creación de claves (también llamado método de autenticación) durante la configuración de la propuesta de fase 1 y fase 2. Consulte Intercambio de claves por internet.

Este tema incluye las siguientes secciones:

Clave manual

Con las claves manuales, los administradores en ambos extremos de un túnel configuran todos los parámetros de seguridad. Esta es una técnica viable para redes pequeñas y estáticas en las que la distribución, el mantenimiento y el seguimiento de claves no son difíciles. Sin embargo, la distribución segura de configuraciones de clave manual a grandes distancias plantea problemas de seguridad. Además de pasar las claves en persona, no puede estar completamente seguro de que las claves no se hayan visto comprometidas durante el tránsito. Además, siempre que desee cambiar la clave, se enfrenta a los mismos problemas de seguridad que cuando la distribuyó inicialmente.

IKE de clave automática

Cuando necesite crear y administrar numerosos túneles, necesitará un método que no requiera configurar cada elemento manualmente. IPsec admite la generación y negociación automatizadas de claves y asociaciones de seguridad mediante el protocolo de intercambio de claves por internet (IKE). Junos OS se refiere a la negociación de túnel automatizada como IKE de clave automática y admite IKE de clave automática con claves previamente compartidas e ICR de clave automática con certificados.

  • IKE de clave automática con claves previamente compartidas: mediante el uso de IKE de clave automática con claves previamente compartidas para autenticar a los participantes en una sesión de IKE, cada lado debe configurar e intercambiar de forma segura la clave previamente compartida. En este sentido, el problema de la distribución de claves seguras es el mismo que el de las claves manuales. Sin embargo, una vez distribuida, una clave automática, a diferencia de una clave manual, puede cambiar automáticamente sus claves a intervalos predeterminados mediante el protocolo IKE. Cambiar las claves con frecuencia mejora en gran medida la seguridad, y hacerlo automáticamente reduce en gran medida las responsabilidades de administración de claves. Sin embargo, cambiar claves aumenta la sobrecarga de tráfico; por lo tanto, cambiar claves con demasiada frecuencia puede reducir la eficiencia de la transmisión de datos.

    Una clave previamente compartida es una clave tanto para el cifrado como para el descifrado, que ambos participantes deben tener antes de iniciar la comunicación.

  • IKE de clave automática con certificados: cuando se usan certificados para autenticar a los participantes durante una negociación de IKE de clave automática, cada lado genera un par de claves públicas y privadas y adquiere un certificado. Siempre que la autoridad de certificación (CA) emisora sea de confianza para ambos lados, los participantes pueden recuperar la clave pública del par y verificar la firma del par. No es necesario realizar un seguimiento de las claves y las SA; IKE lo hace automáticamente.

Intercambio Diffie-Hellman

Un intercambio Diffie-Hellman (DH) permite a los participantes producir un valor secreto compartido. La fuerza de la técnica es que permite a los participantes crear el valor secreto en un medio no seguro sin pasar el valor secreto a través del cable. El tamaño del módulo principal utilizado en el cálculo de cada grupo difiere según se muestra en la tabla siguiente. Las operaciones de intercambio Diffie Hellman (DH) se pueden realizar en software o hardware. Cuando estas operaciones de intercambio se realizan en hardware, utilizamos la criptografía de la tecnología QuickAssist (QAT). A continuación Tabla 1 , se enumeran diferentes grupos Diffie Hellman (DH) y se especifica si la operación realizada para ese grupo se encuentra en el hardware o en el software.

Tabla 1: Los grupos Diffie Hellman (DH) y sus operaciones de intercambio se realizaron

Grupo Diffie-Hellman (DH)

Tamaño del módulo principal

Grupo 1 de DH

768-bit

Grupo DH 2

102-bit

Grupo DH 5

1536-bit

Grupo DH 14

2048-bit

Grupo DH 15

3072-bit

Grupo DH 16

4096-bit

Grupo DH 19

Curva elíptica de 256 bits

Grupo DH 20

Curva elíptica de 384 bits

Grupo DH 21

Curva elíptica de 521 bits

Grupo DH 24

2048 bits con subgrupo de orden principal de 256 bits

A partir de la versión 19.1R1 de Junos OS, los firewalls serie SRX admiten los grupos DH 15, 16 y 21.

A partir de Junos OS versión 20.3R1, las instancias del firewall virtual vSRX con el paquete junos-ike instalado admiten los grupos DH 15, 16 y 21.

No recomendamos el uso de los grupos DH 1, 2 y 5.

Dado que el módulo para cada grupo DH tiene un tamaño diferente, los participantes deben aceptar usar el mismo grupo.

Protocolos de seguridad IPsec

IPsec utiliza dos protocolos para proteger las comunicaciones en la capa IP:

  • Encabezado de autenticación (AH): un protocolo de seguridad para autenticar el origen de un paquete IP y verificar la integridad de su contenido

  • Carga de seguridad de encapsulación (ESP): un protocolo de seguridad para cifrar todo el paquete IP (y autenticar su contenido)

Puede elegir sus protocolos de seguridad (también denominados authentication and encryption algorithms) durante la configuración de la propuesta de fase 2. Consulte Intercambio de claves por internet.

Para cada túnel VPN, se instalan sesiones de túnel AH y ESP en unidades de procesamiento de servicios (SPU) y el plano de control. Las sesiones de túnel se actualizan con el protocolo negociado después de completar la negociación. Para los dispositivos SRX5400, SRX5600 y SRX5800, las sesiones de túnel en SPU de anclaje se actualizan con el protocolo negociado, mientras que las SPU sin anclaje conservan sesiones de túnel ESP y AH. Las sesiones de túnel ESP y AH se muestran en los resultados de los comandos de show security flow session modo operativo y show security flow cp-session .

Este tema incluye las siguientes secciones:

Algoritmos de autenticación IPsec (protocolo AH)

El protocolo encabezado de autenticación (AH) proporciona un medio para verificar la autenticidad e integridad del contenido y el origen de un paquete. Puede autenticar el paquete mediante la suma de comprobación calculada a través de un código de autenticación de mensaje hash (HMAC) mediante una clave secreta y funciones hash MD5 o SHA.

  • Síntesis de mensaje 5 (MD5): un algoritmo que produce un hash de 128 bits (también llamado firma digital o síntesis de mensaje) a partir de un mensaje de longitud arbitraria y una clave de 16 bytes. El hash resultante se utiliza, como una huella digital de la entrada, para verificar la autenticidad e integridad del contenido y del origen.

  • Algoritmo de hash seguro (SHA): es un algoritmo que produce un hash de 160 bits a partir de un mensaje de longitud arbitraria y una clave de 20 bytes. Generalmente se considera más seguro que MD5 debido a los hashes más grandes que produce. Dado que el procesamiento computacional se realiza en el ASIC, el costo de rendimiento es insignificante.

Para obtener más información sobre los algoritmos hash MD5, consulte RFC 1321 y RFC 2403. Para obtener más información sobre los algoritmos hash SHA, consulte RFC 2404. Para obtener más información sobre HMAC, consulte RFC 2104.

Algoritmos de cifrado IPsec (protocolo ESP)

El protocolo carga de seguridad de encapsulación (ESP) proporciona un medio para garantizar la privacidad (cifrado) y la autenticación de origen e integridad del contenido (autenticación). ESP en modo de túnel encapsula todo el paquete IP (encabezado y carga) y, luego, anexa un nuevo encabezado IP al paquete ahora cifrado. Este nuevo encabezado IP contiene la dirección de destino necesaria para enrutar los datos protegidos a través de la red. (Consulte Procesamiento de paquetes en modo de túnel.)

Con ESP, puede cifrar y autenticar, cifrar solo o solo autenticar. Para el cifrado, puede elegir uno de los siguientes algoritmos de cifrado:

  • Estándar de cifrado de datos (DES): un algoritmo de bloque criptográfico con una clave de 56 bits.

  • Triple DES (3DES): una versión más potente de DES en la que el algoritmo DES original se aplica en tres rondas, usando una clave de 168 bits. El DES ofrece ahorros de rendimiento significativos, pero se considera inaceptable para muchas transferencias de material clasificadas o sensibles.

  • Estándar de cifrado avanzado (AES): un estándar de cifrado que ofrece una mayor interoperabilidad con otros dispositivos. Junos OS admite AES con claves de 128 bits, 192 bits y 256 bits.

Para la autenticación, puede usar algoritmos MD5 o SHA.

Aunque es posible seleccionar NULL para el cifrado, se ha demostrado que IPsec podría ser vulnerable a ataques en tales circunstancias. Por lo tanto, le sugerimos que elija un algoritmo de cifrado para la máxima seguridad.

Negociación de túnel IPsec

Los siguientes dos modos diferentes que determinan cómo se intercambia el tráfico en la VPN.

  • Modo de túnel: proteja el tráfico mediante la encapsulación del paquete IP original dentro de otro paquete en el túnel VPN. Este modo usa claves previamente compartidas con IKE para autenticar pares o certificados digitales con IKE para autenticar pares. Esto se usa con mayor frecuencia cuando los hosts dentro de redes privadas separadas desean comunicarse a través de una red pública. Este modo puede ser utilizado tanto por los clientes VPN como por las puertas de enlace VPN, y protege las comunicaciones que vienen o van a sistemas que no son IPsec.

  • Modo de transporte: proteja el tráfico mediante el envío del paquete directamente entre los dos hosts que han establecido el túnel IPsec. Es decir, cuando el punto de conexión de comunicación y el punto de conexión criptográfico son los mismos. La parte de datos del paquete IP está cifrada, pero el encabezado IP no lo es. Las puertas de enlace VPN que proporcionan servicios de cifrado y descifrado para hosts protegidos no pueden usar el modo de transporte para comunicaciones VPN protegidas. Las direcciones IP del origen o destino se pueden modificar si se intercepta el paquete. Debido a su construcción, el modo de transporte solo se puede usar cuando el punto de conexión de comunicación y el punto de conexión criptográfico son los mismos.

Estándares IPsec e IKE compatibles

En enrutadores equipados con una o más MS-MPC, MS-MIC o DPC, la versión de Junos OS para Canadá y Ee. UU. admite sustancialmente las siguientes RFC, que definen estándares para la seguridad IP (IPsec) y el intercambio de claves por internet (IKE).

  • Autenticación IP HMAC-MD5 de RFC 2085 con prevención de reproducción

  • RFC 2401, Arquitectura de seguridad para el protocolo de Internet (obsoleto por RFC 4301)

  • RFC 2402, Encabezado de autenticación IP (reemplazado por RFC 4302)

  • 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 (obsoleto por RFC 4305)

  • RFC 2405, el algoritmo de cifrado ESP DES-CBC con IV explícito

  • RFC 2406, Carga de seguridad de encapsulación (ESP) de IP (obsoleta por RFC 4303 y RFC 4305)

  • RFC 2407, El dominio de interpretación de la seguridad de IP de Internet para ISAKMP (reemplazado por RFC 4306)

  • RFC 2408, Protocolo de administración de claves y asociación de seguridad de Internet (ISAKMP) (reemplazado por RFC 4306)

  • RFC 2409, El intercambio de claves por internet (IKE) (obsoleto por RFC 4306)

  • RFC 2410, el algoritmo de cifrado NULL y su uso con IPsec

  • RFC 2451, Los algoritmos de cifrado esp en modo CBC

  • RFC 2560, Infraestructura de clave pública de Internet X.509 Protocolo de estado de certificado en línea - OCSP

  • RFC 3193, Protección de L2TP mediante IPsec

  • RFC 3280, Perfil de lista de revocación de certificados (CRL) y certificado de infraestructura de clave pública X.509 de Internet

  • RFC 3602, El algoritmo de cifrado AES-CBC y su uso con IPsec

  • RFC 3948, Encapsulación UDP de paquetes ESP IPsec

  • RFC 4106, El uso del modo galois/contador (GCM) en la carga de seguridad de encapsulación (ESP) de IPsec

  • RFC 4210, Protocolo de administración de certificados (CMP) en infraestructura de clave pública X.509 de Internet

  • RFC 4211, Formato de mensaje de solicitud de certificado (CRMF) en infraestructura de clave pública X.509 de Internet

  • RFC 4301, Arquitectura de seguridad para el protocolo de Internet

  • RFC 4302, Encabezado de autenticación IP

  • RFC 4303, Carga de seguridad de encapsulación (ESP) de IP

  • RFC 4305, Requisitos de implementación de algoritmo criptográfico para carga de seguridad de encapsulación (ESP) y encabezado de autenticación (AH)

  • RFC 4306, Protocolo de intercambio de claves por internet (IKEv2)

  • RFC 4307, Algoritmos criptográficos para uso en el intercambio de claves por internet versión 2 (IKEv2)

  • RFC 4308, Conjuntos criptográficos para IPsec

    Solo se admite el suite VPN-A en Junos OS.

  • Autenticación RFC 4754, IKE e IKEv2 mediante el algoritmo de firma digital de curva elíptica (ECDSA)

  • RFC 4835, Requisitos de implementación de algoritmo criptográfico para carga de seguridad de encapsulación (ESP) y encabezado de autenticación (AH)

  • RFC 5996, Protocolo de intercambio de claves por internet versión 2 (IKEv2) (reemplazado por RFC 7296)

  • RFC 7296, Protocolo de intercambio de claves por internet versión 2 (IKEv2)

  • RFC 8200, Protocolo de Internet, versión 6 (IPv6) Especificación

Junos OS admite parcialmente las siguientes RFC para IPsec e IKE:

  • RFC 3526, Grupos Diffie-Hellman exponenciales más modulares (MODP) para intercambio de claves por internet (IKE)

  • RFC 5114, Grupos Diffie-Hellman adicionales para uso con estándares IETF

  • RFC 5903, Módulo principal de grupos de curva elíptica (grupos ECP) para IKE y IKEv2

Los siguientes RFC y borradores de Internet no definen estándares, sino que proporcionan información sobre IPsec, IKE y tecnologías relacionadas. El IETF los clasifica como "Informativos".

  • RFC 2104, HMAC: Hash con claves para la autenticación de mensajes

  • RFC 2412, El protocolo de determinación de claves OAKLEY

  • RFC 3706, un método basado en el tráfico para detectar pares inactivos de intercambio de claves por red (IKE)

  • Borrador de Internet draft-eastlake-sha2-02.txt, Algoritmos hash seguros de EE. UU. (SHA y HMAC-SHA) (caduca en julio de 2006)

Tabla de historial de versiones
Liberación
Descripción
19.1R1
A partir de la versión 19.1R1 de Junos OS, los firewalls serie SRX admiten los grupos DH 15, 16 y 21.