Descripción general del grupo VPNv2

Descripción del grupo VPNv2

VPN de grupo es un grupo de confianza para eliminar los túneles punto a punto y su enrutamiento superpuesto asociado. Todos los miembros del grupo comparten una asociación de seguridad común (SA), conocida como SA de grupo (GSA). La GSA permite a los miembros del grupo descifrar el tráfico cifrado por cualquier otro miembro del grupo. A partir de la versión 18.2R1 de Junos OS, confirmamos la redundancia VPN de grupo con el protocolo de redundancia de servicio [SRD] que se ejecuta en enrutadores MX. Los enrutadores MX con redundancia entre ellos actúan como miembros de VPN de grupo. Para obtener más información sobre el protocolo de redundancia de servicio, consulte Descripción general del demonio de redundancia de servicio.

A partir de la versión 15.1 de Junos OS, Junos OS admite el grupo VPNv2. El grupo VPNv2 es una categoría de VPN que elimina la necesidad de túneles VPN punto a punto en una arquitectura de malla. Es un conjunto de características necesarias para proteger el tráfico de unidifusión a través de una WAN privada que se origina o fluye a través de un enrutador.

El grupo VPNv2 introduce el concepto de grupo de confianza para eliminar los túneles de punto a punto y su enrutamiento de superposición asociado. Todos los miembros del grupo comparten una asociación de seguridad común (SA), también conocida como SA de grupo. Esto permite a los miembros del grupo descifrar el tráfico cifrado por cualquier otro miembro del grupo.

El grupo VPNv2 ofrece las siguientes ventajas:

• Proporciona seguridad de datos y autenticación de transporte, lo que ayuda a cumplir con la normativa interna y de seguridad mediante el cifrado de todo el tráfico de la WAN.

• Habilita mallas de red a alta escala y elimina la compleja administración de claves peer-to-peer con claves de cifrado de grupo.

• Reduce el número de cambios de punto de conexión que deben realizarse debido a un cambio de miembro del grupo o de política.

• Mantiene la inteligencia de red, como la conectividad de malla completa, la ruta de enrutamiento natural y la calidad del servicio (QoS) en las redes MPLS.

• Otorga control de membresía autenticado con un servidor de claves centralizado.

• Permite el cifrado y descifrado del tráfico entre todos los miembros del grupo definidos en la política de grupo.

• Ayuda a garantizar una baja latencia y fluctuación de fase al permitir comunicaciones directas a tiempo completo entre sitios, sin necesidad de transporte a través de un centro central.

• Reduce las cargas de tráfico en el equipo en las instalaciones del cliente (CPE) y los dispositivos de cifrado de borde del proveedor (PE) mediante el uso de la red central para la replicación del tráfico, lo que evita la replicación de paquetes en cada sitio de pares individual.

VPN de grupo VPNv2 y VPN IPsec estándar

El grupo VPNv2 se basa en tecnologías basadas en estándares que integran el enrutamiento y el cifrado en la red. Una SA de seguridad IPsec es un acuerdo unidireccional entre participantes de la VPN que define las reglas que se deben utilizar para los algoritmos de autenticación y cifrado, los mecanismos de intercambio de claves y las comunicaciones seguras.

Los despliegues tradicionales de VPN IPsec abordan el problema de proteger el tráfico entre puertas de enlace en la red mediante la creación de una red superpuesta basada en el uso de túneles punto a punto. El tráfico que se transporta a través de estos túneles normalmente se cifra y autentica para garantizar la integridad y confidencialidad de los datos. Los miembros seguros del grupo se administran a través del protocolo de dominio de interpretación de grupo (GDOI). La solución GDOI adopta un enfoque diferente al disociar el problema de cifrado y autenticación del transporte. De este modo, las soluciones basadas en GDOI permiten cifrar las comunicaciones de sucursal a sucursal sin necesidad de configurar túneles de sucursal a sucursal.

Con las implementaciones VPN actuales, la SA es un túnel de punto a punto entre dos puntos de conexión. El grupo VPNv2 extiende la arquitectura IPsec para admitir SA compartidas por un grupo de enrutadores (consulte la Figura 1). Un servidor de claves distribuye claves y políticas a todos los enrutadores miembro registrados y autenticados. Al distribuir políticas desde un punto centralizado y al compartir la misma asociación de seguridad de grupo (todo el grupo tiene una sola SA de fase 2) con miembros del grupo autenticados, la distribución y administración de claves se simplifican enormemente.

El grupo VPNv2 es una arquitectura de cliente/servidor. Todos los miembros tienen una SA IKE de fase 1 única con el servidor de claves. Por lo tanto, si hay n miembros, hay un total de SA de IKE de n fase 1. Sin embargo, todo el grupo comparte una sola SA de fase 2.

En IPsec tradicional, las direcciones de punto de conexión del túnel se utilizan como un nuevo origen y destino de paquetes. Luego, el paquete se enruta a través de la infraestructura IP utilizando la dirección IP de origen del punto final de cifrado y la dirección IP de destino del punto final de descifrado. En el caso de VPN de grupo, los paquetes de datos protegidos por IPsec conservan las direcciones de origen y destino originales del host en el encabezado IP exterior para conservar la dirección IP. Esto se conoce como preservación del encabezado de túnel. La mayor ventaja de la preservación del encabezado de túnel es la capacidad de enrutar paquetes cifrados mediante la infraestructura de enrutamiento de red subyacente.

Descripción del protocolo GDOI

El protocolo de dominio de interpretación de grupo (GDOI) descrito en RFC 6407 se utiliza para distribuir un conjunto de claves criptográficas y políticas a un grupo de dispositivos. GDOI se define como el dominio de interpretación (DOI) del Protocolo de administración de claves de la Asociación de Seguridad de Internet (ISAKMP) para la administración de claves de grupo. En un modelo de administración de grupos, el protocolo GDOI opera entre un miembro del grupo y un controlador de grupo o servidor de claves (GC/KS) y administra las asociaciones de seguridad de grupo y las claves de grupo para un conjunto de participantes de seguridad. El ISAKMP define dos fases de negociación. GDOI es un protocolo de fase 2 protegido por una asociación de seguridad ISAKMP de fase 1. IKEv1 se especifica en RFC 6407 como un protocolo de fase 1.

GDOI introduce dos claves de cifrado diferentes:

• Clave de cifrado de claves (KEK): se utiliza para proteger el plano de control. KEK es el nombre de la clave utilizada por los miembros del grupo para descifrar los mensajes de regeneración de claves del GC/KS. Esta clave forma parte de la clave de cifrado de claves de asociación de seguridad (SAK).

• Clave de cifrado de tráfico (TEK): se utiliza para proteger el plano de datos. TEK es el nombre de la clave utilizada por los miembros del grupo para cifrar o descifrar la comunicación entre otros miembros del grupo. Esta clave forma parte de la clave de cifrado de transporte de la Asociación de Seguridad (SA TEK).

Al igual que con IPsec estándar, todas las claves tienen una vida útil y se deben volver a codificar. Las claves distribuidas a través de GDOI son claves de grupo y son utilizadas por todo el grupo.

Las SA de grupo y la administración de claves se manejan a través de dos tipos de intercambios de GDOI:

• groupkey-pull: este intercambio permite a un miembro solicitar SA y claves compartidas por el grupo desde el servidor.

  En el método de extracción, el miembro del grupo solicita la SA y la política del grupo al servidor de claves. Esta solicitud está protegida por la SA de IKE.

  Es groupkey-pull el primer intercambio en el protocolo GDOI y se utiliza para el registro de miembros del grupo con el GC/KS. El miembro del grupo especifica el grupo en el que desea registrarse y el GC/KS envía todas las SA y claves de grupo necesarias al miembro del grupo si el miembro está autorizado para unirse al grupo. El intercambio completo está protegido por una SA de fase 1 (SA IKEv1), que se establece con IKEv1 antes de que comience el groupkey-pull intercambio. Es groupkey-pull parte de la Fase 2 del protocolo GADOI.

• groupkey-push: este intercambio es un único mensaje de regeneración de claves que permite al servidor enviar SA y claves de grupo a los miembros antes de que caduquen las SA de grupo existentes. Los mensajes de regeneración de claves son mensajes no solicitados enviados desde el servidor a los miembros.

  Es groupkey-push el segundo intercambio en el protocolo GDOI y es iniciado por el GC/KS a todos los miembros registrados del grupo. En la tabla 2 se muestran las cargas que el miembro del grupo de la serie MX espera recibir en groupkey-push los mensajes.

  Tabla 2: cargas de mensajes de inserción de clave de grupo

  carga	Descripción
  Política asociada al grupo (GAP)	Una carga GAP permite la distribución de políticas para todo el grupo, como instrucciones sobre cuándo activar y desactivar las SA. Esta carga contiene valores para el retardo de tiempo de activación (ATD) y el retardo de tiempo de desactivación (DTD) para la clave de cifrado de tráfico (TEK), así como el tipo de ventana del Protocolo de detección retardada de entrega IP y el tamaño de ventana para el tráfico IPsec.
  Clave de cifrado de transporte de la asociación de seguridad (SA TEK)	Selectores de tráfico.
  Clave de cifrado de clave de asociación de seguridad (SAK) (opcional)	La asociación de seguridad (SA) para la clave de cifrado de claves (KEK). También conocida como SA KEK. Nota: groupkey-push Los mensajes que no incluyen las cargas opcionales siguen siendo mensajes válidos.
  Clave de cifrado de tráfico (TEK) (Opcional)	Clave para cifrar el tráfico de datos entre los miembros del grupo.
  clave de cifrado de claves (KEK) (Opcional)	Se utiliza para proteger el TEK.

  El groupkey-push intercambio está protegido por un SA KEK (SAK), que se instala durante el groupkey-pull intercambio. Es groupkey-push parte de la Fase 2 del protocolo GADOI.

En algunos casos, es posible que el GC/KS desee recibir mensajes de confirmación de inserción de claves de grupo de los miembros del grupo. Los mensajes de confirmación de inserción de los miembros del grupo confirman que el miembro recibió el mensaje y ha tomado medidas en su política. El GC/KS también puede usar la confirmación para determinar qué miembros del grupo reciben la directiva de grupo actual y qué miembros del grupo ya no participan en el grupo. A partir de Junos OS 19.2R1, Junos OS envía un mensaje de confirmación con suma de comprobación SHA-256 cuando recibe un mensaje de inserción de clave de grupo con un valor de KEK_ACK_REQUESTED estándar de 9 en la carga de SA KEK tal y como se define en RFC 8263 o un valor de KEK_ACK_REQUESTED de 129 que se utiliza en servidores de claves más antiguos.

Protocolo GDOI y grupo VPNv2

Grupo VPNv2 es el nombre de la tecnología de seguridad implementada en las plataformas de enrutadores de Juniper Networks. El grupo VPNv2 utiliza el protocolo GDOI (RFC 6407) como base, además de otras funcionalidades.

La tecnología del grupo VPNv2 se basa en el protocolo GDOI para manejar las funcionalidades más importantes. Este protocolo se especifica en RFC 6407 y define un dominio de interpretación ISAKMP (DOI) para administrar las SA y las claves de grupo para un grupo de participantes de seguridad. Por lo tanto, todos los miembros del grupo comparten información idéntica para cifrar y descifrar el tráfico entre ellos. La creación, administración y distribución de SA de grupo y claves de grupo están centralizadas y las realiza el GC/KS. La Figura 2 proporciona una breve descripción de la funcionalidad de VPNv2 de grupo usando GDOI.

Figura 2: Grupo VPNv2 usando GDOI

Los miembros del grupo utilizan el protocolo de carga de seguridad de encapsulación (ESP) en modo de túnel para proteger el tráfico. Sin embargo, en VPN de grupo se modifica el modo de túnel. Dado que no existe una asociación directa entre los miembros del grupo, no es necesario utilizar direcciones IP especiales en el encabezado IP exterior (es decir, direcciones IP de puertas de enlace IPsec). Cada miembro del grupo puede descifrar el tráfico de todos los demás miembros del grupo. Por lo tanto, el encabezado de IP interno se copia en el encabezado de IP externo y se puede utilizar la infraestructura de enrutamiento subyacente y la infraestructura de QoS. Esta característica se denomina Preservación de encabezado y se muestra en la Figura 3.

Figura 3: Preservación del encabezado

Para obtener SA y claves de grupo, el miembro del grupo debe registrarse en el GC/KS de un grupo específico. El resultado es una SA IKEv1, que solo es necesaria para proteger el proceso de registro. Después del registro, el miembro del grupo tiene toda la información para comunicarse con los demás miembros del grupo (SA TEK), así como la información para descifrar correctamente los mensajes de reclave (SAK). El GC/KS envía mensajes de regeneración de claves antes de que caduque la duración de SA TEK o SAK. También es posible enviar una actualización SA TEK, así como una actualización SAK en el mismo mensaje de reclave. La SA IKEv1 ya no es necesaria y se elimina después de que expire la vida útil (sin regeneración de claves IKEv1).

Tráfico VPNv2 de grupo

El tráfico VPNv2 del grupo incluye:

• Control-plane-traffic: tráfico de los miembros del grupo al GC/KS en la implementación de VPNv2 del grupo solo con el protocolo GDOI.

• Tráfico de plano de datos: tráfico entre los miembros del grupo en la implementación de VPNv2 del grupo solo con el protocolo ESP que ya se conoce de IPsec.

Asociación de Seguridad del Grupo

A diferencia de las soluciones de cifrado IPsec tradicionales, VPN de grupo utiliza el concepto de asociación de seguridad de grupo. Una SA de grupo es similar a una SA en términos de funcionalidad. Las SA de grupo se comparten entre todos los miembros de un grupo GDOI común. Todos los miembros del grupo VPN de grupo pueden comunicarse entre sí mediante una política de cifrado común y una SA de grupo compartida. Con una política de cifrado común y una SA de grupo compartida, no es necesario negociar IPsec entre los miembros del grupo. Esto reduce la carga de recursos de los miembros del grupo. Los problemas de escalabilidad de IPsec tradicional (número de túneles y SA asociadas) no se aplican a los miembros del grupo VPN de grupo.

Controlador de grupo/servidor de claves

Un controlador de grupo o servidor de claves (GC/KS) es un dispositivo que se usa para crear y mantener el plano de control VPNv2 de grupo. Es responsable de la creación y distribución de SA de grupo y claves de grupo. Toda la información que los miembros del grupo necesitan para comunicarse con otros miembros del grupo la proporciona el GC/KS. Todas las políticas de cifrado, como el tráfico interesante, los protocolos de cifrado, la asociación de seguridad, los temporizadores de regeneración de claves, etc., se definen de forma centralizada en el GC/KS y se envían a todos los miembros del grupo en el momento del registro. Los miembros del grupo se autentican con el GC/KS mediante la fase 1 de IKE y, luego, descargan las políticas de cifrado y las claves necesarias para la operación de VPN de grupo. El GC/KS también es responsable de actualizar y distribuir las claves.

Miembro del grupo

Un miembro de grupo es un dispositivo de punto de conexión IPsec que se utiliza para el proceso de cifrado del tráfico y es responsable del cifrado y descifrado reales del tráfico de datos. Un miembro del grupo está configurado con parámetros de fase 1 de IKE e información de GC/KS. Las políticas de cifrado se definen de forma centralizada en el GC/KS y se descargan al miembro del grupo en el momento del registro correcto. Luego, cada miembro del grupo determina si el tráfico entrante y saliente se debe descifrar o cifrar (usando su SA) en función de su pertenencia al grupo.

Desde el punto de vista de la funcionalidad, un miembro del grupo es similar a una puerta de enlace IPsec. Sin embargo, las SA en IPsec normal existen entre dos puertas de enlace IPsec. En GDOI, el miembro del grupo se registra en GC/KS para participar en la VPN del grupo. Durante el registro, el miembro del grupo proporciona el identificador de grupo al GC/KS para obtener las políticas, SA y claves respectivas necesarias para este grupo. La regeneración de claves la realizan los miembros del grupo a través del groupkey-pull método (reinscripción) o por el GC/KS a través del groupkey-push método.

Protección antirreproducción para el tráfico VPNv2 de grupo

Dado que la comunicación VPN de grupo es esencialmente una comunicación cualquiera a través de la misma asociación de seguridad compartida, el uso de números de secuencia para la protección contra reproducción no funciona. Debido a esto, Junos OS admite una especificación de borrador de GTI-I para un mecanismo antireproducción basado en el tiempo, draft-weis-delay-detection-01. Está disponible en http://tools.ietf.org/html/draft-weis-delay-detection-01 .

Para implementar esta característica, los enrutadores miembro de la serie MX usan un nuevo encabezado de marca de tiempo del Protocolo de detección de retrasos en la entrega de IP dentro del paquete. Consulte Implementación del protocolo de detección de retrasos en la entrega de IP (protección antireproducción basada en el tiempo) para obtener más información.

Fallo parcial de apertura en enrutadores miembro de la serie MX

Los miembros del grupo en una VPN de grupo dependen del GC/KS para generar material de claves para la SA compartida. Por lo tanto, la conectividad entre los miembros del grupo y los GC/KS es necesaria para proteger inicialmente el tráfico y para proteger continuamente el tráfico sobre eventos de reclave. En caso de que se produzca un error de comunicación entre el miembro del grupo y el GC/KS, el comportamiento predeterminado de los miembros del grupo es detener el tráfico de reenvío. Esto se conoce como cierre por error.

Hay disponible una opción de configuración no predeterminada para permitir que algún tráfico definido específicamente fluya a través del miembro del grupo sin cifrarse hasta el momento en que el miembro pueda ponerse en contacto con GC/KS y recuperar la SA activa. Esto se conoce como falla parcial abierta.

La característica de apertura parcial requiere una opción de configuración de políticas que cree una regla en el miembro del grupo de la serie MX aplicable para un grupo VPNv2 determinado definido por las direcciones de origen y destino. Esta regla de apertura de error solo está activa cuando la SA del grupo está en estado deshabilitado debido a un error de conectividad con el servidor de claves. Se descarta el tráfico que normalmente pasaría por la VPN de grupo, pero que no coincide con la regla de fallo de apertura. Se puede definir más de una regla de fallo abierto para el objeto VPN de grupo. Si no se configuran reglas de fallo abierto, la característica de fallo abierto se desactiva.

Habilitación de VPNv2 grupal

Un conjunto de servicios se utiliza para habilitar el grupo VPNv2 en una interfaz determinada en enrutadores de la serie MX aplicables.

[edit services]
service-set service-set-name {
    interface-service {
        service-interface service-interface-name;
    }
}
ipsec-group-vpn vpn-name;

[edit interfaces]
interface-name {
    unit 0 {
        family inet {
            service {
                input {
                    service-set service-set-name;
                }
                output {
                    service-set service-set-name;
                }
            }
            address 10.0.30.2/30;
        }
    }
}

Registrar a un miembro del grupo

El registro de miembros del grupo en el servidor comienza cuando la ipsec-group-vpn instrucción está configurada para un conjunto de servicios y la interfaz de servicio está activa. Cuando la interfaz de servicio deja de funcionar, se borran todas las SA de grupo asociadas con esta interfaz y no se activa ningún registro para estas VPN de grupo hasta que aparece la interfaz.

El registro de miembros del grupo implica el establecimiento de SA de IKE con el GC/KS seguido de un groupkey-pull intercambio para descargar las SA y las claves de tráfico para el identificador de grupo especificado.

Regeneración de claves de un miembro del grupo (método groupkey-push)

El GC/KS enviará un mensaje de unidifusión groupkey-push a los miembros del grupo registrados para:

• Envíe nuevas claves de cifrado de claves (KEK) o claves de cifrado de tráfico (TEK).

  Los mensajes push pueden contener todos o solo algunos de los elementos de carga útil que se muestran en la Tabla 2. Cuando la carga GAP contiene SA antiguas y SA de reemplazo nuevas, el enrutador miembro del grupo aplicará los valores ATD y DTD como una regeneración de claves normal mediante inserción. Si no hay ningún valor ATD en la actualización, el enrutador miembro instala la nueva SA inmediatamente. Si no hay un valor DTD, las SA antiguas permanecerán en su lugar hasta su vencimiento.

• Actualice la política asociada al grupo (GAP) para una SA existente.

  Un GC/KS puede enviar un mensaje push de unidifusión para actualizar la configuración a los miembros del grupo en cualquier momento. La carga GAP puede incluir cambios de configuración en el protocolo de detección de retrasos en la entrega de IP, algoritmo de cifrado, duración de la vida útil, etc. La configuración actualizada se aplica inmediatamente o con retraso. Los valores de ATD y DTD se utilizan para lograr el momento de la activación del nuevo TEK y la eliminación del TEK existente, respectivamente. Si se debe reducir la vida útil de TEK existente, el valor de DTD se establece en consecuencia en el mensaje push. El nuevo TEK en el mensaje push se activa en función del valor ATD en la carga útil.

• Envíe notificaciones de eliminación de claves para TEK o KEK.

  El GC/KS puede enviar la carga de notificación de eliminación opcional en el mensaje de inserción para eliminar claves y SA en el miembro. El mensaje push contiene el ID de protocolo que indica si la notificación de eliminación es para TEK o KEK. El enrutador miembro del grupo elimina la clave en función del ID de grupo y el valor SPI contenidos en la carga. La eliminación de una TEK o KEK específica se puede realizar con un valor de retraso especificado en el atributo DTD. Si el valor de retraso es 0 y la carga contiene un SPI específico, la TEK o KEK coincidente se elimina inmediatamente. Si es necesario eliminar todas las TEK o KEK (o ambas) del grupo, el valor SPI se establece en 0 para el ID de protocolo correspondiente en la carga.

• Quite un enrutador miembro de la VPN de grupo en el grupo VPNv2.

  Los mensajes push se utilizan para permitir que GC/KS elimine miembros de la VPN de grupo. En un caso, GC/KS envía un mensaje de regeneración de claves con solo las SA antiguas y un valor DTD más pequeño. El enrutador miembro del grupo instala el valor DTD nuevo y más pequeño. Dado que no recibió nuevas claves de SA, el enrutador miembro intenta volver a registrarse mediante el groupkey-pull método. El GC/KS rechaza este intento de volver a registrarse, eliminando así el miembro de la VPN del grupo. En el segundo caso, el GC/KS envía una carga útil de eliminación para el SPI de la SA anterior. El enrutador miembro del grupo elimina la SA inmediatamente e intenta volver a registrarse mediante el groupkey-pull método. El GC/KS rechaza este intento de volver a registrarse, eliminando así el miembro de la VPN del grupo.

Los miembros del grupo de la serie MX registrados envían un mensaje de confirmación de inserción de unidifusión al GC/KS para confirmar la recepción del mensaje de inserción original.

Regeneración de claves de un miembro del grupo (método groupkey-pull)

Para la regeneración de claves de miembros del grupo, mediante el método, los miembros del grupo normalmente se vuelven a registrar en GC/KS cuando queda entre un groupkey-pull 7 y un 5 por ciento en la duración suave de TEK o KEK existente. Si la SA de IKE existente está disponible, se utiliza en el mensaje de extracción. Después de que el GC/KS responda con una nueva clave, tanto la clave antigua como la nueva se pueden usar para el descifrado. Sin embargo, la nueva clave no se usa para el cifrado hasta que le quedan 30 segundos de vida útil de la clave anterior. Si la SA de IKE existente no está disponible, el mensaje de extracción da como resultado nuevas negociaciones de IKE entre el miembro del grupo y el GC/KS.

Al recibir el mensaje de extracción relativo a una VPN de grupo específica del miembro del grupo, el GC/KS responde con todos los TEK y la KEK de ese grupo.

Si alguna SA existente no se incluye en la respuesta del GC/KS, el miembro del grupo elimina las SA que faltan.

Tomando como ejemplo, el GC/KS está configurado con una vida útil de 3600 segundos y está conectado a un miembro del grupo sin retransmisión. En función de la configuración del servidor, GC/KS genera una nueva clave cuando queda el 10 por ciento de la vida útil. Sin embargo, el miembro del grupo se vuelve a registrar en el GC/KS cuando queda entre un 5 y un 7 por ciento de la vida útil.

La figura 4 representa el proceso de regeneración de claves entre el GC/KS y el miembro del grupo.

Figura 4: Regeneración de claves de miembros del grupo

Autenticación de un miembro del grupo

Junos OS no proporciona compatibilidad con infraestructura de clave pública (PKI) para VPN de grupo en VPNv2 de grupo. Como resultado, se utilizan claves previamente compartidas para la autenticación de miembros del grupo.

Fragmentación del tráfico VPNv2 del grupo

Debido a la funcionalidad de conservación de encabezado y al uso de la infraestructura de enrutamiento subyacente, es necesario fragmentar los paquetes antes de que se produzca el cifrado (si no se puede evitar).

Por lo tanto, se admite la prefragmentación y se recomienda para todas las implementaciones.

Para evitar la fragmentación posterior, establezca las opciones , y copy para clearsetel bit DF en la configuración del grupo VPNv2.

En función de esta configuración de marca, el encabezado IPsec tiene el df-bit valor establecido en clear, seto copy del paquete interno.

[edit]
security {
    group-vpn {
        member {
            ipsec {
                vpn group-vpn-name {
                    df-bit clear;
                }
            }
        }
    }
}

Cifrado del tráfico VPNv2 del grupo

Los miembros del grupo cifran el tráfico en función de las SA y las claves de grupo proporcionadas por GC/KS. La ruta de cifrado del grupo VPNv2 es la siguiente:

1. El paquete recibido por el motor de reenvío de paquetes se compara con una coincidencia de flujo. Si se encuentra una coincidencia, el paquete se procesa y transmite posteriormente.

2. Si no se encuentra una coincidencia, se realiza una búsqueda de reglas. Si se encuentra una coincidencia, se crea un flujo y el paquete se procesa y transmite posteriormente.

3. Si se produce un error en la búsqueda de reglas, se descarta el paquete.

Descifrar el tráfico VPNv2 del grupo

Una vez que el registro se realiza correctamente y se instalan las SA de VPN de grupo, se crea una sesión ESP. El grupo VPNv2 crea la sesión ESP con una IP de origen y destino cero. Dado que la sesión ESP ya se creó en la instalación de SA, se espera que los paquetes coincidan con la sesión ESP existente.

La ruta de descifrado del grupo VPNv2 es la siguiente:

1. El paquete recibido por el motor de reenvío de paquetes se somete a una comprobación de fragmentación. Si el paquete está fragmentado, se ensambla para su posterior procesamiento.

2. Después del ensamblaje del paquete, o si el paquete no está fragmentado, se utiliza una IP de origen y destino cero en la búsqueda de flujo de descifrado de 5 tuplas. Si se encuentra una coincidencia, el paquete se procesa y transmite posteriormente.

3. Si se produce un error en la búsqueda de flujo de descifrado, el paquete se compara con un flujo SPI sin IP de origen ni de destino.

4. Si se produce un error en la búsqueda de flujo SPI, se descarta el paquete.

5. Si se encuentra una coincidencia de flujo SPI, se crea un flujo de descifrado para evitar la búsqueda de flujo SPI para los paquetes posteriores.

Configuración de una instancia de enrutamiento para el grupo VPNv2

Las instancias de enrutamiento son compatibles tanto para el tráfico de control como para el de datos. Para habilitar la compatibilidad con instancias de enrutamiento en el tráfico del plano de control para que un miembro del grupo llegue al GC/KS en una instancia de enrutamiento VRF dada, agregue la routing-instance instrucción en el nivel de [edit security group-vpn member ike gateway gateway-name local-address address] jerarquía.

No se necesita ninguna CLI adicional para admitir una instancia de enrutamiento para paquetes de plano de datos, ya que se determina en función de la interfaz de medios en la que se aplica el conjunto de servicios.

Establecimiento de múltiples grupos, políticas y SA

Junos OS proporciona soporte para una VPN de grupo por cada servicio establecido en el grupo VPNv2. Sin embargo, se pueden crear varios conjuntos de servicios para admitir varios grupos en una instancia de enrutamiento. Se pueden configurar varias SA por grupo. Sin embargo, no se admiten varias políticas para la misma clave de tráfico/SPI. Si el servidor envía dos políticas para el mismo TEK, deben estar emparejadas para ser aceptadas, por ejemplo, A-B y B-A, donde A y B son direcciones IP o subredes. Si se reciben varias políticas no emparejadas para un TEK determinado, se produce un error en el registro y se genera un mensaje de registro del sistema.

Conexión con múltiples GC/KS cooperativos

Para que un miembro del grupo trabaje con un GC/KS en el modo cooperativo, la configuración se extiende para permitir un máximo de cuatro servidores en la lista de servidores.

Durante la regeneración de claves cuando se utiliza el groupkey-pull método, el miembro del grupo intenta conectarse al GC/KS. Cuando se produce un error en la conexión con el GC/KS, el miembro del grupo intenta volver a conectarse al GC/KS. Después de tres reintentos con un intervalo de 10 segundos, si no se restaura la conexión con el GC/KS, el miembro del grupo intenta establecer una conexión con el siguiente servidor disponible en la lista de servidores. Este proceso se repite hasta que el miembro del grupo se conecta a un GC/KS. Durante este tiempo, las SA de GDOI no vencidas en los miembros del grupo no se limpian, por lo que el tráfico VPN del grupo no se ve afectado. El intervalo de tiempo entre la regeneración de claves y la expiración de la duración dura proporciona tiempo suficiente para que los miembros del grupo se conecten al siguiente servidor disponible, en tales casos.

Implementación del protocolo de detección de retrasos en la entrega de IP (protección antirreproducción basada en el tiempo)

No es necesaria ninguna configuración para implementar el protocolo de detección de retrasos en la entrega de IP. Los miembros del grupo de la serie MX obtienen el tamaño de la ventana de reproducción para usarlo como parte de la carga GAP en mensajes de inserción o extracción del servidor de claves. Si el tamaño de la ventana recibida es 0, se deshabilita la protección antireproducción basada en el tiempo.

Si el protocolo de detección de retrasos en la entrega de IP está habilitado, el remitente agrega su marca de hora actual y cifra el paquete. El receptor descifra el paquete y compara su hora actual con la marca de hora del paquete. Los paquetes que quedan fuera del tamaño de ventana se descartan. Debido a esto, todos los miembros del grupo deben tener sus relojes sincronizados mediante el protocolo de tiempo de red (NTP).

Protocolo de detección de retrasos en la entrega de IP Los tiempos se miden en segundos. Consulte Protocolo de detección de retrasos en la entrega de IP-draft-weis-delay-detection-01 para obtener más información.

Cambiar la configuración de VPNv2 del grupo

La mayoría de los cambios de configuración de VPNv2 del grupo dan como resultado la eliminación de las SA existentes y el nuevo registro. Esto activa tanto la fase 1 como la descarga de SA con nuevas claves de tráfico.

Omitir la configuración de VPNv2 del grupo

Si cierto tráfico, como un protocolo de enrutamiento, necesita omitir una VPN de grupo en el grupo VPNv2, se debe configurar un filtro de servicio en la interfaz en la que se aplica el conjunto de servicios. Los paquetes que coinciden con el filtro de servicio no llegan a la PIC para su procesamiento y se reenvían directamente al motor de enrutamiento.

[edit interfaces]
interface-name {
    unit 0 {
        family inet {
            service {
                input {
                    service-set service-set-name service-filter filter-name;
                }
                output {
                    service-set service-set-name service-filter filter-name;
                }
            }
        }
    }
}

Implementación de la apertura por error parcial en enrutadores miembro de la serie MX

De forma predeterminada, los paquetes se descartan si un enrutador miembro del grupo no puede obtener SA del GC/KS debido a una pérdida de conectividad. Si desea permitir que parte del tráfico pase sin cifrar en caso de que se produzca un error de comunicación entre el miembro del grupo y el GC/KS, debe configurar una fail-open regla en el nivel de jerarquía [edit security group-vpn member ipsec vpn vpn-name ].

Las reglas de apertura por error se aplicarán al tráfico solo en caso de pérdida de conectividad del servidor. Las reglas de apertura con errores se desactivarán una vez que se restablezca la conectividad y se reciban las claves del GC/KS.

[edit security group-vpn member ipsec vpn vpn-name]
fail-open {
    rule rule-name{
        source-address source-ip-address
            destination-address destination-ip-address}
        }
    }

Se puede configurar un máximo de 10 reglas de fallo abierto para un grupo determinado.

Parámetros IPsec de GDOI compatibles

Cada grupo de GDOI tiene un ID único. Se utiliza como base común entre GC/KS y el miembro del grupo para comunicarse acerca de las SA de grupo y las claves de grupo.

Durante el proceso de registro, el GC/KS envía claves de cifrado de transporte de la Asociación de Seguridad (SA TEK) a los miembros del grupo. Todos los parámetros relacionados con la política de seguridad de todo el grupo se configuran en el GC/KS. Los miembros del grupo utilizan el TEK de SA para proteger el tráfico intercambiado entre ellos. La Tabla 3 muestra los parámetros de SA TEK.

Además de los algoritmos criptográficos, el tráfico, que debe ser cifrado por los miembros del grupo, forma parte de la política SA TEK (selector de tráfico).

Las siguientes instrucciones se pueden utilizar en un miembro del grupo de Juniper Networks. Por lo tanto, las direcciones deben especificarse bajo el nivel de jerarquía IKE. La enumeración también tiene prioridad. Por lo tanto, en la siguiente configuración de ejemplo, se contacta con KS1 antes que con KS2.

[edit security]
group-vpn {
    member {
        ike {
            gateway gateway-name {
                ike-policy policy-name;
                server-address <IP_KS1> <IP_KS2> <IP_KS3> <IP_KS4>;
                local-address <IP_GM> routing-instance routing-instance-name;
            }
        }
        ipsec {
            vpn vpn-group-name {
                ike-gateway gateway-name;
                fail-open {
                    rule rule-name {
                    source-address 198.51.100.1/24 
                    destination-address 192.0.2.1/24 
                    }
                }
                group group-ID;
                match-direction output;
            }
        }
    }
}

Parámetros IKEv1 de GDOI compatibles

Los estándares IKEv1 mencionados anteriormente están configurados de la siguiente manera:

Aplicación de políticas dinámicas

Las input opciones and de la ipsec-group-vpn instrucción especifican output si las políticas dinámicas recibidas del servidor se utilizan cuando la interfaz en la que se aplica el conjunto de servicios es la interfaz entrante o saliente. Esto proporciona flexibilidad para especificar diferentes reglas en las direcciones de entrada y salida.

Compatibilidad con TOS y DSCP

Los bits de tipo de servicio (TOS) y puntos de código DiffServ (DSCP) se copian del paquete interno al paquete ESP.

Interoperabilidad de los miembros del grupo

La implementación de GDOI de Cisco se llama VPN de transporte de cifrado de grupo (GET). Aunque el grupo VPNv2 en Junos OS y GET VPN de Cisco se basan en RFC 6407, El dominio de interpretación del grupo, existen algunas diferencias de implementación que debe tener en cuenta al implementar GDOI en un entorno de red que incluye dispositivos de seguridad y enrutamiento de Juniper Networks y enrutadores de Cisco. Para obtener más información, consulte las notas de la versión actual de Junos OS.

La interoperabilidad del grupo VPNv2 es la siguiente:

• Junos OS proporciona soporte de interoperabilidad con el soporte GC/KS de Cisco iOS.

• Junos OS no proporciona compatibilidad para la interoperabilidad del grupo VPNv2 con el servidor VPN de grupo de la serie SRX.

  Tabla 5: Interoperabilidad de VPNv2 de grupo

  Miembro del grupo	Miembro del grupo SRX	Miembro de VPNv2 del grupo MX	Miembro del grupo Cisco	SRX GC	SRX KS	Cisco GC/KS
  Miembro de VPNv2 del grupo MX	No	Sí	Sí	No	Sí	Sí
  Miembro del grupo SRX	Sí	No	No	Sí	Sí	Sí

Junos OS no admite la política de denegación utilizada en un servidor GC/SK de Cisco para agregar una excepción a la política de grupo. Como solución alternativa, esto se puede hacer configurando reglas de firewall en un miembro del grupo de la serie MX. Además, los miembros del grupo de Junos OS pueden trabajar con la política de denegación si no se produce un error en la negociación y simplemente se ignora el contenido. Esto permite a los administradores de sistemas administrar fácilmente redes en las que coexisten miembros del grupo de Cisco y del grupo de Junos OS.

Limitaciones de VPNv2 de grupo

El grupo VPNv2 de Junos OS no proporciona soporte para lo siguiente:

• Mensajes push de multidifusión

• Tráfico de multidifusión

• MIB SNMP de GDOI

• Protocolo y puerto en las políticas enviadas por el servidor. El miembro del grupo solo respeta la dirección IP o la subred especificadas en la política.

• Varias políticas no emparejadas para la misma clave de tráfico/SPI

• Superposición de IP local y remota a través de instancias de enrutamiento en una configuración de puerta de enlace IKE

• Superposición de políticas VPNv2 de grupo que pueden dar lugar a SA no coincidentes

• IPv6 para control y tráfico de datos

• Coexistencia de IPsec y VPN de grupo en el mismo conjunto de servicios

• Coexistencia de servicios como TDR y ALG en el mismo conjunto de servicios. TDR y VPN de grupo pueden coexistir en diferentes conjuntos de servicios. Sin embargo, no pueden coexistir en el mismo conjunto de servicios.

• La VPN de sitio a sitio (S2S) y la VPN de punto de conexión dinámico (DEP) pueden coexistir con VPN de grupo en diferentes conjuntos de servicios. Sin embargo, no pueden coexistir en el mismo conjunto de servicios.

• Varios grupos en el mismo conjunto de servicios

• Soporte de los miembros del grupo con GC/KS de la serie SRX

• Soporte de miembros del grupo con miembro del grupo de la serie SRX

• Jerarquía de claves lógicas (LKH)

• Reinicio virtuoso

• Alta disponibilidad

• ISSU unificado

• Compatibilidad con PKI para autenticación