Primero se decide exactamente qué paquetes deben ir protegidos. Esto se define como una política: por ejemplo, el tráfico entre dos subredes, entre dos hosts específicos o hacia ciertos servicios. La idea es que IPsec no “adivina” qué proteger: se le indica qué flujo entra al esquema seguro y qué flujo queda como tráfico normal.
Luego, ambos extremos confirman que están hablando con la contraparte correcta y acuerdan cómo se va a aplicar la seguridad. Aquí se define si solo se verificará integridad y origen, o si también se cifrará; se eligen algoritmos, tamaños de clave y parámetros de protección. Sin esta negociación, no hay base común para validar paquetes y se pierde la confianza en el intercambio.
Una vez acordadas las reglas, se generan claves temporales que se usarán para proteger el tráfico real. Estas claves son de sesión: se crean para ese intercambio y se cambian con el tiempo. El objetivo es que, aunque alguien capture paquetes, no pueda derivar las claves ni “fabricar” paquetes válidos, porque no tiene el material criptográfico necesario.
Aquí ocurre lo esencial: cada paquete que coincide con la política es transformado antes de salir. Según lo acordado, se le agrega autenticación e integridad (para comprobar origen y detectar cambios) y, si aplica, se cifra el contenido. Al llegar al receptor, se realiza el proceso inverso: primero se valida; si no pasa la verificación, se descarta; si pasa, se entrega el paquete al sistema como tráfico legítimo.
Dependiendo del objetivo, la protección puede aplicarse de forma directa entre dos hosts o mediante un túnel que conecta redes enteras. La diferencia práctica es que, en un caso, se protege el flujo entre máquinas específicas; en el otro, se encapsula para transportar paquetes de una red dentro de otra de forma segura. Esto es lo que permite escenarios típicos como VPN de sitio a sitio.
Para que el canal no se vuelva predecible o vulnerable con el tiempo, las claves y parámetros se renuevan. Esto reduce el impacto si algún dato de sesión se filtra y limita cuánto puede analizar un atacante sobre un mismo conjunto de claves. En términos simples, se evita “usar lo mismo para siempre” y se mantiene la protección fresca y consistente.
Finalmente, se valida que lo que debía ir protegido realmente lo esté, y que la verificación esté rechazando lo que no corresponde. Esto incluye confirmar que la negociación se establece, que no hay degradaciones de seguridad y que los paquetes inválidos no se aceptan. En operación real, este paso evita configuraciones “creyendo que está seguro” cuando en realidad parte del tráfico sale sin protección.