RFC: 4302
Оригинал: IP Authentication Header
Предыдущие версии: RFC 1826, RFC 2402
Категория: Предложенный стандарт
Дата публикации:
Автор:
Перевод: Николай Малых

RFC 4302, Страница 11 из 28

3.3.3. Расчет ICV

При расчете ICV в AH учитываются следующие поля:

  • Поля заголовка IP или расширения перед заголовком AH, которые не изменяются при передаче или предсказуемы на момент прибытия в конечную точку SA;

  • заголовок AH (поля Next Header, Payload Len, Reserved, SPI, Sequence Number — младшие 32 бита), поле ICV, значение которого на момент расчета принимается нулевым, и явные байты заполнения (если они есть);

  • все данные после заголовка AH предполагаются неизменными при передаче и учитываются в расчете;

  • старшие биты ESN (если расширенная нумерация используется) и все байты неявного заполнения, требуемые алгоритмом контроля целостности.

3.3.3.1. Обработка изменяемых полей

Если поле меняется в процессе передачи, при расчете ICV значение этого поля принимается нулевым. Если поле изменчиво, но его значение на уровне получателя IPsec предсказуемо, это значение может использоваться при расчете ICV. Значение поля Integrity Check Value при расчете также принимается нулевым. Отметим, что использвание нулевого значения поля вместо пропуска этого поля при расчете сохраняет выравнивание для расчета ICV. Кроме того, заполнение неучитываемых полей нулями предотвращает их изменение в процессе передачи, хотя содержимое этих полей и не покрывается явно ICV.

При создании нового расширения заголовка или опции IPv4 они определяются в соответствующем RFC и в сецификацию (раздел «Вопросы безопасности») следует включать инструкции по учету полей при расчете ICV для AH. Если реализация IP (v4 или v6) встречается с нераспознанным расширением заголовка, она должна отбросить такой пакет и передать отправителю сообщение ICMP. IPsec просто не увидит такого пакета. Если реализация IPsec сталкивается с нераспознанной опцией IPv4, эту опцию следует целиком обнулить, используя второй байт опции в качестве ее размера. Опции IPv6 (в заголовках Destination Extension или заголовке Hop-by-Hop Extension) содержат флаг изменчивости, который определяет порядок обработки такой опции.

Страница 11 из 28

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