Таблица N 2

Примечание:

поле "C" (1 бит) должно быть равно "0" для обеспечения заявленной отправителем возможности по пропуску получателем элемента данных, когда получатель не идентифицирует код в поле "Next Payload" предыдущего элемента. Получатель должен игнорировать этот флаг при идентификации типа элемента. Флаг "C" должен относиться к текущему элементу данных;

поле "Резерв" (7 битов) должно быть равно "0" при передаче и игнорироваться на приеме;

поле "Размер текущего элемента" (Payload Length) (2 октета) должно содержать размер текущего элемента данных в октетах с учетом базового заголовка;

2.4. структура элемента данных "Предложения" (SA) приведена на рисунке 3.

Рисунок 3

Данные контекста безопасности (Security Association Payload, далее - SA) должны использоваться для согласования атрибутов защищенной связи. Элемент SA может включать несколько предложений, упорядоченных в порядке снижения приоритета. Каждое предложение может включать несколько протоколов IPsec (IKEv2, ESP, AH), каждый протокол может включать множество преобразований, а каждое преобразование может включать несколько атрибутов.

Примечание:

первый октет должен содержать информацию о том, является ли предложение последним в субструктуре предложений элемента SA (предложение должно быть последним при значении первого октета равном "0" и не должно являться последним при значении равном "2");

поле "Длина предложения" (2 октета) должно указывать размер предложения, включая все входящие в него преобразования и атрибуты;

поле "Номер предложения" (1 октет) должно указывать номер предложения. Первое предложение в элементе SA должно иметь номер "1", а номера последующих предложений должны совпадать с номером предшественника (И - пересечение двух предложений) или быть на 1 больше (ИЛИ - объединение двух предложений). Все номера предложений в элементе SA должны совпадать при приеме и соответствовать номеру переданного предложения, которое было принято;

поле "Идентификатор протокола" (1 октет) должно задавать идентификатор протокола IPsec для текущего согласования;

поле "Значение SPI" (1 октет) должно использоваться для начального согласования IKE_SA и должно быть равно "0". Значение SPI следует получать из внешнего заголовка и при последующих согласованиях поле "Значение SPI" должно показывать размер SPI (в октетах) для соответствующего протокола (8 для IKEv2, 4 для ESP и AH);

поле "Число преобразований" (1 октет) должно содержать информацию о числе преобразований в предложении;

поле "SPI передающей стороны" должно быть переменного размера;

поле "Структура преобразования" должно быть переменного размера.

Формат поля "Структура преобразования" приведен на рисунке 4.

Рисунок 4

Примечание:

первый октет должен должен содержать информацию о том, является ли преобразование последним в предложении. Преобразование должно быть последним при значении первого октета равном "0" и не должно являться последним при значении равном "3";

поле "Резерв" (1 октет) должно быть равно "0" при передаче и игнорироваться на приеме;

поле "Длина преобразования" (2 октета) должно содержать информацию о размере поля "Структура преобразования" (в октетах) с учетом заголовка и атрибутов;

поле "Тип преобразования" (1 октет) должно содержать тип преобразования, задаваемого этим элементом. Преобразование не должно включаться в предложение, если оно является необязательным и инициатор предлагает его пропустить. Инициатор должен включать субструктуру преобразования с идентификатором Transform ID равном "0" в качестве одной из опций при передаче вопроса об использовании необязательного преобразования ответчику.

Типы преобразований приведены в таблице N 3.