EN ESTA PÁGINA
Información general sobre IPsec
Descripción general de las asociaciones de seguridad
Para utilizar los servicios de seguridad IPsec , cree SAentre hosts. Una SA es una conexión simplex que permite que dos hosts se comuniquen entre sí de forma segura mediante IPsec. Hay dos tipos de SA: manuales y dinámicas.
Las SA manuales no requieren negociación; Todos los valores, incluidas las claves, son estáticos y se especifican en la configuración. Las SA manuales definen estáticamente los valores, algoritmos y claves del índice de parámetros de seguridad (SPI) que se van a utilizar, y requieren configuraciones coincidentes en ambos extremos del túnel. Cada par debe tener las mismas opciones configuradas para que la comunicación tenga lugar.
Las SA dinámicas requieren una configuración adicional. Con las SA dinámicas, primero se configura IKE y, a continuación, la SA. IKE crea asociaciones de seguridad dinámicas; negocia SA para IPsec. La configuración de IKE define los algoritmos y las claves utilizados para establecer la conexión IKE segura con la puerta de enlace de seguridad del mismo nivel. A continuación, esta conexión se utiliza para acordar dinámicamente claves y otros datos utilizados por la SA IPsec dinámica. La SA de IKE se negocia primero y, a continuación, se utiliza para proteger las negociaciones que determinan las SA IPsec dinámicas.
Configure túneles o SA a nivel de usuario, incluidas las negociaciones de atributos de túnel y la administración de claves. Estos túneles también se pueden actualizar y terminar en la parte superior del mismo canal seguro.
La implementación de IPsec de Junos OS admite dos modos de seguridad (modo de transporte y modo de túnel).
Ver también
Descripción general del protocolo de administración de claves IKE
IKE es un protocolo de administración de claves que crea SAdinámicas; negocia SA para IPsec. Una configuración de IKE define los algoritmos y las claves utilizados para establecer una conexión segura con una puerta de enlace de seguridad del mismo nivel.
IKE hace lo siguiente:
Negocia y administra parámetros de IKE e IPsec
Autentica el intercambio seguro de claves
Proporciona autenticación mutua entre pares por medio de secretos compartidos (no contraseñas) y claves públicas
Proporciona protección de identidad (en modo principal)
IKE se desarrolla en dos fases. En la primera fase, negocia atributos de seguridad y establece secretos compartidos para formar la SA IKE bidireccional. En la segunda fase, se establecen las SA IPsec entrantes y salientes. La SA de IKE asegura los intercambios en la segunda fase. IKE también genera material de claves, proporciona Perfect Forward Secrecy e intercambia identidades.
A partir de Junos OS versión 14.2, cuando se realiza un recorrido SNMP del objeto jnxIkeTunnelEntry en la tabla jnxIkeTunnelTable, es posible que se genere el mensaje de Request failed: OID not increasing
error. Este problema sólo se produce cuando se crean asociaciones de seguridad de intercambio de claves por Internet (SA de IKE) simultáneas, que se produce cuando ambos extremos de la SA inician negociaciones de SA de IKE al mismo tiempo. Cuando se realiza un recorrido SNMP MIB para mostrar SA de IKE, la herramienta snmpwalk espera que los identificadores de objeto (OID) estén en orden creciente. Sin embargo, en el caso de SA de IKE simultáneas, es posible que los OID de la tabla SNMP no estén en orden creciente. Este comportamiento se produce porque los identificadores de túnel, que forman parte de los OID, se asignan en función del iniciador de la SA de IKE, que puede estar a ambos lados del túnel de IKE.
A continuación se muestra un ejemplo de un recorrido SNMP MIB que se realiza en SA simultáneas IKE:
jnxIkeTunLocalRole."ipsec_ss_cust554".ipv4."192.0.2.41".47885 = INTEGER: responder(2) >>> This is Initiator SA jnxIkeTunLocalRole."ipsec_ss_cust554".ipv4."192.0.2.41".47392 = INTEGER: initiator(1) >>> This is Responder's SA
La comparación del OID falla cuando el recorrido SNMP es el ID de túnel (47885 y 47392). Cuando se realiza una caminata SNMP, no se puede garantizar que los ID de túnel estén en orden creciente, ya que los túneles pueden iniciarse desde cualquier lado.
Para evitar este problema, el paseo SNMP MIB contiene una opción, -Cc, para deshabilitar la comprobación de OID crecientes. A continuación se muestra un ejemplo de la caminata MIB realizada en la tabla jnxIkeTunnelEntry con la opción -Cc:
snmpwalk -Os -Cc -c public -v 1 vira jnxIkeTunnelEntry
Ver también
Requisitos de IPsec para Junos-FIPS
En un entorno Junos-FIPS, las configuraciones de hardware con dos motores de enrutamientodeben configurarse para usar IPsec y una instancia de enrutamiento privada para todas las comunicaciones entre los motores de enrutamiento. También se requiere comunicación IPsec entre los motores de enrutamiento y las PIC FIPS del AS II.
Ver también
Información general sobre IPsec
La seguridad IP (IPsec) es un marco basado en estándares para garantizar una comunicación privada segura a través de redes IP. IPsec proporciona una forma segura de autenticar remitentes y cifrar el tráfico IP versión 4 (IPv4) y versión 6 (IPv6) entre dispositivos de red, como enrutadores y hosts. IPsec incluye la integridad de datos, la autenticación del remitente, la confidencialidad de los datos de origen y la protección contra la reproducción de datos.
Los conceptos principales que debe comprender son los siguientes:
Tarjetas de línea habilitadas para IPsec
La primera elección que debe hacer al implementar IPsec en un enrutador basado en Junos OS es el tipo de tarjeta de línea que desea utilizar. La tarjeta de línea de términos incluye tarjetas de interfaz física (PIC), tarjetas de interfaz modular (MIC), concentradores de puerto denso (DPC) y concentradores de puertos modulares (MPC). Las siguientes tarjetas de línea admiten la implementación de IPsec.
Consulte la documentación de hardware específica del enrutador para determinar si las tarjetas de línea de ese enrutador admiten IPsec.
Las siguientes tarjetas de línea admiten IPsec:
La PIC de servicios de cifrado (ES) proporciona servicios de cifrado y compatibilidad de software para IPsec.
La PIC de Adaptive Services (AS) y la PIC de Adaptive Services (AS) II proporcionan servicios IPsec y otros servicios, como la traducción de direcciones de red (NAT) y el firewall de estado.
El PIC de los estándares federales de procesamiento de información (FIPS) del AS II es una versión especial del PIC del AS que se comunica de forma segura con el motor de enrutamiento mediante IPsec interno. Debe configurar IPsec en la PIC FIPS AS II cuando habilite el modo FIPS en el enrutador. Para obtener más información acerca de la implementación de IPsec en una PIC FIPS As II instalada en un enrutador configurado en modo FIPS, consulte la Guía de configuración segura para Common Criteria y Junos-FIPS.
Las PIC multiservicios proporcionan aceleración de hardware para una matriz de servicios de procesamiento intensivo de paquetes. Estos servicios incluyen servicios IPsec y otros servicios, como firewall de estado, NAT, IPsec, detección de anomalías y servicios de túnel.
Los concentradores de puerto denso (DPC) multiservicios proporcionan servicios IPsec.
Los concentradores de puertos modulares multiservicios (MS-MPC) admiten servicios IPsec.
Las tarjetas de interfaz modular multiservicios (MS-MIC) admiten servicios IPsec.
Los paquetes del proveedor de extensiones de Junos OS, incluido el paquete de servicio IPsec, vienen preinstalados y preconfigurados en MS-MPC y MS-MIC.
Ver también
Algoritmos de autenticación
La autenticación es el proceso de verificar la identidad del remitente. Los algoritmos de autenticación utilizan una clave compartida para comprobar la autenticidad de los dispositivos IPsec. Junos OS utiliza los siguientes algoritmos de autenticación:
Message Digest 5 (MD5) utiliza una función hash unidireccional para convertir un mensaje de longitud arbitraria en un resumen de mensaje de longitud fija de 128 bits. Debido al proceso de conversión, es matemáticamente inviable calcular el mensaje original calculándolo hacia atrás a partir del resumen del mensaje resultante. Del mismo modo, un cambio a un solo carácter en el mensaje hará que genere un número de resumen del mensaje muy diferente.
Para comprobar que el mensaje no ha sido manipulado, Junos OS compara el resumen del mensaje calculado con un resumen del mensaje que se descifra con una clave compartida. Junos OS utiliza la variante de código de autenticación de mensajes hash (HMAC) MD5 que proporciona un nivel adicional de hash. MD5 se puede usar con encabezado de autenticación (AH), carga de seguridad encapsuladora (ESP) e intercambio de claves por Internet (IKE).
El algoritmo de hash seguro 1 (SHA-1) utiliza un algoritmo más sólido que MD5. SHA-1 toma un mensaje de menos de 264 bits de longitud y produce un resumen de mensaje de 160 bits. El resumen de mensaje grande garantiza que los datos no se hayan modificado y que se originen en la fuente correcta. Junos OS utiliza la variante HMAC SHA-1 que proporciona un nivel adicional de hash. SHA-1 se puede usar con AH, ESP e IKE.
SHA-256, SHA-384 y SHA-512 (a veces agrupados bajo el nombre SHA-2) son variantes de SHA-1 y usan resúmenes de mensajes más largos. Junos OS es compatible con la versión SHA-256 de SHA-2, que puede procesar todas las versiones del cifrado Estándar de cifrado avanzado (AES), Estándar de cifrado de datos (DES) y Triple DES (3DES).
Algoritmos de cifrado
El cifrado codifica los datos en un formato seguro para que no puedan ser descifrados por usuarios no autorizados. Al igual que los algoritmos de autenticación, una clave compartida se usa con algoritmos de cifrado para comprobar la autenticidad de los dispositivos IPsec. Junos OS utiliza los siguientes algoritmos de cifrado:
El encadenamiento de bloques de cifrado estándar de cifrado de datos (DES-CBC) es un algoritmo simétrico de bloques de clave secreta. DES utiliza un tamaño de clave de 64 bits, donde se utilizan 8 bits para la detección de errores y los 56 bits restantes proporcionan cifrado. DES realiza una serie de operaciones lógicas simples en la clave compartida, incluidas permutaciones y sustituciones. CBC toma el primer bloque de 64 bits de salida de DES, combina este bloque con el segundo bloque, lo devuelve al algoritmo DES y repite este proceso para todos los bloques posteriores.
Triple DES-CBC (3DES-CBC) es un algoritmo de cifrado que es similar a DES-CBC, pero proporciona un resultado de cifrado mucho más fuerte porque utiliza tres claves para el cifrado de 168 bits (3 x 56 bits). 3DES funciona utilizando la primera clave para cifrar los bloques, la segunda clave para descifrar los bloques y la tercera clave para volver a cifrar los bloques.
Advanced Encryption Standard (AES) es un método de cifrado de próxima generación basado en el algoritmo Rijndael desarrollado por los criptógrafos belgas Dr. Joan Daemen y Dr. Vincent Rijmen. Utiliza un bloque de 128 bits y tres tamaños de clave diferentes (128, 192 y 256 bits). Según el tamaño de la clave, el algoritmo realiza una serie de cálculos (10, 12 o 14 rondas) que incluyen sustitución de bytes, mezcla de columnas, desplazamiento de filas y adición de claves. El uso de AES junto con IPsec se define en RFC 3602, El algoritmo de cifrado AES-CBC y su uso con IPsec.
A partir de Junos OS versión 17.3R1, se admite el estándar de cifrado avanzado en modo Galois/Counter (AES-GCM) para MS-MPC y MS-MIC. Sin embargo, en el modo FIPS de Junos, AES-GCM no se admite en Junos OS versión 17.3R1. A partir de Junos OS versión 17.4R1, AES-GCM se admite en el modo FIPS de Junos. AES-GCM es un algoritmo de cifrado autenticado diseñado para proporcionar autenticación y privacidad. AES-GCM utiliza hashing universal sobre un campo binario de Galois para proporcionar cifrado autenticado y permite el cifrado autenticado a velocidades de datos de decenas de Gbps.
Ver también
Protocolos IPsec
Los protocolos IPsec determinan el tipo de autenticación y cifrado que se aplica a los paquetes protegidos por el enrutador. Junos OS admite los siguientes protocolos IPsec:
AH: definido en RFC 2402, AH proporciona integridad sin conexión y autenticación de origen de datos para paquetes IPv4 e IPv6. También proporciona protección contra repeticiones. AH autentica la mayor cantidad posible del encabezado IP, así como los datos de protocolo de nivel superior. Sin embargo, algunos campos de encabezado IP pueden cambiar durante el tránsito. Dado que el valor de estos campos puede no ser predecible para el remitente, no se pueden proteger mediante AH. En un encabezado IP, AH se puede identificar con un valor de
51
en elProtocol
campo de un paquete IPv4 y elNext Header
campo de un paquete IPv6. En la figura 1 se muestra un ejemplo de la protección IPsec que ofrece AH.Nota:AH no es compatible con los enrutadores serie T, M120 y M320.

ESP: definido en RFC 2406, ESP puede proporcionar cifrado y confidencialidad de flujo de tráfico limitado, o integridad sin conexión, autenticación de origen de datos y un servicio antireproducción. En un encabezado IP, ESP se puede identificar un valor de
50
en elProtocol
campo de un paquete IPv4 y elNext Header
campo de un paquete IPv6. En la figura 2 se muestra un ejemplo de la protección IPsec que ofrece ESP.

Paquete: cuando se compara AH con ESP, hay algunos beneficios y deficiencias en ambos protocolos. ESP proporciona un nivel decente de autenticación y cifrado, pero lo hace solo para parte del paquete IP. Por el contrario, aunque AH no proporciona cifrado, sí proporciona autenticación para todo el paquete IP. Debido a esto, Junos OS ofrece una tercera forma de protocolo IPsec llamado paquete de protocolos. La opción de paquete ofrece una combinación híbrida de autenticación AH con cifrado ESP.
Ver también
Tabla de historial de cambios
La compatibilidad con las funciones viene determinada por la plataforma y la versión que esté utilizando. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.
Request failed: OID not increasing
error.