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

2.5. Pad Length — размер заполнения

Поле Pad Length показывает число байтов заполнения, непосредственно предшествующих данному полю в поле Padding. Значение поля лежит в диапазоне от 0 до 255, где нулевое значение говорит об отсутствии байтов заполнения. Как было отмечено выше, в этом поле не учитываются байты заполнения TFC. Поле Pad Length является обязательным.

2.6. Next Header — следующий заголовок

Восьмибитовое обязательное поле Next Header показывает тип данных, содержащихся в поле Payload Data (например, пакет IPv4 или IPv6, заголовок и данные следующего уровня). Значения этого поля выбираются из списка номеров протоколов IP, представленного на сайте IANA. Например, значение 4 показывает протокол IPv4, значение 41 - IPv6, а 6 - протокол TCP.

Для упрощения быстрой генерации и отбрасывания трафика заполнения, используемого для обеспечения конфиденциальности потока (см. параграф 2.4), в «бутафорских» пакетах должен указываться идентификатор протокола 59 (нет следующего заголовка). Передающая сторона должна обеспечивать возможность генерации «бутафорских» пакетов с указанным значением поля, а получатель должен быть готов к отбрасыванию таких пакетов, без индикации ошибки. Все остальные заголовки и трейлерные поля ESP (SPI, Sequence Number, Padding, Pad Length, Next Header, ICV) должны присутствовать в «бутафорских» пакетах, но нешифрованную часть данных (кроме поля Next Header), следует делать бессмысленной (например, включать в эту часть поля Payload Data случайные байты). «Бутафорские» пакеты отбрасываются без какого-либо ущерба.

Реализациям следует обеспечивать локальные средства управления использованием «бутафорских» пакетов на уровне SA. Средствам управления следует давать пользователю возможность включения и выключения этой функции, а также управления параметрами (например, средства управления могут позволять администратору выбирать случайный или фиксированный размер «бутафорских» пакетов).

Обсуждение: «бутафорские» пакеты могут помещаться в поток со случайными интервалами для маскировки отсутствия реального трафика. Они могут также «формовать» реальный трафик в соответствии с некоторым распределением. Наибольший уровень защиты потоков трафика (TFS) будет обеспечивать генерация «бутафорских» пакетов со скоростью, обеспечивающей постоянную скорость передачи данных для SA. Если все пакеты имеют одинаковый размер, SA показывает постоянную скорость потока данных, аналогично средствам шифрования каналов на уровне 1 или 2. Однако, неочевидно, что такой подход будет подходить во всех случаях (например, при наличии множества активных SA такое решение будет приводить к неоправданному расходу полосы, сводящему на нет преимущества использования коммутации пакетов вместо коммутации каналов). Разработчикам следует обеспечивать средства управления, позволяющие локальному администратору управлять генерацией «бутафорских» пакетов для целей TFC.

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