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

RFC 4303, Страница 10 из 32

2.7. Заполнение TFC

Как было отмечено выше, размер поля Padding ограничен 255 байтами. В общем случае этого не достаточно для адекватного сокрытия харакетристик трафика с целью обеспечения конфиденциальности. Для решения задач обеспечения конфиденциальности потоков (TFC) используется специальное необязательное поле.

Реализациям IPsec следует обеспечивать возможность заполнения трафика путем добавления байтов после поля Payload Data, но до начала поля Padding. Однако такое заполнение (его часто называют заполнением TFC) может добавляться только в тех случаях, когда поле Payload Data содержит размер дейтаграммы IP. Это требование всегда выполняется в туннельном режиме и может выполняться в транспортном, если протокол следующего уровня (например, IP, UDP, ICMP) содержит точное значение размера. Информация о размере позволяет получателю пакета отбросить заполнение TFC, поскольку известен истинный размер поля Payload Data (поля трейлера ESP находятся путем отсчета от конца пакета ESP). Соответственно, при добавлении заполнения TFC значение поля, содержащего размер дейтаграммы IP недопустимо менять с учетом этого заполнения. Данный стандарт не включает требований к содержимому заполнения.

In principle, existing IPsec implementations could have made use of this capability previously, in a transparent fashion. However, because receivers may not have been prepared to deal with this padding, the SA management protocol MUST negotiate this service prior to a transmitter employing it, to ensure backward compatibility. Combined with the convention described in Section 2.6 above, about the use of protocol ID 59, an ESP implementation is capable of generating dummy and real packets that exhibit much greater length variability, in support of TFC.

Implementations SHOULD provide local management controls to enable the use of this capability on a per-SA basis. The controls should allow the user to specify if this feature is to be used and also provide parametric controls for the feature.

2.8. ICV — контроль целостности

The Integrity Check Value is a variable-length field computed over the ESP header, Payload, and ESP trailer fields. Implicit ESP trailer fields (integrity padding and high-order ESN bits, if applicable) are included in the ICV computation. The ICV field is optional. It is present only if the integrity service is selected and is provided by either a separate integrity algorithm or a combined mode algorithm that uses an ICV. The length of the field is specified by the integrity algorithm selected and associated with the SA. The integrity algorithm specification MUST specify the length of the ICV and the comparison rules and processing steps for validation.

Страница 10 из 32

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