Resumen

  • La revisión 04 del Internet-Draft SAND exige integridad BPSec, pero reserva al anunciante la selección de tipos, instancias y filtros según la red subyacente, el punto de terminación y el destino BP; dos vecinos pueden recibir conjuntos legítimos sin solapamiento.
  • Recibir no equivale a autorizar: el descubridor decide qué datos usar o descartar, y una Router Advertisement autenticada necesita una decisión separada antes de convertirse en ruta.
  • Para atribuir una diferencia hace falta un recibo de proyección que una Source, Security Source, Previous Node, destino, interfaz, versión de filtro, Reference Time, vigencia, supersession y política del receptor.

Las arquitecturas distribuidas suelen sufrir una confusión básica: tratan una observación incompleta como si fuese una afirmación negativa. Si un vecino no vio una credencial, el inventario escribe «el nodo no tiene credencial». Si no recibió un endpoint, el motor deduce «el servicio no existe». SAND revisión 04 ofrece razones precisas para rechazar ese salto.

El proyecto Bundle Protocol Secure Advertisement and Neighborhood Discovery dota a BPv7 de mensajes para descubrir vecinos, credenciales, underlayer networks, convergence layers, recursos, topología local, capacidad de encaminamiento y endpoints. Esa información no nace como una base de datos universal. Nace como una declaración emitida bajo una política y recibida bajo otra.

La consecuencia para liderazgo es incómoda pero manejable: antes de preguntar cuál de dos mapas es verdadero, hay que demostrar que ambos pretendían responder a la misma pregunta.

La protección conserva autores distintos

Un SAND Bundle identifica una Source EID y una destination EID. Para un intercambio pensado para vecinos de un salto, el Hop Limit es uno. Sin embargo, limitar saltos no convierte automáticamente al origen y al remitente inmediato en la misma entidad.

Cuando existe reenvío, la revisión 04 exige identificar positivamente el previous hop. Primero se usa una identidad autenticada por la convergence layer, si está disponible. Después puede usarse un Previous Node block autenticado. En el primer salto, el Source Node ID autenticado también puede aportar la identidad.

Todos los bundles SAND deben contener un Block Integrity Block que proteja el payload. Su Security Source debe identificar el mismo nodo que la Source EID, aunque una política de identidad puede permitir EID distintas para ese nodo. Si aparece un Previous Node block, también debe quedar protegido por un BIB cuya Security Source identifique al nodo anterior.

De ahí resultan tres papeles: el autor original del bundle, el nodo que lo entregó en el último salto y la identidad criptográfica que protege cada bloque. Un esquema de datos que los comprime en una sola columna pierde precisamente la información necesaria para investigar un reenvío o una equivalencia de identidades mal aplicada.

La integridad prueba que una declaración protegida no cambió y que una clave atribuible la respalda. No prueba que el autor enumeró todo lo que sabía ni que entregó el mismo conjunto en cada contexto.

Solicitar información no otorga poder de divulgación

Data Solicitation informa al anunciante de un interés. El texto es explícito: la solicitud no debe sobreponerse a la política local sobre lo que puede anunciarse. El propio nodo decide qué tipos de mensaje transmite y qué instancias incluye o excluye.

Un filtro puede eliminar un punto de terminación deshabilitado, evitar repetir credenciales estables o suprimir parámetros que no aportan nada a una red concreta. También puede ser una frontera de seguridad. Un mensaje a grupo puede revelar solo lo necesario para iniciar contacto; un destino singleton protegido puede recibir certificados o instancias más sensibles.

La sección de Context-Specific Advertisement Filtering permite condicionar el contenido a la ULN, al punto de terminación y a la source o destination BP. Un certificado de una CA privada puede anunciarse únicamente en la red que confía en esa raíz. Una instancia IPv6 puede aparecer por una terminación IPv6 y omitirse en otra tecnología. Los filtros se pueden combinar.

La revisión 04 nombra el resultado: una forma de «split brain» en la que diferentes vecinos observan conjuntos distintos, incluso posiblemente no solapados, vinculados al mismo nodo. No es una autorización para mentir. Es una advertencia contra interpretar cada vista local como una lista global exhaustiva.

La confidencialidad explica parte del diseño. El intercambio inicial de grupo para enrolamiento puede tener payload legible si no se añade protección de confidencialidad. Hop Limit 1 no impide que un middlebox lo observe. Ocultar nombres DNS, direcciones, vecinos, CL instances o certificados en determinadas terminaciones puede reducir una exposición real.

La asimetría, por tanto, puede ser la política correcta. Lo incorrecto sería olvidar que existía.

La recepción produce otro filtro

Superar las condiciones de transporte no obliga al descubridor a utilizar el mensaje. La especificación define estructuras que una implementación debe poder interpretar, pero no exige emplear todos los mecanismos o datos.

La autorización receptora puede variar por message type, source, destination, condiciones de la convergence layer o información obtenida antes sobre el anunciante. Después, el nodo puede hacer culling. Un receptor limitado a IP puede no conservar parámetros no IP. Puede apartar una dirección que su tabla local considera inalcanzable.

Ese descarte solo describe el estado local y presente. Una futura ruta puede volver útil la dirección. Una actualización de software puede comprender un parámetro antes desconocido. Si el repositorio central recibe únicamente el resultado depurado, no puede distinguir entre omisión del remitente, denegación del receptor, falta de soporte e imposibilidad temporal de alcanzar el dato.

Además, una autorización contextual necesita enlazar el SAND message con el bundle que lo contenía y con la CL instance local de recepción. El proyecto reconoce que algunas interfaces BP Agent–aplicación no ofrecen esa visibilidad. En ese caso, una regla de política puede existir en un manual y no ser ejecutable por el proceso real.

El mapa local contiene, así, la composición de dos decisiones soberanas: qué quiso mostrar el anunciante y qué aceptó representar el receptor.

Un bundle posterior no es necesariamente más nuevo

Cada mensaje SAND contiene el conjunto completo de su tipo para el anunciante. El receptor no necesita reproducir una cadena de deltas. Esto permite procesamiento idempotente y tolera duplicados, algo natural en BPv7.

Tras procesar un mensaje, el nodo registra el Reference Time por source y type; si falta, recurre al Creation Timestamp. Antes de procesar otro, compara los tiempos. Un valor idéntico o anterior debe ignorarse. El orden usa DTN Time y después Sequence Number. Ignorar un mensaje superseded no significa que el bundle fuese inválido.

Una captura puede, por tanto, mostrar dos mensajes BPSec válidos de los cuales solo uno tenía derecho a modificar el estado. Un replay puede consumir recursos, pero no debería hacer retroceder una vista correctamente implementada. En sentido contrario, una estrategia que solo envía cuando cambia el estado corre el riesgo de dejar vigente una vista antigua si se pierde el mensaje sustituto.

Validity Duration, Repetition Interval y la estrategia periódica o por evento determinan cuánto significa el silencio. La hora de ingestión del colector no sustituye al tiempo declarado por el protocolo.

Los nombres de reachability no son pruebas de servicio

Local Topology Advertisement usa HEARD, SYMMETRIC y LOST. HEARD significa que este nodo recibió un mensaje del peer, pero todavía no se vio a sí mismo en la topología publicada por el peer. SYMMETRIC significa que el peer lo anunció, así que al menos un mensaje fue recibido en cada dirección. LOST significa ausencia de mensajes durante un timeout definido por la implementación.

Nada de eso acredita capacidad estable, éxito de aplicación o una entrega extremo a extremo. Tampoco hay sincronización obligatoria de métricas entre vecinos mutuos. Aunque ambos publiquen el mismo tipo de métrica, no existe garantía ni expectativa de valores iguales. La reconciliación queda en manos de la implementación.

Router Advertisement separa todavía mejor las capas. Un nodo puede expresar willingness de cero a seis y patrones de attached networks, incluso *:** para un comportamiento de gateway. El proyecto advierte que esa indicación debería verla solo una red stub apropiada. Registrar el patrón, autorizarlo para routing e instalar una ruta son actos distintos.

Sin autorización, siguen aplicando riesgos de route leaking y hijacking. El texto señala que BP no dispone de un equivalente de RPKI para autorizar routing. Una firma válida hace atribuible la oferta; no la convierte en derecho de tránsito.

El objeto de control es un recibo de proyección

Una organización que quiera comparar vistas necesita un recibo de proyección de anuncio. Es una recomendación operativa de este análisis, no una extensión exigida por la revisión 04.

El recibo guarda hash e identidad del bundle protegido, Source EID, BIB Security Source, Previous Node, destination, Hop Limit, Creation Timestamp y hora de recepción. También registra qué método autenticó la identidad. A continuación fija la ULN, el termination point y la CL instance por los que salió o entró.

Por cada message type conserva las instancias incluidas, Reference Time, Validity Duration, Repetition Interval y resultado de supersession. Si está disponible, identifica la versión del filtro del anunciante. En el receptor, registra authorization y culling con sus motivos, y calcula un hash de la proyección que realmente entró en la information base.

El recibo no debe absorber la autoridad posterior. La instalación de una ruta requiere otra decisión atribuible. El forwarding necesita observación de plano de datos. El resultado de aplicación necesita su propia confirmación. La separación evita que un único authenticated=true se convierta en sinónimo de completo, autorizado y entregado.

Al comparar dos recibos, la diferencia se puede clasificar: alcance deliberado, versión distinta de política, staleness, supersession, culling receptor, dato no soportado, pérdida, mala configuración o divergencia todavía inexplicada. Sin ellos, se discuten capturas sin poder reconstruir las condiciones.

Mantener modesta la afirmación sobre el estándar

Datatracker presenta la revisión 04 como Internet-Draft activo del grupo DTN, publicado el 8 de septiembre de 2026 y con expiración el 12 de marzo de 2027. El encabezado dice Standards Track, mientras el campo de intended RFC status de Datatracker estaba vacío al congelar las fuentes. No es un RFC ni una asignación definitiva.

La sección Implementation Status menciona un proof of concept. También advierte que la información procede de colaboradores, no fue verificada, no constituye catálogo y no implica respaldo del IETF. Este artículo no afirma adopción, interoperabilidad, producto concreto, ataque, incidente, route leak o corte real.

RFC 9171 define BPv7; RFC 9172, BPSec; RFC 8949 y RFC 8610, CBOR y CDDL. RFC 6130 sirve de antecedente para neighborhood discovery. RFC 4593, RFC 7908 y RFC 6480 enmarcan amenazas de routing, route leaks y RPKI. Ninguna referencia entrega a una vista SAND local autoridad global.

La conclusión es pequeña y suficiente: la autenticación atribuye una afirmación situada. La completitud, el permiso de ruta y el resultado se prueban después.