Кратко

  • Редакция 25 требует конфиденциальности и целостности для зашифрованных Claims и запрещает ChaCha20 без аутентификации, но Marker не удостоверяет личность отправителя и его право занять адрес.
  • Узлы с ключом и без него способны образовать взаимно невидимые области обнаружения коллизий; даже успешно проверенная запись доказывает лишь доступ к допустимому ключевому материалу.

В распределённой системе отсутствие возражения легко принять за согласие. Для GAAP это особенно опасно: конкурентный Claim может не быть виден не потому, что его нет, а потому, что он зашифрован иначе. Тогда две группы участников принимают внутренне правильные решения на основании разных наборов фактов.

Редакция 25 проекта GAAP описывает облегчённое децентрализованное согласование multicast-адресов в административном домене. Хеш Group Name задаёт первый адрес-кандидат. Если разные имена претендуют на один адрес, возникает коллизия; ещё три позиции вычисляются добавлением 1, 2 или 3. Участник отправляет первоначальный Claim, ждёт примерно один периодический интервал, затем поддерживает мягкое состояние повторными Claims. Освобождение локально: отправка просто прекращается.

Статус проекта не позволяет называть это доказанным внедрением. IETF Datatracker указывает предполагаемый статус Experimental и этап IESG Evaluation::AD Followup. История документа показывает развитие спецификации, а не эксплуатацию. Сам текст признаёт, что децентрализованный хеш-подход ещё не развёртывался, а частота коллизий и масштабирование не измерялись.

Точный смысл усиления защиты

По сравнению с редакцией 23 новая версия формулирует требование жёстче. Шифрование Claim должно обеспечивать конфиденциальность и целостность, например средствами AEAD. Использовать один ChaCha20 нельзя. Из RFC 8439 видно почему: потоковый шифр без аутентификации податлив к модификации. Изменение шифротекста способно предсказуемо изменить расшифрованный адрес, метку времени или Group Name.

Nonce обязан быть уникальным для каждого ключа среди всех отправителей, которые этот ключ разделяют. Настроенный на ключ получатель должен отвергать незашифрованный Claim, чтобы защищённая группа не откатывалась незаметно в открытый режим. Это существенные улучшения.

Но Marker остаётся лишь неявным признаком шифрования. Он не передаёт общую схему согласования алгоритма, публичную идентичность или документ полномочий. Механизм, ключи, структура записи, associated data, схема nonce и динамическая смена ключей в основном остаются вне протокола. При неудаче расшифрования запись отбрасывается. Неверный ключ, несовместимый механизм, повреждение и умышленная атака могут выглядеть одинаково—Claim исчезает из наблюдаемого мира.

Криптографическая действительность не равна легитимности

Узел с ключом отвергает открытые Claims, а узел без ключа не читает зашифрованные. В одной физической сети появляются две отдельные картины занятости адресов. Каждая группа может добросовестно считать адрес свободным, поскольку опровергающая запись находится за её границей видимости.

Даже единая ключевая группа не решает вопрос полномочий. Злонамеренный участник, уже обладающий секретом, создаст полностью аутентифицированный Claim. Сравнение меток времени и детерминированное разрешение спора выберут протокольного победителя, но не подтвердят его добросовестность. Поэтому Bad Actor List сделан локальным, ограниченным и рекомендательным: источник можно подделать, а проигрыш по времени не доказывает умысел.

RFC 1982 задаёт арифметику серийных номеров, RFC 8085—правила осторожного применения UDP. Исторический контекст дают RFC 2365, RFC 5771, RFC 2730 и RFC 2909. Современную архитектуру и пробелы описывают RFC 10019 и RFC 10028. Ни один из них не превращает корректность пакета в титул на ресурс.

Разграничение должно сохраниться: криптография защищает утверждение; GAAP сравнивает видимые утверждения; внешняя модель полномочий решает, кто имел право утверждать.

Минимальный протокол и власть вокруг него

Принцип Lu Heng о минимальной исходной спецификации, локальном будущем решении и добровольном принятии соответствует экспериментальному характеру GAAP. Разумно сначала испытать узкий механизм, не возводя над ним громоздкий универсальный институт.

Но исключённые из пакета функции не исчезают. Тот, кто выдаёт ключ, допускает участника; тот, кто отзывает, исключает его. Определение круга расшифрования определяет и круг коллизий, признаваемых общим фактом. Администратор ключей способен незаметно стать фактическим распорядителем адресов.

Принцип приоритета работающего кода требует смотреть на систему, а не на надпись «encrypted»: какие Claims реально видны, что происходит при неполной смене ключей, кто замечает пересечение групп и кто несёт ущерб от конфликта.

Предыдущая статья BTW о GAAP-23, исправленных диапазонах и открытом вопросе сходимости после разделения исследовала другую границу: одно Group Name может остаться на разных запасных адресах после восстановления связи. Редакция 25 не закрывает тот вопрос. Она подчёркивает новый: логическое разделение может создать ключ, даже если физическая сеть цела.

GAAP-25 делает конверт надёжнее. Право положить в него действенную заявку по-прежнему возникает только за пределами конверта.

Источники