Кратко

  • Датированная 29 сентября редакция draft-ietf-schc-schclet-01 заполнила раздел, в котором в версии 00 стояло только «TBD»: SCHClet наследует положения безопасности RFC 8724, а входные данные, не соответствующие поддерживаемой Rule, должны безопасно обрабатываться согласно конфигурации.
  • Модульный подход, обязанность определить поддерживаемую конфигурацию и условие совместимости с полной реализацией уже были в первой версии. Нынешний документ остаётся Internet-Draft рабочей группы со статусом I-D Exists, а не утверждённым RFC или отчётом об испытаниях.

Экономия ресурсов — понятный мотив для частичной реализации Static Context Header Compression. Небольшому устройству может быть нужна отдельная функция сжатия или фрагментации, а не весь набор возможностей. Проект изначально описывал SCHClet как такой модуль в рамках одного Stratum и одного SCHC Instance. Документ, определяющий модуль, должен перечислить его поддерживаемую конфигурацию. Взаимодействие с полной реализацией зависит от совпадения параметров и их трактовки. Эти положения не появились 29 сентября.

Изменился раздел 6. Январская редакция откладывала рассмотрение безопасности; новая прямо распространяет на SCHClet положения RFC 8724 и других используемых спецификаций SCHC. Реализация должна безопасно обходиться с входными данными, для которых нет совпадения среди поддерживаемых Rule. Отклонение и пропуск указаны как возможные варианты, определяемые SCHClet Configuration. Общего действия по умолчанию, протокола испытаний и свидетельств работающих устройств проект не даёт.

В этом состоит практический предел слова «совместимый». Полная реализация может понимать правило, отсутствующее в узком модуле; часть входов может предназначаться другой стадии обработки. Для оценки конкретной пары нужны список Rule, класс входных данных, место принятия решения, выбранное действие и настройки второй стороны. Условная формулировка проекта о взаимодействии не подтверждает совместимость любой пары оборудования лишь потому, что на обоих изделиях указано SCHC.

Особенно важно не расширять значение примера с пропуском. Раздел 12.1.1 RFC 8724 рассматривает поддельный пакет SCHC с невыделенным RuleID на стороне распаковки и предусматривает его молчаливый сброс. Вход, не соответствующий поддерживаемым отдельным SCHClet правилам, может относиться к другому классу и другому месту цепочки. Редакция 01 сама по себе не разрешает пересылать такой поддельный пакет. Но и утверждать уже доказанный конфликт документов без уточнения типа пакета и пути обработки было бы необоснованно.

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

Источники