Intercambio de claves por internet (IKE) para VPN IPsec

Procesamiento de paquetes IKE

Cuando un paquete de texto sin formato llega a un dispositivo de Juniper Networks que requiere tunelización y no existe ninguna SA de fase 2 activa para ese túnel, Junos OS comienza las negociaciones de IKE y deja caer el paquete. Las direcciones de origen y destino en el encabezado del paquete IP son las de las puertas de enlace IKE locales y remotas, respectivamente. En la carga del paquete IP, hay un segmento UDP que encapsula un paquete ISAKMP (IKE). El formato de los paquetes IKE es el mismo para la fase 1 y la fase 2. Consulte Figura 1.

Mientras tanto, el host de origen volvió a enviar el paquete caído. Por lo general, cuando llega el segundo paquete, las negociaciones de IKE se completan y Junos OS protege el paquete y todos los paquetes subsiguientes en la sesión, con IPsec antes de reenviarlo.

Figura 1: Paquete IKE para las fases 1 y 2

El campo Carga siguiente contiene un número que indica uno de los siguientes tipos de carga:

• 0002: la carga de negociación de SA contiene una definición para una SA de fase 1 o fase 2.

• 0004: La carga de la propuesta puede ser una propuesta de fase 1 o fase 2.

• 0008: la carga de transformación se encapsula en una carga de propuesta que se encapsula en una carga sa.

• 0010—La carga de intercambio de claves (KE) contiene información necesaria para realizar un intercambio de claves, como un valor público DH.

• 0020— Carga de identificación (IDx).

  • En la fase 1, IDii indica el ID del iniciador e IDir indica el ID de respuesta.

  • En la fase 2, IDui indica el iniciador del usuario e IDur indica el respondedor de usuario.

  Los ID son tipos de ID de IKE, como FQDN, U-FQDN, dirección IP y ASN.1_DN.

• 0040— Carga de certificado (CERT).

• 0080: Carga de solicitud de certificado (CERT_REQ).

• 0100—La carga hash (HASH) contiene el resultado de resumen de una función hash determinada.

• 0200—La carga de firma (SIG) contiene una firma digital.

• 0400— La carga nonce (Nx) contiene información pseudoalealea necesaria para el intercambio).

• 0800: carga de notificación.

• 1000: ISAKMP eliminar carga.

• 2000— La carga de ID de proveedor (VID) se puede incluir en cualquier lugar de las negociaciones de fase 1. Junos OS lo usa para marcar la compatibilidad con TDR-T.

Cada carga ISAKMP comienza con el mismo encabezado genérico, como se muestra en Figura 2.

Figura 2: Encabezado genérico de carga ISAKMP

Puede haber varias cargas ISAKMP encadenadas, con cada tipo de carga subsiguiente indicado por el valor en el campo Encabezado siguiente. Un valor de 0000 indica la última carga ISAKMP. Consulte Figura 3 para ver un ejemplo.

Figura 3: Encabezado ISAKMP con cargas ISAKMP genéricas

Procesamiento de paquetes IPsec

Después de que se completen las negociaciones de IKE y las dos puertas de enlace de IKE hayan establecido asociaciones de seguridad (SA) de fase 1 y fase 2, todos los paquetes subsiguientes se reenvían mediante el túnel. Si la SA de fase 2 especifica el protocolo de seguridad de encapsulación (ESP) en modo de túnel, el paquete se parece al que se muestra en Figura 4. El dispositivo agrega dos encabezados adicionales al paquete original que envía el host iniciador.

Como se muestra en Figura 4, el paquete que construye el host iniciador incluye la carga, el encabezado TCP y el encabezado IP interno (IP1).

Figura 4: Paquete IPsec: ESP en modo de túnel

El encabezado IP del enrutador (IP2), que agrega Junos OS, contiene la dirección IP de la puerta de enlace remota como la dirección IP de destino y la dirección IP del enrutador local como la dirección IP de origen. Junos OS también agrega un encabezado ESP entre los encabezados IP externos e internos. El encabezado ESP contiene información que permite que el par remoto procese correctamente el paquete cuando lo recibe. Esto se muestra en Figura 5.

Figura 5: Encabezado IP externo (IP2) y encabezado ESP

El campo Encabezado siguiente indica el tipo de datos en el campo de carga. En el modo de túnel, este valor es 4, lo que indica que un paquete IP está contenido dentro de la carga. Consulte Figura 6.

Figura 6: Encabezado IP interno (IP1) y encabezado TCP

Configuración de IKEv2 en Junos OS

Un par vpn está configurado como IKEv1 o IKEv2. Cuando un par está configurado como IKEv2, no puede volver a IKEv1 si su par remoto inicia la negociación de IKEv1. De forma predeterminada, los dispositivos de seguridad de Juniper Networks son pares IKEv1.

Utilice la version v2-only instrucción de configuración en el nivel de jerarquía [edit security ike gateway gw-name] para configurar IKEv2.

La versión de IKE se muestra en la salida de los comandos operativos de cli show security ike security-associations y show security ipsec security-associations .

Los dispositivos de Juniper Networks admiten hasta cuatro propuestas para negociaciones de fase 2, lo que le permite definir cómo se restringe un rango de parámetros de túnel que aceptará. Junos OS ofrece conjuntos predefinidos de propuestas de fase 2 básicas, compatibles y estándar. También puede definir propuestas de fase 2 personalizadas.

Descripción de la carga de configuración de IKEv2

La carga de configuración es una opción de intercambio de claves por internet versión 2 (IKEv2) que se ofrece para propagar la información de aprovisionamiento de un respondedor a un iniciador. La carga de configuración de IKEv2 solo se admite con VPN basadas en rutas.

RFC 5996, Protocolo de intercambio de claves por internet versión 2 (IKEv2), define 15 atributos de configuración diferentes que el respondedor puede devolver al iniciador. Tabla 1 describe los atributos de configuración IKEv2 compatibles con los firewalls serie SRX.

Para que el respondedor de ICR proporcione al iniciador información de aprovisionamiento, debe adquirir la información de un origen especificado, como un servidor RADIUS. La información de aprovisionamiento también se puede devolver desde un servidor DHCP mediante un servidor RADIUS. En el servidor RADIUS, la información de usuario no debe incluir una contraseña de autenticación. El perfil de servidor RADIUS está vinculado a la puerta de enlace de IKE mediante la aaa access-profile profile-name configuración en el nivel de jerarquía [edit security ike gateway gateway-name].

A partir de Junos OS versión 20.3R1, en la línea SRX5000 con firewall virtual SPC3 y vSRX que ejecuta el proceso iked, hemos mejorado la carga de configuración de IKEv2 para:

• Compatibilidad con el conjunto de direcciones locales IPv4 e IPv6. También puede asignar una dirección IP fija a un par.

  Durante el establecimiento de IKE, el iniciador solicita una dirección IPv4, dirección IPv6, dirección DNS o dirección WINS del respondedor. Después de que el respondedor haya autenticado correctamente al iniciador, asigna una dirección IP desde un conjunto de direcciones local o a través del servidor RADIUS. Según la configuración, esta dirección IP se asigna dinámicamente cada vez que un par se conecta o se asigna como una dirección IP fija. Si el servidor RADIUS responde con un conjunto enmarcado, Junos OS asigna una dirección IP o información basada en la configuración desde su grupo local correspondiente. Si configura tanto el conjunto de direcciones locales como el servidor RADIUS, la dirección IP asignada del servidor RADIUS tiene prioridad sobre el grupo local. Si configura un conjunto de direcciones IP local y el servidor RADIUS no devuelve ninguna dirección IP, el grupo local asigna la dirección IP a la solicitud.

• Opción adicional, none introducida para authentication-order. Consulte orden de autenticación (perfil de acceso).

• Los mensajes de inicio y detención de la contabilidad RADIUS informan el estado del túnel o del par al servidor RADIUS. Estos mensajes se pueden utilizar con fines de seguimiento o para notificaciones a subsistemas como un servidor DHCP.

  Asegúrese de que el servidor RADIUS admite mensajes de inicio o detención de la contabilidad. También asegúrese de que tanto los firewalls serie SRX como el servidor RADIUS tengan la configuración adecuada para rastrear estos mensajes.

• La introducción de la compatibilidad con IPv6 permite túneles de doble pila mediante la carga de configuración. Durante el proceso de inicio de sesión, IKE solicita direcciones IPv4 e IPv6. La AAA solo permite el inicio de sesión si todas las direcciones solicitadas se han asignado correctamente. IKE finaliza la negociación si no se asigna la IP solicitada.

En una VPN basada en rutas, las interfaces de túnel seguro (st0) funcionan en modo punto a multipunto o punto a punto. Ahora se admite la asignación de direcciones mediante la carga de configuración IKEv2 para el modo punto a multipunto o punto a punto. Para las interfaces de punto a multipunto, las interfaces deben estar numeradas y las direcciones en la carga de configuración INTERNAL_IP4_ADDRESS tipo de atributo deben estar dentro del intervalo de subredes de la interfaz de punto a multipunto asociada.

A partir de Junos OS versión 20.1R1, puede configurar una contraseña común para solicitudes de carga de configuración de IKEv2 para una configuración de puerta de enlace de IKE. La contraseña común en el rango de 1 a 128 caracteres permite al administrador definir una contraseña común. Esta contraseña se utiliza entre el firewall de la serie SRX y el servidor RADIUS cuando el firewall serie SRX solicita una dirección IP en nombre de un par IPsec remoto mediante la carga de configuración IKEv2. El servidor RADIUS hace coincidir las credenciales antes de proporcionar información ip al firewall serie SRX para la solicitud de carga de configuración. Puede configurar la contraseña común mediante config-payload-password configured-password la instrucción de configuración en el nivel de jerarquía [edit security ike gateway gateway-name aaa access-profile access-profile-name].

Tanto el firewall serie SRX como el servidor RADIUS deben tener la misma contraseña configurada y el servidor radius debe estar configurado para usar el protocolo de autenticación de contraseña (PAP) como protocolo de autenticación. Sin esto, el establecimiento de túneles no tendrá éxito.

Figura 7 muestra un flujo de trabajo típico para una carga de configuración IKEv2.

Figura 7: Flujo de trabajo típico de carga de configuración de IKEv2

La función de carga de configuración IKEv2 es compatible con las interfaces de túnel seguro de punto a multipunto (st0) y las interfaces de punto a punto. Las interfaces de punto a multipunto deben estar numeradas y las direcciones proporcionadas en la carga de configuración deben estar dentro del intervalo de subredes de la interfaz de punto a multipunto asociada.

A partir de junos OS versión 20.1R1, somos compatibles con la función de carga de configuración IKEv2 con interfaces punto a punto en la línea SRX5000 y firewall virtual vSRX que se ejecuta iked.

Descripción del aprovisionamiento de celdas Pico

La carga de configuración de IKEv2 se puede utilizar para propagar la información de aprovisionamiento desde un respondedor de IKE, como un firewall de la serie SRX, a varios iniciadores, como las estaciones base de celdas pico LTE en una red celular. Las celdas pico se envían de fábrica con una configuración estándar que les permite conectarse al firewall de la serie SRX, pero la información de aprovisionamiento de celdas pico se almacena en uno o más servidores de aprovisionamiento dentro de una red protegida. Las celdas pico reciben información completa de aprovisionamiento después de establecer conexiones seguras con los servidores de aprovisionamiento.

El flujo de trabajo necesario para arrancar y aprovisionar una celda pico e introducirla en el servicio incluye cuatro etapas distintas:

1. Adquisición de direcciones iniciales: la celda pico se envía desde la fábrica con la siguiente información:

   • Configuración para el túnel de puerta de enlace segura al firewall serie SRX

   • Certificado digital emitido por el fabricante

   • Nombre de dominio completo (FQDN) de los servidores de aprovisionamiento que se encuentran dentro de la red protegida

   La celda pico se inicia y adquiere una dirección que se utilizará para la negociación de IKE desde un servidor DHCP. Luego, se construye un túnel a la puerta de enlace segura en el firewall de la serie SRX mediante esta dirección. El servidor DHCP también asigna una dirección para el tráfico de operación, administración y administración (OAM) para su uso en la red protegida.

2. Aprovisionamiento de celdas pico: mediante su dirección de tráfico OAM asignada, la celda pico solicita su información de aprovisionamiento (normalmente información de certificado de operador, licencia, software e configuración) a los servidores de la red protegida.

3. Reinicio: la celda pico se reinicia y utiliza la información de aprovisionamiento adquirida para que sea específica para el modelo de red y operación del proveedor de servicios.

4. Provisión de servicio: cuando la celda pico entra en el servicio, usa un único certificado que contiene nombres distinguidos (DN) y valores de nombre alternativos de sujeto con un FQDN para crear dos túneles a la puerta de enlace segura en el firewall serie SRX: uno para el tráfico de OAM y el otro para el tráfico de datos del proyecto de asociación de tercera generación (3GPP).

Descripción general

Con IKEv2, la reenrutación y la reautenticación son procesos independientes. La reenclave establece nuevas claves para la asociación de seguridad (SA) de IKE y restablece los contadores de ID de mensaje, pero no vuelve a autenticar los pares. La reautoentificación verifica que los pares de VPN conserven su acceso a las credenciales de autenticación. La reautenticación establece nuevas claves para la SA de ICR y las SA secundarias; ya no se necesitan las claves de cualquier SA de IKE o SA secundaria pendiente. Después de crear las SA nuevas ICR e secundarias, se eliminan las IKE antiguas y las SA secundarias.

La reautenticación IKEv2 está deshabilitada de forma predeterminada. Puede habilitar la reautenticación configurando un valor de frecuencia de reautenticación entre 1 y 100. La frecuencia de reautenticación es el número de claves de IKE que se produce antes de que se produzca la reautenticación. Por ejemplo, si la frecuencia de reautenticación configurada es 1, la reautenticación se produce cada vez que hay una rekey de ICR. Si la frecuencia de reautenticación configurada es 2, la reautenticación se produce en cada otra rekey de ICR. Si la frecuencia de reautenticación configurada es 3, la reautenticación se produce en cada tercera rekey de ICR, y así sucesivamente.

Configure la frecuencia de reautenticación con la reauth-frequency instrucción en el nivel de jerarquía [edit security ike policy policy-name]. La reautenticación se deshabilita estableciendo la frecuencia de reautenticación en 0 (el valor predeterminado). Los pares no negocian la frecuencia de reautenticación y cada par puede tener su propio valor de frecuencia de reautenticación.

Funciones compatibles

La reautoentificación IKEv2 se admite con las siguientes funciones:

• Iniciadores o respondedores IKEv2

• Detección de pares muertos (DPD)

• Enrutadores virtuales e interfaces de túnel seguro (st0) en enrutadores virtuales

• Recorrido de traducción de direcciones de red (TDR-T)

• Clústeres de chasis en modo activo-activo y activo-pasivo para dispositivos SRX5400, SRX5600 y SRX5800

• Actualización de software en servicio (ISSU) en dispositivos SRX5400, SRX5600 y SRX5800

• Actualización o inserción de una nueva Unidad de procesamiento de servicios (SPU) mediante el procedimiento de actualización de hardware en servicio (ISHU)

Limitaciones

Tenga en cuenta las siguientes advertencias al usar la reautenticación IKEv2:

• Con NAT-T, se puede crear una nueva SA de IKE con puertos diferentes a la SA de IKE anterior. En este caso, es posible que no se elimine la ANTIGUA SA de IKE.

• En una situación TDR-T, el iniciador detrás del dispositivo TDR puede convertirse en el respondedor después de la reautoentificación. Si la sesión TDR caduca, es posible que el dispositivo TDR descarte nuevos paquetes IKE que podrían llegar a un puerto diferente. Se debe habilitar TDR o DPD para mantener viva la sesión TDR. Para AutoVPN, recomendamos que la frecuencia de reautenticación configurada en los radios sea menor que la frecuencia de reautenticación configurada en el hub.

• Según la frecuencia de reautenticación, el iniciador o el respondedor de la SA de IKE original pueden iniciar una nueva SA de IKE. Dado que la autenticación de protocolo de autenticación extensible (EAP) y la carga de configuración requieren que la SA de IKE la inicie el mismo parte que la SA de IKE original, la reautoentificación no se admite con la autenticación de EAP ni con la carga de configuración.

Jerarquía de varios niveles para la autenticación de certificados

La autenticación basada en certificados es un método de autenticación compatible con los firewalls serie SRX durante la negociación de IKE. En redes grandes, varias autoridades de certificación (CA) pueden emitir certificados de entidad final (EE) a sus respectivos dispositivos finales. Es común tener CA separadas para ubicaciones individuales, departamentos u organizaciones.

Cuando se emplea una jerarquía de un solo nivel para la autenticación basada en certificados, todos los certificados EE de la red deben estar firmados por la misma CA. Todos los dispositivos de firewall deben tener el mismo certificado de CA inscrito para la validación del certificado par. La carga de certificado enviada durante la negociación de IKE solo contiene certificados EE.

Alternativamente, la carga de certificado enviada durante la negociación de IKE puede contener una cadena de certificados EE y CA. Una cadena de certificados es la lista de certificados necesarios para validar el certificado EE de un par. La cadena de certificados incluye el certificado EE y cualquier certificado de CA que no esté presente en el par local.

El administrador de red debe asegurarse de que todos los pares que participen en una negociación de IKE tengan al menos una CA de confianza común en sus respectivas cadenas de certificados. La CA de confianza común no tiene que ser la CA raíz. El número de certificados de la cadena, incluidos los certificados para EEs y la CA más alta de la cadena, no puede superar los 10.

A partir de Junos OS versión 18.1R1, la validación de un par de IKE configurado se puede hacer con un servidor de CA o un grupo de servidores de CA especificados. Con las cadenas de certificados, la CA raíz debe coincidir con el grupo de CA de confianza o el servidor de CA configurado en la política de IKE

En la jerarquía de CA de ejemplo que se muestra en Figura 8, LA CA raíz es la CA de confianza común para todos los dispositivos de la red. La CA raíz emite certificados de CA a las CA de ingeniería y ventas, que se identifican como Eng-CA y Sales-CA, respectivamente. Eng-CA emite certificados de CA a las CA de desarrollo y garantía de calidad, que se identifican como Dev-CA y Qa-CA, respectivamente. Host-A recibe su certificado EE de Dev-CA, mientras que el Host-B recibe su certificado EE de Sales-CA.

Figura 8: Jerarquía de varios niveles para autenticación basada en certificados

Cada dispositivo final debe cargarse con los certificados de CA en su jerarquía. El host-A debe tener certificados Root-CA, Eng-CA y Dev-CA; Los certificados Sales-CA y Qa-CA no son necesarios. El host-B debe tener certificados raíz-CA y Sales-CA. Los certificados se pueden cargar manualmente en un dispositivo o inscribirse mediante el proceso simple de inscripción de certificados (SCEP).

Cada dispositivo final debe configurarse con un perfil de CA para cada CA en la cadena de certificados. El siguiente resultado muestra los perfiles de CA configurados en el host-A:

En el siguiente resultado, se muestran los perfiles de CA configurados en el host-B:

Fragmentación de mensajes

La fragmentación de mensajes de IKEv2, como se describe en RFC 7383, Fragmentación de mensajes del protocolo de intercambio de claves de Internet versión 2 (IKEv2), permite que IKEv2 funcione en entornos en los que los fragmentos de IP podrían bloquearse y los pares no podrían establecer una asociación de seguridad IPsec (SA). La fragmentación de IKEv2 divide un mensaje IKEv2 grande en un conjunto de mensajes más pequeños para que no haya fragmentación en el nivel de IP. La fragmentación tiene lugar antes de que el mensaje original se cifrado y autentifique, de modo que cada fragmento se cifra y autentica por separado. En el receptor, los fragmentos se recopilan, verifican, descifran y se fusionan en el mensaje original.

Para que se produzca la fragmentación de IKEv2, ambos pares de VPN deben indicar compatibilidad con la fragmentación mediante la inclusión de la carga de notificación IKEV2_FRAGMENTATION_SUPPORTED en el intercambio de IKE_SA_INIT. Si ambos pares indican compatibilidad con la fragmentación, corresponde al iniciador del intercambio de mensajes determinar si se utiliza o no fragmentación IKEv2.

En los firewalls serie SRX, se permiten un máximo de 32 fragmentos por mensaje IKEv2. Si el número de fragmentos de mensaje IKEv2 que se enviarán o reciben supera los 32, los fragmentos se pierden y no se establece el túnel. No se admite la retransmisión de fragmentos de mensajes individuales

Configuración

En los firewalls serie SRX, la fragmentación de IKEv2 se habilita de forma predeterminada para mensajes IPv4 e IPv6. Para deshabilitar la fragmentación de IKEv2, utilice la disable instrucción en el nivel de jerarquía [edit security ike gateway gateway-name fragmentation]. También puede usar la size instrucción para configurar el tamaño del paquete en el que se fragmentan los mensajes; el tamaño del paquete oscila entre 500 y 1300 bytes. Si size no está configurado, el tamaño predeterminado del paquete es de 576 bytes para el tráfico IPv4 y 1280 bytes para el tráfico IPv6. Se fragmenta un paquete IKEv2 que sea mayor que el tamaño de paquete configurado.

Después de deshabilitar o habilitar la fragmentación de IKEv2 o de cambiar el tamaño del fragmento de paquete, se desactiven los túneles VPN alojados en la puerta de enlace de IKE y se renegocian las SA IKE e IPsec.

Advertencias

No se admiten las siguientes funciones con la fragmentación de IKEv2:

• Descubrimiento de MTU de ruta.

• SNMP.