Intercambio de claves por Internet (IKE) para VPN IPsec

Procesamiento de paquetes de IKE

Cuando un paquete de texto sin cifrar 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 descarta el paquete. Las direcciones de origen y de destino en el encabezado del paquete IP son las de las puertas de enlace IKE local y remota, respectivamente. En la carga del paquete IP, hay un segmento UDP que encapsula un paquete ISAKMP (IKE). El formato para 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 interrumpido. Normalmente, para 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: Carga de negociación de SA contiene una definición para una SA de fase 1 o fase 2.

• 0004: la carga útil 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 de SA.

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

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

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

  • En la fase 2, IDui indica el usuario iniciador e IDur indica el usuario que responde.

  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 de hash (HASH) contiene el resultado de síntesis de una función hash determinada.

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

• 0400—La carga útil de Nonce (Nx) contiene información pseudoaleatoria necesaria para el intercambio).

• 0800—Carga de notificación.

• 1000: Carga de eliminación ISAKMP.

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

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

Figura 2: Encabezado genérico de carga ISAKMP

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

Figura 3: Encabezado ISAKMP con cargas ISAKMP genéricas

Procesamiento de paquete IPsec

Una vez que se completan las negociaciones de IKE y las dos puertas de enlace IKE han 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 tiene un aspecto similar al que se muestra en .Figura 4 El dispositivo agrega dos encabezados adicionales al paquete original que envía el host iniciador.

Tal como se muestra en Figura 4, el paquete que crea el host iniciador incluye la carga, el encabezado TCP y el encabezado de IP interior (IP1).

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

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

Figura 5: Encabezado de IP exterior (IP2) y encabezado ESP

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

Figura 6: Encabezado de dirección IP interior (IP1) y encabezado de TCP

Configuración de IKEv2 en Junos OS

Un par VPN se configura como IKEv1 o IKEv2. Cuando un par se configura como IKEv2, no puede recurrir 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 instrucción de configuración en el nivel de jerarquía [] para configurar IKEv2.version v2-onlyedit security ike gateway gw-name

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

Los dispositivos de Juniper Networks admiten hasta cuatro propuestas para negociaciones de fase 2, lo que le permite definir qué tan restrictivo será un rango de parámetros de túnel que aceptará. Junos OS proporciona conjuntos predefinidos de propuestas de fase 2 de tipo 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 es compatible 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. describe los atributos de configuración de IKEv2 admitidos en los firewalls de la serie SRX.Tabla 1

Para que el respondedor IKE 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 a través de un servidor RADIUS. En el servidor RADIUS, la información del usuario no debe incluir una contraseña de autenticación. El perfil de servidor RADIUS está enlazado a la puerta de enlace IKE mediante la configuración en el nivel de jerarquía [].aaa access-profile profile-nameedit security ike gateway gateway-name

A partir de Junos OS versión 20.3R1, en SRX5000 línea con SPC3 y vSRX Virtual Firewall ejecutando iked proceso, 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, una dirección IPv6, una dirección DNS o una dirección WINS del respondedor. Después de que el respondedor ha autenticado correctamente al iniciador, asigna una dirección IP desde un grupo de direcciones local o a través del servidor RADIUS. Dependiendo de 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 grupo enmarcado, Junos OS asigna una dirección IP o información en función de la configuración de su grupo local correspondiente. Si configura tanto el grupo de direcciones local como el servidor RADIUS, la dirección IP asignada desde el servidor RADIUS tiene prioridad sobre el grupo local. Si configura un grupo de direcciones IP local y el servidor RADIUS no devolvió ninguna dirección IP, el grupo local asignará la dirección IP a la solicitud.

• Opción adicional, introducida para .noneauthentication-order Consulte Orden de autenticación (perfil de acceso).authentication-order (Access Profile)

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

  Asegúrese de que el servidor RADIUS admite mensajes de inicio o detención de cuentas. Asegúrese también de que tanto los firewalls de la serie SRX como el servidor RADIUS tengan la configuración adecuada para realizar un seguimiento de estos mensajes.

• La introducción de la compatibilidad con IPv6 permite túneles de pila dual que utilizan la carga de configuración. Durante el proceso de inicio de sesión, IKE solicita direcciones IPv4 e IPv6. AAA permite el inicio de sesión solo 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 ruta, las interfaces de túnel seguro (st0) funcionan en modo punto a multipunto o punto a punto. La asignación de direcciones a través de la carga de configuración de IKEv2 ahora se admite 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 rango de subred de la interfaz punto a multipunto asociada.

A partir de Junos OS versión 20.1R1, puede configurar una contraseña común para las solicitudes de carga de configuración de IKEv2 para una configuración de puerta de enlace IKE. La contraseña común en el intervalo 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 de la serie SRX solicita una dirección IP en nombre de un par IPsec remoto mediante la carga de configuración de IKEv2. El servidor RADIUS coincide con las credenciales antes de proporcionar cualquier información IP al firewall de la serie SRX para la solicitud de carga de configuración. Puede configurar la contraseña común mediante la instrucción de configuración en el nivel de jerarquía [].config-payload-password configured-passwordedit security ike gateway gateway-name aaa access-profile access-profile-name

Tanto el firewall de la serie SRX como el servidor RADIUS deben tener la misma contraseña configurada y el servidor RADIUS debe configurarse para usar el Protocolo de autenticación de contraseña (PAP) como protocolo de autenticación. Sin esto, el establecimiento del túnel 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 tanto con interfaces de túnel seguro punto a multipunto (st0) como con interfaces punto a punto. Las interfaces punto a multipunto deben estar numeradas y las direcciones proporcionadas en la carga de configuración deben estar dentro del rango de subred de la interfaz punto a multipunto asociada.

A partir de Junos OS versión 20.1R1, admitimos la función de carga de configuración IKEv2 con interfaces punto a punto en línea SRX5000 y firewall virtual vSRX ejecutando iked.

Descripción del aprovisionamiento de células pico

La carga de configuración de IKEv2 se puede usar para propagar información de aprovisionamiento desde un respondedor IKE, como un firewall de la serie SRX, a múltiples iniciadores, como las estaciones base de celdas pico LTE en una red celular. Las picoceldas 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 picoceldas se almacena en uno o más servidores de aprovisionamiento dentro de una red protegida. Las picoceldas 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 pico celda e introducirla en el servicio incluye cuatro etapas distintas:

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

   • Configuración del túnel de puerta de enlace segura al firewall de la 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 pico celda se inicia y adquiere una dirección que se utilizará para la negociación de IKE desde un servidor DHCP. A continuación, se construye un túnel a la puerta de enlace segura en el firewall de la serie SRX utilizando 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 pico celling: mediante su dirección de tráfico OAM asignada, la pico cell solicita su información de aprovisionamiento (normalmente certificado de operador, licencia, software e información de configuración) a los servidores de la red protegida.

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

4. Prestación de servicios: cuando la pico cell entra en servicio, utiliza un único certificado que contiene valores de nombre distintivo (DN) y nombre alternativo de sujeto con un FQDN para construir dos túneles a la puerta de enlace segura en el firewall de la serie SRX: uno para el tráfico 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 reintroducción de claves y la reautenticación son procesos separados. La reintroducción de claves establece nuevas claves para la asociación de seguridad (SA) de IKE y restablece los contadores de ID de mensajes, pero no vuelve a autenticar a los pares. La reautenticació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 IKE y las SA secundarias; ya no se necesitan las reclaves de ninguna SA IKE o SA secundaria pendiente. Después de crear el nuevo IKE y las SA secundarias, se eliminan el IKE antiguo y las SA secundarias.

La reautenticación IKEv2 está deshabilitada de forma predeterminada. Para habilitar la reautenticación, configure un valor de frecuencia de reautenticación entre 1 y 100. La frecuencia de reautenticación es el número de reclaves IKE que se producen antes de que se produzca la reautenticación. Por ejemplo, si la frecuencia de reautenticación configurada es 1, se produce una nueva autenticación cada vez que hay una reclave IKE. Si la frecuencia de reautenticación configurada es 2, la reautenticación se produce en cada dos reclaves de IKE. Si la frecuencia de reautenticación configurada es 3, se produce una nueva autenticación en cada tercera reclave IKE, y así sucesivamente.

La frecuencia de reautenticación se configura con la instrucción en el nivel de jerarquía [].reauth-frequencyedit security ike policy policy-name La reautenticación se deshabilita estableciendo la frecuencia de reautenticación en 0 (valor predeterminado). La frecuencia de reautenticación no es negociada por los pares y cada par puede tener su propio valor de frecuencia de reautenticación.

Características soportadas

La reautenticación IKEv2 es compatible con las siguientes características:

• Iniciadores o respondedores de 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 (NAT-T)

• Clústeres de chasis en modo activo-activo y activo-pasivo para dispositivos de 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 de la SA de IKE anterior. En este escenario, es posible que no se elimine la SA de IKE antigua.

• En un escenario NAT-T, el iniciador detrás del dispositivo NAT puede convertirse en el respondedor después de la reautenticación. Si la sesión NAT caduca, el dispositivo NAT podría descartar nuevos paquetes IKE que podrían llegar a un puerto diferente. NAT-T keepalive o DPD deben estar habilitados para mantener viva la sesión NAT. Para AutoVPN, recomendamos que la frecuencia de reautenticación configurada en los radios sea menor que la frecuencia de reautenticación configurada en el concentrador.

• En función de la frecuencia de reautenticación, el iniciador o el respondedor de la SA original pueden iniciar una nueva SA de IKE. Dado que la carga de configuración y autenticación del Protocolo de autenticación extensible (EAP) requieren que la SA de IKE la inicie la misma parte que la SA de IKE original, no se admite la reautenticación con la autenticación EAP ni con la carga de configuración.

Jerarquía multinivel para la autenticación de certificados

La autenticación basada en certificados es un método de autenticación admitido en los firewalls de la serie SRX durante la negociación 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 independientes para ubicaciones, departamentos u organizaciones individuales.

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 del mismo nivel. La carga del 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 participan 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 EE 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 IKE configurado se puede realizar con un servidor de CA especificado o un grupo de servidores de CA. 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, Root-CA 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 para las CA de desarrollo y control de calidad, que se identifican como Dev-CA y Qa-CA, respectivamente. El 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 multinivel para la 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 Root-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 de la cadena de certificados. El siguiente resultado muestra los perfiles de CA configurados en el host-A:

El siguiente resultado muestra los perfiles de CA configurados en el host B:

Vulnerabilidades de DDoS en implementaciones de IKE

Cuando el interlocutor remoto (iniciador) envía un mensaje SA_INIT, el interlocutor local (respondedor) responde y asigna memoria para la estructura del mensaje. Nos referimos a la sesión como una sesión IKE semiabierta hasta que se realiza la autenticación con el mensaje IKE_AUTH.Después de que los pares establecen una asociación de seguridad (SA) IKE, la sesión se denomina sesión IKE completamente abierta.

Para comprender las vulnerabilidades de IKEv2 DDoS, veamos algunas de las formas en que un atacante puede crear un vector de ataque fácil contra las SA de IKE:

• Enviar grandes cantidades de mensajes de SA_INIT (sin mensajes IKE_AUTH) para los que el atacante puede crear estructuras de asociación de seguridad IKE medio abiertas. Esto hace que el dispositivo utilice los recursos y se quede sin memoria.

• Envíe una gran cantidad de paquetes de IKE_AUTH basura con SPI_i y SPI_r correctos al iniciador y al respondedor, respectivamente. Esto hace que el dispositivo se quede sin memoria al intentar descifrar los paquetes.

• Enviar paquetes SA_INIT continuos. Esto hace que el dispositivo se quede sin memoria al intentar generar claves para paquetes cifrados.

• Envíe grandes cantidades de solicitudes de reclave por segundo durante sesiones de IKE completamente abiertas.

• Envíe grandes cantidades de mensajes con distintos ID de mensaje. Hace que el dispositivo ponga en cola todos los mensajes IKE entrantes y se quede sin memoria.

Cómo proteger las implementaciones de IKE

Proporcionamos una infraestructura robusta para mitigar y monitorear los ataques DDoS para los protocolos IKEv1 e IKEv2. Puede protegerse contra los ataques a las implementaciones de IKE cuando el firewall ejecuta el proceso iked ( paquete) para el servicio VPN IPsec.junos-ike

Protección Against Ataques DDoS

Puede habilitar varios mecanismos de defensa contra los ataques DDoS durante el proceso de creación de asociaciones de seguridad IKE. Estos mecanismos incluyen la configuración de la limitación de velocidad y un período de retención para las asociaciones de seguridad IKE semiabiertas, además de administrar los tipos de cambio entrantes para las solicitudes de reclave. Proporcionamos las siguientes medidas para garantizar la protección:

• Para SA de IKE semiabiertas:

  • El respondedor no permite la configuración de SA de IKE medio abierto durante un período determinado. Puede establecer este límite para que el respondedor no se configure hasta que alcance la duración del tiempo de espera. Para obtener más información, consulte la opción .session (Security IKE)timeout

  • Puede establecer el límite en el máximo permitido de SA de IKE medio abiertas en el respondedor. Cuando el número total de SA de IKE medio abiertas alcanza el recuento máximo, el respondedor rechaza las nuevas conexiones para las SA IKEv1 e IKEv2. Para obtener más información, consulte la opción .session (Security IKE)max-count

  • El respondedor aplica valores de umbral en el recuento de sesiones para las SA de IKE medio abiertas. Cuando el número total de SA de IKE medio abiertas alcanza valores de umbral,

    • En el caso de las SA IKEv2, el respondedor invoca el mecanismo de cookies para cualquier conexión nueva.

    • En el caso de las SA IKEv1, el respondedor rechaza las nuevas conexiones.

    Para obtener más información, consulte las opciones , y .session (Security IKE)thresholdssend-cookiereduce-timeout

  • El respondedor puede descartar sesiones duplicadas. Para obtener más información, consulte la opción .session (Security IKE)discard-duplicate

  • Puede establecer tiempos de espera de retroceso para las fases de error de autenticación e iniciación. Para obtener más información, consulte las opciones , y .session (Security IKE)backoff-timeoutsinit-phase-failureauth-phase-failure

• Para SA de IKE completamente abiertas:

  • Puede configurar las tasas máximas de solicitudes de reclave entrantes para limitar las solicitudes en un escenario escalado. Para obtener más información, consulte la opción .session (Security IKE)incoming-exchange-max-rates

• El respondedor puede bloquear una sesión de IKE entrante de pares en función del ID de IKE del mismo nivel. Para obtener más información, consulte .blocklists (Security IKE)RLI41450 Review this entire topic

• En el caso de las puertas de enlace dinámicas, puede establecer un límite para el número de conexiones en el nivel de configuración de puerta de enlace IKE mediante la opción .connections-limit Para obtener más información, consulte Puerta de enlace (IKE de seguridad)./documentation/us/en/software/junos/vpn-ipsec/topics/ref/statement/security-edit-gateway-ike.html

Para obtener más información sobre cómo configurar estas opciones, consulteConfigurar la protección contra ataques DDoS de IKE.Configurar la protección contra ataques DDoS de IKE

No admitimos:

• Protección DDoS con el servicio VPN IPsec basado en el proceso kmd.

• Protección contra ataques de codificación de certificados hash y URL, ya que no admitimos estos tipos de codificación.

Formas de monitorear ataques DDoS

Proporcionamos los siguientes mecanismos para monitorear los ataques DDoS:

• Utilice el comando para enumerar todas las asociacionesde seguridad de IKE maduras y no maduras.show security ike security-associations Para obtener más información, consulte mostrar asociaciones de seguridad ike de seguridad./documentation/us/en/software/junos/vpn-ipsec/topics/ref/command/show-security-ike-security-associations.html

• Utilice el comando para mostrar estadísticas globales de IKE del túnel VPN IPsec, como estadísticas en curso, establecidas y caducadas.show security ike stats Para obtener más información, consulta Mostrar estadísticas de ike de seguridad./documentation/us/en/software/junos/vpn-ipsec/topics/ref/command/show-security-ike-stats.html

• Utilice el comando para mostrar detalles de las negociaciones exitosas de IKE con los pares remotos.show security ike active-peer Para obtener más información, consulte mostrar ike de seguridad active-peer./documentation/us/en/software/junos/vpn-ipsec/topics/ref/command/show-security-ike-active-peer.html

• Utilice el comando para mostrar los detalles de las SA de IKE en curso, incluidas las SA de IKE medio abiertas.show security ike peers in-progress Para obtener más información, consulte .show security ike peersRLI41450 También puede ver los detalles de los pares bloqueados, con errores y de retroceso mediante este comando.

• Utilice el comando para borrar los pares de IKE que están retrocedidos, bloqueados, fallidos o en curso.clear security ike peers Para obtener más información, consulte .clear security ike peersRLI41450

• Para eliminar una asociación de seguridad IKE existente con pares que deba bloquearse para que no pueda seguir comunicándose, utilice el comando.clear security ike security-associations Para obtener más información, consulte clear security ike security-associations./documentation/us/en/software/junos/vpn-ipsec/topics/ref/command/clear-security-ike-security-associations.html

• Los mensajes syslog de IKED IKE_GATEWAY_PEER_BLOCKED, IKE_GATEWAY_PEER_BACKOFF y IKE_GATEWAY_PEER_FAILED proporcionan detalles sobre las negociaciones IKE bloqueadas, respaldadas y fallidas con los pares remotos, respectivamente.

• Para mayor seguridad, Junos OS ofrece servicios a los usuarios para protegerse contra ataques al sistema basados en paquetes, como el filtrado, el recuento de sesiones y la limitación de velocidad. Para obtener más información, consulte el comando show firewall y la instrucción ids-optionen el nivel de jerarquía []./documentation/us/en/software/junos/routing-policy/topics/ref/command/show-firewall-filter.html/documentation/us/en/software/junos/denial-of-service/topics/ref/statement/security-edit-ids-option.htmledit security screen ids-option screen-name

Fragmentación de mensajes

La fragmentación de mensajes IKEv2, como se describe en RFC 7383, Fragmentación de mensajes del Protocolo de intercambio de claves por Internet versión 2 (IKEv2), permite que IKEv2 funcione en entornos donde los fragmentos de IP podrían estar bloqueados y los pares no podrían establecer una asociación de seguridad (SA) IPsec. 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 cifrar y autenticar el mensaje original, de modo que cada fragmento se cifra y autentica por separado. En el receptor, los fragmentos se recopilan, verifican, descifran y fusionan en el mensaje original.

Para que se produzca la fragmentación de IKEv2, ambas VPN del mismo nivel deben indicar la compatibilidad con la fragmentación mediante la inclusión de la carga de notificación IKEV2_FRAGMENTATION_SUPPORTED en el intercambio 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 la fragmentación de IKEv2.

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

Configuración

En los firewalls de la serie SRX, la fragmentación IKEv2 está habilitada de forma predeterminada para los mensajes IPv4 e IPv6. Para deshabilitar la fragmentación de IKEv2, utilice la instrucción en el nivel de jerarquía [].disableedit security ike gateway gateway-name fragmentation También puede utilizar la 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.size Si no está configurado, el tamaño predeterminado del paquete es 576 bytes para el tráfico IPv4 y 1280 bytes para el tráfico IPv6.size Un paquete IKEv2 mayor que el tamaño de paquete configurado está fragmentado.

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

Advertencias

Las siguientes características no son compatibles con la fragmentación de IKEv2:

• Descubrimiento de MTU de ruta.

• SNMP.