Resumen

  • RFC 1701 insinuó que el receptor podía usar la Key de cuatro octetos para autenticar la fuente, aunque no definió cómo generar, entregar, proteger ni validar esa supuesta prueba.
  • RFC 2890 acotó el campo: Key identifica un flujo lógico dentro del túnel y no participa en ninguna forma de seguridad, pese a su nombre. Sequence Number conserva orden, no fiabilidad.
  • Una secuencia arbitraria inyectada puede adelantar la memoria del receptor y volver “viejos” los paquetes legítimos. La clasificación y el contador solo son confiables cuando otra capa protege la cabecera GRE y su carga.

Cuatro octetos con demasiadas connotaciones

Una clave suele ser un secreto, una credencial o una capacidad. Por eso, encontrar el nombre Key en una interfaz de túnel invita a una conclusión cómoda: quien conoce el valor debe ser el participante correcto. La historia del campo GRE demuestra lo contrario.

RFC 1701, un documento Informational de 1994, propuso una encapsulación genérica de un protocolo de red sobre otro. La cabecera de entrega llevaba una cabecera GRE y, detrás, el paquete encapsulado. GRE podía incluir checksum, información de ruta, Key y Sequence Number.

El documento decía que el receptor podía emplear Key para autenticar el origen del paquete. A continuación dejaba fuera de alcance todas las técnicas para determinar esa autenticidad. No había acuerdo sobre creación, distribución, asociación con un extremo, protección contra copia, renovación o fallo. El campo transportaba un número, no la cadena de evidencias necesaria para convertirlo en identidad.

Sequence Number tampoco tenía todavía reglas completas. Podía indicar orden de transmisión, pero tanto su generación como el significado de recibirlo quedaban sin especificar. Dos equipos podían comprender el formato y, aun así, actuar de manera distinta ante el mismo valor.

Normalizar exigió reducir el terreno común

RFC 2784 cambió el método en marzo de 2000. En lugar de completar todas las posibilidades del diseño anterior, describió la intersección ya desplegada por varios proveedores. La cabecera base conservó el bit de checksum, Version y Protocol Type. Este último identifica la clase de carga; no decide quién tiene permiso para enviarla por el túnel.

Los bits opcionales antiguos quedaron como frontera de compatibilidad. Un emisor que solo siguiera RFC 2784 los enviaba a cero. Un receptor que no implementara RFC 1701 debía descartar el paquete si encontraba no nulo cualquiera de los bits 1 a 5. Las reglas de interfuncionamiento reconocían el pasado sin asignarle un significado inventado.

El resultado era una especificación inicial mínima: cada nodo podía decidir localmente qué conjunto entendía. No hacía falta preguntar qué fabricante había al otro lado ni interpretar el nombre del túnel como una promesa.

RFC 2890 rebajó la Key para volverla operativa

En septiembre del mismo año, RFC 2890 actualizó la base y reutilizó las posiciones K y S. K señala la presencia de una Key de cuatro octetos; S, la de un Sequence Number del mismo tamaño. La disposición seguía siendo compatible con RFC 1701, pero ahora tenía semántica ejecutable.

El encapsulador inserta la Key. Cómo obtiene el número no forma parte del RFC. El desencapsulador lo usa para reconocer un flujo de tráfico individual dentro del túnel cuando el paquete interno no contiene el contexto necesario. Los paquetes del mismo flujo llevan la misma Key y el extremo receptor los asocia con su tratamiento local.

El alcance es el acuerdo de esos extremos, no Internet entero. La misma cifra puede referirse a otro flujo en otro túnel. No declara propiedad, autorización ni secreto. Copiar cuatro octetos visibles es trivial para quien ya puede construir un paquete.

La sección de seguridad lo dice sin rodeos: el campo Key no interviene en ningún tipo de seguridad, pese a su nombre. La norma conservó la palabra por compatibilidad, pero retiró la autoridad que el lector podía atribuirle.

Ordenar no equivale a entregar

S sí añadió una memoria común. El emisor utiliza un contador de 32 bits que comienza en cero y se mueve módulo 2^32. El receptor recuerda el número del último paquete desencapsulado correctamente. Cuando K está presente, ese historial pertenece al flujo identificado por la Key.

El valor siguiente puede aceptarse. Uno viejo o duplicado debe descartarse en silencio. Un salto hacia delante deja un hueco. El receptor puede mantener un búfer pequeño por flujo para esperar paquetes reordenados; cuando se agota el tiempo o el espacio, puede saltar la ausencia y continuar con los disponibles.

RFC 2890 denomina al servicio “no fiable pero en orden”. El contador no recupera la carga que faltó ni garantiza que cada número llegue. Solo define una disciplina limitada para esperar, ordenar y abandonar.

Tampoco existe un reloj total para el túnel. Los paquetes sin S pueden intercalarse. Si hay varias Keys, cada una conserva su propia secuencia. Un hueco demuestra lo que no fue desencapsulado en un estado de flujo; no aclara si la causa fue pérdida, demora, filtrado, reinicio o ausencia de transmisión.

Inyectar el futuro podía borrar el presente

Si el receptor aceptó por última vez 40 y recibe primero un paquete falso con la Key copiada y un número muy adelantado, puede actualizar su estado con ese futuro inventado. Los paquetes legítimos posteriores parecen atrasados y terminan descartados por la propia defensa de orden.

RFC 2890 identifica esa inyección arbitraria como un ataque de denegación de servicio y exige una protección IP separada para la cabecera GRE y el contenido tunelizado. La protección debe cubrir K y S porque son precisamente los campos que seleccionan contexto y alteran la memoria.

Por eso Sequence Number no es una defensa anti-repetición autónoma. Una ventana de repetición solo sirve después de autenticar que el paquete pertenece a la asociación protegida. Sin esa prueba previa, el atacante puede escribir el valor contra el que se juzgarán los siguientes paquetes.

El cifrado tampoco aparece por sumar K y S. La confidencialidad, la integridad y la autenticación son propiedades diferentes del mecanismo protector elegido alrededor de GRE.

ECN añadió otro deber, no otra lectura de Key

RFC 9601, publicado en 2024, es la otra actualización formal de RFC 2784. Incluye GRE en las reglas modernas para propagar Explicit Congestion Notification entre cabeceras IP y añade obligaciones de configuración segura en el ingreso con IPv4 o IPv6 exterior.

Esa actualización trata un plano distinto. ECN lleva evidencia de congestión; Key selecciona contexto; Sequence mantiene orden local; la protección externa verifica procedencia e integridad. Ninguna responsabilidad se hereda solo porque comparten un túnel.

El documento también recuerda que GRE no posee un protocolo propio de creación dinámica del túnel. La relación puede venir de configuración estática o de otro plano de control. Una captura enseña el número; no enseña el mandato que lo asignó.

Un contador registra decisiones, no causas

Una subida de descartes fuera de secuencia admite varias historias: reordenamiento, duplicación, presión del búfer, reinicio de un extremo, desacuerdo de configuración o inyección. El contador demuestra que el receptor comparó un valor con su memoria y decidió. No identifica por sí mismo al responsable.

La investigación útil vincula extremos exteriores, espacio de Keys, mapa de flujo, necesidad de S, último número aceptado y resultado de integridad. Preguntar únicamente si “la clave coincide” vuelve a mezclar las funciones que el estándar había separado.

La reparación histórica de RFC 2890 consistió en una renuncia. Key puede nombrar contexto; Sequence puede organizar lo recibido. La seguridad debe apoyarse en pruebas que esos cuatro octetos nunca ofrecieron.

Fuentes