Кратко

  • На APNIC 62 организация сообщила, что её хостируемый интерфейс ASPA предлагает провайдеров по данным RIPE RIS. Предложения вероятностны, требуют проверки и скорее бывают избыточными, чем неполными.
  • Интерфейс также оценивает влияние отправленного изменения на наблюдаемые пути BGP. Это полезная проверка настоящего, но не репетиция всех будущих маршрутов.
  • Текущий проект IETF рекомендует заранее добавлять резервных и аварийных провайдеров, чтобы распространение объекта RPKI не отстало от маршрута. У действительно неактивного провайдера ещё нет живого пути, который можно наблюдать.
  • APNIC стоит сохранять квитанцию происхождения и сценария: отдельно для наблюдаемой подсказки, заявления оператора, отклонённого кандидата, проверки текущих путей и неиспытанного переключения.

Автоматизация честно начинает с неполной карты

ASPA — подписанный список автономных систем, которым владелец ASN разрешает быть своими вышестоящими провайдерами. RPKI защищает объект, а валидаторы используют его при проверке отношений внутри AS_PATH. Подпись удостоверяет автора и содержимое, но не объясняет, как человек убедился, что список полон.

APNIC помогает именно до подписания. В докладе «APNIC RPKI Updates» на APNIC 62 было сказано, что хостируемый интерфейс обращается к asn-neighbours в RIPEstat. Соседства, замеченные Routing Information Service RIPE, становятся кандидатами — по аналогии с подсказками в управлении объектами маршрутов.

Формулировка APNIC заслуживает внимания своей сдержанностью. Подсказки названы вероятностными, их необходимо просматривать, а лишние включения считаются более вероятными, чем пропуски. После этого система проверяет предлагаемое множество по наблюдаемым путям BGP. Случайное удаление действующего провайдера можно обнаружить до публикации.

Так автоматизация остаётся помощником. Машина показывает наблюдение, владелец ресурса принимает решение о полномочии. Граница проходит по времени. Сервис защиты от DDoS может появляться в маршруте только во время атаки. Аварийный транзит для изолированного сегмента или холодная резервная линия могут не присутствовать в повседневном BGP. Невидимость для них — штатный режим.

RIS видит соседство, но не назначает роль

Документация RIPEstat аккуратно описывает результат. ASN Neighbours возвращает соседние ASN, наблюдавшиеся в RIS. Доступны позиция слева или справа, число путей, число полных пиров-наблюдателей, время запроса или окно действительности. Сосед может получить метку uncertain, если само прямое соединение с коллектором RIS могло создать такую картину.

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

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

Интерфейсу нужны две разные родословные записи. Первая: «этот ASN наблюдался рядом в таком-то окне RIS». Вторая: «владелец разрешает этому ASN быть провайдером, хотя сегодня он не используется». Одинаковые флажки без источника уничтожат сильную сторону обеих записей.

Проект IETF требует решения в тишине

Зафиксированные проекты IETF превращают этот пробел во временную гонку. Версия 29 профиля ASPA описывает один объект на Customer AS со всеми провайдерами, включая применимые непрозрачные серверы маршрутов. Единое полное множество уменьшает риск гонок при обновлении.

Версия 28 процедуры проверки AS_PATH отдельно говорит о резерве. Примеры — временный провайдер защиты от DDoS и аварийный провайдер, соединяющий изолированные части сети. Их рекомендуется включать заранее, чтобы распространение ASPA по миру не проиграло распространению маршрута.

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

Это зеркальная сторона известного ограничения ASPA. Наличие провайдера в объекте не доказывает, что он сейчас переносит трафик. И отсутствие видимого транзита не доказывает, что провайдера не следует разрешить заранее. Наблюдение и полномочие различны в обе стороны.

Из этого не следует, что APNIC скрывает недостаток. Публичный доклад не сообщает о неудачном переключении, отброшенном маршруте, ложной подсказке или пропущенном резерве и прямо просит отзывы. Внутренние поля интерфейса по слайдам неизвестны. Тексты IETF остаются изменяемыми Internet-Drafts, а не окончательными RFC. Доказан лишь предел метода: описанная проверка работает с наблюдаемыми путями, тогда как рекомендация охватывает разрешение, путь которого может законно отсутствовать.

«Конфликтов сейчас нет» — не то же самое, что «резерв проверен»

Пусть Customer AS обычно пользуется A и B, а C держит для аварийной защиты. RIS видит A и B, а также, возможно, пира D. Интерфейс предлагает A, B и D. Оператор удаляет D и вручную добавляет C.

Система может показать, что A всё ещё встречается в пути, B виден только в IPv6, а D пришёл из неопределённого соседства коллектора. Она может честно заключить, что финальное множество не конфликтует с проверенными текущими путями.

Но она не доказывает, что C объявит правильные префиксы, сохранит предусмотренный путь, выдержит нагрузку или включится лишь после того, как новый ASPA станет виден валидаторам. Даже лабораторное упражнение не гарантирует поведение во время реальной атаки.

Фраза «в наблюдаемом множестве конфликт не найден» полезна именно своей точностью. «Переключение валидировано» — другое утверждение. Один зелёный значок в заявке на изменение может означать правильный формат объекта, совместимость нынешних путей или успешную аварийную репетицию. Для каждого нужен свой материал.

Квитанция для ещё не существующего пути

Для исправления не надо публиковать договоры, реквизиты линий или защищённую схему реагирования. Квитанция может остаться в MyAPNIC и внутреннем журнале изменения.

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

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

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

На APNIC 62 был показан снимок из 293 ASPA в APNIC: 257 в хостируемых и 36 в делегированных центрах сертификации. Это число созданных объектов, а не валидирующих сетей, полных множеств или проверенных резервов. Новая страница ASPA в DASH может отдельно показывать публикацию, наблюдение, сценарную проверку и срок следующего пересмотра.

Маршрутное решение остаётся у сети

Проект IETF применяет функцию авторизации к упорядоченным парам ASN, а затем оценивает путь. Провайдер в действительном ASPA может дать положительную аттестацию; отсутствующий — отрицательную; без действительного объекта получается отсутствие аттестации. Проект рекомендует обращение с Invalid и Unknown, но политику смягчения настраивает принимающая сеть.

Разделение глаголов защищает полномочия. RIPE RIS наблюдает. APNIC предлагает, предупреждает и публикует. Владелец ASN разрешает. Валидатор вычисляет. Оператор сети выбирает действие. Зелёный значок не должен объединять эти роли.

Резервный провайдер особенно хорошо показывает границу: ценность его полномочия возникает раньше трафика. APNIC уже улучшила обычный случай. Сценарная квитанция позволит так же точно описать исключение: разрешён, не наблюдался, план проверен, публикация стала видна до необходимости.

Источники