Asociaciones de Seguridad Dinámica
Configuración de propuestas de ICR
Las asociaciones de seguridad dinámica (SA) requieren una configuración de IKE. Con las SA dinámicas, primero se configura ICR y, luego, la SA. IKE crea las SA dinámicas y las negocia para IPsec. La configuración de IKE define los algoritmos y las claves que se usan para establecer la conexión IKE segura con la puerta de enlace de seguridad par.
Puede configurar una o varias propuestas de IKE. Cada propuesta es una lista de atributos de IKE para proteger la conexión de IKE entre el host de IKE y su par.
Para configurar una propuesta de ICR, incluya la proposal instrucción y especifique un nombre en el nivel de [edit services ipsec-vpn ike] jerarquía:
[edit services ipsec-vpn ike] proposal proposal-name { authentication-algorithm (md5 | sha1 | sha-256); authentication-method (ecdsa-signatures-256 | ecdsa-signatures-384 | pre-shared-keys | rsa-signatures); dh-group (group1 | group2 | group5 |group14 | group 15 | group16 | group19 | group20 | group24); encryption-algorithm algorithm; lifetime-seconds seconds; }
En el modo FIPS de Junos, ECDSA no es compatible con el método de autenticación de Junos OS versión 17.3R1. A partir de Junos OS versión 17.4R1, ECDSA es compatible con el modo FIPS de Junos.
En esta sección se incluyen los temas siguientes:
- Configuración del algoritmo de autenticación para una propuesta de IKE
- Configuración del método de autenticación para una propuesta de ICR
- Configuración del grupo Diffie-Hellman para una propuesta de IKE
- Configurar el algoritmo de cifrado para una propuesta de IKE
- Configuración de la duración de una SA de IKE
- Ejemplo: Configuración de una propuesta de ICR
Configuración del algoritmo de autenticación para una propuesta de IKE
Para configurar el algoritmo de autenticación de una propuesta de ICR, incluya la authentication-algorithm instrucción en el nivel de [edit services ipsec-vpn ike proposal proposal-name] jerarquía:
[edit services ipsec-vpn ike proposal proposal-name] authentication-algorithm (md5 | sha1 | sha-256);
El algoritmo de autenticación puede ser uno de los siguientes:
md5: produce un resumen de 128 bits.sha1: produce un resumen de 160 bits.sha-256: produce un resumen de 256 bits.Nota:Para obtener información de referencia sobre los algoritmos de hash seguros (SHA), consulte el borrador
draft-eastlake-sha2-02.txtde Internet, Algoritmos de hash seguros (SHA y HMAC-SHA) (caduca en julio de 2006).
Configuración del método de autenticación para una propuesta de ICR
Para configurar el método de autenticación de una propuesta de ICR, incluya la authentication-method instrucción en el nivel de [edit services ipsec-vpn ike proposal proposal-name] jerarquía:
[edit services ipsec-vpn ike proposal proposal-name] authentication-method (ecdsa-signatures-256 | ecdsa-signatures-384 | pre-shared-keys | rsa-signatures);
En IKEv1, el método de autenticación para las SA se negocia con el par remoto según el tipo de método de autenticación configurado en la propuesta de IKE. En IKEv2, dicha negociación no se realiza con el par remoto. En su lugar, cada par de IKE utiliza el método de autenticación configurado localmente para ellos.
Para las SA en IKEv2, el método de autenticación es el valor predeterminado como IKEv1 si no se configuró un método de autenticación en la propuesta de IKE. Si está configurando un método de autenticación para IKEv2, debe tener configurado el mismo método de autenticación para todas las propuestas a las que se hace referencia en la política.
El método de autenticación puede ser uno de los siguientes:
En el modo FIPS de Junos, ECDSA no es compatible con el método de autenticación de Junos OS versión 17.3R1. A partir de Junos OS versión 17.4R1, ECDSA es compatible con el modo FIPS de Junos.
ecdsa-signatures-256—A partir de la versión 17.3R1 de Junos OS para MS-MPC y MS-MIC, el algoritmo de firma digital de curva elíptica (ECDSA) para módulos de 256 bits.ecdsa-signatures-384—A partir de la versión 17.3R1 de Junos OS para MS-MPC y MS-MIC, el algoritmo de firma digital de curva elíptica (ECDSA) para módulos de 384 bits.pre-shared-keys—Una clave derivada de un mecanismo fuera de banda; La clave autentica los intercambios.rsa-signatures—Algoritmo de clave pública (admite cifrado y firmas digitales).
Configuración del grupo Diffie-Hellman para una propuesta de IKE
Diffie-Hellman es un esquema de criptografía de clave pública que permite a dos partes establecer un secreto compartido a través de un canal de comunicaciones inseguro. También se utiliza en IKE para establecer claves de sesión.
Para configurar el grupo Diffie-Hellman para una propuesta de IKE, incluya la dh-group instrucción en el nivel de [edit services ipsec-vpn ike proposal proposal-name] jerarquía:
[edit services ipsec-vpn ike proposal proposal-name] dh-group (group1 | group2 | group5 |group14 | group15 | group16 | group19 | group20 | group24);
El grupo puede ser uno de los siguientes:
group1: especifica que IKE utiliza el grupo de módulos principales Diffie-Hellman de 768 bits al realizar el nuevo intercambio Diffie-Hellman.group2: especifica que IKE utiliza el grupo de módulos principales Diffie-Hellman de 1024 bits al realizar el nuevo intercambio Diffie-Hellman.group5: especifica que IKE utiliza el grupo de módulos principales Diffie-Hellman de 1536 bits al realizar el nuevo intercambio Diffie-Hellman.group14: especifica que IKE utiliza el grupo de módulos principales Diffie-Hellman de 2048 bits al realizar el nuevo intercambio Diffie-Hellman.group19: especifica que IKE utiliza el grupo Diffie-Hellman de curva elíptica aleatorio de 256 bits al realizar el nuevo intercambio Diffie-Hellman.group20: especifica que IKE utiliza el grupo Diffie-Hellman de curva elíptica aleatorio de 384 bits al realizar el nuevo intercambio Diffie-Hellman.
A partir de la versión 17.4R1 de Junos OS, también se pueden utilizar el grupo 15, el grupo 16 y el grupo 24:
group15: especifica que IKE utilice el grupo de módulos principales Diffie-Hellman de 3072 bits al realizar el nuevo intercambio Diffie-Hellman.group16: especifica que IKE utilice el grupo de módulos principales Diffie-Hellman de 4096 bits al realizar el nuevo intercambio Diffie-Hellman.group24: especifica que IKE utilice el grupo de módulos principales Diffie-Hellman de 2048 bits con un subgrupo de orden principal de 256 bits al realizar el nuevo intercambio Diffie-Hellman.
El uso de un grupo Diffie-Hellman basado en un mayor número de bits da como resultado un túnel IKE más seguro que el uso de un grupo basado en menos bits. Sin embargo, esta seguridad adicional puede requerir tiempo de procesamiento adicional.
Configurar el algoritmo de cifrado para una propuesta de IKE
Para configurar el algoritmo de cifrado de una propuesta de ICR, incluya la encryption-algorithm instrucción en el nivel de [edit services ipsec-vpn ike proposal proposal-name] jerarquía:
[edit services ipsec-vpn ike proposal proposal-name] encryption-algorithm algorithm;
El algoritmo de cifrado puede ser uno de los siguientes:
3des-cbc—Algoritmo de cifrado de encadenamiento de bloques de cifrado con un tamaño de clave de 24 bytes; Su tamaño de clave es de 192 bits de largo.des-cbc—Algoritmo de cifrado de encadenamiento de bloques de cifrado con un tamaño de clave de 8 bytes; El tamaño de su clave es de 56 bits.aes-128-cbc—Algoritmo de cifrado de 128 bits del Estándar de cifrado avanzado (AES).aes-192-cbc—Algoritmo de cifrado de 192 bits del Estándar de cifrado avanzado (AES).aes-256-cbc—Algoritmo de cifrado de 256 bits del Estándar de cifrado avanzado (AES).
Para obtener una lista de las claves débiles y semidébiles del algoritmo de cifrado del Estándar de cifrado de datos (DES), consulte RFC 2409, El intercambio de claves por red (IKE). Los algoritmos de cifrado AES utilizan una implementación de software que tiene una transferencia de datos mucho menor, por lo que DES sigue siendo la opción recomendada.
Para 3des-cbc, los primeros 8 bytes deben diferir de los segundos 8 bytes y los segundos 8 bytes deben ser iguales a los terceros 8 bytes.
Si configura una propuesta de autenticación, pero no incluye la encryption instrucción, el resultado es un cifrado NULL. Ciertas aplicaciones esperan este resultado. Si no configura ningún valor de autenticación o cifrado específico, Junos OS utilizará los valores predeterminados de sha1 para la autenticación y 3des-cbc para el cifrado.
Configuración de la duración de una SA de IKE
La lifetime-seconds instrucción establece la duración de una SA de IKE. Cuando la SA de IKE caduca, se sustituye por una nueva SA (y SPI) o la conexión IPsec finaliza.
Para configurar la duración de una SA de IKE, incluya la lifetime-seconds instrucción en el nivel de [edit services ipsec-vpn ike proposal proposal-name] jerarquía:
[edit services ipsec-vpn ike proposal proposal-name] lifetime-seconds seconds;
De forma predeterminada, la duración de la SA de IKE es de 3600 segundos. El rango es de 180 a 86,400 segundos.
En IKEv1, la duración de las SA se negocia con el par remoto según el tipo de duración configurado en la propuesta de IKE. En IKEv2, dicha negociación no se realiza con el par remoto. En su lugar, cada par de IKE usa la duración configurada localmente para ellos.
En el caso de las SA de IKEv2, la duración es el valor predeterminado como IKEv1 (si no se configura otra duración en la propuesta de IKE) o todas las propuestas de IKEv2 de la política de IKE deben configurarse con el mismo valor de duración útil.
Para las propuestas de IKE, solo hay un valor de duración de SA, especificado por Junos OS. Las propuestas IPsec utilizan un mecanismo diferente.
Ejemplo: Configuración de una propuesta de ICR
Configure una propuesta de ICR:
[edit services ipsec-vpn ike]
proposal ike-proposal {
authentication-method pre-shared-keys;
dh-group group1;
authentication-algorithm sha1;
encryption-algorithm 3des-cbc;
}
Configuración de políticas de IKE
Una política de IKE define una combinación de parámetros de seguridad (propuestas de IKE) que se utilizarán durante la negociación de IKE. Define una dirección par y las propuestas necesarias para esa conexión. Según el método de autenticación que se utilice, define la clave previamente compartida para el par dado o el certificado local. Durante la negociación de IKE, IKE busca una política de IKE que sea la misma en ambos pares. El par que inicia la negociación envía todas sus políticas al par remoto y el remoto intenta encontrar una coincidencia.
Se realiza una coincidencia cuando ambas políticas de los dos pares tienen una propuesta que contiene los mismos atributos configurados. Si las duraciones no son idénticas, se utiliza la duración más corta entre las dos políticas (del host y del par). La clave previamente compartida configurada también debe coincidir con su par.
A partir de Junos OS versión 11.4, IKEv1 y IKEv2 son compatibles de forma predeterminada en todos los enrutadores serie M, serie MX y serie T. Puede configurar la fase de IKE específica para que se admita para la negociación. Sin embargo, si solo se admite IKEv1, Junos OS rechaza las negociaciones de IKEv2. Del mismo modo, si solo se admite IKEv2, Junos OS rechaza todas las negociaciones de IKEv1.
El daemon del proceso de administración de claves (kmd) determina qué versión de IKE se utiliza en una negociación. Si kmd es el iniciador de IKE, utiliza IKEv1 de forma predeterminada y conserva la versión configurada para las negociaciones. Si kmd es el respondedor de IKE, acepta conexiones de IKEv1 y IKEv2.
Puede crear varias propuestas con prioridad en cada par para asegurarse de que al menos una propuesta coincida con la propuesta de un par remoto.
En primer lugar, configure una o varias propuestas de IKE; a continuación, asocie estas propuestas con una política de ICR. También puede priorizar una lista de propuestas utilizadas por IKE en la declaración enumerando las propuestas que desea usar, de la primera a la policy última.
Para configurar una política de ICR, incluya la policy instrucción y especifique un nombre de política en el nivel jerárquico [edit services ipsec-vpn ike] :
[edit services ipsec-vpn ike] policy policy-name { description description; local-certificate identifier; local-id (ipv4_addr ipv4-address | ipv6-addr ipv6-address | key-id identifier); version (1 | 2); mode (aggressive | main); pre-shared-key (ascii-text key | hexadecimal key); proposals [ proposal-names ]; remote-id { any-remote-id; ipv4_addr [ values ]; ipv6_addr [ values ]; key_id [ values ]; } respond-bad-spi max-responses; }
En esta sección se incluyen los temas siguientes:
- Configuración de la fase de IKE
- Configuración del modo para una política de IKE
- Configuración de las propuestas en una política de IKE
- Configuración de la clave previamente compartida para una política de IKE
- Configuración del certificado local para una política de IKE
- Configuración de la descripción de una política de IKE
- Configuración de ID locales y remotos para la negociación de fase 1 de IKE
- Habilitación de la recuperación de SPI no válida
- Ejemplo: Configuración de una política de ICR
Configuración de la fase de IKE
A partir de Junos OS versión 11.4, IKEv1 y IKEv2 son compatibles de forma predeterminada en todos los enrutadores serie M, serie MX y serie T. Puede configurar la fase de IKE específica para que se admita para la negociación. Sin embargo, si solo se admite IKEv1, Junos OS rechaza las negociaciones de IKEv2. Del mismo modo, si solo se admite IKEv2, Junos OS rechaza todas las negociaciones de IKEv1.
Para configurar la fase de IKE utilizada, incluya la version instrucción en el nivel de [edit services ipsec-vpn ike policy policy-name] jerarquía:
[edit services ipsec-vpn ike policy policy-name] version (1 | 2);
Configuración del modo para una política de IKE
La política de IKE tiene dos modos: agresivo y principal. De forma predeterminada, el modo principal está habilitado. El modo principal utiliza seis mensajes, en tres intercambios, para establecer la SA de IKE. (Estos tres pasos son la negociación de SA de IKE, un intercambio Diffie-Hellman y la autenticación del par). El modo principal también permite que un par oculte su identidad.
El modo agresivo también establece una SA y claves de IKE autenticadas. Sin embargo, el modo agresivo usa la mitad del número de mensajes, tiene menos poder de negociación y no proporciona protección de identidad. El par puede usar el modo agresivo o principal para iniciar la negociación de IKE; El par remoto acepta el modo enviado por el par.
La configuración del modo solo es necesaria si la version opción está establecida en 1.
Para configurar el modo de una política de IKE, incluya la mode instrucción y especifique aggressive o main en el nivel de [edit services ipsec-vpn ike policy policy-name] jerarquía:
[edit services ipsec-vpn ike policy policy-name] mode (aggressive | main);
Configuración de las propuestas en una política de IKE
La política de ICR incluye una lista de una o más propuestas asociadas con una política de ICR.
Para configurar las propuestas en una política de IKE, incluya la proposals instrucción y especifique uno o varios nombres de propuesta en el nivel de [edit services ipsec-vpn ike policy policy-name] jerarquía:
[edit services ipsec-vpn ike policy policy-name] proposals [ proposal-names ];
Configuración de la clave previamente compartida para una política de IKE
Cuando se incluye la authentication-method pre-shared-keys instrucción en el nivel de jerarquía, las claves previamente compartidas de la política de IKE autentican a [edit services ipsec-vpn ike proposal proposal-name] los pares. Debe configurar manualmente una clave previamente compartida, la cual debe coincidir con la de su par. La clave previamente compartida puede ser una clave de texto ASCII (alfanumérica) o una clave hexadecimal.
Para configurar la clave previamente compartida en una política de IKE, incluya la pre-shared-key instrucción y una clave en el nivel de [edit services ipsec-vpn ike policy policy-name] jerarquía:
[edit services ipsec-vpn ike policy policy-name] pre-shared-key (ascii-text key | hexadecimal key);
La clave puede ser una de las siguientes:
ascii-text—Clave de texto ASCII. Con lades-cbcopción, la clave contiene 8 caracteres ASCII. Con la3des-cbcopción, la clave contiene 24 caracteres ASCII.hexadecimal—Clave hexadecimal. Con lades-cbcopción, la clave contiene 16 caracteres hexadecimales. Con la3des-cbcopción, la clave contiene 48 caracteres hexadecimales.
Configuración del certificado local para una política de IKE
Cuando se incluye la authentication-method rsa-signatures instrucción en el nivel de jerarquía, los certificados digitales de [edit services ipsec-vpn ike proposal proposal-name] infraestructura de clave pública (PKI) autentican a los pares. Debe identificar un certificado local que se envíe al par durante la fase de autenticación IKE.
Para configurar el certificado local para una política de IKE, incluya la local-certificate instrucción en el nivel de [edit services ipsec-vpn ike policy policy-name] jerarquía:
[edit services ipsec-vpn ike policy policy-name] local-certificate identifier;
La local-certificate instrucción especifica el identificador utilizado para obtener el certificado de la entidad final de la autoridad de certificación. Configurarlo en una política de IKE le permite la flexibilidad de usar un certificado independiente con cada par remoto si es necesario. También debe especificar la identidad de la autoridad de certificación configurando la ca-profile instrucción en el [edit security pki] nivel de jerarquía.
Puede utilizar los perfiles configurados para establecer un conjunto de autoridades de certificación de confianza para su uso con un conjunto de servicios determinado. Esto le permite configurar conjuntos de servicios independientes para clientes individuales a los que proporciona servicios IP; Los distintos conjuntos de servicios proporcionan la separación lógica de un conjunto de sesiones de IKE de otro, utilizando diferentes direcciones de puerta de enlace local o virtualización. Para configurar el conjunto de entidades de certificación de confianza, incluya la trusted-ca instrucción en el nivel de [edit services service-set service-set-name ipsec-vpn-options] jerarquía:
[edit services service-set service-set-name ipsec-vpn-options] trusted-ca ca-profile;
Consulte lo siguiente para configurar una lista de revocación de certificados:
Configuración de una lista de revocación de certificados
Una lista de revocación de certificados (CRL) contiene una lista de certificados digitales que se cancelaron antes de su fecha de caducidad. Cuando un par participante utiliza un certificado digital, comprueba la firma y la validez del certificado. También adquiere la CRL emitida más recientemente y comprueba que el número de serie del certificado no esté en esa CRL.
De forma predeterminada, la verificación de la lista de revocación de certificados está habilitada. Puede deshabilitar la comprobación de CRL incluyendo la disable instrucción en el nivel de [edit security pki ca-profile ca-profile-name revocation-check] jerarquía.
De forma predeterminada, si el enrutador no puede acceder a la URL del protocolo ligero de acceso a directorios (LDAP) o recuperar una lista de revocación de certificados válida, se producirá un error en la comprobación del certificado y no se establecerá el túnel IPsec. Para anular este comportamiento y permitir la autenticación del par IPsec cuando no se descarga la CRL, incluya la disable on-download-failure instrucción en el nivel de [edit security pki ca-profile ca-profile-name revocation-check crl] jerarquía.
Para usar la lista de revocación de certificados de AC, incluya instrucciones en el nivel jerárquico [edit security pki ca-profile ca-profile-name revocation-check] . Para obtener más información, consulte la Guía de configuración de conceptos básicos del sistema de Junos OS.
Configuración de la descripción de una política de IKE
Para especificar una descripción de texto opcional para una política de IKE, incluya la description instrucción en el nivel de [edit services ipsec-vpn ike policy policy-name jerarquía:
[edit services ipsec-vpn ike policy policy-name] description description;
Configuración de ID locales y remotos para la negociación de fase 1 de IKE
Opcionalmente, puede especificar identificadores locales para utilizarlos en la negociación de fase 1 de IKE. Si se omite la local-id instrucción, se utiliza la dirección de puerta de enlace local.
A partir de Junos OS versión 19.1R1, puede configurar uno de los tipos de ID local como nombre distintivo y puede configurar uno de los tipos de ID remoto como nombre distinguido. El campo de nombre distintivo puede ser un contenedor con valores de cadena de contenedor o un comodín con valores de cadena comodín.
Un nombre distintivo es un nombre que se utiliza con certificados digitales para identificar de forma exclusiva a un usuario. Por ejemplo, un nombre distintivo puede ser:
CN=usuario
DC=ejemplo
DC = com
Para la cadena de contenedor, el orden de los campos y sus valores deben coincidir exactamente con el nombre distintivo en el certificado digital del par. Ejemplo: container ["C=US, ST=CA, L=Sunnyvale, O=Juniper, CN=local_neg, CN=test@juniper.net, OU=QA" "cn=admin, ou=eng, o=example, dc=net" ];
Para la cadena comodín, el campo y el valor configurados deben coincidir con el nombre distintivo en el certificado digital del par, pero el orden de los campos en el DN no importa. Ejemplo: wildcard [ "L=Sunnyvale, O=Juniper" "C=US, ST=CA" ];
Para especificar uno o varios ID locales, incluya la local-id instrucción en el nivel de [edit services ipsec-vpn ike policy policy-name] jerarquía:
[edit services ipsec-vpn ike policy policy-name] local-id (distinguished-name container container-string-values |wildcard wildcard-string-values fqdn fqdn-name ipv4_addr ipv4-address | ipv6-addr ipv6-address | key-id identifier);
También puede especificar identificadores de puerta de enlace remota para los que se utiliza la política de IKE. La dirección de puerta de enlace remota en la que se define esta política se agrega de forma predeterminada.
Para especificar uno o varios ID remotos, incluya la remote-id instrucción en el nivel de [edit services ipsec-vpn ike policy policy-name] jerarquía:
[edit services ipsec-vpn ike policy policy-name] remote-id { distinguished-name container container-string-values |wildcard wildcard-string-values fqdn fqdn-name any-remote-id; ipv4_addr [ values ]; ipv6_addr [ values ]; key_id [ values ]; }
La any-remote-id opción permite que se conecte cualquier dirección remota. Esta opción solo se admite en configuraciones de puntos de conexión dinámicos y no se puede configurar junto con valores específicos.
Habilitación de la recuperación de SPI no válida
Cuando los pares de una asociación de seguridad (SA) quedan desincronizados, se pueden enviar paquetes con valores de índice de parámetros de seguridad (SPI) no válidos y el par receptor descarta estos paquetes. Por ejemplo, esto podría ocurrir cuando se reinicia uno de los pares. A partir de Junos OS versión 14.2, puede permitir que el dispositivo se recupere cuando se reciban paquetes con SPI no válidos mediante la resincronización de las SA.
Para habilitar la recuperación de valores SPI no válidos, incluya la respond-bad-spi instrucción en el nivel de [edit services ipsec-vpn ike policy] policy-name jerarquía:
[edit services ipsec-vpn ike policy policy-name] respond-bad-spi max-responses;
Ejemplo: Configuración de una política de ICR
Defina dos políticas de IKE: policy 10.1.1.2 y policy 10.1.1.1. Cada política está asociada con proposal-1 y proposal-2. La siguiente configuración solo utiliza IKEv1 para la negociación.
[edit services ipsec-vpn]
ike {
proposal proposal-1 {
authentication-method pre-shared-keys;
dh-group group1;
authentication-algorithm sha1;
encryption-algorithm 3des-cbc;
lifetime-seconds 1000;
}
proposal proposal-2 {
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm md5;
encryption-algorithm des-cbc;
lifetime-seconds 10000;
}
proposal proposal-3 {
authentication-method rsa-signatures;
dh-group group2;
authentication-algorithm md5;
encryption-algorithm des-cbc;
lifetime-seconds 10000;
}
policy 10.1.1.2 {
mode main;
proposals [ proposal-1 proposal-2 ];
pre-shared-key ascii-text example-pre-shared-key;
}
policy 10.1.1.1 {
local-certificate certificate-file-name;
local-key-pair private-public-key-file;
mode aggressive;
proposals [ proposal-2 proposal-3 ]
pre-shared-key hexadecimal 0102030abbcd;
}
}
Las actualizaciones de la propuesta de IKE actual y la configuración de política no se aplican a la SA de IKE actual; las actualizaciones se aplican a las nuevas SA de IKE.
Si desea que las nuevas actualizaciones surtan efecto de inmediato, debe borrar las asociaciones de seguridad de IKE existentes para que se restablezcan con la configuración cambiada. Para obtener más información sobre cómo borrar la asociación de seguridad IKE actual, consulte Borrar servicios IPsec-VPN IKE security-associations.
Configuración de propuestas IPsec
Una propuesta de IPsec enumera los protocolos y algoritmos (servicios de seguridad) que se negociarán con el par IPsec remoto.
Para configurar una propuesta IPsec, incluya la proposal instrucción y especifique un nombre de propuesta IPsec en el nivel de [edit services ipsec-vpn ipsec] jerarquía:
[edit services ipsec-vpn ipsec] proposal proposal-name { authentication-algorithm (hmac-md5-96 | hmac-sha1-96); description description; encryption-algorithm algorithm; lifetime-seconds seconds; protocol (ah | esp | bundle); }
En esta sección se tratan los siguientes temas:
- Configurar el algoritmo de autenticación para una propuesta IPsec
- Configurar la descripción de una propuesta IPsec
- Configurar el algoritmo de cifrado para una propuesta IPsec
- Configuración de la duración de una SA de IPsec
- Configuración del protocolo para una SA dinámica
Configurar el algoritmo de autenticación para una propuesta IPsec
Para configurar el algoritmo de autenticación de una propuesta IPsec, incluya la authentication-algorithm instrucción en el nivel de [edit services ipsec-vpn ipsec proposal proposal-name] jerarquía:
[edit services ipsec-vpn ipsec proposal proposal-name] authentication-algorithm (hmac-md5-96 | hmac-sha1-96);
El algoritmo de autenticación puede ser uno de los siguientes:
hmac-md5-96: algoritmo hash que autentica los datos del paquete. Produce un resumen de 128 bits. Solo se utilizan 96 bits para la autenticación.hmac-sha1-96: algoritmo hash que autentica los datos del paquete. Produce un resumen de 160 bits. Solo se utilizan 96 bits para la autenticación.hmac-sha-256-128: algoritmo hash que autentica los datos del paquete. Genera un valor de autenticador de 256 bits.
Tenga en cuenta los siguientes puntos al configurar el algoritmo de autenticación en una propuesta IPsec:
Cuando ambos extremos de un túnel VPN IPsec contienen la misma propuesta de ICR, pero diferentes propuestas de IPsec, se produce un error y el túnel no se establece en este escenario. Por ejemplo, si un extremo del túnel contiene el enrutador 1 configurado con el algoritmo de autenticación como hmac-sha- 256-128 y el otro extremo del túnel contiene el enrutador 2 configurado con el algoritmo de autenticación como hmac-md5-96, no se establece el túnel VPN.
Cuando ambos extremos de un túnel VPN IPsec contienen la misma propuesta de ICR pero diferentes propuestas de IPsec, y cuando un extremo del túnel contiene dos propuestas de IPsec para comprobar si se ha seleccionado o no un algoritmo menos seguro, se produce un error y el túnel no se establece. Por ejemplo, si configura dos algoritmos de autenticación para una propuesta de IPsec como hmac-sha-256-128 y hmac-md5-96 en un extremo del túnel, el enrutador 1, y si configura el algoritmo para una propuesta de IPsec como hmac-md5-96 en el otro extremo del túnel, el enrutador 2, el túnel no está establecido y el número de propuestas no coincide.
Cuando configure dos propuestas IPsec en ambos extremos de un túnel, como las
authentication-algorithm hmac-sha-256-128instrucciones andauthentication- algorithm hmac-md5-96en el[edit services ipsec-vpn ipsec proposal proposal-name]nivel de jerarquía en uno de los túneles, el enrutador 1 (con los algoritmos en dos instrucciones sucesivas para especificar el orden) y lasauthentication-algorithm hmac-md5-96instrucciones yauthentication- algorithm hmac-sha-256-128en el[edit services ipsec-vpn ipsec proposal proposal-name]nivel de jerarquía en uno de los túneles, el enrutador 2 (con los algoritmos en dos instrucciones sucesivas para especificar el orden, que es el orden inverso del enrutador 1), el túnel se establece en esta combinación como se esperaba porque el número de propuestas es el mismo en ambos extremos y contienen el mismo conjunto de algoritmos. Sin embargo, el algoritmo de autenticación seleccionado es hmac-md5-96 y no el algoritmo más seguro de hmac-sha-256-128. Este método de selección del algoritmo se produce porque se selecciona la primera propuesta de coincidencia. Además, para una propuesta predeterminada, independientemente de si el enrutador admite el algoritmo de cifrado Advanced Encryption Standard (AES), se elige el algoritmo 3des-cbc y no el algoritmo aes-cfb, lo cual se debe a que se selecciona el primer algoritmo de la propuesta predeterminada. En el escenario de ejemplo descrito aquí, en el enrutador 2, si invierte el orden de la configuración del algoritmo en la propuesta para que sea el mismo orden que el especificado en el enrutador 1, se selecciona hmac-sha-256-128 como método de autenticación.Debe tener en cuenta el orden de las propuestas en una política de IPsec en el momento de la configuración si desea que la coincidencia de propuestas se produzca en un orden de preferencia determinado, como el algoritmo más seguro que se considerará primero cuando se realice una coincidencia cuando ambas políticas de los dos pares tengan una propuesta.
Configurar la descripción de una propuesta IPsec
Para especificar una descripción de texto opcional para una propuesta IPsec, incluya la description instrucción en el nivel de [edit services ipsec-vpn ipsec proposal proposal-name] jerarquía:
[edit services ipsec-vpn ipsec proposal proposal-name] description description;
Configurar el algoritmo de cifrado para una propuesta IPsec
Para configurar el algoritmo de cifrado para una propuesta IPsec, incluya la encryption-algorithm instrucción en el nivel de [edit services ipsec-vpn ipsec proposal proposal-name] jerarquía:
[edit services ipsec-vpn ipsec proposal proposal-name] encryption-algorithm algorithm;
El algoritmo de cifrado puede ser uno de los siguientes:
3des-cbc—Algoritmo de cifrado que tiene un tamaño de bloque de 24 bytes; Su tamaño de clave es de 192 bits de largo.aes-128-cbc—Algoritmo de cifrado de 128 bits del Estándar de cifrado avanzado (AES).aes-192-cbc—Algoritmo de cifrado de 192 bits del Estándar de cifrado avanzado (AES).aes-256-cbc—Algoritmo de cifrado de 256 bits del Estándar de cifrado avanzado (AES).
En el modo FIPS de Junos, AES-GCM no se admite en Junos OS versión 17.3R1. A partir de la versión 17.4R1 de Junos OS, AES-GCM se admite en el modo FIPS de Junos.
aes-128-gcm—A partir de la versión 17.3R1 de Junos OS para MS-MPC y MS-MIC, algoritmo de cifrado de 128 bits con un valor de comprobación de integridad (ICV) de 16 octetos.aes-192-gcm—A partir de la versión 17.3R1 de Junos OS para MS-MPC y MS-MIC, algoritmo de cifrado de 192 bits del estándar de cifrado avanzado en modo Galois/Counter (AES-GCM) con un ICV de valor de comprobación de integridad de 16 octetos.aes-256-gcm—A partir de la versión 17.3R1 de Junos OS para MS-MPC y MS-MIC, algoritmo de cifrado de 256 bits del estándar de cifrado avanzado en modo Galois/Counter (AES-GCM) con un ICV de valor de comprobación de integridad de 16 octetos.des-cbc—Algoritmo de cifrado que tiene un tamaño de bloque de 8 bytes; Su tamaño de clave es de 48 bits.
Para obtener una lista de las claves débiles y semidébiles del algoritmo de cifrado del Estándar de cifrado de datos (DES), consulte RFC 2409, El intercambio de claves por red (IKE). Los algoritmos de cifrado AES utilizan una implementación de software que tiene una transferencia de datos mucho menor, por lo que DES sigue siendo la opción recomendada.
Para 3des-cbc, los primeros 8 bytes deben diferir de los segundos 8 bytes y los segundos 8 bytes deben ser iguales a los terceros 8 bytes.
Si no configura ajustes específicos de autenticación o cifrado, Junos OS utilizará los valores predeterminados de sha1 para la autenticación y 3des-cbc para el cifrado. Para que el cifrado NULL sea eficaz, siempre debe especificar el protocolo de carga de Seguridad de encapsulación (ESP) para el algoritmo de cifrado NULL incluyendo la protocol esp instrucción en el [edit services ipsec-vpn ipsec proposal proposal-name] nivel de jerarquía, independientemente de otras configuraciones del sistema.
Configuración de la duración de una SA de IPsec
Cuando se crea una SA de IPsec dinámica, se utilizan dos tipos de duraciones de duración: dura y blanda. La duración estricta especifica la vida útil de la SA. La duración suave, que se deriva de la duración estricta, informa al sistema de administración de claves IPsec que la SA está a punto de caducar. Esto permite que el sistema de administración de claves negocie una nueva SA antes de que expire la duración del hardware.
En IKEv1, la duración de las SA se negocia con el par remoto según el tipo de duración configurado en la propuesta de IPsec. En IKEv2, dicha negociación no se realiza con el par remoto. En su lugar, cada par de IKE usa la duración configurada localmente para ellos.
En el caso de las SA de IKEv2, la duración es el valor predeterminado como IKEv1 (si no se configura otra duración en la propuesta de IPsec) o todas las propuestas de IKEv2 de la política de IPsec deben configurarse con el mismo valor de duración de la vida.
Para configurar el valor de duración dura, incluya la lifetime-seconds instrucción y especifique el número de segundos en el [edit services ipsec-vpn ipsec proposal proposal-name] nivel de jerarquía:
[edit services ipsec-vpn ipsec proposal proposal-name] lifetime-seconds seconds;
La duración predeterminada es de 28.800 segundos. El rango es de 180 a 86,400 segundos.
Para calcular la vida útil suave, se calcula inicialmente la diferencia de vida útil. Luego, en función de si el par es el iniciador o el respondedor, se calcula la duración de la vida útil suave.
El cálculo de la diferencia de vida útil se realiza de la siguiente manera:
-
Si (3*hard-lifetime)/10 es MAYOR que 850 segundos, entonces lifetime-diff = 850 segundos + fluctuación entre 0 y 850 segundos.
Nota:El valor de fluctuación aumenta de 0 a 850 en cada instalación de SA IPsec y se restablecerá a 0.
-
Si (3*hard-lifetime)/10 es MAYOR que 600 segundos y MENOS que 850, entonces lifetime-diff = 600 segundos + fluctuación aleatoria entre 0 y 45 segundos.
-
Si (3*hard-lifetime)/10 es MAYOR que 90 segundos y MENOR que 600, entonces lifetime-diff = 90 segundos + fluctuación aleatoria entre 0 y 45 segundos.
-
Si (3*hard-lifetime)/10 es MENOS de 90 segundos, entonces lifetime-diff = 90 segundos + fluctuación aleatoria entre 0 y 10 segundos.
En función de la diferencia de vida útil, la vida útil suave se calcula de la siguiente manera:
-
Si la diferencia de vida útil es MAYOR que la vida útil dura, la vida útil suave = (9*vida útil dura)/10
-
Vida útil suave del iniciador = vida útil dura - diferencia de vida útil
-
Respuesta suave de vida útil = vida útil dura - diferencia de vida útil + 45 segundos
La vida útil suave del iniciador siempre será menor que la vida útil suave del respondedor. Es para garantizar que la vida útil del software del iniciador expire primero para que pueda iniciar el proceso de regeneración de claves.
Por ejemplo, si la duración dura se configura como 3600 segundos para SA IPSec:
-
La duración máxima suave del iniciador es: 3600 - 850 (la fluctuación es igual a 0) = 2750 segundos
-
La duración mínima suave del iniciador es: 3600 - 850 - 850 (la fluctuación es igual a 850) = 1900 segundos
-
La duración máxima de la respuesta suave es: 3600 - 850 (la fluctuación es igual a 0) + 45 = 2795 segundos
-
La duración mínima del respondedor suave es: 3600 - 850 - 850 (la fluctuación es igual a 850) + 45 = 1945 segundos
Configuración del protocolo para una SA dinámica
La protocol instrucción establece el protocolo para una SA dinámica. IPsec utiliza dos protocolos para proteger el tráfico IP: ESP y AH. El protocolo ESP puede admitir autenticación, cifrado o ambos. El protocolo AH se utiliza para una autenticación sólida. AH también autentica el paquete IP. La bundle opción utiliza autenticación AH y cifrado ESP; no utiliza autenticación ESP porque AH proporciona una autenticación más segura de los paquetes IP.
Para configurar el protocolo de una SA dinámica, incluya la protocol instrucción y especifique la opción , espo bundle en ahel nivel jerárquico[edit services ipsec-vpn ipsec proposal proposal-name]:
[edit services ipsec-vpn ipsec proposal proposal-name] protocol (ah | esp | bundle);
Configuración de políticas IPsec
Una política de IPsec define una combinación de parámetros de seguridad (propuestas de IPsec) que se utilizan durante la negociación de IPsec. Define la confidencialidad directa perfecta (PFS) y las propuestas necesarias para la conexión. Durante la negociación de IPsec, IPsec busca una propuesta que sea la misma en ambos pares. El par que inicia la negociación envía todas sus políticas al par remoto y el remoto intenta encontrar una coincidencia.
Se realiza una coincidencia cuando ambas políticas de los dos pares tienen una propuesta que contiene los mismos atributos configurados. Si las duraciones no son idénticas, se utiliza la duración más corta entre las dos políticas (del host y del par).
Puede crear varias propuestas IPsec priorizadas en cada par para asegurarse de que al menos una propuesta coincida con la propuesta de un par remoto.
En primer lugar, configure una o varias propuestas de IPsec; A continuación, asocie estas propuestas a una política IPsec. Puede priorizar una lista de propuestas usadas por IPsec en la instrucción enumerando las propuestas que desea usar, de la primera a la policy última.
Para configurar una política IPsec, incluya la policy instrucción y especifique el nombre de la política y una o varias propuestas que se van a asociar a la política en el [edit services ipsec-vpn ipsec] nivel jerárquico:
[edit services ipsec-vpn ipsec] policy policy-name { description description; perfect-forward-secrecy { keys (group1 | group2 | group5 | group14 |group15 |group16 | group24); } proposals [ proposal-names ]; }
En esta sección, se incluyen los siguientes temas relacionados con la configuración de una política IPsec:
- Configurar la descripción de una política IPsec
- Configuración de la confidencialidad directa perfecta
- Configurar las propuestas en una política IPsec
- Política IPsec para puntos de conexión dinámicos
- Ejemplo: Configuración de una política IPsec
Configurar la descripción de una política IPsec
Para especificar una descripción de texto opcional para una política IPsec, incluya la description instrucción en el nivel de [edit services ipsec-vpn ipsec policy policy-name] jerarquía:
[edit services ipsec-vpn ipsec policy policy-name] description description;
Configuración de la confidencialidad directa perfecta
La confidencialidad directa perfecta (PFS) proporciona seguridad adicional por medio de un valor secreto compartido Diffie-Hellman. Con PFS, si una clave está comprometida, las claves anteriores y posteriores están protegidas porque no se derivan de claves anteriores. Esta instrucción es opcional.
Para configurar PFS, incluya la perfect-forward-secrecy instrucción y especifique un grupo Diffie-Hellman en el [edit services ipsec-vpn ipsec policy policy-name] nivel de jerarquía:
[edit services ipsec-vpn ipsec policy policy-name] perfect-forward-secrecy { keys (group1 | group2 | group5 | group14 | group15 |group16 | group24); }
La clave puede ser una de las siguientes:
group1: especifica que IKE utilice el grupo de módulos principales Diffie-Hellman de 768 bits al realizar el nuevo intercambio Diffie-Hellman.group2: especifica que IKE utilice el grupo de módulos principales Diffie-Hellman de 1024 bits al realizar el nuevo intercambio Diffie-Hellman.group5: especifica que IKE utilice el grupo de módulos principales Diffie-Hellman de 1536 bits al realizar el nuevo intercambio Diffie-Hellman.group14: especifica que IKE utilice el grupo de módulos principales Diffie-Hellman de 2048 bits al realizar el nuevo intercambio Diffie-Hellman.
A partir de la versión 17.4R1 de Junos OS, el grupo 15, el grupo 16 y el grupo 24 también se pueden usar para la clave:
group15: especifica que IKE utilice el grupo de módulos principales Diffie-Hellman de 3072 bits al realizar el nuevo intercambio Diffie-Hellman.group16: especifica que IKE utilice el grupo de módulos principales Diffie-Hellman de 4096 bits al realizar el nuevo intercambio Diffie-Hellman.group24: especifica que IKE utilice el grupo de módulos principales Diffie-Hellman de 2048 bits con un subgrupo de orden principal de 256 bits al realizar el nuevo intercambio Diffie-Hellman.
Los grupos con números más altos proporcionan más seguridad que los grupos con números reducidos, pero requieren más tiempo de procesamiento.
Configurar las propuestas en una política IPsec
La política de IPsec incluye una lista de una o más propuestas asociadas con una política de IPsec.
Para configurar las propuestas en una política IPsec, incluya la proposals instrucción y especifique uno o varios nombres de propuesta en el nivel de [edit services ipsec-vpn ipsec policy policy-name] jerarquía:
[edit services ipsec-vpn ipsec policy policy-name] proposals [ proposal-names ];
Política IPsec para puntos de conexión dinámicos
Una política de IPsec para puntos de conexión dinámicos define una combinación de parámetros de seguridad (propuestas de IPsec) que se utilizan durante la negociación de IPsec entre puertas de enlace de seguridad de pares dinámicos, en la que los extremos remotos de los túneles no tienen una dirección IP asignada estáticamente. Durante la negociación de IPsec, la política de IPsec busca una propuesta de IPsec que sea la misma en ambos pares. El par que inicia la negociación envía todas sus políticas al par remoto y el remoto intenta encontrar una coincidencia. Se realiza una coincidencia cuando las políticas de los dos pares tienen una propuesta que contiene los mismos atributos configurados. Si las duraciones no son idénticas, se utiliza la duración más corta entre las dos políticas (del host y del par).
Si no se establece ninguna política, se acepta cualquier política propuesta por el par dinámico.
Ejemplo: Configuración de una política IPsec
Defina una política IPsec, dynamic policy-1, que se asocie con dos propuestas (dynamic-1 y dynamic-2):
[edit services ipsec-vpn ipsec]
proposal dynamic-1 {
protocol esp;
authentication-algorithm hmac-md5-96;
encryption-algorithm 3des-cbc;
lifetime-seconds 6000;
}
proposal dynamic-2 {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm 3des-cbc;
lifetime-seconds 6000;
}
policy dynamic-policy-1 {
perfect-forward-secrecy {
keys group1;
}
proposals [ dynamic-1 dynamic-2 ];
}
Las actualizaciones de la propuesta de IPsec actual y la configuración de política no se aplican a la SA de IPsec actual; las actualizaciones se aplican a las nuevas SA de IPsec.
Si desea que las nuevas actualizaciones surtan efecto de inmediato, debe borrar las asociaciones de seguridad IPsec existentes para que se restablezcan con la configuración cambiada. Para obtener información acerca de cómo borrar la asociación de seguridad IPsec actual, consulte la Referencia de comandos de Conceptos básicos y servicios del sistema de Junos OS.
Tabla de historial de cambios
La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.