RFC-2406. Протокол защиты полезной нагрузки IP-пакетов путем их повторного обрамления (ESP) для IPsec-архитектуры. Ноябрь 1998 года (категория: стандарт)

Подождите немного. Документ загружается.

RFC 2406 ноябрь 1998 года

категория: стандарт

Протокол защиты полезной нагрузки IP-пакетов

путем их повторного обрамления (ESP)

(IPsec)

I. ПРЕДИСЛОВИЕ

Протокол защиты полезной нагрузки IP-пакетов (ESP-протокол)

разрботан для обеспечения различных услуг безопасности при использовании

IPv4- и IPv6-адресации. ESP-протокол может использоваться самостоятельно

или в комбинации АН-протоколом, или в групповом режиме, то есть в режиме

туннелирования (РТУ). Этот протокол предоставляет услуги по обеспечению

безопасности между двумя IP-узлами, между двумя шлюзами безопасности или

между IP-узлом и шлюзом безопасности.

Сообщение ESP-протокола (или просто ESP-заголовок) размещается

после IP-заголовка и перед заголовком протокола верхнего уровня (в

транспортном режиме — РТР) или перед внутренним IP-заголовком (в РТУ).

ESP-протокол используется для обеспечения конфиденциальности,

аутентификации источника данных, целостности виртуального соединения,

защиты от повторной передачи IPsec-пакетов и ограничения потока

конфиденциального трафика

. Набор услуг по обеспечению безопасности

зависит от конкретных настроек в период установления защищенного

виртуального соединения (SA — “Security Association”) и от места нахождения

самого программного IPsec-модуля (то есть с каким программным комплексом

интегрирован IPsec-модуль). Услуга по обеспечению конфиденциальности

может быть выбрана независимо от других услуг. Однако, ее применение без

услуг обеспечения целостности и аутентификации (

либо в рамках ESP-

протокол, либо независимо в рамках АН-протокола) может привести к

ситуации, когда трафик будет подвержен некоторым разновидностям активных

атак, которые могут вообще дискредитировать понятие “конфиденциальности”.

Услуги по аутентификации источника данных и обеспечению целостности

виртуального соединения являются дополнительными (далее по тексту обе эти

услуги будут именоваться одним термином “аутентификация

”) и предлагаются

для совместного применения с услугой обеспечения конфиденциальности.

Услуга по защите от повторной передачи IPsec-пакетов может использоваться

только в том случае, когда выбрана услуга по аутентификации источника

данных, и ее выбор осуществляется только по усмотрению приемного IPsec-

модуля (то есть прерогатива последнего). (Несмотря на то, что в режиме “по

умолчанию”

передающий IPsec-модуль постоянно увеличивает

последовательный номер в IPsec-пакетах, который используется для защиты от

их дублирования, эта услуга будет только тогда эффективна, когда приемный

IPsec-модуль проверяет последовательные номера.) Услуга по обеспечению

конфиденциальности потока трафика требует установления РТУ, более того

реализация этой услуги более эффективна, если она осуществляется в

программном комплексе шлюза безопасности, в котором процедура

мультиплексирования различных подпотоков трафика позволяет “маскировать”

истинные адреса отправителей и получателей IPsec-пакетов. (

Замечание.

Несмотря на то, что услуги по обеспечению конфиденциальности и

аутентификации являются произвольными, с точки зрения выбора, по крайней

мере одна из них должна обязательно быть выбрана для применения.)

II. ФОРМАТ IP-ПАКЕТА ПОСЛЕ ESP-ОБРАБОТКИ (ESP-ПАКЕТ)

IP-заголовок (IPv4, IPv6 или заголовок расширения), после которого

сразу следует ESP-заголовок (рис.1), содержит в поле “Протокол” (для IPv4)

или в поле “Следующий заголовок” (для IPv6 или заголовок расширения)

параметр со значением “50”.

Далее идет рассмотрение предназначений каждого поля, которые

определяют формат ESP-заголовка (сообщения ESP-протокола). Термин

“Optional” означает, что указанное поле опускается, если данная

дополнительная функция

не используется. Выбор (необходимость применения)

той или иной дополнительной функции определяется в период установления

защищенного виртуального соединения. Следовательно, формат ESP-пакетов

для конкретного SA фиксирован и остается без изменений во время всего

“периода жизни” SA. С другой стороны, “обязательные” поля всегда

присутствуют в формате ESP-пакета, причем для всех SA.

2.1. Поле “Индекс параметров безопасности (SPI)”

Это поле содержит произвольное 32-битовое значение, которое в

совокупности с IP-адресом получателя и протоколом безопасности (АН-

протокол), однозначно определяет защищенное виртуальное соединение для

данного IP-пакета. Диапазон значений 1...255 для SPI-параметра зарезервирован

IANA для последующего использования. Это означает, что IANA не будет

использовать данный диапазон, за исключением тех значений, которые будут

стандартизованы в RFC. Значение

данного параметра обычно выбирается

системой-получателем сообщения после формирования SA. Это поле является

обязательным.

Значение “0” параметра зарезервировано для локального применения

специализированным программным обеспечением и не должно передаваться по

линиям связи. Например, прикладной процесс управления распределением

ключевой информации может использовать нулевое значение “SPI” для

указания отсутствия SA в течении периода, когда IPsec-модуль запросил этот

процесс для обмена ключевой информацией при формировании нового SA, но

SA еще пока не сформировано.

Первый октет Второй октет Третий октет Четвертый октет

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

“ Индекс параметров безопасности” (SPI)

“ Последовательный номер”

“ Поле полезной нагрузки”

(данные)

( переменное)

“ Дополнение” (0…255 октетов)

Размер поля “Дополнение” “Следующий заголовок”

“ Данные аутентификации”

( переменное)

Ши

фру

ется

Аутентифицируется

“*” — если это поле содержит данные для синхронизации криптопроцессов (например,

“Вектор начальной установки”), то эти данные как правило не шифруются, несмотря

на то, они указываются как часть шифртекста.

Рис.1.

2.2. Поле “Последовательный номер”

Это “неподписываемое” 32-битовое поле содержит монотонно

возрастающее значение параметра (последовательный номер). Оно является

обязательным и всегда присутствует в ESP-заголовке, даже если получатель

(приемный IPsec-модуль) не использует услугу по защите от повторной

передачи IPsec-пакетов для определенного SA. Обработка этого поля

осуществляется по усмотрению получателя, то есть отправитель (передающий

IPsec-модуль) должен всегда

использовать это поле, но получатель может не

нуждаться в его обработке.

Счетчики IPsec-пакетов у отправителя и получателя устанавливаются в

“0” (синхронизируются) в момент формирования SA. Если процедура защиты

от повторной передачи IPsec-пакетов установлена “по умолчанию”, то тогда

нельзя никогда допускать, чтобы последовательный номер повторялся. Таким

образом, счетчики IPsec-пакетов отправителя и получателя должны

переустанавливаться (путем формирования нового SA и, следовательно,

обновления клечевой информации) еще до того, как будет передан по этому SA

-й IPsec-пакет.

2.3. Поле полезной нагрузки

Это поле является полем переменной длины и содержит данные в

соответствии с полем “Next Header”. Данной поле является обязательным и

состоит из целого числа байтов (октетов). Если алгоритм, используемый для

шифрования этого поля, требует данных для синхронизации криптопроцессов

(например, вектор начальной установки (ВНУ) — “Initialization Vector”), то

тогда это поле может содержать эти данные в

явном виде. Любой

криптоалгоритм, который требует такой процедуры, должен в своем стандарте

(RFC) содержать всю необходимую информацию о размере ВНУ, струтуре

данных, их местоположении в поле полезной нагрузки, как алгоритм который

используется совместно с ESP-протоколом. Более того, если данные для

синхронизации криптопроцессов представлены в поле полезной нагрузки в

неявном виде, то

тогда в стандарте (RFC) должен быть специальный раздел,

который раскрывает алгоритм “извлечения” такой информации.

(

Замечание. В целях гарантированной синхронизации (реального)

шифртекста при наличии в нем ВНУ:

n для некоторых режимов функционирования, основанных на ВНУ —

приемный криптомодуль (криптопроцесс) обрабатывает ВНУ как стартовую

синхропоследовательность основного шифртекста, который поступает

прямо на расшифрование в прикладной криптопроцесс. В этих режимах,

вопрос обработки стартовой синхропоследовательности основного

шифртекста в приемном криптомодуле неактуален;

o в некоторых случаях, приемный криптомодуль анализирует ВНУ отдельно

от основного шифртекста. В таких случаях, стандарт на криптоалгоритм

должен расскрывать механизм синхронизации (реального) шифртекста.)

2.4. Дополнение (для процедуры шифрования)

Существует несколько причин использования поля “Дополнение”

(“Padding”), вот некоторые из них:

c применение криптоалгоритма, который требует, чтобы открытый текст

был кратен некоторому числу октетов (байтов), например, размеру блока

для блочного шифра. Тогда используется поле “Дополнения”, чтобы

дополнить открытый текст (включая собственно поле “Дополнение”, поле

“Размер поля “Дополнение”, а также поле “Следующий заголовок”, то

есть все три поля выступают в роли дополнения открытого

текста) до

размера, который требуется криптоалгоритмом;

d поле “Дополнение” может потребоваться даже невзирая на требования

криптоалгоритма. Например, когда рузультирующий шифртекст

“заканчивается” на 4-байтовой границе. Тогда (на рис.1 это видно),

справа должны размещаться два поля “Размер поля “Дополнение” и

“Следующий заголовок”, причем в рамках 32-битового слова (4

октета/байта), которое будет включать поле “Дополнение” перед этими

двумя полями. Это также необходимо, чтобы следующее поле “Данные

аутентификации” начиналось с 4-байтовой границы;

e процедура дополнения, которая не вызвана причинами, представленными

выше (то есть требованиями криптоалгоритма). Она может быть

использована для “маскирования” реального размера полезной нагрузки с

целью обеспечения конфиденциальности потока трафика (или его части).

Однако, применение такой процедуры дополнения приведет к

отрицательному эффекту с точки зрения оптимального использования

пропускной способности системы, и поэтому ее

использование должно

предприниматься с большой осторожностью.

Передающий IPsec-модуль может использовать 0…255 байтов (октетов)

дополнения. Вставка поля “Дополнение” в ESP-пакет является дополнительной

функцией, однако, все программные реализации IPsec-модуля должны

обеспечивать генерирование и извлечение дополнительной байтовой

последовательности (ДБП) по следующим причинам:

a. с целью гарантированного обеспечения кратности числа битов для

блочных криптоалгоритмов. Вычисление длины поля “Дополнение”

должно учитывать включение ВНУ и полей “Размер поля “Дополнение” и

“Следующий заголовок”;

b. с целью гарантированного обеспечения начала поля “Данные

аутентификации” с 4-байтовой границы. Вычисление длины поля

“Дополнение” должно учитывать включение ВНУ и полей “Размер поля

“Дополнение” и “Следующий заголовок”.

Если функция байтового дополнения является необходимой, но стандарт

криптоалгоритма не определяет содержание ДБП, то тогда в режиме “по

умолчанию” должна использоваться следующая процедура

обработки. ДБП

должна начинаться с серии целых однобайтовых чисел (не подвергающихся

процедуре аутентификации). Первый байт дополнительной последовательности

начинается сразу после открытого текста и имеет значение “1”. Последующие

байты ДБП монотонно увеличиваются на одну единицу: “1”, “2”, “3”, … Если

используется такая схема ДБП, то тогда приемному криптомодулю (IPsec-

модулю) целесообразно “инспектировать” поле “Дополнение”. (Данная схема

была

выбрана вследствие ее относительной простоты и легкости при

использовании в аппартно-программных комплексах, а также потому, что ее

применение не требует дополнительной защиты от атак типа “вырезка и

вставка текста” при отсутствии каких-либо других средств обеспечения

целостности, если же конечно приемный IPsec-модуль проверяет содержание

ДБП после расшифрования.)

Любой криптоалгоритм, требующий использования функции байтового

дополнения, которая отлична от функции “по умолчанию”, должен в

специализированном стандарте RFC определять содержание ДБП (например,

серия нулей или случайное число) и схему (правила) необходимой обработки

этой ДБП приёмным IPsec-модулем, указывая порядок своего применения

совместно с ESP-протоколом. При таких условиях, содержание ДБП (поля

“Дополнение”) будет

определяться криптоалгоритмом, а порядок выбора и

определения режима — соотетствующим алгоритмом, представленным в RFC.

Этот RFC-алгоритм может определять порядок обязательной проверки поля

“Дополнение” приёмным IPsec-модулем, или как приёмный IPsec-модуль

должен информировать передающий IPsec-модуль о том как приёмный IPsec-

модуль будет (или не будет) обрабатывать поле “Дополнение”.

2.5. Поле “Размер поля “Дополнение”

Это поле указывает число байтов (октетов) поля “Дополнение”, которое

предшествует ему. Диапазон допустимых значение — 0…255, причем значение

“0” указывает на отсутствие байтов дополнения. Данное поле явялется

обязательным.

2.6. Поле “Следующий заголовок”

Это поле состоит из 8 битов, которые определяют тип данных,

содержащихся в поле полезной нагрузки (например, заголовок расширения для

IPv6-адресации или идентификатор протокола верхнего уровня). Значение

этого поля может иметь различные величины, которые определены в “Assigned

Numbers” RFC 1700 (Internet Assigned Numbers Authority — IANA). Данное

поле является обязательным.

2.7. Поле “Данные аутентификации”

Это поле является полем переменной длины и содержит значение

контрольной суммы (“Integrity Check Value” — ICV) в интересах обеспечения

целостности ESP-пакета, которое вычисляется по всей последовательности

ESP-пакета, за исключением самого поля “Данные аутентификации”. Размер

этого поля определяется выбранной функцией по обеспечению

аутентификации. Данной поле является не обязательным, и включается только

тогда, когда была выбрана услуга

аутентификации для конкретного

защищенного виртуального соединения. Стандарт алгоритма аутентификации

должен определять размер ICV, правила сравнения и алгоритм обработки с

целью проверки контрольной суммы.

III.

ESP-ОБРАБОТКА

3.1. Размещение ESP-заголовка

Подобно АН-протоколу, ESP-протокол может использоваться в двух

режимах: РТР и РТУ. РТР применяется только IP-узлами и обеспечивает

защиту сообщений протоколов верхних уровней, но не IP-заголовка.

(

Замечание. В этом режиме, программное обеспечение LAN-сервера или

линейнего шифратора (криптопроцессора) может “требовать” от встроенного

программного IPsec-модуля дополнительной сборки/расборки

входных/выходных фрагментов IPsec-пакетов в целях согласования с данным

стандартом и обеспечения “прозрачности” IPsec-обработки. Также и в условиях

применения нескольких криптоинтерфейсов необходимо обеспечение

вышеуказанных процедур.)

В РТР, ESP-заголовок размещается сразу после IP-заголовка и перед

заголовком сообщения верхнего уровня (например, TCP, UDP, ICMP и др.), или

перед любым другим IP-заголовком, который был размещен ранее. С точки

зрения IPv4-адресации, ESP-заголовок транслируется после IP-заголовка (и

любого поля дополнительной услуги, содержащегося в нем), но раньше

сообщения протокола верхнего уровня. На рис.2 приведен

состав ESP-

сообщения при использовании РТР для IPv4-адресации (до и после IPsec-

обработки). (Термин “ESP-концевик” включает в себя поля “Дополнение”,

“Размер поля “Дополнение” и “Следующий заголовок”.)

До

-обработки

Оригинальный IP-

заголовок

(любое число полей

“Дополнительная

услуга”)

ТСР-заголовок

Данные

После

-обработки

Оригинальный IP-

заголовок

(любое число полей

“Дополнительная

услуга”)

ESР-заголовок ТСР-заголовок

ESР-концевик

Данные

ESР-поле

“Данные

аутентификации”

Аутентифицируется

Шифруется

При

использовании

IPv4-адресации

Рис.2.

В контексте IPv6-адресации, ESP-сообщение рассматривается как

полезная нагрузка (поле данных), которой обмениваются между собой два

оконечных IPsec-модуля, и поэтому оно будет размещаться после заголовков

расширения: “Hop-by-hop”, “Routing” и “Fragmentation”. Заголовок(и)

расширения “Destination options” могут размещаться до или после ESP-

заголовка в зависимости от выбранной семантики. Однако, так как ESP-

протокол защищает только те поля, которые следуют после ESP-заголовка, то

рекомендуется размещать заголовок(и) расширения “Destination options” после

ESP-заголовка. На рис.3 приведен состав ESP-сообщения

при использовании

РТР для IPv6-адресации (до и после IPsec-обработки).

До

-обработки

Оригинальный

IP-заголовок

Заголовки

расширения

(если они

представлены)

TCP-заголовок

После

-обработки

ESР-поле

“Данные

тенти

икации”

Оригинальный

IP-заголовок

Заголовки

расширения

“Hop-by-hop”,

“Routing”,

“Fragmentation”

и “Destination

options”

ESP-заголовок

Заголовок(и)

расширения

“Destination

options”

TCP-заголовок

Данные

ESР-концевик

Шифруется

Аутентифицируется

Данные

При

использовании

IPv6-адресации

“*” — если представлен(ы), может(гут) размещаться до или после ESP-заголовка, либо там

и там одновременно.

Рис.3.

ESP-протокол в РТУ может использоваться и IP-узлами, и шлюзами

безопасности. Когда ESP-протокол используется шлюзом безопасности (для

защиты удаленного транзитного трафика), то он должен функционировать

только в РТУ. В этом режиме, “внутренний” IP-заголовок содержит IP-адреса

конечных отправителя/получателя, в то время как “внешний” IP-заголовок

может содержать совершенно другие IP-адреса, например, IP-адреса

шлюзов

безопасности. В РТУ ESP-протокол защищает весь “внутренний” IP-пакет,

включая весь “внутренний” IP-заголовок. На рис.4 приведен состав ESP-

сообщения в РТУ для IPv4/IPv6-адресации (после IPsec-обработки).

ESР-поле

“Данные

тенти

икации”

IPv4-адресация

Новый

(“внешний”)

IP-заголовок

(любое число

полей

“Дополнительная

услуга”

)

ESP-заголовок

Оригинальный

(“внутренний”)

IP-заголовок

(любое число

полей

“Дополнительная

услуга”

)

TCP-заголовок

Данные

Аутентифицируется

Шифруется

ESP-концевик

ESР-поле

“Данные

тенти

икации”

Новый

(“внешний”)

IP-заголовок

IPv

-адресация

Новые

(“внешние”)

заголовки

асши

ения

ESP-заголовок

Оригинальный

(“внутренний”)

IP-заголовок

Оригинальные

(“внутренние”)

заголовки

асши

ения

Аутентифицируется

Шифруется

ESP-концевик

TCP-заголовок

Данные

Рис.4.

3.2. Алгоритмы

Обязательные к применению алгоритмы будут рассмотрены ниже.

Помимо обязательных могут использоваться и другие. (

Замечание. Несмотря на

то, что услуги по обеспечению конфиденциальности и аутентификации являются

необязательными, по крайней мере одна из них должна применяться обязательно,

то есть оба алгоритма не должны быть одновременно установлены в режим

“NULL”.

)

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

Применение того или иного алгоритма шифрования определяется

защищенным виртуальным соединением. ESP-протокол разработан для

использования симметричных криптоалгоритмов. Так как IPsec-пакеты могут

поступать с нарушением порядка следования, то тогда каждый пакет должен

содержать какую-либо дополнительную информацию (данные), позволяющую

приемному IPsec-модулю восстанавливать синхронизацию

(ресинхронизироваться) для последующей процедуры расшифрования. Эти

данные могут передаваться в поле полезной нагрузки в явном виде (например,

ВНУ) или могут извлекаться из заголовка IPsec-пакета. Так как ESP-протокол

позволяет дополнять открытый текст ДБП, то тогда криптоалгоритмы,

используемые этим протоколом, могут размещать на этом месте

характеристики режима функционирования (блочный или поточный шифр).

(

Замечание. Услуга по обеспечению конфиденциальности (шифрованию)

является необязательной, то есть криптоалгоритм может быть установлен в

режим “NULL”.)

3.2.2. Алгоритмы аутентификации

Алгоритм аутентификации, используемый для вычисления ICV (“Integrity

Check Value”), определяется конкретным защищенным виртуальным

соединением. В интересах межтерминального соединения используется целый

набор алгоритмов аутентификации, который включает “Message Authentication

Codes” (MACs), основанные на обмене ключевой информации и применении

симметричных криптоалгоритмов (например, DES), или — на вычислении

однонаправленных функций (например, MD5 или SHA-1). Для многоадресной

рассылки сообщений используются агоритмы вычисления однонаправленных

хэш-функций в

комбинации с алгоритмами вычисления электронной цифровой

подписи (ЭЦП) на основе асимметричных криптоалгоритмов, несмотря на то,

что существующие стандарты препятствуют использованию таких алгоритмов.

(

Замечание. Услуга по обеспечению аутентификации является необязательной,

то есть алгоритм аутентификации может быть установлен в режим “NULL”.)

3.3. Обработка выходных IPsec-пакетов

В РТР, передающий IPsec-модуль осуществляет процедуру повторного

обрамления сообщения протокола верхнего уровня, используя для этого ESP-

заголовок и ESP-концевик, не затрагивая оригинальный IP-заголовок (и любые

IP-заголовки расширения при использовании IPv6-адресации). В РТУ, внешние

и внутренние IP-заголовки и IP-заголовки расширения могут быть

взаимосвязаны между собой по различным причинам. Если в соответствии со

стратегией обеспечения безопасности требуется более чем один IPsec-заголовок

и IPsec-заголовок расширения, то тогда порядок использования таких

заголовков безопасности должен определяться данной стратегией.

3.3.1. Определение защищенного виртаульного соединения

ESP-протокол используется для обработки выходного IP-пакета только

тогда, когда передающий IPsec-модуль определит, что данный IP-пакет связан с

конкретным SA, которое “запросило” ESP-обработку.