Кратко

  • Редакция 04 активного проекта SAND требует BPSec-защиты, но оставляет объявляющему узлу выбор типов и экземпляров по underlayer network, termination point и BP destination; разные соседи могут законно получить непересекающиеся наборы.
  • Получение и проверка не дают права использовать данные: принимающий узел отдельно авторизует и отбрасывает их, а Router Advertisement не становится разрешённым маршрутом без следующего решения.
  • Для расследования нужен receipt проекции, связывающий Source, Security Source, Previous Node, destination, интерфейс, версию фильтра, Reference Time, срок действия, supersession и политику получателя.

В распределённой системе легко перепутать отсутствие строки с отрицательным фактом. Если один сосед не увидел credential, центральный инвентарь делает вывод, что credential нет. Если другой не получил endpoint, система объявляет сервис отсутствующим. SAND revision 04 показывает, почему такие выводы превышают имеющиеся доказательства.

Bundle Protocol Secure Advertisement and Neighborhood Discovery предназначен для discovery в среде BPv7 и delay-tolerant networking. Узлы могут сообщать о credentials, underlayer networks, convergence layers, ресурсах, локальной топологии, готовности маршрутизировать и endpoints. Но это не репликация единой базы. Каждый message формируется под локальной policy, а его использование снова решается локально.

Поэтому сравнение двух карт начинается не с diff строк, а с вопроса: были ли эти карты проекциями одного и того же контекста?

Источник, предыдущий узел и защитивший ключ — разные роли

SAND Bundle имеет Source EID и destination: SAND Group EID либо другой SAND Singleton EID. Для набора сообщений ближайшим соседям используется Hop Limit 1. Но даже короткая область не гарантирует тождество оригинального source и последнего передавшего узла.

При forwarding предыдущий hop должен быть положительно идентифицирован. Приоритет получает аутентифицированная identity convergence layer. Затем возможен защищённый Previous Node extension block. Для первого hop подходит аутентифицированный Source Node ID.

Каждый SAND Bundle обязан иметь Block Integrity Block, защищающий payload. Security Source этого BIB должен идентифицировать тот же node, что и Bundle Source EID, хотя security policy может разрешать разные EID для одного узла. Previous Node block защищается отдельно, и его Security Source соответствует previous node.

Эти поля отвечают на разные вопросы: кто создал bundle, кто отправил его на данном hop и чья криптографическая identity защищает конкретный block. Нормализация в единый node_id допустима лишь как производное представление, рядом с которым сохранены исходные значения и правило их связывания.

BPSec доказывает происхождение и целостность утверждения. Он не доказывает полноту утверждения и не требует одинакового содержания для каждого destination.

Solicitation не отменяет право узла молчать

Data Solicitation выражает желание получить конкретные типы данных. В revision 04 прямо сказано: она не должна обходить local policy объявляющего узла. Сам advertiser выбирает message types и instances.

Причина фильтра может быть операционной. Termination point отключён для discovery; credential редко меняется; параметр другой технологии бесполезен в этой ULN. Причина может быть связана с безопасностью. Group destination получает минимальные сведения для контакта, а защищённый singleton — более подробные addresses, CL instances или certificates.

Context-Specific Advertisement Filtering допускает зависимость от underlayer network, termination point, BP source или destination. Certificate частной PKIX hierarchy можно показать только там, где действует соответствующий trust root. IPv6 CL instance можно рекламировать лишь через IPv6 termination. Фильтры комбинируются.

Документ называет следствие «split brain»: разные соседи видят разные, иногда полностью непересекающиеся наборы, относящиеся к одному advertising node. Это не означает, что любое расхождение полезно. Это означает, что расхождение само по себе не доказывает ложь, loss или non-conformance.

Конфиденциальность усиливает этот вывод. Начальный zero-configuration group exchange без дополнительного шифрования имеет наблюдаемый payload. Hop Limit 1 не скрывает данные от middlebox. Отдельное сокрытие DNS names, IP addresses, соседей, CL instances или certificates по termination point может быть правильной защитой.

Ошибка возникает, когда downstream system стирает scope и трактует «не раскрыто здесь» как «не существует нигде».

Получатель строит второй слой проекции

Успешная доставка SAND message не обязывает discovering node использовать его содержимое. Структуры mandatory-to-implement, но не mandatory-to-use.

Receiver authorization может зависеть от message type, source, destination, CL-параметров приёма или ранее обнаруженных сведений. Затем локальная реализация может cull нерелевантные данные. IP-only node отбросит non-IP parameters. Адрес без текущего route может не попасть в active representation.

Такое решение ограничено местом и временем. Завтра route появится. Новая версия научится понимать параметр. Central inventory, получивший только итоговую таблицу, уже не различит sender omission, receiver denial, unsupported type и временную недоступность.

Для context-specific authorization message требуется связать с исходным enveloping Bundle и локальной CL instance, через которую он принят. Revision 04 отмечает, что не каждая BPA–application interface предоставляет такую видимость. Если decision engine не получает reception context, наличие правила в конфигурации ещё не доказывает его выполнение.

Итоговая карта — это результат по крайней мере двух политик: раскрытия на отправителе и авторизации с culling на получателе.

Криптографически правильное сообщение может быть superseded

SAND message содержит полный набор данных своего типа, а не цепочку дельт. Обработка становится idempotent и допускает дублирование. Чтобы старый полный набор не заменил новый, нужен строгий temporal order.

После обработки узел сохраняет Reference Time по Bundle Source и Message Type, либо использует Creation Timestamp. Перед полной обработкой следующего message значение сравнивается. Равный или более ранний message должен быть проигнорирован. Порядок определяется DTN Time и Sequence Number. Игнорирование superseded data не считается failure.

Два bundle могут успешно пройти BPSec, но только один имеет право изменить current state. Replay расходует ресурсы, однако при правильной реализации не откатывает состояние. Обратная проблема появляется при отправке только по событию: если новый message потерян, старая проекция может остаться.

Validity Duration, Repetition Interval, periodic timer и change-triggered mode вместе определяют значение тишины. Collector ingestion time не заменяет Reference Time и не удостоверяет актуальность.

SYMMETRIC не равен работающему сервису

Local Topology Advertisement использует HEARD, SYMMETRIC и LOST. HEARD означает, что message от peer получен, но этот node ещё не увидел себя в топологии, объявленной peer. SYMMETRIC означает, что peer объявил этот node, то есть как минимум одно сообщение прошло в каждом направлении. LOST означает отсутствие message в течение implementation-defined timeout.

Ни один статус не доказывает устойчивую bandwidth, application transaction или end-to-end delivery. Routing metrics взаимных соседей не синхронизируются. Даже одинаковые metric items не обязаны иметь равные значения. Reconciliation остаётся implementation detail.

Router Advertisement также имеет ограниченную силу. Узел объявляет willingness от нуля до шести и может включать Attached Networks patterns, включая gateway-like *:**. Документ предупреждает, что такую gateway advertisement должна видеть только подходящая stub network.

Записать объявление, разрешить его для routing и установить route — разные действия. Без авторизации сохраняются route leaking и hijacking threats. Проект отмечает отсутствие для BP routing эквивалента RPKI. Аутентифицированное объявление — attributable input, не полномочие маршрутизировать.

Receipt должен описывать именно проекцию

Практический недостающий объект — advertisement-projection receipt. Это предложение по evidence governance, а не новый wire requirement revision 04.

Receipt сохраняет hash и identity защищённого bundle, Source EID, BIB Security Source, Previous Node, destination, Hop Limit, Creation Timestamp и receive time. Он указывает фактически использованный identity-validation path и связывает message с ULN, termination point и CL instance отправки или приёма.

Для каждого message type сохраняются instances, Reference Time, Validity Duration, Repetition Interval и supersession verdict. При доступности фиксируется filter/configuration epoch advertiser. Получатель записывает authorization и culling с причиной, затем hash своей post-policy information-base projection.

Receipt заканчивается там, где начинается другая authority. Route installation получает отдельное решение. Forwarding требует data-plane observation. Application outcome требует собственного подтверждения. Один authenticated=true не должен скрыто означать complete, authorized, installed и delivered.

При наличии двух receipts расхождение классифицируется: intentional scope, разные policy epochs, stale data, supersession, local culling, unsupported parameter, delivery loss, misconfiguration или unexplained divergence. Без них расследование сравнивает картинки, а не воспроизводимые решения.

Draft остаётся draft

Datatracker показывает revision 04 как active Internet-Draft DTN Working Group, опубликованный 8 сентября 2026 года и истекающий 12 марта 2027 года. В header указано Standards Track; поле intended RFC status в Datatracker при фиксации было пустым. Это не RFC и не окончательная IANA allocation.

Implementation Status упоминает пример proof of concept. Там же сказано, что сведения даны contributors, не проверялись, не являются каталогом и не означают endorsement IETF. Статья не утверждает adoption, interoperability, поведение конкретного продукта, реальную атаку, route leak или outage.

RFC 9171 задаёт BPv7, RFC 9172 — BPSec, RFC 8949 и RFC 8610 — CBOR/CDDL. RFC 6130 даёт контекст neighborhood discovery. RFC 4593, RFC 7908 и RFC 6480 описывают routing threats, route leaks и RPKI. Ни один источник не превращает локальную SAND projection в глобальную истину.

Доказуемый вывод уже достаточно важен: authentication привязывает заявление к субъекту и контексту. Полнота, routing authority и outcome принадлежат последующим доказательствам.