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

3.2. Алгоритмы

Обязательные для реализации алгоритмы, используемые с ESP, описаны в отдельном RFC для упрощения процедур обновления требований к алгоритмвам, независимо от протокола. Кроме обязательного набора для ESP могут поддерживаться и другие алгоритмв. Отметим, что несмотря на опциональных характер поддержки конфиденциальности и целостности, по крайней мере одна из этих служб должна быть выбрана и, следовательно, недопустимо устанавливать значение NULL доновременно для обоих алгоритмов.

3.2.1. Алгоритмы шифрования

Алгоритм шифрования, используемый для защиты пакета ESP задается на уровне SA в которой пакет передается/принимается. Поскольку пакеты IP могут доставляться с нарушением порядка и потерей части пакетов, в каждом пакете должны содержаться все данные, требуемые получателю для выполнения криптографической синхронизации при расшифровке. Эти данные могут передаваться явно в поле payload (например, как описанный выше вектор инициализации IV ) или выделяться из незашифрованной части заголовка пакета (внешнего заголовка IP или заголовка ESP). Поскольку ESP использует заполнение незашифрованной части, используемый ESP алгоритм шифрования может демонстрировать характеристики блочного или потокового режима. Поскольку шифрование (конфиденциальность) может быть опциональной услугой (например, в ESP с обеспечением только контроля целостности), этот алгоритм может быть пустым (NULL) [Ken-Arch].

Чтобы позволить реализации ESP рассчитывать заполнение для шифрования, требуемое блочными алгоритмами, и определять влияние алгоритма на MTU, в RFC для каждого алгоритма, используемого с ESP, должен задаваться модуль заполнения.

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