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

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

3.3.2. Шифрование IP-пакета

Передающий IPsec-модуль выполняет следующие функции:

c повторное обрамление исходного IP-пакета:

n для РТР — только оригинальное сообщение протокола верхнего

уровня;

o для РТУ — весь оригинальный IP-пакет;

d добавление необходимой ДБП;

e шифрование результирующей последовательности (поля полезной

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

заголовок”), используя ключевую информацию, криптоалгоритм, режим

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

данные для синхронизации криптопроцессов (если они имеют место):

n если данные для синхронизации криптопроцессов должны быть

представлены в явном виде (например, ВНУ). Тогда они поступают на

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

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

o если данные для синхронизации криптопроцессов должны быть

представлены в неявном виде (например, ВНУ). Тогда они

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

криптоалгоритм, и поступают на вход криптопроцесса.

Конкретные итерации по формированию внешнего IP-заголовка зависят

от используемого режима функционирования SA (РТР или РТУ).

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

процедура шифрования (перед процедурой аутентификации), но шифрование

не охватывает поле “Данные аутентификации”. Такой порядок обработки

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

продублированные или фиктивные (поддельные) IPsec-пакеты перед их

возможным расшифрованием, и, следовательно, повышать уровнь

защищенности от атак типа “отказ в обслуживании”. Это также позволяет

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

например, процедура расшифрования может осуществляться одновременно с

процедурой аутентификации. (

Замечание. Так как поле “Данные

аутентификации” не защищается шифрованием, то для вычисления ICV должен

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

3.3.3. Генерирование последовательного номера

В период формирования SA счетчик передающего IPsec-модуля

устанавливается в “0”. Отправитель (передающий IPsec-модуль) каждый раз

увеличивает значение последовательного номера и размещает новое значение в

поле “Последовательный номер” (“Sequence Number”). Таким образом, первый

IPsec-пакет, транспортируемый по конкретному SA, будет иметь

последовательный номер, равный “1”.

Если процедура защиты от повторной передачи IPsec-пакетов

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

свой счетчик, чтобы убедится в отсутствии его “зацикливания”, и только после

этой проверки (в случае положительного результата — “зацикливания” нет)

размещает новое значение параметра в поле “Последовательный

номер”.

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

IPsec-пакетов по SA, если обнаружится “зацикливание” счетчика, то есть

параметра в поле “Последовательный номер”. Попытка передать IPsec-пакет,

имеющий последовательный номер, значение которого “вышло” за пределы

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

контролю и регистрации. (

Замечание. Такой способ управления

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

Отправитель (передающий IPsec-модуль), предлагающий услугу по

защите от повторной передачи IPsec-пакетов, может использовать ее как “по

умолчанию” (для этого необходимы специальные предварительные настройки),

за исключением случая, когда эта процедура назначается получателем

(приемным IPsec-модулем). Таким образом, если счетчик “переполнен”, то

тогда отправитель должен переустанавливать SA и обновлять ключевую

информацию (за исключением SA, которые

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

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

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

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

переустанавливать счетчик (например, в режиме ручного управления

процедурой обмена ключевой информацией). Однако, отправитель все равно

“запускает” свой счетчик, и когда последний достигнет своего

максимального

значения он опять устанавливает его в “0”.

3.3.4. Вычисление проверочной суммы (ICV)

Если для SA выбрана процедура аутентификации, то тогда передающий

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

ESP-пакет за вычетом поля “Данные аутентификации”. Таким образом, поля

“Индекс параметров безопасности (SPI)”, “Последовательный номер”,

“Полезная нагрузка”, “Дополнение” (если оно имеет место), “Размер поля

“Дополнение” и “Следующий заголовок” принимают “участие” в вычислении

ICV. (

Замечание. По крайней мере четыре поля (из перечисленных выше) будут

зашифрованы, так как процедура шифрования осуществляется перед процедурой

вычисления ICV.)

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

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

кратной определенному размеру блока (представлен в стандарте на алгоритм

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

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

блока, то тогда ESP-пакет должен быть дополнен до необходимого размера

(

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

вычисления ICV. Байты (октеты) дополнения должны быть “нулевыми”. Размер

блока (и, следовательно. длина дополнения) определяется стандартом на

алгоритм аутентфикации. Однако, поле дополнения нулями не транслируется,

IPsec-пакет доставляется без него.

3.3.5. Фрагментация

Если это необходимо, то IPsec-модуль осуществляет процедуру

фрагментации после ESP-обработки. Таким образом, ESP-протокол в РТР

применяется только для целых IP-пакетов (а для их фрагментов). IP-пакет,

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

процедуре фрагментации в маршрутизаторах. Следовательно, такой IP-пакет

должен быть восстановлен на приемной стороне перед ESP-обработкой. В

РТУ

ESP-протокол применяется для IP-пакета, полезная нагрузка которого может

быть разбита на новые IPsec-пакеты. Например, шлюз безопасности, LAN-

сервер или линейный шифратор (криптопроцессор) могут применить ESP-

протокол в РТУ для таких IPsec-пакетов.

(

Замечание. В РТР, программное обеспечение LAN-сервера и линейного

шифратора (криптопроцессора) должно вначале осуществить сборку IPsec-пакета,

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

и только потом фрагментировать обработанный IP-пакет.)

(

Замечание. При использовании IPv6-адресации, программное

обеспечение LAN-сервера и линейного шифратора (криптопроцессора) должно

(если это необходимо) проанализировать все заголовки расширения на предмет

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

вначале провести сборку IPsec-пакета и только потом — IPsec-обработку.)

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

3.4.1. Сборка IPsec-пакетов

Если необходима сборка IPsec-пакетов, то она осуществляется перед ESP-

обработкой. Если фрагмент IPsec-пакета направляется на ESP-обработку (то

есть заголовок IPsec-пакета включает поле “Offset”, содержащее ненулевое

значение, или флаг “More fragments”, установленный в “1”), то тогда приемный

IPsec-модуль должен уничтожать этот IPsec-пакет (данное событие является

объектом аудиторского контроля). В запись аудиорской проверки для данного

события целесообразно включить: значение SPI, время и дату события, IP-

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

(

Замечание. При использовании IPv4-адресации нет требований к

заполнению нулями поля “Offset” или обнулению флага “More fragments”. Но

для того, чтобы восстановленный IPsec-пакет был обработан IPsec-процессом

(то есть не был уничтожен как явный фрагмент большого IPsec-пакета),

программный IP-модуль должен выполнять эти две функции после сборки IPsec-

пакета.)

3.4.2. Поиск SA

После получения IPsec-пакета, содержащего сообщение ESP-протокола

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

(однонаправленное) защищенное виртуальное соединение на основе IP-адреса

получателя, протокола безопасности (ESP) и индекса SPI. Запись об SA

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

наличие поля “Данные аутентификации”, и после этого определяются

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

вычисления ICV (если последняя использовалась).

Если обнаруживается необоснованность применения SA для данного

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

стороне), то тогда приёмный IPsec-модуль должен уничтожать пакет. Такое

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

будет содержать (целесообразно) значение SPI, время и дату события, IP-адреса

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

и “открытый”

идентификатор потока (для IPv6-адресации).

3.4.3. Проверка последовательного номера

Все программные ESP-модули (различные программные реализации ESP-

протокола) должны обеспечивать услугу по предотвращению повторной

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

может или не может поддерживать эту функцию для каждого SA (в случае

использования нескольких SА одновременно). Данная услуга не должна

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

применяется

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

“Последовательный номер” не будет защищена от какой-либо модификации

(подделки). (

Замечание. В принципе, не существует механизма по управлению

передаваемыми значениями последовательных номеров (их синхронизации) для

нескольких отправителей, которые направляют свои трафики по одному SA (вне

зависимости от применяемых IP-адресов: для персонального получателя, для

группы получателей или широковещательные). Таким образом, не

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

пакетов) для одиночного SA, по которому транслируются трафики (групповой

трафик) от нескольких отправителей.)

Если приемный IPsec-модуль не обладает функцией предотвращения

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

последовательных номеров во входных IPsec-пакетах. Однако, с точки зрения

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

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

передачи IPsec-пакетов. Во избежании такой ситуации, когда отправителю нет

необходимости контролировать

последовательный номер, а SA установлен,

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

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

предполагает, что в период формирования SA приемный IPsec-модуль будет

оповещать передающий IPsec-модуль о невозможности применения функции

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

Если приемный IPsec-модуль обладает функцией предотвращения

повторной передачи IPsec-пакетов, то тогда в период формирования SA его

счетчик

пакетов должен быть обнулен. При приеме каждого IPsec-пакета

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

содержащийся в пакете, на предмет его совпадения с другими номерами в ранее

принятых пакетах в течении периода существования (“жизни”) защищенного

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

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

проверки ICV) с целью скорейшего уничтожения продублированных пакетов.

Дубликаты IPsec-пакетов уничтожаются благодаря использованию

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

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

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

IPsec-протоколов любая программная реализация IPsec-модуля должна

удовлетворять ниже следующим требованиям.) Минимальный размер окна,

который должен обеспечивать IPsec-

модуль, составляет 32. Однако,

целесообразно, чтобы в режиме “по умолчанию” размер окна составлял 64.

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

приемной стороной. (При этом приемный IPsec-модуль не информирует

передающий о размере окна).

“Правая” граница окна представляет собой максимальное значение

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

Пакеты, содержание

последовательные номера, которые меньше “левой”

границы окна, уничтожаются. Пакеты с последовательными номерами, которые

“находятся” в рамках скользящего окна, проверяются с ранее принятыми в

рамках этого окна пакетами.

Если принятый в рамках “действующего” окна пакет является новым (или

если этот пакет имеет последовательный номер, который больше правой

границы окна), то тогда приемный IPsec-модуль осуществляет проверку ICV.

Если проверка ICV дала отрицательный результат, то тогда приемный IPsec-

модуль

должен уничтожить IPsec-пакет, как недопустимый (это событие

подлежит аудиторскому контролю). В запись аудиорской проверки для данного

события целесообразно включить: значение SPI, время и дату события, IP-

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

удаленном IPsec-пакете) и идентификатор потока (для IPv6-адресации).

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

ICV.

(

Замечание. Если IPsec-пакет содержит последовательный номер в

пределах “скользящего” окна и является новым, или содержит номер,

превышающий правую границу этого окна, то тогда приемный IPsec-модуль

должен в начале аутентифицировать пакет и только потом изменять данные

приемного окна.

)

3.4.4. Проверка ICV

Если при установлении SA была выбрана процедура аутентификации, то

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

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

поля “Данные аутентификации”, используя при этом специальный алгоритм

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

расположенным в поле “Данные аутентификации” (“Authentication Data”).

Если вычисленное значение ICV совпало с принятым, то

тогда IPsec-

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

обработки. Если проверка ICV дала отрицательный результат, то тогда

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

недействительный (это событие подлежит аудиторскому контролю). В запись

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

SPI, время и дату приема, IP-адреса отправителя и получателя и идентификатор

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

3.4.5. Расшифрование ESP-пакета

Приемный IPsec-модуль выполняет следующие функции:

c расшифровывает ESP-пакет (поля полезной нагрузки, “Дополнение”,

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

этого ключевую информацию, криптоалгоритм, режим

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

криптопроцессов (если они имеют место), которые определяются SA:

n если данные для синхронизации криптопроцессов представлены в

явном виде (например, ВНУ). Тогда они извлекаются из поля полезной

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

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

o если данные для синхронизации криптопроцессов представлены в

неявном виде (например,). Тогда конструируется частная версия ВНУ

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

которая поступает на вход криптопроцесса;

d обрабатывает какое-либо дополнение по правилам, указанным в

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

дополнения “по умолчанию”, то тогда целесообразно, чтобы приемный

IPsec-модуль “просмотрел” поле “Дополнение” перед его удалением,

прежде чем расшифрованные данные будут переданы на обработку

протоколом верхнего уровня;

e реконструирует исходный IP-пакет из:

n (в РТР) оригинальный IP-заголовок плюс оригинальные данные

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

ESP-пакета;

o (в РТУ) весь IP-пакет, содержащиеся в поле полезной нагрузки ESP-

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

IP-пакет).

Конкретные итерации по реконструкции оригинального IP-пакета зависят

от режима функционирования ESP-протокола (РТР или РТУ). Как минимум, с

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

расшифрование данных, размер которых кратен 8-байтовому блоку. Это

необходимо для

“облегчения” процесса последующей обработки в

соответствии с протоколом, который указан в поле “Следующий заголовок”.

Если при установлении SA была выбрана процедура аутентификации, то

тогда проверка ICV и процедура расшифрования могут проводиться

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

целесообразно начинать с проверки ICV. При параллельной обработке проверка

ICV должна завершаться до окончания процедуры расшифрования и

передачи

IP-пакета для последующей обработки. Такой порядок обработки позволяет

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

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

расшифрованием, и, следовательно, повышать уровнь защищенности от атак

типа “отказ в обслуживании”. (

Замечание. Если приемный IPsec-модуль

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

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

синхронизации и по обеспечению их взаимонезависимости друг от друга,

особенно при организации доступа к IPsec-пакету и реконструкции

расшифрованного IP-пакета.)

(Замечание

. Существует несколько ситуаций, при которых процедура

расшифрования может “провалиться”:

c выбранный SA может быть некорректным. SA может быть выбран

некорректно вследстивие подделки (искажения) полей “SPI”, “IP-адрес

получателя” или “Тип IPsec-протокола”. Такие ошибки, если они

“отображают” IPsec-пакет на другое функционирующее SA, не позволят

выявить “искаженный” IPsec-пакет. Подделка SPI может выявлена только

за счет применения процедуры аутентификации. Однако, ошибка при

определении SA все-таки может быть следствием подделки (

искажения)

полей “IP-адрес получателя” или “Тип IPsec-протокола”;

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

ошибочными. Такие ошибки могут быть выявлены независимо от

применения процедуры аутентификации;

e расшифрованный ESP-пакет может быть искаженным. Это может быть

обнаружено при условии, если для данного SA выбрана процедура

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

В первом и третьем случаях, ошибочные результаты процедуры

расшифрования (некорректный IP-пакет или информационный (ТСР/UDP) блок

транспортного уровня) не должны обязательно обнаруживаться IPsec-

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

протоколом.

IV. АУДИТОРСКИЙ КОНТРОЛЬ

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

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

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

должен поддерживать функцию аудиторской проверки. Кроме этого, ESP-

модуль должен предоставлять администратору возможность настройки ESP-

протокола для аудиторской проверки. В большинстве случаев структура

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

значение. Однако, несколько ситуаций,

определенные в этом стандарте, должны подлежать аудиторскому контролю и

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

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

аудиторской проверке. Любая дополнительная информация также может быть

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

событий. Более того, в перечень

обязательных контролируемых событий могут

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

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

результатам аудиторской проверки. К приемному IPsec-модулю не

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

сообщения для информирования передающей стороны об обнаружении

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

привести к

отказу в обслуживании.