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

Internet Engineering Task Force (IETF)                          F. Baker
Request for Comments: 6018                                 Cisco Systems
Category: Informational                                        W. Harrop
ISSN: 2070-1721                                              G. Armitage
                                      Swinburne University of Technology
                                                          September 2010

IPv4 and IPv6 Greynets

«Серые» сети IPv4 и IPv6

PDF

Аннотация

В этом документе рассматривается модель построения «серых сетей» (Greynet) для IPv4 и IPv6.

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

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

Документ является результатом работы IETF¹ и выражает согласованное мнение сообщества IETF. Документ был вынесен на общее рассмотрение и одобрен для публикации IESG². Не все документы, одобренные IESG, рассматриваются в качестве возможных стандартов Internet того или иного уровня (см. раздел 2 в RFC 5741).

Информацию о статусе документа, обнаруженных в нем ошибках и способах обратной связи можно найти по ссылке http://www.rfc-editor.org/info/rfc6018.

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

Авторские права (c) 2010 принадлежат IETF Trust и лицам, указанным в качестве авторов. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

«Темные сети»³ или «сетевые телескопы» развернуты несколькими организациями (включая CAIDA, Team Cymru и Мичиганский университет) для наблюдения за трафиком, адресованным в реально не используемые блоки адресов. Такой трафик становится видимым путем прямого сбора (маршрутизации в коллектор) или благодаря откликам на него (пакеты ICMP или пакеты сброса на транспортном уровне).

С темными сетями связаны две проблемы. Как только их адреса становятся известными, атакующие прекращают использование этих адресов, что ведет к снижению эффективности темных сетей. Кроме того, администраторы таких сетей связаны правилами региональных регистраторов Internet (RIR⁴) и требованиями бизнеса, что препятствует развертыванию темных сетей в активных сетях.

В работе [Harrop] введено понятие «серой сети» (Greynet):

Темные сети часто предлагаются для мониторинга аномального трафика из внешних источников и для таких сетей требуются большие непрерывные блоки неиспользуемых адресов IP — выделение таких блоков зачастую нежелательно для операторов. Мы разработали и опробовали «серую сеть» — «светлый» (lit) диапазон адресного пространства IP, в котором достаточно редко встречаются адреса темных сетей, а большую часть пространства занимают активные («светлые») адреса IP. На основе небольшой выборки трафика в кампусной сети университета можно сказать, что относительно малая плотность темных сетей позволяет обеспечить достаточно эффективное обнаружение сканирования сетей.

Иными словами, вместо резервирования префиксов, которые злоумышленники смогут попытаться проверить, рискую быть обнаруженными, Harrop предложил отвести для этого отдельные адреса (или небольшие группы смежных адресов) в подсетях, используя разные идентификаторы хостов в каждой подсети для осложнения сканирования адресов с целью обнаружения. Концепция имеет ценность в том смысле, что осложняет сопоставление адресов или префиксов с шаблоном поиска злоумышленника, поскольку их присутствие менее очевидно. В исследовании Harrop использовался протокол IPv4 [RFC0791] и была получена интересная информация.

1.1. Предыстория

Исследование, поддерживающее это предложение, включает 2 прототипа — один для IPv4 [RFC0791], другой для IPv6 [RFC2460]. Оба имеют ограничения, будучи исследовательскими экспериментами, а не реализацией готового решения.

Исходное исследование выполнил Warren Harrop и описал в [Harrop]. Оно проводилось лишь для IPv4. Автор исходил из того, что в ЛВС можно разместить неиспользуемую виртуальную или физическую машину, которая будет служить для обнаружения разных типов сканирования. Как отмечено в упомянутой статье, концепция эффективно работала при развертывании прототипа в Центре современной архитектуры Internet (CAIA⁵) Swinburne University of Technology. Основная причина заключалась в том, что со стороны возможного злоумышленника разумно было ожидать присутствия этого адреса и не было шаблонов, которые бы позволили тому догадаться о способе применения машины. В CAIA был разработан и выпущен прототип основанной на FreeBSD системы Greynet в 2008 г. [Armitage].

Baker добавил в свою концепцию маршрутизатор с идеей о том, что тот с большой вероятностью увидит любое сканирование, если оно пришло извне локальной сети и маршрутизатор должен будет использовать протокол ARP⁶ или ND⁷ для идентификации (или отказа при попытке идентификации) интересующей злоумышленника машины. По сути дела, любой отсутствующий в подсети адрес действует как триггер Greynet. Очевидно, что это будет работать в любой системе, которая реализует ARP или ND, но маршрутизатор обычно служит точкой входа в любую подсеть.

Tim Chown из School of Electronics and Computer Science University of Southampton предложил в частном порядке провести некоторые исследования по этому вопросу и весной 2010 г. Owen Stephens сделал для этого прототип Linux. Они продемонстрировали, что технология проста в реализации и фактически работает на прототипе реализации IPv6.

Вопрос, остающийся при сканировании адресов IPv6, заключается в вероятности того, что атака произойдет. Chown изначально утверждал в [RFC5157], что сканирование адресов было невозможно по причине слишком большого их числа. Однако в сентябре 2010 г. был выпущен отчет NANOG о сканировании адресов IPv6. Кроме того, имеются способы ограничения области сканирования, например, можно увидеть, что компания покупает определенный тип машин или сетевых плат (NIC⁸) и поэтому ее вероятные адреса EUI-64 ограничены диапазоном, который меньше 2⁶⁴ и больше похоже на 2²⁴ адресов в данной подсети или можно наблюдать DNS, конверты SMTP, сообщения XMPP⁹, FTP, HTTP и т. п., где содержатся адреса IP. Такие атаки можно ограничить использованием адресов Privacy Addresses [RFC4941], которые периодически меняются, делая прошлую информацию менее полезной. Однако такие аналитические методы существуют.

2. Развертывание серых сетей

Корпоративные отделы IT и другие операторы сетей часто применяют коллекторы и другие типы датчиков. Коллектор — это компьютерная система в Internet, которая специально настроена для привлечения и «отлова» пытающихся проникнуть в систему. Такие средства могут просто записывать попытки или дейтаграммы, инициирующие попытку (darknet/Greynet), или могут служить приманкой для атак с целью изучения действий и методов (honeypot — ловушка).

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

2.1. Развертывание с использованием маршрутизации — темные сети

Одним из очевидных способов идентификации и изоляции вредоносного трафика является его направленность на несуществующие адреса или префиксы. Если в кампусе используется сеть IPv4 с префиксом /24 или IPv6 с префиксом /56, но реально применяется меньше 100 подсетей, можно, например, использовать только четные подсети (128 из 256 для указанного префикса). Зная, что активные префиксы более специфичны и поэтому привлекают соответствующий трафик, можно анонсировать из коллектора используемый по умолчанию префикс, привлекая трафик на неиспользуемые префиксы данного домена.

Второй вопрос связан с имитацией атакуемого хоста — коллектор может просто записывать незванный трафик, а может отвечать на него как ловушка (honeypot).

2.2. Использование малозаселенного адресного пространства — «серые сети»

В подсетях IPv4 обычно имеются нераспределенные адреса, хотя бы потому, что в бесклассовой междоменной маршрутизации (CIDR¹⁰) выделяются блоки адресов O(2ⁿ), размер которых не всегда совпадает с числом систем в подсети. Так же происходит с активными префиксами IPv6 и даже в очень большой коммутируемой ЛВС скорей всего будет использована лишь часть адресов. Этот вопрос рассматривается в параграфе 2.5.1 [RFC4291]. Если адреса распределены более или менее случайно, вероятность того, что атакующий угадает реально применяемые адреса, достаточно мала. Это позволяет использовать такие незанятые адреса внутри префикса IP.

Маршрутизаторы применяют IPv4 ARP [RFC0826] и IPv6 Neighbor Discovery [RFC4861] для определения адресов MAC (Media Access Control — управление доступом к среде) своих соседей, которым нужно передавать дейтаграммы. Обе спецификации предполагают, что при поступлении дейтаграммы на маршрутизатор, обслуживающий целевой префикс, но не знающий MAC-адреса предполагаемого получателя, тот будет выполнять ряд действий:

• размещение дейтаграммы в очереди;

• передача запроса Neighbor Solicitation или ARP;

• ожидание отклика Neighbor Advertisement или ARP;

• при получении отклика пересылка дейтаграммы из очереди.

Когда MAC-адрес хоста имеется в таблице маршрутизатора (и является действительным) вопросов не возникает.

В статье [Harrop] серая сеть (Greynet) организуется на хосте, который отвечает на запросы ARP для всех «темных» адресов IP. Однако небольшое изменение в маршрутизаторе может дополнить эту модель. Помимо постановки в очередь или отбрасывания дейтаграммы, вызвавшей запрос ARP или Neighbor Solicitation, маршрутизатор копирует ее через независимый канал к оборудованию Greynet. Этот канал может быть отдельным физическим интерфейсом, устройством, VLAN, туннелем, инкапсуляцией UDP (или иной), а фактически любым местом, где такая дейтаграмма может быть обработана. В зависимости от требований приемного коллектора можно также предоставлять суммарную информацию в виде IPFIX¹¹ [RFC5101] [RFC5610].

Анализирующее оборудование будет получать два типа дейтаграмм. Наиболее интересны будут те, которые направлены по «темным» адресам IP. Менее интересен случай, когда дейтаграмма адресована легитимному узлу, MAC-адрес которого по той или иной причине временно отсутствует в таблице маршрутизатора. Дейтаграммы, прибывающие адресатам IP, для которых отклик ARP (или Neighbor Advertisement) еще не получен, также могут пересылаться анализирующему устройству по независимому каналу, но это вряд ли даст полезную информацию.

Анализирующее оборудование, в зависимости от способа распознавания маршрутизатором «темных» адресов IP, может легко отслеживать картину дейтаграмм, направленных в неиспользуемые части сети. Оно также может отвечать на такие дейтаграммы, выступая в качестве применки для получения дополнительных дейтаграмм от атакующего.

Если коллектор отвечает напрямую, атакующий может обнаружить это с помощью информации из дейтаграммы (или о ней) — например, дейтаграммы, отправленные в ту же подсеть IP, могут приходить с другими значениями TTL. Поэтому для коллектора может оказаться разумным ответ через туннель, как будто ответ пришел из той же подсети IP. В этом случае коллектору не следует отвечать на дейтаграммы, направленные по «светлым» адресам IP, поскольку исходный получатель в конечном итоге ответит на ARP или Neighbor Solicitation.

Одним из следствий этой модели является то, что распределенные DoS-атаки (DDoS¹²) завершаются в подсетях маршрутизатора, а не на каналах между маршрутизаторами.

2.3. Другие фильтры

Очевидное расширение концепции будет включать трафик, идентифицируемый другими фильтрами, для передачи коллектору. Например, можно настроить систему на пересылку трафика, для которого не проходит проверка по обратному пути с индивидуальной маршрутизацией (uRPF¹³) [RFC2827], в коллектор через тот же туннель.

3. Влияние на устройство маршрутизаторов

Влияние на устройство маршрутизаторов относится к алгоритмам IPv4 ARP и IPv6 Neighbor Discovery. Может оказаться интересной (настраиваемая в конфигурации) возможность пересылки в анализирующую систему приходящих дейтаграммы, которые вызывают запросы ARP Request или Neighbor Solicit, приводящие к отказу, в интерфейс, устройство, VLAN или туннель.

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

Этот документ описывает средство для поддержки безопасности сетей IPv4 и IPv6. Подобно другим инструментам, оно имеет ограничения и возможные атаки. Если отбрасывание трафика в условиях перегрузки — вещь хорошая, то его удержание и последующая пересылка создают нагрузку на сеть и маршрутизатор, что может служить для организации атаки. Однако для такой атаки имеется очевидное смягчение — просто выбирается (как удобно для оператора) подмножество пересылаемого трафика и отбрасывается остальной. Кроме того, такие атаки не новы, здесь лишь меняется характер. Поток, который будет создавать атаку, приведет к росту числа сообщений ARP или Neighbor Solicit, которые все принимающие хосты должны отбрасывать. Такая атака занимает часть пропускной способности, но здесь эта часть предполагается выделенной специально.

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

• Выбор всех дейтаграмм, вызывающих ARP Request или Neighbor Solicit.

• Выбор подмножества дейтаграмм, на которые не было ответа в течение некоторого заданного интервала времени (эти адреса вероятно являются «темными»).

• Выбор из этих адресов подмножества новых — если адрес был запрошен, пересылка избыточных данных может оказаться бесполезной.

• Выбор всех дейтаграмм с ограничением скорости.

• Выбор всех дейтаграмм, соответствующих (не соответствующих) определенному правилу фильтрации.

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

Алгоритмы изучения поведения Internet-атак путем наблюдения рассеянного трафика использовались Team Cymru из CAIDA, University of Michigan и другими исследователями. Harrop расширил их в своем исследовании. Эта формулировка идеи обсуждалась авторами в 2005 г. Данный документ возник в результате разговора с Paul Vixie и Rhette Marsh о сенсорах трафика Internet, они также внесли полезные комментарии по этому поводу. Albert Manfredi отметил различие между ЛВС (в соответствии с IEEE 802) и подсетью IP.

Tim Chown [RFC5157] заметил, что, по крайней мере на момент написания этого RFC, об атаках со сканированием адресов для IPv6 не было известно. Однако, как отмечено в параграфе 1.1, об атаке с (частичным) сканированием недавно писали в почтовой конференции NANOG. Однако Rhette Marsh предложила структуру такой атаки, а Fred Baker — подходы, основанные на адресной информации, которой обмениваются приложения. Поэтому авторы считают, что такие проблемы могут возникнуть для IPv6 в будущем, когда IPv6 станет более интересной целью.

Tim Chown и Owen Stephens проверили предложение и внесли полезные комментарии, которые были включены в этот документ. Однако самым значительным их комментарием было: «Это работает».

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

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

[Harrop] Harrop, W. and G. Armitage, «Greynets: a definition and evaluation of sparsely populated darknets», IEEE LCN IEEE 30th Conference on Local Computer Networks, 2005.

[RFC0791] Postel, J., «Internet Protocol», STD 5, RFC 791, September 1981.

[RFC0826] Plummer, D., «Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware», STD 37, RFC 826, November 1982.

[RFC2460] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 2460, December 1998.

[RFC4291] Hinden, R. and S. Deering, «IP Version 6 Addressing Architecture», RFC 4291, February 2006.

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, «Neighbor Discovery for IP version 6 (IPv6)», RFC 4861, September 2007.

[RFC4941] Narten, T., Draves, R., and S. Krishnan, «Privacy Extensions for Stateless Address Autoconfiguration in IPv6», RFC 4941, September 2007.

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

[Armitage] Armitage, G., Harrop, W., Heyde, A., Parry, L., «Greynets: Passive Detection of Unsolicited Network Scans in Small ISP and Enterprise networks», CAIA, Swinburne University of Technology, December 2008, http://caia.swin.edu.au/greynets/.

[RFC2827] Ferguson, P. and D. Senie, «Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing», BCP 38, RFC 2827, May 2000.

[RFC5101] Claise, B., «Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information», RFC 5101, January 2008.

[RFC5157] Chown, T., «IPv6 Implications for Network Scanning», RFC 5157, March 2008.

[RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, «Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements», RFC 5610, July 2009.

Адреса авторов

Fred Baker

Cisco Systems

Santa Barbara, California 93117

USA

EMail: fred@cisco.com

Warren Harrop

Centre for Advanced Internet Architectures

Swinburne University of Technology

PO Box 218

John Street, Hawthorn,

Victoria, 3122

Australia

EMail: wazz@bud.cc.swin.edu.au

Grenville Armitage

Centre for Advanced Internet Architectures

Swinburne University of Technology

PO Box 218

John Street, Hawthorn,

Victoria, 3122

Australia

EMail: garmitage@swin.edu.au

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                        C. Kaufman
Request for Comments: 5996                                     Microsoft
Obsoletes: 4306, 4718                                         P. Hoffman
Category: Standards Track                                 VPN Consortium
ISSN: 2070-1721                                                   Y. Nir
                                                             Check Point
                                                               P. Eronen
                                                             Independent
                                                          September 2010

Протокол обмена ключами в Internet версии 2 (IKEv2)

Internet Key Exchange Protocol Version 2 (IKEv2)

PDF

Аннотация

В этом документе описана версия 2 протокола IKE¹. Протокол IKE является компонентой IPsec, используемой для взаимной аутентификации, а также организации и поддержки защищённых связей (SA²). Этот документ служит обновлением и заменой RFC 4306, а также включает все разъяснения из RFC 4718.

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

Этот документ является проектом стандарта Internet (Internet Standards Track).

Документ подготовлен IETF³ и содержит согласованный взгляд сообщества IETF. Документ обсуждался публично и одобрен для публикации IESG⁴. Дополнительная информация о стандартах Internet приведена в разделе 2 RFC 5741.

Информацию о текущем состоянии данного документа, обнаруженных ошибках и способах обратной связи можно найти по ссылке http://www.rfc-editor.org/info/rfc5996.

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

Авторские права ((c) 2010) принадлежат IETF Trust и лицам, являющимся авторами документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Документ может содержать материалы из IETF Document или IETF Contribution, опубликованных или публично доступных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из таких документов, могли не предоставить IETF Trust права разрешать внесение изменений в такие документы за рамками процессов IETF Standards. Без получения соответствующего разрешения от лиц, контролирующих авторские права этот документ не может быть изменён вне рамок процесса IETF Standards, не могут также создаваться производные документы за рамками процесса IETF Standards за исключением форматирования документа для публикации или перевода с английского языка на другие языки.

1. Введение

IPsec⁵ обеспечивает конфиденциальность, целостность данных, контроль доступа и проверку подлинности источника данных для дейтаграмм IP. Эти услуги обеспечиваются за счёт поддержки состояния, разделяемого источником и потребителем дейтаграмм IP. Это состояние определяет, наряду с прочим, специфические услуги, обеспечиваемые для дейтаграмм, криптографические алгоритмы, которые будут использоваться для предоставления услуг, а также ключи, применяемые криптоалгоритмами.

Организация такого общего состояния вручную не обеспечивает должного уровня масштабирования. Следовательно, нужен протокол динамической организации таких состояний. В данном документе описывается такой протокол — IKE. Первая версия IKE была определена в RFC 2407 [DOI], 2408 [ISAKMP] и 2409 [IKEV1]. Протокол IKEv2 служит заменой всем этим RFC. Протокол IKEv2 был определён в [IKEV2] (RFC 4306) и дополнительно разъяснён в [Clarif] (RFC 4718). Данный документ служит обновлением и заменой RFC 4306 и RFC 4718. Протокол IKEv2 был заменой протокола IKE, не обеспечивающей совместимости со старой версией. В отличие от этого, данный документ не только обеспечивает разъяснение IKEv2, но и минимизирует изменения, вносимые в протокол IKE. Список существенных различий между RFC 4306 и данным документом приведён в параграфе 1.7.

IKE обеспечивает взаимную аутентификацию сторон и организует защищённую связь IKE (SA), включающую общую секретную информацию, которая может использоваться для эффективной организации защищённых связей для ESP⁶ [ESP] или AH⁷ [AH], а также задаёт набор криптоалгоритмов, который будет использоваться защищёнными связями для передачи трафика между сторонами. В этом документе термин шифронабор (suite или cryptographic suite) служит для обозначения полного множества криптографических алгоритмов, служащих для защиты SA. Инициатор предлагает один или множество шифронаборов, перечисляя поддерживаемые алгоритмы, которые могут комбинироваться в шифронаборы. IKE может также согласовывать использование сжатия IPComp⁸ [IP-COMP] для соединений с ESP или AH. Связи SA для ESP или AH, организуемые с использованием IKE SA, будут называться дочерними SA (Child SA).

Все коммуникации IKE осуществляются в формате пар сообщений «запрос-отклик», которые далее будут называться «обменом» (exchange) или «парой запрос-отклик» (request/response pair). Первый обмен сообщениями, организующий IKE SA, называется обменами IKE_SA_INIT и IKE_AUTH, последующие обмены IKE называются CREATE_CHILD_SA или INFORMATIONAL. В общем случае происходит один обмен IKE_SA_INIT и один обмен IKE_AUTH (в сумме четыре сообщения) для организации IKE SA и первой дочерней SA. В исключительных случаях каждый из этих обменов может осуществляться неоднократно. В любом случае все обмены IKE_SA_INIT должны завершаться до выполнения каких-либо других обменов, после этого должны завершаться все обмены IKE_AUTH, а далее может выполняться любое число обменов CREATE_CHILD_SA и INFORMATIONAL в произвольном порядке. В некоторых сценариях требуется только одна дочерняя SA между конечными точками IPsec и, следовательно, дополнительных обменов не происходит. Последующие обмены могут использоваться для организации дополнительных Child SA между теми же аутентифицированными парами конечных точек для выполнения функций поддержки (housekeeping).

Поток сообщений IKE всегда состоит из запросов, за которыми следуют отклики. Ответственность за обеспечение надёжной доставки лежит на запрашивающей стороне (requester). Если отклик не получен в течение заданного времени ожидания, запрашивающая сторона должна повторить запрос (или разорвать соединение).

Первый обмен в сессии IKE (IKE_SA_INIT) согласует параметры защиты IKE SA, передаёт nonce и значения Diffie-Hellman.

Второй обмен (IKE_AUTH) передаёт отождествления, обеспечивает соответствующие им секреты и организует SA для первой (зачастую, единственной) дочерней SA AH или ESP (если не возникает отказа при организации AH или ESP Child SA, когда IKE SA организуется без дочерней SA).

Типами последующих обменов являются CREATE_CHILD_SA (создание дочерней SA) и INFORMATIONAL (удаление SA, информация об ошибках и прочие функции housekeeping). На каждый запрос требуется давать отклик. Запрос INFORMATIONAL без данных (кроме пустого поля Encrypted, требуемого синтаксисом) в общем случае используется для проверки жизнеспособности. Такие обмены не могут происходить до завершения начального обмена.

В приведённых далее описаниях предполагается отсутствие ошибок. Изменение потока сообщений для случаев возникновения ошибок рассмотрено в параграфе 2.21.

1.1. Сценарии использования

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

1.1.1. Взаимодействие между защитными шлюзами в туннельном режиме

             +-+-+-+-+-+            +-+-+-+-+-+
             | Конечная| Туннель    | Конечная|
Защищённая   | точка   | Ipsec      | точка   |     Защищённая
подсеть  <-->| туннеля |<---------->| туннеля |<--> подсеть
             |         |            |         |
             +-+-+-+-+-+            +-+-+-+-+-+

Рисунок 1. Туннель между защитными шлюзами.

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

1.1.2. Взаимодействие между конечными точками в транспортном режиме

+-+-+-+-+-+-+                             +-+-+-+-+-+-+
|           |   SA в транспортном или     |           |
|Защищённая |   туннельном режиме IPsec   |Защищённая |
|точка      |<--------------------------->|точка      |
|           |                             |           |
+-+-+-+-+-+-+                             +-+-+-+-+-+-+

Рисунок 2. Взаимодействие между парой конечных точек

В этом сценарии обе конечных точки соединения IP реализуют IPsec в соответствии с требованиями к хостам [IPSECARCH]. Транспортный режим в общем случае не использует внутреннего заголовка IP. Для пакетов, защищаемых данной SA, согласуется одна пара адресов. Конечные точки могут реализовать на прикладном уровне контроль доступа на базе аутентифицированных IPsec отождествлений участников. Этот сценарий обеспечивает сквозную защиту, являющуюся одним из базовых принципов Internet в соответствии с [ARCHPRINC] и [TRANSPARENCY], а также метод снижения унаследованных проблем, связанных со сложностью сетей, как отмечено в [ARCHGUIDEPHIL]. Хотя этот сценарий не полностью применим для IPv4 в Internet, об был успешно развернут в intranet-сетях, использующих IKEv1. Этот метод получит более широкое распространение по мере перехода на IPv6 и адаптации IKEv2.

В этом сценарии возможно размещение одной или обеих защищённых конечных точек за узлом трансляции адресов (NAT⁹). В этом случае туннелируемые пакеты могут инкапсулироваться в UDP так, чтобы номера портов в заголовках UDP могли служить для идентификации конечных точек, расположенных за NAT (см. параграф 2.23).

1.1.3. Туннель между конечной точкой и защитным шлюзом

+-+-+-+-+-+-+                         +-+-+-+-+-+-+
|           |         Туннель         |           |     Защищённая
|Защищённая |         IPsec           |Оконечная  |     подсеть
|точка      |<----------------------->|точка      |<--- и/или
|           |                         |туннеля    |     Internet
+-+-+-+-+-+-+                         +-+-+-+-+-+-+

Рисунок 3. Туннель между конечной точкой и защитным шлюзом.

В этом сценарии защищённая конечная точка (обычно перемещаемый портативный компьютер) подключается к корпоративной сети через защищённый с помощью IPsec туннель. Этот туннель может использоваться для доступа к ресурсам корпоративной сети или служить для передачи всего трафика через корпоративную сеть с целью использования обеспечиваемых корпоративным межсетевым экраном услуг защиты от атак из сети Internet. В любом случае защищённой конечной точке требуется адрес IP, связанный с защитным шлюзом, чтобы возвращаемые этой точкой пакеты попадали на защитный шлюз и туннелировались назад. Этот адрес IP может задаваться статически или динамически выделяться защитным шлюзом. Для поддержки второго варианта в IKEv2 обеспечивается механизм (а именно, конфигурационные данные — configuration payload), позволяющий инициатору запросить адрес IP, принадлежащий защитному шлюзу для использования в рамках данной SA.

В этом сценарии для пакетов используется туннельный режим. Для каждого пакета от защищённой конечной точки внешний заголовок IP будет содержать IP-адрес отправителя, связанный с текущим местоположением (т. е., адрес, по которому трафик будет маршрутизироваться напрямую к конечной точке), а внутренний заголовок IP будет содержать IP-адрес отправителя, выделенный защитным шлюзом (т. е., адрес, по которому пакеты будут маршрутизироваться защитному шлюзу для туннелирования в конечную точку). В качестве внешнего адреса получателя всегда будет указываться адрес защитного шлюза, а внутренний адрес получателя будет указывать конечного адресата пакета.

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

1.1.4. Другие сценарии

Возможны и другие сценарии, являющиеся вложенными комбинациями описанных выше вариантов. Одним из значимых примеров является комбинация аспектов, описанных в параграфах 1.1.1 и 1.1.3. Подсеть может осуществлять все внешние взаимодействия через удалённый защитный шлюз, используя туннель IPsec, когда адреса подсети маршрутизируются защитному шлюзу через сеть Internet. Примером может служить домашняя сеть, виртуально являющаяся частью Internet со статическими адресами IP, хотя подключение осуществляется через ISP, выделившего один динамический адрес IP для пользовательского защитного шлюза (статические адреса IP и трансляция IPsec обеспечиваются третьей стороной, расположенной в другом месте).

1.2. Начальный обмен

Коммуникации с использованием IKE всегда начинаются с обменов IKE_SA_INIT и IKE_AUTH (в IKEv1 называются фазой 1 — Phase 1). Эти начальные обмены обычно включают 4 сообщения, хотя в некоторых сценариях число этих сообщений может быть больше. Все коммуникации с использованием IKE состоят из пар запрос-отклик. Сначала будет описан базовый обмен, а потом — возможные варианты. Первая пара сообщений (IKE_SA_INIT) согласует криптографические алгоритмы, осуществляет обмен nonce и обмен Diffie-Hellman [DH].

Вторая пара сообщений (IKE_AUTH) аутентифицирует предыдущие сообщения, обменивается отождествлениями и сертификатами, а также организует первую Child SA. Отдельные части этих сообщений шифруются и целостность их защищается с использованием ключей, организованных при обмене IKE_SA_INIT, что позволяет скрыть отождествление от просмотра и аутентифицировать все поля сообщений (в MITM-атаке¹⁰ нарушитель, который не может завершить обмен IKE_AUTH, тем не менее, способен увидеть отождествление инициатора). Информация о генерировании ключей шифрования приведена в параграфе 2.14.

Все сообщения после начального обмена защищаются криптографически с использованием алгоритмов и ключей, согласованных при обмене IKE_SA_INIT. В этих сообщениях используется синтаксис полей данных Encrypted, описанных в параграфе 3.14, которые шифруются с ключами, полученными, как описано в параграфе 2.14. Все последующие сообщения включают поле Encrypted, даже если эти сообщения указаны в документе, как «пустые». Для обменов CREATE_CHILD_SA, IKE_AUTH и INFORMATIONAL сообщение, следующее после заголовка, шифруется, а целостность сообщения вместе с заголовком защищается с помощью криптоалгоритмов, согласованных для IKE SA.

Каждое сообщение IKE содержит идентификатор Message ID, как часть фиксированного заголовка. Значения Message ID служат для сопоставления запросов и откликов, а также для идентификации повторов передачи сообщений.

В последующих описаниях поля данных (payload), содержащиеся в сообщениях, идентифицируются по именам, приведённым в таблице.

 

Обозначение	Тип данных
AUTH	Аутентификация
CERT	Сертификат
CERTREQ	Запрос сертификата
CP	Конфигурация
DD	Удаление
EAP	Расширяемая аутентификация
HDR	Заголовок IKE (не данные)
IDi	Идентификация — инициатор
IDr	Идентификация — ответчик
KE	Обмен ключами
Ni, Nr	Nonce
NN	Уведомление
SA	Защищённая связь
SK	Зашифровано и аутентифицировано
TSi	Селектор трафика — инициатор
TSr	Селектор трафика — ответчик
VV	Идентификатор производителя

 

Подробные описания всех типов данных (payload) приведены в разделе 3. Данные, являющиеся необязательными, указываются в квадратных скобках — например, [CERTREQ] показывает, что данные запроса сертификата могут включаться опционально.

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

   Инициатор                         Ответчик
   ---------------------------------------------------
   HDR, SAi1, KEi, Ni  -->

HDR содержит индексы параметров защиты (SPI¹¹), номера версий и флаги разных типов. Поле SAi1 указывает криптографические алгоритмы, которые инициатор поддерживает для IKE SA. Поле KE содержит значение Diffie-Hellman для инициатора, а Ni — nonce инициатора.

                                <--  HDR, SAr1, KEr, Nr, [CERTREQ]

Отвечающая сторона выбирает шифронабор из предложенных инициатором вариантов и указывает свой выбор в поле SAr1, завершает обмен Diffie-Hellman своим значением в поле KEr и передаёт своё значение nonce в поле Nr.

На этом этапе согласования каждая из сторон может генерировать значение SKEYSEED, из которого создаются все ключи для данной IKE SA. Последующие сообщения шифруются и целостность их защищается (за исключением заголовка). Ключи, используемые для шифрования и защиты целостности, создаются из SKEYSEED и называются SK_e (шифрование) и SK_a (аутентификация, иначе защита целостности). Подробное описание создания ключей приведено в параграфах 2.13 и 2.14. Ключи SK_e и SK_a создаются отдельно для каждого направления. В дополнение к ключам SK_e и SK_a, получаемым из значения Diffie-Hellman для защиты IKE SA, создаётся значение SK_d, используемое при создании ключевого материала для дочерних SA. Нотация SK { … } показывает, что поля зашифрованы и целостность их защищена с использованием ключей SK_e и SK_a для соответствующего направления.

   HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, Sai2, TSi, TSr}  -->

Инициатор представляет своё отождествление в поле IDi, подтверждает знание секрета, соответствующего IDi, и защищает целостность содержимого первого сообщения с использованием поля AUTH (см. параграф 2.15). Он может также передать сертификат(ы) в поле(ях) CERT и список доверенных привязок в поле(ях) CERTREQ. При включении какого-либо поля CERT первый представленный сертификат должен содержать открытый ключ, используемый для верификации поля AUTH.

Необязательное поле IDr даёт инициатору возможность задать отождествления ответчика, которые он желает получить. Это полезно в тех случаях, когда на отвечающей машине имеется множество отождествлений для одного адреса IP. Если предложенное инициатором отождествление IDr неприемлемо для ответчика, тот может использовать иное значение IDr для завершения обмена. Если инициатор не воспримет от отвечающей стороны значение IDr, отличающееся от запрошенного, он может закрыть SA после фиксации этого факта.

Селекторы трафика (TSi и TSr) рассматриваются в параграфе 2.9.

Инициатор начинает согласование Child SA, используя поле SAi2. Заключительные поля (начиная с SAi2) рассмотрены в описании обмена CREATE_CHILD_SA.

                                <--  HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr}

Ответчик представляет своё отождествление в поле IDr и может также передать один или множество сертификатов (сертификат, содержащий открытый ключ для верификации AUTH, снова должен указываться первым), аутентифицирует своё отождествление и защищает целостность второго сообщения с помощью поля AUTH и завершает согласование Child SA дополнительными полями, рассмотренными ниже при описании обмена CREATE_CHILD_SA.

Обе стороны обмена IKE_AUTH должны удостовериться, что все сигнатуры и коды MAC¹² рассчитаны корректно. Если любая из сторон использует для аутентификации общий секрет, имена в полях ID должны соответствовать ключам, используемым для генерации полей AUTH.

Поскольку инициатор передаёт своё значение Diffie-Hellman в IKE_SA_INIT, он должен предсказать группу Diffie-Hellman, которую ответчик выберет из предложенного им списка поддерживаемых групп. Если предсказание инициатора окажется ошибочным, ответчик передаст поле Notify типа INVALID_KE_PAYLOAD, показывающее выбранную группу. В этом случае инициатор должен повторить IKE_SA_INIT с корректной группой Diffie-Hellman. Инициатор должен снова предложить полный список подходящих для него шифронаборов, поскольку сообщение об отказе не было аутентифицировано. Отказ от такой практики позволит организовать активные атаки, в результате которых злоумышленник может вынудить конечные точки к выбору не самого сильного из поддерживаемых обеими сторонами шифронаборов.

Если при создании Child SA в процессе обмена IKE_AUTH возникает тот или иной сбой, связь IKE SA все равно создаётся, как обычно. Список типов сообщений Notify в обмене IKE_AUTH, которые не препятствуют организации IKE SA, включает, по крайней мере NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE и FAILED_CP_REQUIRED.

Если отказ связан с созданием IKE SA (например, возвращено сообщение об ошибке Notify с типом AUTHENTICATION_FAILED), связь IKE SA не организуется. Отметим, что, несмотря на шифрование и защиту целостности сообщений IKE_AUTH, если получивший такое сообщение Notify об ошибке партнёр ещё не аутентифицирован другой стороной (или аутентификация по той или иной причине завершилась отказом), эта информация должна восприниматься с осторожностью. Точнее говоря, в предположении, что значение MAC прошло верификацию, будет известно, что отправителем сообщения Notify является отвечающая сторона обмена IKE_SA_INIT, но отождествление отправителя проверить невозможно.

Отметим, что сообщения IKE_AUTH не содержат полей KEi/KEr и Ni/Nr. Таким образом, поля SA в обмене IKE_AUTH не могут включать Transform Type 4 (группа Diffie-Hellman) со значениями, отличными от NONE. Реализациям следует опускать всю субструктуру преобразования вместо передачи значения NONE.

1.3. Обмен CREATE_CHILD_SA

Обмен CREATE_CHILD_SA используется для организации новых Child SA и замены ключей сразу для IKE SA и Child SA. Этот обмен включает одну пару «запрос-отклик»; некоторые из функций этого обмена назывались фазой 2 (Phase 2) в обмене IKEv1. Этот обмен может инициироваться любой из сторон IKE SA после завершения начального обмена.

Ключи SA меняются путём создания новой связи SA и последующего удаления прежней связи. В этом параграфе описана первая часть замены ключей (создание новых SA), а в параграфе 2.8 рассмотрены механизмы смены ключей, включая перенос трафика из старых SA в новые и удаление старых связей SA. Эти два параграфа следует прочесть совместно для понимания всего процесса смены ключей.

Любая из конечных точек может инициировать обмен CREATE_CHILD_SA, поэтому в данном параграфе инициатором будет называться именно эта точка. Реализация может отвергать все запросы CREATE_CHILD_SA в рамках IKE SA.

Запрос CREATE_CHILD_SA может включать поле KE для дополнительного обмена Diffie-Hellman, чтобы обеспечить более высокий уровень защиты для Child SA. Ключевой материал для Child SA обеспечивает функция SK_d, организованная при создании IKE SA, значения nonce, обмен которыми осуществляется в процессе CREATE_CHILD_SA, и значение Diffie-Hellman (если поля KE включены в обмен CREATE_CHILD_SA).

Если обмен CREATE_CHILD_SA включает поле KEi, по крайней мере одна из SA должна включать группу Diffie-Hellman этого KEi. Группой Diffie-Hellman для KEi должен быть элемент группы, который инициатор предполагает приемлемым для ответчика (могут быть предложены дополнительные группы Diffie-Hellman). Если ответчик выбирает другую группу Diffie-Hellman (отличную от NONE), он должен отвергнуть запрос и указать предпочтительную группу Diffie-Hellman с помощью INVALID_KE_PAYLOAD Notify. С этим уведомлением связаны два октета данных, указывающих номер приемлемой группы Diffie-Hellman (порядок битов big endian). В случае такого отказа обмен CREATE_CHILD_SA завершается неудачей и инициатор может повторить обмен с предложением группы Diffie-Hellman и KEi из группы, которую ответчик указал в поле INVALID_KE_PAYLOAD Notify.

Ответчик передаёт уведомление NO_ADDITIONAL_SAS для индикации неприемлемости запроса CREATE_CHILD_SA по причине нежелания ответчика организовывать дополнительные дочерние SA в данной IKE SA. Такое уведомление может служить также для отказа от смены ключей IKE SA. Некоторые минимальные реализации могут воспринимать организацию только одной связи Child SA в контексте начального обмена IKE и отвергать все последующие попытки добавления.

1.3.1. Создание дочерних SA с помощью обмена CREATE_CHILD_SA

Дочерняя связь Child SA может быть создана путём передачи запроса CREATE_CHILD_SA, как показано ниже.

   Инициатор                         Ответчик
   -------------------------------------------------------------------
   HDR, SK {SA, Ni, [Kei], TSi, TSr}  -->

Инициатор отправляет предложение(я) SA в поле SA, значение nonce в поле Ni, опционально указывает значение Diffie-Hellman в поле KEi и предлагаемые селекторы трафика для предлагаемой Child SA в полях TSi и TSr.

Отклик CREATE_CHILD_SA для создания новой Child SA имеет вид

                                <--  HDR, SK {SA, Nr, [KEr], TSi, TSr}

Ответчик передаёт отклик (с тем же значением Message ID) с воспринятым предложением в поле SA и значением Diffie-Hellman в поле KEr, если в запросе было поле KEi и выбранный шифронабор включает данную группу.

Селекторы для трафика, передаваемого через эту связь SA, задаются в полях TS отклика и могут быть подмножеством предложенных инициатором Child SA.

В запрос может включаться уведомление USE_TRANSPORT_MODE, которое также включает поле SA, запрашивающее Child SA. Оно запрашивает для создаваемой Child SA использование транспортного режима вместо туннельного¹³. Если запрос принимается, отклик также должен включать уведомление типа USE_TRANSPORT_MODE. Если ответчик отвергает запрос, Child SA будет организована с использованием туннельного режима. Если это неприемлемо для инициатора, он должен удалить SA.

Уведомление ESP_TFC_PADDING_NOT_SUPPORTED показывает, что передающая конечная точка не будет воспринимать пакеты с заполнением TFC¹⁴ через согласуемую Child SA. Если ни одна из конечных точек не воспринимает заполнение TFC, это уведомление включается как в запрос, так и в отклик. Если уведомление включено только в одно из сообщений, для противоположного направления заполнение TFC может использоваться.

Для контроля фрагментации используется уведомление NON_FIRST_FRAGMENTS_ALSO. Более подробно описание контроля фрагментации приведено в [IPSECARCH]. Обе стороны должны согласовать между собой передачу отличных от первого фрагментов до того, как любая из них начнёт передавать такие фрагменты. Передача возможна лишь в тех случаях, когда уведомление NON_FIRST_FRAGMENTS_ALSO включено как в запрос SA, так и в отклик с согласием на организацию связи. Если ответчик не хочет принимать или передавать отличные от первого фрагменты, он просто не включает уведомление NON_FIRST_FRAGMENTS_ALSO в свой отклик, не отвергая создания Child SA.

В сообщение также можно включать уведомление IPCOMP_SUPPORTED, описанное в параграфе 2.22.

При неудачной попытке создания Child SA не следует разрывать организованную связь IKE SA (нет причин для отказа от выполненной работы по созданию IKE SA). Сообщения об ошибках, которые могут возникать при неудачном создании Child SA, описаны в 2.21.

1.3.2. Смена ключей IKE SA с помощью обмена CREATE_CHILD_SA

Запрос CREATE_CHILD_SA для смены ключей IKE SA имеет вид

   Инициатор                         Ответчик
   -------------------------------------------------------------------
   HDR, SK {SA, Ni, KEi} -->

Инициатор передаёт предложение(я) SA в поле SA, значение nonce в поле Ni и значение Diffie-Hellman в поле KEi (должно включаться). Новое значение SPI инициатора представляется в поле SPI элемента SA. После того, как партнёр получит запрос на смену ключей для IKE SA или передаст такой запрос, ему не следует начинать обменов CREATE_CHILD_SA для связи IKE SA, в которой будут меняться ключи.

Отклик CREATE_CHILD_SA для замены ключей IKE SA имеет вид

                                <--  HDR, SK {SA, Nr, KEr}

Ответчик передаёт (с тем же значением Message ID) принятое предложение в поле SA и значение Diffie-Hellman в поле KEr, если выбранный шифронабор включает данную группу. Новое значение SPI ответчика передаётся в поле SPI элемента SA.

Для новой связи IKE SA значение счётчика сообщений устанавливается в 0, независимо от значения счётчика в предшествующей IKE SA. Первые запросы IKE с обеих сторон новой IKE SA будут иметь Message ID=0. Нумерация старой связи IKE SA сохраняется и любые последующие запросы (например, на удаление IKE SA) будут использовать соответствующие номера. В новой IKE SA также устанавливается размер окна 1, а инициатор смены ключей становится «исходным инициатором» новой связи IKE SA.

В параграфе 2.18 смена ключей IKE SA описана более детально.

1.3.3. Смена ключей Child SA с помощью обмена CREATE_CHILD_SA

Запрос CREATE_CHILD_SA для смены ключей Child SA имеет вид

   Инициатор                         Ответчик
   -------------------------------------------------------------------
   HDR, SK {N(REKEY_SA), SA, Ni, 
      [Kei], TSi, TSr}            -->

Инициатор передаёт предложение(я) SA в поле SA, значение nonce в поле Ni, опциональное значение Diffie-Hellman в поле KEi и предлагаемые селекторы трафика для предложенной Child SA в полях TSi и TSr.

При обмене для смены ключей могут также передаваться уведомления, описанные в параграфе 1.3.1. Обычно в этом случае применяются те же самые уведомления, которые передавались в исходном обмене (например, для смены ключей SA, работающей в транспортном режиме, передаётся уведомление USE_TRANSPORT_MODE).

Если целью обмена сообщениями является замена существующей защищённой связи (SA) ESP или AH, в обмен CREATE_CHILD_SA должно включаться уведомление REKEY_SA. Связь SA, для которой будут меняться ключи, указывается полем SPI в элементе Notify (это значение SPI, которое инициатор обмена будет ожидать во входящих пакетах ESP или AH). С этим типом сообщений Notify не связано каких-либо данных. Поле Protocol ID в уведомлении REKEY_SA устанавливается в соответствии с протоколом SA, для которой меняются ключи (3 для ESP, 2 для AH).

Отклик CREATE_CHILD_SA для смены ключей Child SA имеет вид

                                <--  HDR, SK {SA, Nr, [KEr], TSi, TSr}

Ответчик передаёт (с тем же Message ID) принятое предложение в поле SA и значение Diffie-Hellman в поле KEr, если KEi было указано в запросе и выбранный шифронабор включает эту группу.

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

1.4. Обмен INFORMATIONAL

В процессе работы IKE SA у партнёров может возникнуть потребность в обмене управляющими сообщениями, связанными с ошибками или некоторыми событиями. Для решения этой задачи в IKE предусмотрен информационный обмен (INFORMATIONAL). Обмены INFORMATIONAL должны осуществляться только после завершения начальных обменов и защищаться криптографически с использованием согласованных ключей. Отметим, что некоторые информационные сообщения (не обмены), могут передаваться за пределами контекста IKE SA. В параграфе 2.21 более подробно рассматриваются сообщения об ошибках.

Управляющие сообщения, относящиеся к IKE SA, должны передаваться через данную IKE SA. Управляющие сообщения, которые относятся к Child SA, должны передаваться под защитой IKE SA, в которой создана дочерняя связь (или наследующей IKE SA, если были сменены ключи).

Сообщения в обмене INFORMATIONAL могут содержать поля Notification, Delete и Configuration. Получатель запроса INFORMATIONAL должен передать тот или иной отклик. В противном случае отправитель будет предполагать, что сообщение потерялось в сети и повторно передавать его. Откликом может служить пустое сообщение. Запросное сообщение в обмене INFORMATIONAL может не содержать никакой информации (payload). Таким способом один из участников может проверить жизнеспособность другой стороны.

Обмен INFORMATIONAL определяется следующим образом.

   Инициатор                         Ответчик
   -------------------------------------------------------------------
   HDR, SK {[N,] [D,] [CP,] ...}  -->
                                  <--  HDR, SK {[N,] [D,] [CP], ...}

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

1.4.1. Удаление SA с помощью INFORMATIONAL

Защищённые связи (SA) ESP и AH всегда существуют парами, по одной SA в каждом направлении. При разрыве SA оба члена пары должны быть закрыты (т. е., удалены). Каждая из конечных точек должна закрыть свои входящие SA и позволить другой точке закрыть соответствующую SA из каждой пары. Для удаления SA выполняется обмен INFORMATIONAL с одним или множеством полей Delete, указывающих значения SPI (какими они ожидаются во входящих пакетах) удаляемых связей SA. Получатель должен закрыть указанные SA. Отметим, что поля Delete никогда не передаются для двух сторон одной SA в одном сообщении. Если одновременно удаляется множество SA, сообщение в обмене INFORMATIONAL включает поля Delete для входящей половины каждой удаляемой пары SA.

Обычно отклики в обмене INFORMATIONAL содержат поля Delete для парных SA противоположного направления, однако имеется одно исключение. Если обе стороны некоторого множества SA независимо решили разорвать эти связи, каждая из сторон может отправить Delete и два запроса могут «столкнуться» в сети. Если узел получает запрос на удаление SA, для которых он сам уже отправил запрос на удаление, он должен удалить исходящие SA в процессе обработки запроса, а входящие — в процессе обработки отклика. В таких случаях в отклики недопустимо включать поля Delete для удалённых SA, поскольку это приведёт к дублированию удаления и может (в теории) привести к удалению не тех SA.

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

Полузакрытые соединения ESP и AH являются аномалией и узлам с поддержкой аудита, вероятно следует проверять наличие таких соединений. Отметим, что данная спецификация не задаёт период ожидания, так что каждая конечная точка вольна самостоятельно определять его. Узел может отказаться принимать данные через полузакрытые соединения, но недопустимо в одностороннем порядке закрывать их с повторным использованием SPI. Если в состояниях накопилось достаточно путаницы, узел может закрыть IKE SA, как описано выше. Нужные SA можно перестроить, организовав новую связь IKE SA.

1.5. Информационные сообщения за пределами IKE SA

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

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

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

• Пакет с запросом IKE приходит со старшей частью номера версии, значение которой превышает поддерживаемое реализацией.

В первом случае, если принимающий узел имеет активную IKE SA для IP-адреса, с которого был получен пакет, он может передать уведомление INVALID_SPI отправителю пакета через IKE SA с использованием обмена INFORMATIONAL. В поле Notification Data указывается значение SPI неприемлемого пакета. Получатель этого уведомления не сможет определить, относится SPI к AH или ESP, но это не имеет существенного значения, поскольку значения SPI для этих протоколов будут разными. При отсутствии подходящей IKE SA узел может передать информационное сообщение без криптографической защиты по IP-адресу отправителя пакета, используя UDP-порт отправителя в качестве порта назначения, если принятый пакет относился к протоколу UDP (ESP или AH с инкапсуляцией в UDP). В этом случае получателю следует использовать такое сообщение, только как намёк на возможное возникновение каких-то неполадок, поскольку такое сообщение очень просто подделать. Это сообщение не является частью обмена INFORMATIONAL и принимающему узлу недопустимо отвечать на него, поскольку такой отклик может приводить к зацикливанию обмена сообщениями. В сообщениях этого типа нет значений IKE SPI, важных для получателя, поэтому возможна установка нулевых или случайных значений (исключением является правило параграфа 3.1, которое запрещает использование нулевых значений IKE Initiator SPI). Флаг Initiator имеет значение 1, флаг Response — 0, а флаг версии устанавливается, как обычно (описания флагов приведены в параграфе 3.1).

Для второго и третьего варианта сообщения всегда передаются без криптографической защиты (за пределами IKE SA) и включают уведомление INVALID_IKE_SPI или INVALID_MAJOR_VERSION (без данных). Сообщение является откликом и, таким образом, передаётся по адресу IP и в порт, откуда поступил запрос, с теми же значениями IKE SPI, Message ID и Exchange Type, которые были в запросе. Флаг Response имеет значение 1, флаги версии устанавливаются, как обычно.

1.6. Уровни требований

Определения основных терминов (таких, как защищённая связь — SA), используемых в этом документе, можно найти в [IPSECARCH]. Следует отметить, что в некоторых случаях IKEv2 работает на основе правил [IPSECARCH], как указано в соответствующих разделах этого документа.

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

1.7. Существенные отличия от RFC 4306

Этот документ содержит разъяснения и уточнения для протокола IKEv2 [IKEV2]. Многие из разъяснений основаны на работе [Clarif]. Изменения, перечисленные в этом документе, обсуждались в рабочей группе IPsec, а после её расформирования — в списке рассылки IPsec. Документ содержит подробные разъяснения областей, которые оставались неясными в спецификации IKEv2 и, таким образом, будет полезен разработчикам решений IKEv2.

Протокол, описанный в этом документе, сохраняет значения старшего (2) и младшего (0) номера версии, которые использовались в RFC 4306. Таким образом, номер версии не отличается от RFC 4306. Предполагается, что небольшое число технических изменений, внесённых здесь, не повлияет на уже развёрнутые реализации RFC 4306.

Ссылки и рисунки в этом документе более согласованы, нежели в [IKEV2].

Разработчики IKEv2 отметили, что требования уровня следует (SHOULD) в RFC 4306 зачастую неясны и не всегда можно определить соответствие реализации этим требованиям. Отмечено также наличие требования уровня должно (MUST), не связанных со взаимодействием. В данном документе приведены дополнительные разъяснения некоторых из этих требований. Во всех случаях, когда слова следует или должно не выделены шрифтом, они имеют обычную трактовку и не относятся к требованиям взаимодействия [MUSTSHOULD].

Разработчики IKEv2 (и IKEv1) отметили, что приходится много работать с таблицами кодов параграфа 3.10.1 в RFC 4306. Это приводило к тому, что некоторые разработчики не читали остальные части документа. Значительная часть материала из указанных таблиц была перенесена в соответствующие разделы документа.

Из этого документа удалено обсуждение AH и ESP, включённое в RFC 4306 по ошибке, связанной с задержкой между публикацией RFC 4306 и RFC 4301. IKEv2 базируется в основном на спецификации RFC 4301, которая не включает связки SA (SA bundle), присутствовавшие в RFC 2401. Хотя один пакет может проходить обработку IPsec неоднократно, в каждом из таких проходов используется отдельная связь SA и проходы контролируются таблицами пересылки. В IKEv2 каждая из таких SA создаётся с использованием отдельного обмена CREATE_CHILD_SA.

Из этого документа удалено обсуждение конфигурационного атрибута INTERNAL_ADDRESS_EXPIRY, поскольку его реализация была весьма проблематичной. Реализации, соответствующие этому документу, должны игнорировать предложения с конфигурационным атрибутом типа 5 (старое значение для INTERNAL_ADDRESS_EXPIRY). Этот документ также удаляет конфигурационный атрибут INTERNAL_IP6_NBNS.

Этот документ отменяет разрешение отвергать сообщения, в котором элементы данных (payload) располагались в «некорректном» порядке; сейчас реализациям недопустимо так поступать. Это обусловлено недостаточной ясностью описания порядка следования элементов.

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

В этом документе разъяснено, когда следует передавать зашифрованные и незашифрованные уведомления с учётом текущего состояния согласования.

В этом документе приведено дополнительное рассмотрение процесса согласования комбинированных шифров.

В параграфе 1.3.2 требование «KEi следует включать» заменено требованием «должно включаться». Это привело также к изменениям в параграфе 2.18.

В параграфе 2.1 добавлен материал об использовании значений SPI и/или IP инициатора для того, чтобы отличать «полуоткрытые» IKE SA от новых запросов.

В этом документе разъяснено использование флага критичности (параграф 2.5).

В параграфе 2.8 предложение «Отметим, что при смене ключей новая Child SA может иметь селекторы трафика и алгоритмы, отличные от значений для прежней связи.» заменено на «Отметим, что при смене ключей новой Child SA не следует иметь селекторы трафика и алгоритмы, отличные от значений для прежней связи.».

Новый параграф 2.8.2 посвящён одновременной смене ключей IKE SA.

Новый параграф 2.9.2 посвящён селекторам трафика при смене ключей.¹⁵

В параграфе 2.13 добавлено ограничение, в соответствии с которым все псевдослучайные функции (PRF¹⁶), используемые с IKEv2, должны иметь ключи переменного размера. Это требование не должно повлиять на существующие реализации, поскольку неизвестно ни одной стандартизованной PRF с фиксированным размером ключа.

Параграф 2.18 требует выполнения обмена Diffie-Hellman при смене ключей IKE_SA. Теоретически, RFC 4306 разрешает выполнять обмен Diffie-Hellman опционально, но это не полезно (или не приемлемо) при смене ключей IKE_SA.

Параграф 2.21 существенно расширен в части рассмотрения различных случаев, когда требуются отклики на ошибки.

В параграфе 2.23 разъяснено, что при работе через NAT пакеты IPsec, с инкапсуляцией в UDP и без неё, должны быть понятными при получении.

Добавлен параграф 2.23.1, описывающий работу через NAT при запросе транспортного режима.

Добавлен параграф 2.25, объясняющий действия при возникновении конфликтов синхронизации во время удаления и/или смены ключей SA и определяющий два новых уведомления об ошибках (TEMPORARY_FAILURE и CHILD_SA_NOT_FOUND).

В параграф 3.6 добавлен текст: «Реализации должны поддерживать метод HTTP для поиска hash-and-URL. Поведение других URL-методов в настоящее время не задаётся и такие методы не следует применять при отсутствии спецификаций для них.».

В параграф 3.15.3 добавлена ссылка на новый документ, относящийся к настройке адресов IPv6.

Приложение C расширено и сделано более понятным.

2. Детали и варианты протокола IKE

IKE обычно принимает (слушает) и передаёт пакеты через порт UDP 500, хотя сообщения IKE могут приниматься и на порту UDP 4500 с использованием слегка отличающегося формата (см. параграф 2.23). Поскольку протокол UDP работает на основе дейтаграмм (без гарантий доставки), IKE включает восстановление при ошибках передачи, включая потерю и повтор пакетов, а также поддельные пакеты. IKE рассчитан на работу при выполнении двух минимальных требований — (1) по крайней мере один из серии повторных пакетов достигнет адресата до тайм-аута и (2) канал не заполнен поддельными и повторно используемыми пакетами до такой степени, что недостаточно пропускной способности сети или ресурсов CPU какой-либо из конечных точек. Даже при невыполнении этих минимальных требований IKE рассчитан на корректное прерывание работы (как при «обрыве» сети).

Хотя сообщения IKEv2 предполагаются короткими, они содержат структуры, для которых не установлен жёстко верхний предел размера (в частности, цифровые сертификаты), а IKEv2, сам по себе, не включает механизма фрагментации больших сообщений. Протокол IP определяет механизм для фрагментации сообщений UDP избыточного размера, но реализации существенно различаются по значениям максимального поддерживаемого размера. Кроме того, фрагментация IP открывает реализации для DoS-атак [DOSUDPPROT]. Более того, некоторые трансляторы NAT и/или межсетевые экраны могут блокировать фрагменты IP.

Все реализации IKEv2 должны обеспечивать возможность передачи, приёма и обработки сообщений IKE размером до 1280 октетов, а также следует обеспечивать возможность передачи, приёма и обработки пакетов размером до 3000 октетов. Реализации IKEv2 должны быть осведомлены о максимальном поддерживаемом размере сообщений UDP и могут укорачивать сообщения, исключая некоторые сертификаты или шифронаборы, если это позволит сохранить размер сообщения в допустимых пределах. Использование формата «Hash and URL¹⁷» вместо включения сертификатов позволяет избавиться от большинства проблем. При реализации и настройке следует принимать во внимание, что в условиях, когда поиск URL становится возможным только после организации Child SA, этот метод может не сработать.

Данные UDP во всех пакетах, содержащих сообщения IKE, переданные в порт 4500, должны начинаться с префикса из четырёх нулей (в противном случае получатель не будет знать, как их обрабатывать).

2.1. Использование таймеров повтора передачи

Все сообщения IKE существуют попарно — запрос и отклик. Организация IKE SA обычно включает два обмена. После организации IKE SA любая из сторон защищённой связи SA может в любой момент инициировать запросы, в каждый момент «на лету» может находиться множество запросов и откликов. Каждое сообщение маркируется, как запрос или отклик, и для каждого обмена одна сторона SA является инициатором (initiator), а вторая — ответчиком (responder).

Для каждой пары сообщений IKE инициатор отвечает за повтор передачи при тайм-ауте. Ответчику недопустимо передавать повторный отклик до получения повторного запроса. При получении повторного запроса ответчик должен игнорировать (не обрабатывать) его и только повторно передавать отправленный ранее отклик. Инициатор должен помнить каждый запрос, пока на него не будет получен соответствующий отклик. Ответчик должен помнить каждый отклик, пока не будет получен запрос, порядковый номер которого не меньше суммы порядкового номера отклика и размера окна (см. параграф 2.3). В целях экономии памяти ответчикам разрешается забывать переданный отклик по истечении тайм-аута в несколько минут. Если ответчик получает повторный запрос для забытого отклика, он должен игнорировать этот запрос (не пытаясь создать новый отклик на него).

IKE является протоколом с гарантией доставки — инициатор должен повторять запрос, пока на него не будет получен соответствующий отклик или не будет принято решение о возникновении сбоя в IKE SA. В последнем случае инициатор отбрасывает все состояния, связанные с IKE SA и всеми Child SA, согласованными в данной IKE SA. Повторные запросы от инициатора должны быть идентичны исходному запросу (с точностью до бита). Т. е., все биты, начиная с заголовка IKE (перед SPI инициатора IKE SA) должны совпадать; элементы до заголовка IKE (например, заголовки IP и UDP) могут отличаться в повторах.

Повторная передача запроса IKE_SA_INIT требует специальной обработки. Когда ответчик получает запрос IKE_SA_INIT, он проверяет, является пакет повторным, относящимся к имеющимся «полуоткрытым IKE SA (в этом случае повторяет передачу созданного ранее отклика), или новым (в этом случае ответчик создаёт новую IKE SA и передаёт соответствующий отклик) запросом или относится к существующей IKE SA, в которой запрос IKE_AUTH уже был получен (в этом случае ответчик игнорирует запрос).

Для дифференциации трёх описанных выше случаев недостаточно значений SPI и/или IP-адреса инициатора, поскольку два разных партнёра за одним устройством NAT могут выбрать одинаковые значения SPI для инициатора. Отказоустойчивый ответчик будет выполнять поиск IKE SA, используя весь пакет, его хэш или данные Ni.

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

2.2. Использование порядковых номеров для Message ID

Каждое сообщение IKE содержит идентификатор Message ID в своём фиксированном заголовке. Значение Message ID служит для сопоставления откликов с запросами и обнаружения повторной передачи сообщений. При повторе сообщения должно использоваться такое же значение Message ID, как в исходном сообщении.

Message ID представляет собой 32-битовое число, которое имеет нулевое значение для сообщений IKE_SA_INIT (включая повторы по причине откликов типа COOKIE и INVALID_KE_PAYLOAD) и инкрементируется для каждого последующего обмена. Таким образом, первая пара сообщений IKE_AUTH имеет Message ID = 1, вторая пара (при использовании EAP) будет иметь идентификатор 2 и т. д. Значение Message ID сбрасывается в 0 для новой IKE SA после смены ключей IKE SA.

Каждая конечная точка IKE SA поддерживает два «текущих» значения Message ID — следующее значение, которое будет использоваться для инициируемого этой точкой запроса и следующее значение, которое она ожидает увидеть в запросе с другой стороны. Эти счётчики инкрементируются по факту генерации или получения запроса. Отклики всегда содержат значения Message ID из соответствующего запроса. Это значит, что после начального обмена каждое целочисленное значение n может появляться в качестве Message ID четырёх разных сообщений — n-го запроса от исходного инициатора IKE, соответствующего отклика, n-го запроса от исходного ответчика IKE и соответствующего отклика. Если две стороны передают существенно различающиеся количества запросов, значения Message ID для каждого из направления будут сильно отличаться. Здесь не возникает какой-либо неоднозначности, поскольку флаги Initiator и Response в заголовках сообщений позволяют идентифицировать каждое из четырёх сообщений с совпадающими идентификаторами.

В этом документе термин «инициатор» указывает сторону, которая начинает описываемый обмен сообщениями. Исходным инициатором называется сторона, начавшая обмен, который привёл к организации текущей IKE SA. Иными словами, если исходный инициатор начинает смену ключей IKE SA, он остаётся исходным инициатором и для новой IKE SA.

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

2.3. Размер окна для перекрывающихся запросов

Уведомление SET_WINDOW_SIZE говорит о том, что передавшая его точка способна сохранять состояния для множества продолжающихся обменов, что позволяет получателю уведомления передавать множество запросов до получения отклика на первый запрос. Данные, связанные с уведомлением SET_WINDOW_SIZE, должны иметь размер 4 октета и указывать число (порядок битов big endian) сообщений, которые отправитель уведомления обещает сохранять. Размер окна всегда равен 1 до завершения начального обмена.

Конечная точка IKE должна ждать отклика на каждое из своих сообщений прежде, чем передать следующее сообщение, если она не получала от своего партнёра уведомления SET_WINDOW_SIZE, показывающего готовность того поддерживать состояния для множества сообщений (это позволяет повысить пропускную способность).

После организации IKE SA для повышения производительности IKE конечная точка IKE может вводить множество запросов до получения ответа на какой-либо из них — число незавершённых запросов ограничено установленным партнёром значением SET_WINDOW_SIZE. Эти запросы могут передаваться через сеть один за другим. Конечная точка IKE должна быть готова к восприятию и обработке запроса при наличии у неё запроса, обработка которого ещё не завершена, для того, чтобы в таких ситуациях не возникало блокировки. Конечная точка IKE может также воспринимать и обрабатывать множество запросов при наличии у неё запросов с незавершённой обработкой.

Для конечных точек IKE недопустимо превышение заданного партнёром размера окна при передаче запросов IKE. Иными словами, если ответчик указал размер окна N, а инициатору нужно отправить запрос X, он должен дождаться, пока будут получены отклики на все запросы вплоть до X-N. Конечная точка IKE должна сохранять копию (или обеспечивать возможность точного восстановления) каждого переданного запроса, пока не будет получен соответствующий отклик. Конечная точка IKE должна сохранять копию (или обеспечивать возможность точного восстановления) для ранее отправленных откликов в количестве не менее заявленного ею размера окна на случай потери отправленных откликов и получения от инициатора повторного запроса.

Конечная точка IKE, поддерживающая размер окна больше 1, должна быть способна обрабатывать входящие запросы без учёта порядка их доставки для повышения производительности в условиях отказов в сети или нарушения порядка доставки пакетов.

Размер окна является обычным (возможно, настраиваемым) параметром конкретной реализации и не связан с контролем насыщения (как размер окна TCP). В частности, поведение ответчика при получении уведомления SET_WINDOW_SIZE с размером окна меньше текущего значения не определено. Т. е., в настоящее время не существует способа снижения размера окна для существующих IKE SA, окно можно лишь увеличивать. При смене ключей IKE SA новая IKE SA работает с размером окна, равным 1, пока окно явно не будет увеличено новым уведомлением SET_WINDOW_SIZE.

Уведомление INVALID_MESSAGE_ID передаётся в случае получения сообщения со значением IKE Message ID, выходящим за пределы поддерживаемого окна. Такие уведомления недопустимо передавать в откликах и недопустимо подтверждать некорректный запрос. Вместо этого следует информировать другую сторону с помощью обмена INFORMATIONAL, в котором данные Notification содержат 4 октета некорректного значения Message ID. Передача такого уведомления является необязательной и скорость отправки таких уведомлений должна быть ограничена.

2.4. Синхронизация состояний и тайм-ауты соединений

Конечным точкам IKE можно в любой момент забывать все данные о состоянии IKE SA и соответствующих Child SA. Такое поведение является ожидаемым в случаях аварий или перезагрузки конечной станции. При отказе или повторной инициализации конечной точки важно, чтобы другая сторона могла детектировать это и не расходовать пропускную способность сети на передачу пакетов через разорванные связи SA (отправку в «чёрную дыру»).

Уведомление INITIAL_CONTACT говорит о том, что данная IKE SA является единственной связью IKE SA между аутентифицированными узлами, активной в данный момент. Оно может быть передано, когда IKE SA организуется после аварии и получатель может использовать эту информацию для удаления всех остальных IKE SA, имеющихся у него для этого аутентифицированного узла без ожидания тайм-аута. Передача такого уведомления недопустима для узла, который может быть реплицированным (например, для корпоративного пользователя в роуминге, которому разрешено одновременное подключение к корпоративному межсетевому экрану из двух разных точек). Если уведомление INITIAL_CONTACT передаётся, оно должно включаться в первый запрос или отклик IKE_AUTH (а не в последующие сообщения), принимающая сторона может игнорировать это уведомление в других сообщениях.

Поскольку протокол IKE разработан с учётом возможности DoS-атак из сети, конечным точкам недопустимо принимать решение об отказе другой стороны соединения на основании какой-либо маршрутной информации (например, сообщений ICMP) или сообщений IKE, приходящих без криптографической защиты (например, сообщений Notify, говорящих о неизвестных SPI). Конечная точка должна принимать решение об отказе другой стороны только после того, как продолжающиеся попытки контакта оставались безответными в течение заданного времени или после получения криптографически защищённого уведомления INITIAL_CONTACT, полученного через другую IKE SA от того же аутентифицированного узла. Конечной точке следует предполагать возможность аварии на другой стороне на основании маршрутной информации и в таких случаях инициировать запрос с целью проверки жизнеспособности другой стороны. Для такой проверки в IKE служат пустые сообщения INFORMATIONAL, на которые (как и на все прочие сообщения IKE) требуется ответ (отметим, что в контексте IKE SA «пустое» сообщение включает заголовок IKE, за которым следует поле Encrypted, не содержащее данных). Если криптографически защищённое (свежее, а не повторное) сообщение было недавно получено от другой стороны, незащищённые сообщения Notify можно игнорировать. Реализации должны ограничивать скорость, с которой могут предприниматься действия в ответ на получение незащищённых сообщений.

Число попыток и продолжительность ожидания не задаются этой спецификацией, поскольку они не оказывают влияния на взаимодействие. Предлагается повторять попытки не менее нескольких десятков раз в течение периода в несколько минут, но требования разных сред могут отличаться. В соответствии с сетевым этикетом интервалы повтора должны увеличиваться экспоненциально, чтобы избежать лавинной загрузки сети и усугубления имеющихся перегрузок. Если во всех SA, связанных с IKE SA, был только исходящий трафик, важно подтвердить жизнеспособность другой стороны во избежание передачи пакетов в «чёрную дыру». Если через IKE SA или какую-либо из дочерних SA в последнее время не было получено ни одного криптографически защищённого сообщения, следует проверить жизнеспособность другой стороны, чтобы предотвратить отправку сообщений «мёртвому» партнёру¹⁸. Получение свежего криптографически защищённого сообщения в IKE SA или любой из дочерних SA подтверждает жизненность IKE SA и всех дочерних SA. Отметим, что это вносит требования к режимам отказов конечных точек IKE. Реализация должна прекратить передачу через все SA, если тот или иной отказ не позволяет приём через все связанные SA. Если система создаёт Child SA, которые с точки зрения отказов не зависят от других дочерних связей без возможности связанной IKE SA передавать сообщение Delete, система должна согласовывать такие Child SA с использованием разных IKE SA.

Существуют DoS-атаки на инициатора IKE SA, которые можно предотвратить за счёт применения на стороне инициатора соответствующих мер. Поскольку два первых сообщения в процессе организации SA не защищены криптографически, атакующий может ответить на сообщение инициатора раньше настоящего ответчика и нарушить процесс организации соединения. Для предотвращения этого инициатор может воспринимать множественные ответы на своё первое сообщение, трактуя каждый из них, как потенциально легитимный, отвечать на них и затем отбрасывать некорректные полуоткрытые соединения после получения корректного криптографически защищённого отклика для одного из своих запросов. Когда получен корректный криптографически защищённый отклик, все последующие отклики следует игнорировать, независимо от корректности их криптозащиты.

Отметим, что при выполнении этих правил не возникает необходимости согласования времени жизни SA. Если IKE предполагает, что партнёр умер на основе повторяющегося отсутствия откликов на сообщение IKE, удаляется IKE SA и все организованные в ней Child SA.

Конечная точка IKE может в любой момент удалить неактивные Child SA для освобождения связанных с ними ресурсов. Если конечная точка IKE выбирает удаление Child SA, она должна передать данные Delete на другую сторону для уведомления об удалении. Это действует подобно тайм-ауту для IKE SA. Закрытие IKE SA неявно закрывает все связанные Child SA. В этом случае конечной точке IKE следует передать данные Delete, указывающие на закрытие IKE SA, если другая сторона больше не отвечает.

2.5. Номера версий и совместимость с новыми версиями

В этом документе описана версия 2.0 протокола IKE — значение старшего номера равно 2, младшего — 0. Данный документ является заменой [IKEV2]. Очевидно, что некоторые реализации захотят поддерживать протоколы версии 1.0 и 2.0, а в будущем и других версий.

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

Если конечная точка получает сообщение с более высоким, чем у ней, старшим номером версии, она должна отбросить сообщение, ей следует также передать неаутентифицированное сообщение Notify типа INVALID_MAJOR_VERSION, содержащее максимальный (ближайший) поддерживаемый номер версии. Если конечная точка поддерживает старший номер n, а в уведомлении указана версия m, эта точка должна поддерживать все версии от n до m. Если точка получает сообщение с поддерживаемым ею старшим номером версии, она должна отвечать с этим же номером. Чтобы предотвратить согласование парой узлов значения старшего номера меньше максимально поддерживаемого обоими узлами, в IKE имеется флаг, показывающий, что узел способен понимать более высокое значение старшего номера версии.

Таким образом, старший номер версии в заголовке IKE показывает версию, использованную для сообщения, а не максимальную поддерживаемую отправителем версию. Если инициатор способен поддерживать версии n, n+1 и n+2, а ответчик — n и n+1, они согласуют между собой версию n+1 и инициатор будет устанавливать флаг поддержки более высокой версии. Если узлы по ошибке (возможно, в результате атаки) согласуют версию n, тогда оба узла будут видеть, что партнёр может поддерживать больший номер версии и должны разорвать соединение, а потом организовать новое с версией n+1.

Отметим, что это правило не выполняется в IKEv1, поскольку для узлов этого протокола не имеет смысла говорить о возможности поддержки большего номера версии. Поэтому активный атакующий способен вынудить два узла, поддерживающих v2, к согласованию v1. Когда поддерживающий v2 узел переходит в режим v1, ему следует отмечать это в системном журнале.

Для совместимости с будущими версиями значения всех резервных полей (RESERVED) должны устанавливаться в 0 реализациями версии 2.0, а на приёме такие реализации должны игнорировать содержимое этих полей («будьте консервативны при передаче и либеральны на приёме» [IP]). В этом случае будущие версии протокола смогут использовать резервные поля, заведомо зная, что их содержимое будет игнорироваться не понимающими данное поле версиями. Аналогично, типы данных (payload type), которые не определены, являются резервом на будущее, реализации версии, где эти типы ещё не определены, должны пропускать такие данные, игнорируя их содержимое.

IKEv2 добавляет флаг критичности (critical) в каждый заголовок данных (payload) для совместимости с будущими версиями. Если для нераспознанных данных установлен флаг критичности, сообщение должно быть отвергнуто, а отклик на запрос IKE с такими данными должен включать поле Notify типа UNSUPPORTED_CRITICAL_PAYLOAD, указывающее на наличие неподдерживаемого типа данных. Если флаг критичности отсутствует для неподдерживаемого типа данных, эти данные должны игнорироваться. В элементах данных, передаваемых в откликах IKE, устанавливать флаг критичности недопустимо. Отметим, что флаг критичности применим только к типу поля данных, но не к его содержимому. Если тип данных распознан, но поле содержит что-либо непонятное (например, неизвестное преобразование в элементах данных SA или неизвестный тип уведомления в поле Notify), флаг критичности игнорируется.

Хотя новые типы полей, которые могут быть добавлены в новых версиях, могут чередоваться с полями определённых здесь типов, реализациям следует передавать определённые в этой спецификации данные в порядке, показанном на рисунках разделов 1 и 2. Реализациям недопустимо отвергать, как некорректные, сообщения с иным порядком полей.

2.6. IKE SA SPI и уведомления Cookie

Два первых 8-октетных поля в заголовке пакетов IKE, называемые IKE SPI, служат в качестве идентификаторов соединения в начале пакетов IKE. Каждая конечная точка выбирает одно из двух значений SPI и должна выбрать то, которое будет уникальным идентификатором IKE SA. Нулевое значение SPI имеет специальный смысл — оно показывает, что значение SPI удалённой стороны ещё не известно отправителю.

Входящие пакеты IKE отображаются на IKE SA только по значениям SPI, а не по значениям (например) IP-адресов отправителей.

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

Для первого сообщения начального обмена IKE инициатор ещё не знает SPI отвечающей стороны и будет, следовательно, устанавливать для поля значение 0. Когда обмен IKE_SA_INIT не завершается созданием IKE SA по причине INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN или COOKIE (см. параграф 2.6), значение SPI ответчика будет нулевым даже в отклике. Однако, если ответчик передаёт отличное от нуля значение SPI, инициатору не следует отвергать сообщение только по этой причине.

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

Когда отвечающая сторона детектирует многочисленные полуоткрытые IKE SA, ей следует отвечать на запросы IKE_SA_INIT откликами с уведомлением COOKIE. Размер данных, связанных с таким уведомлением, должен составлять от 1 до 64 октетов (включительно), а генерация значения описана ниже. Если отклик IKE_SA_INIT включает уведомление COOKIE, инициатор должен повторить запрос IKE_SA_INIT, включив в него уведомление COOKIE, содержащее полученные данные в качестве первого элемента данных и сохранив все прочие элементы неизменными. Начальный обмен в таком случае будет иметь вид

   Инициатор                         Ответчик
   -------------------------------------------------------------------
   HDR(A,0), SAi1, KEi, Ni      -->
                                <--  HDR(A,0), N(COOKIE)
   HDR(A,0), N(COOKIE), 
     Sai1, KEi, Ni              -->
                                <--  HDR(A,B), SAr1, Ker, Nr, [CERTREQ]
   HDR(A,B), SK {IDi, [CERT,] 
     [CERTREQ,] [IDr,] AUTH, 
     SAi2, TSi, TSr}            -->
                                <--  HDR(A,B), SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr}

Два первых сообщения не оказывают никакого влияния на состояние инициатора и ответчика, за исключением того, что осуществляется обмен cookie. В частности, порядковые номера 4 первых сообщений будут иметь нулевые значения, а порядковые номера в двух последних сообщениях будут иметь значение 1. В приведённой схеме обмена сообщениями A — значение SPI, выделенное инициатором, а B — значение SPI, выделенное ответчиком.

Реализация IKE может организовать генерацию значений cookie ответчиком таким образом, что это не будет требовать каких-либо сохранённых состояний для проверки приемлемости cookie при получении второго сообщения IKE_SA_INIT. Алгоритмы и синтаксис генерации cookie не оказывают влияния на взаимодействие реализаций и поэтому не рассматриваются здесь. Ниже приводится пример организации конечной точкой частичной защиты от DoS-атак на основе применения cookie.

Хорошим способом является установка ответчиком значения cookie по следующему алгоритму:

   Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)

где <secret> — случайным образом сгенерированное секретное значение, известное только ответчику и периодически сменяемое, | указывает на конкатенацию. Значение <VersionIDofSecret> следует менять при каждой смене значения <secret>. Значение cookie может быть рассчитано заново при получении повторного запроса IKE_SA_INIT для сравнения полученного значения с расчётным. Если значения соответствуют, ответчик знает, что значение cookie было сгенерировано после смены значения <secret>, а значение IPi должно совпадать с адресом отправителя в первом запросе. Включение SPIi в создание cookie позволяет организовать множество разных значений для множества параллельных IKE SA (предполагается, что инициатор выбирает уникальные SPIi’). Включение Ni в хэш гарантирует, что атакующий, который видел только сообщение 2, не сможет создать корректное сообщение 3. Встраивание в хэш значения SPIi не позволяет атакующему взять значение cookie от другой стороны и инициировать множество обменов IKE_SA_INIT с разными значениями SPI инициатора (и, возможно, разными номерами портов), которые ответчик мог бы принять за множество узлов, расположенных за одним устройством NAT.

Если в процессе организации соединения значение <secret> было изменено, запрос IKE_SA_INIT может быть возвращён с отличным от текущего значением <VersionIDofSecret>. Ответчик в таком случае может отвергнуть сообщение, отправив новый отклик с другим значением cookie или может сохранять старое значение <secret> в течение некоторого времени после замены и воспринимать значения cookie, созданные с использованием старого секрета. Ответчику не следует воспринимать значения cookie в течение неопределённо долгого периода после замены значения <secret>, поскольку это может ослабить защиту от DoS-атак. Ответчику следует достаточно часто менять значение <secret>, особенно во время атак.

Когда одна сторона получает запрос IKE_SA_INIT со значением cookie, не соответствующим ожидаемому, она должна игнорировать это значение и обрабатывать сообщение, как при отсутствии cookie (обычно это заключается в передаче отклика с новым значением cookie). Инициаторам следует ограничивать число обменов cookie, которые они предпринимают (возможно, путём экспоненциального роста интервала). Атакующий может подделать множество откликов с cookie на сообщение инициатора IKE_SA_INIT и каждое такое сообщение с поддельным cookie будет вызывать передачу двух откликов — один от инициатора к ответчику (который будет отвергать cookie), а второй от ответчика к инициатору с корректным значением cookie.

Следует отметить, что термин cookie появился в документе Karn и Simpson [PHOTURIS] при описании управления ключами в IPsec и получил признание. Фиксированные заголовки протокола ISAKMP¹⁹ [ISAKMP] включают два 8-октетных поля cookie и этот синтаксис используется в протоколах IKEv1 и IKEv2, хотя в IKEv2 эти поля названы IKE SPI, а для cookie выделено отдельное поле в элементе данных Notify.

2.6.1. Взаимодействие COOKIE и INVALID_KE_PAYLOAD

Существуют две основных причины повтора инициатором обмена IKE_SA_INIT — запрос ответчиком cookie и желание ответчика использовать не ту группу Diffie-Hellman, которая была включена в данные KEi. Если инициатор получает от ответчика cookie, он должен принять решение о включении значения cookie только в ближайший повтор IKE_SA_INIT или во все последующие повторы.

Если инициатор включает cookie только в один повтор, в некоторых случаях может потребоваться один дополнительный круговой обход. Это требуется также в тех случаях, когда инициатор включает cookie во все повторы, но ответчик этого не поддерживает. Например, если ответчик включает данные KEi в расчёт cookie, он будет отвергать запрос, передавая новое значение cookie.

Если оба партнёра включают cookie во все повторы, обмен слегка сокращается, как показано на рисунке.

Инициатор                         Ответчик
-----------------------------------------------------------
HDR(A,0), SAi1, KEi, Ni -->
                        <-- HDR(A,0), N(COOKIE)
HDR(A,0), N(COOKIE), 
   SAi1, KEi, Ni        -->
                        <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
HDR(A,0), N(COOKIE), 
   SAi1, KEi', Ni       -->
                        <-- HDR(A,B), SAr1, KEr, Nr

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

2.7. Согласование криптоалгоритма

Элемент данных типа SA показывают предложение для набора вариантов протоколов IPsec (IKE, ESP, AH) в SA, а также криптоалгоритмов, связанных с каждым протоколом.

Элемент данных SA содержит одно или несколько предложений, каждое из которых включает один протокол. Каждый протокол содержит одно или множество преобразований и каждое из них задаёт криптографический алгоритм. Преобразование может иметь атрибуты (они требуются только в тех случаях, когда Transform ID не полностью задаёт криптоалгоритм).

Такая иерархическая структура была разработана для повышения эффективности кодирования предложений для шифронаборов, когда число поддерживаемых наборов велико, поскольку приемлемо множество значений для многочисленных преобразований. Ответчик должен выбрать один набор, который может быть подмножеством предложенного в SA с учётом приведённых ниже правил.

Каждое предложение содержит один протокол. Если предложение принимается, поле SA в отклике должно содержать этот же протокол. Ответчик должен принять одно предложение или отвергнуть все, возвратив сообщение об ошибке. Ошибка указывается типом уведомления NO_PROPOSAL_CHOSEN.

Каждое предложение протокола IPsec содержит не менее одного преобразования, а каждое преобразование содержит тип — Transform Type. Принятый шифронабор должен содержать единственное преобразование каждого типа, включённого в предложение. Например, если предложение ESP включает преобразования ENCR_3DES, ENCR_AES с размером ключа 128, ENCR_AES с размером ключа 256, AUTH_HMAC_MD5 и AUTH_HMAC_SHA, принятый набор должен содержать одно из преобразований ENCR_ и одно из AUTH_. Таким образом, возможны 6 комбинаций.

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

2.8. Смена ключей

Защищённые связи (SA) IKE, ESP и AH используют секретные ключи, которые следует применять только в течение ограниченного срока для защиты ограниченного объёма данных. Это ограничивает время жизни связей SA. Когда срок существования защищённой связи заканчивается, дальнейшее использование SA недопустимо. При наличии потребности может быть организована новая связь SA. Организация SA заново при завершении времени жизни называется сменой ключей (rekeying).

В интересах минимальных реализаций IPsec возможность смены ключей SA без перезапуска всей IKE SA не является обязательной. Реализация может отвергать все запросы CREATE_CHILD_SA в рамках IKE SA. Если срок жизни SA завершился или близок к завершению и попытка смены ключей с помощью описанных здесь механизмов не удаётся, реализация должна закрыть IKE SA и все дочерние связи (Child SA), а после этого может организовать новые защищённые связи. Реализации могут пожелать замены ключей SA в процессе работы, поскольку это повышает производительность и вероятно снижает число пакетов, теряемых во время смены ключей.

Для смены ключей Child SA в существующей IKE SA создаётся новая, эквивалентная связь SA (см. параграф 2.17 ниже), а после её организации старая связь удаляется. Отметим, что при смене ключей новой Child SA не следует иметь селекторов трафика и алгоритмов, отличных от значений для прежней связи.

Для смены ключей IKE SA организуется новая, эквивалентная IKE SA (см. параграф 2.18 ниже) с тем же партнёром путём выполнения обмена CREATE_CHILD_SA в рамках существующей IKE SA. Новая связь IKE SA наследует все дочерние связи (Child SA) исходной IKE SA и применяется для всех управляющих сообщений, требуемых для поддержки этих Child SA. После создания новой IKE SA инициатор удаляет старую IKE SA, при этом данные Delete для удаления связи должны быть последним запросом, передаваемым через старую IKE SA.

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

Различие между IKEv1 и IKEv2 заключается в том, что время жизни SA в IKEv1 согласовывалось. В IKEv2 каждая сторона SA отвечает за реализацию своей политики ограничения времени жизни SA и смену ключей SA при необходимости. Если стороны имеют разные правила для времени жизни, смена ключей всегда будет инициироваться стороной с более коротким сроком существования защищённых связей. Если SA была неактивна достаточно долго и если конечная точка не инициировала SA при отсутствии трафика, эта конечная точка может предпочесть закрытие SA (вместо смены ключей) при завершении срока жизни. Это может происходить также в тех случаях, когда после предшествующей смены ключей трафика через SA не было совсем.

Отметим, что в IKEv2 осознанно разрешена организация параллельных SA с общими селекторами трафика между парой конечных точек. Одна из целей этого заключается в поддержке дифференциации качества обслуживания (QoS²⁰) между SA (см. [DIFFSERVFIELD], [DIFFSERVARCH] и параграф 4.1 в [DIFFTUNNEL]). Следовательно, в отличие от IKEv1, комбинация конечных точек и селекторов трафика может не обеспечивать уникальной идентификации SA, организованных между этими точками, поэтому здесь не следует применять удаление SA при смене ключей на основании совпадения селекторов трафика, как это принято в IKEv1.

Возможны интервалы времени (в частности, при наличии потерь пакетов), когда стороны не могут договориться о состоянии SA. Ответчик на CREATE_CHILD_SA должен быть готов к восприятию сообщений в SA до передачи своего отклика на запрос создания — здесь не возникает двусмысленностей для инициатора. Инициатор может начать передачу в SA, как только он обработает отклик. Однако инициатор не может принимать что-либо в новой SA, пока он не получит и не обработает отклик на свой запрос CREATE_CHILD_SA. В таком случая, как ответчик узнает о возможности передачи через созданную SA?

С точки зрения технической корректности и взаимодействия ответчик может начать передачу в SA сразу же после отправки отклика на запрос CREATE_CHILD_SA. В некоторых случаях, однако, это может приводить к ненужному отбрасыванию пакетов, поэтому реализация может задержать такую передачу.

Ответчик может быть уверен в том, что инициатор готов к приёму сообщений через SA, если (1) если он получил криптографически защищённое сообщение на другой половине пары SA или (2) новая SA организована в результате смены ключей существующей SA и был получен запрос IKE на закрытие заменяемой SA. При смене ключей SA ответчик продолжает передавать трафик в старую SA, пока не произойдёт одно из указанных выше событий. При создании новой SA ответчик может отложить передачу сообщений через неё, пока не получит сообщение через неё или не истечёт время ожидания. Если инициатор получает сообщение из SA, для которой он ещё не принял отклика на свой запрос CREATE_CHILD_SA, он интерпретирует это, как результат потери пакета и повторяет запрос CREATE_CHILD_SA. Инициатор может передать «холостое» (dummy) сообщение ESP в новую ESP SA, если в его очереди нет сообщений для передачи — это позволит ответчику убедиться в том, что инициатор готов к приёму сообщений.

2.8.1. Одновременная смена ключей дочерних SA

Если на обеих сторонах используются общие правила для времени жизни, возможно одновременное инициирование смены ключей обеими сторонами (это будет приводить к созданию избыточных SA). Для снижения вероятности таких событий в отправку запросов на смену ключей следует вводить варьируемые задержки (задержка на случайное время с момента обнаружения необходимости смены ключей).

Такая форма смены ключей может временно приводить к наличию множества похожих SA между парой узлов. При наличии двух SA, имеющих право получать пакеты, узел должен воспринимать пакеты через любую из них. Если в результате конфликта создаются избыточные SA, связь SA, созданную с меньшим из четырёх значений nonce, использованных в двух обменах, следует закрыть со стороны создавшей эту связь конечной точки. Значения nonce сравниваются пооктетно (вместо сравнения их, как больших целых чисел). Иными словами, сравниваются сначала первые октеты, а при их равенстве вторые и т. д. Если достигнут последний октет одного из значений nonce, это значение будет наименьшим. Узлу, инициировавшему SA, для которой были сменены ключи, следует удалить старую SA после организации новой связи.

Ниже показано влияние описанного на реализации. Предположим, что хосты A и B имеют пару Child SA с SPI (SPIa1,SPIb1) и обе стороны одновременно начинают смену ключей.

   Хост A                            Хост B
   -------------------------------------------------------------------
   передача req1: N(REKEY_SA,SPIa1),
       SA(..,SPIa2,..),Ni1,..   -->
                                <--  передача req2: N(REKEY_SA,SPIb1), SA(..,SPIb2,..),Ni2
   приём req2                   <--

В этот момент A узнает о начавшейся одновременной смене ключей. Однако он ещё не знает, который из обменов будет иметь наименьшее значение nonce, поэтому хост просто зафиксирует этот факт и будет отвечать, как обычно.

   передача resp2: SA(..,SPIa3,..), 
                        Nr1,..  -->
                                -->  приём req1

В этот момент B также узнает об одновременной смене ключей и отвечает, как обычно.

                               <--  передача resp1: SA(..,SPIb3,..), Nr2,..
   приём resp1                 <--
                               -->  приём resp2

В этот момент между хостами будет три Child SA (одна старая и две новых). A и B могут сейчас сравнить значения nonce. Предположим, что меньшим оказалось значение Nr1 из сообщения resp2 — в этом случае B (отправитель req2) удаляет избыточную новую SA, а хост A (инициатор организации SA, для которой менялись ключи) удаляет старую дочернюю связь.

   передача req3: D(SPIa1)  -->
                            <--  передача req4: D(SPIb2)
                            -->  приём req3
                            <--  передача resp3: D(SPIb1)
   приём req4               <--
   передача resp4: D(SPIa3) -->

Смена ключей на этом завершается.

Однако возможна иная последовательность событий, если возникнет потеря пакетов в сети, приводящая к повторам передачи. Смена ключей начинается, как обычно, но первый пакет от хоста A (req1) теряется.

   Хост A                            Хост B
   -------------------------------------------------------------------
   передача req1: N(REKEY_SA,SPIa1), SA(..,SPIa2,..),
       Ni1,..                   -->  (потеряно)
                                <--  передача req2: N(REKEY_SA,SPIb1), SA(..,SPIb2,..),Ni2
   приём req2                   <--
   передача resp2: SA(..,SPIa3,..), 
       Nr1,..                   -->
                                -->  приём resp2
                                <--  передача req3: D(SPIb1)
   приём req3                   <--
   передача resp3: D(SPIa1)     -->
                                -->  recv resp3

С точки зрения хоста B смена ключей завершена, но, поскольку этот хост ещё не получил пакет req1 от хоста A, он ещё не знает об одновременной смене ключей. Однако A будет повторять передачу сообщения и оно придёт хосту B.

   повтор req1                  -->
                                -->  приём req1

Для B это выглядит, как попытка A сменить ключи для SA, которой уже не существует, поэтому B будет отвечать на запрос сообщением о некритической ошибке (например, CHILD_SA_NOT_FOUND).

                                <--  передача resp1: N(CHILD_SA_NOT_FOUND)
   приём resp1                  <--

Когда A получит это сообщение, он уже будет знать об одновременной смене ключей и может просто игнорировать его.

2.8.2. Одновременная смена ключей IKE SA

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

Ситуация, когда обе стороны видят одновременную замену ключей, обрабатывается так же, как для Child SA. После обмена CREATE_CHILD_SA между хостами A и B будет существовать три IKE SA — старая IKE SA и две новых IKE SA. Новую IKE SA с меньшим значением nonce следует удалить создавшему её узлу, а оставшаяся новая IKE SA должна стать родителем всех Child SA.

Хост A                        Хост B
-------------------------------------------------------------------
передача req1:
   SA(..,SPIa1,..),Ni1,.. -->
                          <-- передача req2: SA(..,SPIb1,..),Ni2,..
                          --> приём req1
                          <-- передача resp1: SA(..,SPIb2,..),Nr2,..
приём resp1               <--
передача req3: D()        -->
                          --> приём req3

В дополнение к обычной ситуации одновременной замены ключей существует специальный случай, когда один из партнёров заканчивает процесс смены ключей до того, как узнает о смене ключей другой стороной. Если одновременная смена ключей замечена только одним из партнёров, избыточные SA не создаются. В этом случае, когда не заметивший одновременной смены ключей партнёр получает запрос на смену ключей IKE SA, для которой он уже сменил ключи, ему следует возвращать сообщение TEMPORARY_FAILURE, поскольку это IKE SA, которую он в настоящее время пытается закрыть (независимо от того, успел ли он передать уведомление о закрытии SA). Если партнёр, заметивший одновременную смену ключей, получает от другой стороны запрос на удаление старой IKE SA, он понимает, что партнёр не обнаружил одновременной смены и может забыть о своей попытке смены ключей.

В этот момент хост B видит запрос на закрытие IKE_SA. Тут не требуется ничего, сверх обычного отклика. Однако в этот момент хосту B следует прекратить повтор передачи req2, поскольку с момента получения хостом A отклика resp3 он будет удалять все состояния, связанные со старой IKE_SA и не сможет отвечать на эти запросы.

                                                     <-- передача resp3: ()

Уведомление TEMPORARY_FAILURE не было включено в RFC 4306 и поддержка уведомлений TEMPORARY_FAILURE не согласуется. Таким образом, узлы, реализующие RFC 4306, но не соответствующие этому документу, могут получать эти уведомления. В таких случаях, узлы будут трактовать эти уведомления, как неизвестные сообщения об ошибках и прекращать обмен. Поскольку другой партнёр уже завершил смену ключей, это прекращение не будет оказывать какого-либо влияния.

2.8.3. Замена ключей IKE SA по сравнению с повторной аутентификацией

Смена ключей IKE SA и повторная аутентификация концептуально различаются в IKEv2. При смене ключей IKE SA организуются новые ключи для IKE SA и сбрасываются счётчики Message ID, но не выполняется повторной аутентификации сторон (элементы AUTH и EAP не используются).

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

IKEv2 не осуществляет какой-либо специальной поддержки для повторной аутентификации, которая выполняется новой IKE SA с нуля (с использованием обменов IKE_SA_INIT/IKE_AUTH без каких-либо элементов REKEY_SA Notify), создания новых Child SA в созданной IKE SA (без элементов REKEY_SA Notify) и удаления имеющейся IKE SA (при этом удаляются и старые дочерние связи — Child SA).

Это означает, что при повторной аутентификации также создаются новые ключи для IKE SA и Child SA. Следовательно, если менять ключи чаще, чем проводить повторную аутентификацию, ситуации, когда «срок аутентификации» короче времени жизни ключей, не возникают.

Хотя создание новой IKE SA может быть инициировано любой из сторон (инициатором или ответчиком исходной IKE SA), использование элементов EAP и/или Configuration на практике означает, что повторная аутентификация будет инициирована той же стороной, что и для исходной IKE SA. IKEv2 в настоящее время не позволяет ответчику в данном случае запросить повторную аутентификацию, однако существуют расширения, добавляющие такую функциональность [REAUTH].

2.9. Согласование селекторов трафика

Когда соответствующая RFC 4301 подсистема IPsec получает пакет IP, который соответствует селектору protect в базе данных SPD²¹, подсистема защищает такой пакет с помощью IPsec. Если SA ещё не существует, организация такой связи является задачей IKE. Поддержка SPD системы выходит за пределы IKE, хотя некоторые реализации могут обновлять SPD при работающем IKE (пример сценария приведён в параграфе 1.1.3).

Элементы данных TS²² позволяют конечным точкам обмениваться с партнёрами некоторой информацией из своей SPD. Эти данные должны передаваться в IKE из SPD (например, PF_KEY API [PFKEY] использует сообщения SADB_ACQUIRE). Элементы TS задают критерии отбора для пакетов, которые будут пересылаться через вновь созданную SA. В некоторых сценариях это может служить проверкой согласованности SPD, а в других случаях приводить к динамическому обновлению SPD.

В каждом сообщении обмена, создающего пару Child SA, присутствуют два элемента TS и каждый из них содержит один или множество селекторов трафика. Каждый селектор включает диапазон адресов (IPv4 или IPv6), диапазон портов и идентификатор протокола IP.

Первую пару селекторов трафика обозначают TSi²³, а вторую — TSr²⁴. TSi задаёт адрес отправителя трафика, пересылаемого от инициатора пары Child SA (или получателя трафика, пересылаемого ему). TSr указывает адрес получателя трафика, пересылаемого ответчику пары Child SA (или адрес отправителя трафика, пересылаемого от него). Например, если исходный инициатор запрашивает создание пары Child SA и хочет туннелировать весь трафик из подсети 198.51.100.* на стороне инициатора в подсеть 192.0.2.* на стороне ответчика, инициатор будет включать один селектор трафика в каждое поле TS. TSi будет задавать диапазон адресов (198.51.100.0 — 198.51.100.255), а TSr — диапазон (192.0.2.0 — 192.0.2.255). В предположении, что это предложение приемлемо для ответчика, он будет передавать обратно идентичные элементы TS.

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

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

Чтобы обеспечить ответчику возможность выбора подходящего диапазона в том случае, когда инициатор запрашивает создание SA по причине наличия пакета данных, инициатору следует включить в качестве первого селектора трафика в каждое поле TSi и TSr очень специфичный селектор трафика, включающий адреса из вызвавшего запрос пакета. В нашем примере инициатор будет включать в TSi два селектора трафика — первый с диапазоном адресов (198.51.100.43 — 198.51.100.43) , номером порта и протоколом IP из пакета, а второй с диапазоном (198.51.100.0 — 198.51.100.255) для всех портов и протоколов IP. Инициатор будет просто включать в TSr два селектора трафика. Если инициатор создаёт пару Child SA не в результате получения пакета, а, например, при старте, здесь может не оказаться специфичных адресов, которые инициатор предпочтёт для туннеля. В таком случае первые значения в TSi и TSr могут быть диапазонами, а не конкретными значениями.

Ответчик сужает диапазон следующим образом:

• если политика ответчика не позволяет ему принимать никакую часть предложенных селекторов, он отвечает сообщением TS_UNACCEPTABLE Notify;

• если политика ответчика позволяет принимать весь трафик, покрываемый селекторами TSi и TSr, сужения диапазона не требуется и ответчик может вернуть те же значения TSi и TSr;

• если политика ответчика позволяет принимать первый селектор TSi и TSr, ответчик должен сузить диапазон предложенных селекторов до подмножества, включающего первый выбор инициатора; в приведённом выше примере ответчик может возвратить TSi с адресами (198.51.100.43 — 198.51.100.43) для всех портов и протоколов IP;

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

После сужения диапазона может возникнуть несколько приемлемых подмножеств, объединение которых не приемлемо. В таких случаях ответчик выбирает одно из приемлемых подмножеств и может включить в отклик уведомление ADDITIONAL_TS_POSSIBLE, которое информирует о том, что ответчик сузил диапазон полученных селекторов, но приемлемы и другие селекторы в отдельных SA. С этим типом сообщений Notify не связано каких-либо данных. Такие ситуации могут возникать при разной конфигурации инициатора и ответчика. Если обе стороны согласны с гранулярностью туннелей, инициатор никогда не будет запрашивать более широкий туннель, нежели ответчик готов воспринимать.

Вполне возможно, что политика ответчика будет включать множество небольших диапазонов, охватываемых селектором трафика инициатора, но в соответствии с политикой для каждого из этих диапазонов трафик следует передавать через разные SA. В использованном выше примере политика ответчика может требовать организации для каждой пары адресов отдельно согласованной связи Child SA. Если инициатор генерирует запрос не на основе имеющегося для передачи пакета, а (например) при старте, у него не будет достаточно специфичных первых селекторов трафика, помогающих ответчику выбрать корректный диапазон. В этом случае у ответчика не будет возможности определить, какую пару адресов следует включить в этот туннель и он должен будет делать предположение или отвергнет запрос с сообщением SINGLE_PAIR_REQUIRED Notify.

Сообщение об ошибке SINGLE_PAIR_REQUIRED показывает, что запрос CREATE_CHILD_SA не воспринят, поскольку его отправитель желает воспринимать только селекторы трафика, задающие одну пару адресов. Предполагается, что запрашивающая сторона ответит на уведомление запросом SA только для конкретного трафика, который она пытается переслать.

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

2.9.1. Селекторы трафика, нарушающие свою политику

При создании новой SA инициатор должен избегать предложения селекторов трафика, нарушающих его собственную политику. При нарушении этого правила может отбрасываться допустимый трафик. Если используются декоррелированные правила из [IPSECARCH], таких нарушений не может возникать.

Это лучше всего проиллюстрировать на примере. Предположим, что хост A имеет политику, в соответствии с которой трафик по адресу 198.51.100.66 передаётся через хост B с использованием шифрования AES, а трафик для остальных адресов сети 198.51.100.0/24 также передаётся через хост B, но с шифрованием 3DES. Предположим также, что B воспринимает любые комбинации AES и 3DES.

Если хост A предлагает SA, которая использует 3DES и включает TSr с блоком адресов (198.51.100.0-198.51.100.255), это будет приемлемо для хоста B. Хост B может также использовать эту SA для передачи трафика с адреса 198.51.100.66, но такие пакеты будут отбрасываться хостом A, поскольку он требует использования для них шифрования AES. Даже если хост A создаст новую SA только для 198.51.100.66 (использующего AES), хост B может свободно продолжать использование первой SA для этого трафика. В такой ситуации, предлагая SA хосту A, следует соблюдать свою политику и предлагать TSr, содержащий ((198.51.100.0-198.51.100.65),(198.51.100.67-198.51.100.255)) вместо единого блока.

В общем случае, если (1) инициатор делает предложение «для трафика X (TSi/TSr), создать SA», (2) для некоторого подмножества X’ инициатор на деле не будет принимать X’ через SA и (3) инициатор желает принимать трафик X’ через другую связь SA’ (!=SA), корректный трафик может необоснованно отбрасываться, поскольку ответчик может использовать для трафика X’ как SA, так и SA’ .

2.10. Nonce

Каждое сообщение IKE_SA_INIT содержит значение nonce, которое используется в качестве аргумента криптографической функции. Запросы CREATE_CHILD_SA и отклики CREATE_CHILD_SA также содержат nonce, которые служат для добавления «свежести» методам создания ключей, используемым при генерации ключей для Child SA, а также для обеспечения создания действительно псевдослучайных битов из ключа Diffie-Hellman. Значения nonce, используемые в IKEv2, должны выбираться случайным образом, должны быть размером не менее 128 битов, а также должны быть по размеру не менее половины размера результата согласованной псевдослучайной функции (PRF). Однако инициатор выбирает nonce до того, как узнает результат согласования. По этой причине размер nonce должен быть достаточно велик для всех предлагаемых функция PRF. Если для ключей и nonce используется общий источник случайных чисел, следует принимать меры против компрометации ключей при использовании nonce.

2.11. Адреса и номера портов

IKE работает по протоколу UDP через порты 500 и 4500, неявно устанавливая связь ESP и AH с теми же адресами IP, которые используются IKE. Однако адреса и номера портов во внешних заголовках не защищаются криптографически, а протокол IKE рассчитан также на работу через системы трансляции адресов (NAT²⁵). Реализации должны воспринимать входящие запросы, если номер порта источника отличается от 500 и 4500, а также должны отвечать по адресам и номерам портов, с которых были получены запросы. Реализации должны указывать адрес и номер порта, по которым были получены запросы, в полях адреса и номера порта отправителя передаваемых откликов. Функции IKE идентичны для протоколов IPv4 и IPv6.

2.12. Многократное использование показателей Diffie-Hellman

IKE генерирует ключевой материал, используя эфемерный обмен Diffie-Hellman для достижения преимуществ «совершенной защиты²⁶». Это означает, что после разрыва соединения и забывания соответствующих ключей даже тот, кто сумел записать все данные из соединения и получить доступ ко всем долгосрочным ключам обеих конечных точек, не сможет восстановить ключи, использованные для защиты соединения без перебора всех ключей в пространстве ключей сеанса (brute force search).

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

Поскольку расчёт значений Diffie-Hellman требует значительных вычислительных ресурсов, конечная точка может принять решение о неоднократном использовании этих значений DH при организации последующих соединений. Для таких действий имеется несколько разумных стратегий. Конечная точка может менять значения DH периодически, хотя это приведёт к некоторому снижению уровня защиты, если срок жизни соединения окажется меньше периода смены значений DH. Можно также отслеживать использование значений DH в каждом соединении и удалять информацию, связанную со значением DH, только после закрытия соответствующего соединения. Это позволит многократно использовать значения DH без снижения уровня защиты но с некоторым ростом издержек на поддержку большего числа состояний.

Решение о многократном использовании значений Diffie-Hellman и режиме такого использования является частным в том смысле, что оно не оказывает влияния на взаимодействие. Реализация, использующая значения DH неоднократно, может запоминать значения DH, использованные другой точкой в прошлых обменах, и при повторном их появлении избежать второй половины расчёта. Анализ защиты для этого случая и дополнительное рассмотрение вопросов безопасности при многократном использовании эфемерных ключей Diffie-Hellman приведены в работе [REUSE].

2.13. Генерация ключевого материала

В контексте IKE SA согласуются четыре криптографических алгоритма — алгоритмы шифрования и защиты целостности, группа Diffie-Hellman и псевдослучайная функция (PRF). Функция PRF служит для подготовки ключевого материала, используемого всеми криптоалгоритмами IKE SA и Child SA.

Предполагается, что алгоритмы шифрования и защиты целостности используют ключи фиксированного размера и в качестве ключа может служить произвольное случайно выбранное значение этого размера. Для алгоритмов, способных работать с ключами разного размера, должен задаваться фиксированный размер ключа при согласовании криптографических преобразований (см. определение атрибута преобразования Key Length в параграфе 3.3.5). Для алгоритмов, которые принимают не все значения ключей (таких, как DES или 3DES с чётностью ключей), алгоритм выбора ключей из набора произвольных значений должен задаваться криптографическим преобразованием. Для функций защиты целостности на базе хэшированных кодов аутентификации сообщений (HMAC²⁷) фиксированным размером ключа является размер вывода используемой хэш-функции.

Предполагается, что функции PRF воспринимают ключи любого размера, но имеют предпочтительный размер ключей. Этот размер должен использоваться в качестве размера SK_d, SK_pi и SK_pr (см. параграф 2.14). Для функций PRF на базе конструкций HMAC предпочтительный размер ключей равен размеру результата используемой хэш-функции. Остальные типы PRF должны задавать предпочтительный размер ключей.

Ключевой материал всегда берётся из вывода согласованного алгоритма PRF. Поскольку количество требуемого ключевого материала может превышать размер вывода PRF, функция PRF используется в режиме итераций. Обозначение prf+ указывает на функцию, результатом которой является псевдослучайный поток, основанный на вводе данных в случайную функцию prf.

В приведённых ниже примерах | обозначает конкатенацию. Функция prf+ определяется, как

   prf+ (K,S) = T1 | T2 | T3 | T4 | ...

где:

   T1 = prf (K, S | 0x01)
   T2 = prf (K, T1 | S | 0x02)
   T3 = prf (K, T2 | S | 0x03)
   T4 = prf (K, T3 | S | 0x04)
   ...

Этот процесс продолжается, пока на выходе функции prf+ не будет получен полный объем ключевого материала, требуемого для расчёта. всех нужных ключей. Ключи берутся из результата функции без учёта границ (т. е, если требуется 256-битовый ключ AES²⁸ и 160-битовый ключ HMAC, а функция prf генерирует на выход 160 битов, ключ AES будет состоять из T1 и начала T2, а ключ HMAC из остатка T2 и начала T3).

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

2.14. Генерация ключевого материала для IKE SA

Общие (разделяемые) ключи генерируются, как описано ниже. Значение SKEYSEED рассчитывается из значений nonce, передаваемых в процессе обмена IKE_SA_INIT и общего секрета Diffie-Hellman, организованного в процессе этого обмена. Число SKEYSEED используется для расчёта. семи других секретов — SK_d применяется при генерации новых ключей для Child SA, организуемых в рамках IKE SA, SK_ai и SK_ar служат в качестве ключей алгоритма защиты целостности для аутентификации сообщений при последующих обменах, SK_ei и SK_er применяются для шифрования (и расшифровки) при всех последующих обменах, SK_pi и SK_pr используются при генерации данных AUTH. Размеры SK_d, SK_pi и SK_pr должны совпадать с предпочтительным размером ключей согласованной ранее функции PRF.

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

SKEYSEED = prf(Ni | Nr, gir)
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} = prf+(SKEYSEED, Ni | Nr | SPIi | SPIr)

(левая часть второго уравнения показывает, что значения SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi и SK_pr берутся в том порядке, в котором создаётся выход prf+). g^ir является общим секретом из эфемерного обмена Diffie-Hellman. Значение g^ir представляется, как строка октетов в порядке big endian и дополняется при необходимости нулями до требуемого размера. Ni и Nr представляют собой одноразовые значения nonce, вырезаемые из любых заголовков. В силу исторических причин (для совместимости со старыми версиями) имеется две функции PRF, которые в таком расчёте имеют специфическую трактовку. Если согласованной PRF является AES-XCBC-PRF-128 [AESXCBCPRF128] или AES-CMAC-PRF-128 [AESCMACPRF128], только первые 64 бита Ni и первые 64 бита Nr используются при расчёте SKEYSEED, а все остальные биты служат для ввода в prf+.

Разные направления потока трафика используют различные ключи. Ключами, служащими для защиты трафика от исходного инициатора являются SK_ai и SK_ei, а ключами для другого направления — SK_ar и SK_er.

2.15. Аутентификация IKE SA

Когда расширяемая аутентификация (см. параграф 2.16) не используется, партнёры аутентифицируются с помощью цифровых подписей (или MAC с использованием дополненного общего секрета, как описано ниже в этом параграфе) для блоков данных. В этих расчётах IDi’ и IDr’ — все данные ID за исключением фиксированного заголовка. Для ответчика подписываемые октеты начинаются с первого октета первого значения SPI в заголовке второго сообщения (отклик IKE_SA_INIT) и заканчивается последним октетом последнего элемента данных во втором сообщении. К этому в конце добавляется (для расчёта. цифровой подписи) значение nonce инициатора Ni (просто значение, а не содержащий его элемент данных) и prf(SK_pr, IDr’). Отметим, что ни nonce Ni, ни значение prf(SK_pr, Idr’), сами по себе, не передаются. Подобно этому, инициатор подписывает первое сообщение (запрос IKE_SA_INIT), начиная с первого октета первого SPI в заголовке и заканчивая последним октетом последнего элемента данных. В конце этого добавляется (для расчёта. цифровой подписи) значение nonce ответчика Nr и значение prf(SK_pi, IDi’). Для защиты крайне важно использование в подписи каждой стороны значения nonce другой стороны.

Подписанные инициатором октеты можно описать следующим образом:

   InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI
   GenIKEHDR = [ 4 октета со значением 0, если применяется порт 4500 ] | RealIKEHDR
   RealIKEHDR =  SPIi | SPIr |  . . . | Length
   RealMessage1 = RealIKEHDR | RestOfMessage1
   NonceRPayload = PayloadHeader | NonceRData
   InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload
   RestOfInitIDPayload = IDType | RESERVED | InitIDData
   MACedIDForI = prf(SK_pi, RestOfInitIDPayload)

Подписанные ответчиком октеты можно описать, как:

   ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR
   GenIKEHDR = [ 4 октета со значением 0, если применяется порт 4500 ] | RealIKEHDR
   RealIKEHDR =  SPIi | SPIr |  . . . | Length
   RealMessage2 = RealIKEHDR | RestOfMessage2
   NonceIPayload = PayloadHeader | NonceIData
   ResponderIDPayload = PayloadHeader | RestOfRespIDPayload
   RestOfRespIDPayload = IDType | RESERVED | RespIDData
   MACedIDForR = prf(SK_pr, RestOfRespIDPayload)

Отметим, что в расчёт подписи включаются все элементы данных (payload), в том числе и те, которые не определены в данном документе. Если первое сообщение в обмене (например, cookie ответчика и/или другая группа Diffie-Hellman) повторяется несколько раз, подписывается последняя версия сообщения.

Опционально сообщения 3 и 4 могут включать сертификат или цепочку сертификатов, подтверждающих, что ключ, использованный для создания цифровой подписи, относится к имени, указанному в элементе данных ID. Подпись или код MAC будут рассчитываться с использованием алгоритма, диктуемого типом ключа, применяемого подписавшим и указанного в поле Auth Method элемента данных Authentication. Инициатор и ответчик не обязаны использовать для подписи один криптографический алгоритм. Выбор алгоритма зависит от типа имеющихся ключей. В частности, инициатор может использовать общий ключ, а ответчик иметь открытый ключ подписи и сертификат. На практике зачастую (но не обязательно) при использовании общего секрета для аутентификации в обоих направлениях применяется один ключ.

Отметим, что обычной, но зачастую небезопасной практикой является использование общего ключа, полученного из выбранного пользователем пароля без включения иных источников случайных данных. Недостаточная безопасность такого подхода обусловлена тем, что выбираемые пользователями пароли не обеспечивают непредсказуемости, достаточной для предотвращения атак по словарю (приложениям, использующим парольную аутентификацию для загрузки и IKE SA, следует выбирать метод аутентификации из параграфа 2.16, который предотвращает атаки по словарю в режиме off-line). Заранее созданные общие ключи должны обеспечивать уровень непредсказуемости, достаточный для самого сильного из согласуемых ключей. В случае заранее созданного общего ключа (pre-shared key), значение AUTH рассчитывается, как показано ниже.

Для инициатора

      AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), <InitiatorSignedOctets>)

Для ответчика

      AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), <ResponderSignedOctets>)

где строка «Key Pad for IKEv2²⁹» представляет собой 17 символов ASCII без завершающего null-символа. Общий секрет может иметь переменный размер. Строка заполнения добавляется так, чтобы при создании общего секрета из пароля реализации IKE не требовалось сохранять пароля в открытом виде, а можно было бы сохранить значение prf(Shared Secret,»Key Pad for IKEv2″), которое не может использоваться в качестве эквивалента пароля за пределами IKEv2. Как было отмечено выше, создание общего секрета из пароля не вполне безопасно. Такая конструкция используется в предположении, что люди все равно будут делать это. Интерфейс управления, посредством которого обеспечивается общий секрет, должен воспринимать строки ASCII размером, по крайней мере 64 октета, добавление null-символа завершения перед использованием разделяемого секрета недопустимо. Интерфейс управления может воспринимать другие кодировки символов, если задан алгоритм для представления символов в форме двоичной строки.

Имеется два типа аутентификации EAP³⁰ (см. параграф 2.16), каждый из которых использует разные значения в описанных выше расчётах AUTH. Если метод EAP служит для генерации ключей, главный сеансовый ключ (MSK³¹) при расчёте меняется на общий секрет. Для методов, не используемых для генерации ключей, SK_pi и SK_pr заменяются общим секретом в обоих расчётах AUTH.

2.16. Методы EAP

В дополнение к аутентификации с использованием подписей на основе открытых ключей и общих секретов, IKE поддерживает аутентификацию на основе методов, определённых в RFC 3748 [EAP]. Обычно эти методы являются асимметричными (предназначены для аутентификации пользователей на сервере) и могут не быть взаимными. По этой причине такие протоколы обычно используются инициатором для аутентификации самого себя перед ответчиком и должны применяться совместно с аутентификацией на основе подписи с открытым ключом для представления ответчика инициатору. Эти методы часто связывают с механизмами, которые называют «унаследованной аутентификацией³²».

Хотя в этом документе [EAP] упоминается с учётом добавления в будущем новых методов без обновления данной спецификации, некоторые простые вариации здесь рассматриваются. [EAP] определяет протокол аутентификации, требующий переменного числа сообщений. Расширяемая аутентификация реализуется в IKE в форме дополнительных обменов IKE_AUTH, которые должны быть завершены для инициализации IKE SA.

Инициатор показывает желание использовать EAP, опуская поле AUTH в первом сообщении обмена IKE_AUTH (отметим, что это поле требуется для других вариантов аутентификации, поэтому в данном документе не отмечено, как опциональное). Путём включения элемента IDi и исключения AUTH инициатор заявляет свою подлинность, но не подтверждает её. Если ответчик согласен использовать метод EAP, он помещает элемент EAP в отклик обмена IKE_AUTH и откладывает передачу SAr2, TSi и TSr, пока аутентификация инициатора не будет завершена в следующем обмене IKE_AUTH. Для случая минимального метода EAP организация начальной SA показана на рисунке.

Инициатор                         Ответчик
-------------------------------------------------------------------
HDR, SAi1, KEi, Ni           -->
                             <--  HDR, SAr1, KEr, Nr, [CERTREQ]
HDR, SK {IDi, [CERTREQ,] 
   [IDr,] Sai2, TSi, TSr}    -->
                             <--  HDR, SK {IDr, [CERT,] AUTH, EAP }
HDR, SK {EAP}                -->
                             <--  HDR, SK {EAP (успех)}
HDR, SK {AUTH}               -->
                             <--  HDR, SK {AUTH, SAr2, TSi, TSr }

Как указано в параграфе 2.2, при использовании EAP каждая пара изначальных сообщений при организации IKE SA будет использовать увеличивающиеся порядковые номера — сообщения IKE_AUTH первой пары будут иметь номер 1, второй — 2 и т. д.

Для методов EAP, создающих общий ключ в качестве побочного эффекта аутентификации, этот ключ должен использоваться как инициатором, так и ответчиком для генерации данных AUTH в сообщениях 7 и 8 с использованием синтаксиса общих секретов, описанного в параграфе 2.15. Общий ключ от EAP представляет собой поле, которое в спецификации EAP названо MSK. Этот общий ключ генерируется в процессе обмена IKE и его недопустимо использовать для каких-либо целей.

Методы EAP, которые не организуют общего ключа, не следует применять, поскольку они могут быть подвержены MITM-атакам [EAPMITM], если эти методы EAP используются в других протоколах, не использующих аутентифицируемого сервером туннеля. Более подробное обсуждение этой ситуации приводится в разделе «Вопросы безопасности». При использовании методов EAP, не генерирующих общего ключа, элементы AUTH в сообщениях 7 и 8 должны генерироваться с использованием SK_pi и SK_pr, соответственно.

От инициатора IKE SA, использующего EAP, требуется возможность расширения начального протокольного обмена по крайней мере до 10 обменов IKE_AUTH в тех случаях, когда ответчик передаёт уведомления и/или отклики на приглашение аутентификации. После успешного завершения протокольного обмена, определённого выбранным методом аутентификации EAP, ответчик должен передать элемент EAP, содержащий сообщение Success. При отказе ответчик должен передать элемент EAP, содержащий сообщение Failure. Ответчик может в любой момент прервать обмен IKE, передав элемент EAP с сообщением Failure.

После расширенного обмена данные EAP AUTH должны быть включены в два сообщения после сообщение с EAP Success.

При использовании инициатором аутентификации EAP возможны ситуации, когда содержимое IDi используется только для целей AAA³³ при маршрутизации и выбора используемого метода EAP. Это значение может отличаться от отождествлений, аутентифицированных методом EAP. Важно, чтобы при просмотре правил и принятии решения о предоставлении доступа использовались актуальные аутентифицированные отождествления. Зачастую сервер EAP реализуется на отдельном сервере AAA, который обменивается данными с ответчиком IKEv2. В таких случаях, аутентифицированное отождествление (если оно отличается от данных Idi) будет передаваться от сервера AAA ответчику IKEv2.

2.17. Генерация ключевого материала для Child SA

Одна дочерняя связь Child SA создаётся обменом IKE_AUTH, а дополнительные Child SA могут создаваться в обменах CREATE_CHILD_SA. Ключевой материал для них генерируется следующим образом

   KEYMAT = prf+(SK_d, Ni | Nr)

Здесь Ni и Nr — значения nonce из обмена IKE_SA_INIT, если это запрос на создание первой Child SA или свежие значения Ni и Nr из обмена CREATE_CHILD_SA для последующих дочерних связей.

Для CREATE_CHILD_SA, включающих обмен Diffie-Hellman, ключевой материал генерируется по формуле

   KEYMAT = prf+(SK_d, gir (new) | Ni | Nr )

где g^ir (new) — общий секрет из эфемерного обмена Diffie-Hellman в данном CREATE_CHILD_SA (представляется, как строка октетов с порядком big endian, дополненная при необходимости нулями в старших битах для получения размера модуля).

Одно согласование CHILD_SA может приводить к организации множества защищённых связей. Связи ESP и AH существуют попарно (по одной для каждого направления), поэтому для этих протоколов создаётся две SA в одном согласовании Child SA. Кроме того, согласование Child SA может включать некоторые будущие протоколы IPsec в дополнение (или взамен) к ESP или AH (например, ROHC_INTEG [ROHCV2]). В любом случае ключевой материал для каждой Child SA должен браться из расширенного KEYMAT с использованием приведённых ниже правил.

• Все ключи для SA, передающих данные от инициатора к ответчику, берутся до ключей для SA обратного направления.

• Если согласовано множество протоколов IPsec, ключевой материал для каждой Child SA берётся в порядке следования протокольных заголовков в инкапсулированном пакете.

• Если протокол IPsec требует множества ключей, порядок их извлечения из ключевого материала SA требуется описать в спецификации протокола. Для ESP и AH в [IPSECARCH] определён следующий порядок — ключ шифрования (если он есть) должен браться из первых битов, а ключ защиты целостности (если он есть) — из оставшихся.

Каждый криптографический алгоритм берет фиксированное число битов ключевого материала, заданное в спецификации или согласованное в данных SA (см описание размеров ключей в параграфе 2.13 и определение алгоритма преобразования Key Length в параграфе 3.3.5).

2.18. Смена ключей IKE SA с помощью обмена CREATE_CHILD_SA

Обмен CREATE_CHILD_SA можно использовать для смены ключей существующей IKE SA (см. параграфы 1.3.2 и 2.8). Новые значения SPI инициатора и ответчика поставляются в полях SPI субструктур Proposal внутри элементов SA (не поля SPI в заголовке IKE). Элементы TS опускаются при смене ключей IKE SA. Значение SKEYSEED для новой IKE SA рассчитывается с использованием SK_d из существующей IKE SA следующим образом:

   SKEYSEED = prf(SK_d (old), gir (new) | Ni | Nr)

где g^ir (new) — общий секрет из эфемерного обмена Diffie-Hellman в данном CREATE_CHILD_SA (представляется, как строка октетов с порядком big endian, дополненная при необходимости нулями в старших битах для получения размера модуля), а Ni и Nr — значения nonce из любых заголовков.

Старая и новая IKE SA могут иметь разные функции PRF. Поскольку обмен, связанный со сменой ключей, происходит в старой IKE SA, для генерации SKEYSEED используется функция PRF из старой IKE SA.

Основной причиной смены ключей IKE SA является предотвращение возможности использования скомпрометированного старого ключевого материала для получения информации о текущих ключах и наоборот. Следовательно, реализации должны выполнять новый обмен Diffie-Hellman при смене ключей IKE SA. Иными словами, для инициатора недопустимо предлагать значение NONE в качестве преобразования Diffie-Hellman, а для ответчика недопустимо принимать такие предложения. Это означает, что для успешного обмена с заменой ключей IKE SA всегда используются элементы данных KEi/KEr.

В новой IKE SA значения счётчиков сообщений должны сбрасываться в 0.

SK_d, SK_ai, SK_ar, SK_ei и SK_er рассчитываются из SKEYSEED, как описано в параграфе 2.14, с использованием SPIi, SPIr, Ni и Nr из нового обмена и функции PRF из новой IKE SA.

2.19. Запрос внутреннего адреса из удалённой сети

Наиболее часто встречающимся сценарием взаимодействия между конечной точкой и защитным шлюзом является необходимость получения конечной точкой IP-адреса из сети, защищённой шлюзом (возможно, динамического). Запрос на получение такого адреса может быть включён в любой запрос на создание Child SA (включая неявный запрос в сообщении 3) с использованием элемента CP. Отметим, однако, что обычно выделяется только один адрес IP в процессе обмена IKE_AUTH. Этот адрес сохраняется по крайней мере до удаления IKE SA.

Инициатор                         Ответчик
-------------------------------------------------------------------
 HDR, SK {IDi, [CERT,]
    [CERTREQ,] [IDr,] AUTH,
    CP(CFG_REQUEST), SAi2,
    TSi, TSr}                -->
                             <--  HDR, SK {IDr, [CERT,] AUTH,
                                     CP(CFG_REPLY), Sar2, TSi, TSr}

Эта функция обеспечивает выделение адреса для удалённого клиента IPsec (CRC³⁴), пытающегося организовать туннель в сеть, защищённую сервером удалённого доступа IPsec (IRAS³⁵). Поскольку обмен IKE_AUTH создаёт IKE SA и Child SA, CRC должен запросить контролируемый сервером IRAS адрес (и, возможно, другую информацию, относящуюся к защищённой сети) в обмене IKE_AUTH. Сервер IRAS может получать адрес для CRC из любого числа источников типа серверов DHCP/BOOTP³⁶ (протокол загрузки) или выделять его из своего пула.

Во всех случаях данные CP должны помещаться до данных SA. В вариантах протокола с множественными обменами IKE_AUTH данные CP должны помещаться в сообщения, содержащие данные SA.

Вызов CP(CFG_REQUEST) должен включать по крайней мере один атрибут INTERNAL_ADDRESS (IPv4 или Ipv6), но может содержать любое число дополнительных атрибутов, которые инициатор хочет вернуть в отклике.

Пример сообщения от инициатора к ответчику может иметь вид:

   CP(CFG_REQUEST) = INTERNAL_ADDRESS()
   TSi37 = (0, 0-65535,0.0.0.0-255.255.255.255)
   TSr = (0, 0-65535,0.0.0.0-255.255.255.255)

Сообщение от ответчика инициатору:

   CP(CFG_REPLY) = INTERNAL_ADDRESS(192.0.2.202)
     INTERNAL_NETMASK(255.255.255.0)
     INTERNAL_SUBNET(192.0.2.0/255.255.255.0)
   TSi = (0, 0-65535,192.0.2.202-192.0.2.202)
   TSr = (0, 0-65535,192.0.2.0-192.0.2.255)

Все возвращаемые значения зависят от реализации. Как можно видеть в приведённых примерах, сервер IRAS может также передать другие атрибуты, которые не были включены в CP(CFG_REQUEST) и может игнорировать любые необязательные атрибуты, которые он не поддерживает.

Ответчику недопустимо передавать CFG_REPLY без получения сначала запроса CP(CFG_REQUEST) от инициатора, поскольку мы не хотим, чтобы сервер IRAS выполнял ненужные просмотры конфигурации в случаях, когда CRC не может обработать REPLY.

В случаях, когда конфигурация IRAS требует, чтобы элемент CP использовался для данного отождествления IDi, но CRC не смог передать CP(CFG_REQUEST), сервер IRAS должен отказаться от выполнения запроса и прервать создание Child SA с помощью сообщения об ошибке FAILED_CP_REQUIRED. Это сообщение не относится к критическим для IKE SA и просто приводит к отказу при создании Child SA. Инициатор может исправить ситуацию с помощью нового запроса с элементом Configuration. С сообщением FAILED_CP_REQUIRED не связано каких-либо данных.

2.20. Запрос версии партнёра

Узел IKE, желающий узнать версию IKE своего партнёра, может использовать описанный ниже метод. Это пример конфигурационного запроса в обмене INFORMATIONAL после организации IKE SA и первой Child SA.

Инициатор                         Ответчик
-------------------------------------------------------------------
HDR, SK{CP(CFG_REQUEST)}     -->
                             <--  HDR, SK{CP(CFG_REPLY)}

CP(CFG_REQUEST)= APPLICATION_VERSION("")

CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar Inc.")

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

2.21. Обработка ошибок

При обработке IKE может возникать множество различных ошибок. Общим правилом является передача в ответ на запросы с некорректным форматом или неприемлемые по соображениям политики (например, несоответствие криптографических алгоритмов) отклика с элементами Notify, указывающими на ошибку. Решение о передаче такого отклика зависит от того, была ли аутентифицирована связь IKE SA.

Если ошибка возникает при разборе или обработке отклика, в соответствии с общим правилом не следует передавать в ответ сообщение об ошибке, поскольку отклики не должны вызывать генерации новых запросов (а новый запрос является единственным способом передать ответчику сообщение об ошибке). В случае ошибки при разборе или обработке отклика его получателю следует сбросить состояние IKE (например, передать Delete для SA).

Только отказы при аутентификации (AUTHENTICATION_FAILED и отказ EAP) и сообщения с некорректным форматом (INVALID_SYNTAX) ведут к удалению IKE SA без необходимости использования явного обмена INFORMATIONAL с данными Delete. Другие ошибки могут требовать такого обмена в соответствии с политикой. Если обмен прерывается отказом EAP Failure, уведомление AUTHENTICATION_FAILED не передаётся.

2.21.1. Обработка ошибок в IKE_SA_INIT

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

При обменах IKE_SA_INIT любое уведомление об ошибки вызывает отказ. Отметим, что некоторые уведомления (например, COOKIE, INVALID_KE_PAYLOAD или INVALID_MAJOR_VERSION) позволяют впоследствии завершить обмен успешно. Поскольку все уведомления об ошибках полностью не аутентифицированы, получателю следует продолжать попытки в течение некоторого времени прежде, чем дать отказ. Получателю не следует незамедлительно выполнять какие-либо действия на основе полученных уведомлений об ошибке, если в этой спецификации не определено соответствующих корректировочных мер, как для уведомлений COOKIE, INVALID_KE_PAYLOAD и INVALID_MAJOR_VERSION.

2.21.2. Обработка ошибок в IKE_AUTH

При возникновении любой ошибки в обмене IKE_AUTH, вызывающей отказ аутентификации независимо от причины (некорректный общий секрет или идентификатор, недоверенный эмитент сертификата, отозванный или просроченный сертификат и т. п.), следует передавать уведомление AUTHENTICATION_FAILED. Если ошибка возникла на стороне ответчика, уведомление возвращается в защищённом отклике и обычно не содержит других элементов. Хотя сообщения IKE_AUTH шифруются и целостность их защищается, если получивший такое сообщение партнёр ещё не аутентифицирован на другой стороне, ему следует с осторожностью воспринимать информацию об ошибке.

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

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

Если проверка подлинности успешно завершилась в обмене IKE_AUTH, это означает, что связь IKE SA организована, однако при организации Child SA или запросе конфигурационной информации может возникнуть отказ. Такие отказы не ведут к автоматическому удалению IKE SA. В частности, ответчик может включить все элементы, связанные с аутентификацией (IDr, CERT, AUTH) при отправке уведомления об ошибке для дополняемых обменов (FAILED_CP_REQUIRED, NO_PROPOSAL_CHOSEN и т. п.), а инициатору недопустимо на основании этого отказываться от аутентификации. Инициатор может, конечно, по соображениям политики позднее удалить эту IKE SA.

В обмене IKE_AUTH или непосредственно следующим за ним обмене INFORMATIONAL (в случае ошибок при обработке отклика на IKE_AUTH) только уведомления UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX и AUTHENTICATION_FAILED вызывают удаление или отказ от создания IKE SA без использования элемента Delete. Документы расширений могут определять дополнительные уведомления об ошибках, использующие такую семантику, но недопустимо использовать их, пока партнёр не указал, что способен их понимать (например, используя данные Vendor ID).

2.21.3. Обработка ошибок после аутентификации IKE SA

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

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

Если разбирающий запрос партнёр видит, что запрос имеет некорректный формат (после проверки кода аутентификации сообщения и окна), и возвращает уведомление INVALID_SYNTAX, такое уведомление рассматривается обеими сторонами, как критическое и требующее удаления IKE SA без необходимости явного включения элемента Delete.

2.21.4. Обработка ошибок за пределами IKE SA

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

Если узел получает сообщение в порт UDP с номером 500 или 4500 за пределами известного ему контекста IKE SA (и это сообщение не является запросом на организацию новой IKE SA), это может быть результатом недавней аварии на узле. Если сообщение помечено, как отклик, узел может проверить подозрительное событие, но отвечать на сообщение недопустимо. Если сообщение помечено, как запрос, узел может проверить подозрительное событие и может передать отклик на сообщение. Если отклик передаётся, он должен направляться по адресу IP и с номером порта, которые были указаны в полях отправителя полученного пакета с сохранением значений IKE SPI и Message ID из принятого пакета. Отклик недопустимо защищать криптографически и он должен содержать элемент Notify из INVALID_IKE_SPI. Уведомление INVALID_IKE_SPI показывает, что сообщение IKE было получено для нераспознанного SPI (это обычно говорит о перезагрузке получателя с потерей существовавших IKE SA).

Партнёру, получившему такой незащищённый элемент Notify, недопустимо отвечать на сообщение и недопустимо менять состояние для любой из существующих SA. Сообщение может быть обманным или являться корректным откликом на переданный отвечающему узлу обманный запрос. Узлу следует трактовать такие сообщения (а также сетевые сообщения типа ICMP destination unreachable), как намёк на возможное наличие проблем с SA для этого адреса IP и целесообразность проверки жизнеспособности IKE SA. Реализациям следует ограничивать частоту таких проверок, чтобы не оказаться вовлеченным в организацию DoS-атак.

Если ошибка происходит вне контекста запроса IKE (например, узел получает сообщения ESP для несуществующего SPI), узлу следует инициировать обмен INFORMATIONAL с элементом Notify, описывающим проблему.

Узлу, получившему подозрительное сообщение с адреса IP (и номера порта, если используется NAT), с которым он имеет IKE SA, следует передать элемент IKE Notify в обмене IKE INFORMATIONAL через эту связь SA. Получателю недопустимо менять состояние какой-либо SA в результате приёма подозрительных сообщений, но можно проверить подозрительные события.

2.22. Компрессия IPComp

Использование компрессии IP [IP-COMP] может быть согласовано в процессе организации Child SA. Хотя сжатие IP включает дополнительный заголовок в каждом пакете и индекс параметров сжатия (CPI³⁸), виртуальная «ассоциация сжатия» не выходит на пределы содержащей её связи ESP или AH. Эти ассоциации исчезают при завершении соответствующей связи ESP или AH. Они явно не указываются в элементах Delete.

Согласование сжатия IP отделено от согласования криптографических параметров, связанных с Child SA. Узел, запрашивающий Child SA, может анонсировать поддержку одного или множества алгоритмов компрессии а одном или множестве элементов Notify типа IPCOMP_SUPPORTED. Эти сообщения Notify могут включаться только в сообщение, содержащее элемент SA, согласующий Child SA, и показывает желание отправителя использовать IPComp для этой SA. Отклик может показывать приемлемость одного механизма сжатия с помощью элемента Notify типа IPCOMP_SUPPORTED. Такие элементы недопустимо помещать в сообщения, не содержащие полей элементов SA.

Данные, связанные с этим сообщением Notify, включают два октета IPComp CPI, за которыми следует один октет Transform ID, после которого могут включаться атрибуты, размер и формат которых определяется значением Transform ID. Сообщение, предлагающее SA, может содержать множество уведомлений IPCOMP_SUPPORTED для указания разных поддерживаемых алгоритмов. В сообщении, принимающем SA, может указываться не более одного алгоритма.

Значения Transform ID приведены в таблице (по состоянию на момент публикации RFC 4306). С тех пор могли появиться новые преобразования, возможно их добавление и после публикации данного документа. Для получения актуальной информации следует обратиться к [IKEV2IANA].

 

Имя	Номер	Документ
IPCOMP_OUI	1
IPCOMP_DEFLATE	2	RFC 2394
IPCOMP_LZS	3	RFC 2395
IPCOMP_LZJH	4	RFC 3051

 

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

Побочным эффектом раздельного согласования IPComp и криптографических параметров является невозможность предложить заданные комбинации шифронаборов и IP Compression.

В некоторых случаях компрессия заголовков ROHC³⁹ может оказаться более подходящей, нежели IP Compression. Документ [ROHCV2] определяет использование компрессии ROHC с IKEv2 и IPsec.

2.23. Работа через NAT

Шлюзы с трансляцией адресов (NAT⁴⁰) являются спорным вопросом. В этом параграфе кратко описано, что и как такие шлюзы делают с трафиком IKE. Многие считают NAT злом и полагают, что не следует разрабатывать протоколы так, чтобы трансляторы работали лучше. IKEv2 задаёт некоторые не вполне очевидные правила обработки для того, чтобы улучшить работу через NAT.

Существование NAT обусловлено в основном нехваткой адресов IPv4, хотя есть и другие причины. Узлы IP, находящиеся за NAT, могут не иметь уникальных в глобальном масштабе адресов IP, а использовать адреса из неких блоков, обеспечивающих уникальность лишь в пределах расположенной за NAT сети, которые могут одновременно применяться в других сетях, расположенных за другими устройствами NAT. В общем случае узлы, расположенные за NAT, могут взаимодействовать с узлами, расположенными за тем же NAT, и с узлами, имеющими уникальные в глобальном масштабе адреса, но не с узлами, расположенными за другими трансляторами NAT. Из этого правила существуют исключения. Когда расположенные за NAT узлы соединяются с другими узлами в сети Internet, шлюз NAT транслирует IP-адреса отправителей, преобразуя их в некий адрес (адреса), которые будут маршрутизироваться обратно на этот шлюз. Приходящие на шлюз пакеты из сети Internet будут снова транслироваться с заменой адреса получателя на внутренний адрес, чтобы пакет был доставлен нужному узлу за шлюзом.

Системы NAT устроены так, чтобы они оставались «прозрачными» для конечных узлов. Ни программы на узлах за NAT, ни узлы Internet не требуется как-то изменять для работы через NAT. Обеспечение такой прозрачности для некоторых протоколов сложнее, чем для других. Протоколы, включающие в поля данных пакетов IP-адреса конечных точек, не будут работать, пока шлюзы NAT не станут понимать эти протоколы и изменять внутренние поля пакетов, как это делается при трансляции полей заголовков. Однако такое решение по своей природе ненадежно, нарушает требования сетевого уровня и зачастую приводит к возникновению серьёзных проблем.

Организация соединений IPsec через NAT вносит свои проблемы. Если соединение организуется в транспортном режиме, замена адресов IP в пакетах будет приводить к отказам при проверке контрольной суммы, а NAT не может её исправить, поскольку значение контрольной суммы защищено криптографически. Даже в туннельном режиме возникают проблемы с маршрутизацией, поскольку прозрачная трансляция адресов в пакетах AH и ESP требует реализации в NAT специальной логики, которая эвристична и ненадёжна по своей природе. По этим причинам в IKEv2 используется инкапсуляция пакетов IKE и ESP в UDP. Такое кодирование менее эффективно, но существенно упрощает обработку в NAT. В дополнение к этому, межсетевые экраны могут быть настроены на пропускание инкапсулированного в UDP трафика IPsec, но не трафика ESP/AH без инкапсуляции (или наоборот).

Общей практикой в NAT является трансляция номеров портов TCP и UDP вместе с сетевыми адресами и использование номера порта во входящих пакетах для определения внутреннего узла, которому пакет адресован. По этой причине, несмотря на то, что пакеты IKE должны передаваться в порт (из порта) UDP с номером 500 или 4500, они должны восприниматься из любого порта, а отклики должны передаваться в тот порт, откуда поступил пакет. Это обусловлено тем, номера портов могут изменяться при прохождении пакетов через NAT. По этой же причине IP-адреса конечных точек IKE обычно не включаются в элементы данных IKE, поскольку те защищены криптографически и не могут прозрачно изменяться в устройствах NAT.

Порт 4500 зарезервирован для инкапсулированных в UDP пакетов ESP и IKE. Конечная точка IPsec, обнаружившая NAT между собой и корреспондентом (как описано ниже), должна передавать весь последующий трафик из порта 4500, для которого устройствам NAT не следует требуется специальной обработки (как и для порта 500).

Инициатор может использовать порт 4500 для IKE и ESP, независимо от информации о наличии NAT в момент организации соединения IKE. Когда любая из сторон использует порт 4500, инкапсуляция ESP в UDP не требуется, но необходимо понимание инкапсулированных в UDP пакетов ESP на стороне приёма. Инкапсуляцию UDP недопустимо использовать для порта 500. Если поддерживается NAT-T⁴¹ (т. е., произошёл обмен элементами NAT_DETECTION_*_IP в процессе обмена IKE_SA_INIT), все устройства должны быть способны принимать и обрабатывать в любой момент пакеты ESP как с инкапсуляцией в UDP, так и без неё. Каждая сторона может принять решение об использовании инкапсуляции трафика ESP в UDP, независимо от выбора другой стороны. Однако при обнаружении NAT оба устройства должны использовать для пакетов ESP инкапсуляцию в UDP.

Ниже приведены конкретные требования для поддержки работы через NAT [NATREQ] (такая поддержка не является обязательной). В этом параграфе требования с уровнем должны относятся лишь к устройствам с поддержкой работы через NAT.

• Инициатор и ответчик IKE должны включить в свои пакеты IKE_SA_INIT элементы Notify типа NAT_DETECTION_SOURCE_IP и NAT_DETECTION_DESTINATION_IP. Эти элементы могут использоваться для детектирования присутствия NAT между хостами и определения стороны, расположенной за NAT. Элементы размещаются в пакетах IKE_SA_INIT после Ni и Nr (перед необязательным элементом CERTREQ).

• Данными, связанными с уведомлением NAT_DETECTION_SOURCE_IP, является сигнатура SHA-1 для значений SPI (в порядке их следования в заголовке), адреса IP и номера порта, откуда был передан пакет. Элементов NAT_DETECTION_SOURCE_IP может быть более одного, если отправитель не знает, которая из подключённых сетей будет использоваться для передачи пакетов.

• Данными, связанными с уведомлением NAT_DETECTION_DESTINATION_IP, является сигнатура SHA-1 для значений SPI (в порядке их следования в заголовке), адреса IP и номера порта, куда был передан пакет.

• Получатель уведомления NAT_DETECTION_SOURCE_IP или NAT_DETECTION_DESTINATION_IP может сравнить полученные значения с сигнатурой SHA-1 для SPI, адресом IP и номером порта отправителя или получателя (соответственно). При несоответствии получателю пакета следует включить работу через NAT. В случаях, когда хэш NAT_DETECTION_SOURCE_IP не совпадает для всех полученных данных NAT_DETECTION_SOURCE_IP, получатель может отвергнуть попытку организации соединения, если работа через NAT не поддерживается. Несоответствие хэша NAT_DETECTION_DESTINATION_IP означает, что система, получившая данные NAT_DETECTION_DESTINATION_IP, расположена за NAT и этой системе следует начать передачу пакетов keepalive, как определено в [UDPENCAPS], система может также отвергнуть попытку организации соединения, если работа через NAT не поддерживается.

• Если ни один из полученных элементов NAT_DETECTION_SOURCE_IP не соответствует ожидаемому IP-адресу и порту отправителя из заголовка IP содержащего данные пакета, это означает, что отправившая данные система расположена за транслятором NAT (т. е., кто-то на пути меняет адрес отправителя в исходном пакете на адрес устройства NAT). В таких случаях получившей данные системе следует разрешить динамическое обновление IP-адресов других систем, как описано ниже.

• Инициатор IKE должен проверить элементы NAT_DETECTION_SOURCE_IP и NAT_DETECTION_DESTINATION_IP, если они имеются и, при несоответствии адресам во внешнем пакете, должен туннелировать все будущие пакеты IKE и ESP, связанные с данной IKE SA через порт UDP 4500.

• При туннелировании пакетов IKE через порт UDP 4500 4 октета с нулевыми значениями в начале заголовка IKE размещаются сразу после заголовка UDP. При туннелировании пакетов ESP через порт UDP 4500 заголовок ESP следует сразу после заголовка UDP. Поскольку первые 4 октета заголовка ESP содержат SPI и корректное значение SPI не может быть равно 0, это позволяет во всех случаях различать сообщения ESP и IKE.

• Реализации должны обрабатывать инкапсулированные в UDP принятые пакеты ESP даже в тех случаях, когда наличие NAT не обнаружено.

• Исходные IP-адреса отправителя и получателя, которые нужны в транспортном режиме для расчёта. контрольной суммы пакетов TCP и UDP (см. [UDPENCAPS]), извлекаются из селекторов трафика, связанных с этим обменом. При работе через NAT селекторы трафика должны содержать в точности один адрес IP, который используется в качестве исходного адреса. Этот вопрос более подробно рассмотрен в параграфе 2.23.1.

• В некоторых случаях устройство NAT может удалить отображения, которые продолжают использоваться (например, интервал keepalive слишком велик или транслятор NAT перезагружен). Хост будет видеть это, как будто он получил пакет, прошедший проверку защиты целостности, но имеющий адрес и/или порт, отличающийся от связанного с SA в проверенном пакете. Когда обнаруживается такой прошедший проверку пакет, а хост не поддерживает других методов восстановления типа IKEv2 MOBIKE⁴² [MOBIKE] и не находится за NAT, следует передавать все пакеты (включая повторы) в IP-адрес и порт из проверенного пакета, а также следует сохранить этот адрес и порт, как новую комбинацию для SA (т. е., следует динамически обновить адрес). Находящемуся за NAT хосту не следует выполнять такое динамическое обновление адреса, если проверенный пакет имеет другой адрес/порт, поскольку это может открывать возможность организации DoS-атаки (позволяя атакующему разорвать соединение, отправив единственный пакет). Динамическое обновление адреса следует проводить только в ответе на новый пакет, поскольку в противном случае атакующий сможет вернуться к адресам из старых, повторно использованных пакетов. По этой причине динамическое обновление адресов может выполняться безопасно лишь при включённой защите от повторного использования пакетов. При использовании IKEv2 с MOBIKE описанное выше динамическое обновление будет конфликтовать с используемым MOBIKE способом восстановления для таких ситуаций (см. параграф 3.8 в [MOBIKE]).

2.23.1. Работа через NAT в транспортном режиме

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

+------+        +------+            +------+         +------+
|Узел- | IP1    | NAT  | IPN1  IPN2 | NAT  |     IP2 |Сервер|
|клиент|<------>|  A   |<---------->|  B   |<------->|      |
+------+        +------+            +------+         +------+

В этом сценарии используется два транслятора адресов — NAT A и NAT B. NAT A является динамическим транслятором, который отображает клиентские адреса отправителя IP1 в IPN1. NAT B — статический транслятор, настроенный так, что входящие соединения для адреса IPN2 отображаются на адрес шлюза IP2 (т. е. адрес получателя IPN2 отображается на IP2). Это позволяет клиентам подключаться к серверу, обращаясь по адресу IPN2. Транслятору NAT B не обязательно быть статическим, но клиент должен знать, по какому адресу он может обращаться к серверу и он может добиться этого, лишь обращаясь по внешнему адресу NAT B (т. е., IPN2). Если NAT B является статическим транслятором, его адрес можно будет просто указать в конфигурации клиента. Другим вариантом может служить поиск адреса с использованием того или иного протокола (типа DNS), но это выходит за рамки IKEv2.

В этом сценарии клиент и сервер настраиваются на работу в транспортном режим для трафика, исходящего от клиента и адресованного серверу.

Когда клиент начинает создание IKEv2 SA и Child SA для передачи трафика серверу, он может иметь инициирующий (триггерный) пакет с адресом отправителя IP1 и адресом получателя IPN2. В его базе полномочий партнёров (PAD⁴³) и SPD должно быть конфигурационное соответствие между этими адресами (или соответствующими шаблонами).

В транспортном режиме используются в точности те же адреса, что в селекторах трафика и внешних заголовках IP пакетов IKE. Для транспортного режима должен применяться в точности один адрес IP в элементах данных TSi и TSr. Может применяться множество селекторов трафика, если имеется, например, множество диапазонов портов, которые хочется согласовать, но все элементы TSi должны использовать диапазон IP1-IP1 в качестве адресов IP и все элементы TSr должны иметь адреса из диапазона IPN2-IPN2. Первому селектору трафика TSi и TSr следует иметь конкретные значения Traffic Selector, включая протокол и номера портов (как значения из пакета, инициировавшего запрос).

NAT A будет менять адрес отправителя в пакете IKE с IP1 на IPN1, а NAT B будет менять адрес получателя пакета IKE с IPN2 на IP2, поэтому по прибытии пакета на сервер он будет иметь точно такие селекторы трафика, какие были переданы клиентом, но адреса IP в пакете IKE будут заменены на IPN1 и IP2.

Когда сервер получает этот пакет, он обычно просматривает базу данных PAD, описанную в RFC 4301 [IPSECARCH], по значению ID и ищет SPD по значениям Traffic Selector. Поскольку IP1 реально ничего не говорит серверу (это адрес клиента за NAT), бесполезно заниматься поиском по этому адресу в транспортном режиме. С другой стороны, сервер не может знать, разрешает ли его политика транспортный режим, пока не будет найдена соответствующая запись SPD.

В этом случае серверу следует сначала проверить, запрашивал ли транспортный режим инициатор, а после этого провести замену адреса в селекторах трафика. Сначала нужно сохранить старый адрес IP из селектора трафика, который позднее будет применяться для корректировки контрольной суммы (IP-адрес в TSi может сохраняться, как исходный адрес отправителя, а IP-адрес в TSr — как исходный адрес получателя). После этого, если другая сторона была определена, как расположенная за устройством NAT, сервер меняет адрес IP в элементе данных Tsi на IP-адрес из поля отправителя принятого пакета IKE (т. е., меняет в TSi адрес IP1 на IPN1). Если определено нахождение серверной стороны за устройством NAT, сервер меняет адрес IP в элементе данных TSr на IP-адрес из поля получателя в принятом пакете IKE (т. е., IPN2 в TSr меняется на IP2).

После замены адреса в селекторах трафика и заголовке IKE UDP будут совпадать и сервер может выполнить поиск в SPD по новым значениям Traffic Selector. Если запись найдена и разрешает транспортный режим, эта запись используется. Если же найденная запись не позволяет использовать транспортный режим, сервер может вернуться к прежним адресам и повторить поиск в базе SPD по исходным селекторам трафика. Если такой поиск даст положительный результат, сервер будет создавать SA в туннельном режиме, используя реальные значения Traffic Selector, переданные другой стороной.

Такая подстановка адресов в транспортном режиме нужна потому, что поиск SPD выполняется с использованием адресов, которые видны локальному хосту. Это также позволяет добавлять записи в базу данных SAD⁴⁴ для проверки точек выхода из туннеля и возврата пакетов с использованием адресов, которые видны стеку локальной операционной системы.

В наиболее общем случае SPD сервера будет включать шаблонные записи, соответствующие адресам, но возможно и включение разных записей SPD (например, для разных известных внешних адресов NAT).

После просмотра SPD сервер будет сужать Traffic Selector на основе найденной в SPD записи. Он будет снова использовать селекторы трафика, в которых уже выполнена подстановка адресов, и возвращать селекторы, имеющие IPN1 и IP2 в качестве адресов IP. Сервер может дополнительно сузить диапазоны номеров протоколов и портов, используемые в селекторах трафика. Запись в базе SAD, создаваемая для Child SA, будет иметь адреса, которые видны серверу (IPN1 и IP2).

При получении клиентом отклика от сервера для Child SA он будет выполнять аналогичную обработку. Если создана SA транспортного режима, клиент может сохранить исходные возвращённые селекторы трафика в качестве исходных адресов отправителя и получателя. Он будет заменять адреса IP в селекторах трафика адресами из заголовка IP в пакете IKE, меняя IPN1 на IP1 и IP2 на IPN2. После этого клиент будет использовать селекторы трафика при сравнении SA с переданными селекторами трафика и организации записи SAD.

Правила для прохождения через трансляторы NAT перечислены ниже.

Для клиентов, предлагающих транспортный режим:

• записи TSi должны иметь в точности 1 адрес IP, который должен соответствовать адресу отправителя IKE SA;

• записи TSr должны иметь в точности 1 адрес IP, который должен соответствовать адресу получателя IKE SA;

• первым селекторам трафика TSi и TSr следует иметь наиболее специфичные Traffic Selector, включая номера протоколов и портов (такие, зак из вызвавшего запрос пакета);

• может присутствовать множество элементов TSi и Tsr;

• если для SA выбран транспортный режим (т. е., сервер включил в свой отклик уведомление USE_TRANSPORT_MODE):

• исходные селекторы трафика сохраняются, как принятые адреса отправителя и получателя;

• если сервер расположен за транслятором NAT, адрес IP в TSr заменяется удаленным адресом IKE SA;

• если клиент расположен за транслятором NAT, адрес IP в TSi заменяется локальным адресом IKE SA;

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

Для отвечающих в случае предложения клиентом транспортного режима:

• сохраняются адреса IP исходного селектора трафика, как полученные адреса отправителя и получателя на случай необходимости их восстановления с целью использования, как «реальных адресов отправителя и получателя», описанного в [UDPENCAPS], и расчёта. контрольных сумм TCP/UDP;

• если клиент расположен за транслятором NAT, адрес IP в TSi заменяется удаленным адресом IKE SA;

• если сервер расположен за транслятором NAT, адрес IP в TSr заменяется локальным адресом IKE SA;

• выполняется поиск в базах PAD и SPD с использованием ID и селекторов трафика с заменёнными адресами;

• если в SPD не найдено записи или найденная запись не разрешает транспортный режим, восстанавливаются селекторы трафика с обратной подстановкой адресов; выполняется новый поиск в базах PAD и SPD с использованием ID и селекторов трафика с исходными адресами, а также поиск записи SPD для туннельного режима (с целью перехода в этот режим);

• если запись SPD найдена, выполняется обычное сужение селекторов трафика на основе Traffic Selector с подстановкой адресов и записи SPD; полученные в результате селекторы трафика применяются для создания записей SAD и передачи селекторов трафика обратно клиенту.

2.24. Явное уведомление о перегрузке (ECN)

При развёртывании туннелей IPsec в соответствии с исходной спецификацией [IPSECARCH-OLD], использование ECN⁴⁵ во внешних заголовках IP было, по сути, невозможно, поскольку при декапсуляции туннеля индикаторы перегрузки ECN, появившиеся в сети, отбрасывались. Поддержка ECN для туннелей IPsec на базе IKEv1 требует множества режимов работы и согласований (см. [ECN]). IKEv2 упрощает ситуацию, вводя требование возможности использования ECN во внешних заголовках IP для всех IPsec SA в туннельном режиме, создаваемых IKEv2. В частности, точки инкапсуляции и декапсуляции туннельных SA, создаваемых IKEv2, должны поддерживать опцию полной функциональности ECN для туннелей, заданную в [ECN], а также должны реализовать инкапсуляцию и декапсуляцию в соответствии с [IPSECARCH] для предотвращения отбрасывания индикации перегрузки ECN.

2.25. Конфликты при обменах

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

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

Следует передавать уведомление TEMPORARY_FAILURE в тех случаях, когда принятый запрос временно не может быть выполнен (например, по причине смены ключей). При получении партнёром уведомления TEMPORARY_FAILURE ему недопустимо сразу же повторять запрос, он должен дать отправителю время на завершение операции вызвавшей временный отказ. Получатель уведомления может повторить запрос один или множество раз в течение нескольких минут. Если продолжают поступать уведомления TEMPORARY_FAILURE для той же IKE SA по истечении нескольких минут, следует принять решение о наличии рассинхронизации данных о состоянии и закрыть IKE SA.

Следует передавать уведомление CHILD_SA_NOT_FOUND при получении запроса на смену ключей для несуществующей связи Child SA. Связь SA, для которой инициатор пытается сменить ключ, указывается полем SPI в элементе Notify, которое копируется из поля SPI в уведомлении REKEY_SA. При получении уведомления CHILD_SA_NOT_FOUND следует удалить Child SA (если она ещё существует) и отправить запрос на создание новой Child SA с нуля (если Child SA ещё не существует).

2.25.1. Конфликты во время смены ключей или закрытия дочерних SA

Если партнер получает запрос на смену ключей Child SA, для которой в данный момент выполняется попытка завершения, ему следует ответить сообщением TEMPORARY_FAILURE. Если такой запрос поступает во время происходящей уже замены ключей, на него следует ответить обычным способом, а также следует подготовиться к последующему закрытию избыточных SA на базе значений nonce (см. параграф 2.8.1). Если приходит запрос смены ключей для отсутствующей Child SA, на него следует ответить сообщением CHILD_SA_NOT_FOUND.

При получении запроса на закрытие Child SA, для которой уже начата попытка закрытия, на него следует ответить без элемента Delete (см. параграф 1.4.1). Если такой запрос приходит для Child SA, в которой меняются ключи, на него следует отвечать обычным путём с элементом Delete. При получение запроса на закрытие отсутствующей Child SA следует отвечать без элемента Delete.

При получении запроса на смену ключей IKE SA, в которой происходит создание, смена ключей или закрытие Child SA в данной IKE SA следует отвечать на него сообщением TEMPORARY_FAILURE.

2.25.2. Конфликты во время замены ключей или закрытия IKE SA

При получении запроса на смену ключей IKE SA, в которой уже идёт процесс смены ключей, не него следует отвечать обычным способом, а также следует приготовиться к последующему закрытию избыточных SA и переносу наследуемых Child SA на основе значений nonce (см. параграф 2.8.2). При получении такого запроса для закрываемой в данный момент IKE SA на него следует отвечать сообщением TEMPORARY_FAILURE.

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

При получении запроса на создание или смену ключей Child SA во время смены ключей IKE SA на него следует отвечать сообщением TEMPORARY_FAILURE. При получении запроса на удаление Child SA во время смены ключей IKE SA следует отвечать обычным способом с элементом Delete.

3. Форматы заголовков и данных

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

3.1. Заголовок IKE

Сообщения IKE используют протокол UDP через порты 500 и/или 4500, передаётся по одному сообщению IKE в дейтаграмме UDP. Информация от начала пакета до завершения заголовка UDP большей частью игнорируется, исключения составляют адреса IP и номера портов UDP в заголовках, которые сохраняются и используются для передачи ответных пакетов. При передаче через порт UDP 500 сообщение IKE начинается непосредственно после заголовка UDP. При передаче через порт UDP 4500 перед сообщением IKE помещается четыре октета с нулевыми значениями. Эти октеты не являются частью сообщения IKE и не учитываются в размерах и контрольных суммах IKE. Каждое сообщение IKE начинается с заголовка IKE, обозначаемого в данном документе HDR. После заголовка следует один или множество элементов данных IKE, каждый из которых идентифицируется полем Next Payload в предыдущем элементе данных. Элементы данных идентифицируются в порядке их следования в сообщении IKE путём вызова соответствующей процедуры, согласно значению поля Next Payload в заголовке IKE, потом согласно значению Next Payload в первом элементе данных IKE и так далее, пока в поле Next Payload не будет обнаружено нулевое значение, показывающее отсутствие следующего элемента данных. При обнаружении элемента данных типа Encrypted этот элемент дешифруется и результат расшифровки разбирается, как дополнительные элементы данных. Элемент Encrypted должен быть последним элементом в пакете и включать в зашифрованные элементы другие элементы типа Encrypted недопустимо.

Значение Recipient SPI в заголовке идентифицирует экземпляр защищённой связи IKE. Следовательно, один экземпляр IKE может мультиплексировать различные сессии с множеством партнёров, а также множество сессий с одним партнёром.

Многооктетные поля, представляющие собой целые числа используют сетевой порядок байтов (или big endian — старший байт сначала).

Рисунок 4 показывает формат заголовка IKE.

                     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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       IKE SA Initiator's SPI                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       IKE SA Responder's SPI                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Next Payload | MjVer | MnVer | Exchange Type |     Flags     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Message ID                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Length                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 4. Формат заголовка IKE.

Initiator’s SPI (8 октетов)

Значение, выбранное инициатором для уникальной идентификации IKE Security Association. Нулевое значение недопустимо.

Responder’s SPI (8 октетов)

Значение, выбранное ответчиком для уникальной идентификации IKE Security Association. Это поле должно иметь значение 0 в первом сообщении начального обмена IKE (включая повторы этого сообщения, содержащие cookie).

Next Payload (1 октет)

Указывает тип элемента данных, расположенного сразу после заголовка. Форматы и значения всех типов описаны ниже.

Major Version (4 бита)

Указывает старшую часть номера версии используемого протокола IKE. Реализации на основе данной версии IKE, должны устанавливать Major Version=2. Реализации, основанные на предыдущих версиях IKE и ISAKMP, должны устанавливать Major Version=1. Основанные на этой версии протокола IKE реализации должны отвергать или игнорировать пакеты со значением этого поля, превышающим 2, возвращая уведомление INVALID_MAJOR_VERSION, как описано в параграфе 2.5.

Minor Version (4 бита)

Указывает младшую часть номера версии IKE. Реализации на основе этого документа должны устанавливать Minor Version = 0 и игнорировать младшую часть номера в принимаемых сообщениях.

Exchange Type (1 октет)

Указывает тип обмена, который будет применяться. Это значение ограничивает тип элементов данных, передаваемых в каждом сообщении обмена. Приведённые в таблице значения типов были определены на момент публикации RFC 4306. Другие значения могли быть добавлены с тех пор и могут добавляться после публикации этого документа. Актуальный набор значений можно найти в [IKEV2IANA].

 

Тип обмена	Значение
IKE_SA_INIT	34
IKE_AUTH	35
CREATE_CHILD_SA	36
INFORMATIONAL	37

 

Flags (1 октет)

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

        +-+-+-+-+-+-+-+-+
        |X|X|R|V|I|X|X|X|
        +-+-+-+-+-+-+-+-+

В приведённых ниже описаниях установленные флаги имеют значение 1, сброшенные — 0. Флаги, обозначенные символом X должны быть сброшены при передаче, а на приёмной стороне должны игнорироваться.

R (Response)

Этот флаг указывает, что сообщение является откликом на сообщение с таким же Message ID. Флаг должен быть сброшен во всех запросах и должен устанавливаться во всех откликах. Конечным точкам IKE недопустимо генерировать отклики на сообщения, помеченные как отклики (с одним исключением, описанным в параграфе 2.21.2).

V (Version)

Этот флаг показывает, что передающая сторона может поддерживать более высокое значение старшего номера версии протокола, нежели указано в поле Major version. Реализации IKEv2 должны сбрасывать этот бит при передаче и игнорировать его в принимаемых сообщениях.

I (Initiator)

Этот бит должен устанавливаться в сообщениях, передаваемых исходным инициатором IKE SA, и должен сбрасываться в сообщениях от исходного ответчика. Флаг используется получателем для того, чтобы определить, какие 8 октетов SPI были созданы получателем. Значение бита меняется в соответствии с тем, кто инициировал последнюю смену ключей IKE SA.

Message ID (4 октета, целое число без знака)

Идентификатор сообщения, используемый для управления повтором передачи потерянных пакетов и определения соответствия между запросами и откликами. Идентификатор играет важную роль в безопасности протокола, поскольку служит для предотвращения атак с повторным использованием пакетов (см. параграфы 2.1 и 2.2).

Length (4 октета, целое число без знака)

Размер всего сообщения (заголовок и элементы данных) в октетах.

3.2. Базовый заголовок элемента данных

Каждый из элементов данных (payload) IKE, определённых в параграфах 3.3 — 3.16, начинается с базового заголовка (Рисунок 5). Рисунки в описании каждого элемента включают базовый заголовок, но описания полей этого заголовка для краткости опущены и приводятся только в этом параграфе.

                     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 Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 5. Базовый заголовок элемента данных.

Next Payload (1 октет)

Идентификатор типа следующего элемента данных в сообщении. Если текущий элемент является последним, это поле имеет значение 0. Это поле позволяет создавать «цепочки», когда дополнительный элемент просто добавляется в конец сообщения и устанавливается значение поля Next Payload в предыдущем элементе для индикации типа нового элемента. Элемент типа Encrypted, который всегда должен быть последним в сообщении, является исключением. Он содержит структуры данных в формате дополнительных элементов. В заголовке элемента Encrypted поле Next Payload устанавливается в соответствии с типом первого вложенного элемента (вместо 0), а в поле Next Payload последнего вложенного элемента устанавливается 0. Значения типов элементов данных показаны в таблице. Эти значения были определены на момент публикации RFC 4306. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

 

Тип следующего элемента данных	Обозначение	Значение
Нет		0
Защищённая связь	SA	33
Обмен ключами	KE	34
Идентификация — инициатор	IDi	35
Идентификация — ответчик	IDr	36
Сертификат	CERT	37
Запрос сертификата	CERTREQ	38
Аутентификация	AUTH	39
Nonce	Ni, Nr	40
Уведомление	N	41
Удаление	D	42
Идентификатор производителя	V	43
Селектор трафика — инициатор	TSi	44
Селектор трафика — ответчик	TSr	45
Зашифрованные и аутентифицированные	SK	46
Конфигурация	CP	47
Расширяемая аутентификация	EAP	48

 

Значения 1 — 32 не были распределены для того, чтобы не возникало перекрытия с кодами, определёнными для IKEv1.

Critical (1 бит)

Это поле должно иметь значение 0, если отправитель хочет, чтобы получатель пропустил этот элемент в случае непонимания им кода в поле Next Payload предыдущего элемента. Поле должно иметь значение 1, если отправитель хочет, чтобы получатель целиком отвергал сообщение с непонятным типом элемента данных. Если получатель понимает тип элемента, он должен игнорировать этот флаг. Это поле должно устанавливаться в 0 для определённых в документе типов элементов данных. Отметим, что флаг критичности относится к текущему элементу данных, а не к следующему, чей тип указывается в первом октете. Причина сбрасывания бита критичности для всех определённых здесь элементов заключается в том, что все реализации должны поддерживать все типы элементов, определённые в этой спецификации, и, следовательно, должны игнорировать значение флага Critical. Предполагается, что пропускаемые элементы будут иметь корректные значения полей Next Payload и Payload Length. Дополнительная информация об этом флаге приведена в параграфе 2.5.

RESERVED (7 битов)

Должен устанавливаться в 0 при передаче и игнорироваться на приёмной стороне.

Payload Length (2 октета, целое число без знака)

Размер текущего элемента данных в октетах с учётом базового заголовка элемента данных.

Многие элементы данных содержат резервные (RESERVED) поля. Некоторые элементы данных в IKEv2 (и в IKEv1) не выравниваются по 4-октетным границам.

3.3. Элемент данных SA

Элементы данных защищённой связи, обозначаемые в этом документе SA, служат для согласования атрибутов защищённой связи. Сборка элементов данных SA требует внимания. Элемент SA может включать множество предложений. Если предложений больше одного, они должны быть упорядочены в порядке снижения предпочтительности. Каждое предложение включает один протокол IPsec (протоколами являются IKE, ESP, AH), каждый протокол может включать множество преобразований, а каждое преобразование может включать множество атрибутов. При разборе SA реализация должна проверить соответствие значения Payload Length размерам и числу отдельных компонент. Предложения (Proposal), преобразования (Transform) и атрибуты (Attribute) используют своё представление с различными размерами. Они вкладываются в элемент так, чтобы значение поля Payload Length элемента SA учитывало данные SA, Proposal, Transform и Attribute. Размер Proposal включает размер всех содержащихся в нем Transform и Attribute. Размер Transform включает размеры всех содержащихся в нем Attribute.

Синтаксис элементов SA, Proposal, Transform и Attribute основан на ISAKMP, однако семантика их слегка отличается. Причина использования иерархической структуры заключается в том, что такая структура позволяет представлять в одной SA множество возможных комбинаций алгоритмов. Иногда предоставляется выбор из множества алгоритмов, в других случаях — комбинация алгоритмов. Например, инициатор может предложить использование ESP с комбинацией (3DES и HMAC_MD5) или с комбинацией (AES и HMAC_SHA1).

Одной из причин изменения семантики элементов SA по сравнению с ISAKMP и IKEv1 является повышение уровня компактности представления в наиболее распространённых случаях.

Структура Proposal включает Proposal Num (номер предложения) и идентификатор протокола IPsec. Каждая структура должна использовать номер предложения, увеличенный на 1 по сравнению со значением в предыдущей структуре. Первый элемент Proposal в SA инициатора должен иметь Proposal Num = 1. Одной из причин использования множества предложений является обеспечение возможности предложить использования стандартных и комбинированных шифров. Комбинированные шифры обеспечивают шифрование и защиту целостности на основе одного алгоритма и должны не предлагать алгоритма защиты целостности или предлагать алгоритм none (первый вариант является рекомендуемым). Если инициатор хочет предложить комбинированные и стандартные шифры, он должен включить два предложения — одно включает все комбинированные алгоритмы, а другое — все обычные алгоритмы в комбинации с алгоритмами защиты целостности. Например, одно такое предложение будет включать две структуры Proposal. Первая структура Proposal 1 предлагает ESP с ключами AES-128, AES-192, AES-256 в режиме CBC⁴⁶ и алгоритмом защиты целостности HMAC-SHA1-96 или XCBC-96, а вторая структура Proposal 2 предлагает AES-128 или AES-256 в режиме GCM с 8-октетным значением контроля чётности (ICV⁴⁷). Оба предложения позволяют, но не требуют использовать расширенные порядковые номера ESN⁴⁸. Вид предложений представлен на рисунке.

   Элемент SA 
      |
      +--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4,
      |     |            7 преобразований,      SPI = 0x052357bb )
      |     |
      |     +-- Преобразование ENCR ( Name = ENCR_AES_CBC )
      |     |     +-- Атрибут ( Key Length = 128 )
      |     |
      |     +-- Преобразование ENCR ( Name = ENCR_AES_CBC )
      |     |     +-- Атрибут ( Key Length = 192 )
      |     |
      |     +-- Преобразование ENCR ( Name = ENCR_AES_CBC )
      |     |     +-- Атрибут ( Key Length = 256 )
      |     |
      |     +-- Преобразование INTEG ( Name = AUTH_HMAC_SHA1_96 )
      |     +-- Преобразование INTEG ( Name = AUTH_AES_XCBC_96 )
      |     +-- Преобразование ESN ( Name = ESN )
      |     +-- Преобразование ESN ( Name = не ESN )
      |
      +--- Proposal #2 ( Proto ID = ESP(3), размер SPI = 4,
            |            4 преобразования,      SPI = 0x35a1d6f2 )
            |
            +-- Преобразование ENCR ( Name = AES-GCM с 8 октетами ICV )
            |     +-- Атрибут ( Key Length = 128 )
            |
            +-- Преобразование ENCR ( Name = AES-GCM с 8 октетами ICV )
            |     +-- Атрибут ( Key Length = 256 )
            |
            +-- Преобразование ESN ( Name = ESN )
            +-- Преобразование ESN ( Name = не ESN )

За каждой структурой Proposal/Protocol следует одна или множество структур преобразований. Число разных преобразований обычно определяется элементом Protocol. Протокол AH обычно имеет два преобразования — расширенные порядковые номера (ESN⁴⁹) и алгоритм контроля целостности. ESP обычно имеет три преобразования — ESN, алгоритм шифрования и алгоритм контроля целостности. IKE обычно имеет четыре преобразования — группа Diffie-Hellman, алгоритм контроля целостности, алгоритм PRF и алгоритм шифрования. Для каждого элемента Protocol набор разрешённых преобразований указывается значениями Transform ID после заголовка каждого преобразования.

Если имеется множество преобразований с одним значением Transform Type, они должны комбинироваться в одно предложение с помощью операции ИЛИ⁵⁰. При наличии множества преобразований различных типов, группы объединяются операцией И. Например, чтобы предложить ESP с (3DES или IDEA) и (HMAC_MD5 или HMAC_SHA), предложение ESP будет включать два кандидата Transform Type 1 (один для 3DES, второй для IDEA) и два кандидата Transform Type 3 (для HMAC_MD5 и HMAC_SHA). Это обеспечивает эффективное предложение четырёх комбинаций алгоритмов. Если инициатор хочет предложить только подмножество этого — например, (3DES и HMAC_MD5) или (IDEA и HMAC_SHA), — не существует возможности представить это в виде множества преобразований в одном предложении. Взамен инициатор будет создавать два разных предложения по паре преобразований в каждом.

Преобразование может иметь один или множество атрибутов (Attribute). Атрибуты требуются, когда преобразование может использоваться множеством способов (например, алгоритм шифрования с переменным размером ключей — преобразование будет задавать алгоритм, а атрибут — размер ключа). Большинство преобразований не имеет атрибутов. Для преобразования недопустимо наличие множества однотипных атрибутов. Чтобы предложить варианты значения для атрибута (например, множество размеров ключа для алгоритма шифрования AES), реализация должна включать множество преобразований с общим значением Transform Type, каждое из которых имеет один атрибут (Attribute).

                     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 Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                          <Proposals>                          ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 6. Элемент данных SA.

Отметим, что семантика Transform и Attribute достаточно сильно отличается от IKEv1. В IKEv1 одно преобразование задаёт множество алгоритмов для протокола и один из них передаётся в Transform, а другие в Attribute.

Proposals (переменный размер)

Одна или множество субструктур Proposal.

Идентификатор типа для элемента данных SA имеет значение 33.

3.3.1. Субструктура Proposal

                     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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (last) или 2|   RESERVED    |         Proposal Length       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proposal Num  |  Protocol ID  |    SPI Size   |Num  Transforms|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    SPI (переменный размер)                    ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                        <Transforms>                           ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 7. Субструктура Proposal.

0 (последнее) или 2 (не последнее) (1 октет)

Указывает, является ли данная субструктура Proposal последней в SA. Синтаксис поля унаследован от ISAKMP, но не является требуемым, поскольку последнюю субструктуру Proposal можно идентифицировать по размеру SA. Значение (2) соответствует элементу данных типа Proposal в IKEv1, а первые 4 октета субструктуры Proposal организованы так, чтобы выглядеть подобно заголовку элемента данных.

RESERVED (1 октет)

Должно устанавливаться в 0 при передаче и игнорироваться при получении.

Proposal Length (2 октета, целое число без знака)

Размер данной субструктуры Proposal с учётом всех следующих за ним преобразований и атрибутов.

Proposal Num (1 октет)

Когда предложение вносится, первое из предложений в данных SA должно иметь номер 1, а последующие должны иметь номера на 1 больше своего предшественника (указывается оператором OR между предложениями). Когда предложение принимается, его номер в элементе данных SA должен совпадать с номером, с которым оно было передано.

 

Протокол	Идентификатор
IKE	1
AH	2
ESP	3

 

Protocol ID (1 октет)

Задаёт идентификатор протокола IPsec для текущего согласования. Определённые на момент публикации RFC 4306 значения идентификаторов показаны в таблице. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

SPI Size (1 октет)

Для начального согласования IKE_SA это поле должно иметь нулевое значение; значение SPI получается из внешнего заголовка. При последующих согласованиях это поле показывает размер (в октетах) SPI для соответствующего протокола (8 для IKE, 4 для ESP и AH).

Num Transforms (1 октет)

Указывает число преобразований в этом предложении.

SPI (переменный размер)

Значение SPI передающей стороны. Даже при SPI Size не кратном 4 октетам заполнение для этого поля не применяется. При SPI Size = 0 это поле отсутствует в элементе данных SA.

Transforms (переменный размер)

Одна или множество субструктур Transform.

3.3.2. Субструктура Transform

                     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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 (last) или 3|   RESERVED    |        Transform Length       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Transform Type |   RESERVED    |          Transform ID         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                      Transform Attributes                     ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 8. Субструктура Transform.

0 (последнее) или (не последнее) (1 октет)

Указывает, является ли данная субструктура Transform последней в Proposal. Синтаксис поля унаследован от ISAKMP, но не является требуемым, поскольку последнюю субструктуру Transform можно идентифицировать по размеру Proposal. Значение (3) соответствует элементу данных типа Transform в IKEv1, а первые 4 октета субструктуры Transform организованы так, чтобы выглядеть подобно заголовку элемента данных.

RESERVED

Должно устанавливаться в 0 при передаче и игнорироваться при получении.

Transform Length

Размер данной субструктуры Transform с учётом всех следующих за ним преобразований и атрибутов.

Transform Type (1 октет)

Тип преобразования, задаваемого этой субструктурой. Различные протоколы поддерживают разные значения Transform Type. Для некоторых протоколов отдельные преобразования могут быть необязательными. Если преобразование не является обязательным, а инициатор желает внести предложение без него, такое преобразование просто опускается. Если инициатор хочет передать решение вопроса использования необязательного преобразования ответчику, он включает эту субструктуру с Transform ID = 0 в качестве одной из опций.

Transform ID (2 октета)

Указывает конкретный экземпляр Transform Type, который будет предложен.

Значения Transform Type, приведённые в таблице, отражают типы, определённые на момент публикации RFC 4306. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

 

Описание	Тип	Применение
Алгоритм шифрования (ENCR)	1	IKE и ESP
Псевдослучайная функция (PRF)	2	IKE
Алгоритм защиты целостности (INTEG)	3	IKE51, AH, опционально в ESP
Группа Diffie-Hellman (D-H)	4	IKE, может использоваться также в AH и ESP
Расширенные порядковые номера (ESN)	5	AH и ESP

 

Для преобразований типа 1 (Transform Type 1, алгоритм шифрования) значения идентификаторов преобразования (Transform ID) приведены в таблице слева, включающей идентификаторы, определённые на момент публикации RFC 4306. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

 

Имя	Номер	Документ
ENCR_DES_IV64	1	Нет спецификации
ENCR_DES	2	RFC2405, [DES]
ENCR_3DES	3	RFC2451
ENCR_RC5	4	RFC2451
ENCR_IDEA	5	RFC2451, [IDEA]
ENCR_CAST	6	RFC2451
ENCR_BLOWFISH	7	Нет спецификации
ENCR_3IDEA	8	Нет спецификации
ENCR_DES_IV32	9	Нет спецификации
ENCR_NULL	11	RFC2410
ENCR_AES_CBC	12	RFC3602
ENCR_AES_CTR	13	RFC3686

 

Для преобразований типа 2 (Transform Type 2, псевдослучайная функция) значения Transform ID приведены в таблице, включающей идентификаторы, определённые на момент публикации RFC 4306. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

 

Имя	Номер	Документ
PRF_HMAC_MD5	1	RFC2104, [MD5]
PRF_HMAC_SHA1	2	RFC2104, [SHA]
PRF_HMAC_TIGER	3	Нет спецификации

 

Для преобразований типа 3 (Transform Type 3, алгоритм защиты целостности) значения Transform ID приведены в таблице справа, включающей идентификаторы, определённые на момент публикации RFC 4306. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

 

Имя	Номер	Документ
NONE	0
AUTH_HMAC_MD5_96	1	RFC2403
AUTH_HMAC_SHA1_96	2	RFC2404
AUTH_DES_MAC	3	Нет спецификации
AUTH_KPDK_MD5	4	Нет спецификации
AUTH_AES_XCBC_96	5	RFC3566

 

Для преобразований типа 4 (Transform Type 4, группа Diffie-Hellman) значения Transform ID приведены в таблице слева, включающей идентификаторы, определённые на момент публикации RFC 4306. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

 

Имя	Номер	Документ
NONE	0
768-битовый MODP	1	Приложение B
1024-битовый MODP	2	Приложение B
1536-битовый MODP	5	[ADDGROUP]
2048-битовый MODP	14	[ADDGROUP]
3072-битовый MODP	15	[ADDGROUP]
4096-битовый MODP	16	[ADDGROUP]
6144-битовый MODP	17	[ADDGROUP]
8192-битовый MODP	18	[ADDGROUP]

 

Хотя протоколы ESP и AH не включают напрямую обмена Diffie-Hellman, группа DH может быть согласована для Child SA. Это позволяет партнёрам использовать метод Diffie-Hellman в обмене CREATE_CHILD_SA для обеспечения совершенной защиты генерируемых ключей Child SA.

Для преобразований типа 5 (Transform Type 5, расширенные порядковые номера ESN) значения Transform ID приведены в таблице справа, включающей идентификаторы, определённые на момент публикации RFC 4306. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

 

Имя	Номер
Нет ESN	0
ESN	1

 

Отметим, что инициатор, поддерживающий ESN, обычно будет включать два преобразования ESN со значениями 0 и 1 в своих предложениях. Предложения, включающие только преобразование ESN со значением 1, означает отказ от применения обычных (не расширенных) порядковых номеров.

После RFC 4306 было добавлено множество значения Transform Type, которые можно найти в реестре IANA IKEv2.

3.3.3. Приемлемые типы преобразований для протоколов

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

 

Протокол	Обязательные типы	Опциональные типы
IKE	ENCR, PRF, INTEG52, D-H
ESP	ENCR, ESN	INTEG, D-H
AH	INTEG, ESN	D-H

 

3.3.4. Обязательные Transform ID

Указание шифронаборов, которые должно и следует поддерживать для взаимодействия, было удалено из этого документа, поскольку стало ясно, что эти списки будут меняться чаще, нежели обновляется документ. На момент публикации этого документа такие шифронаборы были указаны в [RFC4307], но следует отметить, что этот список может быть обновлён в будущем, а другие RFC могут задавать другие наборы шифров.

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

Очевидно, что IANA будет добавлять новые преобразования, а некоторые пользователи могут применять приватные шифронаборы, особенно для IKE, где разработчикам следует обеспечивать поддержку различных параметров, вплоть до некоторых ограничений размера. В поддержку этой идеи всем реализациям IKEv2 следует включать средства управления, которые позволяют (пользователю или системному администратору) задавать параметры Diffie-Hellman (генератор, модуль, размер и значения экспоненты) для новых групп DH. Разработчикам следует поддерживать интерфейс управления, через который могут задаваться эти параметры и связанные с ними Transform ID (пользователем или системным администратором) для обеспечения возможности согласования таких групп.

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

3.3.5. Атрибуты преобразования

                     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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|       Attribute Type        |    AF=0  Attribute Length     |
|F|                             |    AF=1  Attribute Value      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   AF=0  Attribute Value                       |
|                   AF=1  Not Transmitted                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 9. Атрибуты преобразования.

Каждое преобразование в элементе SA может включать атрибуты, меняющие или дополняющие спецификацию преобразования. Эти атрибуты представляют собой пары «тип-значение» и определены ниже. Например, если алгоритм шифрования имеет ключи переменного размера, этот размер может задаваться в качестве атрибута. Атрибуты могут иметь значение фиксированного (2 октета) или переменного размера. В последнем случае для представления атрибута используется формат «тип-размер-значение».

Attribute Format (AF) (1 бит)

Указывает использование для данных атрибута формата TLV⁵³ или более короткого TV⁵⁴. Нулевое значение флага AF говорит о формате TLV, а 1 — о формате TV (2-байтовое значение).

Attribute Type (15 битов)

Уникальный идентификатор типа атрибута (см. ниже).

Attribute Value (переменный размер)

Значение атрибута указанного типа. Если бит AF сброшен (0), это поле имеет переменный размер, указанный полем Attribute Length. При установленном (1) флаге AF поле Attribute Value имеет размер 2 октета.

Единственным определенным в настоящее время атрибутом является размер ключа (Key Length) и для него используется фиксированный размер. Спецификации атрибутов переменной длины включены только для будущих расширений. Атрибуты, описанные в качестве базовых, недопустимо представлять с использованием переменного размера. Атрибуты переменного размера недопустимо представлять в качестве базовых, даже если их значение может быть помещено в два октета. Отметим, что это отличается от IKEv1 тем, что повышается гибкость и упрощается создание сообщений, но несколько усложняется их разбор.

 

Тип атрибута	Значение	Формат атрибута
Key Length (в битах)	14	TV

 

В таблице указано значение, определённое на момент публикации RFC 4306. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

Значения 0 — 13 и 15 — 17, использовались в похожем контексте IKEv1 и их не следует выделять без наличия совпадений.

Атрибут Key Length указывает размер ключа в битах (должен использоваться сетевой порядок байтов) для некоторых преобразований, как описано ниже.

• Атрибут Key Length недопустимо использовать в преобразованиях с фиксированным размером ключа. Например, к таким преобразованиям относятся ENCR_DES, ENCR_IDEA, а также все преобразования Type 2 (псевдослучайная функция) и Type 3 (защита целостности), описанные в этом документе.

• Для некоторых преобразований атрибут Key Length должен включаться всегда (пропускать атрибут не разрешается и преобразования без него должны отвергаться). Примерами могут служить преобразования ENCR_AES_CBC и ENCR_AES_CTR.

• В некоторых преобразованиях с переменным размером ключей устанавливается используемый по умолчанию размер. Примерами таких преобразований являются ENCR_RC5 и ENCR_BLOWFISH.

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

Поддержка такой возможности позволяет ответчику выразить концепцию «не ниже» некоторого уровня защиты — «размер ключа не менее X битов для шифра Y». Однако, поскольку атрибут всегда возвращается неизменным (см. следующий параграф), инициатору, желающему воспринимать разные размеры ключей, следует включать множество преобразования одного типа, каждое из которых имеет свой атрибут Key Length.

3.3.6. Согласование атрибутов

При согласовании защищённой связи инициаторы вносит свои предложения ответчикам. Ответчики должны выбрать из предложений один полный набор параметров (или отвергнуть все предложения, если они не подходят). Если имеется множество предложений, ответчик должен выбрать одно из них. Если выбранное предложение включает множество однотипных преобразований, ответчик должен выбрать одно из них. Все атрибуты выбранного преобразования должны возвращаться в неизменном виде. Инициатор обмена должен убедиться в том, что принятое предложение согласуется со сделанными им предложениями. При наличии расхождений отклик должен быть отвергнут.

Если ответчик получает предложение с непонятным Transform Type или в предложении отсутствует обязательный тип преобразования, такое предложение должно рассматриваться, как неприемлемое, однако другие предложения из того же элемента SA обрабатываются обычным путём. Аналогично, если ответчик получает преобразование непонятного типа или с непонятным значением Transform Attribute, он должен рассматривать такое преобразование, как неприемлемое, сохраняя обычную обработку других преобразований с тем же Transform Type. Это позволит определят в будущем новые значения Transform Type и Transform Attribute.

Согласование групп Diffie-Hellman имеет некоторые особенности. SA включает предлагаемые атрибуты и открытое значение Diffie-Hellman (KE⁵⁵) в одном сообщении. Если в начальном обмене инициатор предлагает использовать одну из нескольких групп Diffie-Hellman, ему следует выбрать ту, которую ответчик с высокой вероятностью примет, и включить соответствующее этой группе значение KE. Если ответчик выберет предложение с другой группой DH (отличной от NONE), он укажет в отклике корректную группу и инициатору следует найти для своего KE элемент в этой группе при повторе сообщения. Однако ему следует по-прежнему предлагать полный набор поддерживаемых групп, чтобы предотвратить возможность организации атак, направленных на снижение уровня защиты. Если одним из предложений для группы DH является NONE и ответчик выбирает предложение, он должен игнорировать элемент KE инициатора и не включать KE в свой отклик.

3.4. Элемент Key Exchange

                     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 Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Diffie-Hellman Group Num    |           RESERVED            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                       Key Exchange Data                       ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 10. Формат элемента Key Exchange.

Элемент данных Key Exchange (KE) служит для обмена открытыми значениями Diffie-Hellman в процессе обмена ключами Diffie-Hellman. Элемент Key Exchange состоит из базового заголовка данных IKE, за которым следует открытое значение Diffie-Hellman.

KE создаётся путём копирования открытого значения Diffie-Hellman в поле Key Exchange Data. Размер открытого значения DH для модульных экспоненциальных групп (MODP⁵⁶) должен совпадать с размером простого числа (prime modulus), которое возводится в степень. При необходимости поле заполняется нулями слева (prepend).

Поле Diffie-Hellman Group Num указывает группу DH, в которой будет рассчитываться Key Exchange Data (см. параграф 3.3.2). Поле Diffie-Hellman Group Num должно соответствовать группе DH, заданной в предложении элемента данных SA, переданного в том же сообщении, следует также обеспечивать соответствие группе DH в первой группе первого предложения, если она указана. Если ни одно из предложений с данном элементе SA не указывает группу DH, наличие элемента KE недопустимо. Если выбранное предложение использует другую группу DH (отличную от NONE), сообщение должно быть отвергнуто с возвратом элемента Notify типа INVALID_KE_PAYLOAD. См. также параграфы 1.2 и 2.7.

Идентификатор типа для элемента Key Exchange имеет значение 34.

3.5. Элемент Identification

Элемент данных Identification (ID), обозначаемый в этом документе IDi и IDr, позволяет партнёрам предъявлять свою идентификацию другой стороне. Эта идентификация может использоваться при просмотре политики, но не обязана соответствовать информации в элементе CERT — оба эти поля могут использоваться реализацией для контроля доступа. При использовании отождествлений типа ID_IPV4_ADDR/ID_IPV6_ADDR в элементах IDi/IDr протокол IKEv2 не требует соответствия этих адресов адресам в заголовках IP пакетов IKEv2 или содержимом элементов TSi/TSr. Информация IDi/IDr используется исключительно для выбора политики и аутентификационных данных, относящихся к другой стороне.

Примечание. В IKEv1 использовались два элемента ID в каждом направлении для данных селекторов трафика (TS) для данных, передаваемого через SA. В IKEv2 эта информация передаётся в элементах TS (см. параграф 3.13).

База данных PAD⁵⁷, как указано в RFC 4301 [IPSECARCH], описывает использование элемента ID в IKEv2 и обеспечивает формальную модель для привязки отождествления в политики в дополнение к службам, связанным более конкретно с исполнением политики. PAD предназначена для обеспечения связи между SPD и управления IKE Security Association (дополнительную информацию можно найти в параграфе 4.4.3 RFC 4301).

                     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 Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   ID Type     |                 RESERVED                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                   Identification Data                         ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 11. Формат данных Identification.

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

ID Type (1 октет)

Задаёт тип используемой идентификации.

RESERVED

Должно устанавливаться в 0 при передаче и игнорироваться при получении.

Identification Data (переменный размер)

Значение, определяемое полем Identification Type. Размер идентификационных данных рассчитывается из размера в заголовке элемента ID.

Идентификатор типа для элемента Identification имеет значение 35 в случае IDi и 36 в случае IDr.

В таблице приведены значения типов идентификации, выделенные на момент публикации RFC 4306. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

 

ID Type	Значение	Описание Identification Data
ID_IPV4_ADDR	1	Один четырёхоктетный адрес IPv4.
ID_FQDN	2	Строка полного доменного имени (например, example.com). В строку недопустимо включать символы завершения (NULL, CR и т. п.). Все символы ID_FQDN указываются в кодировке ASCII, для доменных имён на других языках применяется синтаксис, определённый в [IDNA] (например, xn--tmonesimerkki-bfbb.example.net).
ID_RFC822_ADDR	3	Строка полного почтового адреса RFC822 (например, jsmith@example.com). В строку недопустимо включать символы завершения. С учётом [EAI] реализациям уместно трактовать эту строку, как текст UTF-8, а не ASCII.
ID_IPV6_ADDR	5	Один шестнадцатиоктетный адрес IPv6.
ID_DER_ASN1_DN	9	Двоичное представление в формате DER58 для ASN.1 X.500 Distinguished Name [PKIX].
ID_DER_ASN1_GN	10	Двоичное представление в формате DER для ASN.1 X.500 GeneralName [PKIX].
ID_KEY_ID	11	Неструктурированный поток октетов, который может использоваться для передачи связанной с производителем информации, требуемой для некоторых фирменных вариантов идентификации.

 

Две реализации будут совместимы только в том случае, когда каждая может генерировать тип ID, приемлемый для другой стороны. Для обеспечения максимальной совместимости реализация должна быть настраиваемой на передачу по крайней мере одного из типов ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, ID_KEY_ID и восприятие всех этих типов. Реализациям следует обеспечивать возможность генерации и восприятия всех этих типов. Поддерживающие IPv6 реализации должны дополнительно иметь возможность настройки восприятия ID_IPV6_ADDR. Реализации, поддерживающие только IPv6, можно настраивать на передачу только ID_IPV6_ADDR вместо ID_IPV4_ADDR.

EAP [EAP] не требует использования какого-либо конкретного типа идентификаторов, но зачастую EAP применяется с идентификаторами NAI⁵⁹, определёнными в [NAI]. Хотя идентификаторы NAI похожи на адреса электронной почты (например, joe@example.com), их синтаксис отличается от синтаксиса почтовых адресов [MAILFORMAT]. По этой причине для NAI с компонентов realm (область) следует указывать типа ID_RFC822_ADDR. Реализациям ответчиков не нужно предпринимать попыток проверки точного соответствия идентификатора синтаксису [MAILFORMAT], принимая любые, выглядящие разумно NAI. Для идентификаторов NAI без компоненты следует указывать тип ID_KEY_ID.

3.6. Элемент Certificate

Элемент данных Certificate (CERT) обеспечивает способ передачи сертификатов или других, связанных с идентификацией данных через IKE. Элементы Certificate следует включать в обмен, если сертификаты доступны отправителю. Форматы Hash and URL (хэш и ссылка) для элементов Certificate следует применять в тех случаях, когда партнёр указал возможность получения информации иным путём с использованием элемента Notify типа HTTP_CERT_LOOKUP_SUPPORTED. Отметим, что термин Certificate Payload может вводить в заблуждение, поскольку не все механизмы аутентификации используют сертификаты и в этом элементе могут передаваться иные данные.

Поля элемента Certificate описаны ниже.

                     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 Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert Encoding |                                               |
+-+-+-+-+-+-+-+-+                                               |
~                       Certificate Data                        ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 12. Формат элемента Certificate.

Certificate Encoding (1 октет)

Это поле указывает тип сертификата или связанной с сертификатом информации в поле Certificate Data. В таблице приведены значения типов сертификатов, выделенные на момент публикации RFC 4306. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

 

Сертификат	Код	Описание
PKCS #7 wrapped X.509	1	Не задано
PGP	2	Не задано
DNS Signed Key	3	Не задано
X.509 — подпись	4
Kerberos Token	6	Не задано
CRL (список отозванных сертификатов)	7
ARL (список УЦ с прерванными полномочиями)	8	Не задано
SPKI	9	Не задано
X.509 — атрибут	10	Не задано
Raw RSA Key	11
Хэш и URL сертификата X.509	12
Хэш и URL связки (bundle) X.509	13

 

Certificate Data (переменный размер)

Реальный размер сертификационных данных. Тип сертификата задаётся полем Certificate Encoding.

Идентификатор типа для элемента Certificate имеет значение 37.

Конкретный синтаксис для некоторых типов сертификатов в этом документе не определён. Ниже приведён список типов сертификатов, для которых синтаксис определён в этой спецификации.

• «X.509 — подпись» содержит DER-представление сертификата X.509, открытый ключ которого служит для проверки элемента AUTH отправителя. Отметим, что при этом варианте представления в случаях, когда нужно передать цепочку сертификатов, используется множество элементов CERT и только первый из них содержит открытый ключ, используемый для проверки элемента AUTH отправителя.

• CRL содержит DER-представление списка отозванных сертификатов X.509.

• Raw RSA Key содержит представление PKCS #1 ключа RSA, т. е., представленную в формате DER структуру RSAPublicKey (см. [RSA] и [PKCS1]).

• Представления «Хэш и URL» позволяют снизить размер сообщений IKE путём замены длинных структур данных 20-октетным хэш-значением SHA-1 (см. [SHA]) заменённого сертификата и ссылкой (URL) переменного размера на место хранения этого сертификата в представлении DER. Это повышает эффективность в случаях кэширования данных сертификатов в конечных точках и делает IKE менее подверженным DoS-атакам, которые стали бы проще для больших сообщений IKE требующих фрагментации IP [DOSUDPPROT].

Тип «Хэш и URL связки» (Hash and URL of a bundle) использует определение ASN.1 для связки X.509 приведённое ниже.

   CertBundle
     { iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) id-mod(0)
       id-mod-cert-bundle(34) }

   DEFINITIONS EXPLICIT TAGS ::=
   BEGIN

   IMPORTS
     Certificate, CertificateList
     FROM PKIX1Explicit88
        { iso(1) identified-organization(3) dod(6)
          internet(1) security(5) mechanisms(5) pkix(7)
          id-mod(0) id-pkix1-explicit(18) } ;

   CertificateOrCRL ::= CHOICE {
     cert [0] Certificate,
     crl  [1] CertificateList }

   CertificateBundle ::= SEQUENCE OF CertificateOrCRL

   END

Реализации должны обеспечивать возможность настройки передачи и восприятия до четырёх сертификатов X.509 в поддержку аутентификации, а также должны обеспечивать возможность настройки передачи и восприятия двух первых форматов Hash and URL (с HTTP URL). Реализациям следует обеспечивать возможность настройки передачи и восприятия ключей Raw RSA. При передаче множества сертификатов первый из них должен содержать открытый ключ, используемый для подписывания элемента AUTH. Остальные сертификаты можно передавать в любом порядке.

Реализации должны поддерживать метод HTTP для поиска hash-and-URL. Поведение других URL-методов в настоящее время не задаётся и такие методы не следует применять при отсутствии спецификаций для них.

3.7. Элемент Certificate Request

                     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 Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cert Encoding |                                               |
+-+-+-+-+-+-+-+-+                                               |
~                    Certification Authority                    ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 13. Формат элемента Certificate Request.

Элемент данных Certificate Request (далее, CERTREQ) обеспечивает способ запроса предпочтительных сертификатов через IKE и может присутствовать в отклике IKE_SA_INIT⁶⁰ и/или запросе IKE_AUTH. Элементы Certificate Request могут включаться в обмен, где отправителю нужно получить сертификат получателя.

Поля Certificate Request описаны ниже.

Certificate Encoding (1 октет)

Указывает тип или формат запрашиваемого сертификата. Возможные значения указаны в параграфе 3.6.

Certification Authority (переменный размер)

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

Идентификатор типа для элемента Certificate Request имеет значение 38.

В поле Certificate Encoding используются те же значения, которые были определены в параграфе 3.6. Поле Certification Authority содержит индикатор доверенных УЦ для данного типа сертификата. Значение Certification Authority представляет собой конкатенацию хэш-значений SHA-1 для открытых ключей удостоверяющих центров (CA⁶¹). Каждое значение представляет собой хэш SHA-1 для элемента Subject Public Key Info (см. параграф 4.1.2.7 работы [PKIX]) из каждого сертификата Trust Anchor. Двадцатиоктетные хэш-значения объединяются (конкатенация) и помещаются в поле без дополнительного форматирования.

Содержимое поля Certification Authority определено только для сертификатов X.509 (типы 4, 12 и 13). Использовать другие значения не следует, пока не будут опубликованы соответствующие спецификации их применения со статусом Standards-Track.

Отметим, что термин Certificate Request (запрос сертификата) может вводить в заблуждение, поскольку запрашиваться с помощью этого элемента могут не только сертификаты, но и другие данные, как было указано в описании элемента Certificate. Синтаксис элемента Certificate Request для таких случаев не определяется в этом документе.

Элемент Certificate Request обрабатывается путём проверки поля Cert Encoding для определения наличия у обрабатывающего сертификатов этого типа. Если такие сертификаты имеются, просматривается поле Certification Authority для проверки наличия у обрабатывающего сертификатов, которые могут быть подтверждены в одном из указанных удостоверяющих центров. Это может быть цепочка сертификатов.

Если существует сертификат конечного объекта, который удовлетворяет критериям, заданным в CERTREQ, этот сертификат или цепочку сертификатов следует передать назад запрашивающему сертификат узлу, при условии, что получатель CERTREQ:

• настроен на использование аутентификации по сертификатам;

• имеет разрешение на передачу элемента CERT;

• имеет соответствующую политику доверия к CA для текущего согласования;

• имеет по крайней мере один действующий (time-wise) и подходящий сертификат конечного объекта, связанный с CA из CERTREQ.

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

Не ставится задачи блокирования связи на основе строгого соответствия выбора сертификата предложенному в CERTREQ — отправитель может выбирать другие сертификаты, которые получатель может проверить и которым он сможет доверять на основе кросс-сертификации, списков отзыва и других способов. Таким образом, обработке CERTREQ следует выглядеть, как предложению на выбор сертификата (не обязательно одного). Если сертификата нет, элемент CERTREQ игнорируется. С точки зрения протокола это не является ошибкой. Могут возникать случаи, когда при наличии предпочтительного CA, указанного в CERTREQ, подходящим оказывается другой удостоверяющий центр (возможно, в результате выбора оператора).

Уведомления HTTP_CERT_LOOKUP_SUPPORTED могут включаться в любые сообщения, которые могут включать элемент CERTREQ, для указания возможности отправителя просматривать сертификаты но ссылкам HTTP (URL) и, следовательно, его вероятного предпочтения сертификатов в таком формате.

3.8. Элемент Authentication

Элемент данных Authentication (далее, AUTH) содержит данные, которые используются для аутентификации. Синтаксис Authentication Data меняется в соответствии с выбором Auth Method, как описано ниже.

Поля элемента Authentication описаны ниже.

                     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 Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Method   |                RESERVED                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                      Authentication Data                      ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 14. Формат элемента Authentication.

Auth Method (1 октет)

Задаёт используемый метод аутентификации. Ниже перечислены типы подписей, определённые на момент публикации RFC 4306. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

RSA Digital Signature 1

Рассчитывается в соответствии с параграфом 2.15 с использованием секретного ключа RSA со схемой подписи RSASSA-PKCS1-v1_5, описанной в [PKCS1] (разработчикам следует принимать во внимание, что IKEv1 использует другой метод для подписей RSA). Для обеспечения взаимодействия реализациям, поддерживающим этот тип, следует поддерживать подписи, использующие SHA-1 в качестве хэш-функции, а также следует применять функцию SHA-1 по умолчанию при генерации подписей. Реализации могут использовать полученный от партнёра сертификат, как рекомендацию по выбору понятной обеим сторонам хэш-функции для подписи в элементе AUTH. Однако следует отметить, что используемый в подписи элемента AUTH алгоритм хэширования не обязан совпадать с алгоритмами хэширования в сертификатах.

Shared Key Message Integrity Code 2

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

DSS Digital Signature 3

Рассчитывается в соответствии с параграфом 2.15 с использованием секретного ключа DSS (см. [DSS]) и хэширования SHA-1.

Authentication Data (переменный размер)

См. параграф 2.15.

Идентификатор типа для элемента Authentication имеет значение 39.

3.9. Элемент Nonce

Элементы Nonce, обозначаемые в этом документе Ni и Nr (для инициатора и ответчика, соответственно), содержат случайные значения, служащие для обеспечения жизнестойкости в процессе обмена и защиты от атак с повторным использованием пакетов.

                     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 Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                            Nonce Data                         ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 15. Формат элемента Nonce.

Элемент Nonce включает единственное поле.

Nonce Data (переменный размер)

Случайные данные, генерируемые передающей стороной.

Идентификатор типа для элемента Nonce имеет значение 40.

Размер поля Nonce Data должен быть в диапазоне 16 — 256 октетов, включительно. Недопустимо повторное использование значений Nonce.

3.10. Элемент Notify

                     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 Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Protocol ID  |   SPI Size    |      Notify Message Type      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                Security Parameter Index (SPI)                 ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                       Notification Data                       ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 16. Формат элемента Notify.

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

Поля элемента Notify описаны ниже.

Protocol ID (1 октет)

Если уведомление относится к существующей SA, значение SPI которой указано в поле SPI, это поле показывает тип данной SA. Для уведомлений, относящихся к Child SA, это поле должно содержать значение 2 для индикации протокола AH или 3 для индикации ESP. Из уведомлений, определённых в этом документе, поле SPI включается только в INVALID_SELECTORS, REKEY_SA и CHILD_SA_NOT_FOUND⁶². Если поле SPI пусто, в поле идентификатора протокола при передаче должно помещаться значение 0, а на приёмной стороне это поле должно игнорироваться.

SPI Size (1 октет)

Размер SPI (в октетах) в соответствии с идентификатором протокола IPsec или 0, если индекс SPI не применим. Для уведомлений, касающихся IKE_SA, поле SPI Size должно иметь значение 0, а поле SPI должно быть пустым.

Notify Message Type (2 октета)

Указывает тип уведомления.

SPI (переменный размер)

Индекс параметров защиты.

Notification Data (переменный размер)

Данные о статусе или ошибке, передаваемые в дополнение к Notify Message Type. Значения этого поля определяются типом уведомления (см. ниже).

Идентификатор типа для элемента Notify имеет значение 41.

3.10.1. Типы сообщений Notify

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

Ниже приведён список сообщений Notification с их кодами. Число разных сообщений об ошибках существенно снижено по сравнению с IKEv1 в целях упрощения и сокращения объёма конфигурационных данных, доступных для зондирования.

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

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

Дополнительная информация по обработке ошибок приведена в параграфе 2.21.

Ниже приведены типы сообщений, определённые на момент публикации RFC 4306, а также два дополнительных типа, определённые в этом документе. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

Типы ошибок для сообщений NOTIFY.

UNSUPPORTED_CRITICAL_PAYLOAD 1

См. параграф 2.5.

INVALID_IKE_SPI 4

См. параграф 2.21.

INVALID_MAJOR_VERSION 5

См. параграф 2.5.

INVALID_SYNTAX 7

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

INVALID_MESSAGE_ID 9

См. параграф 2.3.

INVALID_SPI 11

См. параграф 1.5.

NO_PROPOSAL_CHOSEN 14

Ни один из предложенных шифронаборов не может быть принят. Такое сообщение может передаваться в любой ситуации, когда предложения (включая значения элементов SA, уведомления USE_TRANSPORT_MODE и IPCOMP_SUPPORTED и др.) не могут быть приняты ответчиком. Сообщение может также указывать ошибку общего типа для Child SA, когда связь Child SA не может быть создана по той или иной причине. См. также параграф 2.7.

INVALID_KE_PAYLOAD 17

См. параграфы 1.2 и 1.3.

AUTHENTICATION_FAILED 24

Передаётся в ответ на сообщение IKE_AUTH когда аутентификация по той или иной причине завершилась отказом. См. также параграф 2.21.2.

SINGLE_PAIR_REQUIRED 34

См. параграф 2.9.

NO_ADDITIONAL_SAS 35

См. параграф 1.3.

INTERNAL_ADDRESS_FAILURE 36

См. параграф 3.15.4.

FAILED_CP_REQUIRED 37

См. параграф 2.19.

TS_UNACCEPTABLE 38

См. параграф 2.9.

INVALID_SELECTORS 39

Может передаваться в обмене IKE INFORMATIONAL, когда узел получает пакет ESP или AH с селекторами, не соответствующими SA, использованной для его доставки (это требует отбрасывания пакета). Поле Notification Data указывает начало пакета-нарушителя (как в сообщениях ICMP), а поле SPI в уведомлении устанавливается в соответствии с SPI для Child SA.

TEMPORARY_FAILURE 43

См. параграф 2.25.

CHILD_SA_NOT_FOUND 44

См. параграф 2.25.

Типы состояний для сообщений NOTIFY.

INITIAL_CONTACT 16384

См. параграф 2.4.

SET_WINDOW_SIZE 16385

См. параграф 2.3.

ADDITIONAL_TS_POSSIBLE 16386

См. параграф 2.9.

IPCOMP_SUPPORTED 16387

См. параграф 2.22.

NAT_DETECTION_SOURCE_IP 16388

См. параграф 2.23.

NAT_DETECTION_DESTINATION_IP 16389

См. параграф 2.23.

COOKIE 16390

См. параграф 2.6.

USE_TRANSPORT_MODE 16391

См. параграф 1.3.1.

HTTP_CERT_LOOKUP_SUPPORTED 16392

См. параграф 3.6.

REKEY_SA 16393

См. параграф 1.3.3.

ESP_TFC_PADDING_NOT_SUPPORTED 16394

См. параграф 1.3.1.

NON_FIRST_FRAGMENTS_ALSO 16395

См. параграф 1.3.1.

3.11. Элемент Delete

                     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 Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID   |   SPI Size    |          Num of SPIs          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~               Security Parameter Index(es) (SPI)              ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 17. Формат элемента Delete.

Элемент Delete (далее, D) содержит определяемый протоколом идентификатор защищённой связи, которую отправитель удаляет из базы данных (следовательно, связь перестаёт быть корректной). Рисунок 17 Показывает формат элемента Delete. В этом элементе данных можно передавать множество SPI, однако все SPI должны относиться к одному протоколу. Смешивание идентификаторов протоколов в элементе Delete недопустимо. Однако в одном обмене INFORMATIONAL допускается использование множества уведомлений Delete с SPI для разных протоколов.

Удаление IKE_SA указывается значением идентификатора протокола 1 (IKE), а не значениями SPI. Удаление CHILD_SA (таких, как ESP или AH) будет включать идентификатор протокола IPsec (2 для AH, 3 для ESP) и значение SPI, которое передающая точка ожидает во входящих пакетах ESP ил AH.

Поля элемента Delete описаны ниже.

Protocol ID (1 октет)

1 для IKE SA, 2 для AH, 3 для ESP.

SPI Size (1 октет)

Размер (в октетах) индекса SPI, определяемого идентификатором протокола. Это поле должно иметь значение 0 для IKE (SPI заголовке сообщения) или 4 для AH и ESP.

Num of SPIs (2 октета, целое число без знака)

Число индексов SPI в элементе Delete. Размер отдельных SPI определяется полем SPI Size.

Security Parameter Index(es) (переменный размер)

Указывает конкретную удаляемую связь или связи SA. Размер этого поля определяется значениями полей SPI Size и Num of SPIs.

Идентификатор типа для элемента Delete имеет значение 42.

3.12. Элемент Vendor ID

Элемент данных Vendor ID (далее, V) содержит определённые производителем константы, которые служат для идентификации и распознавания удалённых экземпляров реализаций данного производителя. Этот механизм позволяет производителям экспериментировать с новыми возможностями, обеспечивая совместимость со старыми версиями.

Элемент Vendor ID может анонсировать возможность отправителя работать с некими расширениями протокола или просто идентифицировать реализацию в целях отладки. На основе значения недопустимо изменять интерпретацию какой-либо информации, определённой в этом документе (т. е. бит критичности должен быть сброшен). Возможна передача множества элементов Vendor ID. Реализации не обязана передавать элементы Vendor ID и может не использовать их совсем.

Элемент Vendor ID может передаваться в любом сообщении. Получение знакомого элемента Vendor ID даёт реализации возможность использовать значения, выделенные в этом документе для частного применения — частные элементы данных, типы обмена, уведомления и т. п. Непонятные элементы Vendor ID должны игнорироваться.

Разработчики документов, желающие расширить данный протокол, должны определить элемент Vendor ID для анонсирования возможности реализовать расширение описанное в документе. Предполагается, что получившие признание документы, будут стандартизоваться с выделением значений из резервных блоков IANA (Future Use) и использование данного Vendor ID будет прекращаться.

                     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 Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                        Vendor ID (VID)                        ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 18. Формат элемента Vendor ID.

Поля элемента Vendor ID описаны ниже.

Vendor ID (переменный размер)

Несмотря на отсутствие централизованного реестра идентификаторов, на выбравшего значение Vendor ID ложится ответственность за уникальность этого идентификатора. Хорошим тоном является включение в идентификатор названия компании, имени разработчика и т. п. Можно также использовать географическую широту и долготу в комбинации со временем выбора значения или придумать иной уникальный идентификатор. Использование цифровой сигнатуры взамен длинных строк является предпочтительной практикой.

Идентификатор типа для элемента Vendor ID имеет значение 43.

3.13. Элемент TS

                     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 Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of TSs |                 RESERVED                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                       <Traffic Selectors>                     ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 19. Формат элемента TS.

Элемент данных Traffic Selector (TS) позволяет партнёрам идентифицировать потоки пакетов для обработки службами IPsec. Элемент TS состоит из базового заголовка IKE, за которым следуют отдельные селекторы трафика.

Number of TSs (1 октет)

Число представляемых селекторов трафика.

RESERVED

Должно устанавливаться в 0 при передаче и игнорироваться при получении.

Traffic Selectors (переменный размер)

Один или множество индивидуальных селекторов трафика.

Размер элемента TS включает заголовок TS и все селекторы трафика.

Идентификатор типа элемента Traffic Selector имеет значение 44 для адресов на стороне инициатора SA и 45 на стороне ответчика.

Элементы TSi и TSr не обязаны включать одинаковое число селекторов трафика. Пакет считается соответствующим данному Tsi/TSr, если он соответствует хотя бы одному индивидуальному селектору в TSi и хотя бы одному индивидуальному селектору в TSr.

Например, селекторам

   TSi = ((17, 100, 198.51.100.66-198.51.100.66), (17, 200, 198.51.100.66-198.51.100.66))
   TSr = ((17, 300, 0.0.0.0-255.255.255.255), (17, 400, 0.0.0.0-255.255.255.255))

будут соответствовать пакеты UDP с адреса 198.51.100.66 в любой адрес, использующие любую из комбинаций портов (100,300), (100,400), (200,300), (200, 400).

Таким образом, для некоторых типов правил может потребоваться несколько пар Child SA. Например, правило, соответствующее только портам отправителя/получателя (100,300) и (200,400) в приведённом выше примере, не может быть согласовано при одной паре Child SA.

3.13.1. Селектор трафика

                     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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   TS Type     |IP Protocol ID*|       Selector Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Start Port*         |           End Port*           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                         Starting Address*                     ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                         Ending Address*                       ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 20. Селектор трафика.
* (все поля, кроме TS Type и Selector Length зависят от TS Type; на рисунке приведены поля для типов 7 и 8, определённых в настоящее время)

TS Type (1 октет)

Задаёт тип селектора трафика.

IP protocol ID (1 октет)

Значение, указывающее идентификатор связанного протокола IP (например, UDP, TCP, ICMP). Нулевое значение указывает, что с данным TS не связан какой-то протокол – SA может применяться для всех протоколов.

Selector Length

Указывает размер данной субструктуры Traffic Selector с учётом заголовка.

Start Port (2 октета, целое число без знака)

Наименьший номер порта, разрешенный для этого селектора. Для протоколов, где номер порта не определён (включая protocol 0) или разрешены любые номера, это поле должно иметь значение 0. Значения кода и типа ICMP и ICMPv6, а также типы заголовка (MH) Mobile IP версии 6 (MIPv6) представляются в этом поле в соответствии с параграфом 4.4.1.1 [IPSECARCH]. Значения типа и кода ICMP трактуются, как 16-битовый целочисленный номер порта, где старшие 8 битов указывают тип, а младшие 8 — код. Значения MIPv6 MH Type трактуются, как 16-битовый целочисленный номер порта, где старшие 8 битов указывают тип, а младшие 8 имеют значение 0.

End Port (2 октета, целое число без знака)

Наибольший номер порта, разрешенный для этого селектора. Для протоколов, где номер порта не определён (включая protocol 0) или разрешены любые номера, это поле должно иметь значение 65535. Значения кода и типа ICMP и ICMPv6, а также типы заголовка (MH) Mobile IP версии 6 (MIPv6) представляются в этом поле в соответствии с параграфом 4.4.1.1 [IPSECARCH]. Значения типа и кода ICMP трактуются, как 16-битовый целочисленный номер порта, где старшие 8 битов указывают тип, а младшие 8 — код. Значения MIPv6 MH Type трактуются, как 16-битовый целочисленный номер порта, где старшие 8 битов указывают тип, а младшие 8 имеют значение 0.

Starting Address

Наименьший адрес, включенный в этот селектор трафика (размер определяется полем TS Type).

Ending Address

Наибольший адрес, включенный в этот селектор трафика (размер определяется полем TS Type).

Системы, соответствующие [IPSECARCH] и желающие показать все порты (ANY), должны устанавливать для начального порта значение 0, а для конечного — 65535 (отметим, что, согласно [RFC4301], ANY включает OPAQUE). Системы, работающие с [IPSECARCH] и желающие показать порты OPAQUE, но не ANY, должны установить для начального порта значение 65535, а для конечного — 0.

Селекторы трафика типов 7 и 8 могут также указывать поля типа и кода ICMP или ICMPv6, равно как тип полей MH Type в заголовках IPv6 mobility [MIPV6]. Однако следует отметить, что пакеты ICMP и MIPv6 не имеют раздельных полей для отправителя и получателя. Метод задания селекторов трафика для ICMP и MIPv6 показан в примере параграфа 4.4.1.3 [IPSECARCH].

Ниже приведены значения поля Traffic Selector Type с описаниями адресных селекторов, определённые на момент публикации RFC 4306. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

TS_IPV4_ADDR_RANGE 7

Диапазон адресов IPv4, представленный двумя 4-октетными значениями. Первое значение указывает начальный, второе — конечный адрес IPv4 (оба значения включаются в диапазон адресов).

TS_IPV6_ADDR_RANGE 8

Диапазон адресов IPv6, представленный двумя 16-октетными значениями. Первое значение указывает начальный, в второе — конечный адрес IPv6 (оба значения включаются в диапазон адресов).

3.14. Элемент Encrypted

Элемент Encrypted, обозначаемый в этом документе SK{…}, содержит другие элементы в зашифрованном виде. При наличии элемента Encrypted этот элемент должен быть последним в сообщении. Часто этот элемент является единственным элементом данных в сообщении. Этот элемент называют также Encrypted and Authenticated (зашифровано и аутентифицировано).

Алгоритмы шифрования и защиты целостности согласуются при организации IKE_SA, а ключи рассчитываются в соответствии с параграфами 2.14 и 2.18.

В этом документе описана криптографическая обработка элементов Encrypted с использованием блочного шифра в режиме CBC и алгоритма защиты целостности с контрольными суммами фиксированного размера, рассчитываемыми для сообщений переменного размера. Устройство протокола разрабатывалось после алгоритмов ESP, описанных в RFC 2104 [KBC96], 4303 [RFC4303] и 2451 [ESPCBC]. В данном документе полностью описана криптографическая обработка данных IKE, а упомянутые документы следует рассматривать в качестве обоснования устройства протокола. В будущих документах может быть задана обработка элементов Encrypted для других видов преобразований типа алгоритмов шифрования со счётчиком (counter mode encryption) и аутентифицированного шифрования (authenticated encryption). Партнёрам недопустимо согласовывать преобразования, для которых нет спецификаций.

                     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 Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Initialization Vector                     |
|             (размер блока для алгоритма шифрования)           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    Encrypted IKE Payloads                     ~
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |             Padding (0-255 октетов)           |
+-+-+-+-+-+-+-+-+                               +-+-+-+-+-+-+-+-+
|                                               |  Pad Length   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    Integrity Checksum Data                    ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 21. Формат элемента Encrypted.

При использовании алгоритма аутентифицированного шифрования для защиты IKE SA устройство элементов Encrypted отличается от описанного здесь. В документе [AEAD] представлена информация о таких алгоритмах и их использовании в ESP.

Идентификатор типа для элемента Encrypted имеет значение 46. Элемент Encrypted включает базовый заголовок IKE и перечисленные ниже поля.

Next Payload

Указывает тип первого вложенного элемента данных. Отметим, что это отличается от стандартного формата заголовка, поскольку элемент Encrypted является последним в сообщении и в этом случае полю Next Payload следовало бы иметь значение 0. Однако по причине того, что содержимым этого элемента данных являются другие (вложенные) элементы и отсутствует логичное место для размещения информации о типе первого элемента, этот тип помещён сюда.

Payload Length

Размер элемента данных с учётом полей вектора инициализации (IV), Encrypted IKE Payloads, Padding, Pad Length, и Integrity Checksum Data.

Initialization Vector

Для шифров в режиме CBC размер вектора инициализации (IV) совпадает с размером блока алгоритма шифрования. Отправитель должен выбирать новый непредсказуемый вектор IV для каждого сообщения, получатели должны воспринимать любое значение. Читателям рекомендуется обратиться к работе [MODES] по вопросам генерации IV. В частности, использование последнего зашифрованного блока из предыдущего сообщения не считается непредсказуемым. Для отличных от CBC режимов формат и обработка IV задаётся в документах, определяющих алгоритм шифрования и режим работы.

IKE payloads

Соответствует приведённому выше описанию. Это поле шифруется с использованием согласованного алгоритма.

Padding

Может содержать любое значение, выбранное отправителем и должно иметь размер, делающий суммарный размер шифрованных элементов, поля Padding и поля Pad Length кратным размеру блока шифрования. Это поле шифруется с использованием согласованного алгоритма.

Pad Length

Размер поля Padding. Отправителю следует устанавливать в поле Pad Length минимальное значение, которое делает размер полей шифрованных элементов, Padding и Pad Length кратным размеру блока шифрования, но получатель должен принимать любые значения, обеспечивающие требуемое выравнивание. Это поле шифруется с использованием согласованного алгоритма.

Integrity Checksum Data

Криптографическая контрольная сумма всего сообщения, начиная с фиксированного заголовка IKE и заканчивая полем Pad Length. Контрольная сумма должна рассчитываться для зашифрованного сообщения. Размер поля определяется согласованным алгоритмом защиты целостности.

3.15. Элемент Configuration

Элемент данных Configuration (CP) используется для обмена конфигурационными параметрами между партнёрами IKE. Такой обмен используется для запроса клиентом CRC внутреннего адреса IP у сервера IRAS, а также для обмена другой информацией в процессе получения адреса по протоколу DHCP⁶³, если клиент CRC подключён непосредственно к ЛВС.

Поля элемента Configuration описаны ниже.

                     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 Payload  |C| RESERVED    |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   CFG Type    |                    RESERVED                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                   Configuration Attributes                    ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 22. Формат элемента Configuration.

Идентификатор типа для элемента Configuration имеет значение 47.

CFG Type (1 октет)

Тип обмена, представленного полем Configuration Attributes. В таблице приведены идентификаторы типов, определённые на момент публикации RFC 4306. Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

 

Тип	Значение
CFG_REQUEST	1
CFG_REPLY	2
CFG_SET	3
CFG_ACK	4

 

RESERVED (3 октета)

Должно устанавливаться в 0 при передаче и игнорироваться при получении.

Configuration Attributes (переменный размер)

Структуры TLV⁶⁴ конкретного элемента Configuration, описанные ниже. Элемент может включать множество атрибутов или не иметь их совсем.

3.15.1. Атрибуты конфигурации

                     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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|         Attribute Type      |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                             Value                             ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 23. Формат атрибута Configuration.

Reserved (1 бит)

Должно устанавливаться в 0 при передаче и игнорироваться при получении.

Attribute Type (15 битов)

Уникальный идентификатор типа конфигурационного атрибута.

Length (2 октета, целое число без знака)

Размер значения в октетах.

Value (0 или более октетов)

Значение атрибута (переменный размер). Список возможных типов атрибутов приведён ниже.

В таблице приведён список атрибутов конфигурации, определённых на момент публикации RFC 4306 (за исключением INTERNAL_ADDRESS_EXPIRY и INTERNAL_IP6_NBNS, которое отменяются этим документом). Новые значения могли быть добавлены с тех пор и могут быть добавлены после публикации этого документа. Актуальные значения следует смотреть в [IKEV2IANA].

 

Тип атрибута	Значение	Многозначный	Размер
INTERNAL_IP4_ADDRESS	1	да65	0 или 4 октета
INTERNAL_IP4_NETMASK	2	нет	0 или 4 октета
INTERNAL_IP4_DNS	3	да	0 или 4 октета
INTERNAL_IP4_NBNS	4	да	0 или 4 октета
INTERNAL_IP4_DHCP	6	да	0 или 4 октета
APPLICATION_VERSION	7	нет	0 или более
INTERNAL_IP6_ADDRESS	8	да2	0 или 17 октетов
INTERNAL_IP6_DNS	10	да	0 или 16 октетов
INTERNAL_IP6_DHCP	12	да	0 или 16 октетов
INTERNAL_IP4_SUBNET	13	да	0 или 8 октетов
SUPPORTED_ATTRIBUTES	14	нет	кратно 2
INTERNAL_IP6_SUBNET	15	да	17 октетов

 

INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS

Адрес внутренней сети, иногда называемый адресом красного узла (red node address) или приватным адресом, этот адрес может быть приватным с точки зрения сети Internet. В запросе указанный адрес является запрашиваемым (или адресом нулевого размера, если конкретный адрес не запрашивается). Если запрошен конкретный адрес, это скорей всего говорит о том, что ранее существовало соединение с таким адресом и запрашивающий узел хочет снова использовать данный адрес. В IPv6 запрашивающий узел может указать младшие байты желаемого адреса. Можно запросить множество внутренних адресов, запрашивая множество атрибутов для внутреннего адреса. Ответчик может вернуть число адресов, не превышающее запрошенное количество. INTERNAL_IP6_ADDRESS может включать до двух полей, первое из которых содержит шестнадцатиоктетный адрес IPv6, а второе — однооктетный размер префикса, как определено в [ADDRIPV6]. Запрашиваемый адрес остаётся корректным в течение всего срока действия IKE SA (или её наследников после смены ключей). Этот вопрос более подробно рассмотрен в параграфе 3.15.3.

INTERNAL_IP4_NETMASK

Маска внутренней сети. В запросах и откликах допускается только одна маска (например, 255.255.255.0) и она должна использоваться только с атрибутом INTERNAL_IP4_ADDRESS. Атрибут INTERNAL_IP4_NETMASK в CFG_REPLY означает то же самое, что атрибут INTERNAL_IP4_SUBNET, содержащий ту же информацию (передавать трафик для этих адресов через меня), но подразумевает границу сети. Например, клиент может использовать свой собственный адрес и маску при расчёте широковещательного адреса для канала. Пустой атрибут INTERNAL_IP4_NETMASK может включаться в CFG_REQUEST для запроса информации (хотя шлюз может передать информацию даже без запроса). Непустые значения этого атрибута в CFG_REQUEST не имеют смысла и их включение недопустимо.

INTERNAL_IP4_DNS, INTERNAL_IP6_DNS

Указывает адрес сервера DNS в сети. Запрашивать можно множество серверов DNS. Ответчик может вернуть адреса множества серверов или не вернуть ни одного.

INTERNAL_IP4_NBNS

Указывает адрес сервера сервера имён NetBios (WINS) в сети. Запрашивать можно множество серверов NBNS. Ответчик может вернуть адреса множества серверов или не вернуть ни одного.

INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP

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

APPLICATION_VERSION

Версия или информация приложения хоста IPsec, заданная в форме строки печатаемых символов ASCII без null-символа завершения.

INTERNAL_IP4_SUBNET

Защищаемые данным краевым устройством подсети. Атрибут может содержать до двух полей, первое из которых задаёт адрес IP, а второе — маску. Можно запрашивать множество подсетей. Ответчик может вернуть множество подсетей или не вернуть ни одной. Дополнительное рассмотрение этого вопроса приведено в параграфе 3.15.2.

SUPPORTED_ATTRIBUTES

При использовании в запросе этот атрибут должен иметь нулевой размер и указывает ответчику запрос на возврат списка всех поддерживаемых тем атрибутов. В откликах этот атрибут содержит набор 2-октетных идентификаторов атрибутов. Размер атрибута, разделённый на 2, будет указывать число поддерживаемых атрибутов в отклике.

INTERNAL_IP6_SUBNET

Защищаемые данным краевым устройством подсети. Атрибут может содержать до двух полей, первое из которых задаёт 16-октетный адрес IPv6, а второе — маску. Можно запрашивать множество подсетей. Ответчик может вернуть множество подсетей или не вернуть ни одной. Дополнительное рассмотрение этого вопроса приведено в параграфе 3.15.2.

Отметим, что в этом документе не даётся рекомендаций по выбору информации, которую реализация будет возвращать в откликах. В частности, мы не даём каких-либо конкретных рекомендаций в части определения сервером IRAS сервера DNS, адрес которого следует возвращать по запросам CRC.

Пара CFG_REQUEST и CFG_REPLY позволяет конечной точке IKE запросить информацию у своего партнёра. Если размер атрибута в элементе Configuration сообщения CFG_REQUEST не равен 0, такой элемент воспринимается как предложение атрибута. В элементе Configuration сообщения CFG_REPLY CFG_REPLY может быть возвращено это или новое значение атрибута. В отклик могут также добавляться атрибуты, не включённые в запрос. Непонятные или неподдерживаемые атрибуты должны игнорироваться в запросах и откликах.

Пара CFG_SET и CFG_ACK позволяет конечной точке передать (втолкнуть — push) конфигурационные данные своему партнёру. В этом случае элемент Configuration сообщения CFG_SET указывает атрибуты, которые инициатор желает изменить у партнёра. Ответчик должен возвращать элемент Configuration payload, если он воспринял какие-либо из предложенных конфигурационных данных, и должен указывать воспринятые атрибуты с нулевым размером данных. Не воспринятые атрибуты недопустимо включать в элемент Configuration сообщения CFG_ACK. Если не воспринят ни один из предложенных атрибутов, ответчик должен вернуть пустой элемент CFG_ACK или отклик без элемента CFG_ACK. В настоящее время использование обмена CFG_SET/CFG_ACK не определено, хотя он может применяться в комбинациях с расширениями на базе Vendor ID. Реализации могут игнорировать элементы CFG_SET.

3.15.2. Смысл атрибутов INTERNAL_IP4_SUBNET и INTERNAL_IP6_SUBNET

Атрибуты INTERNAL_IP4/6_SUBNET могут указывать дополнительные подсети, для которых может потребоваться одна или множество отдельных связей SA, доступных через шлюз, анонсируемый этими атрибутами. Атрибуты INTERNAL_IP4/6_SUBNET могут также выражать политику шлюза для трафика, который следует передавать через него — клиент может выбрать передачу другого трафика (входящего в TSr, но не в INTERNAL_IP4/6_SUBNET) через шлюз или напрямую адресату. Таким образом, трафик по адресам, указанным атрибутами INTERNAL_IP4/6_SUBNET, следует передавать через анонсируемые этими атрибутами шлюзы. Если нет Child SA, чьи селекторы трафика включают рассматриваемый адрес, требуется создание новых связей SA.

Например, если имеются две подсети 198.51.100.0/26 и 192.0.2.0/24, а запрос клиента включает

   CP(CFG_REQUEST) = INTERNAL_IP4_ADDRESS()
   TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
   TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)

приемлемый отклик может иметь вид (TSr и INTERNAL_IP4_SUBNET содержат одинаковую информацию)

   CP(CFG_REPLY) =
     INTERNAL_IP4_ADDRESS(198.51.100.234)
     INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
     INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
   TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
   TSr = ((0, 0-65535, 198.51.100.0-198.51.100.63), (0, 0-65535, 192.0.2.0-192.0.2.255))

В таких случаях INTERNAL_IP4_SUBNET реально не содержит какой-либо полезной информации.

Другой возможный отклик имеет вид

   CP(CFG_REPLY) =
     INTERNAL_IP4_ADDRESS(198.51.100.234)
     INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
     INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
   TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
   TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)

Этот отклик будет означать, что клиент может передавать весь свой трафик через шлюз, но этот шлюз не будет возражать, если клиент станет передавать трафик, не включенный в INTERNAL_IP4_SUBNET напрямую адресатам (без прохождения через шлюз).

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

   CP(CFG_REPLY) =
     INTERNAL_IP4_ADDRESS(198.51.100.234)
     INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
     INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
   TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
   TSr = (0, 0-65535, 198.51.100.0-198.51.100.63)

Атрибут INTERNAL_IP4_SUBNET может быть также полезен в случаях, когда клиентский селектор TSr включает лишь часть адресного пространства. Например, если клиент запрашивает

   CP(CFG_REQUEST) = INTERNAL_IP4_ADDRESS()
   TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
   TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)

отклик шлюза может иметь вид

   CP(CFG_REPLY) =
     INTERNAL_IP4_ADDRESS(198.51.100.234)
     INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
     INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
   TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
   TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)

Поскольку смысл атрибутов INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET в сообщениях CFG_REQUEST не ясен, их невозможно надёжно применять в CFG_REQUEST.

3.15.3. Элемент Configuration для IPv6

Элементы Configuration для IPv6, основанные на соответствующих элементах для IPv4, не вполне соответствуют «обычному стилю» IPv6. В частности, не используется автонастройка IPv6 без учёта состояний, сообщения с анонсами маршрутизаторов и обнаружение соседей. Отметим наличие дополнительного документа, посвящённого конфигурации IPv6 в IKEv2 [IPV6CONFIG]. В настоящее время это экспериментальный документ, но есть надежда по результатам экспериментов сделать его стандартом.

Клиенту можно выделить адрес IPv6, используя атрибут INTERNAL_IP6_ADDRESS элемента Configuration. Минимальный обмен при этом может иметь вид

   CP(CFG_REQUEST) =
     INTERNAL_IP6_ADDRESS()
     INTERNAL_IP6_DNS()
   TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
   TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

   CP(CFG_REPLY) =
     INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
     INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
   TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)
   TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

Клиент может передать непустой атрибут INTERNAL_IP6_ADDRESS в CFG_REQUEST для запроса конкретного адреса или идентификатора интерфейса. Шлюз сначала проверяет доступность указанного адреса и, при наличии, возвращает этот адрес. Если адрес не доступен, шлюз пытается использовать идентификатор интерфейса с некоторым другим префиксом, а при отказе будет выбирать другой идентификатор интерфейса.

Атрибут INTERNAL_IP6_ADDRESS содержит также поле размера префикса. При использовании в CFG_REPLY это поле соответствует атрибуту INTERNAL_IP4_NETMASK для случая IPv4.

Хотя описанная модель настройки адресов IPv6 достаточно проста, ей присущи некоторые ограничения. Туннели IPsec, настроенные с использованием IKEv2 не являются полнофункциональными «интерфейсами» в понимании архитектуры адресации IPv6 [ADDRIPV6]. В частности, у него может не быть локального для канала адреса (link-local) и это может осложнять использование протоколов, предполагающих его наличие (например, [MLDV2]).

3.15.4. Отказы при выделении адресов

Если ответчик сталкивается с ошибкой при попытке выделить инициатору адрес IP в процессе обработки элемента Configuration, он отвечает уведомлением INTERNAL_ADDRESS_FAILURE. Связь IKE SA все равно создаётся, даже если упомянутый отказ не позволяет организовать начальную Child SA. Если ошибка возникает в обмене IKE_AUTH, связи Child SA не будут организованы. Однако имеются и более сложные ситуации.

Если ответчик совсем не поддерживает элементы Configuration, он может просто игнорировать их. Реализации такого типа никогда не передают уведомления INTERNAL_ADDRESS_FAILURE. Если инициатору требуется выделение адреса IP, он будет трактовать отклик CFG_REPLY, как ошибку.

Инициатор может запросить конкретный тип адреса (IPv4 или IPv6), который не поддерживается ответчиком, даже если ответчик поддерживает элементы данных Configuration. В таких случаях ответчик просто игнорирует не поддерживаемый тип адреса, выполняя обычную обработку оставшейся части запроса.

Если инициатор запрашивает множество адресов поддерживаемого ответчиком типа и некоторые (не все) запросы приводят к отказу, ответчик возвращает только адреса, не вызвавшие ошибок и только в случае отказа при выделении всех запрошенных адресов передаёт INTERNAL_ADDRESS_FAILURE.

Если инициатор не получает адрес(а), требуемый его политикой, он может сохранить IKE SA и повторить элемент Configuration в отдельном обмене INFORMATIONAL после некоторого ожидания или может разорвать связь IKE SA, передав элемент Delete в отдельном обмене INFORMATIONAL, а позднее повторить попытку организации IKE SA. Время ожидания в описанных случаях не следует выбирать слишком малым (особенно при организации IKE SA заново), поскольку приведшие к ошибке ситуации могут сохраняться довольно долго. Разумным представляется интервал в несколько минут. Например, проблема нехватки адресов у ответчика может сохраняться, пока не будут возвращены адреса, используемые другими клиентами, или не будет изменена конфигурация ответчика с расширением доступного блока адресов.

3.16. Элемент EAP

Элемент Extensible Authentication Protocol⁶⁶ (EAP) позволяет выполнять аутентификацию IKE_SA с использованием протокола, определённого в RFC 3748 [EAP] и его последующих расширений. При использовании EAP требуется выбрать подходящий метод. Определено множество таких методов, описывающих использование протокола с разными механизмами аутентификации. Типы методов EAP перечислены в [EAP-IANA]. Здесь включено краткое описание формата EAP для ясности.

                     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 Payload  !C!   Резерв    !         Payload Length        !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!                                                               !
~                       EAP Message                             ~
!                                                               !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 24. Формат EAP.

Идентификатор типа для элемента данных EAP имеет значение 48.

                     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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!     Code      ! Identifier    !           Length              !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!     Type      ! Type_Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Рисунок 25. Формат сообщения EAP.

Code (1 октет)

Показывает, является это сообщение запросом (Request — 1), откликом (Response — 2), успешным завершением (Success — 3) или отказом (Failure — 4).

Identifier (1 октет)

Используется в PPP, чтобы отличить повторное использование сообщений от повторной передачи. Поскольку в IKE протокол EAP работает на базе протокола с гарантированной доставкой, использование идентификатора смысла не имеет. В откликах этот октет должен устанавливаться равным значению идентификатора в соответствующем запросе.

Length (2 октета, целое число без знака)

Указывает размер сообщения EAP и должно иметь значение на 4 меньше значения Payload Length в инкапсулирующем элементе.

Type (1 октет)

Присутствует только для элементов с кодом Request (1) или Response (2). Для других кодов размер сообщения EAP должен составлять четыре октета, а присутствие полей Type и Type_Data недопустимо. В запросах поле Type указывает запрашиваемые данные. В откликах в поле Type должно быть значение Nak или данные запрошенного типа. Поскольку протокол IKE передаёт индикацию отождествления инициатора в первом сообщении обмена IKE_AUTH, ответчику не следует передавать запросов EAP Identity (тип 1). Однако инициатор может отвечать на такие запросы при их получении.

Type_Data (переменный размер)

Зависит от типа запроса и связанного с ним отклика. Описание методов EAP приведено в документе [EAP].

4. Требования по соответствию

Для обеспечения взаимодействия всех реализаций IKEv2 вводятся специальные требования «необходимо поддерживать» (MUST support) в дополнение к другим требованиям. IKEv2 является протоколом защиты и одной из его основных функций является предоставление возможности организации SA только уполномоченным сторонам. Поэтому конкретная реализация может быть настроена с любыми ограничениями по части алгоритмов и удостоверяющих центров, что вступает в противоречие с всеобщей совместимостью.

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

• возможность согласования SA через NAT и туннелирования полученной ESP SA с использованием UDP;

• возможность запрашивать (и отдавать по запросу) временный адрес IP на удалённой стороне туннеля;

• возможность поддерживать EAP-аутентификацию;

• возможность поддерживать окна размером более 1;

• возможность организации множества SA (ESP и/или AH) в одной IKE SA;

• возможность замены ключей SA.

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

Каждая реализация должна быть способна выполнять обмен 4 сообщениями IKE_SA_INIT и IKE_AUTH, обеспечивающий организацию двух SA (одна для IKE, одна для ESP или AH). Реализации могут работать в режиме «только инициатор» или «только ответчик», если это подходит для используемой платформы. Каждая реализация должна быть способна отвечать на обмен INFORMATIONAL, но минимальные реализации могут отвечать на любое сообщение INFORMATIONAL пустым откликом INFORMATIONAL (отметим, что в контексте IKE SA пустое сообщение состоит из заголовка IKE, за которым следует элемент Encrypted без вложенных в него элементов). Минимальная реализация может поддерживать обмен CREATE_CHILD_SA лишь для случаев, когда запрос распознан, и отвергать его с уведомлением типа NO_ADDITIONAL_SAS. От минимальных реализаций не требуется возможность инициирования обменов CREATE_CHILD_SA или INFORMATIONAL. Когда срок жизни SA истекает (по локальному значению времени жизни или числу переданных октетов), реализация может попытаться обновить связь с помощью обмена CREATE_CHILD_SA или удалить (закрыть) SA и создать новую. Если ответчик отвергает запрос CREATE_CHILD_SA с передачей уведомления NO_ADDITIONAL_SAS, реализация должна быть способна закрыть старую SA и создать новую.

Реализации не обязаны поддерживать возможность запроса временных адресов IP и отклики на такие запросы. Если реализация поддерживает создание таких запросов и политика требует использовать временный адрес IP, в первое сообщение обмена IKE_AUTH должен включаться элемент данных CP, содержащий по крайней мере поле типа INTERNAL_IP4_ADDRESS или INTERNAL_IP6_ADDRESS. Все остальные поля являются необязательными. Если реализация поддерживает отклики на такие запросы, она должна разобрать элемент CP типа CFG_REPLY в первом сообщении обмена IKE_AUTH, а также поле INTERNAL_IP4_ADDRESS или INTERNAL_IP6_ADDRESS. Если реализация поддерживает выдачу временных адресов запрошенного типа, она должна возвратить элемент CP типа CFG_REPLY, содержащий адрес запрошенного типа. Ответчик может включать любые другие относящиеся к делу атрибуты.

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

• инфраструктуры открытых ключей (PKI⁶⁷), использующей сертификаты X.509 (PKIX), содержащие ключи RSA размером 1024 или 2048 и подписанные с использованием таких ключей, когда передаваемый идентификатор является ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR или ID_DER_ASN1_DN;

• аутентификации с общим ключом, когда передаваемый идентификатор является ID_KEY_ID, ID_FQDN или ID_RFC822_ADDR;

• аутентификации ответчика с использованием сертификатов PKIX, а инициатора — с использованием общего ключа.

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

Хотя протокол разработан так, чтобы минимизировать раскрытие конфигурационной информации неуполномоченным партнёрам, некоторое раскрытие всё-таки неизбежно. Один из партнёров в любом случае должен сначала идентифицировать себя и подтвердить эту идентификацию. Для предотвращения зондирования к инициаторам обмена предъявляется требование идентифицировать себя первым и обычно требуется первым подтвердить свою подлинность. Однако инициатор может узнать, что ответчик поддерживает IKE и определить поддерживаемые им криптографические протоколы. Ответчик (или кто-нибудь, прикидывающийся таковым) может не только проверить идентификацию инициатора, но и с помощью элементов CERTREQ определить, какие сертификаты желает использовать инициатор.

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

Повторяющаяся замена ключей с использованием CREATE_CHILD_SA без дополнительных обменов Diffie-Hellman делает все SA уязвимыми для криптоанализа одного ключа. Разработчикам следует отметить этот факт и установить предел для числа обменов CREATE_CHILD_SA между сторонами. В этом документе данный предел не задаётся.

Стойкость ключей, созданных в результате обмена Diffie-Hellman с использованием любой из определённых здесь групп, зависит от стойкости самой группы, размера используемого показателя и энтропии при генерации случайных значений. По причине большого числа влияющих на стойкость ключей факторов сложно определить стойкость ключа для любой из определённых групп. Группа Diffie-Hellman номер 2 при использовании с качественным генератором случайных чисел и показателем не менее 200 битов является общепринятой для 3DES. Группа 5 обеспечивает лучшую защиту по сравнению с группой 2. Группа 1 сохранена в качестве достояния истории и не обеспечивает достаточной защиты за исключением случаев применения с алгоритмом DES, который тоже стал уже достоянием истории. Разработчикам следует принимать во внимание эти оценки при выборе политики и согласовании параметров защиты.

Отметим, что отмеченные выше ограничения относятся к самим группам Diffie-Hellman. В IKE нет запретов на использование более сильных групп и ничто не снижает уровень стойкости, обеспечиваемый наиболее сильными группами (уровень стойкости ограничивается только выбранными при согласовании алгоритмами, включая функцию PRF). Фактически, расширяемая схема IKE поощряет определение новых групп — применение групп эллиптических кривых может существенно повысить уровень стойкости при использовании значительно меньших чисел.

Предполагается, что все показатели Diffie-Hellman удаляются из памяти после использования.

Обмены IKE_SA_INIT и IKE_AUTH происходят до того, как аутентифицируется инициатор. В результате этого от реализаций данного протокола требуется полная устойчивость к развёртыванию в любой незащищённой сети. Уязвимости реализаций, особенно для DoS-атак, могут быть использованы неуполномоченными партнёрами. Эта проблема вызывает особое беспокойство с учётом неограниченного числа сообщений при аутентификации EAP.

Стойкость всех ключей ограничивается размером результата согласованной функции PRF. По этой причине функции PRF, выходное значение которых имеет размер менее 128 битов (например, 3DES-CBC) недопустимо использовать с протоколом IKE.

Безопасность данного протокола критически зависит от уровня хаотичности случайно выбираемых параметров. Случайные значения должны создаваться качественным генератором случайных чисел или источником псевдослучайных чисел с подходящей «затравкой» (см. [RANDOMNESS]). Разработчикам следует обеспечить гарантии того, что использование случайных чисел для создания ключей и значений nonce не может приводить к снижению уровня защиты ключей.

Для информации о причинах выбора многих криптографических параметров протокола рекомендуется обратиться к работам [SIGMA] и [SKEME]. Хотя защита согласованных Child SA не зависит от стойкости алгоритмов шифрования и защиты целостности, выбранных для IKE_SA, реализациям недопустимо согласовывать использование NONE в качестве алгоритма защиты целостности IKE или ENCR_NULL в качестве алгоритма шифрования IKE.

При использовании заранее распространённых общих (pre-shared) ключей критически важным становится вопрос уровня хаотичности этих секретов. Жёсткая практика требует обеспечения для этих ключей уровня хаотичности не меньше, чем у самого стойкого из согласуемых ключей. Создание общих ключей из паролей, имён или других источников с малой энтропией не обеспечивает нужной защиты. Такие источники не обеспечивают устойчивости к атакам по словарю и использованию методов социальной психологии, а также к другим атакам.

Уведомления NAT_DETECTION_*_IP содержат хэш адресов и портов для сокрытия внутренней структуры сети IP, расположенной за устройством NAT. Поскольку пространство адресов IPv4 включает лишь 32 бита и обычно очень разрежено, атакующий может найти внутренние адреса, скрытые NAT простым перебором всех возможных адресов IP и сравнением хэш-значений. Номера портов обычно содержат фиксированное значение 500, а значения SPI можно выделить из пакетов. Это снижает число попыток расчёта. хэш-значений до 2³². Когда можно обоснованно предположить использование адресов из приватных блоков⁶⁸, объем расчётов дополнительно сокращается во много раз. Разработчикам, в результате, не следует полагаться на то, что использование IKE гарантирует отсутствие утечки внутренней адресной информации.

При использовании методов аутентификации EAP без генерации общих ключей для защиты последующих элементов данных AUTH становятся возможными некоторые MITM⁶⁹—атаки и атаки с подставными серверами [EAPMITM]. Такие уязвимости возникают при использовании EAP с протоколами, которые не защищены безопасным туннелем. Поскольку EAP является протоколом аутентификации общего назначения, который часто используется в системах с единым входом⁷⁰, развёрнутое решение IPsec, которое опирается на аутентификацию EAP без генерации общего ключа (этот метод также называют EAP без генерации ключей), может быть скомпрометировано в результате развёртывания совершенно не связанных с ним приложений, использующих тот же метод EAP без генерации ключей, но не обеспечивающих должной защиты. Отметим, что эта уязвимость не связана только с EAP и может возникать также в других сценариях с повторным использованием инфраструктуры аутентификации. Например, если механизм EAP, используемый IKEv2, основан на маркерных идентификаторах, организатор MITM-атаки может использовать подставной web-сервер, перехватить аутентификационный обмен с использованием маркера и применить результат для организации соединения IKEv2. По этой причине следует избегать, по возможности, использования методов EAP без генерации ключей. При использовании таких методов крайне следует применять EAP только в защищённых туннелях, когда инициатор проверяет сертификат ответчика до начала обмена EAP. Разработчикам следует описывать уязвимость использования методов EAP без генерации ключей в своих реализациях так, чтобы администраторы при развёртывании решений IPsec осознавали возможные риски.

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

Если сообщения IKEv2 слишком велики и требуется фрагментация на уровне IP, атакующие могут заблокировать завершение обмена путём опустошения ресурсов (заполнения буферов) для сборки фрагментов. Вероятность такого исхода можно минимизировать за счёт использования кодирования «Hash and URL» вместо передачи сертификатов (см. параграф 3.6). Дополнительные меры по снижению рисков обсуждаются в работе [DOSUDPPROT].

Контроль доступа имеет важное значение для безопасности протокола. Например, доверенные привязки, используемые для идентификации партнёров IKE, следует, по возможности, отделять от привязок, используемых для идентификации общедоступных web-серверов. Протокол IKE обеспечивает значительную свободу при выборе политики безопасности в части идентификации доверенных партнёров и их свидетельств (credentials), а также связей между ними и наличие политики безопасности с явными определениями в этой части весьма важно для реализации системы защиты.

5.1. Полномочия для селекторов трафика

IKEv2 основывается на данных PAD⁷¹ при определении типов Child SA, которые разрешено создавать партнёру. Этот процесс описан в параграфе 4.4.3 [IPSECARCH]. Когда партнёр запрашивает создание Child SA с некими селекторами трафика, PAD должна содержать запись Child SA Authorization Data (данные о полномочиях Child SA) связывающую отождествление партнёра, аутентифицированное IKEv2, и адреса, разрешённые для селекторов трафика.

Например, PAD может содержать запись, разрешающую партнёру с отождествлением sgw23.example.com создавать связи Child SA для адресов 192.0.2.0/24, которая означает, что данный защитный шлюз является приемлемым «представителем» для этих адресов. Для прямого взаимодействия между хостами IPsec требует наличия аналогичной записи. Например, fooserver4.example.com с 198.51.100.66/32 будет говорить о том, что указанное отождествление является приемлемым «владельцем» или «представителем» для данного адреса.

Как отмечено в [IPSECARCH], «Требуется вносить некоторые ограничения на создание дочерних SA, чтобы обезопасить идентифицированного партнёра от обманных ID, связанных с другими легитимными партнёрами.⁷²» В приведённом выше примере корректная конфигурация PAD препятствует sgw23 в создании связей Child SA с адресом 198.51.100.66, а fooserver4 — в создании Child SA с адресами 192.0.2.0/24.

Важно отметить, сто простая передача пакетов IKEv2, использующих некий конкретный адрес, не подразумевает разрешения на создание связей Child SA с этим адресом в селекторах трафика. Например, даже если sgw23 сможет подменить свой адрес IP на 198.51.100.66, он не сможет создать связей Child SA, соответствующих селекторам трафика fooserver4.

Спецификация IKEv2 не задаёт точного взаимодействия процесса выделения адресов IP с использованием элементов Configuration и базы данных PAD. Наша интерпретация состоит в том, что при выделении защитным шлюзом адреса с использованием элементов данных Configuration этот шлюз создаёт также временную запись в PAD, связывающую отождествление партнёра и вновь выделенный внутренний адрес.

Отмечено, что в некоторых средах корректная настройка конфигурации PAD может оказаться сложной. Например, если IPsec используется между парой хостов с динамическими адресами DHCP, очень сложно обеспечить указание в PAD корректного «владельца» для таких адресов IP. Это потребует защищённого механизма передачи сведений о выделении адресов от сервера DHCP и связывания этих хостов с отождествлениями, аутентифицированными с помощью IKEv2.

В силу таких ограничений некоторые производители настраивают конфигурацию своих PAD так, что аутентифицированным партнёрам разрешается создавать связи Child SA с селекторами трафика, содержащими тот же адрес, который используется для пакетов IKEv2. В средах, где возможно использование обманных адресов IP (т. е., почти повсеместно) такой подход позволяет любому партнёру создавать Child SA с любыми селекторами трафика. Во многих случаях такая конфигурация не будет ни подходящей, ни безопасной. Подробное обсуждение этого вопроса и общих ограничений для коммуникаций IPsec между парами хостов приведено в работе [H2HIPSEC].

6. Взаимодействие с IANA

[IKEV2] определяет множество типов и значений полей. Агентство IANA уже внесло эти типы и значения в реестры [IKEV2IANA], поэтому они не указываются здесь.

Два элемента были удалены из таблицы IKEv2 Configuration Payload Attribute Types — INTERNAL_IP6_NBNS и INTERNAL_ADDRESS_EXPIRY.

Добавлены два элемента в реестр IKEv2 NOTIFY MESSAGES — ERROR TYPES, определённые в этом документе и отсутствовавшие в [IKEV2]:

   43   TEMPORARY_FAILURE
   44   CHILD_SA_NOT_FOUND

Агентство IANA изменило в таблицу IKEv2 Payload Types строку

   46        Encrypted                        E          [IKEV2]

на

   46        Encrypted and Authenticated      SK    [This document]

Агентство IANA заменило все ссылки на RFC 4306 ссылками на этот документ.

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

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

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

Этот документ является результатом совместных усилий рабочей группы IPsec. Если бы не было ограничений на количество авторов RFC, следовало бы указать всех перечисленных ниже в алфавитном порядке людей — Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer Reingold и Michael Richardson. Множество других людей также внесло свой вклад. Это работы по развитию IKEv1, ISAKMP и IPsec DOI, каждая из которых имеет свой авторский коллектив. Hugh Daniel предложил включить нахождение инициатора (в сообщении 3), задал имя для ответчика и дал имя функции «You Tarzan, Me Jane». David Faucher и Valery Smyzlov помогли усовершенствовать процесс согласования селекторов трафика.

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

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

[ADDGROUP] Kivinen, T. and M. Kojo, «More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)», RFC 3526, May 2003.

[ADDRIPV6] Hinden, R. and S. Deering, «IP Version 6 Addressing Architecture», RFC 4291, February 2006.

[AEAD] Black, D. and D. McGrew, «Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol», RFC 5282, August 2008.

[AESCMACPRF128] Song, J., Poovendran, R., Lee, J., and T. Iwata, «The Advanced Encryption Standard-Cipher-based Message Authentication Code-Pseudo-Random Function-128 (AES-CMAC-PRF-128) Algorithm for the Internet Key Exchange Protocol (IKE)», RFC 4615, August 2006.

[AESXCBCPRF128] Hoffman, P., «The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE)», RFC 4434, February 2006.

[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, «Extensible Authentication Protocol (EAP)», RFC 3748, June 2004.

[ECN] Ramakrishnan, K., Floyd, S., and D. Black, «The Addition of Explicit Congestion Notification (ECN) to IP», RFC 3168, September 2001.

[ESPCBC] Pereira, R. and R. Adams, «The ESP CBC-Mode Cipher Algorithms», RFC 2451, November 1998.

[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, «Hypertext Transfer Protocol — HTTP/1.1», RFC 2616, June 1999.

[IKEV2IANA] «Internet Key Exchange Version 2 (IKEv2) Parameters», <http://www.iana.org>.

[IPSECARCH] Kent, S. and K. Seo, «Security Architecture for the Internet Protocol», RFC 4301, December 2005.

[MUSTSHOULD] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[PKCS1] Jonsson, J. and B. Kaliski, «Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1», RFC 3447, February 2003.

[PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 5280, May 2008.

[RFC4307] Schiller, J., «Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)», RFC 4307, December 2005.

[UDPENCAPS] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, «UDP Encapsulation of IPsec ESP Packets», RFC 3948, January 2005.

[URLS] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, January 2005.

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

[AH] Kent, S., «IP Authentication Header», RFC 4302, December 2005.

[ARCHGUIDEPHIL] Bush, R. and D. Meyer, «Some Internet Architectural Guidelines and Philosophy», RFC 3439, December 2002.

[ARCHPRINC] Carpenter, B., «Architectural Principles of the Internet», RFC 1958, June 1996.

[Clarif] Eronen, P. and P. Hoffman, «IKEv2 Clarifications and Implementation Guidelines», RFC 4718, October 2006.

[DES] American National Standards Institute, «American National Standard for Information Systems-Data Link Encryption», ANSI X3.106, 1983.

[DH] Diffie, W. and M. Hellman, «New Directions in Cryptography», IEEE Transactions on Information Theory, V.IT-22 n. 6, June 1977.

[DIFFSERVARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, «An Architecture for Differentiated Services», RFC 2475, December 1998.

[DIFFSERVFIELD] Nichols, K., Blake, S., Baker, F., and D. Black, «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers», RFC 2474, December 1998.

[DIFFTUNNEL] Black, D., «Differentiated Services and Tunnels», RFC 2983, October 2000.

[DOI] Piper, D., «The Internet IP Security Domain of Interpretation for ISAKMP», RFC 2407, November 1998.

[DOSUDPPROT] C. Kaufman, R. Perlman, and B. Sommerfeld, «DoS protection for UDP-based protocols», ACM Conference on Computer and Communications Security, October 2003.

[DSS] National Institute of Standards and Technology, U.S. Department of Commerce, «Digital Signature Standard», Draft FIPS 186-3, June 2008.

[EAI] Abel, Y., «Internationalized Email Headers», RFC 5335, September 2008.

[EAP-IANA] «Extensible Authentication Protocol (EAP) Registry: Method Types», <http://www.iana.org>.

[EAPMITM] N. Asokan, V. Nierni, and K. Nyberg, «Man-in-the-Middle in Tunneled Authentication Protocols», November 2002, <http://eprint.iacr.org/2002/163>.

[ESP] Kent, S., «IP Encapsulating Security Payload (ESP)», RFC 4303, December 2005.

[EXCHANGEANALYSIS] R. Perlman and C. Kaufman, «Analysis of the IPsec key exchange Standard», WET-ICE Security Conference, MIT, 2001, <http://sec.femto.org/wetice-2001/papers/radia-paper.pdf>.

[H2HIPSEC] Aura, T., Roe, M., and A. Mohammed, «Experiences with Host-to-Host IPsec», 13th International Workshop on Security Protocols, Cambridge, UK, April 2005.

[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, «HMAC: Keyed-Hashing for Message Authentication», RFC 2104, February 1997.

[IDEA] X. Lai, «On the Design and Security of Block Ciphers», ETH Series in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992.

[IDNA] Klensin, J., «Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework», RFC 5890, August 2010.

[IKEV1] Harkins, D. and D. Carrel, «The Internet Key Exchange (IKE)», RFC 2409, November 1998.

[IKEV2] Kaufman, C., «Internet Key Exchange (IKEv2) Protocol», RFC 4306, December 2005.

[IP] Postel, J., «Internet Protocol», STD 5, RFC 791, September 1981.

[IP-COMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, «IP Payload Compression Protocol (IPComp)», RFC 3173, September 2001.

[IPSECARCH-OLD] Kent, S. and R. Atkinson, «Security Architecture for the Internet Protocol», RFC 2401, November 1998.

[IPV6CONFIG] Eronen, P., Laganier, J., and C. Madson, «IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)», RFC 5739, February 2010.

[ISAKMP] Maughan, D., Schneider, M., and M. Schertler, «Internet Security Association and Key Management Protocol (ISAKMP)», RFC 2408, November 1998.

[MAILFORMAT] Resnick, P., Ed., «Internet Message Format», RFC 5322, October 2008.

[MD5] Rivest, R., «The MD5 Message-Digest Algorithm», RFC 1321, April 1992.

[MIPV6] Johnson, D., Perkins, C., and J. Arkko, «Mobility Support in IPv6», RFC 3775, June 2004.

[MLDV2] Vida, R. and L. Costa, «Multicast Listener Discovery Version 2 (MLDv2) for IPv6», RFC 3810, June 2004.

[MOBIKE] Eronen, P., «IKEv2 Mobility and Multihoming Protocol (MOBIKE)», RFC 4555, June 2006.

[MODES] National Institute of Standards and Technology, U.S. Department of Commerce, «Recommendation for Block Cipher Modes of Operation», SP 800-38A, 2001.

[NAI] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, «The Network Access Identifier», RFC 4282, December 2005.

[NATREQ] Aboba, B. and W. Dixon, «IPsec-Network Address Translation (NAT) Compatibility Requirements», RFC 3715, March 2004.

[OAKLEY] Orman, H., «The OAKLEY Key Determination Protocol», RFC 2412, November 1998.

[PFKEY] McDonald, D., Metz, C., and B. Phan, «PF_KEY Key Management API, Version 2», RFC 2367, July 1998.

[PHOTURIS] Karn, P. and W. Simpson, «Photuris: Session-Key Management Protocol», RFC 2522, March 1999.

[RANDOMNESS] Eastlake, D., Schiller, J., and S. Crocker, «Randomness Requirements for Security», BCP 106, RFC 4086, June 2005.

[REAUTH] Nir, Y., «Repeated Authentication in Internet Key Exchange (IKEv2) Protocol», RFC 4478, April 2006.

[REUSE] Menezes, A. and B. Ustaoglu, «On Reusing Ephemeral Keys In Diffie-Hellman Key Agreement Protocols», December 2008, <http://www.cacr.math.uwaterloo.ca/techreports/2008/cacr2008-24.pdf>.

[ROHCV2] Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C. Bormann, «IKEv2 Extensions to Support Robust Header Compression over IPsec», RFC 5857, May 2010.

[RSA] R. Rivest, A. Shamir, and L. Adleman, «A Method for Obtaining Digital Signatures and Public-Key Cryptosystems», February 1978.

[SHA] National Institute of Standards and Technology, U.S. Department of Commerce, «Secure Hash Standard», FIPS 180-3, October 2008.

[SIGMA] H. Krawczyk, «SIGMA: the `SIGn-and-MAc’ Approach to Authenticated Diffie-Hellman and its Use in the IKE Protocols», Advances in Cryptography — CRYPTO 2003 Proceedings LNCS 2729, 2003, <http://www.informatik.uni-trier.de/~ley/db/conf/crypto/crypto2003.html>.

[SKEME] H. Krawczyk, «SKEME: A Versatile Secure Key Exchange Mechanism for Internet», IEEE Proceedings of the 1996 Symposium on Network and Distributed Systems Security , 1996.

[TRANSPARENCY] Carpenter, B., «Internet Transparency», RFC 2775, February 2000.

Приложение A. Обзор отличий от IKEv1

Цели пересмотра IKE перечислены ниже

1. Определение протокола IKE в едином документе, замена RFC 2407, 2408, 2409 и включение последующих изменений в части добавления работы через NAT, расширяемой аутентификации (EAP) и получения удалённых адресов.

2. Упрощение IKE за счёт замены 8 разных начальных обменов одним обменом из 4 сообщений (с изменением механизмов аутентификации, воздействующих только на один элемент AUTH вместо реструктуризации всего обмена), см. [EXCHANGEANALYSIS].

3. Удаление полей области интерпретации (DOI), ситуации (SIT) и Labeled Domain Identifier, а также битов Commit и Authentication.

4. Снижение задержки IKE в общем случае за счёт сведения изначального обмена к 2 периодам кругового обхода (4 сообщения) и разрешения организации CHILD_SA в этом обмене.

5. Замена криптографического синтаксиса для защиты самих сообщений IKE синтаксисом, близким к ESP, для упрощения реализации и анализа защиты.

6. Снижение числа возможных ошибочных состояний за счёт обеспечения в протоколе гарантий доставки (все сообщения подтверждаются) и упорядочивания, позволивших сократить обмены CREATE_CHILD_SA с 3 сообщений до 2.

7. Повышение отказоустойчивости за счёт предоставления ответчику возможности не выполнять существенной обработки до подтверждения инициатором возможности приёма сообщений по заявленному им адресу IP.

8. Устранение криптографических недостатков типа проблем с симметрией в хэш-значениях, используемых для аутентификации (отмечена Tero Kivinen).

9. Задание селекторов трафика в специальных элементах данных вместо перегрузки информацией элементов ID и более гибкое указание селекторов трафика.

10. Описание поведения при возникновении некоторых ошибок или получении непонятных данных для упрощения совместимости с будущими версиями без ухудшения совместимости с предшествующими.

11. Упрощение и прояснение поддержки общих состояний при возникновении ошибок в сети или DoS-атаках.

12. Поддержка существующего синтаксиса и «магических» значений для упрощения поддержки в реализациях IKEv1 расширения для работы с IKEv2 при минимальных затратах.

Приложение B. Группы Diffie-Hellman

Имеется две группы Diffie-Hellman, определённых здесь для использования в протоколе IKE. Эти группы создал Richard Schroeppel из Университета штата Аризона. Свойства этих простых чисел описаны в работе [OAKLEY].

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

Дополнительные группы Diffie-Hellman определены в работе [ADDGROUP].

B.1. Группа 1 — 768-битовая MODP

Этой группе присвоен идентификатор 1.

Простое число имеет значение: 2⁷⁶⁸ — 2⁷⁰⁴ — 1 + 2⁶⁴ * { [2⁶³⁸ pi] + 149686 }, а его шестнадцатеричная форма имеет вид

   FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
   29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
   EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
   E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF

Генератор имеет значение 2.

B.2. Группа 2 — 1024-битовая MODP

Этой группе присвоен идентификатор 2.

Простое число имеет значение 2¹⁰²⁴ — 2⁹⁶⁰ — 1 + 2⁶⁴ * { [2⁸⁹⁴ pi] + 129093 }, а его шестнадцатеричная форма имеет вид

   FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
   29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
   EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
   E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
   EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
   FFFFFFFF FFFFFFFF

Генератор имеет значение 2.

Приложение C. Обмены и данные

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

Элементы данных Vendor ID (V) могут включаться почти во все сообщения. Ниже они представлены в наиболее логичных местах.

C.1. Обмен IKE_SA_INIT

   Запрос              --> [N(COOKIE)],
                           SA, KE, Ni,
                           [N(NAT_DETECTION_SOURCE_IP)+,
                            N(NAT_DETECTION_DESTINATION_IP)],
                           [V+][N+]

   обычный отклик      <-- SA, KE, Nr,
   (без cookie)            [N(NAT_DETECTION_SOURCE_IP),
                            N(NAT_DETECTION_DESTINATION_IP)],
                           [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
                           [V+][N+]

   отклик с cookie     <-- N(COOKIE), [V+][N+]

   нужна другая группа <-- N(INVALID_KE_PAYLOAD),
   группа Diffie-Hellman   [V+][N+]

C.2. Обмен IKE_AUTH без EAP

   Запрос              --> IDi, [CERT+],
                           [N(INITIAL_CONTACT)],
                           [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
                           [IDr],
                           AUTH,
                           [CP(CFG_REQUEST)],
                           [N(IPCOMP_SUPPORTED)+],
                           [N(USE_TRANSPORT_MODE)],
                           [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                           [N(NON_FIRST_FRAGMENTS_ALSO)],
                           SA, TSi, TSr,
                           [V+][N+]

   отклик              <-- IDr, [CERT+],
                           AUTH,
                           [CP(CFG_REPLY)],
                           [N(IPCOMP_SUPPORTED)],
                           [N(USE_TRANSPORT_MODE)],
                           [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                           [N(NON_FIRST_FRAGMENTS_ALSO)],
                           SA, TSi, TSr,
                           [N(ADDITIONAL_TS_POSSIBLE)],
                           [V+][N+]

   ошибка при         <--  IDr, [CERT+],
   создании Child SA       AUTH, N(error), [V+][N+]

C.3. Обмен IKE_AUTH с EAP

   Первый запрос       --> IDi,
                           [N(INITIAL_CONTACT)],
                           [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
                           [IDr],
                           [CP(CFG_REQUEST)],
                           [N(IPCOMP_SUPPORTED)+],
                           [N(USE_TRANSPORT_MODE)],
                           [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                           [N(NON_FIRST_FRAGMENTS_ALSO)],
                           SA, TSi, TSr,
                           [V+][N+]

   первый отклик       <-- IDr, [CERT+], AUTH, EAP, [V+][N+]

                     / --> EAP
   повтор 1..N раз  |
                     \ <-- EAP

   послед. запрос      --> AUTH

   послед. отклик      <-- AUTH,
                           [CP(CFG_REPLY)],
                           [N(IPCOMP_SUPPORTED)],
                           [N(USE_TRANSPORT_MODE)],
                           [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                           [N(NON_FIRST_FRAGMENTS_ALSO)],
                           SA, TSi, TSr,
                           [N(ADDITIONAL_TS_POSSIBLE)],
                           [V+][N+]

C.4. Обмен CREATE_CHILD_SA для создания или смены ключей Child SA

   Запрос              --> [N(REKEY_SA)],
                           [CP(CFG_REQUEST)],
                           [N(IPCOMP_SUPPORTED)+],
                           [N(USE_TRANSPORT_MODE)],
                           [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                           [N(NON_FIRST_FRAGMENTS_ALSO)],
                           SA, Ni, [KEi], TSi, TSr
                           [V+][N+]

   обычный             <-- [CP(CFG_REPLY)],
   отклик                  [N(IPCOMP_SUPPORTED)],
                           [N(USE_TRANSPORT_MODE)],
                           [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                           [N(NON_FIRST_FRAGMENTS_ALSO)],
                           SA, Nr, [KEr], TSi, TSr,
                           [N(ADDITIONAL_TS_POSSIBLE)]
                           [V+][N+]

   ошибка              <-- N(error)

   нужна другая группа <-- N(INVALID_KE_PAYLOAD),
   Diffie-Hellman          [V+][N+]

C.5. Обмен CREATE_CHILD_SA для смены ключей IKE SA

   Запрос              --> SA, Ni, Kei [V+][N+]

   отклик              <-- SA, Nr, Ker [V+][N+]

C.6. Обмен INFORMATIONAL

   Запрос              --> [N+], [D+], [CP(CFG_REQUEST)]

   отклик              <-- [N+], [D+], [CP(CFG_REPLY)]

Адреса авторов

Charlie Kaufman

Microsoft

1 Microsoft Way

Redmond, WA 98052

US

Phone: 1-425-707-3335

EMail: charliek@microsoft.com

Paul Hoffman

VPN Consortium

127 Segre Place

Santa Cruz, CA 95060

US

Phone: 1-831-426-9827

EMail: paul.hoffman@vpnc.org

Yoav Nir

Check Point Software Technologies Ltd.

5 Hasolelim St.

Tel Aviv 67897

Israel

EMail: ynir@checkpoint.com

Pasi Eronen

Independent

EMail: pe@iki.fi

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                   W. Townsley
Request for Comments: 5969                                  O. Troan
Category: Standards Track                                      Cisco
ISSN: 2070-1721                                          August 2010

 

Быстрое развертывание IPv6 на инфраструктурах IPv4 (6rd) — Спецификация протокола

IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) – Protocol Specification

PDF

Аннотация

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

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

Этот документ содержит проект стандарта Internet.

Документ является результатом работы IETF¹ и представляет согласованное мнение сообщества IETF. Документ был вынесен на открытое обсуждение и одобрен для публикации IESG². Не все документы, одобренные IESG, претендуют на статус тех или иных стандартов Internet (см. раздел 2 документа RFC 5741).

Информация о статусе этого документа, обнаруженных ошибках и способах обратной связи доступна по ссылке http://www.rfc-editor.org/info/rfc5969.

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

Авторские права (c) 2010 принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Исходная идея и название механизма 6rd описаны в [RFC5569], где подробно рассмотрено коммерчески эффективное «быстрое развертывание» 6rd провайдерами домашних сетей. Рекомендуется прочесть упомянутый документ. В данном документе описан механизм 6rd, который был расширен для использования в средах общего назначения. В документе используется термин 6to4 для обозначения механизма, описанного в [RFC3056] и 6rd — для описанного здесь механизма.

6rd задает протокольный механизм развертывания IPv6 на сайтах через сети IPv4 сервис-провайдеров (SP³). Механизм базируется на 6to4 [RFC3056], а основное отличие состоит в использовании принадлежащего SP префикса IPv6 вместо префикса общего пользования (2002::/16). В результате использования операторского префикса IPv6 область действия 6rd ограничивается сетью SP и находится под его непосредственным контролем. С точки зрения пользовательских сайтов и сети IPv6 Internet в целом, обеспечиваемые услуги IPv6 эквивалентны естественному развертыванию IPv6.

Механизм 6rd основан на алгоритмическом отображении между адресами IPv6 и IPv4, выделенными для использования в сети SP. Это отображение обеспечивает возможность автоматического определения конечных точек туннеля IPv4 из префикса IPv6, позволяя 6rd работать без учета состояния соединений.

6rd рассматривает сеть IPv4, как канальный уровень для IPv6 и поддерживает абстракцию автоматического туннелирования, подобно модели NBMA⁴ [RFC2491].

Домен 6rd состоит из краевых маршрутизаторов 6rd CE⁵ и одного или нескольких граничных трансляторов 6rd BR⁶. Пакеты IPv6, инкапсулируемые 6rd следуют топологии маршрутизации IPv4 внутри сети SP между устройствами CE и BR. Через трансляторы 6rd BR проходят только пакеты IPv6, адресованные за пределы домена 6rd сервис-провайдера или приходящие в этот домен извне. Поскольку 6rd работает без учета состояния соединений, доступ к шлюзам BR можно обеспечить с использованием адресации anycast для отказоустойчивости и надежности (подобно [RFC3068]).

На «клиентской» (т. е. ЛВС) стороне CE реализация IPv6 осуществляется как для любого естественного сервиса IP, предоставляемого SP, и дальнейшее рассмотрение работы IPv6 на стороне ЛВС устройства CE выходит за пределы документа. На «операторской» (т. е. WAN) стороне 6rd CE сам интерфейс WAN, инкапсуляция в Ethernet, ATM или PPP, а также протоколы управления (PPPoE, IPCP, DHCP и т. п.) остаются неизменными (как они используются в текущей среде IPv4). Хотя технология 6rd была разработана в основном для поддержки развертывания IPv6 на клиентской стороне (например, в домовых сетях SP), она подходит и для отдельных хостов IPv6, действующих, как CE.

Механизм 6rd опирается на IPv4 и разработан для предоставления высококачественных услуг IPv6 через сеть IPv4 с минимальным изменением инфраструктуры и работы сети IPv4. Естественное развертывание IPv6 в сети SP может происходить независимо для решения внутренних задач SP, а доставка услуг IPv6 на сайты клиентов будет обеспечиваться 6rd. После того, как сеть SP будет полностью (доступ и транспорт) переведена на IPv6, использование 6rd может быть прекращено.

6rd использует такую же инкапсуляцию и базовый механизм, какие применяются в 6to4, и может рассматриваться, как надмножество 6to4 (6to4 можно получить, установив для 6rd префикс 2002::/16). В отличие от 6to4, механизм 6rd предназначен для использования только в средах, где сервис-провайдер управляет доставкой услуг IPv6. Маршруты 6to4 с префиксом 2002::/16 могут использоваться совместно с 6rd в маршрутизаторе 6rd CE и это может обеспечить некоторые преимущества при непосредственном взаимодействии с маршрутизаторами 6to4.

Канальная модель 6rd может быть расширена для поддержки групповой адресации IPv6. Вопрос поддержки групповой адресации IPv6 оставлен для рассмотрения в будущем.

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

2. Язык описания требований

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

3. Терминология

6rd prefix — префикс 6rd

Префикс IPv6, выбранный сервис-провайдером для использования в домене 6rd. Для данного домена 6rd используется в точности один префикс 6rd. SP может реализовать 6rd на базе одного или множества доменов 6rd.

6rd Customer Edge (6rd CE) — краевой маршрутизатор

Устройство, функционирующее в качестве граничного маршрутизатора на стыке с клиентом в 6rd. В домовых широкополосных системах устройства такого типа иногда называют «домовыми шлюзами» (RG⁷) или оборудованием CPE⁸. Типичное устройство 6rd CE в домовом сайте имеет один интерфейс WAN, один или множество интерфейсов ЛВС и виртуальный интерфейс 6rd. В контексте 6rd устройства 6rd CE часто называют просто CE.

6rd delegated prefix — делегированный префикс 6rd

Префикс IPv6, рассчитанный устройством CE для использования на клиентской стороне, путем комбинирования префикса 6rd и адреса CE IPv4, полученного с помощью средств настройки конфигурации IPv4. Это префикс можно рассматривать, как логический эквивалент делегированного префикса DHCPv6 IPv6 [RFC3633].

6rd domain — домен 6rd

Множество устройств 6rd CE и BR, подключенных к одному виртуальному каналу 6rd. Сервис-провайдер может развернуть 6rd с одним или множеством доменов 6rd. Для каждого домена нужен отдельный префикс 6rd.

CE LAN side — сторона ЛВС

Функциональность устройства 6rd CE, используемая для обслуживания ЛВС или «клиентской» стороны CE. Интерфейс клиентской стороны CE полностью поддерживает IPv6.

CE WAN side — сторона WAN

Функциональность 6rd CE, используемая для обслуживания провайдерской или WAN-стороны CE. Интерфейс CE WAN поддерживает только IPv4.

6rd Border Relay (BR) — граничный транслятор 6rd

Поддерживающий 6rd маршрутизатор, управляемый сервис-провайдером и расположенный на краю домена 6rd. Маршрутизатор BR имеет по крайней мере по одному из перечисленных интерфейсов: IPv4, виртуальный интерфейс 6rd (конечная точка туннеля 6rd IPv6 в IPv4), IPv6, подключенный к сети IPv6. В контексте 6rd маршрутизатор 6rd BR может называться просто BR.

BR IPv4 address — адрес BR IPv4

Адрес IPv4 маршрутизатора 6rd BR для данного домена 6rd. Этот адрес используется устройствами CE для передачи маршрутизатору BR пакетов, адресованных получателям IPv6 за пределами домена 6rd.

6rd virtual interface — виртуальный интерфейс 6rd

Внутренний многоточечный туннельный интерфейс, на котором выполняется инкапсуляция и декапсуляция 6rd пакетов IPv6 в IPv4. Для типовой реализации CE или BR требуется только один виртуальный интерфейс 6rd. Маршрутизатору BR для работы во множестве доменов 6rd может потребоваться более одного виртуального интерфейса 6rd (но не более одного интерфейса на каждый домен 6rd).

CE IPv4 address — адрес CE IPv4

Адрес IPv4, выделенный устройству CE для обычного доступа IPv4 Internet (т. е., настроенный через DHCP, PPP и т. п.). Этот адрес может быть глобальным или приватным [RFC1918] в рамках домена 6rd. Адрес используется только устройством 6rd CE для создания делегируемого префикса 6rd, а также передачи и приема инкапсулированных в IPv4 пакетов IPv6.

4. Делегирование префиксов 6rd

Делегируемый префикс 6rd для использования на клиентской стороне создается путем комбинирования префикса 6rd и полного или частичного адреса CE IPv4. Из этих элементов делегируемый префикс 6rd автоматически создается маршрутизатором CE для клиентского сайта при обнаружении сервиса IPv4. Делегированный префикс 6rd используется точно так же, как префикс, полученный через делегирование DHCPv6 [RFC3633].

В 6to4 подобная операция выполняется за счет встраивания полного адреса IPv4 в фиксированную позицию общеизвестного префикса /16 IPv6. В 6rd префикс IPv6, позиция встраивания и число битов встраиваемого адреса IPv4 отличаются для разных доменов 6rd. Механизм 6rd позволяет оператору подстраивать размер префикса 6rd, число битов, используемых 6rd, и число битов, остающихся для делегирования сайтам клиентов. Для обеспечения возможности автоматической настройки конфигурации без учета состояния на стороне ЛВС следует использовать делегируемый префикс 6rd размером /64 или короче.

Делегируемый префикс 6rd создается путем конкатенации префикса 6rd и набора последовательных битов адреса CE IPv4 с сохранением их порядка. Размер делегируемого префикса 6rd равен сумме размеров префикса 6rd (n) и числа битов из адреса CE IPv4 (o).

|     n битов   |    o битов   |   m битов |    128-n-o-m битов     |
+---------------+--------------+-----------+------------------------+
|  префикс 6rd  | адрес IPv4   | ID подсети|     ID интерфейса      |
+---------------+--------------+-----------+------------------------+
|<-делегированный префикс 6rd->|

Рисунок 1

На рисунке показан формат адреса IPv6 (параграф 2.5.4 в [RFC4291]) с префиксом 6rd и встроенным адресом CE IPv4.

Если используется префикс 6rd размером /32 и 24 бита адреса CE IPv4 (например, все адреса CE IPv4 могут агрегироваться в 10.0.0.0/8), делегируемый префикс 6rd для каждого CE будет автоматически задан с размером /56 (32 + 24 = 56).

Встраивание в делегируемый префикс лишь части из 32 битов адреса CE IPv4 возможно только в тех случаях, когда для данного домена 6rd доступен агрегированный блок адресов IPv4. Это может оказаться непрактичным для глобальных адресов IPv4, но достаточно часто встречаются сети, где устройствам CE выделяются приватные адреса. Если приватные адреса перекрываются для данной инсталляции 6rd, можно организовать несколько доменов 6rd, вероятно с использованием такой же топологии линий, которая требуется для развертывания IPv4 на базе NAT. В этом случае для каждого домена используется свой префикс 6rd.

Каждый домен 6rd может использовать свое представление встроенных адресов IPv4 даже в рамках одного сервис-провайдера. Например, при использовании множества адресных блоков IPv4 с различными уровнями агрегирования число битов IPv4, требуемое для представление делегируемого префикса 6rd, может отличаться для каждого блока. В этом случае могут использоваться разные префиксы 6rd (и, следовательно, разные домены) для поддержки разного представления.

Поскольку делегируемый префикс 6rd выбирается алгоритмически на основе адреса IPv4, смена этого адреса будет приводить к изменению делегируемого префикса IPv6 и соответствующим негативным эффектам для клиентского сайта. Для предотвращения этого сервис-провайдерам рекомендуется выделять адреса CE IPv4 с достаточно большим сроком жизни.

Выделение адресов 6rd IPv6 и, следовательно, сам сервис IPv6 замыкаются на выделение (аренду) адресов IPv4; т. о, услуги 6rd также связаны с этим в плане проверки полномочий, учета использования услуг и т. п. Например, делегируемый префикс 6rd имеет такой же срок жизни, как и связанный с ним адрес IPv4. Время жизни префиксов, анонсируемое в Router Advertisement или используемое сервером DHCP на строне ЛВС устройства CE, должно быть не больше времени аренды адреса IPv4. Если время аренды адреса IPv4 не известно, в качестве времени жизни делегируемого префикса 6rd следует использовать принятое по умолчанию значение, заданное в [RFC4861].

5. Поиск неисправностей и трассировка

Адрес 6rd IPv6 и связанный с ним адрес IPv4 для данного клиента всегда можно определить алгоритмически со стороны сервис-провайдера, обслуживающего данный домен 6rd. Это может быть полезно при работе сервис-провайдера с системными журналами и другими данными в тех случаях, когда инструменты анализа данных более приспособлены для IPv4, нежели для IPv6. Это позволяет также использовать мониторинг путей данных, узлов и конечных пользователей IPv4 для протокола IPv6.

Устройствам CE и BR в 6rd следует поддерживать адрес IPv6 Subnet-Router [RFC4291] для своего делегируемого префикса 6rd. Это позволит, например, виртуальному интерфейсу 6rd передавать сообщения IPv6 ICMP echo самому себе для поиска неисправностей в работе 6rd на данном CE или BR. В случае BR адрес IPv4, используемый для расчета делегируемого префикса 6rd, является заданным конфигурацией BR адресом IPv4.

6. Выбор адреса

Все адреса, выделяемые из делегированных префиксов 6rd, следует трактовать, как естественные адреса IPv6. Не требуется вносить какие-либо изменения в таблицу политики выбора адресов отправителей и получателей [RFC3484].

7. Конфигурация 6rd

Для данного домена 6rd устройства BR и CE должны быть настроенными с перечисленными ниже четырьмя элементами 6rd. Значения этих параметров 6rd идентичны для всех устройств CE и BR в данном домене 6rd.

IPv4MaskLen

Число старших битов, которые совпадают для всех адресов CE IPv4 в данном домене 6rd. Например, при отсутствии идентичных битов IPv4MaskLen = 0 и для делегируемого префикса 6rd используется полный адрес CE IPv4. Если в адресах совпадает 8 битов (например, приватные адреса IPv4 из блока 10.0.0.0/8), IPv4MaskLen = 8 и восемь старших битов адреса IPv4 не используются при создании соответствующего делегируемого префикса 6rd.

6rdPrefix

Префикс 6rd IPv6 для данного домена 6rd.

6rdPrefixLen

Размер префикса 6rd IPv6 для данного домена 6rd.

6rdBRIPv4Address

Адрес IPv4 маршрутизатора 6rd BR для данного домена 6rd.

7.1. Конфигурация на клиентской стороне

Для четырех элементов 6rd устанавливаются одинаковые значение на всех CE в домене 6rd. Эти значения могут быть заданы разными способами, включая такие, как интерфейс управления домовыми шлюзами TR-69 [TR069], объект на базе XML, получаемый после организации соединения IPv4, запись DNS, SMIv2 MIB [RFC2578], PPP IPCP или настройка администратором вручную. В этом документе описана настройка требуемых конфигурационных параметров с использованием DHCP. Устройствам CE, которые позволяют настраивать конфигурацию IPv4 по протоколу DHCP, следует поддерживать этот вариант. Для других вариантов настройки и управления могут использоваться форматы, описанные для этого варианта, в целях совместимости и удобства реализации на CE, поддерживающих разные опции настройки конфигурации.

Единственной недостающей информацией, которая требуется CE для расчета делегируемых префиксов 6rd и обеспечения связности IPv6, является адрес IPv4 для CE. Этот адрес CE IPv4 задается в процессе получения доступа IPv4 в Internet (т. е. через DHCP, PPP или иным способом). Адрес может быть глобальным или приватным [RFC1918] в домене 6rd.

Одно устройство 6rd CE может быть подключено к множеству доменов 6rd просто, как любой маршрутизатор может быть подключен к множеству сервис-провайдеров IPv6 и иметь множество делегированных префиксов, полученных через DHCPv6 или иным способом. Каждый домен данного CE будет требовать своего набора конфигурационных элементов 6rd и будет генерировать свой делегируемый префикс 6rd.

7.1.1. Опция 6rd DHCPv4

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  OPTION_6RD   | option-length |  IPv4MaskLen  |  6rdPrefixLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                           6rdPrefix                           |
|                          (16 октетов)                         |
|                                                               |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     6rdBRIPv4Address(es)                      |
.                                                               .
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 2

option-code

OPTION_6RD (212)

option-length

Размер опции DHCP в октетах (22 октета с одним адресом BR IPv4).

IPv4MaskLen

Число старших битов адреса, совпадающих на всех интерфейсах CE IPv4 в данном домене 6rd. Это поле может принимать значения от 0 до 32. Все значения, превышающие 32, являются некорректными.

6rdPrefixLen

Размер префикса IPv6 (SP 6rd IPv6) в битах. В целях контроля границ октетов при обработке опции DHCP сумма (32 — IPv4MaskLen) + 6rdPrefixLen должна иметь значение не более 128.

6rdBRIPv4Address

Один или множество адресов IPv4 маршрутизатора(ов) 6rd BR данного домена 6rd.

6rdPrefix

Принадлежащий провайдеру префикс 6rd IPv6, представленный в форме 16-октетного адреса IPv6. Биты префикса после 6rdPrefixlen являются резервными и должны устанавливаться в 0 отправителем и игнорироваться получателем.

Маршрутизатор CE должен включать опцию Parameter Request List Option [RFC2132] для OPTION_6RD. Поскольку OPTION_6RD содержит один блок IPv4MaskLen/6rdPrefixLen/6rdPrefix, а DHCP не может передавать более одного экземпляра опции, OPTION_6RD предоставляется не более, чем одному домену 6rd. Предоставление опции маршрутизатором CE, подключенным к множеству доменов 6rd, выходит за пределы спецификации протокола.

Наличие опции DHCP OPTION_6RD служит индикацией доступности сервиса 6rd. По умолчанию получение корректной опции 6rd DHCP поддерживающим 6rd маршрутизатором CE приводит к настройке виртуального интерфейса 6rd и делегированию префикса для использования на стороне ЛВС устройства CE. Маршрутизатор CE должен иметь конфигурационную опцию отключения механизма 6rd; в этом случае принятые опции 6rd DHCP просто игнорируются.

Подробное рассмотрение поведения CE с использованием множества адресов BR IPv4 оставлено на будущее. В таких случаях CE должен по крайней мере один адрес BR IPv4 и может поддерживать множество адресов.

При включенном 6rd типичный маршрутизатор CE будет устанавливать маршрут по умолчанию к BR, «черную дыру» (black hole route) для делегированного префикса 6rd и маршруты для любой стороны ЛВС, получившей и анонсирующей префикс. Рассмотрим пример, где CE использует адрес IPv4 10.100.100.1, BR — 10.0.0.1, IPv4MaskLen = 8, 2001:db8::/32 служит префиксом 6rdPrefix, а для стороны ЛВС выделен префикс /64. Таблица маршрутизации типичного CE будет иметь вид:

::/0 -> 6rd-virtual-int0 via 2001:db8:0:100:: (маршрут по умолчанию)
2001:db8::/32 -> 6rd-virtual-int0 (прямое подключение к 6rd)
2001:db8:6464:100::/56 -> Null0 (null-маршрут к делегированному префиксу)
2001:db8:6464:100::/64 -> Ethernet0 (интерфейс ЛВС)

7.2. Конфигурация граничного транслятора

Маршрутизатор 6rd BR должен настраиваться с такими же элементами конфигурации 6rd, как устройства 6rd CE в том же домене.

Для повышения надежности и балансирования нагрузки в качестве адреса BR IPv4 может использоваться адрес anycast, совместно используемый в данном домене 6rd. Поскольку 6rd не учитывает состояния соединений, в любой момент можно работать с любым из маршрутизаторов BR. Если BR использует anycast-адрес IPv4, он должен устанавливать этот адрес IPv4 в поле отправителя пакетов, транслируемых маршрутизаторам CE.

Поскольку в 6rd используется адресное пространство провайдера, для работы 6rd не требуется анонсировать специфические маршруты за пределы домена ни для IPv6, ни для IPv4 BGP. Однако при использовании для трансляторов 6rd IPv4 адресов anycast эти адреса должны анонсироваться в IGP⁹ провайдера.

8. Детектирование недоступности соседа

Механизм детектирования отсутствия соседа (NUD¹⁰) для туннелей описан в параграфе 3.8 документа [RFC4213]. В 6rd все маршрутизаторы CE и BR можно рассматривать, как подключенные к одному виртуальному каналу и, следовательно, все они являются соседями один другому. В этом параграфе описан механизм детектирования недоступности соседа, не оказывающий негативного влияния на масштабируемость 6rd.

Типовая реализация 6rd может содержать очень большое число маршрутизаторов CE в одном домене. Связность между CE основана на маршрутизации IPv4 и передача NUD или других периодически повторяемых пакетов между устройствами 6rd CE за исключением случаев поиска неисправностей 6rd не рекомендуется.

Хотя детектирование доступности между данным 6rd CE и BR не требуется для корректной работы 6rd, в случаях, когда CE имеет множество путей для достижения BR, такое детектирование может быть полезным. Передача сообщений NUD маршрутизатору BR, повторяемая периодически очень большим числом маршрутизаторов CE, может вызвать перегрузку системы обработки управляющих сообщений в BR и это оказывает негативное влияние на масштабируемость 6rd. Вместо этого CE, которому нужно проверить доступность BR, должен использовать метод, который позволяет пакетам детектирования доступности следовать по обычному пути пересылки данных без специальной обработки на BR. Один из таких методов описан ниже.

1. CE создает произвольные данные любого размера для передачи BR (например, пустой блок данных размером 0, блок заполненный произвольными данными для тестирования MTU, сообщение NUD и т. п.). Формат данных сообщения не имеет никакого значения, поскольку BR не будет обрабатывать эти данные.
2. Данные инкапсулируются в пакет с внутренним заголовком IPv6 и внешним заголовком IPv4:

• • в качестве адреса получателя IPv6 указывается адрес из делегированного префикса 6rd, который связан с виртуальным интерфейсом CE;
  • в качестве адреса отправителя IPv6 устанавливается адрес из делегированного префикса 6rd (можно тот же, который указан в качестве адреса отправителя IPv6);
  • заголовок IPv4 добавляется обычным путем, как для любого пакета, адресованного BR (т. е. в качестве адреса получателя IPv4 указывается адрес BR, а в качестве адреса отправителя — CE IPv4).

3. CE передает подготовленный пакет через интерфейс, для которого проверяется доступность BR. При получении пакета маршрутизатор BR должен декапсулировать его и переслать обычным способом. Заголовок IPv4 декапсулируется, как обычно, показывая, что IPv6-адресатом пакета является CE, что приводит в результате к пересылке пакета этому CE с использованием механизма 6rd (т. е., адресатом получателя IPv4 будет CE, создавший пакет, отправителем IPv4 — маршрутизатор BR).
4. Прибытие сконструированного для проверки пакета IPv6 по адресу CE IPv6 завершает круговой обход до BR и обратно, а маршрутизатор BR не выполняет никаких операций по обработке тестового пакета, сверх его обычной пересылки. CE обрабатывает пакет IPv6 подобающим образом (обновляет таймер keepalive, метрику и т. п.).

Поле данных пакета может быть пустым или содержать значения, имеющие смысл для CE. Для некоторых реализаций может оказаться удобной передача сообщений NUD (отметим, что BR будет уменьшать значение поля IPv6 hop limit). Поскольку BR пересылает тестовый пакет, как обычный пакет данных без специальной обработки содержащихся в нем данных, выбор формата данных пакета остается за разработчиком.

9. Инкапсуляция IPv6 в IPv4

Действия, выполняемые при инкапсуляции IPv6 в IPv4 и пересылке (например, обработка маркеров пакета, подсчет контрольных сумм и т. п.) выполняются в соответствии с параграфом 3.5 документа [RFC4213] и совпадают с операциями, используемыми 6to4 [RFC3056]. Сообщения об ошибках ICMPv4 обрабатываются в соответствии с параграфом Section 3.4 [RFC4213]. По умолчанию поле IPv6 Traffic Class должно копироваться в поле IPv4 ToS¹¹. Такое поведение может быть изменено конфигурационными параметрами. В документах [RFC2983] и [RFC3168] приведена дополнительная информация, относящаяся к дифференцированным услугам IP и туннелированию.

Пакеты IPv6 от CE инкапсулируются в пакеты IPv4, когда они покидают сайте через интерфейс CE WAN. Для передачи и приема пакетов через этот интерфейс на CE должен адрес IPv4.

Канал 6rd моделируется, как канал NBMA, подобно другим механизмам автоматического туннелирования IPv6 в IPv4 типа [RFC5214] и все устройства 6rd CE и BR определяются как соседи. Адрес link-local виртуального интерфейса 6rd, выполняющего инкапсуляцию 6rd будет (при необходимости, формироваться, как описано в параграфе 3.7 [RFC4213]. Однако обмена данными с использованием адреса link-local происходить не будет.

9.1. MTU

MTU¹² и фрагментация для инкапсуляции IPv6 в IPv4 подробно рассмотрены в параграфе 3.2 RFC 4213 [RFC4213]. Область действия 6rd ограничена сетью сервис-провайдера. При выборе значения MTU для туннеля можно использовать механизм IPv4 Path MTU, как описано в параграфе 3.2.2 RFC 4213 [RFC4213] или явно задать значение 6rd Tunnel MTU в параметрах конфигурации.

Использование в качестве адреса отправителя anycast-адреса может приводить к тому, что сообщения ICMP об ошибках, генерируемые на пути, будут передаваться разным BR. Следовательно, использование динамического значения MTU для туннеля в соответствии с параграфом 3.2.2 [RFC4213] может приводить к «черным дырам» IPv4 Path MTU.

Множество маршрутизаторов BR, использующих один anycast-адрес отправителя, могут передавать одновременно фрагменты пакетов одному устройству IPv6 CE. Если в пакетах от разных BR окажется одинаковый номер фрагмента, при сборке могут возникнуть ошибки. По этой причине BR, использующие anycast-адрес отправителя должны устанавливать флаг IPv4 Don’t Fragment.

Если управление MTU организовано так, что значение IPv4 MTU на интерфейсе CE WAN обеспечивает предотвращение фрагментации в рамках сети SP, для 6rd Tunnel MTU следует установить значение IPv4 MTU за вычетом размера инкапсулирующего заголовка IPv4 (20 байтов). Например, если IPv4 MTU = 1500 байтов, для 6rd Tunnel MTU может быть установлено значение 1480 байтов. При отсутствии информации для установки 6rd Tunnel MTU следует использовать принятое по умолчанию значение 1280 байтов.

9.2. Правила приема

Для предотвращения использования обманных адресов IPv6 (spoofing) устройства 6rd BR и CE должны MUST сравнивать адрес отправителя IPv4 инкапсулированных пакетов IPv6 с адресом отправителя IPv4, заданным в конфигурации домена 6rd. Если адреса отправителей не совпадают, пакет должен быть отброшен с увеличеснием значения счетчика для индикации потенциальной атаки с подменой адресов. Кроме того, маршрутизатор CE должен разрешать пересылку пакетов, исходящих с заданного конфигурацией адреса.

По умолчанию маршрутизатор CE должен отбрасывать пакеты, полученные на виртуальном интерфейсе 6rd (т. е., после декапсуляции IPv4) для получателей IPv6, не относящихся к своему делегированному префиксу 6rd.

10. Процесс перехода на IPv6

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

SP может выбрать отдельный блок адресов IPv6 для естественного сервиса или использовать для этого префикс 6rd. При использовании отдельного блока переход с 6rd на естественную реализацию IPv6 будет выглядеть для клиентов просто, как смена адресов IPv6. Замены адресов можно избежать за счет вставки делегируемого префикса 6rd в домен маршрутизации IPv6 сервис-провайдера. Дальнейшее рассмотрение вопросов перехода от 6rd к естественному развертыванию IPv6 выходит за рамки спецификации данного протокола.

11. Использование адресного пространства IPv6

6rd использует адресное пространство сервис-провайдера, которое тот получает от регионального регистратора (RIR¹³), и для работы 6rd не требуется запрашивать у IANA выделение глобального блока адресов типа 6to4 2002::/16.

Префикс сервис-провайдера должен быть достаточно коротким для представления уникальных битов всех адресов IPv4 в данном домене 6rd и достаточно длинным для предоставления адресов IPv6 всем клиентам в жилых зонах. В самом худшем случае использования всех 32 битов адреса IPv4 и в предположении выделения префикса /56 для пользовательских сайтов, каждому сервис-провайдеру, использующему 6rd, будет требоваться блок /24 для 6rd в дополнение к другим блокам адресов IPv6. Предполагая, что развертывание 6rd будет весьма успешным и произойдет почти во всех автономных системах (AS¹⁴), число владельцев которых составляет сегодня примерно 32K, общий размер адресного блока для 6rd можно оценить в /9. Если SP будет делегировать сайтам префиксы /60, ему потребуется блок размером /28, а общий расход адресов для 6rd будет эквивалентен размеру блока /13. Отметим, что эти оценки основаны на предположении о том, что 6rd используется одновременно всеми владельцами AS в современной сети IPv4 Internet никто из них не использует методов компрессии адресов 6rd и никто не использует естественное развертывание IPv6, а для 6rd не выделяется адресное пространство, использованное ранее для других целей.

Для смягчения проблемы использования адресного пространства 6rd позволяет оставить избыточные биты префикса IPv4 при представлении адреса IPv4 внутри адреса 6rd IPv6. Наиболее полезно это в тех случаях, когда адресное пространство IPv4 очень хорошо агрегировано. Например, для обеспечения каждого клиента префиксом /60 при условии, что все клиенты IPv4 адресуются префиксом /12 для представления адреса IPv4 требуется только 20 битов и сервис-провайдеру будет достаточно префикса /40 IPv6 для 6rd. Если используется приватное адресное пространство, для блока 10/8 потребуется префикс /36. При использовании множества доменов 10/8 до 16 таких доменов можно поддерживать в /32.

Если сервис-провайдер имеет неагрегируемое пространство адресов IPv4 и требуется использовать все 32 бита адреса IPv4 при кодировании адресов 6rd IPv6, префикс 6rd должен иметь размер не более /32 для того, чтобы предлагать делегируемый префикс 6rd размером, по крайней мере, /64.

Адресный блок 6rd можно использовать для других целей после перехода всех пользователей на естественный сервис IPv6. Это может потребовать смены адресов на сайтах клиентов и выделения дополнительного адресного пространства на переходный период.

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

Транслирующий маршрутизатор 6to4, как отмечено в [RFC3056], может быть использован в качестве открытого транслятора для анонимизации и трансляции трафика IPv6. Ограничение домена 6rd сетью провайдера приводит к тому, что CE может принимать пакеты лишь от одного или немногих известных ему адресов IPv4 устройств 6rd BR. По этой причине многие из угроз для 6to4, описанных в [RFC3964], не применимы к 6rd.

При реализации правил приема, описанных в параграфе 9.2, пакеты IPv6 защищены от подмены адресов, если пакеты IPv4 приходят из сети SP или от других маршрутизаторов CE в домене 6rd¹⁵.

Злоумышленник, осведомленный о домене 6rd и адресе BR IPv4, может использовать эту информацию для создания пакетов, которые будут заставлять транслятор BR отражать туннелированные пакеты за пределы обслуживаемого им домена. Если атакующий создаст пакеты должным образом и сможет вставить пакет с адресовм отправителя IPv6, который выглядит, как исходящий из другого домена 6rd, может возникнуть циклическая пересылка пакетов (петля) между парой доменов 6rd, позволяющая злоумышленнику реализовать атаку packet amplification между двумя доменами [RoutingLoop].

Одним из способов предотвращения такой угрозы является закрытие доступа по адресу BR IPv4 извне (не из домена 6rd данного SP). В этом случае специально подготовленные пакеты IPv6 будут по-прежнему отражаться маршрутизатором BR, но циклической пересылки не возникнет. Можно также отфильтровывать туннелированные пакеты с адресом BR IPv4 в поле отправителя для предотвращения туннелей, выходящих из домена 6rd.

Для предотвращения циклической пересылки через другие внутренние трансляторы на маршрутизаторе BR следует использовать фильтрацию входящих и исходящих пакетов IPv4, отбрасывая пакеты с известными адресами внутренних 6rd BR, маршрутизаторов ISATAP и трансляторов 6to4, а также общеизвестными адресами anycast пространства 6to4.

Другой вариант предотвращения петель описан в работе [V6OPS-LOOPS].

Маршрутизатор BR должен организовать null-маршрут [RFC4632] для своего делегируемого префикса 6rd, созданного на основе адреса BR IPv4, с исключением адреса IPv6 Subnet-Router anycast.

13. Согласование с IANA

Агентство IANA выделило новый код опции DHCP для OPTION_6RD (212) с размером данных 18 + N (OPTION_6RD с адресами N/4 6rd BR).

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

Этот документ основан на идее Remi Despres, описанной в [RFC5569], и работе, выполненной Rani Assaf, Alexandre Cassen, и Maxime Bizon в компании Free Telecom. Brian Carpenter и Keith Moore документировали механизм 6to4, на котором основан данный протокол. Мы благодарим Fred Templin за его комментарии и предложения, а также его опыт работы с ISATAP. Комментарии и предложения предоставили также многие другие люди, особенно следует отметить Chris Chase, Thomas Clausen, Wouter Cloetens, Wojciech Dec, Bruno Decraene, Remi Despres, Alain Durand, Washam Fan, Martin Gysi, David Harrington, Jerry Huang, Peter McCann, Alexey Melnikov, Dave Thaler, Eric Voit и David Ward.

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

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

[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, «Address Allocation for Private Internets», BCP 5, RFC 1918, February 1996.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC2132] Alexander, S. and R. Droms, «DHCP Options and BOOTP Vendor Extensions», RFC 2132, March 1997.

[RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, «IPv6 over Non-Broadcast Multiple Access (NBMA) networks», RFC 2491, January 1999.

[RFC3056] Carpenter, B. and K. Moore, «Connection of IPv6 Domains via IPv4 Clouds», RFC 3056, February 2001.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, «The Addition of Explicit Congestion Notification (ECN) to IP», RFC 3168, September 2001.

[RFC4213] Nordmark, E. and R. Gilligan, «Basic Transition Mechanisms for IPv6 Hosts and Routers», RFC 4213, October 2005.

[RFC4291] Hinden, R. and S. Deering, «IP Version 6 Addressing Architecture», RFC 4291, February 2006.

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, «Neighbor Discovery for IP version 6 (IPv6)», RFC 4861, September 2007.

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

[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., «Structure of Management Information Version 2 (SMIv2)», STD 58, RFC 2578, April 1999.

[RFC2983] Black, D., «Differentiated Services and Tunnels», RFC 2983, October 2000.

[RFC3068] Huitema, C., «An Anycast Prefix for 6to4 Relay Routers», RFC 3068, June 2001.

[RFC3484] Draves, R., «Default Address Selection for Internet Protocol version 6 (IPv6)», RFC 3484, February 2003.

[RFC3633] Troan, O. and R. Droms, «IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6», RFC 3633, December 2003.

[RFC3964] Savola, P. and C. Patel, «Security Considerations for 6to4», RFC 3964, December 2004.

[RFC4632] Fuller, V. and T. Li, «Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan», BCP 122, RFC 4632, August 2006.

[RFC5214] Templin, F., Gleeson, T., and D. Thaler, «Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)», RFC 5214, March 2008.

[RFC5569] Despres, R., «IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)», RFC 5569, January 2010.

[RoutingLoop] Nakibly and Arov, «Routing Loop Attacks using IPv6 Tunnels», August 2009, <http://www.usenix.org/event/woot09/tech/full_papers/nakibly.pdf>.

[TR069] «TR-069, CPE WAN Management Protocol v1.1, Version: Issue 1 Amendment 2», December 2007.

[V6OPS-LOOPS] Nakibly, G. and F. Templin, «Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations», Work in Progress, May 2010.

Адреса авторов

Mark Townsley

Cisco

Paris,

France

EMail: mark@townsley.net

Ole Troan

Cisco

Bergen,

Norway

EMail: ot@cisco.com

---

Перевод на русский язык

Николай Малых

nmalykh@gmail.com

Internet Engineering Task Force (IETF)                  V. Dolmatov, Ed.
Request for Comments: 5933                                   A. Chuprina
Category: Standards Track                                     I. Ustinov
ISSN: 2070-1721                                           Cryptocom Ltd.
                                                               July 2010

Использование алгоритмов электронной подписи ГОСТ в записях DNSKEY и RRSIG для DNSSEC

Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC

PDF

Аннотация

В этом документе описано создание цифровых подписей и хэш-значений с использованием алгоритмов ГОСТ Р 34.10-2001 и ГОСТ Р 34.11-94 для записей DNSKEY, RRSIG и DS в защитных расширениях системы доменных имен (DNSSEC¹).

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

Этот документ является проектом стандарта (Internet Standards Track).

Документ является результатом работы IETF² и представляет собой согласованное мнение сообщества IETF. Документ был вынесен на публичное рассмотрение и одобрен для публикации IESG³. Дополнительная информация о документах BCP представлена в разделе 2 документа RFC 5741.

Информация о текущем статусе этого документа, обнаруженных ошибках и способах обратной связи может быть найдена по ссылке http://www.rfc-editor.org/info/rfc5933.

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

Авторские права (Copyright (c) 2010) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Система доменных имен (DNS⁴) представляет собой глобальную, иерархическую распределенную базу данных об именах Internet. Система DNS была расширена для использования криптографических ключей и цифровых подписей с целью проверки подлинности и целостности данных. RFC 4033 [RFC4033], RFC 4034 [RFC4034] и RFC 4035 [RFC4035] описывают эти защитные расширения DNS, называемые DNSSEC⁵.

В RFC 4034 описано размещение записей DNSKEY и RRSIG, а также указан список криптографических алгоритмов для применения в DNSSEC. Этот документ расширяет указанный список, алгоритмами подписи и хэширования ГОСТ Р 34.10-2001 ([GOST3410], [RFC5832]) и ГОСТ Р 34.11-94 ([GOST3411], [RFC5831]), а также задает размещение записей DNSKEY и способ создания записей RRSIG с использованием этих алгоритмов.

Предполагается знакомство читателя с DNSSEC и алгоритмами хеширования и подписи GOST, упомянутыми в этом документе.

Термин ГОСТ не определен официально, но обычно применяется для обозначения российских криптографических алгоритмов ГОСТ Р 34.10-2001 [RFC5832], ГОСТ Р 34.11-94 [RFC5831] и ГОСТ 28147-89 [RFC5830]. Поскольку ГОСТ 28147-89 не используется в DNSSEC, в данном документе термин ГОСТ служит для обозначения только алгоритмов ГОСТ Р 34.10-2001 и ГОСТ Р 34.11-94.

1.1. Уровни требований

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

2. Записи DNSKEY

Формат DNSKEY RR определен в RFC 4034 [RFC4034].

Открытые ключи ГОСТ Р 34.10-2001 указываются с номером алгоритма 12.

Формат передачи открытых ключей совместим с RFC 4491 [RFC4491]:

Согласно [GOST3410] и [RFC5832], открытый ключ является точкой на эллиптической кривой Q = (x,y).

Представление открытого ключа при передаче должно содержать 64 октета, из которых первые 32 задают значение x в формате little-endian, а вторые 32 октета — значение y в таком же формате.

Соответствующие параметры открытых ключей идентифицируются значением id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357], а параметры дайджеста (отпечатка) — id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357].

2.1. Использование открытого ключа с имеющимися криптобиблиотеками

На момент подготовки этого документа существующие криптографические библиотеки с поддержкой ГОСТ были способные читать открытые ключи ГОСТ с помощью базового интерфейса X509 API, если ключ представлен в соответствии с параграфом 2.3.2 RFC 4491 [RFC4491].

Для использования этого представления из формата передачи открытого ключа ГОСТ с параметрами, применяемыми в этом документе, перед 64 октетами данных ключа добавляется приведенная ниже 37-байтовая последовательность.

      0x30 0x63 0x30 0x1c 0x06 0x06 0x2a 0x85 0x03 0x02 0x02 0x13 0x30
      0x12 0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x23 0x01 0x06 0x07 0x2a
      0x85 0x03 0x02 0x02 0x1e 0x01 0x03 0x43 0x00 0x04 0x40

2.2. Пример DNSKEY RR

Если секретный ключ имеет значение (поле GostAsn1 разделено на 2 строки для удобства, в реальном ключе оно записывается одной строкой)

      Private-key-format: v1.2
      Algorithm: 12 (ECC-GOST)
      GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQg/9M
                iXtXKg9FDXDN/R9CmVhJDyuzRAIgh4tPwCu4NHIs=

Запись DNSKEY RR с ключом зоны DNS для example.net будет иметь вид

      example.net. 86400 IN DNSKEY 256 3 12 (
                                   aRS/DcPWGQj2wVJydT8EcAVoC0kXn5pDVm2I
                                   MvDDPXeD32dsSKcmq8KNVzigjL4OXZTV+t/6
                                   w4X1gpNrZiC01g==
                                   ) ; key id = 59732

3. Записи RRSIG

Значение поля подписи в RRSIG RR следует RFC 4490 [RFC4490] и рассчитывается, как показано ниже. Значения полей RDATA, предшествующих данным подписи, указаны в RFC 4034 [RFC4034].

   hash = GOSTR3411(data)

где параметр data представляет собой формат передачи подписываемого набора записей, как указано в RFC 4034 [RFC4034].

Хэш-значение должно рассчитываться с параметрами ГОСТ Р 34.11-94, идентифицируемыми набором id-GostR3411-94-CryptoProParamSet [RFC4357].

Подпись рассчитывается из хэш-значения в соответствии со стандартом ГОСТ Р 34.10-2001, а формат ее передачи соответствует RFC 4490 [RFC4490].

Цитата из RFC 4490:

Алгоритм цифровой подписи ГОСТ Р 34.10-2001 создает подпись в виде двух 256-битовых чисел r и s. Ее представление в форме строки октетов включает 64, из которых первые 32 содержат представление s в формате big-endian, а вторые 32 — представление r в том же формате.

3.1. Пример RRSIG RR

С помощью секретного ключа, указанного в параграфе 2.2, подписывается приведенный ниже набор RRSet, состоящий из записи A

      www.example.net. 3600 IN A 192.0.2.1

При установке даты заполнения 2000-01-01 00:00:00 UTC и срока окончания 2030-01-01 00:00:00 UTC приведенная ниже запись RR будет корректной.

     www.example.net. 3600 IN RRSIG A 12 3 3600 20300101000000 (
                                    20000101000000 59732 example.net.
                                    7vzzz6iLOmvtjs5FjVjSHT8XnRKFY15ki6Kp
                                    kNPkUnS8iIns0Kv4APT+D9ibmHhGri6Sfbyy
                                    zi67+wBbbW/jrA== )

Примечание. Алгоритм подписи ECC-GOST использует случайные данные, поэтому рассчитанное реально значение подписи будет отличаться от приведенного здесь.

4. Записи DS

Алгоритм цифровой подписи ГОСТ Р 34.11-94 обозначается в записях DS RR типом 3. Формат передачи значения подписи совместим с RFC 4490 [RFC4490], т. е., подпись использует представление little-endian.

Подпись всегда должна рассчитываться с параметрами ГОСТ Р 34.11-94, заданными набором id-GostR3411-94-CryptoProParamSet [RFC4357].

4.1. Пример DS RR

Для ключа подписывания ключей (KSK⁶)

      example.net. 86400   DNSKEY  257 3 12 (
                                   LMgXRHzSbIJGn6i16K+sDjaDf/k1o9DbxScO
                                   gEYqYS/rlh2Mf+BRAY3QHPbwoPh2fkDKBroF
                                   SRGR7ZYcx+YIQw==
                                   ) ; key id = 40692

Запись DS RR будет иметь вид

      example.net. 3600 IN DS 40692 12 3 (
                22261A8B0E0D799183E35E24E2AD6BB58533CBA7E3B14D659E9CA09B
                2071398F )

5. Вопросы развертывания

5.1. Размеры ключей

В соответствии с RFC 4357 [RFC4357] размер открытых ключей должен быть равен 512 битам.

5.2. Размеры подписей

В соответствии со спецификацией алгоритма цифровой подписи ГОСТ Р 34.10-2001 ([GOST3410], [RFC5832]) размер подписи составляет 512 битов.

5.3. Размеры дайджестов

В соответствии с ГОСТ Р 34.11-94 ([GOST3411], [RFC5831]) размер дайджеста (подписи) составляет 256 битов.

6. Вопросы реализации

6.1. Поддержка подписей ГОСТ

Осведомленные о DNSSEC реализации могут поддерживать записи RRSIG и DNSKEY, созданные с использованием алгоритмов ГОСТ, как описано в этом документе.

6.2. Поддержка NSEC3 Denial of Existence

Все реализации DNSSEC-GOST должны поддерживать NSEC [RFC4035] и NSEC3 [RFC5155].

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

В настоящее время криптостойкость алгоритма цифровой подписи ГОСТ Р 34.10-2001 оценивается в 2¹²⁸ операций расчета множества точек эллиптических кривых для модуля в виде простого числа порядка 2²⁵⁶.

В настоящее время криптостойкость алгоритма ГОСТ Р 34.11-94 оценивается в 2¹²⁸ операций расчета хэш-функции (известен метод снижения этого значения примерно до 2¹⁰⁵ операций, но он не пригоден для практического применения, поскольку требует создания конфликта с заполнением 1024 случайными блоками по 256 битов каждый).

8. Согласование с IANA

Этот документ обновляет реестр IANA DNS Security Algorithm Numbers [RFC4034], добавляя в него приведенное в таблице значение.

Значение	Алгоритм	Обозначение	Подпись зон	Защита транзакций	Документ	Статус
12	GOST R 34.10-2001	ECC-GOST	+	*	RFC 5933	OPTIONAL

Этот документ обновляет реестр RFC 4034 Digest Types ([RFC4034], параграф A.2), добавляя в него значение и статус для алгоритма ГОСТ Р 34.11-94.

Значение	Алгоритм	Статус
3	GOST R 34.11-94	OPTIONAL

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

Этот документ является незначительным дополнением к RFC 4034 [RFC4034]. Для согласованности авторы пытались следовать RFC 3110 [RFC3110], RFC 4509 [RFC4509] и RFC 4357 [RFC4357]. Авторам и участникам этих работ выражается признательность за хорошо выполненную работу.

Помощь в работе над документом оказали также комментарии и предложения Dmitry Burkov, Jaap Akkerhuis, Olafur Gundmundsson, Jelte Jansen и Wouter Wijngaards.

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

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

[GOST3410] «Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи.», ГОСТ Р 34.10-2001, Государственный стандарт Российской Федерации, Госстандарт России, 2001.

[GOST3411] «Информационная технология. Криптографическая защита информации. Функция хеширования.», ГОСТ Р 34.11-94, Государственный стандарт Российской Федерации, Госстандарт России, 1994.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC3110] Eastlake 3rd, D., «RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)», RFC 3110, May 2001.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «DNS Security Introduction and Requirements», RFC 4033, March 2005.

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Resource Records for the DNS Security Extensions», RFC 4034, March 2005.

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Protocol Modifications for the DNS Security Extensions», RFC 4035, March 2005.

[RFC4357] Popov, V., Kurepkin, I., and S. Leontiev, «Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms», RFC 4357, January 2006.

[RFC4490] Leontiev, S., Ed. and G. Chudov, Ed., «Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS)», RFC 4490, May 2006.

[RFC4491] Leontiev, S., Ed. and D. Shefanovski, Ed., «Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile», RFC 4491, May 2006.

[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, «DNS Security (DNSSEC) Hashed Authenticated Denial of Existence», RFC 5155, March 2008.

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

[RFC4509] Hardaker, W., «Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)», RFC 4509, May 2006.

[RFC5830] Dolmatov, V., Ed., «GOST 28147-89: Encryption, Decryption, and Message Authentication Code (MAC) Algorithms», RFC 5830, March 2010.

[RFC5831] Dolmatov, V., Ed., «GOST R 34.11-94: Hash Function Algorithm», RFC 5831, March 2010.

[RFC5832] Dolmatov, V., Ed., «GOST R 34.10-2001: Digital Signature Algorithm», RFC 5832, March 2010.

Адреса авторов

Vasily Dolmatov (редактор)

Cryptocom Ltd.

14/2, Kedrova St.

Moscow, 117218

Russian Federation

Phone: +7 499 124 6226

EMail: dol@cryptocom.ru

Artem Chuprina

Cryptocom Ltd.

14/2, Kedrova St.

Moscow, 117218

Russian Federation

Phone: +7 499 124 6226

EMail: ran@cryptocom.ru

Igor Ustinov

Cryptocom Ltd.

14/2, Kedrova St.

Moscow, 117218

Russian Federation

Phone: +7 499 124 6226

EMail: igus@cryptocom.ru

Перевод на русский язык

Николай Малых

nmalykh@gmail.com

Internet Engineering Task Force (IETF)                           D. Katz
Request for Comments: 5882                                       D. Ward
Category: Standards Track                               Juniper Networks
ISSN: 2070-1721                                                June 2010

Generic Application of Bidirectional Forwarding Detection (BFD)

Базовое применение протокола BFD

PDF

Аннотация

Этот документ описывает базовое применение протокола обнаружения двухсторонней пересылки (Bidirectional Forwarding Detection или BFD).

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

Этот документ является проектом стандарта Internet (Internet Standards Track).

Документ подготовлен IETF¹ и содержит согласованный взгляд сообщества IETF. Документ обсуждался публично и одобрен для публикации IESG². Дополнительная информация о стандартах Internet приведена в разделе 2 RFC 5741.

Информацию о текущем состоянии данного документа, обнаруженных ошибках и способах обратной связи можно найти по ссылке http://www.rfc-editor.org/info/rfc5882.

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

Авторские права ((c) 2010) принадлежат IETF Trust и лицам, являющимся авторами документа. Все права защищены.

К этому документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Протокол BFD [BFD] предоставляет механизм обнаружения, который может применяться другими компонентами сети, когда их собственные механизмы проверки живучести слишком медленны, неуместны или отсутствуют. Применение BFD с конкретной инкапсуляцией описано в документах [BFD-1HOP] [BFD-MULTI] [BFD-MPLS]. По мере того, как полезность BFD становилась понятной, возникли призывы задать взаимодействие BFD с растущим списком сетевых функций. Вместо создания серии коротких документов по использованию BFD представляется разумным описать взаимодействие BFD с другими сетевыми функциями (клиентами BFD) в широком смысле.

Этот документ описывает базовое применение BFD. Конкретные протоколы рассматриваются для иллюстрации.

1.1. Используемые соглашения

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

2. Обзор

Спецификация BFD определяет протокол с простой и конкретной семантикой. Единственной целью протокола является проверка связности между парой систем для конкретного протокола передачи данных по определённому пути (путь может использовать любую технологию, иметь любую длину и относиться к любому уровню OSI). Оперативность обнаружения отказов путей может контролироваться с обеспечением компромисса между издержками протокола, загрузкой систем и временем обнаружения.

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

Сервисный интерфейс с BFD прост. Приложение предоставляет параметры сессии (адрес соседа, временные параметры, опции протокола), а BFD представляет состояние сессии, для которого наиболее интересны переходы в статус Up и из него. Предполагается запуск сессии BFD приложением, поскольку протокол BFD не имеет средств обнаружения (соседей).

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

BFD следует считать «консультантом» для протоколов или иных сетевых функций, с которыми протокол взаимодействует и которые используют свои механизмы реагирования на смену состояния. Взаимодействие происходит «на расстоянии вытянутой руки», что делает его простым и отвязанным от других функций. В частности, BFD не передаёт связанной с приложениями информации, отчасти из архитектурных соображений, отчасти потому, что BFD может иметь странные и непредсказуемые характеристики, что делает протокол непригодным в качестве транспорта.

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

3. Базовые взаимодействия между сессиями и клиентами BFD

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

3.1. Гистерезис состояния сессии

Сессия BFD может быть тесно связана со своими клиентскими приложениями, например, любой выход из состояния Up может вызывать сигнал, заставляющий клиента выполнить действия по преодолению отказа. Одна в некоторых случаях это может быть не лучшим решением.

Реализации могут скрывать быстрые переходы Up-Down-Up сессий BFD от своих клиентов. Это полезно, например, для предотвращения ненужных перезапусков сложных протокольных механизмов.

Таким образом, система может не уведомлять клиентов о переходе сеанса BFD из состояния Up в Down с возвратом в состояние Up, если это происходит в течение разумного интервала времени (размер интервала выходит за рамки этой спецификации). Если сессия BFD не возвращается в состояние Up в течение заданного времени, клиентов следует уведомить об отказе сессии.

3.2. Статус AdminDown

Механизм AdminDown в BFD предназначен для информирования об административном отключении сессии BFD и этот статус ничего не говорит о живучести пути данных.

Поэтому системе не следует указывать клиенту отказ в связности при переходе локального или удалённого (если оно известно) статуса сессии в AdminDown, если у клиента есть независимый способ проверки живучести (обычно протокол управления). Если у клиента нет независимого способа контроля живучести, системе следует сообщить клиенту о нарушении связности и принять семантику статуса Down при переходе состояния сессии на локальной или удалённой стороне в состояние AdminDown. Иначе клиент не сможет определить жизнеспособность пути, что может приводить к нежелательным результатам.

3.3. Организация и восстановление статуса BFD без влияния на клиентов

Полезно иметь возможность настройки сессии BFD между парой систем без влияния на связанных с сессией клиентов. Точно так же полезно восстанавливать статус BFD без нарушения работы клиентов при потере состояния BFD (например, в случае перезапуска). Это связано со способностью клиентов поддерживать свой статус независимо от BFD.

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

4. Взаимодействия с протоколами управления

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

4.1. Организация смежности

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

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

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

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

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

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

4.2. Реакция на смену состояния сессии BFD

Если сессия BFD переходит из состояния Up в AdminDown или из Up в Down в результате индикации удалённой системой статуса AdminDown, клиентам не следует выполнять каких-либо действий в протоколе управления.

Для других переходов из состояния Up в Down механизм реагирования протокола управления на индикацию отказа пути протоколом BFD зависит от возможностей протокола управления, как описано ниже.

4.2.1. Протоколы управления с одним протоколом данных

Протоколу управления, тесно связанному с отказом одного протокола данных, следует предпринимать действия, гарантирующие отправку трафика данных в обход отказавшего пути. Отметим, что это не следует считать заменой протоколом BFD механизмов проверки живучести протокола управления (если они есть), поскольку протокол управления может опираться на механизмы, не проверяемые BFD (например, групповая передача), поэтому BFD скорей всего будет обнаруживать не все отказы, влияющие на протокол управления. Однако протокол управления может выбрать применение сведений о статусе сессии BFD для более быстрого обнаружения надвигающегося отказа протокола управления, в частности, при работе этого протокола по основному каналу (in-band, по протоколу данных).

Поэтому при переходе сессии BFD из состояния Up в Down в протоколе управления следует выполнять действия, сигнализирующие об отсутствии связности на пути, по которому работает BFD. Если протокол управления имеет явный механизм анонсирования статуса пути, системе следует использовать такой механизм, не влияя на связность протокола управления, в частности, при работе протокола управления по отдельному от протокола данных каналу (out-of-band). Однако при недоступности такого механизма протоколу управления следует имитировать тайм-аут для соответствующего соседа.

4.2.2. Протоколы управления с несколькими протоколами данных

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

4.2.2.1. Общая топология

При общей топологии в случае отказа одного протокола данных (как указывает соответствующая сессия BFD) необходимо считать этот путь отказавшим для всех протоколов данных. Иначе протокол управления не сможет переместить на другой путь трафик отказавшего протокола (и тот будет заблокирован на неопределённое время).

Поэтому при переходе сессии BFD из состояния Up в Down в протоколе управления следует выполнить действия по сигнализации отсутствия связности на пути в топологии, соответствующей сессии BFD. Если нет иной возможности передачи такого сигнала, следует имитировать тайм-аут для соответствующего соседа.

4.2.2.2. Независимые топологии

При использовании для каждого протокола своей топологии требуется перенаправлять лишь трафик протокола, столкнувшегося с отказом. Поэтому при переходе сессии BFD из состояния Up в Down, в протоколе управления следует выполнить действия по сигнализации потери связности на пути в топологии, где работает BFD. Обычно это можно сделать без влияния на связность других топологий (иначе очень сложно поддерживать разные топологии для нескольких протоколов данных).

4.3. Взаимодействие с механизмами аккуратного перезапуска

Многие протоколы управления, включая IS-IS [ISIS-GRACE], OSPF [OSPF-GRACE], BGP [BGP-GRACE], поддерживают механизм аккуратного перезапуска (Graceful Restart). Эти механизмы позволяют перезапустить протокол управления без нарушения статуса связности сети (чтобы не возникало впечатления об отказе системы и/или всех её каналов). Механизмы основаны на наличии отдельной плоскости пересылки, которая не обязательно разделяет судьбу плоскости управления, где работает протокол. В частности, предполагается возможность работы плоскости пересылки во время перезапуска и установки состояния протокола.

Реализации BFD указывают флагом C (Control Plane Independent), имеет ли BFD общую судьбу с плоскостью управления. Это служит для определения действий, применяемых вместе с Graceful Restart. Если BFD не зависит от плоскости управления какой-либо из систем, протокол можно использовать для обнаружения нежизнеспособности Graceful Restart в протоколе управления (нарушение работы плоскости пересылки).

Если протокол управления имеет механизм аккуратного перезапуска, BFD можно применять в комбинации с этим механизмом. Взаимодействие между BFD и протоколом управления зависит от возможностей протокола и наличия (отсутствия) связи между судьбой BFD и плоскости управления. В частности, может оказаться желательным при отказе сессии BFD прерывать процесс Graceful Restart, чтобы отказ можно было увидеть в сети.

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

Если протокол BFD реализован в плоскости пересылки и не зависит от судьбы плоскости управления какой-либо из систем (бит C установлен в пакетах BFD Control для обоих направлений), перезапуск протокола управления не должен влиять на сессии BFD. В этом случае отказ сессии BFD предполагает невозможность пересылки данных, поэтому запущенные на момент отказа сессии BFD процедуры Graceful Restart следует прервать для предотвращения «чёрных дыр», а протокол управления следует информировать об изменении топологии.

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

Если BFD разделяет судьбу плоскости управления любой из систем (бит C сброшен для любого из направлений), отказ сессии BFD невозможно отделить от других событий в плоскости управления. Во многих случаях отказ сессии BFD будет побочным эффектом перезапуска. Поэтому следует по возможности избегать прерывания процедуры Graceful Restart, поскольку иначе BFD не сможет сосуществовать с Graceful Restart. При этом возникает некоторый риск, поскольку одновременный отказ или перезапуск плоскости пересылки не будет обнаружен, но это возникает во всех случаях, когда BFD разделяет судьбу плоскости управления.

4.3.2.1. Протоколы управления с сигнализацией запланированного перезапуска

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

4.3.2.2. Протоколы управления без сигнализации запланированного перезапуска

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

Однако, если перезапуск действительно запланирован, реализация может настроить временные параметры сессии BFD до перезапуска так, чтобы интервал Detection Time в каждом направлении был больше продолжительности перезапуска протокола управления, обеспечивая перезапускаемой системе такую же возможность использовать Graceful Restart, как это было бы без BFD. Перезапускаемой системе не следует передавать пакеты BFD Control, пока не будет высокой вероятности того, что соседи знают о процедуре Graceful Restart, поскольку первый пакет BFD Control будет вызывать отказ сессии BFD.

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

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

Если применяются иерархические или зависимые один от другого уровни протоколов управления (например, OSPF и IBGP), взаимодействие более одного из них с BFD может оказаться бесполезным. В упомянутом примере IBGP зависит от OSPF в плане маршрутных данных, поэтому быстрое информирование IBGP о возникающих отказах может оказаться даже вредным. Издержки смены статуса соседа в BGP достаточно велики, а OSPF естественным способом найдёт путь через сеть при обнаружении отказа.

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

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

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

Если известна или предполагается поддержка BFD удалённой системой, а сессия BFD не находится в состоянии Up, следует предпринять соответствующий действия (такие как отзыв статических маршрутов). Если известно или предполагается отсутствие поддержки BFD в удалённой системе, такие действия, как отзыв маршрутов, не следует предпринимать.

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

6. Протоколы данных и демультиплексирование

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

Такой же метод можно применять для более тонкого разделения путей. Например, при работе нескольких дифференцированных служб [DIFFSERV] через IPv4 можно использовать сессию BFD для каждого уровня обслуживания. Пакеты BFD Control должны маркироваться как и пакеты данных для обеспечения общей судьбы трафика BFD и данных, а также для демультиплексирования начального пакета, пока ещё не произошёл обмен дискриминаторами.

7. Подсети с множеством каналов

Имеется много технологий объединения нескольких параллельный каналов на уровне N-1, рассматриваемых как один путь на уровне N. Механизмы работы с такими каналами выходят за рамки спецификации, однако в этом разделе приведено несколько примеров. Возможны и другие варианты применения.

7.1. Полная развязка

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

7.2. Подсказки от уровня N-1

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

7.3. Агрегирование сессий BFD

Другой вариант использует сессию BFD на каждом канале уровня N-1 и объединяет состояния нескольких сессий в один сигнал индикации для клиентов уровня N. Преимуществом такого подхода является независимость от технологии уровня N-1. Однако этот подход работает лишь в случае, когда сосед уровня N является соседом и на уровне N-1 (один интервал пересылки на уровне N-1).

7.4. Комбинированный вариант

В некоторых случаях может быть полезна комбинация нескольких описанных выше (или иных) вариантов. Например, если соседи уровня N не соединены напрямую на уровне N-1, система может организовать сессию BFD через каждый канал уровня N-1 с непосредственным соседом на этом уровне и другую сессию BFD с соседом на уровне N. Агрегатное состояние сессий BFD на уровне N-1 можно использовать в качестве триггера отказа сессии BFD уровня N.

8. Другие вопросы с приложениями

BFD может обеспечивать обнаружение активности функций, связанных с OAM³, в туннельных и псевдопроводных протоколах. Рекомендуется запуск BFD вне туннеля, поскольку при этом используется больше элементов пути. Одним из способов реализации является адресация пакетов BFD по конечным точкам туннеля в предположении наличия у них адресов.

Если на пути, где работает BFD, происходит плановая остановка, предпочтительно заранее отключить сеанс BFD, переведя его в статус AdminDown. Системе, заявившей статус AdminDown, следует сохранять его в течение по меньшей мере интервала Detection Time, чтобы удалённая система гарантированно увидела изменение статуса.

BFD следует исключить из конфигурации системы, если желательно не вызывать каких-либо действий клиентского приложения. Простое прекращение передачи пакетов BFD Control приведёт лишь к тому, что удалённая система обнаружит отказ сессии. Для предотвращения этого системе, в которой BFD исключается из конфигурации, следует перевести сессию в состояние AdminDown и поддерживать его в течение интервала Detection Time, чтобы удалённая система гарантированно увидела изменение статуса.

9. Вопросы совместимости

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

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

10. Конкретные взаимодействия протокола

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

10.1. Взаимодействие BFD и OSPFv2, OSPFv3 и IS-IS

Для двух версий OSPF ([OSPFv2] и [OSPFv3]), а также протокола IS-IS [ISIS] характерны архитектурные ограничения, связанные с тем, что протоколы Hello не способны достаточно точно фиксировать время обнаружения отказа. В частности, для OSPF минимальное время обнаружения составляет 2 секунды, а для IS-IS — 1 секунду.

BFD можно использовать для обеспечения в этих протоколах сколь угодно малого времени обнаружения за счёт дополнения к протоколам Hello.

10.1.1. Организация сессии

Наиболее очевидным выбором для запуска организации сессии BFD в этих трёх протоколах является применение механизма обнаружения протоколов Hello в OSPF и IS-IS. Сессии BFD для поддержки OSPF и IS-IS через одни интервал пересылки IP (hop) должны работать в соответствии с [BFD-1HOP].

10.1.2. Реакция на смену состояния BFD

Базовые механизмы описаны в разделе 3. В настоящее время OSPFv2 и OSPFv3 передают маршрутные сведения для одного протокола данных (IPv4 и IPv6, соответственно) поэтому при потребности в сигнализации о смене топологии после отказа сессии BFD это следует делать путём отключения соответствующего соседа OSPF.

IS-IS можно использовать для поддержки одного или нескольких протоколов данных. В [ISIS] задана общая топология для нескольких протоколов данных, а работа над поддержкой нескольких топологий ещё не завершена. При использовании разных топологий для поддержки нескольких протоколов данных (или нескольких классов обслуживания в одном протоколе) определяемый топологией путь, связанный с отказавшей сессией BFD, следует прекратить анонсировать в IS-IS LSP (Link⁴ Switched Path), чтобы сообщить о потере связности. В иных случаях об отказе в сессии BFD следует сообщать имитацией потери смежности IS-IS.

В OSPF имеется механизм сигнализации о плановом перезапуске, а в IS-IS такого механизма нет. Следует использовать подходящий механизм из числа описанных в параграфе 3.3.

10.1.3. Виртуальные каналы OSPF

Если нужно применять BFD для обнаружения отказов OSPF Virtual Link, должен применяться механизм, описанный в [BFD-MULTI], поскольку виртуальные каналы OSPF могут включать произвольное число пересылок (hop). В таких случаях следует и настоятельно рекомендуется применять аутентификацию BFD.

10.2. Взаимодействия с BGP

Протокол BFD может быть полезен в сессиях протокола EBGP (External Border Gateway Protocol) [BGP] для более быстрой смены топологии в случае отказа пути. Как отмечено в параграфе 4.4, сеансам IBGP обычно нецелесообразно взаимодействовать с BFD, если базовый протокол IGP уже делает это.

Сессии EBGP с применением BFD, можно организовать через один [BFD-1HOP] или несколько [BFD-MULTI] интервалов пересылки в зависимости от наличия прямой смежности с соседом. Сессию BFD следует организовывать с соседом BGP (в отличие от других Next Hop, анонсируемых в BGP). В таких случаях следует и настоятельно рекомендуется применять аутентификацию BFD.

В [BGP-GRACE] описан механизм Graceful Restart для протокола BGP. Если этот механизм не применяется в сессии EBGP и в соответствующей сессии BFD возникает отказ, сессию EBGP следует отключить в соответствии с параграфом 3.2. Если используется Graceful Restart, применимы базовые процедуры параграфа 4.3. в BGP Graceful Restart нет сигнализации планового перезапуска, поэтому применим параграф 4.3.2.2. При прерывании Graceful Restart в соответствии с параграфом 4.3 принимающему узлу следует действовать как при завершении отсчёта таймера перезапуска [BGP-GRACE].

10.3. Взаимодействия с RIP

Протокол RIP (Routing Information Protocol) [RIP] отличается тем, что состояние смежности с соседом, как таковое, не сохраняется (по крайней мере в соответствии со спецификацией). Вместо этого установленные маршруты включают адрес next hop, который в большинстве случаев является адресом анонсирующего соседа (но может не быть им).

В случае RIP при отказе сессии BFD, связанной с соседом, следует имитировать завершение отсчёта тайм-аута для каждого маршрута, полученного от этого соседа. Отметим, что при отказе сессии BFD в случае несовпадения полученного от соседа адреса next hop с адресом самого соседа маршрут будет сохраняться до естественного тайм-аута (180 секунд). Однако при отслеживании реализацией всех маршрутов от каждого соседа все маршруты от соседа, соответствующего отказавшей сессии BFD, следует исключить по тайм-ауту, независимо от указанного в них next hop и таким способом избежать проблемы «застревания» маршрута.

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

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

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

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

[BFD] Katz, D. and D. Ward, «Bidirectional Forwarding Detection», RFC 5880, June 2010.

[BFD-1HOP] Katz, D. and D. Ward,»Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)», RFC 5881, June 2010.

[BFD-MPLS] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, «Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)», RFC 5884, June 2010.

[BFD-MULTI] Katz, D. and D. Ward, «Bidirectional Forwarding Detection (BFD) for Multihop Paths», RFC 5883, June 2010.

[KEYWORDS] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

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

[BGP] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, January 2006.

[BGP-GRACE] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, «Graceful Restart Mechanism for BGP», RFC 4724, January 2007.

[DIFFSERV] Nichols, K., Blake, S., Baker, F., and D. Black, «Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers», RFC 2474, December 1998.

[ISIS] Callon, R., «Use of OSI IS-IS for routing in TCP/IP and dual environments», RFC 1195, December 1990.

[ISIS-GRACE] Shand, M. and L. Ginsberg, «Restart Signaling for IS-IS», RFC 5306, October 2008.

[OSPFv2] Moy, J., «OSPF Version 2», STD 54, RFC 2328, April 1998.

[OSPFv3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, «OSPF for IPv6», RFC 5340, July 2008.

[OSPF-GRACE] Moy, J., Pillay-Esnault, P., and A. Lindem, «Graceful OSPF Restart», RFC 3623, November 2003.

[RIP] Malkin, G., «RIP Version 2», STD 56, RFC 2453, November 1998.

Адреса авторов

Dave Katz

Juniper Networks

1194 N. Mathilda Ave.

Sunnyvale, CA 94089-1206

USA

Phone: +1-408-745-2000

EMail: dkatz@juniper.net

 

Dave Ward

Juniper Networks

1194 N. Mathilda Ave.

Sunnyvale, CA 94089-1206

USA

Phone: +1-408-745-2000

EMail: dward@juniper.net

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                           D. Katz
Request for Comments: 5881                                       D. Ward
Category: Standards Track                               Juniper Networks
ISSN: 2070-1721                                                June 2010

Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)

BFD для IPv4 и IPv6 через один интервал (hop)

PDF

Аннотация

Этот документ описывает применение протокола обнаружения двухсторонней пересылки (Bidirectional Forwarding Detection или BFD) для IPv4 и IPv6 при одном интервале пересылки IP (hop).

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

Этот документ является проектом стандарта Internet (Internet Standards Track).

Документ подготовлен IETF¹ и содержит согласованный взгляд сообщества IETF. Документ обсуждался публично и одобрен для публикации IESG². Дополнительная информация о стандартах Internet приведена в разделе 2 RFC 5741.

Информацию о текущем состоянии данного документа, обнаруженных ошибках и способах обратной связи можно найти по ссылке http://www.rfc-editor.org/info/rfc5881.

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

Авторские права ((c) 2010) принадлежат IETF Trust и лицам, являющимся авторами документа. Все права защищены.

К этому документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Одним из важных применений протокола BFD [BFD] является отслеживание связности IPv4 и IPv6 между соединёнными напрямую (без маршрутизаторов) системами. Это может служить дополнением к механизмам обнаружения в протоколах маршрутизации или применяться для отслеживания связности хоста с маршрутизатором и решения других задач.

Этот документ содержит сведения, требуемые для использования BFD в такой среде. Взаимодействия между BFD и другими протоколами и системными функциями описаны в документе «BFD Generic Applications» [BFD-GENERIC].

1.1. Уровни требований

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

2. Применение и ограничения

Протокол (приложение) BFD может применяться любой парой систем, взаимодействующих по протоколу IPv4 и/или IPv6 через один интервал IP (hop), включая физические и виртуальные каналы, туннели и т. п.

Каждая сессия BFD между парой систем должна проходить по своему пути сетевого уровня в обоих направлениях. Это нужно для корректного демультиплексирования, а также потому, что в противном случае (по определению) будет возникать несколько сессий для защиты одного пути.

Если BFD применяется с IPv4 и IPv6 на определённом пути, для каждого протокола должна создаваться своя сессия BFD (с инкапсуляцией в соответствующий протокол) через данный канал.

При использовании функции BFD Echo переданные пакеты незамедлительно возвращаются отправителю на интерфейс, который их передал. Это может взаимодействовать с другими механизмами, используемыми на двух системах, реализующих BFD. В частности, входная фильтрация [BCP38] не совместима со способом передачи пакетов Echo. Реализации, поддерживающие функцию Echo, должны обеспечивать отсутствие входной фильтрации на интерфейсе, применяющем функцию Echo или задавать исключение для входящих пакетов Echo.

От реализаций функции Echo также требуются прикладные интерфейсы (Application Programming Interface или API), которых может не быть в каждой системе. Система с поддержкой функции Echo должна быть способна передавать пакеты по своему адресу, для чего обычно требуется обходить обычный поиск в таблице пересылки. Как правило для этого требуется доступ к API для обхода функциональности уровня IP.

Отметим, что протокол BFD предназначен для роли механизма OAM³, служащего для проверки связности и соединений. Он применим для сетевых служб (например, взаимодействие между маршрутизаторами, пользователем и шлюзом, конечными точками LSP/каналов и обнаружение отказов оборудования). В таких ситуациях от оператора требуется корректное обеспечение скоростей, с которыми передаются пакеты BFD, чтобы избежать перегрузок (например, каналов, устройств ввода-вывода, процессоров) и ложных обнаружений отказов. Это не применимо для обнаружения отказов между приложениями через Internet, поскольку в сети не обеспечиваются требуемое обнаружение и предотвращение перегрузок и поэтому нет возможности предотвратить коллапс. Системы «хост-хост» или «приложение-приложение», развёрнутые через Internet, будут требовать инкапсуляции BFD в транспортный протокол, «дружественный» к TCP (TCP-friendly) [TFRC].

3. Инициализация и демультиплексирование

В описываемом варианте применения между двумя системами через данный интерфейс (физический или логический) для конкретного протокола будет создаваться лишь 1 сессия BFD. Эта сессия BFD должна быть привязана к данному интерфейсу. Таким образом, обе системы должны быть в роли активных (Active), передавая начальные пакеты BFD Control с Your Discriminator =0 и любой пакет BFD от удалённой машины с Your Discriminator = 0 должен ассоциироваться с сессией, привязанной к удалённой системе, интерфейсу и протоколу.

4. Инкапсуляция

Пакеты BFD Control должны передаваться в дейтаграммах UDP с портом получателя 3784 внутри пакетов IPv4 или IPv6. Порт отправителя должен быть из диапазона от 49152 до 65535. Для всех пакетов BFD Control, связанных с определённой сессией должен использоваться один порт отправителя UDP (source port). Для всех сессий BFD в системе следует выбирать уникальные номера портов. При одновременном использовании более 16384 сессий BFD номер порта UDP можно использовать в нескольких сессиях, но число сессий с одним номером порта следует минимизировать. Реализация может использовать номер порта отправителя UDP для демультиплексирования входящих пакетов BFD Control, но в конечном итоге для демультиплексирования пакетов в нужную сессию должны применяться механизмы [BFD].

Пакеты BFD Echo должны передаваться в дейтаграммах UDP с портом получателя 3785 внутри пакетов IPv4 или IPv6. Номер порта отправителя UDP эта спецификация не задаёт. Адрес получателя должен выбираться так, чтобы вызвать на удалённой системе пересылку пакета обратно в локальную систему. Адрес отправителя должен выбираться так, чтобы предотвратить генерацию удалённой системой сообщений ICMP или Neighbor Discovery Redirect. В частности адресу отправителя не следует быть частью подсети интерфейса, через который передаётся пакет BFD Echo, а также не следует быть адресом IPv6 link-local, пока нет уверенности (информации из других источников) в том, что удалённая система не будет передавать сообщений Redirect.

Пакеты BFD Echo должны передаваться так, чтобы гарантировать их получение удалённой системой. Например, в средах с множественным доступом это требует указания в качестве получателя адреса удалённой системы на канальном уровне.

Для выполнения приведённых выше требований возможно придётся обходить некоторые функции уровня IP, особенно в реализациях на хостах.

5. Проблемы TTL/Hop Limit

Если в сессии не применяется аутентификация BFD, все пакеты BFD Control в этой сессии должны передаваться со значением 255 в поле TTL или Hop Limit. Все полученные пакеты BFD Control, демультиплексируемые в сессию, должны отбрасываться, если TTL или Hop Limit отличается от 255. Описание механизма приведено в [GTSM].

Если в сессии применяется аутентификация BFD, все пакеты BFD Control должны передаваться со значением 255 в поле TTL или Hop Limit. Полученные пакеты BFD Control, демультиплексируемые в сессию, могут отбрасываться, если TTL или Hop Limit отличается от 255. При проверке TTL/Hop Limit она может выполняться до криптографической аутентификации, что позволяет избежать на приёмной стороне расчётов для пакетов, которые будут отброшены.

В контексте этого параграфа «использование аутентификации» означает передачу пакетов BFD Control с установленным битом Authentication, включающих Authentication Section, и отбрасывание всех демультиплексируемых в сессию пакетов, которые не были аутентифицированы (в соответствии с базовой спецификацией BFD).

6. Вопросы адресации

Реализации должны гарантировать передачу всех пакетов BFD Control по пути без маршрутизаторов (one-hop), защищённому BFD.

В сетях с множественным доступом пакеты BFD Control должны передаваться с адресами отправителя и получателя, относящимися к подсети (адресованные на интерфейсы подсети или отправленные из подсети).

На каналах «точка-точка» адрес отправителя пакета BFD Control недопустимо использовать для идентификации сессии. Это означает, что исходный пакет BFD должен восприниматься с любого адреса отправителя, а последующие пакеты BFD должны демультиплексироваться лишь по полю Your Discriminator (как обычно). Это позволяет при необходимости менять адрес отправителя. Если адрес отправителя в полученном пакете изменился, локальной системе недопустимо указывать его в качестве адреса получателя исходящих пакетов BFD Control, должен сохраняться адрес, заданный при создании сессии. Реализация может уведомить приложение о смене адреса соседа, чтобы приложение могло поменять адрес получателя или предпринять иные действия. Отметим, что проверка TTL/Hop Limit, описанная в разделе 5 (или применение аутентификации) предотвращает получение пакетов BFD от всех отправителей, кроме непосредственного соседа.

7. BFD в туннеле

Имеется много механизмов для туннелирования IPv4 и IPv6 через произвольную топологию. Если туннельный механизм не декрементирует TTL или Hop Limit для сетевого протокола, в котором передаются пакеты, описанный в этом документе механизм может служить для проверки живучести туннеля. Следует применять механизм аутентификации BFD и это настоятельно рекомендуется.

8. Взаимодействие с IANA

Порты 3784 и 3875 выделены IANA для использования в пакетах BFD Control и BFD Echo, соответственно.

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

В этом варианте применения значение TTL=255⁴ при передаче и получении пакетов в сочетании с привязкой к входному интерфейсу представляется обеспечивающим характеристики защиты, эквивалентные другим протоколам, используемым в инфраструктуре, поскольку подделка становится нетривиальной задачей. Влияние этого механизма на защиту рассматривается в [GTSM].

Влияние аутентификации BFD на защиту рассматривается в [BFD].

Использование проверки TTL=255 вместе с аутентификацией BFD обеспечивает снижение вычислительных издержек за счёт отбрасывания неаутентифицированных пакетов и может быть полезно в реализациях, где криптографическая контрольная сумма может быть подвержена атакам с отказом в обслуживании (denial-of-service). Использование этих механизмов (или отказ от них) не влияет на совместимость.

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

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

[BFD] Katz, D. and D. Ward, «Bidirectional Forwarding Detection», RFC 5880, June 2010.

[BFD-GENERIC] Katz, D. and D. Ward, «Generic Application of Bidirectional Forwarding Detection (BFD)», RFC 5882, June 2010.

[GTSM] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, «The Generalized TTL Security Mechanism (GTSM)», RFC 5082, October 2007.

[KEYWORDS] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

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

[BCP38] Ferguson, P. and D. Senie, «Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing», BCP 38, RFC 2827, May 2000.

[TFRC] Floyd, S., Handley, M., Padhye, J., and J. Widmer, «TCP Friendly Rate Control (TFRC): Protocol Specification», RFC 5348, September 2008.

Адреса авторов

Dave Katz

Juniper Networks

1194 N. Mathilda Ave.

Sunnyvale, CA 94089-1206

USA

Phone: +1-408-745-2000

EMail: dkatz@juniper.net

 

Dave Ward

Juniper Networks

1194 N. Mathilda Ave.

Sunnyvale, CA 94089-1206

USA

Phone: +1-408-745-2000

EMail: dward@juniper.net

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                          J. Touch
Request for Comments: 5925                                       USC/ISI
Obsoletes: 2385                                                A. Mankin
Category: Standards Track                            Johns Hopkins Univ.
ISSN: 2070-1721                                                R. Bonica
                                                        Juniper Networks
                                                               June 2010

The TCP Authentication Option

Опция аутентификации TCP

PDF

Аннотация

Этот документ содержит спецификацию опции аутентификации TCP (TCP-AO¹), которая отменяет опцию TCP MD5 Signature из RFC 2385 (TCP MD5). TCP-AO задает использование более строгих кодов MAC², защищающих от повторного использования пакетов даже в долгоживущих соединениях TCP и обеспечивает более четкую привязку ассоциации защиты с соединениями TCP, нежели TCP MD5. Опция TCP-AO совместима со статической настройкой MKT³ или внешним механизмом установки MKT по отдельному каналу. В обоих случаях TCP-AO защищает соединение при использовании одного MKT для разных экземпляров соединений, используя транспортные ключи, выведенные из MKT, и координирует замену MKT между конечными точками. Это предназначено для поддержки имеющейся инфраструктуры применения TCP MD5, например, защиты долгосрочных соединений (скажем, в BGP и LDP), а также для поддержки большего набора MAC с минимальными изменениями в системах и их работе. TCP-AO использует другой идентификатор опции по сравнению с TCP MD5, даже при том, что TCP-AO и TCP MD5 не могут применяться совместно. Опция TCP-AO поддерживает IPv6 и полностью совместима с предложенными требованиями для замены TCP MD5.

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

Этот документ содержит проект стандарта Internet (Internet Standards Track).

Документ является результатом работы IETF⁴ и представляет собой согласованное мнение членов (сообщества) IETF. Документ был представлен для публичного обсуждения и одобрен для публикации IESG⁵. Дополнительную информацию о стандартах Internet можно найти в разделе 2 документа RFC 5741.

Информацию о текущем состоянии этого документа, обнаруженных ошибках и способах обратной связи можно найти по ссылке http://www.rfc-editor.org/info/rfc5925.

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

Авторские права ((c) 2010) принадлежат IETF Trust и лицам, указанным в числе авторов документа. Все права защищены.

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

1. Введение

Сигнатура TCP MD5 (TCP MD5) является опцией TCP для проверки подлинности сегментов TCP, включая псевдозаголовок IP, заголовок и данные TCP. Она была предложена для защиты сессий BGP от обманных сегментов TCP, которые могли влиять на данные BGP или отказоустойчивость самих соединений TCP [RFC2385][RFC4953].

По поводу TCP MD5 было высказано много опасений. Использование простой хэш-аутентификации является проблематичным, поскольку были усилены атаки на сам механизм [Wa05]. В TCP MD5 также не достает гибкости управления ключами и алгоритмом. Этот документ добавляет гибкость выбора алгоритма и обеспечивает простой механизм координации ключей, позволяющих менять их в рамках соединения. Однако документ не предусматривает полного криптографического управления ключами по каналу TCP, поскольку сегменты TCP SYN не обеспечивают достаточного для такого согласования пространства (7.6. Влияние на размер заголовка TCP). Документ отменяет использование опции TCP MD5, меняя ее на более общую опцию TCP-AO. Новая опция позволяет применять более строгие функции хэширования, обеспечивает защиту от повторов в долгосрочных соединениях и повторяющихся экземплярах соединений, а также дает более явные рекомендации в части внешнего управления ключами. Результат совместим с IPv6 и полностью совместим с предложенными требованиями по замене TCP MD5 [Ed07].

TCP-AO отменяет TCP MD5, хотя конкретная реализация может для совместимости поддерживать оба механизма. Для данного соединения может применяться лишь один из этих механизмов. Защищенные TCP MD5 соединения нельзя перевести на TCP-AO, поскольку TCP MD5 не поддерживает изменения алгоритма защиты после организации соединения.

1.1. Используемые соглашения

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

В документе эти слова выделяются полужирным шрифтом, а обычное использование слов не означает уровня требования в соответствии с RFC 2119.

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

1.2. Заявление о применимости

Опция TCP-AO предназначена для поддержки имеющегося применения TCP MD5, такого как защита долгосрочных соединений протоколов маршрутизации, например, BGP и LDP. Опция также обеспечивает похожую защиту для долгосрочных соединений TCP и может применяться, например, между кэшами прокси, а не только или главным образом для протоколов маршрутизации.

Опция TCP-AO предназначена для замены (и отмены) применения TCP MD5. TCP-AO расширяет возможности TCP MD5, как отмечено в параграфе 1.3. Краткая сводка рекомендация этого документа приведена ниже.

>> Реализации TCP, поддерживающие TCP MD5, должны поддерживать TCP-AO.

>> TCP-AO следует реализовать там, где нужна аутентификация TCP по причине отсутствия поддержки IPsec или требуются конкретные свойства TCP-AO (например, ключи на уровне соединения).

>> TCP-AO можно реализовать в любом случае.

Опция TCP-AO не предназначена для использования со стеком IPsec (IPsec и IKE⁶) для защиты соединений TCP [RFC4301][RFC4306]. Конкретные различия указаны в параграфе 1.3. Фактически рекомендуется применять IPsec и IKE, особенно там, где желательна поддержка согласования параметров или сеансовых ключей, а также смена ключей. Опция TCP-AO предназначена для применения лишь там, где невозможно реализовать IPsec, например, для поддержки протоколов маршрутизации или когда нужно четко согласовывать ключи с отдельными транспортными сессиями [Ed07].

Опция TCP-AO не предназначена для использования с TLS⁷ [RFC5246], Secure BGP (sBGP), Secure Origin BGP (soBGP) [Le09] и иными механизмами, защищающими лишь поток данных TCP. TCP-AO защищает транспортный уровень, предотвращая атаки на сами соединения TCP [RFC4953]. Механизмы защиты потока данных защищают лишь содержимое сегментов TCP и могут быть нарушены воздействием на соединение. Некоторые из указанных протоколов защиты данных (особенно TLS) предлагают более широкий набор механизмов аутентификации и управления ключами, нежели TCP-AO, и таким образом, иначе защищают поток данных. TCP-AO можно применять вместе с защитой потока данных для дополнения.

1.3. Сводка отличий

Этот документ заменяет TCP MD5 [RFC2385] в отмеченных ниже аспектах.

• TCP-AO использует отдельную опцию Kind (29).

• TCP-AO позволяет использовать TCP MD5 для унаследованных соединений.

• TCP-AO заменяет один алгоритм TCP MD5 MAC, алгоритмами MAC, заданными в отдельных документах, и может быть расширен включением других MAC.

• TCP-AO позволяет менять ключи в соединении TCP при условии смены ключей по отдельному протоколу (out-of-band) или вручную. Опция включает идентификатор ключа (key ID), который эффективно позволяет использовать одновременно несколько ключей и механизм координации ключей «получить идентификатор следующего ключа» для смены ключей. Отметим, что TCP MD5 не препятствует смене ключей в соединении, но не требует поддержки этого. Кроме того, TCP-AO поддерживает смену ключей без потери сегментов, тогда как в TCP MD5 при смене ключей сегменты могут теряться во время перехода или может требоваться использования для полученных в процессе перехода сегментов разных ключей, поскольку ключи не имеют идентификаторов. Хотя TCP восстанавливает потерянные при смене ключа сегменты, это может существенно влиять на производительность.

• TCP-AO обеспечивает автоматическую защиту от повторов (replay) для долгосрочных соединений с помощью порядковых номеров.

• TCP-AO обеспечивает ключи трафика для соединения, уникальные для каждого соединения TCP, с использованием начальных порядковых номеров TCP (ISN⁸) для различения ключей даже при статических MKT в повторяющихся экземплярах соединений через одну пару сокетов.

• TCP-AO задает детали взаимодействия опции с состояниями TCP, обработкой событий и интерфейсом пользователя.

• TCP-AO на 2 байта короче опции TCP MD5 (16 вместо 18) в заданном изначально варианте (96 битов MAC).

Отличия TCP-AO от решения IPsec/IKE [RFC4301][RFC4306] перечислены ниже.

• TCP-AO не поддерживает динамического согласования параметров.

• TCP-AO включает пару сокетов TCP (адреса и порты отправителя и получателя) в качестве индекса параметров защиты (вместе с KeyID), не используя отдельного поля, как IPsec Security Parameter Index (SPI).

• TCP-AO вынуждает менять рассчитанные MAC при перезапуске соединения даже при сохранении пары сокетов TCP (адреса и номера портов) [Ed07].

• TCP-AO не поддерживает шифрования.

• TCP-AO не аутентифицирует сообщения ICMP (при использовании IPsec некоторые сообщения ICMP аутентифицируются в зависимости от конфигурации).

2. Опция аутентификации TCP

Опция TCP-AO использует значение Kind = 29. В последующих параграфах описана опция TCP-AO и приведен обзор TCP MD5 для сравнения.

2.1. Обзор опции TCP MD5

Структура опции TCP MD5 представлена на рисунке 1.

+---------+---------+-------------------+
| Kind=19 |Length=18| подпись MD5 …   |
+---------+---------+-------------------+
|      ... подпись (продолжение)...     |
+---------------------------------------+
|                  ...                  |
+---------------------------------------+
|                  ...                  |
+-------------------+-------------------+
| ...подпись (прод.)|
+-------------------+

Рисунок 1. Опция TCP MD5 [RFC2385].

В опции TCP MD5 поле размера фиксировано и дайджест (подпись) MD5 занимает 16 байтов вслед за полями Kind и Length (каждое по 1 байту), а полный размер подписи MD5 составляет 128 битов [RFC1321].

Опция TCP MD5 задает использование подписи MD5 для указанных ниже полей с соблюдением порядка.

1. Псевдозаголовок IP (IP-адреса отправителя и получателя, номер протокола, размер сегмента).

2. Заголовок TCP без опций и контрольной суммы.

3. Данные TCP (payload).

4. Ключ

2.2. Формат опции TCP-AO

TCP-AO обеспечивает надмножество возможностей TCP MD5 и минимальная в духе SP4 [SDNS88]. Опция TCP-AO включает поля Kind и поле Length как TCP MD5, а также поля KeyID и RnextKeyID, показанные на рисунке 2.

+------------+------------+------------+------------+
|  Kind=29   |   Length   |   KeyID    | RNextKeyID |
+------------+------------+------------+------------+
|                     MAC           ...
+-----------------------------------...

   ...-----------------+
   ...MAC (продолжение)|
   ...-----------------+

Рисунок 2. Опция TCP-AO.

Определения полей TCP-AO приведены ниже.

Kind

1-байтовое целое число без знака, указывающее опцию TCP-AO. Kind = 29.

>> Конечной точке недопустимо использовать TCP-AO в одном соединении с опцией TCP MD5. При наличии обеих опций протокол TCP должен отбрасывать сегмент без уведомления отправителя.

>> Одному сегменту TCP недопустимо включать долее 1 опции TCP-AO. При наличии нескольких опций протокол TCP должен отбрасывать сегмент без уведомления отправителя.

Length

1-байтовое целое число без знака, указывающее размер опции в байтах, включая поля Kind, Length, KeyID, RnextKeyID и MAC.

>> Поле Length должно иметь значение не меньше 4, в противном случае TCP должен отбрасывать сегмент без уведомления отправителя.

>> Значение поля Length должно соответствовать размеру заголовка TCP, в противном случае TCP должен отбрасывать сегмент без уведомления отправителя.

Проверка поля Length предполагает, что сумма размеров всех опций при сложении с размером базового заголовка TCP (5 слов) совпадает со значением поля TCP Offset. Такая полная проверка возможна, поскольку RFC 793 задает размер требуемых опций, а RFC 1122 требует, чтобы все новые опции использовали единый формат с фиксированным размером [RFC793][RFC1122]. Проверка может быть частичной с учетом лишь опции TCP-AO, когда размер TCP-AO в сумме со смещением TCP-AO от начала заголовка TCP не первышает размер заголовка TCP, указанный в поле Offset заголовка TCP.

Значение 4 и другие небольшие значения > 4 (например, указывающие очень короткие поля MAC) не запрещены, но бессмысленны для этой опции.

KeyID

1-байтовое целое число без знака, указывающее кортеж первичного ключа (MKT, параграф 3.1), служащий для генерации ключей трафика, который применяются при создании MAC для аутентификации данного сегмента.

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

>> KeyID может совпадать для обоих направления соединения, но это не требуется и не имеет особого смысла.

Это позволяет устанавливать MKT в группе устройств без предшествующей координации KeyID среди них, а также позволяет добавлять новые устройства в группу MKT без перенумерации KeyID. Эти два свойства особенно важны при использовании с шаблонами пар сокетов TCP для MKT, т. е. при использовании MKT для группы устройств, заданных шаблоном (3.1. Кортеж первичного ключа (MKT)).

RnextKeyID

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

Обеспечивается эффективная координация смены ключей (6.1. Координация применения новых MKT). Поле RNextKeyID не имеет криптографических свойств и нужно применять случайное, а не зарезервированное значение.

MAC (Message Authentication Code)

Содержимое поля определяется параметрами защитной ассоциации. Типичные MAC имеют размер 96-128 битов (12-16 байтов), но разрешен любой размер, помещающийся в аутентифицируемый сегмент. Расчет MAC описан в параграфе 5.1. Алгоритмы MAC.

>> Требуется поддержка TCP-AO MAC, определенных в [RFC5926] и могут поддерживаться другие MAC.

Поля TCP-AO не указывают алгоритм MAC явно (как TCP MD5) или неявно. Конкретный алгоритм является частью конфигурации защитной ассоциации и устанавливается отдельно (3. Ключи TCP-AO и их свойства).

Следует отметить, что TCP-AO не влияет на анонсируемый максимальный размер сегмента TCP (Maximum Segment Size или MSS), как другие опции TCP [Bo09].

В оставшейся части документа описана обработка TCP-AO и связь опции с TCP.

3. Ключи TCP-AO и их свойства

Работа TCP-AO основана на двух наборах ключей для аутентификации входящих и исходящих сегментов — MKT, а также ключах трафика. MKT служат для создания уникальных ключей трафика и содержат ключевой материал для генерации этих ключей, а также указывают параметры, с которыми применяются ключи. К таким параметрам относится набор аутентифицируемых опций TCP, а также индикаторы алгоритмов, применяемых для вывода ключей трафика и расчета MAC. Ключи трафика являются материалом при расчете MAC для отдельных сегментов TCP.

3.1. Кортеж первичного ключа (MKT)

Кортеж первичного ключа (MKT) описывает свойства опции TCP-AO, связанной с 1 или несколькими соединениями.

TCP connection identifier — идентификатор соединения TCP

Пара сокетов TCP (локальные и удаленные адреса IP и номера портов TCP). Значения можно задавать частично с помощью диапазона (например, 2-30), маски (например, 0xF0), шаблона (например, «*») или иным способом.

TCP option flag — флаг опции TCP

Этот флаг указывает, включаются ли отличные от TCP-AO опции TCP в расчет MAC. При включении опций их содержимое в порядке указания включается в MAC с использованием значения 0 для поля TCP-AO MAC. Если опции не включены, в расчете учитывается лишь TCP-AO, а прочие опции пропускаются (без обнуления). Отметим, что опция TCP-AO учитывается всегда (с обнулением поля MAC), независимо от установки данного флага. Это защищает индикацию размера MAC, а также поля идентификаторов ключей (KeyID, RNextKeyID). Флаг применим к обциям TCP в обоих направлениях (входящие и исходящие сегменты).

IDs — идентификаторы

Значения, используемые в полях KeyID и RNextKeyID опции TCP-AO и служащие для различения MKT при одновременном использовании (KeyID), а также для индикации MKT, готовых для использования в противоположном направлении (RnextKeyID).

Каждый MKT имеет два идентификатора — SendID и RecvID. Первый помещается в поле KeyID опции TCP-AO в исходящих сегментах, а RecvID сопоставляется с TCP-AO KeyID во входящих сегментах. Применение идентификаторов рассмотрено в параграфах 7.4 и 7.5.

>> MKT ID должны поддерживать любые значения от 0 до 255, включительно. Резервных значений нет.

Значения ID выделяются произвольно, т. е. не требуется их монотонного роста, нет резервных значений и им не придается какого-либо особого смысла. Значения могут выделяться по порядку или на основе любого метода, согласованного конечными точками соединения (например, с помощью механизма внешнего управления MKT).

>> Недопустимо предполагать случайное назначение ID.

Master key — первичный ключ

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

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

Key Derivation Function (KDF) — функция вывода ключей

Указывает функцию вывода ключей и их параметров, используемую для генерации ключей трафика из первичных ключей. Описание приведено в параграфе 5.2 и в [RFC5926].

Message Authentication Code (MAC) algorithm — алгоритм кода аутентификации сообщений

Указывает алгоритм MAC и его параметры, применяемые для данного соединения. Дополнительная информация приведена в параграфе 5.1 и [RFC5926].

>> Компоненты MKT недопустимо менять в течение работы соединения.

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

>> Набор MKT можно менять в процессе работы соединения.

Параметры MKT не меняются и можно установить новые MKT и соединение может сменить применяемый MKT.

>> Недопустимо перекрытие идентификаторов MKT в случае перекрытия идентификаторов соединений TCP.

Этот документ не задает способ создания MKT пользователем или процессом. Предполагается, что MKT, влияющий на конкретное соединение, не может быть уничтожен для активного соединения или (что эквивалентно) его параметры копируются в локальную область соединения (создается экземпляр) и поэтому изменения будут влиять лишь на новые соединения. Для управления MKT может применяться отдельный прикладной протокол.

3.2. Ключи трафика

Ключ трафика выводится и MKT и пар адресов IP и номеров портов TCP (локальные и удаленные), а для организованных соединений — исходных порядковых номеров TCP (Initial Sequence Number или ISN) в каждом направлении. Сегменты, переданные до организации соединения используют ту же информацию, заменяя неизвестные значения 0 (например, несогласованные ISN).

Один кортеж MKT можно использовать для создания 4 разных ключей трафика:

• Send_SYN_traffic_key;

• Receive_SYN_traffic_key;

• Send_other_traffic_key;

• Receive_other_traffic_key.

Отметим, что ключи являются односторонними. Данной соединение обычно применяет лишь 3 из этих ключей, поскольку обычно используется только один из ключей SYN. Все 4 ключа применяются при «одновременном открытии» соединения [RFC793].

Связи между MKT и ключами трафика показаны на рисунке 3, где ключи трафика помечены символом *. Отметим, что каждый MKT можно использовать для создания любого из 4 ключей трафика, но рассчитывать требуется лишь ключи, реально нужные для обработки сегментов соединения. Подробное описание генерации ключей дано в параграфе 5.2.

                  MKT-A                            MKT-B
         +---------------------+        +------------------------+
         | SendID = 1          |        | SendID = 5             |
         | RecvID = 2          |        | RecvID = 6             |
         | MAC = HMAC-SHA1     |        | MAC = AES-CMAC         |
         | KDF = KDF-HMAC-SHA1 |        | KDF = KDF-AES-128-CMAC |
         +---------------------+        +------------------------+
                    |                                |
         +----------+----------+                     |
         |                     |                     |
         v                     v                     v
    Соединение 1          Соединение 2          Соединение 3
+------------------+  +------------------+  +------------------+
| * Send_SYN_key   |  | * Send_SYN_key   |  | * Send_SYN_key   |
| * Recv_SYN_key   |  | * Recv_SYN_key   |  | * Recv_SYN_key   |
| * Send_Other_key |  | * Send_Other_key |  | * Send_Other_key |
| * Recv_Other_key |  | * Recv_Other_key |  | * Recv_Other_key |
+------------------+  +------------------+  +------------------+

Рисунок 3. Связь между MKT и ключами трафика.

3.3. Свойства MKT

TCP-AO требует, чтобы каждый защищаемый сегмент TCP соответствовал в точности одному MKT. Когда исходящий сегмент соответствует MKT, применяется опция TCP-AO, в противном случае она не используется. Одному исходящему сегменту может соответствовать несколько MKT, например при смене MKT. Эти MKT не могут иметь конфликтующих идентификаторов, и должен быть некий механизм, определяющий MKT, применяемый для данного исходящего сегмента.

>> Исходящий сегмент TCP должен соответствовать не более, чем одному желаемому MKT, указанному парой сокетов сегмента. Сегмент может соответствовать нескольким MKT, при условии указания единственного желаемого MKT. Для определения желаемого MKT может использоваться другая информация в сегменте, но в нее недопустимо включать значения полей каких-либо опций TCP.

Рекомендуется использовать в механизме выбора MKT лишь ту информацию, которую TCP-AO будет аутентифицировать. Поскольку MKT могут указывать, что опции, не относящиеся к TCP-AO, можно игнорировать при расчете MAC, рекомендуется не применять эти опции при выборе MKT.

>> Входящий сегмент TCP, включая TCP-AO, должен соответствовать в точности одному MKT, указанному исключительно парой сокетов и TCP-AO KeyID.

Входящие сегменты включают внутри TCP-AO индикатор выбора среди подходящих MKT — поле KeyID. TCP-AO требует, чтобы для выбора среди подходящих MKT применялось лишь поле KeyID, что позволяет координировать смену MKT с помощью смены ключа в TCP-AO.

>> Когда исходящий сегмент TCP не соответствует никакому MKT, опция TCP-AO не применяется. TCP-AO всегда используется для исходящих сегментов, соответствующих MKT, и не применяется в иных случаях.

4. Параметры TCP-AO для соединения

TCP-AO использует небольшое число параметров, связанных с каждым соединение, которое использует TCP-AO после организации. Эти значения могут сохраняться в блоке управления транспортом (Transport Control Block или TCB) [RFC793]. Значения описаны в последующих параграфах документа, а список их приведен ниже.

1. Current_key — MKT, применяемый в настоящее время для аутентификации исходящих сегментов, где SendID помещается в сегмент как KeyID (параграф 7.4, 2.f). Входящие сегменты аутентифицируются с помощью MKT, соответствующего сегменту и его TCP-AO KeyID (параграф 7.5, 2.c) по сопоставлению с MKT идентификатора соединения TCP и MKT RecvID. В каждый момент для данного соединения имеется лишь одно значение current_key.

   >> Каждое соединение TCP в состоянии, отличном от IDLE, должно иметь не более одного current_key.

2. Rnext_key — MKT, предпочитаемый в настоящее время для входящих (принимаемых) сегментов, где RecvID помещен в исходящий сегмент как RNextKeyID (параграф 7.4, 2.d).

   >> Каждое соединение TCP в состоянии, отличном от IDLE, должно иметь не более одного rnext_key.

3. Пара SNE (Sequence Number Extension — расширение с порядковым номеров). SNE служат для предотвращения атак с повторным использованием (replay), как описано в параграфе 6.2. Каждый SNE инициализируется значением 0 при создании соединения. Использование номеров при расчете MAC описано в параграфе 5.1.

4. Один или несколько кортежей MKT, которые соответствуют паре сокетов данного соединения.

   MKT применяются вместе с другими параметрами соединения для создания уникальных ключей трафика в каждом соединении, как описано в параграфе 5.2. Эти ключи могут кэшироваться после расчета и сохраняться в TCB с соответствующей информацией MKT. Они могут считаться частью параметров соединения.

5. Криптографические алгоритмы

TCP-AO использует криптографические алгоритмы для расчета MAC (код аутентификации сообщения), применяемого при проверке подлинности сегмента и его заголовков, которые называют алгоритмами MAC. Эти алгоритмы задаются в отдельных документах для упрощения независимого от протокола обновления требований к алгоритмам [RFC5926]. TCP-AO также применяет криптографические алгоритмы для преобразования MKT, которые могут совместно использоваться несколькими соединениями, в уникальные для каждого соединения ключи трафика. Это называется функциями вывода ключей (Key Derivation Function или KDF) и также задано в [RFC5926]. В данном разделе описано использование алгоритмов в TCP-AO.

5.1. Алгоритмы MAC

Алгоритмы MAC принимают на входе данные переменного размера и ключ, возвращая на выход число фиксированного размера. Это число служит для определения, поступили ли входные данные от источника с тем же ключом и не были ли они подменены в процессе передачи. Интерфейс кодов MAC для TCP-AO показан ниже.

      MAC = MAC_alg(traffic_key, message)

Ввод: MAC_alg, traffic_key, message

Вывод: MAC

Определения элементов интерфейса представлены ниже.

MAC_alg

Конкретный алгоритм MAC, применяемый для расчета. Алгоритм MAC задает выходной размер, поэтому отдельного поля размера не требуется, см. [RFC5926].

Traffic_key

Ключ трафика, используемый для расчета. Расчет выполняется с текущим MKT соединения (параграф 5.2).

Message

Входные данные, для которых рассчитывается MAC. В TCP-AO это сегмент TCP, которому предшествует псевдозаголовок IP и заголовок TCP, как описано в этом параграфе.

MAC

Выход алгоритма MAC с заданными параметрами (постоянный размер).

На момент написания этого документа, для алгоритмов, применяемых в TCP-AO, как описано в [RFC5926], задана отсечка до 96 битов. Хотя каждый из алгоритмов дает MAC большего размера, 96 битов обеспечивают разумный компромисс между защищенностью и размером сообщения. Однако в будущем это может измениться, поэтому размер TCP-AO не следует предполагать постоянным.

Алгоритм MAC, используемый для расчета кода MAC в соединении, выполняется в соответствии с определением MKT из [RFC5926].

Обязательные для реализации алгоритмы MAC в опции TCP-AO описаны в отдельном RFC [RFC5926]. Это позволяет выполнить для спецификации TCP-AO процесс стандартизации IETF Standards Track, даже при возникновении потребности в замене алгоритмов и их меток (которые могут применяться на пользовательском интерфейсе и в протоколах автоматизированного управления MKT) в результате изменений в динамичном мире криптографии.

>> Могут поддерживаться дополнительные алгоритмы, не требуемые в TCP-AO.

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

1. Порядковый номер (SNE) с сетевым порядком байтов, как показано ниже (см. также параграф 6.2).

   +--------+--------+--------+--------+
   |                SNE                |
   +--------+--------+--------+--------+

   Рисунок 4. Порядковый номер.

   
   SNE для передаваемых сегментов поддерживаются локально в переменной SND.SNE, а для принятых сегментов используется локальное значение RCV.SNE. Детали поддержки и использования этих значений приведены в параграфах 6.2, 7.4 и 7.5.

2. Псевдозаголовок IP с адресами IP для отправителя и получателя, номером протокола и размером сегмента, заданными в сетевом порядке байтов, предшествующий заголовкуTCP. Псевдо заголовок IP не отличается от применяемого для расчета контрольной суммы TCP в случаях IPv4 [RFC793] и IPv6 [RFC2460].

+--------+--------+--------+--------+
|           Source Address          |
+--------+--------+--------+--------+
|         Destination Address       |
+--------+--------+--------+--------+
|   0    |Протокол|    TCP Length   |
+--------+--------+--------+--------+

Рисунок 5. Псевдозаголовок IPv4 для TCP.

+--------+--------+--------+--------+
|                                   |
+                                   +
|                                   |
+           Source Address          +
|                                   |
+                                   +
|                                   |
+                                   +
+--------+--------+--------+--------+
|                                   |
+                                   +
|                                   |
+         Destination Address       +
|                                   |
+                                   +
|                                   |
+--------+--------+--------+--------+
| Размер данных вышележащего уровня |
+--------+--------+--------+--------+
|        0        |   Next Header   |
+--------+--------+--------+--------+

Рисунок 6. Псевдозаголовок IPv6 [RFC2460].

3. Заголовок TCP, включающий по умолчанию опции, где при расчете поля контрольной суммы TCP и TCP-AO MAC принимаются нулевыми. Байты располагаются в сетевом порядке.

   Флаг опций TCP в MKT определяет включение полей опций TCP в расчет MAC. При включении опций для расчета обнуляется лишь поле TCP-AO MAC. Если флаг указывает исключение опций, все опции TCP, за исключением TCP-AO, опускаются при расчете MAC. Значение поля TCP-AO MAC при расчете принимается нулевым.

4. Данные TCP, т. е. содержимое сегмента TCP.

   Отметим, что ключи трафика не считаются частью данных, их использование задает алгоритм MAC (например, в качестве HMAC [RFC2104][RFC2403]). Ключи трафика выводятся из текущего MKT, как указано в параграфе 5.2.

5.2. Функции выведения ключей трафика

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

      traffic_key = KDF_alg(master_key, context, output_length)

Ввод: KDF_alg, master_key, context, output_length

Вывод: traffic_key

Описание параметров создания ключей трафика представлено ниже.

KDF_alg

Конкретная функция KDF, служащая основным элементом создания ключей трафика в соответствии с текущим MKT (см. [RFC5926]).

Master_key

Строка первичного ключа (master_key), хранящаяся в связанном MKT.

Context

Контекст, служащий вводом при создании ключа трафика traffic_key, как указано в [RFC5926]. Конкретный способ использования контекста и других данных для обеспечения необработанного вывода KDF описан в [RFC5926].

Output_length

Желаемый размер вывода KDF, т. е. размер, до которого этот вывод отсекается в соответствии с [RFC5926].

Traffic_key

Желаемый вывод KDF размером output_length, для использования в качестве входных данных алгоритма MAC, как описано в параграфе 5.1.

Контекст, служащих вводом для KDF, включает пару сокетов TCP и начальные порядковые номера (ISN) для соединения. Эти данные уникальны для каждого экземпляра соединения TCP, что позволяет TCP-AO создавать уникальные ключи трафика для соединения даже при использовании MKT на нескольких соединениях или при повторяющихся соединениях с той же парой сокетов. Контекст KDF показан на рисунках 7 и 8.

+--------+--------+--------+--------+
|           Source Address          |
+--------+--------+--------+--------+
|         Destination Address       |
+--------+--------+--------+--------+
|   Source Port   |    Dest. Port   |
+--------+--------+--------+--------+
|            Source ISN             |
+--------+--------+--------+--------+
|             Dest. ISN             |
+--------+--------+--------+--------+

Рисунок 7. Контекст KDF для соединения IPv4.

+--------+--------+--------+--------+
|                                   |
+                                   +
|                                   |
+           Source Address          +
|                                   |
+                                   +
|                                   |
+                                   +
+--------+--------+--------+--------+
|                                   |
+                                   +
|                                   |
+         Destination Address       +
|                                   |
+                                   +
|                                   |
+--------+--------+--------+--------+
|   Source Port   |    Dest. Port   |
+--------+--------+--------+--------+
|            Source ISN             |
+--------+--------+--------+--------+
|             Dest. ISN             |
+--------+--------+--------+--------+

Рисунок 8. Контекст KDF для соединения IPv6.

Ключи трафика являются «направленными», поэтому отправитель и получатель интерпретируются по-разному для входящих и исходящих сегментов. Во входящих сегментах отправителем является удаленный сайт, в исходящих — локальный. Это гарантирует уникальность ключей для каждого направления.

Для сегментов с флагом SYN (но без ACK) значение ISN получателя неизвестно. Поэтому для них ключ соединения рассчитывается с использованием показанного выше контекста с нулевым значением Destination ISN. Для прочих сегментов используется известная пара ISN. Если значение ISN неизвестны (например, при отправке RST после перезагрузки), сегмент следует передавать без аутентификации. Если же аутентификация требуется, создать корректный код MAC все равно не удастся и сегмент будет отброшен при получении.

>> Сегменты TCP-AO SYN (SYN, без ACK) должны использовать Destination ISN = 0 (отправляемые и принимаемые), все прочие сегменты используют известную пару ISN.

В целом это означает, что каждое соединение будет иметь 4 разных ключа трафика для каждого MKT, как показано ниже.

Send_SYN_traffic_key

Ключ трафика, служащий для аутентификации исходящих сегментов SYN. Значение Source ISN известно (локальный ISN соединения TCP), Destination ISN (удаленный) неизвестно (используется 0).

Receive_SYN_traffic_key

Ключ трафика, служащий для аутентификации входящих сегментов SYN. Значение Source ISN известно (удаленный ISN соединения TCP), Destination ISN неизвестно (используется 0).

Send_other_traffic_key

Ключ трафика, служащих для аутентификации всех прочих исходящих сегментов TCP.

Receive_other_traffic_key

Ключ трафика, служащих для аутентификации всех прочих входящих сегментов TCP.

В приведенной ниже таблице показано, как рассчитывается каждый из этих ключей. Алгоритмы TCP-AO используют адреса IP (IP) для отправителя (S) и получателя (D), порты TCP (port), номера ISN (ISN) и каждый сегмент (входящий или исходящий) помечен как относящийся к локальной (l) или удаленной ® стороне.

	S-IP	S-port	S-ISN	D-IP	D-port	D-ISN
Send_SYN_traffic_key	l-IP	l-port	l-ISN	r-IP	r-port	0
Receive_SYN_traffic_key	r-IP	r-port	r-ISN	l-IP	l-port	0
Send_other_traffic_key	l-IP	l-port	l-ISN	r-IP	r-port	r-ISN
Receive_other_traffic_key	r-IP	r-port	r-ISN	l-IP	l-port	l-ISN

Использование обоих номеров ISN в расчетах ключей трафика гарантирует предотвращение повторного использования сегментов в повторяющихся соединениях через те же сокеты. 32-битовые номера позволяют избавиться от повторов за исключением случаев перезагрузки. Повторное использование предполагает, что обе стороны повторяют свое использование в том же соединении. Ожидается, что:

>> конечным точкам следует выбирать номера ISN псевдослучайно, например, как указано в [RFC1948].

Сегменты SYN аутентифицируются с нулевым значением ISN получателя (при отправке и приеме), а все прочие сегменты используют пару ISN для соединения. Имеются другие случаи, когда значение Destination ISN неизвестно, но сегменты передаются (например после перезагрузки конечной точки), хотя у конечных точек может не быть информации, достаточной для аутентификации сегментов. Это дополнительно рассматривается в параграфе 7.7.

5.3. Вопросы организации и срока действия ключей трафика

TCP-AO не предоставляет механизма согласования ключей трафика или параметров (алгоритм MAC, размер, использование TCP-AO для соединения), а также смены ключей в соединении. Предполагается использование механизмов распространения MKT, согласования параметров и смены ключей по отдельным каналам. Разделение использования и поддержки MKT похоже на применяемое в стеке IPsec [RFC4301][RFC4306].

Пользователям TCP-AO предлагается применять известные методы генерации подходящих MKT, включая обоснованный размер первичного ключа, ограничение совместного использования ключей трафика и продолжительности действия MKT в соответствии с [RFC3562]. Этот также включает использование в соединении отдноразовых значений (nonce), как предложено в параграфе 5.2⁹.

TCP-AO поддерживает смену ключей с согласованием и координацией новых MKT по отдельному каналу с помощью протокола или вручную [RFC4808]. Новые MKT применяются скоординировано с использованием отдельного (out-of-band) механизма для обновления обеих конечных точек TCP. Когда в каждый момент применяется лишь один MKT, временное использование недействительного MKT может приводить к отбрасыванию сегментов. Хотя протокол TCP достаточно устойчив к такому отбрасыванию, в TCP-AO применяется поле KeyID, позволяющее избежать потерь. Данное соединение может иметь несколько соответствующих MKT, а поле KeyID служит для выбора MKT, соответствующего используемому для сегмента ключу трафика для предотвращения необходимости выбора MKT методом проб и ошибок.

TCP-AO предоставляет явный механизм координации MKT, описанный в параграфе 6.1. такой механизм полезен при установке новых MKT или смене MKT для определения момента начала использования установленных MKT.

Пользователям рекомендуется поддерживать MKT в соответствии с рекомендациями по управления ключами при использовании TCP MD5 [RFC3562], в частности, применять подходящий размер ключей (12-24 байта) и избегать совместного использования MKT во множестве партнерских связей BGP.

5.3.1. Повторное использование MKT для пары сокетов

MKT можно неоднократно применять для разных пар сокетов в рамках хоста или в разных экземплярах соединения для той же пары сокетов на хосте. В любом случае обеспечивается защита от повторного использования сегментов (replay).

Повторное использование MKT для разных пар сокетов не открывает возможность для replay-атак, поскольку пара сокетов TCP включается в MAC и генерацию ключей трафика. Повторное использование в повторяющихся экземплярах соединений с той же парой сокетов также не способствует таким атакам, поскольку в ключи трафика включаются ISN соединения, а повтор пары ISN маловероятен в разумные сроки.

5.3.2. Использование MKT в долгосрочных соединениях

TCP-AO использует расширение для порядковых номеров (SNE) с целью предотвращения атак на долгосрочные соединения. Явное обновление MKT с помощью внешних механизмов и индексирование на основе поля KeyID можно использовать для смены ключевого материала по разным причинам (например, при смене персонала), но это не требуется для поддержки долгосрочных соединений.

6. Дополнительные механизмы защиты

TCP-AO добавляет механизмы поддержки активного использования, особенно в средах, где доступна поддержка ключей лишь вручную. Это включает описанные ранее механизмы поддержки множества одновременных MKT (с помощью поля KeyID) и генерацию уникальных ключей трафика для соединения (с помощью KDF). В этом разделе описаны дополнительные механизмы координации смены MKT и предотвращения replay-атак при продолжительном использовании ключа трафика.

6.1. Координация применения новых MKT

В любой конкретный момент соединение TCP может иметь несколько MKT, заданных для сегментов каждого направления (входящие, исходящие). TCP-AO обеспечивает механизм индикации готовности нового MKT, что позволяет отправителю начать использование этого нового MKT. Этот механизм позволяет скоординировать применение новых MKT для предотвращения неоправданных потерь при аутентификации отправителя с использованием MKT, еще не готового у получателя.

Отметим, что это предназначено для оптимизации. Решение о начале применения нового ключа является вопросом производительности. Предполагается удаление недействительных MKT. TCP-AO не предоставляет механизмов для координации такого удаления, поскольку это считается операцией управления ключами.

Использование нового MKT координируется с помощью двух идентификаторов в заголовке:

• KeyID;

• RnextKeyID.

KeyID представляет информацию исходящего MKT, применяемую отправителем сегмента для создания MAC (исходящий), а соответствующая информация о входных ключах применяется получателем для проверки этого MAC и включает SendID для MKT, применяемого сейчас в данном направлении.

RNextKeyID представляет сведения о предпочтительном MKT для следующих принимаемых сегментов (receive next), что обеспечивает отправителю сегмента способ указать готовность входящего MKT для принимаемых впредь сегментов и позволяет получателю сегмента узнать, когда следует сменить MKT (а также KeyID и связанные с ними ключи трафика). Это RecvID первичного ключа MKT, желаемого во входящих сегментах.

Имеется 2 указателя, сохраняемые на каждой стороне соединения и содержащие сведения для соединения (раздел 4):

• активный в данный момент исходящий ключ MKT (current_key);

• текущее предпочтение для кходящего MKT (rnext_key).

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

Rnext_key указывает входящий MKT, который готов и является предпочтительным для использования, а при организации соединения — активный в данный момент входящий MKT. Значение может быть изменено при установке новых MKT (например, протоколом автоматической смены MKT или ручным выбором пользователя).

Rnext_key меняется лишь вручную пользователем или операцией протокола управления MKT, но не TCP-AO. Current_key обновляется TCP-AO при обработке принятых сегментов TCP, как описано в параграфе 7.5. Отметим, что алгоритм позволяет сменить current_key на новый MKT, а затем вернуться к прежнему MKT («резервное копирование»). Это может происходить при смене MKT, когда сегменты принимаются с нарушением порядка, и считается свойством TCP-AO, поскольку нарушение порядка не ведет к отбрасыванию сегмента. Единственным способом предотвратить повторное использование прежнего MKT является удаление MKT, признанных ненужными.

6.2. Предотвращение повторов в долгосрочных соединениях

TCP использует 32-битовый порядковый номер, который может повторяться в долгосрочных соединениях. Это может приводить к преднамеренному и легитимному повторному использованию сегментов TCP в соединениях. TCP-AO предотвращает replay-атаки и для этого нужно отличать допустимые повторы от прочих, для чего используется расширение порядковых номеров в форме 32-битовых SNE в принимаемых и передаваемых сегментах.

SNE расширяют порядковые номера TCP так, что сегменты в одном соединении всегда уникальны. При переходе порядкового номера TCP от максимума к началу, возникает вероятность полного повтора сегмента. Использование SNE позволяет различать идентичные сегменты с одинаковыми номерами в разные моменты работы соединения. TCP-AO имитирует 64-битовое пространство порядковых номеров, определяя рост старших 32-битов номера (SNE) по переходу младшей части (TCP) через максимум.

TCP-AO поддерживает SND.SNE для передаваемых сегментов и RCV.SNE для принимаемых, инициализируя их значением 0 при организации соединения. Назначение SNE состоит в организации вместе с 32-битовыми порядковыми номерами TCP единого 64-битового пространства номеров.

Для передаваемых сегментов SND.SNE можно реализовать путем расширения имеющегося порядкового номера TCP до 64 битов, при этом SND.SNE содержит старшие 32 бита номера. Для принимаемых сегментов TCP-AO приходится имитировать использование 64-битовых номеров и корректно выводить 32 старших бита номера RCV.SNE из полученного 32-битового порядкового номера и текущего контекста соединения.

Реализация SNE не задается в этом документе, но одним из возможных способов является использование RCV.SNE, SND.SNE или обоих номеров.

Рассмотрим реализацию с двумя SNE (SND.SNE, RCV.SNE) и приведенными ниже дополнительными переменными, которые вместе с текущим номером сегмента TCP (SEG.SEQ) инициализируются нулями:

• SND.PREV_SEQ для детектирования перехода SND.SEQ через максимум;

• RCV.PREV_SEQ для детектирования перехода RCV.SEQ через максимум;

• SND.SNE_FLAG для индикации инкремента SND.SNE;

• RCV.SNE_FLAG для индикации инкремента RCV.SNE.

При получении сегмента приведенный ниже код рассчитывает SNE, использованный в MAC, для стороны RCV (на стороне SND можно применить эквивалентный алгоритм).

      /* Установка флага при первом переходе SEG.SEQ через максимум */
      if ((RCV.SNE_FLAG == 0)
         && (RCV.PREV_SEQ > 0x7fffffff) && (SEG.SEQ < 0x7fffffff10)) {
            RCV.SNE = RCV.SNE + 1;
            RCV.SNE_FLAG = 1;
      }
      /* Выбор SNE для использования после инкрементирования */
      if ((RCV.SNE_FLAG == 1) && (SEG.SEQ > 0x7fff)) {
         SNE = RCV.SNE - 1; # use the pre-increment value
      } else {
         SNE = RCV.SNE; # use the current value
      }
      /* Сброс флага в «середине» окна */
      if ((RCV.PREV_SEQ < 0x7fffffff) && (SEG.SEQ > 0x7fffffff)) {
         RCV.SNE_FLAG = 0;
      }
      /* Сохранение текущего SEQ для следующего применения кода */
      RCV.PREV_SEQ = SEG.SEQ;

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

Если флаг установлен и встречается большой номер, требуется восстановление порядка сегментом, поэтому используется прежнее (до инкрементирования) значение SNE.

К моменту достижения максимум флаг будет сброшен.

Флаг предотвращает повторное инкрементирование SNE и сбрасывается в середине окна (когда старый номер из нижней половины, а новый из верхней). Поскольку размер окна приема никогда не превышает половину пространства номеров, невозможно установить и сбросить флаг одновременно — остающиеся в сети сегменты независимо от нарушения порядка не могут быть одновременно в обеих половинах пространства номеров.

7. Взаимодействие TCP-AO с TCP

Ниже описано влияние TCP-AO на состояния, сегменты, события и интерфейсы TCP. Описание предназначено для дополнения сведений о TCP, как это предусмотрено в [RFC793].

7.1. Пользовательский интерфейс TCP

Пользовательский интерфейс TCP активно и пассивно поддерживает команды OPEN, SEND, RECEIVE, CLOSE, STATUS, ABORT. TCP-AO не меняет этот интерфейс применительно к TCP, но некоторые команды или последовательности команд нужно изменить для поддержки TCP-AO. Детали этих изменений в TCP-AO не задаются.

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

>> TCP OPEN или последовательность команд настройки соединения для перехода в активное или пассивное состояние OPEN должна быть дополнена возможностью настройки.

>> реализация TCP-AO должна разрешать изменение набора MKT для исходящих соединений TCP (не CLOSED).

MKT, связанные с соединением, должны быть доступные для подтверждения, включая возможность чтения этих MKT.

>> TCP STATUS следует дополнить для обеспечения возможности читать MKT текущего или ожидающего соединения (для подтверждения).

Отправителям может потребоваться возможность определять смену исходящего MKT (KeyID) или указание нового предпочтительного MKT (RnextKeyID). Эти изменения сразу влияют на все последующие исходящие сегменты.

>> TCP SEND или последовательность команд, приводящая к состоянию SEND, должна быть дополнена так, чтобы можно было указать предпочтительный MKT для исходящих (current_key) и/или входящих (rnext_key) сегментов.

Может оказаться полезной смена активного исходящего MKT (current_key) даже при отсутствии переданных данных, что можно выполнить путем отправки буфера нулевого размера или использования интерфейса без передачи (non-send, например, опции сокета в Unix) в зависимости от реализации.

Полезно также указывать полученные в недавнем сегменте значения KeyID и RnextKeyID. Хотя таких значений может быть множество, их быстрая смена не предполагается, поэтому любой свежей выборки должно быть достаточно.

>> TCP RECEIVE или последовательность команд, приводящая к RECEIVE, должна быть дополнена так, чтобы значения KeyID и RNextKeyID из недавно принятого сегмента были доступны пользователю по отдельному каналу (например, как дополнительный параметр RECEIVE или через вызов STATUS).

7.2. Состояния и переходы TCP

TCP включает состояния LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT, CLOSED.

>> MKT можно связать с любым состоянием TCP.

7.3. Сегменты TCP

TCP включает сегменты управления (с флагом SYN, FIN, RST) и данных (без флагов SYN, FIN, RST), при этом сегменты управления могут включать данные (например, SYN).

>> Все сегменты TCP должны сравниваться с набором MKT на предмет соответствия идентификаторам соединений TCP.

>> Сегменты TCP, не прошедшие проверку TCP-AO, должны отбрасываться без уведомления отправителя.

>> Реализация TCP-AO должна разрешать настройку поведения сегментов с TCP-AO, не соответствующих MKT. Исходно по умолчанию такие соединения следует просто воспринимать. Если такое поведение нежелательно, можно включить MKT для сопоставления с такими соединениями или соединение может указывать обязательность TCP-AO. Кроме того, можно изменить конфигурацию для отбрасывания сегментов с опцией TCP-AO, не соответствующих MKT.

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

Обработка TCP-AO выполняется между интерфейсами TCP и IP. Для входящих сегментов это выполняется после проверки контрольной суммы TCP, для исходящих — перед расчетом контрольной суммы TCP.

Отметим, что использование TCP-AO на соединении не согласуется с TCP. Получатель отвечает за определение необходимости TCP-AO другими средствами (например, по отдельному каналу или с помощью протокола управления ключами) и исполнение этого требования.

7.4. Передача сегментов TCP

Приведенная ниже процедура описывает изменения TCP для поддержки вставки опции TCP-AO при отправке сегмента.

>> TCP-AO должна обрабатываться последней в заголовке TCP исходящего сегмента, поскольку в расчете MAC могут учитываться другие опции TCP.

1. Определение параметров соединения для сегмента.

   1. Если в сегменте имеется флаг SYN, этот сегмент является первым в соединении. Определяется ключ MKT для сегмента на основе пары сокетов этого сегмента.

      1. If Если нет соответствующего MKT, опция TCP-AO опускается и сегмент передается без нее.

      2. При наличии соответствующего MKT устанавливаются нужные параметры на уровне соединения (раздел 4). Переход к п. 2.

   2. Если в сегменте нет флага SYN, проверяется использование TCP-AO для соединения и выбирается MKT в соответствии со значением current_key из параметров соединения (раздел 4). Переход к п. 2.

2. Использование заданных на уровне соединения параметров.

   1. В заголовок TCP добавляется опция TCP-AO путем вставки полей Length и KeyID, соответствующих MKT, указанному current_key (используется current_key для MKT SendID как TCP-AO KeyID). Должным образом обновляется размер заголовка TCP.

   2. Определяется SND.SNE в соответствии с параграфом 6.2.

   3. Определяется подходящий ключ трафика (указанный current_key в соответствии с параграфом 6.1 и, возможно, кэшированный в TCB). Т. е. применяется send_SYN_traffic_key для сегментов SYN и send_other_traffic_key для других сегментов.

   4. Определяется RNextKeyID в соответствии с указателем rnext_key и помещается в поле TCP-AO RNextKeyID (используется rnext_key для MKT RecvID как TCP-AO RNextKeyID¹¹) в соответствии с параграфом 6.1.

   5. Рассчитывается MAC с использованием MKT (и кэшированного ключа трафика) и данных из сегмента, как указано в параграфе 5.1.

   6. Вставляется значение MAC в поле TCP-AO MAC.

   7. Выполняется передача сегмента.

7.5. Прием сегментов TCP

Приведенная ниже процедура описывает изменения TCP для поддержки опции TCP-AO при получении сегмента.

>> Опция TCP-AO должна обрабатываться первой во входящем сегменте TCP, поскольку расчет MAC может включать другие опции TCP, которые могут измениться при обработке. Это также защищает другие опции TCP от влияния обманных сегментов или измененных данных заголовка.

>> Проверки TCP-AO должны выполняться для всех входящих сегментов SYN, чтобы избежать SYN без требуемой опции TCP-AO. Для других сегментов можно использовать кэшированные в TCB сведения о применении TCP-AO.

1. Отыскиваются параметры соединения для сегмента.

   1. Если в сегменте установлен флаг SYN, этот сегмент является первым в соединении. Отыскивается ключ MKT для этого сегмента по паре сокетов и TCP-AO KeyID, соответствующему идентификатору соединения TCP и RecvID для MKT.

      1. При отсутствии нужного MKT опция TCP-AO удаляется из сегмента и обработка продолжается. Это предполагает, что соединения, не соответствующие MKT воспринимаются без уведомления, как указано в параграфе 7.3.

      2. При наличии соответствующего MKT устанавливаются нужные параметры соединения (раздел 4). Переход к п. 2.

2. Использование заданных на уровне соединения параметров.

   1. Проверка соответствия TCP-AO Length размеру, указанному MKT.

      1. Если размеры отличаются, сегмент отбрасывается без уведомления. Событие записывается в журнал и/или выдается предупреждение в соответствии с параграфом 7.3.

   2. Определяется RCV.SNE для сегмента в соответствии с параграфом 6.2.

   3. Определяется ключ трафика для сегмента из MKT в соответствии с параграфом 5.1 (вероятно кэшированный в TCB). Т. е. применяется receive_SYN_traffic_key для сегментов SYN и receive_other_traffic_key — для остальных сегментов.

   4. Рассчитывается MAC для сегмента с использованием MKT (и выведенного из него ключа трафика) и частей сегмента, как указано в параграфе 5.1.

      1. Если полученное значение отличается от поля TCP-AO MAC, сегмент отбрасывается без уведомления. Событие записывается в журнал и/или выдается предупреждение в соответствии с параграфом 7.3.

   5. Сравнивается полученное значение RNextKeyID с активным исходящим KeyID (current_key MKT SendID).

      1. При совпадении дополнительные действия не нужны.

      2. Если значения различаются, проверяется готовность RNextKeyID MKT.

         1. Если MKT, соответствующий паре сокетов и RNextKeyID недоступен, дальнейших действий не требуется (RNextKeyID принимающей стороны должен соответствовать SendID в MKT).

         2. Если доступен MKT, соответствующий паре сегментов и RNextKeyID:

            1. Для current_key устанавливается RNextKeyID MKT.

   6. Выполняется обработка сегмента TCP.

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

Дополнительное снижение издержек, связанных с проверкой MAC, может обеспечиваться алгоритмами MAC, например, за счет алгоритма расчета, добавляющего фиксированное значение в начало учитываемой части, и соответствующего алгоритма, проверяющего наличие этого значения в самом начале процесса. Такая оптимизация будет включаться в спецификацию алгоритма MAC и ее не нужно радавать явно в TCP-AO. Отметим, что KeyID не может применяться для проверки соединения как такового, поскольку это значение не предполагается случайным.

7.6. Влияние на размер заголовка TCP

TCP-AO с изначально заданными 96-битовыми MAC добавляет в заголовок TCP 16 байтов [RFC5926], что на 2 байта меньше размера опции TCP MD5 (18 байтов).

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

4-битовое поле Data Offset в заголовке TCP требует, чтобы заголовок и опции занимали не более 60 байтов (15 слов по 32 бита) от начала заголовка, фиксированная часть которого составляет 20-байтов. Это оставляет для опций 40 байтов заголовка, из которых 15 предполагаются занятыми в текущих реализациях (см. ниже), и доступно лишь 25 байтов. TCP-AO занимает 16 байтов, оставляя 9 для дополнительных опций SYN (в от реализации до 2 байтов может тратиться на заполнение).

• Разрешение SACK (2 байта) [RFC2018][RFC3517].

• Временные метки (10 байтов) [RFC1323].

• Масштабирование окна (3 байта) [RFC1323].

• Максимальный размер сегмента (4 байта) [RFC793]¹².

После SYN в текущих реализациях TCP предполагаются опции:

• SACK (10 байтов) [RFC2018][RFC3517] (18 байтов для D-SACK [RFC2883]);

• Временные метки (10 байтов) [RFC1323].

TCP-AO продолжает занимать 16 байтов в сегментах без SYN, оставляя 24 байта для других опций, из которых 10 байтов занимают временные метки. В результате остаются 14 байтов, из которых десять служат для одного блока SACK. При использовании 2 блоков SACK (например, для обработки D-SACK), требуется сокращать TCP-AO MAC для размещения дополнительного блока SACK (т. е. для 18 байтов опции D-SACK, являющейся вариантом SACK) [RFC2883].Отметим, что D-SACK не поддерживается с TCP MD5 при наличии временных меток, поскольку размер MAC в TCP MD5 фиксирован и не оставляет достаточно места.

Хотя пространство опций TCP ограничено, предполагается, что TCP-AO согласуется с желанием аутентифицировать TCP на уровне соединений с целями, для которых была предназначена опция TCP MD5.

7.7. Обработка сброса соединений

TCP-AO позволяет обмен сегментами сброса TCP (RST) при условии, что обе стороны находятся в допустимом (valid) состоянии соединения. После установки такого состояния в случае перезагрузки одной из сторон TCP-AO не позволяет механизму TCP RST сбросить (очистить) прежнее состояние на другой стороне. Это обусловлено тем, что перезагруженная сторона теряет состояние соединения и, как следствие, ключи трафика.

Важно, чтобы реализации были способны обнаруживать избыточные соединения TCP в такой конфигурации и устранять их при необходимости для экономии памяти [Ba10]. Для защиты от накопления таких состояний имеется ряд рекомендаций, приведенных ниже

>> В соединениях с TCP-AO следует применять также TCP keepalive [RFC1122].

Использование пакетов поддержки TCP (keepalive) гарантирует, что соединения с утраченными ключами будут прерываться за конечное время. Аналогичный эффект может быть обеспечен на уровне приложения, например, с помощью BGP keepalive [RFC4271]. Любой тип сообщений keepalive обеспечит очистку состояния TCP в таких случаях. Другой вариант, разрешающий принимать RST без аутентификации, имеет существенную уязвимость, которую можно предотвратить с помощью TCP-AO.

Сообщения keepalive обеспечивают сброс соединений при перезагрузке, но это может негативно влиять на некоторые протоколы. В частности, BGP плохо реагирует на такие разрывы соединений, даже при использовании BGP keepalive, поэтому была разработана специальная процедура «аккуратной перезагрузки» (graceful restart) [RFC4724], которая была затем расширена для BGP с MPLS [RFC4781]. В соответствии с этим:

>> соединениям BGP следует требовать поддержки graceful restart при использовании TCP-AO.

Понятно, что такая поддержка возможна (желателина) не во всех случаях, поэтому предлагается иной вариант.

>> При перезапуске BGP без поддержки graceful restart, но с использованием TCP-AO, обеим сторонам соединения следует сохранять ключи трафика и восстанавливать их после перезагрузки, а также следует ограничивать влияние такого сохранения и восстановления ключей на производительность.

7.8. Обработка ICMP

Протокол TCP можно атаковать по основному каналу с помощью сегментов TCP или по отдельному (out of band) с использованием ICMP. Пакеты ICMP невозможно защитить с помощью механизмов TCP-AO, однако прямую защиту сигнализации ICMP не может обеспечить как TCP-AO, так и IPsec. В TCP-AO даются конкретные рекомендации по обработке некоторых пакетов ICMP в дополнение к требуемым IPsec; это обусловлено работой TCP-AO в контексте соединения TCP.

IPsec включает рекомендации по отбрасыванию ICMP в определенном контексте и требования аутентификации конечных точек [RFC4301]. Имеются и другие механизмы, снижающие влияние атак ICMP на счет дополнительной проверки содержимого ICMP и смены влияния некоторых сообщений на основе состояния TCP, но они не обеспечивают уровень проверки подлинности ICMP, который TCP-AO предоставляет TCP [Go10]. В результате рекомендуется сдержанный подход к восприятию сообщений ICMP, как описано в [Go10].

>> Реализация TCP-AO по умолчанию должна игнорировать входящие сообщения ICMPv4 типа 3 (адресат недоступен) с кодами 2-4 (протокол недоступен, порт недоступен, требуется фрагментация — «жесткие ошибки»), и ICMPv6 типа 1 (адресат недоступен) с кодом 1 (административно запрещено) и 4 (порт недоступен), предназначенные для соединений в синхронизированных состояниях (ESTABLISHED, FIN-WAIT-1, FIN- WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), которые соответствуют MKT.

>> Реализации TCP-AO следует разрешать настройку игнорирования таких ICMP на уровне соединения.

Реализации TCP-AO следует поддерживать меры защиты от сообщений ICMP о слишком больших пакетах (packet too big), некоторые примеры которых рассматриваются в [Go10].

>> Реализации следует разрешать запись событий игнорирования ICMP в системный журнал.

Это влияет лишь на сообщения ICMP, которые в настоящее время требуют жестких мер (hard error), связанных с разрывом соединения TCP [RFC1122]. Рекомендации аналогичны мерам обработки таких сообщений в IPsec, как указано в [RFC4301].

8. Отмена TCP MD5 и взаимодействие с устаревшими системами

TCP-AO отменяет опцию TCP MD5.

>> Реализации TCP, поддерживающие TCP MD5, должны поддерживать TCP-AO.

Системы, реализующие лишь TCP MD5, считаются устаревшими, и их следует обновлять по мере возможностей. Для поддержки взаимодействия с такими системами до их обновления следует выполнять приведенные ниже требования.

>> TCP MD5 следует поддерживать там, где нужно взаимодействие с устаревшими системами.

>> Система, поддерживающая TCP-AO и TCP MD5, должна применять TCP-AO для соединений, если это поддерживает партнер. В противном случае можно использовать TCP MD5.

>> Реализации TCP недопустимо применять TCP-AO и TCP MD5 на одном соединении TCP, но можно поддерживать одновременно TCP-AO и TCP MD5 для разных соединений (в частности, для работы с устаревшими системами TCP MD5).

Значение Kind явно указывает в сегментах использование TCP-AO или TCP MD5 на конкретном соединении TCP.

Можно расширить MKT для поддержки TCP MD5, но использование MKT не описано в RFC 2385.

Для соединения можно требовать TCP-AO или TCP MD5, но не то и другое сразу. Если конечная точка настроена требовать TCP MD5 на соединении, она должна включать эту опцию во все исходящие сегменты и проверять ее во входящих [RFC2385]. Требования TCP MD5 запрещают использование обеих опций на одном соединении, например, для передачи решения о выборе другой стороне.

9. Взаимодействие с промежуточными устройствами

TCP-AO может взаимодействовать с промежуточными устройствами в зависимости от их поведения [RFC3234]. Некоторые промежуточные устройства меняют опции TCP (такие как TCP-AO) напрямую или информацию, включенную в расчет TCP-AO MAC. Это может мешать работе TCP-AO, особенно при изменении данных, защищенных опцией.

9.1. Взаимодействие с устройствами без NAT/NAPT

TCP-AO поддерживает промежуточные устройства, не меняющие адреса IP или порты в сегментах. Такие устройства могут менять опции TCP и в этом случае нужно настраивать TCP-AO на игнорирование всех опций при расчете MAC для проходящих через такие устройства соединений.

Отметим, что игнорирование опций TCP может снижать уровень защиты, т. е. опции TCP можно будет незаметно изменить в пути, что открывает путь для атак. В зависимости от изменений (например, временных меток) может быть снижена эффективность TCP или нарушена корректность операций (например, при изменении размера окна). Эти уязвимости присущи лишь соединениям TCP, где для TCP-AO задано игнорирование опций TCP.

9.2. Взаимодействие с устройствами NAT/NAPT

TCP-AO не может естественным путем работать через устройства NAT/NAPT (Network Address Port Translation — трансляция адресов и портов), меняющие адреса IP и/или номера портов. Предполагается, что для прохождения через такие устройства могут потребоваться варианты имеющихся механизмов прохождения NAT/NAPT, например, инкапсуляция сегментов с защитой TCP-AO в другие транспортные сегменты (например, UDP), как принятов в IPsec [RFC2663][RFC3947]. Такие варианты могут быть приспособлены для работы с TCP-AO или можно использовать IPsec с прохождением через NAT вместо применения TCP-AO [RFC3947].

Другой вариант приспособления к NAT расширяет TCP-AO независимо от данной спецификации [To10].

10. Оценка выполнения требований

TCP-AO соответствует всем текущим требованиям к пересмотру TCP MD5, как показано ниже [Ed07].

1. Защищаемые элементы.

   Решению, заменяющему TCP MD5, следует защищать (проверять подлинность) перечисленные ниже элементы (выполнено, см. параграф 5.1).

   1. Псевдозаголовок IP, включая IPv4 и IPv6.

      Отметим, что частичное покрытие не допускается, поскольку адреса IP определяют соединение. Если адреса можно согласовать через NAT/NAPT, отправитель может рассчитать MAC по полученным адресам, в остальных случаях требуется организация туннеля, как отмечено в параграфе 9.2.

   2. Заголовок TCP.

      Отметим, что частичное покрытие не допускается, поскольку порты определяют соединение. Если порты можно согласовать через NAT/NAPT, отправитель может рассчитать MAC по полученным номера, в остальных случаях требуется организация туннеля, как отмечено в параграфе 9.2.

   3. Опции TCP.

      TCP-AO разрешает исключать опции TCP из расчета MAC для работы через промежуточные устройства, меняющие опции (но не TCP-AO), как описано в раздел 9.

   4. Данные TCP.

2. Требования к структуре опции.

   Решению по замене TCP MD5 следует выполнять приведенные ниже требования к структуре опции (выполнено, см. параграф 5.1).

   1. Конфиденциальность.

      Опции следует не раскрывать без нужды информацию о механизме TCP-AO. Обеспечиваемая этим дополнительная защита может не иметь большого значения, зато помогает сократить размер опции. TCP-AO раскрывает лишь идентификаторы MKT, MAC и размер опции в линии. Отметим, что укороченные MAC можно скрыть, указав в размере опции полное значение и задав меньший размер MAC (это эквивалентно другому алгоритму MAC и указывается в MKT). См. параграф 2.2.

   2. Разрешение на уровне соединения.

      Опцию не следует требовать в каждом соединении, ее следует разрешать на уровне соединения.

      Это поддерживается за счет возможности установки MKT, соответствующих лишь некоторым соединениям. Для соединений, не соответствующих ни одному MKT, применять TCP-AO не требуется. Кроме того, входящие сегменты с TCP-AO не отбрасываются исключительно по присутствию опции, не соответствующей ни одному MKT.

   3. Требование использовать опцию.

      Опции следует предоставлять возможность указания как требуемой для данного соединения. Это поддерживается за счет возможности установки набора MKT, который может соответствовать лишь некоторым соединениям. Опция TCP-AO требуется для соединений, соответствующих любому из MKT TCP-AO.

   4. Стандартный анализ.

      Опции следует быть легко анализируемой, т. е. не требовать дополнительного разбора и соответствовать стандартному формату опций RFC 793 (поддерживается, см. параграф 2.2).

   5. Совместимость с Large Window и SACK.

      Опции следует обеспечивать совместимость с опциями Large Window и SACK (поддерживается, см. параграф 7.6). Размер опции рассчитан на совместное использование с Large Window и SACK. См. также параграф 1.3, где указано, что TCP-AO на 2 байта короче опции TCP MD5 в принятом по умолчанию случае с 96-битовым MAC.

3. Криптографические требования.

   Решению по замене TCP MD5 следует выполнять приведенные ниже криптографические требования.

   1. Базовые значения по умолчанию.

      Опции следует по умолчанию использовать значения, требуемые от всех реализаций. TCP-AO использует по умолчанию обязательный алгоритм, заданный в [RFC5926], как указано в параграфе 5.1.

   2. Качественные алгоритмы.

      Опции следует использовать алгоритмы, принятые сообществом безопасности, которые считаются достаточно защищенными. Следует избегать применения нестандартных или неопубликованных алгоритмов. TCP-AO использует MAC, указанные в [RFC5926], где заданы также функции KDF. Входные строки KDF соответствуют типовым [RFC5926].

   3. Гибкость выбора алгоритмов.

      Опции следует поддерживать отличающиеся от принятых по умолчанию алгоритмы для обеспечения гибкости с течением времени. TCP-AO позволяет применять любой желаемый алгоритм с учетом ограничений на размер опций TCP, как отмечено в параграфе 2.2. Использование набора MKT позволяет в разных соединениях выбирать свои алгоритмы как для MAC, так и для KDF.

   4. Независимая от порядка доставки обработка.

      Опции следует поддерживать обработку без зависимости от порядка доставки, т. е. следует разрешать обработку сегментов TCP, принятых с нарушением порядка, без переупорядочения. Это избавляет от необходимости восстанавливать порядок до обработки и влияния нарушения порядка доставки сегментов на опцию (поддерживается, см. параграфы 7.3 — 7.5). Отметим, что требуется предварительная обработка до TCP, поскольку сегмент TCP нельзя отбросить лишь на основании состояния соединения и проверки выхода за пределы окна. Многие из таких сегментов, хотя и отбрасываются, заставляют хост ответить повтором последнего действительного ACK [RFC793]. В описании вывода номеров SNE на стороне получателя приведена демонстрация алгоритма, позволяющего избежать восстановления порядка (параграф 6.2).

   5. Смена параметра защиты требует замены ключей.

      Опции следует требовать смены MKT при изменении любого из параметров защиты. Это избавляет от необходимости координации состояние опции в процессе работы соединения, что типично для опций TCP. Это также позволяет разрешить реализации bump in the stack, не объединенные с реализацией TCP на конечной точке. Параметры меняются лишь при переходе на новый ключ MKT (раздел 3).

4. Требования к ключам.

   Решению по замене TCP MD5 следует поддерживать установку ключей вручную, а также внешние системы автоматизированного управления ключами (например, протокол или иной механизм). Отметим, что TCP-AO не задает систему управления MKT.

   1. Смена ключей в соединении.

      Опции следует поддерживать смену ключей в соединении для устранения влияния на долгосрочные соединения. Это поддерживается за счет применения идентификаторов и множества MKT (раздел 3).

   2. Эффективная смена ключей.

      Опции следует поддерживать смену ключей в соединении без чрезмерного расхода вычислительных ресурсов. В частности, следует избегать необходимости проверки множества ключей для данного сегмента. Это поддерживается на основе применения KeyID (параграф 6.1).

   3. Автоматизированная и ручная установка ключей.

      Опции следует поддерживать ручную и автоматизированную установку ключей. Использование MKT позволяет задавать ключи вручную или автоматизированно (раздел 3). Это свойство усилено генерацией уникальных ключей для соединения, что позволяет применять заданные вручную MKT с автоматически генерируемыми ключами трафика (параграф 5.2).

   4. Независимость от управления ключами.

      Опции не следует предполагать или требовать наличия системы управления ключами. Это обеспечивается за счет поддержки множества MKT (раздел 3).

5. Ожидаемые ограничения.

   Решению по замене TCP MD5 следует поддерживать типовые методы защиты.

   1. Сокрытие отказов при проверке.

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

   2. Не более одной опции на сегмент.

      В сегменте разрешена лишь 1 опция аутентификации (поддерживается в требованиях, см. параграф 2.2).

   3. Проверять на выходе все или ничего.

      Сегменты из соединения TCP должны проверяться все или не проверяться совсем (поддерживается, см. параграф 7.4).

   4. На входе проверять все.

      Входящие сегменты в соединении TCP всегда проверяются на предмет наличия и пригодности опции аутентификации (поддерживается, см. параграф 7.5).

   5. Отсутствие взаимодействия с TCP MD5.

      Использование этой опции для данного соединения не должно препятствовать применению TCP MD5 на других соединениях, например, при работе с устаревшими системами (поддерживается, см. раздел 8).

   6. «Жесткое» отбрасывание ICMP.

      Опции следует разрешать отбрасывать некоторые сообщения ICMP, особенно типа 3 (destination unreachable) с кодами 2-4 (transport protocol unreachable, port unreachable, fragmentation needed and IP DF field set), говорящие об отказе конечной точки от взаимодействия (поддерживается, см. параграф 7.8).

   7. Поддержка семантики соединений TCP, где лишь пара сокетов связывает ассоциацию TCP и все параметры ее защиты (поддерживается, см. разделы 3 и 9).

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

Применение TCP-AO будет влиять на производительность, подобно TCP MD5 или IPsec. Соединения, для которых известно применение TCP-AO, могут быть атакованы сегментами с недействительными MAC. Атакующему нужно знать лишь идентификатор соединения ID и значение TCP-AO Length для воздействия на возможности хоста обрабатывать трафик. Это похоже на уязвимость IPsec к атакам в пути, где адреса IP и SPI будут видны. В IPsec доступно все пространство SPI (32 бита), тогда как протоколы маршрутизации обычно могут произвольно менять лишь порт-источник (16 битов, но на деле имеется меньшее число случайных битов [La10]). В результате атакующему, не находящемуся на пути доставки проще передавать фиктивные сегменты TCP-AO, которые могут потребовать усилий по обработке на приемной стороне. Однако следует отметить, что между маршрутизаторами Internet произвольными могут быть значения обоих портов (задаются по отдельному каналу), что будет представлять примерно такой же уровень защиты от подставных пакетов, как произвольные SPI.

TCP-AO, подобно TCP MD5, может запрещать сбров без организации соединения. Такой сброс обычно связан с отказом одного из партнеров, ответом на попытку соединения или передачей данных в устаревшее (stale) соединение. В любом случае восстанавливающая конечная точку может не иметь нужных ключей соединения (например, потеряны при отказе). Это может приводить к тайм-аутам, а не к ускоренному восстановлению после отказа. Рекомендации по снижению таких воздействий приведены в параграфе 7.7.

В TCP-AO нет возможности быстрого отклонения, например, при получении SYN-ACK без ожидаемого TCP-AO с быстым сбросом или разрывом соединения. Обычной реакцией TCP будет повтор или тайм-аут, которого следует ожидать, когда предусмотренный получатель не способен поддержать требуемый вариант TCP. Отказ от этого не предусмотрен, поскольку он открыл бы атакующим путь к прерыванию попыток соединения путем отправки фиктивных SYN-ACK без TCP-AO.

Опция TCP-AO нацелена на обеспечение защиты, подобной IPsec, но не для замены IPsec или IKE на более отказоустойчивую защиту или изощренное управления защитой. Опция TCP-AO предназначена для защиты от атак самого протокола TCP, которую не могут предоставить такие протоколы как TLS, sBGP/soBGP и др. Подобно IPsec, TCP-AO не решает до конца вопросы защиты от ICMP-атак на TCP, но ограничивает влияние ICMP, как отмечено в параграфе 7.8.

TCP-AO включает идентификаторы соединений TCP (пара сокетов) в расчет MAC. Это предохраняет обновременные соединения, использующие один MKT (по любой причине) от атак с перекрестным трафиком, когда сегменты с одной парой сокетов перенаправляются на другую пару. При использовании несколькими соединениями одного MKT, полезно знать, что сегменты для одной пары не могут (умышленно или ненароком) изменены при передаче и аутентифицированы для другой пары. Это требование задает дополнительную нагрузку, связанную с уникальностью MKT в конечной системе и, возможно, среди разных конечных систем. Хотя вероятность атак невелика, защита, обеспечиваемая включением принятого идентификатора гарантирует его учет в MAC и не усложняет чрезмерно расчет MAC и управление MKT.

Использование любого алгоритма защиты может сделать возможными DoS-атаки¹³ на CPU, когда злоумышленник передает случайные фиктивные сегменты, на обработку которых получатель затрачивает много ресурсов CPU. В IPsec ослабление таких атак обеспечивается использованием больших полей SPI (Security Parameter Index -индекс параметров защиты) и порядковых номеров для частичной проверки сегментов до того, как будут затрачены ресурсы CPU на проверку ICV (Integrity Check Value — код контроля целостности). В TCP-AO пара сокетов выполняет большинство функций SPI, а порядковый номер IPsec, служащий для предотвращения replay-атак, не требуется по причине наличия порядкового номера TCP, служащего для восстановления порядка принятых сегментов (при условии, что порядковый номер не зациклен, что обеспечивается добавлением в TCP-AO номеров SNE, описанный в параграфе 6.2). TCP уже защищает себя от повторов аутентичных сегментов данных и управления (например, биты SYN, FIN, ACK), но даже аутентичные повторные пакеты могут влиять на контроль перегрузок в TCP [Sa99]. TCP-AO не защищает контроль перегрузок TCP от последней формы атак из-за громоздкости применения порядковых номеров окна защиты в дополнение к обычным номерам TCP. При желательности такой защиты следует применять IPsec.

Кроме того, бесполезно проверять порядковый номер TCP до выполнения расчетов TCP-AO, поскольку сегменты за пределами окна все равно вызывают корректные действия протокола TCP (например, повтор ACK) [RFC793]. Также бесполезно добавлять отдельное поле порядкового номера в TCP-AO, поскольку это может привести к изменению поведения TCP даже для корректных сегментов.

12. Взаимодействие с IANA

Опции аутентификации TCP (TCP-AO) в IANA был назначен номер 29.

Этот документ не задает новых пространств имен.

Задание алгоритмов MAC и KDF для TCP-AO вынесено в отдельный документ [RFC5926].

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

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

[RFC793] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, September 1981.

[RFC1122] Braden, R., Ed., «Requirements for Internet Hosts — Communication Layers», STD 3, RFC 1122, October 1989.

[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, «TCP Selective Acknowledgment Options», RFC 2018, October 1996.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC2385] Heffernan, A., «Protection of BGP Sessions via the TCP MD5 Signature Option», RFC 2385, August 1998.

[RFC2403] Madson, C. and R. Glenn, «The Use of HMAC-MD5-96 within ESP and AH», RFC 2403, November 1998.

[RFC2460] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 2460¹⁴, December 1998.

[RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, «An Extension to the Selective Acknowledgement (SACK) Option for TCP», RFC 2883, July 2000.

[RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, «A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP», RFC 3517¹⁵, April 2003.

[RFC4306] Kaufman, C., Ed., «Internet Key Exchange (IKEv2) Protocol», RFC 4306, December 2005.

[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, «Graceful Restart Mechanism for BGP», RFC 4724, January 2007.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, January 2006.

[RFC4781] Rekhter, Y. and R. Aggarwal, «Graceful Restart Mechanism for BGP with MPLS», RFC 4781, January 2007.

[RFC5926] Lebovitz, G. and E. Rescorla, «Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)», RFC 5926, June 2010.

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

[Ba10] Bashyam, M., Jethanandani, M., and A. Ramaiah «Clarification of sender behaviour in persist condition», Work in Progress¹⁶, January 2010.

[Bo07] Bonica, R., Weis, B., Viswanathan, S., Lange, A., and O. Wheeler, «Authentication for TCP-based Routing and Management Protocols», Work in Progress, February 2007.

[Bo09] Borman, D., «TCP Options and MSS», Work in Progress, July 2009¹⁷.

[Ed07] Eddy, W., Ed., Bellovin, S., Touch, J., and R. Bonica, «Problem Statement and Requirements for a TCP Authentication Option», Work in Progress, July 2007.

[Go10] Gont, F., «ICMP Attacks against TCP», Work in Progress¹⁸, March 2010.

[La10] Larsen, M. and F. Gont, «Transport Protocol Port Randomization Recommendations», Work in Progress¹⁹, April 2010.

[Le09] Lepinski, M. and S. Kent, «An Infrastructure to Support Secure Internet Routing», Work in Progress²⁰, October 2009.

[RFC1321] Rivest, R., «The MD5 Message-Digest Algorithm», RFC 1321, April 1992.

[RFC1323] Jacobson, V., Braden, R., and D. Borman, «TCP Extensions for High Performance», RFC 1323, May 1992.

[RFC1948] Bellovin, S., «Defending Against Sequence Number Attacks», RFC 1948, May 1996.

[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, «HMAC: Keyed-Hashing for Message Authentication», RFC 2104, February 1997.

[RFC2663] Srisuresh, P. and M. Holdrege, «IP Network Address Translator (NAT) Terminology and Considerations», RFC 2663, August 1999.

[RFC3234] Carpenter, B. and S. Brim, «Middleboxes: Taxonomy and Issues», RFC 3234, February 2002.

[RFC3562] Leech, M., «Key Management Considerations for the TCP MD5 Signature Option», RFC 3562, July 2003.

[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, «Negotiation of NAT-Traversal in the IKE», RFC 3947, January 2005.

[RFC4301] Kent, S. and K. Seo, «Security Architecture for the Internet Protocol», RFC 4301, December 2005.

[RFC4808] Bellovin, S., «Key Change Strategies for TCP-MD5», RFC 4808, March 2007.

[RFC4953] Touch, J., «Defending TCP Against Spoofing Attacks», RFC 4953, July 2007.

[RFC5246] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.2», RFC 5246²¹, August 2008.

[Sa99] Savage, S., N. Cardwell, D. Wetherall, T. Anderson, «TCP Congestion Control with a Misbehaving Receiver», ACM Computer Communications Review, V29, N5, pp71-78, October 1999.

[SDNS88] Secure Data Network Systems, «Security Protocol 4 (SP4)», Specification SDN.401, Revision 1.2, July 12, 1988.

[To07] Touch, J. and A. Mankin, «The TCP Simple Authentication Option», Work in Progress, July 2007.

[To10] Touch, J., «A TCP Authentication Option NAT Extension», Work in Progress²², January 2010.

[Wa05] Wang, X., H. Yu, «How to break MD5 and other hash functions», Proc. IACR Eurocrypt 2005, Denmark, pp.19-35.

[We05] Weis, B., Appanna, C., McGrew, D., and A. Ramaiah, «TCP Message Authentication Code Option», Work in Progress, December 2005.

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

Этот документ был совместно разработан командой TCP Authentication Design (tcp-auth-dt), членами которой были (по алфавиту): Mark Allman, Steve Bellovin, Ron Bonica, Wes Eddy, Lars Eggert, Charlie Kaufman, Andrew Lange, Allison Mankin, Sandy Murphy, Joe Touch, Sriram Viswanathan, Brian Weis, Magnus Westerlund. Текст документа взят из предложения Joe Touch и Allison Mankin [To07] (изначально июнь 2006 г.), которое было задумано как контрпредложение к пересмотру TCP MD5, предложенному в документе Ron Bonica, Brian Weis, Sriran Viswanathan, Andrew Lange, and Owen Wheeler [Bo07] (исходно сентябрь 2005 г.) и в документе Brian Weis [We05].

Russ Housley предложив управление кортежами первичных ключей на уровне L4 и пркладном. Steve Bellovin был за поле KeyID. Eric Rescorla предложил использовать начальные порядковые номера TCP ISN при расчете ключей трафика и SNE для предотвращения replay-атак, а Brian Weis расширил расчет путем включения идентификатора соединения полностью и предоставил детали расчета ключей трафика. Mark Allman, Wes Eddy, Lars Eggert, Ted Faber, Russ Housley, Gregory Lebovitz, Tim Polk, Eric Rescorla, Joe Touch и Brian Weis разработали механизм координации первичных ключей.

Alfred Hoenes, Charlie Kaufman, Adam Langley и многие другие члены рабочей группы TCPM WG предоставили существенные отклики для этого документа.

Документ изначально был подготовлен с использованием шаблона 2-Word-v2.0.template.dot.

Адреса авторов

Joe Touch

USC/ISI

4676 Admiralty Way

Marina del Rey, CA 90292-6695

U.S.A.

Phone: +1 (310) 448-9151

EMail: touch@isi.edu

URL: http://www.isi.edu/touch

Allison Mankin

Johns Hopkins Univ.

Baltimore, MD

U.S.A.

Phone: 1 301 728 7199

EMail: mankin@psg.com

URL: http://www.psg.com/~mankin/

Ronald P. Bonica

Juniper Networks

2251 Corporate Park Drive

Herndon, VA 20171

U.S.A.

EMail: rbonica@juniper.net

Перевод на русский язык

Николай Малых

nmalykh@protokols.ru