Кратко

  • Опубликованный 20 августа проект DOA связывает префиксы и их длины, исходную AS, необязательные промежуточные AS и BGP Communities с подписью владельца адресного ресурса.
  • Состояние DOA остаётся независимым от ROV и не задаёт действие по умолчанию; документ не принят IETF, а безопасность, эксплуатация и доставка по RPKI-RTR не описаны полностью.

Удалённо запускаемый blackholing требует точности: сеть объявляет более специфичный маршрут, чтобы вышестоящий оператор отбросил трафик к атакуемому адресу раньше перегруженной линии. Но та же длина префикса может превысить maxLength в ROA. Тогда намеренно созданный аварийный маршрут получает ROV-состояние Invalid.

В draft-spaghetti-grow-rpki-doa-00 предлагается не ослаблять обычную проверку происхождения, а выдать отдельное полномочие. Discard Origin Authorization был бы подписанным объектом RPKI, содержащим разрешённую исходную AS, диапазоны адресов и длин префикса, Classic или Large BGP Communities, а также, при необходимости, AS соседей, которым разрешена передача сигнала.

Публикация 20 августа не означает решения IETF. Datatracker называет документ индивидуальным Internet-Draft, прямо указывает на отсутствие поддержки IETF и формального статуса в процессе стандартизации. Авторы перенесли предложение 2022 года из имени, ориентированного на SIDROPS, в новое имя для GROW. Принятие рабочей группой источниками не подтверждено.

В новой редакции есть конкретное уточнение. Старый текст оставлял открытым вопрос, должны ли несколько Communities сопоставляться как AND или OR. Теперь действует логическое OR: для этой части проверки достаточно одной указанной Community на принятом маршруте. Если издатель не выбрал другое значение, инструмент подписи может по умолчанию добавить well-known BLACKHOLE Community из RFC 7999.

Однако одной метки недостаточно. Для Matched должны одновременно совпасть исходная AS, допустимая длина, источник получения и хотя бы одна Community. Маршрут принимается непосредственно от origin AS либо от AS, включённой в peerAsIDs. Если валидный объект покрывает префикс, но ограничения не совпадают, результатом будет Unmatched; при отсутствии покрывающего объекта — NotFound.

ROV вычисляется отдельно. Легитимный маршрут сброса может иметь DOA Matched и ROV Invalid одновременно. Проект предлагает проверить узкое разрешение раньше, а несовпавшие и отсутствующие случаи вернуть в обычную политику, включая ROV. Он также запрещает совместимым реализациям принимать действие по умолчанию только на основании одного из состояний. Установку, отклонение, экспорт или сброс должен явно определить оператор.

Так подпись не превращается в универсальное доказательство. Валидная DOA подтверждает полномочие владельца ресурса на заданную комбинацию. Она не доказывает сам факт атаки, текущую волю отправителя, подлинность всего AS path или необходимость именно сброса трафика.

Граница экспорта сохраняется. RFC 7999 в общем случае рекомендует не распространять blackhole-маршрут за пределы принявшей его AS. Проект делает узкое исключение, когда локальная AS явно перечислена как разрешённый peer. Это позволяет один дополнительный переход, но не создаёт неограниченного транзитивного разрешения.

Отдельный объект нужен из-за риска другой схемы. Если расширить maxLength обычной ROA ради аварийного более специфичного анонса, расширится и повседневное полномочие origin AS. RFC 9319 предостерегает от чрезмерно широких максимальных длин. DOA должна ограничить дополнительную длину назначением blackholing.

До эксплуатации остаются существенные пробелы. Расширение RPKI-RTR для передачи DOA вынесено в будущий документ. Разделы об эксплуатации и безопасности ещё не написаны, а значения IANA не назначены. Упомянут один подписывающий инструмент на Python, но сведения предоставлены участниками, не проверены независимо и не показывают совместимость с валидаторами и маршрутизаторами.

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

Источники