Resumen
- El
rttopcional de RFC 9891 es una pista del cliente sobre el viaje de ida y vuelta. El servidor ACME define el intervalo real, aplica límites propios de la red y compara la respuesta con la vida útil del Challenge Bundle original. - Una respuesta válida vincula una cuenta ACME, un Node ID y una prueba concreta dentro de un plazo. No acredita propiedad permanente, rutas futuras, emisión o instalación de un certificado, una sesión TCPCL ni el resultado de una aplicación.
Un sistema de renovaciones recibió el número 300 y lo convirtió en una autorización: “el nodo dispone de cinco minutos”. El primer número era una previsión de trayecto. La segunda frase atribuía al cliente un poder que el protocolo había reservado al servidor.
RFC 9891 lleva la validación de identificadores de ACME a Delay-Tolerant Networking. El servidor crea una autorización para un bundleEID, ofrece el desafío bp-nodeid-00 y envía uno o varios Challenge Bundles al Node ID. El agente que controla ese destino prepara una respuesta criptográficamente ligada al desafío y la devuelve como Response Bundle.
La especificación es Experimental. Su propósito es permitir implementación y evaluación donde las rutas pueden ser intermitentes o tardar mucho más que una consulta web. Ese estatus también reconoce incertidumbres sobre ataques en ruta, diversidad efectiva, autoridad de nombres y confianza entre organizaciones. No es un informe de adopción.
La ruta estimada no gobierna el verificador
El objeto con el que el cliente autoriza el intento puede incluir rtt. Expresa los segundos esperados entre el envío del desafío y la recepción de la respuesta. RFC 9891 lo define como una pista no autoritativa.
El servidor debería tomar normalmente dos veces ese valor y aplicarle un mínimo y un máximo adaptados a la red. En una DTN exclusivamente terrestre, el máximo no debería superar sesenta segundos. Una red con enlaces de otra naturaleza puede necesitar otra política. Lo invariable es quién la decide.
El cliente debe esperar hasta que su BP Agent esté listo para responder. También debería declarar un RTT pesimista porque no controla qué ruta concreta seguirán los Bundles. Estas obligaciones mejoran la información del servidor; no desplazan su responsabilidad por capacidad, exposición y confianza.
La distinción evita dos fallos simétricos. Si el servidor acepta cualquier cifra, el solicitante puede mantener estado de validación durante intervalos costosos. Si ignora toda información del cliente, excluye nodos legítimos cuyo diseño precisamente tolera desconexiones. La solución no es convertir el dato en mandato, sino hacer visible la regla que lo transforma en un plazo.
La respuesta no puede renovarse el plazo a sí misma. Aunque el Response Bundle indique el tiempo de vida restante, el servidor mide su llegada contra la creación y la vida útil del Challenge Bundle asociado. La autoridad temporal está en el desafío original.
El digest no nace en una sola ruta
La prueba combina información que viaja por dos canales. token-chal pertenece a la autorización ACME, permanece fuera del canal BP y es compartido por todos los Bundles de ese desafío. token-bundle cambia en cada Challenge Bundle y puede ser observado en la ruta DTN.
El agente concatena ambos valores, incorpora la huella de la clave de cuenta y calcula la Key Authorization. Luego devuelve un digest con un algoritmo aceptado. Quien solamente escucha la red Bundle carece del token ACME; quien solo conoce el objeto ACME no demuestra recepción del Bundle particular.
Para declarar exitosa una perspectiva, el servidor comprueba llegada puntual, igualdad entre el Node ID de origen y el que se valida, integridad del bloque primario y la carga, coincidencia de ambos tokens, algoritmo permitido y digest esperado. La falta de respuesta dentro del plazo también es un fallo.
Este conjunto demuestra algo valioso, pero acotado. El titular de la cuenta coordinó una respuesta desde el Node ID durante una autorización concreta. No demuestra que el identificador sea una persona, que sea único en todo contexto o que siga bajo el mismo control después de vencer el desafío.
RFC 9171 define el Node ID como un Endpoint ID singleton apto para identificar un nodo BP. Aclara que no tiene garantía de unicidad global y que un nodo puede utilizar varios. La Administrative EID ordinaria es única para un nodo dentro de un esquema URI específico.
Por eso los registros de ACME en IANA y del Bundle Protocol en IANA coordinan, pero no certifican la realidad operativa. Registran bundleEID, bp-nodeid-00, el tipo administrativo y los esquemas dtn e ipn. Un código común evita colisiones semánticas; no prueba que un nodo esté activo o que una organización tenga derecho permanente sobre él.
Perspectivas múltiples, política única
Para reducir ciertos ataques en ruta, el servidor puede lanzar pruebas desde varias fuentes o por distintos caminos. Cada Challenge Bundle recibe un token propio y cada devolución queda como observación independiente. La diversidad solicitada no garantiza diversidad real: varios trayectos pueden compartir una puerta de enlace o un enlace subyacente.
RFC 9891 deja al servidor la política que agrega esas observaciones. Una recomendación consiste en exigir éxito de la perspectiva primaria y permitir como máximo un fallo secundario. La designación de primario y secundario también es local. El estado final “válido” contiene, por tanto, mediciones y una decisión política.
Una auditoría madura guarda ambas cosas. Si solo conserva el estado agregado, no podrá distinguir “tres rutas respondieron” de “la primaria respondió y una secundaria falló, algo que la política toleraba”. Tampoco podrá comparar dos CAs que aplican tolerancias diferentes.
La puerta de enlace de integridad introduce otra delegación. Puede verificar localmente la fuente de un Bundle y añadir un Block Integrity Block. El receptor necesita una regla que indique para qué patrones de Node ID confía en esa Security Source. La criptografía protege la declaración de la puerta de enlace; la configuración decide hasta dónde alcanza su autoridad.
Esta arquitectura refleja la propuesta de Heng Lu en Especificación inicial mínima y decisión futura localizada. El estándar fija lo que debe ser interoperable. El tiempo aceptable, la confianza entre dominios y la agregación quedan en manos de quienes sufren sus consecuencias. La coordinación no debe absorber esas decisiones locales.
Todavía no hay un certificado en uso
RFC 8555 sitúa la validación dentro de una cadena mayor. Un desafío pasa de pendiente a procesamiento y finalmente a válido o inválido. Una autorización válida permite continuar una orden, pero no equivale a su emisión.
Una solicitud de seguridad Bundle puede contener NODE-ID, DNS-ID e IP-ID. Cada identidad necesita su validación. La CA todavía revisa la política, el uso de clave y los algoritmos. Una respuesta DTN correcta no obliga a emitir.
Después, RFC 9174 permite que un certificado contenga NODE-ID y el propósito id-kp-bundleSecurity. Una sesión real puede exigir autenticación del nombre DNS, la dirección, el Node ID o una combinación. Si la referencia no coincide, el par puede terminar la sesión.
RFC 9891 no define cómo el cliente instala el certificado emitido en el BP Agent. Por ello, el operador debe enlazar registros distintos: autorización, orden, emisión, instalación, certificado activo, handshake, sesión, Bundle y resultado de aplicación. Saltar cualquiera convierte una prueba anterior en una conclusión posterior.
RFC 9172 aporta el marco de BPSec para proteger bloques. Una verificación de integridad confirma datos cubiertos bajo una clave y un contexto. No decide la legitimidad social o institucional de la fuente.
La regla de Código en ejecución como evidencia primaria obliga a comprobar qué hizo el sistema, no solo qué permite el estándar. Capas de realidad y poder simbólico advierte por qué un indicador “válido” puede adquirir significados que la prueba nunca produjo.
El cliente calculó la demora. Esa información era útil. El servidor conservó el plazo porque conservar el plazo era conservar la responsabilidad por la prueba. Lo que regresó a tiempo acreditó control en un instante, no dominio sobre el futuro.
Fuentes
- RFC 9891, extensión ACME para validar un Node ID DTN
- RFC 8555, Automatic Certificate Management Environment
- RFC 9171, Bundle Protocol versión 7
- RFC 9172, seguridad del Bundle Protocol
- RFC 9174, TCP Convergence-Layer versión 4
- IANA, registro del protocolo ACME
- IANA, registro del Bundle Protocol
- Heng Lu, Código en ejecución como evidencia primaria
- Heng Lu, Especificación inicial mínima y decisión futura localizada
- Heng Lu, Capas de realidad y poder simbólico
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance

