RFC: 4303
Оригинал: IP Encapsulating Security Payload (ESP)
Предыдущие версии: RFC 1827, RFC 2406
Категория: Предложенный стандарт
Дата публикации:
Автор:
Перевод: Николай Малых

5. Соответствие требованиям

Реализации, которые заявляют о своем соответствии или совместимости с данной спецификацией, должны полностью реализовать синтаксис и обработку ESP, описанные здесь, для индивидуального трафика, а также должны полностью выполнять все требования документа по архитектуре защиты [Ken-Arch]. В дополнение к этому, реализации, заявляющие поддержку группового трафика, должны соответствовать всем дополнительным требованиям, заданным для такого трафика. При ручном распределении ключей, используемых для расчета ICV, корректная работа системы предотвращения повторного использования пакетов требует аккуратной поддержки состояния счетчика на передающей стороне при замене ключа, поскольку в этом случае невозможно восстановить работу после переполнения счетчика. Таким образом, совместимым со спецификацией реализациям не следует предоставлять такой сервис для SA с распространением ключей вручную.

Обязательные для реализации алгоритмы, используемые с ESP, описаны в отдельном документе [Eas04], для обеспечения возможности обновления алгоритмов независимо от протокола. Кроме обязательных для ESP алгоритмов могут поддерживаться дополнительные алгоритмы.

Поскольку шифрование в ESP не является обязательным, требуется поддержка «пустого» (NULL) алгоритма шифрования для обеспечения совместимости способов согласования сервиса ESP. Поддержка только услуг защиты конфиденциальности является опциональной. Если раелизация предлагает такой сервис, она должна поддерживать использование пустого (NULL) алгоритма контроля целостности. Отметим, что хотя услуги защиты целостности и конфиденциальности сами по себе могут использовать алгоритм NULL при указанных выше условиях, недопустимо выбирать NULL для обоих услуг сразу.

2007 - 2017 © Русские переводы RFC, IETF, ISOC.