Кратко

  • Намеренно неверный ноль допустим только после того, как партнёр объявил в INIT или INIT ACK поддерживаемый альтернативный метод для данной ассоциации.
  • Альтернатива обязана не хуже CRC32c выявлять ошибки и не допускать отказ пути из-за middlebox дольше двух RTO; для установления связи, особых пакетов и отката правильная CRC32c сохраняется.

Значение без контекста не является доказательством

Обычная SCTP-дейтаграмма несёт 32-битную CRC32c в общем заголовке. По RFC 9260 отправитель вычисляет её по общему заголовку и всем chunks, а получатель отбрасывает пакет с неправильной суммой. Псевдозаголовок IPv4 или IPv6 в расчёт не входит. Michael Tüxen — один из авторов этой действующей базовой спецификации SCTP.

Но ноль не зарезервирован для пропущенного расчёта: корректная CRC32c тоже способна дать такой результат. Поэтому один пакет не сообщает, вычислялась ли сумма или отправитель намеренно поставил неверный ноль. Система наблюдения, которая маркирует всякий ноль как отключение проверки, ошибётся; система, считающая всякий ноль корректным результатом, пропустит нарушение.

RFC 9653 помещает разрешение в начало ассоциации. Конечная точка может не более одного раза включить параметр Zero Checksum Acceptable в INIT или INIT ACK и указать конкретный метод обнаружения ошибок. Отправитель получает право на намеренно неверный ноль лишь после этого объявления, при собственной поддержке метода и, если требуется, после одобрения верхнего уровня.

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

Две независимые проверки замены

Сначала альтернативный метод сравнивают с CRC32c: вероятность не заметить ошибку должна быть такой же или ниже. Метод вправе задать ограничения для отдельных пакетов. Ссылки на «имеющееся шифрование» недостаточно — защита должна охватывать именно тот трафик, где применяется исключение.

Затем проверяют путь. SCTP-aware middlebox может валидировать CRC32c и отбрасывать намеренно неверное поле. Спецификация требует, чтобы вызванный этим отказ пути не продолжался более двух интервалов retransmission timeout. Тем самым неизвестность поведения посредников превращается в ограниченный по времени режим обнаружения и возврата.

SCTP поверх DTLS из RFC 8261 удовлетворяет обоим условиям. При передаче SCTP через UDP напрямую либо посредством ICE/UDP DTLS даёт конфиденциальность, аутентификацию источника и целостность. Он выполняет обнаружение ошибок и скрывает внутренний пакет SCTP от посредника, который иначе мог бы отвергнуть его CRC. В RFC 9653 этому варианту присвоен идентификатор 1 — регистрационный номер, а не оценка защищённости.

SCTP-AUTH из RFC 4895 показывает, почему одного условия мало. Если AUTH стоит первым chunk, аутентификация может выполнить требование к обнаружению для защищённого содержимого. Общий заголовок остаётся видимым, и посредник по-прежнему способен потребовать правильную CRC32c. Без дополнительного механизма конкретного развёртывания AUTH сам по себе не доказывает совместимость пути.

Пакеты, для которых исключения нет

Даже в согласованной ассоциации INIT требует правильной CRC32c. То же относится к ответам на out-of-the-blue трафик, к COOKIE ECHO и ASCONF. Пакеты за пределами условий альтернативного метода возвращаются к исходному правилу. Если партнёр не объявил приемлемый метод, исключение отсутствует полностью.

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

Настоящая поверхность управления шире четырёх байтов: параметры INIT и INIT ACK, поддержка метода, политика верхнего уровня, внешняя защита, классификация пакетов, таймеры RTO и поведение middlebox. Пропустить только вычислительную операцию, не поддержав это состояние, значит нарушить, а не реализовать RFC.

Инженерная граница Michael Tüxen

Michael Tüxen руководит Network Programming Laboratory в FH Münster. IETF Datatracker также указывает его как действующего сопредседателя TCPM, рецензента TSVART и участника десятков RFC. Его работа и над базовым SCTP, и над контролируемым исключением показывает непрерывность подхода.

RFC 3309 прежде заменил Adler-32 на CRC32c, чтобы улучшить обнаружение ошибок SCTP. RFC 9653 не отменяет эту цель. Он допускает перенос работы на квалифицированный слой, но требует сохранить сопоставимую защиту и жизнеспособность пути.

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

Источники