Кратко

  • В повестке IESG на 24 сентября стоит проверка по RFC 5742 документа draft-irtf-nmrg-ai-challenges-06: это работа исследовательской группы NMRG из потока IRTF, намеченная к публикации как Informational.
  • Версия ответа -00 соединяла вывод об отсутствии конфликта с замечанием об атаках и опасных результатах ИИ. Версия -01 от 24 сентября сохранила предлагаемый вывод, но убрала замечание. Datatracker по-прежнему показывает IESG Evaluation и неразрешённый DISCUSS.
  • Для защиты обучающих данных и для запрета недопустимой сетевой команды нужны разные проверки. Ни одну из них сам факт рассмотрения документа не подтверждает.

Оператору мало услышать, что модель не подвергалась атаке. Если она предложит выделить каналу больше полосы, чем он физически способен передать, правильная история её обучения не спасёт конфигурацию. И наоборот: жёсткое ограничение полосы не обнаружит, что классификатор трафика обманули специально подготовленными данными. В обоих случаях на экране может появиться убедительная автоматическая рекомендация, но место контроля различно — до вывода модели и после него.

История версий превратила эту границу в новость о пределах полномочий. Ответ -00 предлагал считать, что документ NMRG не конфликтует с работой IETF, и просил учесть комментарий IRSG о разделах 9.2 и 9.3. Mohamed Boucadair согласился с основным выводом, однако возразил против требования отвечать на комментарии IRSG именно в данном документе; Tommy Jensen поддержал возражение. Версия -01 оставила предлагаемый вывод и убрала примечание. Последовательность событий не раскрывает всех мотивов редакции и не означает принятия решения: остаются IESG Evaluation и DISCUSS. Различие двух опасностей сохранилось в исследовании, а не в нынешнем проекте ответа.

Раздел 9.2 перечисляет воздействия на ИИ: отравление обучающих данных, обход классификации и извлечение сведений о данных обучения. Здесь важны происхождение входов, права на их изменение и результаты испытаний против противника. Раздел 9.3 описывает уже последствия работы системы: изменение таблиц фильтрации с нарушением правил доступа либо распределение ресурсов QoS сверх возможностей линии. Здесь нужен внешний по отношению к модели предел команд, поэтапное применение и проверяемый возврат. В проекте обсуждаются постепенные действия и откат, но из этого не следует доказанная надёжность какого-либо внедрения.

У RFC 5742 более узкий предмет, чем безопасность сетевого оборудования. IESG выясняет, вступает ли публикация из потока IRTF в конфликт с работой IETF; такая процедура не удостоверяет техническую пригодность инструмента. Документ отражает исследовательский консенсус и предназначен для информационной категории, а не для статуса интернет-стандарта. Даже итоговое «конфликта нет» не подтвердило бы работу контроллера в реальной сети. Источники не сообщают ни о внедрении, ни об аварии.

Daniel Kade предлагает перед практическим применением требовать две независимые записи. Первая — модель угроз, происхождение данных, круг лиц с правом изменения и испытания на отравление и обход. Вторая — перечень допустимых команд, ограничения ёмкости и политики, проверяемые без доверия к модели, условия остановки и фактически восстановленное состояние после отката. Это редакционное предложение, не правило IETF. Оно не позволяет подменить безопасность результата отчётом о целостности модели.

Sources