ANTIRREPETICIÓN DE IPSEC
¿Por qué un paquete cifrado puede seguir siendo una repetición?
Un texto cifrado copiado puede volver a llegar sin haber sido modificado. La protección antirrepetición de ESP vincula los números de secuencia a una asociación de seguridad, comprueba una ventana de recepción acotada y confirma el estado después de la autenticación. La protección se aplica a los extremos del túnel seleccionados; los comandos de la aplicación siguen necesitando sus propias reglas sobre duplicados y temporización.
Extremos del túnel
Las pasarelas que actúan como extremos autentican el tráfico; el conmutador intermedio lo reenvía.
Ventana de secuencia
Una secuencia no vista dentro de la ventana puede someterse a comprobación; los duplicados se descartan.
Confirmar después de verificar
Solo un paquete autenticado hace avanzar el estado de recepción de confianza.
Identificar los extremos y el alcance.
Confirmar el protocolo y los ajustes reales.
Realizar pruebas con datos inocuos y autorización.
Lista de comprobación para la selección y la verificación — desplegar
Identificar los extremos y la SA; confirmar los ajustes antirrepetición; probar paquetes reordenados, duplicados y no válidos con datos inocuos y autorización.
Un enlace de datos remoto está cifrado; entonces, ¿por qué una pasarela de seguridad sigue registrando los números de secuencia de los paquetes? Impedir que terceros lean un mensaje y evitar que el mismo mensaje se acepte de nuevo son objetivos distintos. Alguien puede copiar un paquete legítimo y volver a enviarlo sin comprender su contenido. La protección antirrepetición proporciona al receptor un registro de los paquetes que ya ha aceptado.
Un paquete sin modificaciones puede seguir siendo un duplicado
Imagine una orden de trabajo sellada. El sello puede ayudar a demostrar que el contenido no se ha modificado, pero no demuestra por sí solo que esa misma orden no se haya entregado ya. Del mismo modo, un paquete cifrado capturado puede enviarse de nuevo sin que el atacante lo descifre ni cree un comando válido nuevo.
Esta analogía explica únicamente la entrega repetida. Los protocolos reales utilizan claves y algoritmos de autenticación. La confidencialidad, la integridad y la protección antirrepetición responden a necesidades distintas. La detección de errores de Ethernet no sustituye a la autenticación criptográfica: detectar errores de transmisión es distinto de comprobar si un paquete fue creado por alguien que posee la clave adecuada.
Una descripción de producto que mencione el cifrado no establece por sí sola cómo se rechazan los paquetes antiguos. Identifique el protocolo, sus extremos de seguridad reales, los ajustes negociados y las comprobaciones del receptor. Este artículo utiliza IPsec ESP como ejemplo; no atribuye capacidad antirrepetición a todos los dispositivos industriales del trayecto.
Localice los dos extremos que mantienen el registro
IPsec puede proteger el tráfico a través de una red IP, y ESP es uno de sus mecanismos de protección de paquetes. Una asociación de seguridad, o SA, es un conjunto de disposiciones de protección para un sentido, que incluye las claves, los algoritmos y el estado correspondientes. Los registros de ambos sentidos no deben tratarse como un único contador compartido.
El emisor numera los paquetes pertenecientes a una SA. El receptor selecciona la asociación correspondiente y comprueba su propio registro; no compara un número con todos los dispositivos de la red. El índice de parámetros de seguridad (SPI) de ESP ayuda a identificar la asociación, mientras que su número de secuencia permite realizar las comprobaciones antirrepetición. Estos campos deben recibir la protección de integridad correspondiente.
Un servidor serie, un conmutador Ethernet industrial y una pasarela de seguridad externa pueden estar presentes en el mismo enlace. El servidor de dispositivos serie FCT-1100-F1S1 de Feichang aporta el contexto de un producto real de conversión de serie a red; esto no afirma que implemente IPsec. Si las pasarelas externas son los extremos del túnel, ellas realizan las comprobaciones de los extremos. Un conmutador de reenvío ordinario no adquiere automáticamente una ventana antirrepetición.
¿Por qué no aceptar solo números superiores al último?
Los paquetes no siempre llegan en el orden en que se enviaron. Los trayectos, las colas y el procesamiento paralelo pueden hacer que un paquete posterior llegue primero. Un receptor que rechace todos los números inferiores al mayor número registrado podría descartar tráfico legítimo retrasado. La comprobación debe reconocer los duplicados y, al mismo tiempo, tolerar cierto reordenamiento.
Imagine una ventana deslizante como un conjunto de posiciones numeradas. Cada posición registra si un paquete con ese número de secuencia ya se ha autenticado y aceptado; no almacena el paquete completo. El extremo superior sigue el mayor número autenticado y el extremo inferior limita hasta dónde puede llegar fuera de orden un paquete no visto. Un paquete demasiado antiguo se descarta.
Como ejemplo didáctico, supongamos que la ventana contiene los números del 101 al 108 y que ya se ha aceptado el 106. Un segundo 106 es un duplicado. Si el 105 no se ha visto, puede pasar a la autenticación. Las ocho posiciones son solo una ilustración, no un tamaño de ventana estándar ni una especificación de un producto Feichang.
Desplace la ventana solo después de que la autenticación sea satisfactoria
Cuando llega el paquete 109, el receptor no debe hacer avanzar su registro simplemente porque el número sea mayor. De lo contrario, un atacante podría falsificar un número muy grande y dejar el tráfico legítimo fuera de la ventana. El orden de las comprobaciones importa más que memorizar la expresión «deslizar la ventana».
Una implementación puede realizar primero una comprobación preliminar de la secuencia y descartar un duplicado evidente o un paquete antiguo. Un paquete admisible aún debe superar la comprobación de integridad o autenticación correspondiente. Solo después de superarla se registra como recibido y se hace avanzar la ventana si es necesario. Una comprobación preliminar no convierte el paquete en fiable.
Un paquete que no supere la autenticación no debe ocupar una nueva posición ni hacer avanzar el mayor número autenticado. Los distintos algoritmos e implementaciones pueden organizar el trabajo interno de formas diferentes. La distinción esencial está entre el filtro inicial, la validación criptográfica y la confirmación del estado. Un número mayor por sí solo no autoriza la entrega.
La pérdida, el reordenamiento y la repetición pueden parecer similares
La ventana puede aceptar un número no visto que llegue dentro de su rango, pero no puede aceptar tráfico con un retraso arbitrariamente grande. Un reordenamiento intenso puede dejar un paquete legítimo por debajo del límite inferior. Por tanto, un aumento del contador de descartes no demuestra por sí solo un ataque, una fibra dañada o un puerto de conmutador averiado.
Correlacione la hora, el sentido, la asociación de seguridad y los registros de la aplicación. Compruebe si al mismo tiempo hubo un cambio de ruta, una acumulación en las colas o una variación de la carga de la pasarela. Ampliar la ventana no es una solución universal: verifique los límites de la implementación, los costes de procesamiento y el retraso aceptable. No desactive la protección simplemente para ocultar una alarma.
La ventana no recupera un paquete perdido. Determina si un paquete puede continuar; la retransmisión, la recuperación de sesiones y el comportamiento ante tiempos de espera agotados de la aplicación corresponden al mecanismo de transporte o de aplicación adecuado. Una ventana antirrepetición no es un protocolo de entrega fiable ni un búfer de reordenamiento de paquetes de uso general.
Un paquete nuevo del túnel puede contener un comando antiguo de la aplicación
Una aplicación puede volver a enviar la misma operación. El extremo de seguridad puede encapsular esa segunda solicitud en un nuevo paquete externo con un nuevo número de secuencia. En la capa del túnel no es el paquete ESP aceptado anteriormente; en la capa de aplicación puede seguir siendo una operación duplicada.
Por tanto, la protección antirrepetición no garantiza que cada comando se ejecute una sola vez. Según el protocolo real, las operaciones importantes pueden necesitar identificadores de transacción, gestión de solicitudes duplicadas, caducidad, permisos y comprobaciones respecto al estado actual. Estas funciones requieren acuerdo y verificación en ambos extremos; añadir un campo por sí solo no establece una seguridad completa.
Un paquete válido no visto dentro de la ventana tampoco llega necesariamente a tiempo para la operación de negocio. Decidir si debe ejecutarse un comando retrasado corresponde a la aplicación. Distinga entre la duplicación de paquetes, la autenticidad del emisor y si la acción es apropiada en ese momento.
Convierta el mecanismo en un registro verificable del proyecto
Señale los extremos del túnel y el ámbito que realmente protegen. Verifique el protocolo, la negociación, la ventana admitida y el significado de los registros. Las interfaces serie, el reenvío Ethernet y el procesamiento de seguridad son capas distintas. La compatibilidad con fibra, VLAN o redes serie no demuestra la compatibilidad con ningún algoritmo criptográfico ni certificación específicos.
En un entorno de pruebas autorizado, utilice datos inocuos y aislados para observar el orden normal, el reordenamiento permitido, los paquetes repetidos y los fallos de autenticación. Registre la versión de la documentación, la configuración y los resultados. No vuelva a enviar comandos de control reales de producción ni presente los números ilustrativos del diagrama como mediciones.
Recuerde tres responsabilidades: el cifrado protege el contenido, una ventana antirrepetición registra los números de los paquetes aceptados y la aplicación sigue gestionando las operaciones duplicadas y la temporización. La autenticación impide que un número de secuencia inventado haga avanzar sin más el registro de confianza. En conjunto, estos límites facilitan la evaluación de un diseño de comunicación industrial.
Referencias principales
RFC 4303: carga útil de seguridad encapsuladora de IP, secciones 2.1, 2.2 y 3.4.3; RFC 6479: algoritmo antirrepetición de IPsec (informativo, no una norma de Internet obligatoria). Contexto del producto: Servidor de dispositivos serie FCT-1100-F1S1; esto no afirma que ese producto admita IPsec.
Traducido del artículo técnico en chino: Leer el artículo original en chino.
Preguntas prácticas frecuentes
¿El cifrado por sí solo impide la repetición?
No. La protección antirrepetición también necesita seguimiento de secuencias, autenticación y un estado correcto del receptor.
¿Se rechaza todo número de secuencia anterior?
No. Un número no visto dentro de la ventana puede pasar a la autenticación; los duplicados y los números demasiado antiguos se rechazan.
¿La protección antirrepetición del túnel garantiza que un comando se ejecute una sola vez?
No. Un paquete externo nuevo puede contener un comando de aplicación repetido; la aplicación necesita sus propias reglas.
Alcance y lecturas adicionales
Conceptos genéricos de la protección antirrepetición de ESP, no una afirmación sobre ningún producto específico.
Semicierre de TCP y respuestas serie · Cargas unitarias de RS485 y presupuesto de carga del controlador de línea
