Resumen

  • El receptor BPSec debe saber de antemano quién puede proteger cada bloque. Un borrador individual del 27 de octubre propone anotar la fuente y la clave esperadas para cada servicio obligatorio; la firma válida de otro nodo no ocupa ese lugar.
  • La misma propuesta pide que el bloque de integridad de la carga incluya el bloque primario en su propia cobertura. Protegerlos por separado deja abierta la posibilidad de unir piezas auténticas de paquetes distintos.

La firma responde a la pregunta equivocada

Un relevo recibe un paquete en una red tolerante a interrupciones. Tiene una clave auténtica para proteger ciertos tramos. Cambia la carga que había protegido el origen y firma la nueva con su propia clave. El receptor comprueba esa firma y obtiene un resultado positivo.

La firma acredita al relevo; no acredita su derecho a sustituir la carga del origen. Ese segundo derecho solo puede venir de la política que el receptor ya había fijado.

RFC 9172, la especificación de seguridad del protocolo Bundle, ya describe en su sección 8.2.2 esta sustitución por un nodo legítimo. El problema aparece si el receptor pregunta únicamente si el bloque de integridad procede de «un usuario legítimo». En una red con varias fuentes de seguridad, esa expresión agrupa funciones que deberían seguir separadas. Ser miembro autorizado de la red no otorga una firma universal para todos los contenidos.

El borrador de N. D. S. Gupthaa sitúa la solución en el criterio de aceptación. Antes de mirar el bloque recibido, la política local debe registrar qué fuente de seguridad y qué material de clave son autoritativos para un servicio concreto sobre un bloque concreto. Un BIB, bloque de integridad, o un BCB, bloque de confidencialidad, solo satisface ese requisito si verifica bajo la clave prevista. Una firma válida de otra fuente sigue siendo válida para lo que esa otra fuente pueda hacer. Aquí no sirve.

La ficha de IETF Datatracker presenta el texto como revisión 00 de un Internet-Draft individual, sin respaldo formal del IETF ni vía RFC. Es una propuesta de reglas para el receptor; no documenta su despliegue en una red identificada.

Un directorio de gente fiable no es un reparto de competencias

Las cuatro primeras reglas del borrador recortan el problema en unidades pequeñas. R1 vincula cada servicio requerido y cada bloque objetivo con la fuente esperada y su clave. R2 impide que el bloque de otra fuente, aunque sea legítima, cumpla esa exigencia. R3 obliga a dar por fallido el servicio si no llega una prueba conforme. R4 evita que el permiso de una pasarela para volver a proteger una clase de tráfico se convierta en autoridad sobre el contenido de otros emisores.

La última distinción es la que suelen borrar los paneles con un único indicador verde. Una pasarela puede tener derecho a reenviar, derecho a cifrar en un tramo y derecho a atestiguar ciertos orígenes bajo una delegación definida. Los tres derechos tienen sujetos y límites distintos. Si el receptor guarda solamente una lista de claves «de confianza», fabrica un organigrama sin cargos: conoce a las personas, pero ignora quién puede firmar cada decisión.

El campo Security Source que llega dentro del bloque tampoco nombra por sí solo al titular de la competencia. El borrador lo trata como pista de búsqueda no fiable. El bloque puede declarar quién lo produjo; la política previa del receptor decide si esa persona era la esperada. Permitir que la declaración entrante escoja su propio criterio de validación sería entregar el libro de visitas al visitante para que se añada al consejo de administración.

Esta lógica exige claves diferenciadas por fuente. RFC 9172 advierte que, cuando todos los nodos comparten una misma clave, cada titular legítimo de ella tiene en la práctica un poder privilegiado. Ninguna tabla del receptor puede averiguar quién firmó realmente si el diseño de claves eliminó esa distinción. La separación de funciones empieza en la custodia de claves, no en la pantalla que muestra el resultado.

La cabecera y la carga deben viajar en la misma prueba

Hay una segunda manera de aceptar una historia falsa sin falsificar ninguna firma. Un BIB protege la carga útil. Otro BIB protege por separado el bloque primario, que contiene información de identidad y tratamiento del bundle. Ambos bloques pueden ser auténticos y proceder de dos bundles diferentes del mismo emisor. Verificar cada uno demuestra dos hechos aislados. No demuestra que la cabecera y la carga se crearan como pareja.

La regla R5 exige que el propio BIB de la carga incluya el bloque primario en su alcance de integridad. RFC 9173, sección 3.3.3, define el bit 0 que incluye ese bloque; si se omite el parámetro, el valor por defecto 7 también lo incluye. Un BIB aparte sobre la cabecera no aporta la unión que falta. Dos páginas auténticas de un expediente no se convierten en un documento firmado conjuntamente porque alguien las guarde bajo la misma tapa.

RFC 9171 define la estructura de los bundles y permite ver la consecuencia: el bloque primario y la carga cumplen funciones distintas. Si un receptor informa simplemente «integridad correcta», oculta el alcance de la prueba. La pregunta útil es qué campos quedaron protegidos juntos por el mismo cálculo y bajo qué fuente autorizada.

Lo que todavía falta ver

El borrador afirma que existen modelos en Tamarin y un comprobador de configuración, disponibles a petición y pendientes de publicación como artefacto. El texto abierto no permite inspeccionarlos. Una configuración real del receptor y una traza reproducible de sustitución mostrarían cómo operan R1 a R5 fuera del papel.

Mientras tanto, la decisión de diseño es concreta. El receptor necesita conservar su expectativa antes de recibir la firma, separar los permisos de cada pasarela y fallar el servicio requerido cuando la fuente no coincide. La red puede tener muchos actores legítimos. La legitimidad general de uno de ellos no le da potestad sobre todos los paquetes que toca.

Fuentes