Кратко

  • RFC 3554 переносит множества адресов многосвязной SCTP-ассоциации в селекторы IPsec. Проверять нужно каждый элемент; успешная Phase 1 подтверждает пира, но не его право на произвольный адрес.
  • Итоговое множество доказано лишь тогда, когда одна версия прослеживается через исправление IKE, установку SPD, поиск одной SA по всем адресам в SAD и фактический выбор пути SCTP.

Для приложения ассоциация одна. Для сети это набор сочетаний источников и назначений, которые могут не входить в общий префикс. Отдельная политика для каждой пары прозрачна, но число правил быстро растёт. Единый селектор экономнее, зато одна ложная запись получает влияние на весь объект.

RFC 3554 вышел в июле 2003 года как Proposed Standard. Он предлагает множества адресов в селекторах и требует, чтобы любой согласованный адрес назначения вместе с теми же SPI и протоколом безопасности находил одну SA.

Удостоверение личности не определяет адресный периметр

IKE Phase 1 устанавливает личность контрагента согласно принятой учётной записи и политике. Ответчику всё равно нужны доказательства, что инициатор уполномочен получать трафик по каждому заявленному адресу.

Основанием могут быть сертификаты и идентификаторы Phase 1 либо внешняя политика. Один сертификат способен содержать несколько subject alternative names; несколько сертификатов могут использовать один публичный ключ. Это способы выразить связь, а не отменить решение о её границах.

Иначе действительный пир сможет присвоить адрес другого. Пакет будет зашифрован правильной SA, но направлен туда, куда не следовало. Ошибка произойдёт до криптографии, поэтому криптографический успех её не исправляет.

В журнале нужны два вердикта: личность принята и версия адресного множества разрешена. Второй перечисляет элементы, основание, срок, владельца решения и отдельный результат по каждому адресу.

Смена ролей исправляет асимметрию знания

Инициатор первого Quick Mode может не знать полный набор ответчика. При неточных селекторах ответчик меняет роли, запускает новый Quick Mode, переносит относящийся к SA контекст и исправляет свою часть списка. Реализация IKE с SCTP должна поддерживать этот ход.

Это не повтор прежней заявки. Теперь утверждение делает сторона с более точным знанием. Если хранить только последний успех, пропадут исходная ошибка, причина исправления и дельта. Следует связать предложение, диагноз, проверку элементов и финальное согласие.

ID_LIST упаковывает несколько Identification Payloads и запрещает вложенные списки. Ограниченная форма упрощает разбор, но не удостоверяет владение, полноту или установку.

Одна согласованная версия должна дойти до каждой базы

SPD устанавливает итоговый селектор. SAD должна возвращать одну SA для каждого согласованного адреса назначения. SCTP выбирает путь только из этого множества.

Успех IKE совместим с расхождением: элемент отсутствует в SPD, поиск работает лишь по основному адресу либо старое правило выигрывает по приоритету. Проверка единственного пути ничего не говорит о резервном, который проснётся во время аварии.

Сохраняйте хеш и версию множества, квитанцию SPD и результат SAD-поиска для каждого адреса. Выполняйте управляемое переключение и негативный тест с неучастником. Только положительный тест не показывает границу запрета.

Изменение адреса начинает новое решение

Базовый SCTP 2003 года не менял адреса в активной ассоциации, но RFC 3554 заранее описал риск перенаправления: злоумышленник добавляет контролируемый адрес и получает последующий трафик.

Поздний RFC 5061 определил Dynamic Address Reconfiguration с аутентифицированными управляющими блоками. Это контекст, а не свидетельство внедрения. Подлинный запрос на добавление доказывает автора запроса, но не его права на адрес.

Любое добавление или удаление требует новой версии, повторной авторизации элементов, синхронной проекции SCTP/IPsec, подтверждения вывода старого состояния и наблюдения пути. Принятое обновление ещё не означает завершённый переход.

Восстанавливаемая цепочка доказательств

Сначала фиксируются идентификатор Phase 1, цепочка, ключ, политика и время проверки. Затем каждый адрес получает источник полномочия и решение. SCTP-ассоциация хранит обе стороны множества и версию.

Для Phase 2 сохраняются первое предложение, члены ID_LIST, порты, протокол, SPI, преобразования и инициатор. Смена ролей связывается с исходной транзакцией. SPD/SAD дают квитанции установки; плоскость данных показывает выбранное назначение, SA, результат защиты и предполагаемого получателя.

RFC 2960 и RFC 4960 ограничивают контекст SCTP, RFC 2401, RFC 2409 и RFC 2407 — тогдашний IPsec/IKE, RFC 4301 — позднюю архитектуру. Ни один документ не доказывает конкретное внедрение или инцидент.

Граница доказательств

Статья не называет оператора, продукт, сертификат, адрес, SA, атаку или пострадавшего. Она не утверждает уровень внедрения, наблюдавшуюся эксплуатацию или измеренную стоимость. Сценарии следуют из возможностей протокола.

Эссе Heng Lu о приоритете работающего кода и минимальной начальной спецификации — раскрытые редакционные линзы. Они помогают разделять текст, установку и результат, но не доказывают намерение авторов RFC или производственное событие.

Вывод точен: IKE может подтвердить подлинного пира и принять синтаксически правильный список. Право каждого элемента доказывают только адресная авторизация, согласованная проекция и наблюдение конкретного пути.

Sources