Перевод RFC 4302 — Идентификационный заголовок IP

: RFC: 4302; Оригинал: IP Authentication Header; Предыдущие версии: RFC 1826, RFC 2402; Категория: Предложенный стандарт; Дата публикации: Декабрь 2005; Автор: Stephen Kent; Перевод: Николай Малых

Статус документа

Это документ содержит проект стандарта протокола Internet для сообщества Internet и служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации и статус протокола можно узнать из текущей версии документа «Internet Official Protocol Standards» (STD 1). Допускается свободное распространение документа.

Авторские права

Тезисы

В этом документе описана обновленная версия идентификационного заголовка IP (AH — Authentication Header), который разработан для обеспечения услуг проверки тождественности (идентификации) в IPv4 и IPv6. Этот документ отменяет действие RFC 2402 (ноябрь 1998).

1. Введение
2. Формат заголовка идентификации
2.1. Next Header — следующий заголовок
2.2. Payload Length — размер данных
2.3. Reserved — резерв
2.4. Security Parameters Index (SPI) — список параметров защиты
2.5. Sequence Number — порядковый номер
2.6. Integrity Check Value (ICV) — контроль целостности
3. Обработка идентификационного заголовка AH
3.1. Местоположение AH
3.2. Контроль целостности
3.3. Обработка исходящих пакетов
3.4. Обработка входящих пакетов
4. Аудит
5. Соответствие требованиям
6. Вопросы безопасности
7. Отличия от RFC 2402
8. Благодарности
9. Литература
9.1. Нормативные документы
9.2. Дополнительная литература
Приложение A: Изменяемые опции и расширения заголовков IP
A1. Опции IPv4
A2. Заголовки расширения IPv6
Приложение B: Расширенные порядковые номера (64 бита)
B1. Обзор
B2. Окно Anti-Replay
B3. Обработка потери синхронизации в результате больших потерь пакетов

1. Введение

В документе предполагается, что читатель достаточно знаком с терминами и концепциями, изложенными в документе «Архитектура защиты для протокола IP» [Ken-Arch], далее называемом для карткости описанием архитектуры. В частности, читателю следует понимать определения услуг по защите, обеспечиваемых ESP (Encapsulating Security Payload — инкапсуляция защищенных данных) [Ken-ESP] и AH, концепцию защищенных связей, способы использования ESP вместе с идентификационным заголовком AH, а также различные опции управления ключами, поддерживаемые для ESP и AH.

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119 [Bra97].

Идентификационный заголовок IP (AH) используется для обеспечения целостности и идентификации источника данных для дейтаграмм IP (далее для краткости будет использоваться термин «целостность») без организации специальных соединений и защиты против повторного использования пакетов. Второй, необязательный, сервис может выбираться получателем при создании защищенной связи (SA — Security Association). Протокол по умолчанию требует от отправителя увеличивать порядковые номера для предотвращения повторного использования пакетов, но этот механизм работает только при проверке порядковых номеров на приемной стороне. Для использования расширенных возможностей порядковой нумерации AH вносит требование к протоколу управления SA по обеспечению возможности согласования этой новой функции (см. параграф 2.5.1).

AH обеспечивает идентификацию для всех возможных частей заголовка, а также для данных протокола следующего уровня. Однако некоторые поля заголовка IP могут изменяться на пути передачи и значения этих полей при получении пакета могут быть непредсказуемыми для отправителя. Такие поля нельзя защитить с помощью AH. Таким образом, защита заголовка IP с помощью AH является неполной (см. Приложение A.).

AH может использоваться в комбинации с ESP [Ken-ESP] или путем вложения [Ken-Arch]. Услуги по защите могут обеспечиваться между парой взаимодействующих хостов, парой защитных шлюзов, а также между защитным шлюзом и хостом. ESP может использоваться для обеспечения такой же защиты от повторного использования пакетов и аналогичной защиты целостности, а также обеспечивает дополнительную защиту конфиденциальности (шифрование). Основным различием между защитой целостности, обеспечиваемой ESP и AH является расширение покрытия. В частности, ESP не защищает никаикх полей заголовка IP, пока эти поля не инкапсулируются ESP (например, за счет использования туннеля). Более детальное описание использования AH и ESP в разных сетевых средах приводится в документе, посвященном архитектуре защиты [Ken-Arch].

В разделе 7 кратко рассмотрены отличия этого документа от RFC 2402 [RFC2402].

2. Формат заголовка идентификации

В протокольный заголовок (IPv4, IPv6 или расширение IPv6), непосредственно предшествующий заголовку AH, следует помещать значение 51 в поле Protocol (IPv4) или Next Header (IPv6, включая расширение) [DH98]. Рисунок 1 показывает формат заголовка AH.

  0                   1                   2                   3
  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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header   |  Payload Len  |          RESERVED             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Security Parameters Index (SPI)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Sequence Number Field                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                Integrity Check Value-ICV (variable)           |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Рисунок 1: Формат заголовка AH

В приведенной ниже таблице приведены поля заголовка AH, показанные на рисунке, и другие поля, используемые при проверке целостности, а также указано, какие поля покрываются ICV и что передается.

	Число битов	Когда требуется [1]	Покрывается	Передается
IP Header	переменное	M	[2]	да
Next Header	1	M	да	да
Payload Len	1	M	да	да
RESERVED	2	M	да	да
SPI	4	M	да	да
Seq# (младшие 32 бита)	4	M	да	да
ICV	переменное	M	да [3]	да
IP datagram [4]	переменное	M	да	да
Seq# (старшие 32 бита)	4	При поддержке ESN	да	нет
ICV Padding	переменное	Если нужно		нет

[ 1 ] M = mandatory — обязательно.
[ 2 ] Информация о покрываемых полях заголовка IP приведена в параграфе 3.3.3.
[ 3 ] Обнуляется перед расчетом ICV и результат расчета помещается в это поле.
[ 4 ] В туннельном режиме — дейтаграмма IP, в транспортном — следующий заголовок и данные.

Описание полей заголовка AH приводится в последующих параграфах. Все описанные здесь поля являются обязательными, т. е., всегда должны присутствовать в заголовке AH и учитываются при расчете значения для контроля целостности (ICV — Integrity Check Value) (см. параграфы 2.6 и 3.3.3).

Предполагается, что все криптографические алгоритмы IPsec используют на входе канонический сетевой порядок байтов (см. Приложение к RFC 791 [RFC791]) и на выходе дают результат также в каноническом сетевом порядке байтов.

При передаче пакетов IP также используется сетевой порядок байтов.

AH не содержит номера версии, следовательно для обеспечения совместимости со старыми версиями информация о версии идентификационного заголовка должна передаваться с помощью механизмов сигнализации между партнерами IPsec (например, IKE [IKEv2] или настройка по отдельному каналу).

2.1. Next Header — следующий заголовок

Восьмибитовое поле Next Header показывает тип информации, расположенной после идентификационного заголовка AH. Значения этого поля выбираются из списка номеров протоколов IP, представленного на сайте IANA. Например, значение 4 показывает протокол IPv4, значение 41 — IPv6, а 6 — протокол TCP.

2.2. Payload Length — размер данных

Это 8-битовое поле указывает размер заголовка AH в 32-битовых словах (4-байтовых блоках) минус 2. Например, если алгоритм проверки целостности использует 96-битовое идентификационное значение, поле длины будет иметь значение 4 (3 слова полей фиксированной длины и 3 слова для ICV минус 2). Для IPv6 общий размер заголовка должен быть кратным 8 октетам (отметим, что хотя IPv6 [DH98] характеризует AH как внешний заголовок, его размер измеряется в 32-битовых словах, а не 64-битовых, как в заголовках расширения IPv6). Комментарии по учету байтов заполнения приведены в параграфах 2.6 и 3.3.3.2.1.

2.3. Reserved — резерв

Это 16-битовое поле зарезервировано для использования в будущем. Отправитель должен устанавливать для этого поля нулевое значение, а получателю следует игнорировать значение этого поля. Отметим, что значение этого поля (0) учитывается при вычислении ICV, но игнорируется получателем.

2.4. Security Parameters Index (SPI) — список параметров защиты

SPI представляет собой произвольное 32-битовое значение, используемое получателем для идентификации SA, с которой связан входящий пакет. Для индивидуальных SA, значение SPI может само по себе идентифицировать SA или использоваться в комбинации с типом протокола IPsec (в данном случае AH). Поскольку для индивидуальных SA значение SPI генерируется получателем, решение вопроса о достаточности этого значения для идентификации SA или необходимости использования в комбинации с типом протокола IPsec определяется локальными условиями. Поле SPI является обязательным и упомянутый выше механизм отображения входящего трафика на индивидуальные SA должен поддерживаться всеми реализациями AH.

В реализациях IPsec, поддерживающих групповую адресацию, должны поддерживаться групповые SA с использованием описанного ниже алгоритма отображения входящих дейтаграмм IPsec на SA. Разработчикам, поддерживающим только индивидуальный трафик, не обязательно реализовать механизм демультиплексирования.

Во многих защищенных multicast-архитектурах (например, [RFC3740]) центральный контроллер группы/сервер ключей сам выделяет для группы значение SPI. Выделение SPI не согласуется и не координируется с подсистемами управления ключами (например, IKE) на конечных узлах группы. Следовательно, возникает возможность совпадения значений SPI для групповой и индивидуальной SASA. Поддерживающие групповую адресацию реализации IPsec должны корректно демультиплексировать входящий трафик даже в случаях совпадения значений SPI.

Каждая запись в базе данных защищенных связей (SAD — Security Association Database) [Ken-Arch] должна указывать, по каким критериям в дополнение к SPI SPI SPI SPI отыскивается SA — получатель, получатель и отправитель. Для групповых SA поле протокола не используется при поиске SA. Для каждого входящего пакета с защитой IPsec реализация должна произвести поиск в SAD и найти запись, наиболее точно соответствующую идентификатору SA. Если обнаруживается более одной записи SAD, соответствующей значению SPI, выбирается запись по наиболее точному соответствию получателя или получателя и отправителя (как указано в записи SAD). Таким образом, логический порядок поиска в SAD имеет вид:

Поиск в базе SAD соответствия {SPI, адрес получателя, адрес отправителя}. Если запись SAD найдена, входящий пакет AH обрабатывается с найденной записью SAD. В противном случае выполняется п. 2.
Поиск в базе SAD соответствия {SPI, адрес получателя}. Если запись SAD найдена, входящий пакет AH обрабатывается с найденной записью SAD. В противном случае выполняется п. 3.
Поиск в базе SAD соответствия {SPI}, если получатель выбрал поддержку одного пространства SPI для AH и ESP, или {SPI, протокол} в противном случае. Если запись SAD найдена, входящий пакет AH обрабатывается с найденной записью SAD. В противном случае пакет отбрасывается с записью в журнал аудита.

На практике реализация может выбрать любой метод ускорения поиска, но наблюдаемое извне поведение должно соответствовать описанному выше поиску в SAD. Например, программные реализации могут индексировать хэш-таблицу SPI. Записи SAD в хэш-таблице сортируются в связный список, в котором записи для SA с большим соответствием располагаются ближе к началу, а с меньшим соответствием — ближе к концу списка. В аппаратных реализациях поиск максимального соответствия может ускоряться встроенными средствами с использованием общедоступной технологии TCAM (Ternary Content-Addressable Memory — ассоциативная память).

Индикация использования адресов отправителя и получателя при поиске соответствия для отображения входящего трафика IPsec на SA должна выполняться при настройке конфигурации SA вручную или путем согласования параметров с использованием протокола управления SA (например, IKE или GDOI [RFC3547]). Обычно группы SSM (Source-Specific Multicast) [HC03] используют трехкомпонентный идентификатор SA, включающий SPI, групповой адрес получателей и адрес отправителя. SA группы Any-Source Multicast требует в качестве идентификатора только SPI и групповой адрес получателей.

Значения SPI в диапазоне от 1 до 255 зерезервированы IANA для использования в будущем. Эти значения не будут распределяться агентством IANA, пока их использование не будет оговорено в специальном RFC. Значение SPI = 0 зарезервировано для локального, связанного с реализацией, применения и его недопустимо передавать в сеть. Например, реализация управления ключами может использовать SPI=0 для идентификации отсутствия защищенных связей в период, когда реализация IPsec запрашивает новую SA для объекта управления ключами, но данная SA еще не организована.

2.5. Sequence Number — порядковый номер

Это 32-битовое поле, трактуемое, как целое число без знака, содержит значение счетчика пакетов, которое увеличивается на 1 для каждого переданного пакета (счетчик пакетов для SA). Для индивидуальных SA и групповых SA с одним отправителем, последний должен инкрементировать данное поле для каждого переданного пакета. Использование одной SA множеством отправителей допустимо, хотя в общем случае не рекомендуется. AH не предоставляет возможностей синхронизации порядковых номеров между множеством отправителей или осмысленного счетчика пакетов на стороне получателя и не обеспечивает окна в контексте множества отправителей. Таким образом, для SA с множеством отправителей функции предотвращения повторного использования пакетов AH становятся недоступными (см. параграфы 3.3.2 и 3.4.3).

Это поле является обязательным и должно присутствовать даже в тех случаях, когда получатель не пользуется услугами по предотвращению повторного использования пакетов для конкретной SA. Обработка поля Sequence Number осуществляется по усмотрению получателя, но все реализации AH должны обеспечивать возможность обработки, описанной в параграфах 3.3.2. Генерация порядковых номеров и 3.4.3. Проверка порядковых номеров. Таким образом, отправитель должен передавать это поле, но получатель не обязан принимать его во внимание.

Счетчики на стороне отправителя и получателя инициализируются нулевым значением при создании SA (первый пакет, переданный с использованием данной SA будет иметь порядковый номер 1; генерация порядковых номеров более подробно описана в параграфе 3.3.2). Если предотвращение повторного использования пакетов включено (используется по умолчанию), передаваемые порядковые номера никогда не должны повторяться. Таким образом, счетчики пакетов на стороне отправителя и получателя должны сбрасываться (путем создания новой SA и нового ключа) до передачи пакета с порядковым номером 2^32 в каждой SA.

2.5.1. Extended Sequence Number — расширенный порядковый номер (64 бита)

В высокоскоростных реализациях IPsec следует предлагать новую опцию для расширения 32-битового поля порядкового номера. Использование поля ESN (Extended Sequence Number — расширенный порядковый номер) должно согласовываться протоколом управления SA. Отметим, что в IKEv2 это согласование происходит неявно — использование ESN включено по умолчанию, пока явно не выбраны 32-битовые порядковые номера. Поддержка ESN возможна как для индивидуальных, так и для групповых SA.

ESN позволяет использовать для SA 64-битовые порядковые номера (см. Приложение B: Расширенные порядковыеномера (64 бита) ). В заголовке AH каждого пакета передаются только младшие 32 бита расширенного порядкового номера, а старшие 32 бита учитываются, как часть порядкового номера, отправителем и получателем и включаются в расчет ICV, но не передаются.

2.6. Integrity Check Value (ICV) — контроль целостности

Это поле переменной длины содержит значение контрольной суммы ICV (Integrity Check Value — значение для проверки целостности) для данного пакета. Размер поля должен быть кратным 32 битам как для IPv4, так и для IPv6. Обработка ICV рассматривается в параграфах 3.3.3. Расчет ICV и 3.4.4. Проверка ICV. Это поле может включать явное заполнение для обеспечиния кратности размера заголовка AH в целом 32 (IPv4) или 64 (IPv6) битам. Заполнение должны поддерживать все реализации и размер заполнения должен быть минимально достаточным для выравнивания заголовков в соответствии с требованиями IPv4/IPv6. Подробное описание расчета размера области заполнения приведено в параграфе 3.3.3.2. Заполнение и расширенныепорядковые номера. Спецификация алгоритма контроля целостности должна включать размер ICV, а также правила сравнения и этапы обработки при проверке целостности.

3. Обработка идентификационного заголовка AH

3.1. Местоположение AH

AH может работать в двух режимах — транспортном и туннельном. Более подробное описание этих режимов и рекомендации по выбору приводится в документе, посвященном архитектуре защиты.

3.1.1. Транспортный режим

В транспортном режиме AH помещается между заголовком IP и заголовком протокола следующего уровня (например, TCP, UDP, ICMP и т.п.) или перед другими заголовками IPsec, если они имеются. В контексте IPv4 это говорит о размещении AH после заголовка IP (и всех опций этого заголовка), но перед заголовком протокола следующего уровня.

На рисунке показан заголовок типичного пакета IPv4 до защиты и положение заголовка AH при работе в транспортном режиме:

            До применения AH
      ----------------------------
IPv4  |Исх. заг. IP |     |      |
      |   (опции)   | TCP | Data |
      ----------------------------
            После применения AH
      -------------------------------------------------------
IPv4  |Исходный заголовок IP (опции) | AH | TCP |    Data   |
      -------------------------------------------------------
      |<- Обраб. переменного поля -->|<-- неизменые поля -->|
      |<------ идентифицировано кроме перемен. полей ------>|

В контексте IPv6 заголовок AH представляется, как передаваемые «насквозь» данные и, следовательно, ему надлежит размещаться после заголовков расширения (hop-by-hop, routing, fragmentation). Опции получателя в расширенном заголовке могут располагаться перед заголовком AH, после него или по обе стороны, в зависимости от желаемой семантики. На приведенном ниже рисунке показано размещение AH для транспортного режима в типичном пакете IPv6.

                 До применения AH
      ---------------------------------------
IPv6  |             | расш. заг|     |      |
      | Исх. заг. IP|если есть | TCP |Данные|
      ---------------------------------------
                После применения AH
      ------------------------------------------------------------
IPv6  |             |hop-by-hop, dest*, |    | dest |     |      |
      | Исх. заг. IP|routing, fragment. | AH | opt* | TCP | Data |
      ------------------------------------------------------------
      |<--- Обраб. переменного поля --->|<--- неизменые поля --->|
      |<-------- идентифицировано кроме перемен. полей --------->|
* = при наличии может располагаться перед AH, после AH или в обоих местах

ESP и AH могут использоваться совместно в разных режимах. В документе, описывающем архитектуру IPsec, кратко рассматриваются методы настройки защищенных связей при использовании обоих протоколов.

Отметим, что в транспортном режиме для реализаций «bump-in-the-stack» и «bump-in-the-wire», как определено в архитектуре защиты, входящие и исходящие фрагменты IP могут потребовать от реализации IPsec выполнения дополнительных операций фрагментации/сборки дейтаграмм IP для выполнения требования данной спецификации и обеспечения прозрачной поддержки IPsec. Особое внимание следует обращать на выполнение таких операций при использовании множества интерфейсов.

3.1.2. Туннельный режим

В туннельном режиме «внутренний» заголовок IP содержит исходные адреса получателя и отправителя, а «внешний» заголовок IP — адреса «партнеров» IPsec (например, защитных шлюзов). Во внутреннем и внешнем заголовках могут использоваться разные версии IP (например, IPv6 через туннель IPv4 или IPv4 через туннель IPv6). В туннельном режиме заголовок AH защищает внутренний пакет целиком (включая его заголовок). Положение AH в туннельном режиме относительно внешнего заголовка IP совпадает с положением AH в транспортном режиме. На рисунке показано размещение AH в типичных пакетах IPv4 и IPv6 для туннельного режима.

     ----------------------------------------------------------------
IPv4 |                              |    | Исх. заг. IP* |   |      |
     | Новый заголовок IP* (опции)  | AH |    (опции)    |TCP| Data |
     ----------------------------------------------------------------
     |<-- обработка измен. полей -->|<------ неизменные поля ------>|
     |<-- идентифицировано кроме изменяемых полей в новом загол. -->|
     --------------------------------------------------------------
IPv6 |           | расширен.|    |            | расширен.|   |    |
     |Нов. загол*|заголовки*| AH |Исх. заг.IP*|заголовки*|TCP|Data|
     --------------------------------------------------------------
     |<-- Обраб. перем. поля -->|<-------- неизменые поля ------->|
     |<-- идентифицировано кроме изменяемых полей в новом загол.->|
* при использовании создается внешний заголовок IP и меняется
  внутренний, как описано в документе, посвященном архитектуре
  защиты. Расширенные заголовки могут отсутствовать.

3.2. Контроль целостности

Алгоритм контроля целостности, используемый для расчета ICV, задается SA. Для связи «точка-точка» к числу подходящих алгоритмов контроля целостности относится MAC (Message Authentication Code — код идентификации сообщения) с использованием симметричных алгоритмов шифрования (например, AES [AES]) или необратимые хэш-функции типа MD5, SHA-1, SHA-256 и т.п.). Для групповых приложений разработан большой набор криптографических стратегий и продолжаются исследования в этой области.

3.3. Обработка исходящих пакетов

В транспортном режиме отправитель помещает заголовок AH после заголовка IP и перед заголовком протокола следующего уровня, как описано выше. В туннельном режиме внешний и внутренний заголовок IP и расширения могут взаимодействовать различными способами. Создание внешнего заголовка IP в процессе инкапсуляции описан в документе, посвященном архитектуре защиты.

3.3.1. Нахождение SA

AH применяется к исходящим пакетам только после того, как реализация IPsec определит, что пакет связан с SA, которая вызывается для обработки AH. Процесс определения необходимости обработки IPsec для исходящего трафика описан в документе по архитектуре защиты.

3.3.2. Генерация порядковых номеров

Счетчик отправителя инициализуируется нулевым значением при организации SA. Отправитель инкрементирует счетчик порядковых номеров (или ESN) для данной SA и помещает младшие 32 бита номера в поле Sequence Number. Таким образом, первый пакет для данной SA получает порядковый номер 1.

Если включена функция предотвращения повторного использования пакетов (включена по умолчанию), отправитель проверяет, не повторяется ли порядковый номер перед вставкой значения в поле Sequence Number. Иными словами, для отправителя недопустимо передавать пакет в SA, если эта передача будет приводить к повторному использованию порядкового номера. Попытка передачи пакета, которая будет вызывать переполнение (переход на новый цикл отсчета) счетчика порядковых номеров приводит к внесению записи в журнал аудита. В эту запись следует включать значение SPI, текущую дату и время, адреса отправителя и получателя, а для IPv6 еще и нешифрованное представление Flow ID.

Отправитель предполагает, что предотвращение повторного использования включено по умолчанию, пока получатель однозначно не укажет обратное (см. параграф 3.4.3) или эта функция была отключена вручную при выборе конфигурации SA. Таким образом, в типичном случае реализация AH говорит отправителю о необходимости организации новой SA, когда значение Sequence Number (или ESN) достигает максимума и должно вернуться к нулю.

Если функция предотвращения повторов отключена (как описано выше) отправителю не нужно заботиться о мониторинге переполнения (сброса в 0) счетчика порядковых номеров (например, в случае управления ключами вручную, как описано в разделе 5). Однако отправитель будет по-прежнему инкрементировать значение счетчика и после максимального значения счетчик будет сброшен в 0. Такой вариант поведения рекомендуется для групповых SA со множеством отправителей, если между отправителями и получателями не согласовано использование механизма предотвращения повторов (выходящего за рамки данного стандарта).

Если выбрано использование ESN (см. Приложение B), в поле Sequence Number передаются только 32 младших бита расширенного порядкового номера, хотя отправитель и получатель поддерживают полные 64-битовые счетчики ESN. При этом старшие 32 бита порядкового номера учитываются в контрольной сумме ICV.

Если отправитель отказался от использования функции предотвращения повторов для SA, ему не следует согласовывать использование ESN в протоколе управления SA. Использование ESN вызывает у получателя необходимость поддержки окна anti-replay (для определения корректного значения старших битов ESN, которые используются при расчете ICV), что вступает в противоречие с отказом от предотвращения повторов для SA.

3.3.3. Расчет ICV

При расчете ICV в AH учитываются следующие поля:

Поля заголовка IP или расширения перед заголовком AH, которые не изменяются при передаче или предсказуемы на момент прибытия в конечную точку SA;
заголовок AH (поля Next Header, Payload Len, Reserved, SPI, Sequence Number — младшие 32 бита), поле ICV, значение которого на момент расчета принимается нулевым, и явные байты заполнения (если они есть);
все данные после заголовка AH предполагаются неизменными при передаче и учитываются в расчете;
старшие биты ESN (если расширенная нумерация используется) и все байты неявного заполнения, требуемые алгоритмом контроля целостности.

3.3.3.1. Обработка изменяемых полей

Если поле меняется в процессе передачи, при расчете ICV значение этого поля принимается нулевым. Если поле изменчиво, но его значение на уровне получателя IPsec предсказуемо, это значение может использоваться при расчете ICV. Значение поля Integrity Check Value при расчете также принимается нулевым. Отметим, что использвание нулевого значения поля вместо пропуска этого поля при расчете сохраняет выравнивание для расчета ICV. Кроме того, заполнение неучитываемых полей нулями предотвращает их изменение в процессе передачи, хотя содержимое этих полей и не покрывается явно ICV.

При создании нового расширения заголовка или опции IPv4 они определяются в соответствующем RFC и в сецификацию (раздел «Вопросы безопасности») следует включать инструкции по учету полей при расчете ICV для AH. Если реализация IP (v4 или v6) встречается с нераспознанным расширением заголовка, она должна отбросить такой пакет и передать отправителю сообщение ICMP. IPsec просто не увидит такого пакета. Если реализация IPsec сталкивается с нераспознанной опцией IPv4, эту опцию следует целиком обнулить, используя второй байт опции в качестве ее размера. Опции IPv6 (в заголовках Destination Extension или заголовке Hop-by-Hop Extension) содержат флаг изменчивости, который определяет порядок обработки такой опции.

3.3.3.1.1. Расчет ICV для IPv4

3.3.3.1.1.1. Поля основного заголовка

Базовые поля заголовка IPv4 характеризуются следующим образом:

Неизменные
Version
Internet Header Length
Total Length
Identification
Protocol (здесь должно быть значение для AH)
Source Address
Destination Address (без строгой или нестрогой маршрутизации, заданной отправителем)
Предсказуемо изменяемые
Destination Address (со строгой или нестрогой маршрутизацией, заданной отправителем)
Изменяемые (0 перед расчетом ICV)
Differentiated Services Code Point (DSCP) (6 битов, см. RFC 2474 [NBBB98])
Explicit Congestion Notification (ECN) (2 бита, см. RFC 3168 [RFB01])
Flags
Fragment Offset
Time to Live (TTL)
Header Checksum

DSCP — маршрутизаторы могут менять значение поля DS для обеспечения желаемого сервиса (локального или сквозного), поэтому значение поля в момент получения пакета отправителю предсказать невозможно.
ECN — это поле будет меняться, если на пути встретится перегруженный маршрутизатор, следовательно значение поля в момент получения пакета не может быть определено отправителем.
Flags — это поле исключается из расчетов, поскольку промежуточные маршрутизаторы могут устанавливать флаг DF, даже в тех случаях, когда отправитель не установил его.
Fragment Offset — поскольку AH применяется только к нефрагментированным пакетам IP, значение этого поля всегда должно быть нулевым, поэтому оно исключено из расчета (несмотря на предсказуемость).
TTL — это значение маршрутизаторы меняют в процессе штатной обработки пакетов, поэтому отправитель не может предсказать значение поля в момент приема пакета.
Header Checksum — это поле меняется при изменении любого флага, поэтому отправитель не может предсказать значение поля на момент доставки пакета.

3.3.3.1.1.2. Опции

Для IPv4 (в отличие от IPv6) не существует механизма маркировки опций, изменяющихся при передаче. По этой причине опции IPv4 перечислены в Приложении A и явно классифицированы, как неизменные, изменяющиеся предсказуемо и переменчивые. Для IPv4 опция рассматривается как неделимый объект, поэтому, несмотря на неизменность типа и размера некоторых опций при передаче, изменение значения опции делает все поле данной опции изменяемым и опция целиком учитывается как нулевые значения при расчете ICV.

3.3.3.1.2. Расчет ICV для IPv6

3.3.3.1.2.1. Поля основного заголовка

Поля заголовков IPv6 классифицируются следующим образом:

Неизменные
Version
Payload Length
Next Header
Source Address
Destination Address (без заголовка Routing Extension)
Предсказуемо изменяемые
Destination Address (с заголовком Routing Extension)
Изменяемые (0 перед расчетом ICV)
DSCP (6 битов, см. RFC2474 [NBBB98])
ECN (2 бита, см. RFC3168 [RFB01])
Flow Label
Hop Limit

3.3.3.1.2.2. Расширенные заголовки с опциями

Опции IPv6 в расширенных заголовках Hop-by-Hop и Destination содержат бит, указывающий, что опция может измениться (непредсказуемо) в процессе передачи. Для любой опции, которая может измениться на маршруте, все поле Option Data должно трактоваться как нулевые октеты при вычислении и проверке ICV. Поля Option Type и Opt Data Len включаются в расчет ICV. Все опции, для которых упомянутый бит показывает неизменность, включаются в расчет ICV. Дополнительную информацию о заголовках IPv6 можно найти в спецификации протокола [DH98].

3.3.3.1.2.3. Расширенные заголовки без опций

Расширенные заголовки IPv6, не содержащие опций, явно перечислены в Приложении A и классифицированы, как неизменные, изменяемые предсказуемо или изменяемые.

3.3.3.2. Заполнение и расширенные порядковые номера

3.3.3.2.1. Заполнение ICV

Как указано в параграфе 2.6, поле ICV может включать явное заполнение, если это требуется для выравнивания заголовка AH по границе 32 (IPv4) или 64 (IPv6) бита. Если заполнение требуется, его размер определяют два фактора:

размер ICV;
версия протокола IP (v4 или v6)

Например, если выбранный алгоритм дает 96 контрольную сумму, заполнения не требуется для обеих версий IP. Однако, если другой алгоритм расчета ICV дает сумму иного размера, может потребоваться заполнение в зависимости от размера результата и версии протокола IP. Содержимое поля заполнения выбирается по усмотрению отправителя (заполнение произвольно, но использования случайных значений в целях защиты не требуется). Эти байты заполнения включаются в расчет ICV, учитываются, как часть Payload Length, и передаются в конце поля ICV, чтобы позволить получателю повторно выполнить расчет ICV для проверки. Заполнение, превышающее по размеру количество, требуемое для выравнивания заголовков Ipv4/IPv6, не допускается.

3.3.3.2.2. Неявное заполнение и ESN

Если для SA выбрано использование ESN, старшие 32 бита расширенного порядкового номера должны включаться в расчет ICV. При расчете эти биты (неявно) добавляются непосредественно после данных и перед любым неявным заполнением в пакете.

Для некоторых алгоритмов контроля целостности строка байтов, по отношению к которой выполняются операции расчета ICV, должна иметь размер, кратный заданному алгоритмом размеру блока. Если размера пакета IP (включая AH и 32 старших бита ESN при использовании расширенной нумерации) не соответствует этим требованиям, в конец пакета перед рачсетом ICV должны добавляться байты неявного заполнения. Октеты заполнения должны иметь нулевое значение. Для решения вопроса об использовании такого неявного заполнения необходимо обратиться к документу, определяющему алгоритм контроля целостности. Если в документе нет ответа на данный вопрос, по умолчанию предполагается необходимость использования неявного заполнения (для выравнивания размера пакета в соответствии с размером блока, требуемого алгоритмом). Если байты заполнения требуются, но алгоритм не задает значения этих байтов, должны использоваться нулевые значения байтов заполнения.

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

Если требуется фрагментация IP, она выполняется после обработки AH в реализации IPsec. Таким образом, в транспортном режиме AH применяется только к целым дейтаграммам IP (не фрагментам). Пакет IPv4, к которому применили AH, может быть фрагментирован маршрутизаторами на пути и в таком случае фрагменты должны быть собраны до обработки AH на приемной стороне (этого не возникает для IPv6, где фрагментация по инициативе маршрутизаторов невозможна). В туннельном режиме AH применяется к пакетам IP, содержимое которых может представлять собой фрагменты пакетов IP. Например, шлюз или реализация IPsec bump-in-the-stack или bump-in-the-wire (см. документ по архитектуре защиты) может использовать AH для таких фрагментов в туннельном режиме.

Фрагментация, выполняемая реализацией IPsec или маршрутаторами на пути доставки между партнерами IPsec, существенно снижает производительность. Более того, необходимость сборки фрагментов на приемной стороне до выполнения операций AH, порождает возможность организации атак на отказ служб. Таким образом, реализация AH может выбрать отказ от поддержки фрагментации и маркировать передаваемые пакеты флагом DF (Не фрагментировать) для облегчения определения PMTU (Path MTU — размер максимального передаваемого блока для пути). В любом случае, реализация AH должна поддерживать генерацию сообщений ICMP PMTU (или использование эквивалентной внутренней сигнализации) для минимизации издержек на фрагментирование. Детали требований, связанных с фрагментацией рассматриваются в документе по архитектуре защиты.

3.4. Обработка входящих пакетов

При наличии нескольких заголовков/расширений IPsec при обработке каждого из них остальные игнорируются (не обнуляются и не используются).

3.4.1. Сборка фрагментов

Если нужна сборка фрагментов, она выполняется до обработки AH. Если переданный на обработку AH пакет оказывается фрагментом IP (т. е., поле Offset имеет ненулевое значение или установлен флаг More Fragments), получатель должен отбрасывать такой пакет и делать запись в журнале аудита. В запись следует включать значение SPI, дату и время, адреса отправителя и получателя, а также Flow ID для IPv6.

3.4.2. Нахождение SA

При получении пакета, содержащего идентификационный заголовок IP (AH), получатель определяет подходящую (одностороннюю) SA путем просмотра SAD. Для индивидуальных SA определение основано на значении SPI, в дополнение к которому может использоваться поле протокола, как описано в параграфе 2.4. Если реализация поддерживает групповой трафик, при определении SA используется также адрес получателя (в дополнение к SPI) и может применяться адрес отправителя, как описано в параграфе 2.4 (более подробно этот процесс описан в документе по архитектуре защиты). Запись SAD для SA показывает также использование поля Sequence Number и его размер (32 или 64 бита) для данной SA. Кроме того, запись SAD для SA задает алгоритм(ы), используемый для расчета ICV и показывает, нужно ли проверять значения ICV.

Если для пакета не найдено защищенной связи, получатель должен отбросить пакет с записью в журнал аудита. В запись следует включать значение SPI, дату и время, адреса отправителя и получателя, а также Flow ID для IPv6.

Отметим, что трафик управления SA (такой, как пакеты IKE) не требуется обрабатывать на базе SPI, т. е., этот трафик может демультиплексироваться отдельно (например, на основе полей Next Protocol и Port).

3.4.3. Проверка порядковых номеров

Все реализации AH должны поддерживать предотвращение повторного использования пакетов, хотя использование этой функции может быть включено или отключено получателем на уровне SA. Функции предотвращения повторного использования применимы как к индивидуальным, так и к групповым SA. Однако данный стандарт не задает механизмов защиты от повторного использования пакетов для SA со множеством отправителей (групповых или индивидуальных). При отсутствии согласования (или настройки вручную) механизма предотвращения повторного использования для таких SA отправителю и получателю рекомендуется проверить запрет использования поля Sequence Number для таких SA (запрет организуется путем согласования или вручную), как описано ниже.

Если получатель не включил предотвращение повторного использования для SA, на входе не проверяются значения поля Sequence Number. Однако с точки зрения отправителя предотвращение повторного использования по умолчанию включено. Чтобы избавить отправителя от ненужной передачи и мониторинга порядковых номеров (см. параграф 3.3.2.Генерация порядковых номеров), получателю следует уведомить отправителя об отказе от поддержки предотвращения повторного использования на этапе организации SA с помощью протокола организации SA (например, IKE).

Если получатель включил предотвращение повторного использования для SA, он должен установить значение счетчика пакетов для данной SA нулевым на момент организации SA. Для каждого принятого пакета получатель должен проверять, что поле Sequence Number в пакете не совпадает с порядковым номером ни одного из пакетов, полученных в данной SA. Эту проверку следует проводить до выполнения каких-либо операций AH по отношению к данному пакету сразу после проверки принадлежности пакета к SA для ускорения отбрасывания дубликатов.

Дубликаты отбрасываются с помощью «скользящего» окна приема. Реализация такого окна осуществляется локально, но описанная ниже функциональность должна поддерживаться всем реализациями.

«Правый» край окна представляет ноибольшее проверенное значение поля Sequence Number для данной SA. Пакеты с номерами, выходящими за «левый» край окна, отбрасываются. Попадающие в окно пакеты проверяются на предмет совпадения порядковых номеров с номерами принятых пакетов для окна.

При использовании опции ESN для SA явно передаются только младшие 32 бита расширенного порядкового номера, но получатель использует и старшие 32 бита номера для SA (от локального счетчика) при проверке порядковых номеров. При восстановлении полного порядкового номера, если значение младших 32 битов порядкового номера из принятого пакета меньше младших 32 битов значения счетчика порядковых номеров на стороне получателя, последний предполагает, что значение старших 32 битов номера было инкрементировано, т. е., перемещает номер в новое «подпространство». Этот алгоритм допускает интервал приема для отдельной SA до 2^32-1 пакетов. Если интервал становится больше, могут использоваться эвристические проверки для ресинхронизации порядковых номеров на приемной стороне, как описано в Приложении B.

Если полученный пакет попадает в окно и не является дубликатом, получатель выполняет проверку ICV. При отрицательном результате проверки ICV получатель должен отбросить полученную дейтаграмму IP, как некорректную, с записью в журнал аудита. В запись следует включать значение SPI, дату и время, адреса отправителя и получателя, а также Flow ID для IPv6. Окно приема обновляется только при положительном результате проверки ICV.

Должны поддерживаться окна минимального размера в 32 пакета, но по умолчанию следует поддерживать окна размером 64 пакета. Получатель может выбирать другие размеры окна (больше минимального). Получатель не информирует отправителя о выбранном размере окна. Для высоскоскоростных сред размер окна приема следует увеличивать. Минимальные и рекомендуемые размеры окна для высокоскоростных (например, мультимегабитных) устройств данный стандарт не задает.

3.4.4. Проверка ICV

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

Если рассчитанное значение ICV совпадает с полученным в пакете, дейтаграмма считается корректной. Если значения не совпадают, получатель должен отбросить полученную дейтаграмму IP, как некорректную с записью информации об этом факте в журнал аудита. В запись следует включать значение SPI, дату и время, адреса отправителя и получателя, а также Flow ID для IPv6.

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

Сначала значение ICV из принятого пакета сохраняется и заменяется нулем. Значения поля заполнения ICV при этом не изменяются. Далее обнуляются все остальные поля, которые могли измениться в процессе передачи пакета (поля, которые следует обнулять при расчете ICV, перечислены в параграфе 3.3.3.1. Обработка изменяемыхполей). Если для данной SA выбрано использование ESN, добавляются старшие 32 бита ESN в конце пакета. Проверяется общий размер пакета (как описано выше) и при необходимости в конец пакета (после старших битов ESN, ESN, ESN, ESN, если они используются) добавляются нулевые байты неявного заполнения с учетом требований алгоритма контроля целостности.

Здесь описан лишь общий ход проверки, который на практике может быть существенно другим. Например, при использовании цифровой подписи или однонаправленной хэш-функции для расчета ICV соответствующий процесс может быть более сложным.

4. Аудит

Не все системы, поддерживающие AH, реализуют аудит. Однако, если AH встраивается в систему, поддерживающую аудит, реализация AH должна поддерживать аудит и также должна позволять администратору системы включать и отключать аудит для AH. В большинстве случаев гранулярность аудита определяется локально. Однако некоторые события, заносимые в журнал аудита, задаются данной спецификацией и для каждого из этих событий указывается минимальный набор информации, которую следует включать в журнал аудита. В записи можно также включать дополнительную информацию и можно указывать в журнале информацию о других событиях, которые явно не упомянуты в данной спецификации. Получатель не обязан уведомлять отправителя о внесении записей в журнал аудита, поскольку такое требование создавало бы возможность организации атак на отказ служб.

5. Соответствие требованиям

Реализации, которые заявляют о своем соответствии или совместимости с данной спецификацией, должны полностью реализовать синтаксис и обработку AH, описанные здесь, для индивидуального трафика, а также должны полностью выполнять все требования документа по архитектуре защиты [Ken-Arch]. В дополнение к этому, реализации, заявляющие поддержку группового трафика, должны соответствовать всем дополнительным требованиям, заданным для такого трафика. При ручном распределении ключей, используемых для расчета ICV, корректная работа системы предотвращения повторного использования пакетов требует аккуратной поддержки состояния счетчика на передающей стороне при замене ключа, поскольку в этом случае невозможно восстановить работу после переполнения счетчика. Таким образом, совместимым со спецификацией реализациям не следует предоставлять такой сервис для SA с распространением ключей вручную.

Обязательные для реализации алгоритмы, используемые с AH, описаны в отдельном RFC [Eas04], для обеспечения возможности обновления алгоритмов независимо от протокола. Кроме обязательных для AH алгоритмов могут поддерживаться дополнительные алгоритмы.

6. Вопросы безопасности

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

7. Отличия от RFC 2402

В этом документе имеется ряд перечисленных ниже отличий от RFC 2402 [RFC2402].

Изменено определение SPI для обеспечения возможности однотипного поиска в SAD для индивидуальных и групповых SA, совместимого со многими технологиями групповой передачи. Для выбора индивидуальных SASA значение SPI может использоваться само по себе или в комбинации с протоколом по усмотрению получателя. Для выбора групповых SA значение SPI объединяется с адресом отправителя (и, опционально, с адресом получателя).
Добавлены расширенные порядковые номера (ESN) для обеспечения 64-битовой нумерации на высокоскоростных соединениях. Разъяснены требования к отправителю и получтателю для групповых SA A и защищенных связей с множеством отправителей.
Спецификации обязательных алгоритмов вынесены в отдельный документ [Eas04].

8. Благодарности

Автор выражает свою благодарность Ran Atkinson, за его критически важную роль на начальном этапе создания IPsec и всем авторам первой серии стандартов IPsec — RFC 1825-1827. Отдельная благодарность Karen Seo за помощь в редактировании этой и предыдущей версии данной спецификации. Автор также благодарит членов рабочих групп IPsec и MSEC, которые внесли свой вклад в разработку спецификации протокола.

9. Литература

9.1. Нормативные документы

[Bra97]	S. Bradner, «Key words for use in RFCs to Indicate Requirement Level», BCP 14, RFC 2119, Март 1997.
[DH98]	S. Deering and R. Hinden, «Спецификация IPv6», RFC 2460, Декабрь 1998.
[Eas04]	D. Eastlake 3rd, «Требования к реализациям криптографических алгоритмов для ESP и AH», RFC 4305, Декабрь 2005
[Ken-Arch]	S. Kent and K. Seo, «Security Architecture for the Internet Protocol», RFC 4301, Декабрь 2005.
[RFC791]	J. Postel, «Протокол IP (Internet Protocol)», STD 5, RFC 791, Сентябрь 1981
[RFC1108]	S. Kent, «U.S. Department of Defense Security Options for the Internet Protocol», RFC 1108, Ноябрь 1991.

9.2. Дополнительная литература

[AES]	Advanced Encryption Standard (AES), Federal Information Processing Standard 197, National Institutes of Standards and Technology, November 26, 2001.
[HC03]	H. Holbrook and B. Cain, «Source Specific Multicast for IP», RFC 4607, Август 2006.
[IKEv2]	C. Kaufman, «Протокол обмена ключами в Internet (IKEv2)», RFC 4306, Декабрь 2005
[Ken-ESP]	S. Kent, «RFC 4303 — Инкапсуляция защищенных данных IP (ESP)», RFC 4303, Декабрь 2005
[NBBB98]	K. Nichols, S. Blake, F. Baker, D. Black, «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers», RFC 2474, Декабрь 1998.
[RFB01]	Ramakrishnan, K., Floyd, S., and D. Black, «Добавление явных уведомлений о перегрузке (ECN) в IP», RFC 3168, Сентябрь 2001
[RFC1063]	J. Mogul, C. Kent, C. Partridge, K. McCloghrie, «IP MTU discovery options», RFC 1063, Июль 1988.
[RFC1122]	R. Braden, «Требования к хостам Internet - Коммуникационные уровни», STD 3, RFC 1122, October 1989
[RFC1191]	J. Mogul and S. Deering, «Path MTU discovery», RFC 1191, Ноябрь 1990
[RFC1385]	Z. Wang, «EIP: The Extended Internet Protocol», RFC 1385, Ноябрь 1992.
[RFC1393]	G. Malkin, «Traceroute Using an IP Option», RFC 1393, Январь 1993.
[RFC1770]	C. Graff, «IPv4 Option for Sender Directed Multi-Destination Delivery», RFC 1770, Март 1995.
[RFC2113]	D. Katz, «IP Router Alert Option», RFC 2113, Февраль 1997.
[RFC2402]	S. Kent and R. Atkinson, «IP Authentication Header», RFC 2402, Ноябрь 1998.
[RFC3547]	M. Baugher, B. Weis, T. Hardjono, H. Harney, «The Group Domain of Interpretation», RFC 3547, Июль 2003.
[RFC3740]	T. Hardjono and B. Weis, «The Multicast Group Security Architecture», RFC 3740, Март 2004.

Приложение A: Изменяемые опции и расширения заголовков IP

A1. Опции IPv4

В таблице показаны опции IPv4 с классификацией их по «изменяемости». Если в колонке «Документ» указаны две ссылки, второй документ имеет более высокий приоритет.

Копия	Класс	Номер опции	Имя	Документ
Неизменные — учитываются в ICV
0	0	0	End of Options List — конец списка опций	[RFC791]
0	0	1	No Operation — нет операции	[RFC791]
1	0	2	Security — защита	[RFC1108]
1	0	5	Extended Security — расширенная защита	[RFC1108]
1	0	6	Commercial Security — коммерческая защита	[RFC2113]
1	0	20	Router Alert — сигнал маршрутизатора	[RFC1770]
1	0	21	Sender Directed Multi-Destination Delivery — направленная отправителем доставка по множеству адресов
Изменяемые — должны иметь нулевое значение
1	0	3	Loose Source Route — нежестко заданный отправителем маршрут	[RFC791]
0	2	4	Time Stamp — временная метка	[RFC791]
0	0	7	Record Route — запись маршрута	[RFC791]
1	0	9	Strict Source Route — жестко заданный отправителем маршрут	[RFC791]
0	2	18	Traceroute — трассировка пути	[RFC1393]
Экспериментальные и переопределенные — должны иметь нулевое значение
1	0	8	Stream ID — идентификатор потока	[RFC791] [RFC1122]
0	0	11	MTU Probe — проба MTU	[RFC1063] [RFC1191]
0	0	12	MTU Reply — отклик MTU	[RFC1063] [RFC1191]
1	0	17	Extended Internet Protocol — расширенный протокол IP	[RFC1385] [DH98]
0	0	10	Experimental Measurement — экспериментальные измерения
1	2	13	Experimental Flow Control — экспериментальное управление потоком данных
1	0	14	Experimental Access Ctl — экспериментальный контроль доступа
0	0	15	???
1	0	16	IMI Traffic Descriptor — дескриптор трафика IMI
1	0	19	Address Extension — расширение адреса

A2. Заголовки расширения IPv6

В таблице показаны расширения заголовков IPv6 и дана их классификация в плане «изменчивости»

Название опции или расширения	Ссылка
Предсказуемо изменяемые — включаются в расчет ICV
Routing (Type 0)	[DH98]
Биты, показывающие изменяется ли опция (изменения при передаче непредсказуемы)
Опция Hop-by-Hop	[DH98]
Опция Destination	[DH98]
Неприменимо
Fragmentation	[DH98]

Опции IPv6 в расширенных заголовках Hop-by-Hop и Destination содержат бит, который показывает возможность (непредсказуемого) изменения опции в процессе доставки пакета. Для лобой опции, содержимое которое может меняться на пути, все поле Option Data должно трактоваться, как нулевые октеты при расчете и проверке ICV. Поля Option Type и Opt Data Len включаются в расчет ICV. Все опции, для которых флаг показывает неизменность, включаются в расчет ICV. Дополнительная информация по опциям IPv6 приведена в [DH98].
Routing (Type 0) — этот заголовок IPv6 будет приводить к реорганизации адресных полей в пакете на пути доставки. Однако содержимое пакета на момент доставки известно отправителю и всем промежуточным узлам. Следовательно, это поле включается в расчет ICV, поскольку его изменения предсказуемы. Отправитель должен перед расчетом ICV включить в это поле то значение, которое увидит получатель.
Fragmentation — фрагментация происходит после выходной обработки IPsec (параграф 3.3), а сборка — перед входной обработкой IPsec (параграф 3.4). По этой причине расширенный заголовок Fragmentation (если он имеется) не виден для IPsec

Отметим, что на приемной стороне реализация IP может сохранить расширенный заголовок Fragmentation после сборки фрагментов. В таком случае реализация AH при получении пакета должна «удалить» (или пропустить) этот заголовок до обработки ICV и заменить значение предыдущего поля Next Header на значение Next Header из заголовка Fragmentation.

Отметим, что на стороне отправителя реализация IP может передавать IPsec пакет с расширенным заголовком Fragmentation, где Offset = 0 (первый фрагмент) и флаг More Fragments = 0 (последний фрагмент). В таких случаях до обработки ICV реализация AH должна «удалить» (или пропустить) этот заголовок и заменить значение предыдущего Next Header на значение Next Header из заголовка Fragmentation.

Приложение B: Расширенные порядковые номера (64 бита)

B1. Обзор

В этом приложении описана схема расширенной порядковой нумерации (ESN) для IPsec (ESP и AH), где используются 64-битовые порядковые номера, но в каждом пакете передаются только младшие 32 бита номера. Описана схема окна, используемого для обнаружения повтрно используемых пакетов, а также механизм определения старших битов порядкового номера, используемых для отбрасывания пакетов и расчета ICV. Описан также механизм обработки случаев потери синхронизации для старших (не передаваемых в пакетах) битов порядкового номера.

B2. Окно Anti-Replay

Получатель будет поддерживать окно предотвращения повторного использования пакетов размером W. Это окно будет ограничивать степень разупорядочивания пакетов при доставке без потери идентификации. Все 2^32 порядковых номера, связанных с любым фиксированным значением старших 32 битов (Seqh) будем называть подпространством порядковых номеров. В приведенной ниже таблице перечислены используемые переменные и даны их определения.

Имя	Размер в битах	Значение
W	32	Размер окна
T	64	Наибольший порядковый номер, идентифицированный до настоящего времени — верхняя граница окна
Tl	32	32 младших бита T
Th	32	32 старших бита T
B	64	Нижняя граница окна
Bl	32	32 младших бита B
Bh	32	32 старших бита B
Seq	64	Порядковый номер полученного пакета
Seql	32	32 младших бита Seq
Seqh	32	32 старших бита Seq

При выполнении проверки на предмет повторного использования пакетов или определении старших битов номера для идентификации входящего пакета возможны два случая:

Случай A: Tl >= (W - 1) все окно находится в одном подпространстве порядковых номеров (Рисунок 2)
Случай B: Tl < (W - 1) окно захватывает части двух смежных подпространств порядковых номеров (Рисунок 3).

На рисунках нижняя линия ---- показывает смежные подпространства порядковых номеров, а 0 указывает начало каждого подпространства. Короткая двойная линия === показывает применимые старшие биты, а ==== представляет окно. Звездочки **** обозначают грядущие номера, т. е., номера номера, превышающие максимальный идентифицируемый в данный момент номер (ThTl).

Th+1                         *********
Th               =======*****
      --0--------+-----+-----0--------+-----------0--
                 Bl    Tl            Bl
                                (Bl+2^32) mod 2^32
Рисунок 2: Случай A

Th                           ====**************
Th-1                      ===
      --0-----------------+--0--+--------------+--0--
                          Bl    Tl            Bl
                                         (Bl+2^32) mod 2^32
Рисунок 3: Случай B

B2.1. Использование окна Anti-Replay и управление им

Окно предотвращения повторов можно рассматривать как строку битов размером W (W = T - B + 1 и не может превышать 2^32 - 1). Младший бит строки соответствует B, а старший — T и каждый порядковый номер от Bl до Tl представлен соответствующим битом. Значение бита показывает, был ли пакет с соответствующим номером принят и идентифицирован, что позволяет обнаружить и отбросить повторные пакеты.

При получении и проверке корректности пакета с 64-битовым порядковым номером (Seq), превышающим T:

B увеличивается на (Seq - T);
отбрасываются (Seq - T) битов в левой части окна;
добавляются (Seq - T) битов в правой части окна;
устанавливается «верхний» бит для индикации приема и идентификации пакета с данным порядковым номером;
сбрасываются новые биты между T и «верхним» битом для индикации отсутствия принятых пакетов с соответствующими порядковыми номерами;
для T устанавливается значение нового порядкового нгомера.

Проверка пакетов на предмет повторного использования:

Случай A: Если Seql >= Bl (где Bl = Tl - W + 1) И Seql <= Tl, проверяется соответствующий бит окна. Если пакет с номером Seql уже был принят (бит окна установлен), он отбрасывается. В противном случае проверяется целостность пакета. Проверка старших битов номера (Seqh) описана в параграфе B2.2.
Случай B: Если Seql >= Bl ( где Bl = Tl - W + 1) ИЛИ Seql <= Tl, проверяется соответствую щий бит окна. Если пакет с номером Seql уже был принят (бит окна установлен), он отбрасывается. В противном случае проверяется целостность пакета. Проверка старших битов номера (Seqh) описана в параграфе B2.2.

B2.2. Определение старших битов (Seqh) порядкового номера

Поскольку в пакетах передается только значение Seql, получатель должен отслеживать подпространство порядковых номеров для каждого пакета (т. е., определять значение Seqh). Приведенные уравнения определяют выбор Seqh в «нормальных» условиях. В параграфе B3 рассматривается определение старших битов номера в условиях экстремальных потерь пакетов.

+ Для случая A (Рисунок 2):
  Если Seql >= Bl (где Bl = Tl - W + 1), то Seqh = Th
  Если Seql <  Bl (где Bl = Tl - W + 1), то Seqh = Th + 1
+ Для случая B (Рисунок 3):
  Если Seql >= Bl ( где Bl = Tl - W + 1), то Seqh = Th - 1
  Если Seql <  Bl ( где Bl = Tl - W + 1), то Seqh = Th

B2.3. Пример псевдокода

Приведенный ниже псевдокод иллюстрирует описанные выше алгоритмы предотвращения повторного использования и контроля целостности пакетов. Значения Seql, Tl, Th и W являются 32-битовыми целыми числами без знака. Используется арифметика по модулю 2^32.

Если (Tl >= W - 1)                                  Случай A
    Если (Seql >= Tl - W + 1)
        Seqh = Th
        Если (Seql <= Tl)
            Если (проверка на предмет повтора прошла)
                Если (проверка целостности прошла)
                    Установить бит, соответствующий Seql
                    Принять пакет
                Иначе отбросить пакет
            Иначе отбросить пакет
        Иначе
            Если (проверка целостности прошла)
                Tl = Seql (shift bits)
                Установить бит, соответствующий Seql
                Принять пакет
            Иначе отбросить пакет
    Иначе
        Seqh = Th + 1
        Если (проверка целостности прошла)
            Tl = Seql (shift bits)
            Th = Th + 1
            Установить бит, соответствующий Seql
            Принять пакет
        Иначе отбросить пакет
Иначе                                               Случай B
    Если (Seql >= Tl - W + 1)
        Seqh = Th - 1
        Если (проверка на предмет повтора прошла)
            Если (pass integrity check)
                Установить бит, соответствующий Seql
                Принять пакет
            Иначе отбросить пакет
        Иначе отбросить пакет
    Иначе
        Seqh = Th
        Если (Seql <= Tl)
            Если (проверка на предмет повтора прошла)
                Если (проверка целостности прошла)
                    Установить бит, соответствующий Seql
                    Принять пакет
                Иначе отбросить пакет
            Иначе отбросить пакет
        Иначе
            Если (проверка целостности прошла)
                Tl = Seql (shift bits)
                Установить бит, соответствующий Seql
                Принять пакет
            Иначе отбросить пакет

B3. Обработка потери синхронизации в результате больших потерь пакетов

При потере 2^32 или более пакетов подряд для одной SA отправитель и получатель теряют синхронизацию старших битов порядкового номера, т. е., уравнения параграфа B2.2 не будут давать корректного значения. Пока эта проблема не будет обнаружена и разрешена, последующие пакеты для данной SA не могут быть идентифицированы и будут отбрасываться. Описанную ниже процедуру восстановления синхронизации следует поддерживать во всех реализациях IPsec (ESP или AH), которые работают с ESN.

Отметим, что описанный вариант экстремальных потерь представляется маловероятным для SA, использующих протокол TCP, поскольку отправитель, не получающий пакетов ACK в ответ на переданные пакеты, будет останавливать передачу до того, как будут потеряны 2^32. И другие приложения с двухсторонним обменом данными (даже работающие по протоколу UDP) при таких экстремальных потерях будут включать тот или иной тайм-аут. Однако приложения с односторонним потоком трафика, работающие по протоколу UDP, могут не поддерживать средств автоматического детектирования экстремальных потерь пакетов и, следовательно, требуется обеспечить метод восстановления для таких ситуаций.

Предлагаемое решение призвано:

минимизировать влияние на обработку нормального трафика;
предотвратить создание новой возможности организации атак на отказ служб за счет неоправданной затраты ресурсов на ресинхронизацию;
реализовать механизм восстановления только на принимающей стороне, поскольку отправитель обычно не знает, для каких порядковых номеров получателю требуется восстановление синхронизации; реализация механизмов восстановления на приемной стороне является предпочтительной; кроме того, такое решение обеспечивает совместимость с ранними версиями.

B3.1. Включение ресинхронизации

Для каждой SA получатель запоминает число последовательных пакетов, для которых не прошла идентификация. Это значение используется для включения процесса ресинхронизации, который следует выполнять в фоновом режиме или на отдельном процессоре. Прием корректного пакета для данной SA ведет к сбросу счетчика некорректных пакетов в 0. Значение, при котором включается ресинхронизация, является локальным параметром. Не требуется поддерживать независимые значения порога ресинхронизации для каждой SA, но реализация вправе поддерживать их.

B3.2. Процесс ресинхронизации

Когда значение счетчика некорректных пакетов достигает заданного порога, выбирается «плохой» пакет, для которого процедура идентификации повторяется с использованием следующего большего значения для старшей части расширенного порядкового номера (Seqh). Значение старшей части номера увеличивается на 1 при каждой проверке.

Число попыток проверки следует ограничивать на случай того, что выбранный для проверки пакет оказался «из прошлого» или является поддельным. Максимальное число попыток задается локальным параметром. Поскольку значение Seqh неявно помещается после данных AH (или ESP), может оказаться возможной оптимизация процедуры восстановления за счет выполнения процедуры контроля целостности пакета с использованием нарастающих значений Seqh для расчета ICV. При успешной идентификации пакета с помощью описанной процедуры значение счетчика некорректных пакетов сбрасывается и устанавливается значение T, определенное по прошедшему проверку пакету.

Это решение требуется поддерживать только на приемной части, следовательно, оно обеспечивает совместимость с прежними версиями. Поскольку процедура ресинхронизации осуществляется в фоновом режиме или выполняется на отдельном процессоре, она не будет оказывать влияния на обработку остального трафика и не создает дополнительной возможности организации атак на службы путем отвлечения ресурсов от обработки трафика.

Адрес автора

Stephen Kent
BBN Technologies
10 Moulton Street
Cambridge, MA 02138 USA
Phone: +1 (617) 873-3988
EMail: moc.nbb@tnek

RFC 4302 — Идентификационный заголовок IP