Resumen

  • La revisión 25 exige cifrado con confidencialidad e integridad y prohíbe ChaCha20 sin autenticación, pero su Marker solo indica cómo tratar el registro: no acredita identidad, propiedad ni autorización.
  • Los nodos con clave y sin ella pueden dejar de verse mutuamente y tomar decisiones de colisión sobre universos distintos; incluso dentro del grupo cifrado, poseer el secreto no equivale a tener mandato para asignar.

Una dirección multicast puede parecer libre por dos motivos opuestos. El primero es que nadie la reclama. El segundo es que quien la reclama habla en un lenguaje criptográfico que el observador no puede leer. GAAP-25 vuelve imposible tratar ambos silencios como si fueran la misma evidencia.

El borrador GAAP en su revisión 25 propone que aplicaciones de un dominio administrativo se coordinen sin un servidor central pesado. Un nombre de grupo se somete a una función hash para obtener una dirección candidata. Si aparece una colisión—la misma dirección para nombres diferentes—hay tres alternativas deterministas adicionales, calculadas añadiendo 1, 2 o 3 al nombre. El solicitante transmite un Claim inicial, espera aproximadamente un intervalo periódico y mantiene después un estado blando mediante Claims sucesivos. Para liberar la dirección, deja de enviarlos.

La propuesta sigue siendo experimental. El registro del Datatracker la sitúa en evaluación del IESG con seguimiento del Area Director, y el historial del documento muestra una especificación activa. No es un RFC ni una prueba de funcionamiento en producción. El propio borrador reconoce que el esquema descentralizado basado en hashes no ha sido desplegado y que no existen mediciones de colisiones o escala.

Una corrección criptográfica precisa

La seguridad de la revisión 25 es más exigente que la que podía inferirse de la revisión 23. Si un Claim se cifra, el mecanismo debe ofrecer confidencialidad e integridad, como hace un AEAD. El texto prohíbe expresamente utilizar ChaCha20 por sí solo. La razón aparece en RFC 8439: el cifrado de flujo sin autenticación es maleable. Un adversario puede modificar bits del texto cifrado para provocar cambios previsibles en la dirección, la marca temporal o el nombre tras el descifrado.

También se exige que el nonce no se repita para una misma clave entre ninguno de los emisores que la comparten. Y un receptor configurado para usar clave debe rechazar Claims sin cifrar. Son decisiones correctas: evitan tanto la reutilización peligrosa de parámetros como la degradación silenciosa al modo abierto.

Sin embargo, el Marker de GAAP no es una credencial. Solo funciona como señal implícita de que el registro está cifrado. No especifica por sí mismo el algoritmo, no identifica al actor y no incorpora una autorización. El mecanismo, las claves, el formato exacto del registro, los datos asociados, los nonces y la renovación se acuerdan en gran medida fuera del protocolo. Cuando el descifrado falla, el receptor descarta. Una clave incorrecta, una versión incompatible, un paquete dañado y una manipulación hostil producen la misma ausencia de Claim visible.

Ese diseño divide el campo de observación. Los nodos con clave rechazan lo que llega en claro; los nodos sin clave no entienden el cifrado. Dos aplicaciones pueden compartir enlaces y aun así habitar dominios de colisión distintos. Cada una puede asignar la misma dirección de buena fe, porque la prueba que habría contradicho su decisión está fuera de su universo legible.

La integridad del registro no legitima al emisor

Incluso todos dentro del mismo dominio de clave comparten una limitación. Un participante malicioso que posee el secreto puede crear un Claim que supera perfectamente la autenticación. El protocolo puede comparar marcas temporales y aplicar su desempate determinista, pero el ganador técnico no se convierte por ello en titular legítimo.

Por eso la lista local de malos actores es deliberadamente modesta y limitada. La fuente de red puede falsificarse; perder una comparación temporal no demuestra intención. RFC 1982 ayuda a comparar números de serie y RFC 8085 ofrece disciplina operativa para UDP. Ninguno añade una cadena de mandato.

La familia de documentos multicast—RFC 2365, RFC 5771, RFC 2730 y RFC 2909—sitúa el alcance y los mecanismos anteriores. RFC 10019 y RFC 10028 describen la arquitectura actual y el vacío que motiva nuevas opciones. Aun así, la inferencia correcta sigue siendo limitada: una prueba criptográfica informa sobre el mensaje; una comparación GAAP informa sobre los Claims visibles; una política externa debe informar sobre el derecho a operar.

El mínimo técnico no debe ocultar el máximo poder

La defensa que Heng Lu hace de una especificación inicial mínima y decisiones futuras localizadas resulta pertinente. GAAP no necesita convertirse en una institución universal para ser útil. Puede experimentar, permitir aprendizaje local y evitar una capa de gobernanza innecesariamente gruesa.

La condición es hacer explícitos los poderes que aparecen alrededor del protocolo. Quien entrega la clave admite participantes. Quien la revoca expulsa. Quien define el grupo de descifrado decide qué colisiones existen a efectos prácticos. Una función que parece administrativa puede convertirse en el verdadero control de acceso al espacio multicast.

La primacía del código en ejecución obliga a mirar más allá del rótulo. ¿Qué ven realmente los receptores? ¿Qué ocurre con una clave caducada? ¿Quién detecta dos poblaciones superpuestas? ¿Quién paga la interrupción? Esas respuestas describen el sistema real.

El artículo previo de BTW sobre GAAP-23 y la convergencia después de una partición examina cómo un mismo nombre puede quedar en direcciones alternativas distintas. Es un problema separado. La seguridad de la revisión 25 no lo resuelve; añade otra advertencia: también las claves pueden crear una partición lógica.

El logro de GAAP-25 es concreto y valioso. Protege mejor una afirmación. Precisamente por eso conviene no convertirla en prueba de algo distinto.

Fuentes