Internet Research Task Force (IRTF)                         M. Behringer
Request for Comments: 7575                                   M. Pritikin
Category: Informational                                     S. Bjarnason
ISSN: 2070-1721                                                 A. Clemm
                                                           Cisco Systems
                                                            B. Carpenter
                                                       Univ. of Auckland
                                                                S. Jiang
                                            Huawei Technologies Co., Ltd
                                                            L. Ciavaglia
                                                          Alcatel Lucent
                                                               June 2015

Autonomic Networking: Definitions and Design Goals

Самоуправляющиеся сети — определения и цели разработки

PDF

Аннотация

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

В этом документе определён язык описания и очерчены цели (а также отмечено то, что не является целью) автоматических функций. Высокоуровневая эталонная модель иллюстрирует взаимодействие функциональных элементов в самоуправляемой сети (Autonomic Network или AN). Документ является результатом работы исследовательской группы IRTF Network Management.

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

Документ не содержит какой-либо спецификации (Internet Standards Track) и публикуется с информационными целями.

Документ является результатом работы IRTF (Internet Research Task Force). IRTF публикует результаты исследований и разработок, связанных с Internet. Эти результаты не всегда пригодны для развёртывания. Данный документ RFC представляет согласованный взгляд исследовательской группы Network Management в составе IRTF. Документы, одобренные для публикации IRSG, не претендуют на статус стандартов Internet (см. раздел 2 в RFC 5741).

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

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

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

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно.

1. Введение в самоуправляющиеся сети

Самоуправляющиеся (автоматические) системы впервые были описаны в манифесте IBM [Kephart] в 2001 году. Фундаментальная концепция включает устранение внешних систем из контура управления и замыкание этого контура в самой автоматической системе с целью обеспечения ей возможностей самоуправления, включая самонастройку, самовосстановление и самозащиту.

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

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

Самоуправляющиеся функции можно определить двумя способами:

• на уровне узла, когда узлы взаимодействуют между собой образуя контуры обратной связи;

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

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

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

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

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

Самоуправляемые вычисления (Autonomic Computing) в целом и самоуправляющиеся сети в частности много лет служат предметом академического изучения. Имеется много литературы, в том числе несколько полезных обзорных статей (например, [Samaan], [Movahedi], [Dobson]). В этом документе основное внимание уделено концепциям и определениям, которые представляются достаточно зрелыми и способны стать основой для совместимых спецификаций в ближайшем будущем. В частности, такие спецификации должны будут сосуществовать с традиционными методами настройки и управления сетями, а не просто реализовать самоуправляющиеся системы со всеми требуемыми свойствами.

Имеется важное различие между «автоматизированным» и «автоматическим». Автоматизированными называют предопределённые процессы, такие как сценарии. Термин «автоматический» применяется в контексте самоуправления и включает контуры обратной связи между элементами, а также «северный» интерфейс к централизованным элементам (см. определения в следующем параграфе). Обычно автоматизированный процесс работает в данной среде, но при изменении среды его приходится изменять. Самоуправляющийся процесс может адаптироваться к изменению среды.

В этом документе даны определения и указаны цели проектирования для AN в рамках IETF и IRTF. Документ представляет согласованный взгляд исследовательской группы IRTF Network Management (NMRG).

2. Определения

Autonomic — самоуправляющийся, автоматический

Самоуправление (самонастройка, самозащита, самовосстановление, самооптимизация), с возможностью высокоуровневого вмешательства со стороны централизованного элемента через Intent (намерение, см. ниже). Функции самоуправления приспосабливаются к изменяющейся среде.

Automatic — автоматизированный¹

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

Intent — намерение, цель

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

Autonomic Domain — домен самоуправления

Группа (набор) автоматических (самоуправляющихся) узлов с общей целью (Intent).

Autonomic Function — функция самоуправления

Свойство или функция, которое не требует настройки и может получить все требуемые сведения путём самообучения, обнаружения или получения цели (Intent).

Autonomic Service Agent — агент самоуправляемой службы

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

Autonomic Node — узел с самоуправлением

Узел, реализующий исключительно автоматические функции. Такой узел не требует (!) настройки конфигурации (отметим, что настройка конфигурации может применяться для переопределения автоматической функции, см. параграф 3.2). Autonomic Node может работать на любом уровне сетевого стека. Примерами являются маршрутизаторы, коммутаторы, ПК, менеджеры вызовов (call manager) и т. п.

Autonomic Network — сеть с самоуправлением

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

3. Цели

В этом разделе описаны высокоуровневые цели Autonomic Networking, не зависящие от конкретного решения.

3.1. Самоуправление

Исходная цель проектирования самоуправляющихся систем, описанная в [Kephart] применима и к сетям с самоуправлением (Autonomic Network). Главное целью является самоуправление, которое включает несколько «само» свойств.

• Самонастройка. Функции не требуют настройки администратором или системой управления. Они сами настраивают себя на основе самообучения, обнаружения и целей (Intent). Обнаружение (Discovery) служит используемым по умолчанию способом получения требуемой для работы информации.

• Самовосстановление. Автоматические функции адаптируют себя в соответствии с изменением среды и автоматически восстанавливаются при возникновении проблем.

• Самооптимизация. Самоуправляемые функции автоматически определяют способы оптимизации своего поведения для набора чётко заданных целей.

• Самозащита. Самоуправляемые функции автоматически защищают себя от возможных атак.

Самоуправляемой можно назвать почти любую сеть, если понятие «само» достаточно широко. Например, чётко заданная система программно-определяемых сетей (Software-Defined Networking или SDN), включая контроллеры, может быть описана в целом как самоуправляемая (автоматическая), если контроллер обеспечивает администратору интерфейс, имеющий перечисленные выше свойства (высокий уровень, сеть в целом и т. д.).

В рамках работ IETF и IRTF свойства «само» определяются на уровне узла. Цель проекта заключается в том, чтобы сделать функции узлов самоуправляемыми (минимизировать зависимость от систем управления и контроллеров, а также от участия человека). Самоуправляемым функциям на узле может потребоваться обмен информацией с другими узлами для достижения поставленных целей.

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

3.2. Сосуществование с традиционным управлением

В ближайшем будущем узлы и сети с самоуправлением будут скорее исключением, автоматические функции будут определяться поэтапно. Поэтому нужно принимать во внимание сосуществование с другими парадигмами сетевого управления, такими как управление с консоли, SNMP, SDN (с соответствующими API), NETCONF (Network Configuration Protocol) и т. п. Это требует разрешения конфликтов a) принятого по умолчанию автоматического поведения и Intent с b) другими методами. Проблема решается с помощью приоритизации. В общем случае автоматические механизмы определяют поведение на уровне сети, тогда как альтернативные методы обычно работают по узлам. Концепция управления на уровне узла имеет более высокий приоритет по сравнению с другими автоматическими методами. Это соответствует современным примерам автоматических функций, например, в маршрутизации (статический) маршрут имеет преимущество перед алгоритмом маршрутизации. Вкратце можно сказать:

• низший приоритет — принятое по умолчанию автоматическое поведение:

• средний приоритет — автоматические намерения (Intent);

• высший приоритет — концепции управления сетью для конкретного узла, такие как управление с консоли, SNMP, SDN, NETCONF и т. п. (приоритеты этих концепций выходят за рамки документа).

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

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

3.3. Защита по умолчанию

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

Надёжное, криптографически проверяемое отождествление в домене является фундаментом автоматических сетей (Autonomic Networking). Его можно применять для защиты всех коммуникаций без традиционной настройки, например, заранее известных общих ключей. Дополнительную информацию можно найти в документе «Making The Internet Secure By Default» [Behringer].

Автоматические функции должны поддерживать способность адаптировать своё поведение в зависимости от домена или узла, с которым происходит взаимодействие.

3.4. Децентрализация и распределённость

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

В некоторых случаях для современной практики предпочтительней иметь централизованное хранилище информации, например, базу данных о пользователях на сервере проверки подлинности и полномочий, а также учёта (Authentication, Authorization, Accounting или AAA). Автоматической сети следует иметь возможность распределять такие базы данных и по меньшей мере следует предпринимать такие усилия. В зависимости от ситуации распределение может быть простой репликацией или включать более сложные взаимодействия и организацию.

3.5. Упрощение северного интерфейса автоматических узлов

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

Поэтому узлам в Autonomic Network требуется «северный» (northbound) интерфейс. Однако такой интерфейс следует делать как можно более простым и высокоуровневым.

3.6. Абстракции

Администратор или автоматическая система управления взаимодействует с AN на высоком уровне абстракций. Намерение (Intent) определяется на уровне абстракции, который много выше типичных параметров конфигурации. Например, намерением может быть «оптимизация сети по потреблению электроэнергии». Intent недопустимо использовать для передачи низкоуровневых команд или концепций, поскольку они относятся к другому уровню абстракции. Например, администратору не следует раскрывать версию протокола IP, используемого в сети. Со стороны отчётов и обратной связи сеть с самоуправлением абстрагирует информацию и предоставляет сообщения высокого уровня, такие как «связь между узлами x и y не работает» (возможно с указанием конкретного канала, если их несколько).

3.7. Автоматические отчёты.

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

Уровни абстракции, предоставляемые через Intent, должны поддерживаться и для функций отчётов, чтобы пользователи имели представление об эффективности их намерений (Intent). Например, для оценки эффективности сети в части намерения «оптимизировать с точки зрения потребляемой энергии» следует предоставлять агрегированные сведения о числе портов, которые удалось отключить, и соответствующей экономии энергии с соблюдением проверки текущего уровня обслуживания.

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

3.8. Общая инфраструктура автоматических сетей

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

Целью работы группы Autonomic Networking в IETF является не просто создание автоматических функций, но и определение общей инфраструктуры, которую автоматические функции могут использовать. Эта инфраструктура AN может включать общие функции управления и администрирования, обнаружения служб, согласования, распространения намерений, самослежения (мониторинга), диагностики и т. п. Нужен также общий подход к определению и распространению намерений (Intent).

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

3.9. Независимость функции и уровня

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

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

Для автоматических сетей AN требуется общий уровень управления, чтобы автоматические узлы могли взаимодействовать. В обычных сетях IP протокол IP является связующим уровнем, который объединяет все элементы, и автоматические функции в контексте этой схемы также следует реализовать на уровне IP. Это относится к протоколам обнаружения соседей и другим функциям автоматической плоскости управления (Autonomic Control Plane).

3.10. Поддержка полного жизненного цикла

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

Состояние жизненного цикла автоматического узла отражается в модели состояния. Поведение автоматической функции может различаться в разных состояниях развёртывания.

4. Что не относится к целям разработки

В этом разделе отмечены элементы, которые явно не являются целями разработки для автоматических сетей в IETF и IRTF. Они отмечены для предотвращения недопонимания в части общих намерений, часто отмечаемого в опасениях администраторов и архитекторов сетей.

4.1. Исключение операторов

В параграфе 3.1 сказано: «Цель проекта заключается в том, чтобы сделать функции узлов самоуправляемыми (минимизировать зависимость от систем управления и контроллеров, а также от участия человека)». Однако полное исключение операторов не является целью разработки. Проблема, на решение которой нацелены сети с самоуправлением (Autonomic Networking), состоит в подверженной ошибкам и сложно расширяемой модели индивидуальной настройки элементов сети, традиционно выполняемой с помощью команд, но сегодня в основном использующей сценарии и базы данных конфигурации. Это не означает исключения опытных операторов, которые все равно нужны для надзора, управления правилами, диагностики, реагирования на обращения в службу поддержки и т. п. Основной задачей является снижение нагрузки на операторов для выполнения рутинной работы и привлечение их к решению задач более высокого уровня (им следует быть похожими на врачей, а не санитаров).

4.2. Исключение аварийных исправлений

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

4.3. Исключение центрального управления

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

5. Эталонная модель самоуправления

Автоматическая сеть AN состоит из автоматических узлов (Autonomic Node), которые взаимодействуют между собой через автоматическую плоскость управления (Autonomic Control Plane), которая обеспечивает отказоустойчивые и защищённые коммуникации. Автоматическая плоскость управления является самоорганизующейся и автоматической.

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

• Агенты автоматических служб (Autonomic Service Agent) реализуют автоматическое поведение конкретных служб или функций.

• Самопознание (Self-knowledge) — автоматический узел знает свои свойства и возможности.

• Изучение (обнаружение) сети (Network Knowledge (Discovery)) может потребоваться автоматическим агентам служб для выполнения таких задач как обнаружение служб.

• Контуры обратной связи (Feedback Loop) обеспечивают взаимодействие узла с внешними элементами управления.

• Автоматический пользовательский агент (Autonomic User Agent) предоставляет интерфейс (front-end) для внешних пользователей (администраторы или программы управления), через который можно получать отчёты. и выполнять мониторинг AN.

+------------------------------------------------------------+
|                      +------------+                        |
|                      |  Контуры   |                        |
|                      |обрат. связи|                        |
|                      +------------+                        |
|                            ^                               |
|            Автоматический пользовательский агент           |
|                            V                               |
| +-----------+        +------------+        +------------+  |
| | Само-     |        |   Агенты   |        | Изучение   |  |
| | познание  |<------>| автоматич. |<------>|(обнаружен.)|  |
| |           |        |   служб    |        |   сети     |  |
| +-----------+        +------------+        +------------+  |
|                            ^                     ^         |
|                            |                     |         |
|                            V                     V         |
|------------------------------------------------------------|
|           Автоматическая плоскость управления              |
|------------------------------------------------------------|
|                 Стандартные функции ОС                     |
+------------------------------------------------------------+

Рисунок 1. Эталонная модель для узла с самоуправлением.

На момент завершения этого документа работа над эталонной моделью ещё продолжалась, см. [Reference-Model].

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

В этом документе приведены определения и цели проектирования автоматических сетей (Autonomic Networking). В рамках разработки решений потребуется полный анализ угроз с учётом возможных атак как внутри сети, так и извне.

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

[ACP] Behringer, M., Bjarnason, S., BL, B., and T. Eckert, «An Autonomic Control Plane», Work in Progress², draft-behringer-anima-autonomic-control-plane-02, March 2015.

[Behringer] Behringer, M., Pritikin, M., and S. Bjarnason, «Making The Internet Secure By Default», Work in Progress, draft-behringer-default-secure-00, January 2014.

[BOOTSTRAP] Pritikin, M., Behringer, M., and S. Bjarnason, «Bootstrapping Key Infrastructures», Work in Progress, draft-pritikin-anima-bootstrapping-keyinfra-01, February 2015.

[Dobson] Dobson, S., Denazis, S., Fernandez, A., Gaiti, D., Gelenbe, E., Massacci, F., Nixon, P., Saffre, F., Schmidt, N., and F. Zambonelli, «A survey of autonomic communications», ACM Transactions on Autonomous and Adaptive Systems (TAAS), Volume 1, Issue 2, Pages 223-259, DOI 10.1145/1186778.1186782, December 2006.

[GANA] ETSI, «Autonomic network engineering for the self-managing Future Internet (AFI); Generic Autonomic Network Architecture (An Architectural Reference Model for Autonomic Networking, Cognitive Networking and Self-Management)», ETSI GS AFI 002, April 2013, <http://www.etsi.org/deliver/etsi_gs/AFI/001_099/002/01.01.01_60/gs_afi002v010101p.pdf>.

[Kephart] Kephart, J. and D. Chess, «The Vision of Autonomic Computing», IEEE Computer, vol. 36, no. 1, pp. 41-50, DOI 10.1109/MC.2003.1160055, January 2003.

[Movahedi] Movahedi, Z., Ayari, M., Langar, R., and G. Pujolle, «A Survey of Autonomic Network Architectures and Evaluation Criteria», IEEE Communications Surveys & Tutorials, Volume 14, Issue 2, Pages 464-490, DOI 10.1109/SURV.2011.042711.00078, 2012.

[Reference-Model] Behringer, M., Ed., Carpenter, B., Eckert, T., Ciavaglia, L., and B. Liu, «A Reference Model for Autonomic Networking», Work in Progress³, draft-behringer-anima-reference-model-02, June 2015.

[RFC7576] Jiang, S., Carpenter, B., and M. Behringer, «General Gap Analysis for Autonomic Networking», RFC 7576, DOI 10.17487/RFC7576, June 2015, <http://www.rfc-editor.org/info/rfc7576>.

[Samaan] Samaan, N. and A. Karmouch, «Towards Autonomic Network Management: an Analysis of Current and Future Research Directions», IEEE Communications Surveys and Tutorials, Volume 11, Issue 3, Page(s) 22-36, DOI 10.1109/SURV.2009.090303, 2009.

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

Большая часть работы по AN выполнена в рамках крупного проекта Cisco Systems, где участвовали (в алфавитном порядке) Ignas Bagdonas, Parag Bhide, Balaji BL, Toerless Eckert, Yves Hertoghs, Bruno Klauser.

Спасибо за вклад в документ Dimitri Papadimitriou, Rene Struik, Kostas Pentikousis, Dave Oran, Diego Lopez Garcia.

Рабочая группа ETSI AFI <http://portal.etsi.org/afi> определила похожую схему для Autonomic Networking в документе «General Autonomic Network Architecture» [GANA]. Многие из концепций данного документа можно сопоставить со схемой GANA, но это выходит за рамки этого документа. Отдельная благодарность Ranganai Chaparadza за комментарии и помощь при создании документа.

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

Michael H. Behringer

Cisco Systems

Building D, 45 Allee des Ormes

Mougins 06250

France

EMail: mbehring@cisco.com

Max Pritikin

Cisco Systems

5330 Airport Blvd

Boulder, CO 80301

United States

EMail: pritikin@cisco.com

Steinthor Bjarnason

Cisco Systems

Mail Stop LYS01/5

Philip Pedersens vei 1

LYSAKER, AKERSHUS 1366

Norway

EMail: sbjarnas@cisco.com

Alexander Clemm

Cisco Systems

170 West Tasman Drive

San Jose, CA 95134-1706

United States

EMail: alex@cisco.com

Brian Carpenter

Department of Computer Science

University of Auckland

PB 92019

Auckland 1142

New Zealand

EMail: brian.e.carpenter@gmail.com

Sheng Jiang

Huawei Technologies Co., Ltd

Q14, Huawei Campus

No.156 Beiqing Road

Hai-Dian District, Beijing 100095

China

EMail: jiangsheng@huawei.com

Laurent Ciavaglia

Alcatel Lucent

Route de Villejust

Nozay 91620

France

EMail: laurent.ciavaglia@alcatel-lucent.com

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                         M. Belshe
Request for Comments: 7540                                         BitGo
Category: Standards Track                                        R. Peon
ISSN: 2070-1721                                              Google, Inc
                                                         M. Thomson, Ed.
                                                                 Mozilla
                                                                May 2015

Протокол передачи гипертекста версии 2 (HTTP/2)

Hypertext Transfer Protocol Version 2 (HTTP/2)

PDF

Аннотация

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

Данная спецификация дополняет, но не отменяет синтаксис сообщений HTTP/1.1. Существующая семантика HTTP сохранена без изменений.

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

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

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

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

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

Авторские права (Copyright (c) 2015) принадлежат 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. Введение

Протокол передачи гипертекста HTTP чрезвычайно успешен. Однако способы использования нижележащего транспорта в HTTP/1.1 (раздел 6 в [RFC7230]) имеют некоторые характеристики, оказывающие отрицательное влияние на производительность современных приложений.

В частности, HTTP/1.0 разрешает в каждый момент времени только один незавершенный запрос на соединение TCP. В HTTP/1.1 добавлен конвейер для запросов (pipelining), но это лишь частично решает проблему одновременных запросов и продолжает вызывать блокировку (head-of-line). Следовательно, клиенты HTTP/1.0 и HTTP/1.1, которым нужно сделать множество запросов, вынуждены организовывать множественные соединения с сервером, чтобы обеспечить их параллельную обработку и снизить задержку.

Кроме того, поля заголовков HTTP зачастую многословны и содержат повторы, что ведет к бессмысленному росту сетевого трафика, приводящему к быстрому заполнению начального окна насыщения TCP [TCP]. Это может приводить к избыточным задержкам при отправке множества запросов через новое соединение TCP.

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

Новый протокол более «дружелюбен» к сети за счет использования меньшего числа соединений TCP по сравнению с HTTP/1.x. Это снижает конкуренцию с другими потоками и долгосрочными соединениями, что, в свою очередь, повышает эффективность использования пропускной способности сети.

Наконец, HTTP/2 обеспечивает возможность более эффективной обработки сообщений за счет применения двоичного кадрирования сообщений.

2. Обзор протокола HTTP/2

HTTP/2 обеспечивает оптимизированный транспорт для семантики HTTP. HTTP/2 поддерживает все основные свойства HTTP/1.1, но его целью является повышение эффективности несколькими способами.

Базовым блоком протокола HTTP/2 является кадр (frame, см. параграф 4.1). каждый тип кадров служит для своих целей. Например, кадры HEADERS и DATA служат базой для запросов и откликов HTTP (параграф 8.1), а другие кадры типа SETTINGS, WINDOW_UPDATE и PUSH_PROMISE служат для поддержки иных функций HTTP/2.

Мультиплексирование запросов обеспечивается связыванием каждого обмена HTTP «запрос-отклик» со своим потоком (stream, см. раздел 5). Потоки в значительной мере не зависимы один от другого, поэтому блокировка или приостановка того или иного запроса или отклика не препятствует работе других потоков.

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

HTTP/2 добавляет новый режим взаимодействия, в котором сервер может «выталкивать» (push) отклики для клиента (параграф 8.2). Выталкивание позволяет серверу по своему усмотрению передать данные, которые сервер считает требующимися для клиента, что требует некого компромисса между загрузкой сети и снижением задержки. Сервер делает это, синтезируя запрос, который он передает, как кадр PUSH_PROMISE. После этого сервер имеет возможность отправить отклик на синтезированный запрос в отдельном потоке.

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

2.1. Организация документа

Спецификация HTTP/2 разделена на 4 части:

• начало работы HTTP/2 (раздел 3) — инициирование соединений HTTP/2;

• уровни кадров (раздел 4) и потоков (раздел 5), описывающие структуру кадров HTTP/2 и формирование из них мультиплексируемых потоков;

• определения кадров (раздел 6) и ошибок (раздел 7) подробно описывают типы кадров и ошибок, применяемые в HTTP/2;

• отображения HTTP (раздел 8) и дополнительные требования (раздел 9) описывают выражение семантики HTTP с использованием кадров и потоков.

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

2.2. Соглашения и термины

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

Все числовые значения используют сетевой порядок байтов и предполагаются беззнаковыми, пока явно не указано иное. Литералы приводятся в десятичном или шестнадцатеричном формате. Шестнадцатеричные значения указываются префиксом 0x.

Ниже приведены определения основных терминов, используемых в документе.

client — клиент

Конечная точка, выступающая инициатором соединения HTTP/2. Клиенты передают запросы HTTP и получают отклики HTTP.

connection — соединение

Соединение транспортного уровня между двумя конечными точками.

connection error — ошибка соединения

Ошибка, воздействующая на соединение HTTP/2 в целом.

endpoint — конечная точка

Клиент или сервер в данном соединении.

frame — кадр

Наименьший коммуникационный блок в соединении HTTP/2, состоящий из заголовка и последовательности октетов переменного размера в зависимости от типа кадра.

peer — партнер

Конечная точка. При обсуждении конкретной конечной точки термин «партнер» используется для конечной точки на другой стороне соединения.

receiver — получатель

Конечная точка, получающая кадры.

sender — отправитель

Конечная точка, передающая кадры.

server — сервер

Конечная точка, воспринимающая соединение HTTP/2. Сервер получает запросы HTTP и передает отклики HTTP.

stream — поток

Двухсторонний поток кадров в соединении HTTP/2.

stream error — ошибка потока

Ошибка отдельного потока HTTP/2.

Термины gateway (шлюз), intermediary (посредник), proxy (прокси) и tunnel (туннель) определены в параграфе 2.3 [RFC7230]. Посредники в разные моменты могут выступать как клиент или как сервер.

Термин payload body (тело данных) определен в параграфе 3.3 [RFC7230].

3. Начало работы HTTP/2

Соединение HTTP/2 представляет собой протокол прикладного уровня, работающий через соединение TCP ([TCP]). Клиент является инициатором соединения TCP.

HTTP/2 использует те же схемы http и https для URI, которые применяются в HTTP/1.1. По умолчанию в HTTP/2 используются те же номера портов — 80 для http URI и 443 для https URI. В результате от реализации, обрабатывающей запрос для URI целевого ресурса типа http://example.org/foo или https://example.com/bar, требуется сначала определить, поддерживает ли восходящий сервер (партнер, с которым клиент желает организовать непосредственное соединение) HTTP/2.

Способы определения поддержки HTTP/2 различаются для http и https URI. Обнаружение поддержки для http URI описано в параграфе 3.2, для https URI — в параграфе 3.3.

3.1. Идентификация версии HTTP/2

Определенный в этом документе протокол имеет два идентификатора.

• Строка h2 указывает протокол, где HTTP/2 использует защиту транспортного уровня (TLS⁴) [TLS12]. Этот идентификатор применяется в поле согласования TLS прикладного уровня (ALPN⁵) [TLS-ALPN] и в любом другом месте, где указывается HTTP/2 «поверх» TLS.

  Строка h2 включается в идентификатор протокола ALPN в форме последовательности из 2 октетов 0x68, 0x32.

• Строка h2c указывает протокол, где HTTP/2 работает на основе открытого TCP. Этот идентификатор применяется в поле заголовка HTTP/1.1 Upgrade и в любых других местах, где указывается HTTP/2 на базе TCP.

  Строка h2c зарезервирована из пространства ALPN, на протокол не использует TLS.

Согласование h2 или h2c предполагает использование транспорта, защиты, кадрирования и семантики сообщений, описанных в этом документе.

3.2. Начало работы HTTP/2 для http URI

Клиент, делающий запрос для http URI, не зная о поддержке HTTP/2 на следующем интервале, использует механизм HTTP Upgrade (параграф 6.7 d [RFC7230]). Это выполняется путем отправки запроса HTTP/1.1, включающего поле заголовка Upgrade с маркером h2c. Такой запрос HTTP/1.1 должен включать в точности одно поле заголовка HTTP2-Settings (параграф 3.2.1) .

Например,

     GET / HTTP/1.1
     Host: server.example.com
     Connection: Upgrade, HTTP2-Settings
     Upgrade: h2c
     HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>

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

Если важна одновременная передача начального и последующих запросов, можно использовать запрос OPTIONS для перехода на HTTP/2 за счет задержки в один период кругового обхода.

Не поддерживающий HTTP/2 сервер может передать в ответ на запрос отклик без поля Upgrade в заголовке.

     HTTP/1.1 200 OK
     Content-Length: 243
     Content-Type: text/html
     ...

Сервер должен игнорировать маркер h2 в поле заголовка Upgrade. Присутствие маркера h2 предполагает работу HTTP/2 через TLS и для этого случая согласование происходит иначе (см. параграф 3.3).

Сервер, поддерживающий HTTP/2, воспринимает Upgrade с откликом 101 (переключение протокола). После пустой строки, завершающей отклик 101, сервер может начать передачу кадров HTTP/2. Эти кадры должны включать отклик на запрос, вызвавший переключение протокола (Upgrade).

Например,

     HTTP/1.1 101 Switching Protocols
     Connection: Upgrade
     Upgrade: h2c

     [ HTTP/2 connection ...

Первым кадром HTTP/2 от сервера должен быть серверный префикс соединения (параграф 3.5), состоящий из кадра SETTINGS (параграф 6.5). При получении отклика 101 клиент должен передать префикс соединения (параграф 3.5), включающий кадр SETTINGS.

Запросу HTTP/1.1, переданному до Upgrade, присваивается идентификатор потока 1 (параграф 5.1.1) с принятыми по умолчанию значениями (параграф 5.3.5). Поток 1 является неявно «полузакрытым» соединением от клиента к серверу (параграф 5.1), поскольку запрос завершается, как HTTP/1.1. После начала работы соединения HTTP/2 поток 1 используется для отклика.

3.2.1. Поле заголовка HTTP2-Settings

Запросы для перехода от HTTP/1.1 к HTTP/2 (обновления) должны включать в точности одно поле заголовка HTTP2-Settings. Это поле зависит от контекста и включает параметры, управляющие соединением HTTP/2 в предположении, что сервер примет запрос на переход.

     HTTP2-Settings    = token68

Серверу недопустимо переводить соединение на HTTP/2, если данное поле отсутствует в заголовке или задано в нескольких экземплярах. Серверам недопустимо передавать это поле в заголовке.

Содержимое поля заголовка HTTP2-Settings — это информационные элементы (payload) кадра SETTINGS (параграф 6.5), представленные в форме строки base64url (т. е., URL и безопасное для имен файлов представление Base64, описанное в разделе 5 [RFC4648] без трейлерных символов =). Создание ABNF [RFC5234] для token68 определено в параграфе 2.1 [RFC7235].

Поскольку обновление предназначено лишь для следующего незамедлительно соединения, передающий поле HTTP2-Settings клиент должен также передать HTTP2-Settings в качестве опции соединения в поле заголовка Connection для предотвращения пересылки (см. параграф 6.1 в [RFC7230]).

Сервер декодирует и интерпретирует эти значения, как и остальные значения в кадре SETTINGS. Явное подтверждение этих установок не требуется (параграф 6.5.3), поскольку отклик 101 служит неявным подтверждением. Предоставление этих значений в запросе Upgrade дает пользователю возможность обеспечить параметры до получения от сервера каких-либо кадров.

3.3. Начало работы HTTP/2 для https URI

Клиент, делающий запрос для https URI, использует TLS [TLS12] с расширением ALPN⁶ [TLS-ALPN].

В HTTP/2 на основе TLS используется идентификатор протокола h2. Идентификатор h2c недопустимо передавать от клиентов или выбирать на сервере — этот идентификатор описывает протокол, не использующий TLS.

После завершения согласования TLS клиент и сервер должны передать префикс соединения (параграф 3.5).

3.4. Начало работы с заранее известным HTTP/2

Клиент может получить информацию о поддержке конкретным сервером HTTP/2 иными способами. Например, в [ALT-SVC] описан механизм анонсирования такой поддержки.

Клиент должен отправить префикс соединения (параграф 3.5) и сразу после этого может передавать такому серверу кадры HTTP/2. Сервер может идентифицировать такие соединения по полученным префиксам. Это оказывает влияние лишь на организацию соединений HTTP/2 через открытые (не шифрованные) соединения TCP, а реализации, поддерживающие HTTP/2 через TLS должны использовать согласование протокола в TLS [TLS-ALPN].

Аналогично, сервер должен передать префикс соединения (параграф 3.5).

Без дополнительной информации известная заранее поддержка сервером HTTP/2 вовсе не означает, что он будет поддерживать такие соединения и впредь. Например, конфигурация сервера может измениться, на разных экземплярах кластеризованного сервера конфигурации могут отличаться, могут также измениться условия в сети.

3.5. Префикс соединения HTTP/2

В HTTP/2 от каждой из оконечных точек требуется отправить префикс соединения в качестве финального подтверждения использования протокола для организации начальных установок соединения HTTP/2. Клиент и сервер передают разные префиксы соединения.

Клиентский префикс начинается с последовательности из 24 октетов с шестнадцатеричным представлением

     0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a

Таким образом, префикс соединения начинается со строки «PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n⁷». За этой последовательностью должен быть передан кадр SETTINGS (параграф 6.5), который может быть пустым. Клиент передает свой префикс соединения непосредственно по получении отклика 101 (Switching Protocols), указывающего успешную смену протокола, или в качестве первых октетов данных приложения в соединении TLS. Если соединение HTTP/2 начинается до получения информации о поддержке сервером этого протокола, клиентский префикс соединения передается сразу после организации соединения.

Примечание. Клиентский префикс соединения выбран так, что большая часть серверов HTTP/1.1 и HTTP/1.0, а также посредников не будет пытаться обработать последующие кадры. Однако это не решает вопросов, поднятых в [TALKING].

Серверный префикс соединения состоит из (возможно пустого) кадра SETTINGS (параграф 6.5), который должен быть первым кадром от сервера в соединении HTTP/2.

Кадры SETTINGS, полученные от партнера, как часть префикса соединения, должны подтверждаться (см. параграф 6.5.3) после отправки префикса соединения.

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

Клиенты и серверы должны трактовать неприемлемый префикс соединения, как ошибку соединения (параграф 5.4.1) типа PROTOCOL_ERROR. В этом случае кадр GOAWAY (параграф 6.8) может быть опущен, поскольку неприемлемый префикс показывает, что партнер не использует HTTP/2.

4. Кадры HTTP

После того, как соединение HTTP/2 организовано, его оконечные точки начинают обмен кадрами.

4.1. Формат кадра

Все кадры начинаются с фиксированного 9-октетного заголовка, за которым следуют информационные поля переменного размера.

+-----------------------------------------------+
|                 Length (24)                   |
+---------------+---------------+---------------+
|   Type (8)    |   Flags (8)   |
+-+-------------+---------------+-------------------------------+
|R|                 Stream Identifier (31)                      |
+=+=============================================================+
|                   Frame Payload (0...)                      ...
+---------------------------------------------------------------+

Рисунок 1. Схема кадра

Поля фиксированного заголовка определены ниже.

Length

Размер информационных полей кадра (frame payload), выраженный 24-битовым целым числом без знака. Кадры размером более 2¹⁴ (16384) недопустимо передавать, если получатель не установил большее значение для параметра SETTINGS_MAX_FRAME_SIZE.

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

Type

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

Flags

8-битовое поле, зарезервированное для логических флагов, определяемых типом кадра.

Семантика флагов указывается типом кадра. Не определенные семантикой соответствующего типа флаги должны игнорироваться, а при передаче для них должно устанавливаться значение 0 (0x0).

R

1-битовое резервное поле. Назначение этого бита не определено, он должен оставаться сброшенным (0x0) при передаче и должен игнорироваться на приемной стороне.

Stream Identifier

Идентификатор потока (см. параграф 5.1.1), указанный 31-битовым целым числом без знака. Значение 0x0 зарезервировано для кадров, связанных с соединением в целом, а не с отдельным потоком.

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

4.2. Размер кадра

Размер информационных полей в кадре ограничен анонсированным получателем значением SETTINGS_MAX_FRAME_SIZE, которое может находиться в диапазоне от 2¹⁴ (16 384) до 2²⁴-1 (16 777 215) октетов, включительно.

Все реализации должны обеспечивать возможность приема и минимальной обработки кадров размером до 2¹⁴ октетов плюс 9-октетный заголовок кадра (параграф 4.1). При описании размера кадров фиксированный заголовок кадра не учитывается.

Примечание. Для некоторых типов кадров, например, PING (параграф 6.7), имеются дополнительные ограничения на размер.

Конечная точка должна передать код ошибки FRAME_SIZE_ERROR, если размер полученного кадра превосходит SETTINGS_MAX_FRAME_SIZE, любой из пределов, заданных типом кадра, или слишком мал, чтобы вместить обязательные для кадра данные. Ошибка размера для кадра, который меняет состояние всего соединения, должна трактоваться, как ошибка соединения (параграф 5.4.1) — это включает все кадры, содержащие блок заголовка (параграф 4.3) (HEADERS, PUSH_PROMISE и CONTINUATION), SETTINGS, а также все кадры с идентификатором потока 0. Конечные точки не обязаны использовать все доступное пространство кадра и применение кадров с размером меньше разрешенного максимума позволяет ускорить реакцию на них. Большие кадры могут вызывать задержки передачи чувствительных к задержкам кадров (типа RST_STREAM, WINDOW_UPDATE или PRIORITY), блокировка которых может негативно влиять на производительность.

4.3. Сжатие и декомпрессия заголовка

Как и в HTTP/1, поле заголовка HTTP/представляет собой имя и одно или несколько связанных с ним значений. Поля заголовков используются в сообщениях с запросами и откликами HTTP, а также в операциях выталкивания (push) на серверах (см. параграф 8.2).

Список заголовка может включать множество полей или не включать ни одного. При передаче через соединение список преобразуется (serialize) в блок заголовка с использованием сжатия заголовков HTTP [COMPRESSION]. Последовательный блок заголовка затем может быть разделен на множество последовательностей октетов, называемых фрагментами блока заголовка, которые передаются в информационных блоках (payload) кадров HEADERS (параграф 6.2), PUSH_PROMISE (параграф 6.6) или CONTINUATION (параграф 6.10).

Для поля заголовка Cookie [COOKIE] используется особая трактовка с помощью отображения HTTP (см. параграф 8.1.2.5).

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

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

• один кадр HEADERS или PUSH_PROMISE с установленным флагом END_HEADERS;

• кадр HEADERS или PUSH_PROMISE со сброшенным флагом END_HEADERS и одним или множеством кадров CONTINUATION, из которых в последнем установлен флаг END_HEADERS.

Сжатие заголовка выполняется с учетом состояния. Для соединения в целом используется один контекст сжатия и один контекст декомпрессии. Ошибки при декодировании блока заголовка должны трактоваться, как ошибки соединения (параграф 5.4.1) типа COMPRESSION_ERROR.

Каждый блок заголовка обрабатывается, как дискретный элемент. Блоки заголовков должны передаваться в виде непрерывной последовательности кадров без чередования с кадрами других типов или из других потоков. Последний кадр в последовательности HEADERS или CONTINUATION имеет установленный флаг END_HEADERS. Последний кадр в последовательности PUSH_PROMISE или CONTINUATION имеет установленный флаг END_HEADERS. Это обеспечивает логическую эквивалентность блока заголовка одному кадру.

Фрагменты блока заголовка могут передаваться только в кадрах HEADERS, PUSH_PROMISE или CONTINUATION, поскольку эти кадры переносят данные, которые могут изменять контекст сжатия на приемной стороне. Конечной точке, принимающей кадры HEADERS, PUSH_PROMISE или CONTINUATION требуется собрать блоки заголовков и выполнить декомпрессию даже если кадры будут отброшены. Получатель должен разорвать соединение с возвратом ошибки (параграф 5.4.1) типа COMPRESSION_ERROR, если он не смог выполнить декомпрессию блока заголовка.

5. Потоки и мультиплексирование

«Поток» представляет собой независимую, двунаправленную последовательность кадров, передаваемых между клиентом и сервером через соединение HTTP/2. Потоки имеют несколько важных характеристик:

• в одном соединении HTTP/2 может быть открыто множество одновременных потоков и любая из конечных точек может чередовать кадры разных потоков;

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

• любая из конечных точек может закрыть поток;

• порядок передачи кадров в потоке имеет значение и получатель обрабатывает кадры в порядке их приема; в частности, кадры HEADERS и DATA значимы в семантическом смысле;

• потоки обозначаются целочисленными идентификаторами, которые выделяются создавшей поток конечной точкой.

5.1. Состояния потока

Жизненный цикл потока показан на рисунке 2.

                         +--------+
                 send PP |        | recv PP
                ,--------|  idle  |--------.
               /         |        |         \
              v          +--------+          v
       +----------+          |           +----------+
       |          |          | send H /  |          |
,------| reserved |          | recv H    | reserved |------.
|      | (local)  |          |           | (remote) |      |
|      +----------+          v           +----------+      |
|          |             +--------+             |          |
|          |     recv ES |        | send ES     |          |
|   send H |     ,-------|  open  |-------.     | recv H   |
|          |    /        |        |        \    |          |
|          v   v         +--------+         v   v          |
|      +----------+          |           +----------+      |
|      |   half   |          |           |   half   |      |
|      |  closed  |          | send R /  |  closed  |      |
|      | (remote) |          | recv R    | (local)  |      |
|      +----------+          |           +----------+      |
|           |                |                 |           |
|           | send ES /      |       recv ES / |           |
|           | send R /       v        send R / |           |
|           | recv R     +--------+   recv R   |           |
| send R /  `----------->|        |<-----------'  send R / |
| recv R                 | closed |               recv R   |
`----------------------->|        |<----------------------'
                         +--------+

   send:   конечная точка передает этот кадр
   recv:   конечная точка принимает этот кадр

   H:  кадр HEADERS (с подразумеваемыми CONTINUATION)
   PP: кадр PUSH_PROMISE (с подразумеваемыми CONTINUATION)
   ES: флаг END_STREAM 
   R:  кадр RST_STREAM

Рисунок 2. Состояния потока

На рисунке показаны переходы состояний потока, а также кадры и флаги, воздействующие только на эти переходы. В этом смысле кадры CONTINUATION не оказывают влияния на смену состояний — эффективно они являются частью кадра HEADERS или PUSH_PROMISE, за которым данный кадр следует.

В плане смены состояний потоков флаг END_STREAM обрабатывается как отдельное от переносящего этот флаг кадра событие — кадр HEADERS с установленным флагом END_STREAM может вызвать две смены состояния.

Каждая из конечных точек имеет свое представление о состоянии потока и эти представления могут различаться, когда часть кадров еще находится в пути. Конечные точки не координируют создание потоков и каждая из точек создает потоки по своему усмотрению. Негативные последствия рассогласования состояний ограничиваются возможностью получения кадров в течение некоторого времени после «закрытия» потока с помощью RST_STREAM.

Состояния потоков описаны ниже.

idle — бездействие

Все потоки начинаются в состоянии idle.

Ниже перечислены переходы, которые приемлемы из этого состояния.

• Отправка или получение кадра HEADERS вызывает переход потока в состояние open. Идентификатор потока выбирается в соответствии с параграфом 5.1.1. Этот же кадр HEADERS может вызвать незамедлительный переход потока в состояние half-closed.
• Отправка кадра PUSH_PROMISE в другой поток резервирует бездействующий поток для использования в будущем. Состояние потока меняется на reserved (local).
• Получение кадра PUSH_PROMISE из другого потока резервирует бездействующий поток для использования в будущем. Состояние потока меняется на reserved (remote).
• Отметим, что кадр PUSH_PROMISE не передается через бездействующий поток, но указывает вновь резервируемый поток в поле Promised Stream ID.

Прием кадра, отличного от HEADERS или PRIORITY, через поток в состоянии должна трактоваться, как ошибка соединения (параграф 5.4.1) типа PROTOCOL_ERROR.

reserved (local) — локально зарезервирован

Поток в состоянии reserved (local) — этот поток, который был зарезервирован отправкой кадра PUSH_PROMISE. Кадр PUSH_PROMISE резервирует бездействующий (idle) поток, путем связывания с открытым потоком, который был инициирован удаленным партнером (см. параграф 8.2).

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

• Конечная точка передает кадр HEADERS который переводит поток в состояние half-closed (remote).
• Любая из конечных точек может передать кадр RST_STREAM, переводящий поток в состояние closed с отменой имеющегося резервирования.

В этом состоянии конечной точке недопустимо передавать какие-либо кадры, за исключением HEADERS, RST_STREAM или PRIORITY.

В этом состоянии может быть принят кадр PRIORITY или WINDOW_UPDATE. Получение кадра любого типа, кроме RST_STREAM, PRIORITY или WINDOW_UPDATE, в этом состоянии должно трактоваться, как ошибка соединения (параграф 5.4.1) типа PROTOCOL_ERROR.

reserved (remote) — зарезервирован удаленной стороной

Поток в состоянии reserved (remote) — этот поток, который был зарезервирован удаленным партнером.

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

• Получение кадра HEADERS вызывает переход потока в состояние half-closed (local).
• Любая из оконечных точек может передать кадр RST_STREAM, который переводит поток в состояние closed, отменяя резервирование.

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

Получение кадра любого типа, кроме HEADERS, RST_STREAM или PRIORITY, в этом состоянии должно трактоваться, как ошибка соединения (параграф 5.4.1) типа PROTOCOL_ERROR.

open — открыт

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

Из этого состояния любая из конечных точек может передать кадр с установленным флагом END_STREAM, который вызывает переход потока в одно из полузакрытых (half-closed) состояний. Конечная точка, передавшая флаг END_STREAM вызывает переход потока в состояние half-closed (local), а принявшая флаг END_STREAM — в состояние half-closed (remote).

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

half-closed (local) — полузакрыт локальной стороной

Поток в состоянии half-closed (local) не может быть использован для передачи каких-либо кадров за исключением WINDOW_UPDATE, PRIORITY и RST_STREAM.

Поток переходит из состояния half-closed (local) в закрытое (closed) при получении кадра с установленным флагом END_STREAM или при отправке любым из партнеров кадра RST_STREAM.

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

Кадры PRIORITY, полученные в этом состоянии, служат для повторной приоритизации потоков, зависящих от указанного потока.

half-closed (remote) — полузакрыт удаленной стороной

Поток в состоянии half-closed (remote) больше не может использоваться партнером для передачи кадров. В этом состоянии конечная точка больше не обязана поддерживать окно (получателя) управления потоком данных.

Если конечная точка получает какие-либо кадры, отличные от WINDOW_UPDATE, PRIORITY и RST_STREAM, для потока в этом состоянии, она должна возвращать ошибку потока (параграф 5.4.2) типа STREAM_CLOSED.

Поток в состоянии half-closed (remote) может использоваться конечной точкой для передачи кадров любого типа и конечная точка будет продолжать наблюдение ограничений, связанных у управлением потоком данных на уровне потока в целом (параграф 5.2).

Поток может перейти из состояния half-closed (remote) в закрытое состояние путем передачи кадра с флагом END_STREAM или передачи любой из сторон кадра RST_STREAM.

closed — закрыт

Состояние closed является завершающим для потока.

Конечной точке недопустимо передавать в закрытый поток какие-либо кадры, за исключением PRIORITY. Конечная точка, получившая отличный от PRIORITY после приема RST_STREAM, должна трактовать его, как ошибку потока (параграф 5.4.2) типа STREAM_CLOSED. Аналогично, конечная точка, получившая любой кадр после приема кадра с флагом END_STREAM, должна трактовать это, как ошибку соединения (параграф 5.4.1) типа STREAM_CLOSED, если кадр не разрешен в соответствии с приведенным ниже описанием.

Кадры WINDOW_UPDATE или RST_STREAM могут приниматься в этом состоянии в течение короткого периода после отправки кадра DATA или HEADERS с флагом END_STREAM. Пока удаленный партнер не получит и не обработает RST_STREAM или кадр с флагом END_STREAM, передача этих типов кадров возможна. Конечные точки должны игнорировать кадры WINDOW_UPDATE и RST_STREAM, принятые в этом состоянии, хотя они могут выбрать трактовку кадров, принятых по истечении достаточно продолжительного времени после отправки END_STREAM, как ошибок соединения (параграф 5.4.1) типа PROTOCOL_ERROR.

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

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

Кадры с управлением потоком данных (т. е., DATA), принятые после отправки RST_STREAM, учитываются в окне управления потоком данных соединения. Эти кадры могут игнорироваться, но, поскольку они были переданы до получения их отправителем кадра RST_STREAM, отправитель будет учитывать их в окне управления потоком данных.

Конечная точка может получить кадр PUSH_PROMISE после отправки ею RST_STREAM. Кадр PUSH_PROMISE вызывает переход потока в состояние reserved, даже если связанный с ним поток сброшен. Следовательно, для закрытия нежелательного потока требуется RST_STREAM.

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

Пример смены состояния для обмена запрос-отклик HTTP приведены в параграфе 8.1, примеры смены состояний для выталкивания на сервере (server push) — в параграфах 8.2.1 и 8.2.2.

5.1.1. Идентификаторы потоков

Для идентификации потоков используются целые числа без знака размером 31 бит. Потоки, инициируемые клиентами, должны иметь нечетные идентификаторы, а потоки, инициируемые серверами, — четные. Идентификатор с нулевым значением (0x0) служит для сообщений управления соединением и не может применяться для организации нового потока.

На запросы HTTP/1.1, обновленные до HTTP/2 (см. параграф 3.2), отвечают с идентификатором потока 1 (0x1). По завершении процесса обновления поток 0x1 переходит в состояние half-closed (local) для клиента. Следовательно, идентификатор 0x1 не может быть выбран для нового потока клиентом, который обновляется с HTTP/1.1.

Идентификатор вновь созданного потока должен быть численно больше идентификаторов всех потоков, которые инициирующая точка открыла или зарезервировала. Это относится к потокам, открываемым с помощью кадров HEADERS и резервируемым с помощью PUSH_PROMISE. Конечная точка, получившая неожиданный идентификатор потока, должна ответить на него сообщением об ошибке соединения (параграф 5.4.1) типа PROTOCOL_ERROR.

Первое использование идентификатора нового потока неявно закрывает все бездействующие (состояние idle) потоки, которые были инициированы этим партнером и имеют меньшие значения идентификаторов. Например, если клиент передает кадр HEADERS в поток 7 без передачи кадров в поток 5, то поток 5 переводится в состояние closed при отправке или получении первого кадра для потока 7.

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

5.1.2. Одновременные потоки

Партнер может ограничить число одновременно активных потоков, используя параметр SETTINGS_MAX_CONCURRENT_STREAMS (см. параграф 6.5.2) в кадре SETTINGS. Максимальное число одновременных потоков задается для каждой конечной точки и применяется только к партнеру, получившему эти настройки. Т. е., клиент определяет максимальное число одновременных потоков, которые может инициировать сервер, а серверы задают максимальное число одновременных потоков, которые может инициировать клиент.

Потоки в состоянии open или любом из полузакрытых (half-closed) состояний учитываются в числе разрешенных одновременных потоков. Потоки в любом из этих трех состояний учитываются при контроле предела, заданного параметром SETTINGS_MAX_CONCURRENT_STREAMS. Потоки в любом из резервных (reserved) состояний не учитываются в числе одновременных.

Конечной точке недопустимо превышать заданный ее партнером предел числа потоков. Конечная точка, получившая кадр HEADERS, который вызывает превышение анонсированного предела, должна трактовать это как ошибку потока (параграф 5.4.2) типа PROTOCOL_ERROR или REFUSED_STREAM. Выбор типа определяется желанием конечной точки разрешать автоматические повторы (см. параграф 8.1.4).

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

5.2. Управление потоком

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

HTTP/2 обеспечивает управление потоком данных на основе кадров WINDOW_UPDATE (параграф 6.9).

5.2.1. Принципы управления потоком данных

Управление потоком данных в потоках HTTP/2 имеет целью обеспечить возможность применения множества разных алгоритмов управления потоком данных без изменения протокола. Характеристики управления потоком данных в HTTP/2 перечислены ниже.

1. Управление потоком данных относится к конкретному соединению. Оба типа управления потоком реализуются между конечными точками одного интервала пересылки (hop), а не сквозного пути.

2. Управление потоком данных основано на кадрах WINDOW_UPDATE. Получатели анонсируют число октетов, которые они готовы принимать в потоке и соединении в целом. Эта схема является кредитной (credit-based).

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

4. Начальное значение размера окна управления потоком данных составляет 65 535 октетов как для нового потока, так и для соединения в целом.

5. Тип кадра определяет применение к нему управления потоком данных. Из описанных в документе типов кадров управление потоком применяется только к кадрам DATA, а остальные типы кадров не учитываются в окне управления потоком данных. Это предотвращает блокировку важных кадров управления системой контроля потока данных.

6. Управление потоком данных не может быть отключено.

7. HTTP/2 определяет лишь формат и семантику кадров WINDOW_UPDATE (параграф 6.9). Этот документ не задает условий, при которых получатель передает такие кадры или отправляемые в них значения, и не указывает, как отправитель выбирает пакеты для передачи. Реализации могут выбирать любые алгоритмы, соответствующие их потребностям.

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

5.2.2. Допустимое использование управления потоком данных

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

Системы, где такая возможность не требуется, могут анонсировать окно управления потоком данных максимального размера (2³¹-1) и поддерживать это окно, предавая кадр WINDOW_UPDATE при получении любых данных. Это эффективно отключает управление потоком данных для этого получателя. А отправитель всегда использует окно управления потоком данные, анонсированное получателем.

Системы с ограниченными ресурсами (например, памятью) могут реализовать управление потоком данных для ограничения объема памяти, которым может воспользоваться партнер. Однако следует отметить, что это может приводить к неоптимальному использованию доступных ресурсов сети, если управление потоком данных включено без информации о произведении «пропускная способность — задержка» (см. [RFC7323]).

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

5.3. Приоритет потока

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

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

Потоки можно приоритизировать путем их маркировки в зависимости от завершения других потоков (параграф 5.3.1). Для каждой зависимости выделяется относительный «вес» — число, которое используется для определения относительной доли доступных ресурсов, выделяемых потокам, которые зависят от одного и того же потока.

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

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

5.3.1. Зависимости потока

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

Поток, который не зависит от какого-либо другого потока, имеет значение зависимости 0x0. Иными словами, несуществующий поток 0 образует корень дерева (зависимостей).

Поток, зависящий от другого потока, является зависимым. Поток, от которого зависит другой поток, называется родительским. Зависимость потока, не включенного в текущее дерево (такой поток находится в состоянии простоя — idle), приводит к тому, что данный поток получает используемый по умолчанию приоритет (параграф 5.3.5).

При определении зависимости от другого потока поток добавляется в качестве новой зависимости родительского потока. Зависимые потоки с общим родителем не упорядочиваются один относительно другого. Например, если потоки B и C зависят от потока A и создается поток D, зависящий от потока A, это приведет к зависимости от A потоков B, C и D в любом порядке.

                     A                 A
                    / \      ==>      /|\
                   B   C             B D C

Рисунок 3. Пример создания зависимости «по умолчанию»

 

Флаг эксклюзивности позволяет добавить новый уровень зависимости. Этот флаг делает поток зависящим лишь от его родителя, делая остальные потоки (зависимости) зависящими от данного исключительного потока. В предыдущем примере создание потока D с исключительной зависимостью от потока A делает поток D родительским для B и C.

                                       A
                     A                 |
                    / \      ==>       D
                   B   C              / \
                                     B   C

Рисунок 4. Пример создания исключительной зависимости

 

Внутри дерева зависимостей зависимому потоку следует выделять ресурсы только в тех случаях, когда все потоки, от которых он зависит (цепочка родителей вплоть до 0x0), закрыты или в них ничего не происходит.

Поток не может зависеть от самого себя. Конечная точка должна трактовать это как ошибку потока (параграф 5.4.2) типа PROTOCOL_ERROR.

5.3.2. «Взвешивание» зависимостей

Все зависимости потоков выражаются «весом» — целыми числами от 1 до 256 (включительно).

Потокам, имеющим общего родителя следует распределять ресурсы пропорционально весу. Таким образом, если поток B зависит от потока A и имеет вес 4, поток C тоже зависит от A, но имеет вес 12 и в потоке A ничего не происходит, в идеальном случае B получит треть ресурсов, выделенных для потока C.

5.3.3. Повторная приоритизация

Приоритет для потоков изменяется с помощью кадров PRIORITY. Установка зависимости вынуждает поток стать зависимым от указанного родительского потока.

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

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

В качестве примера рассмотрим дерево зависимостей, где B и C зависят от A, D и E зависят от C, а F — от D. Если поток A становится зависимым от D, то D занимает место A. Все остальные отношения зависимости сохраняются за исключением потока F, который становится зависимым от A, если реприоритизация является исключительной.

  x                x                x                 x
  |               / \               |                 |
  A              D   A              D                 D
 / \            /   / \            / \                |
B   C     ==>  F   B   C   ==>    F   A       OR      A
   / \                 |             / \             /|\
  D   E                E            B   C           B C F
  |                                     |             |
  F                                     E             E
            (промежуточное)   (неисключит.)    (исключит.)

Рисунок 5. Пример изменения порядка зависимостей

5.3.4. Управление состоянием приоритизации

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

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

В качестве примера предположим, что потоки A и B имеют общего родителя, а потоки C и D зависят от A. До удаления потока A при невозможности продолжения A и D поток C получит все ресурсы, выделенные для A. Если поток A удален из дерева, вес этого потока будет поделен между C и D. Если продолжение D становится невозможным, поток C получит только часть ресурсов. При одинаковых начальных весах это составит 1/3, а не половину доступных ресурсов.

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

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

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

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

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

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

5.3.5. Приоритеты по умолчанию

Все потокам изначально задается неисключительная зависимость от потока 0x0. Выталкиваемые потоки (параграф 8.2) изначально зависят от связанных с ними потоков. В обоих случаях потокам присваивается принятый по умолчанию вес 16.

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

Кадрирование HTTP/2 допускает два класса ошибок:

• ошибки, не позволяющие использовать соединение совсем, называются ошибками соединения;

• ошибки в отдельных потоках называются ошибками потока.

Список кодов ошибок представлен в разделе 7.

5.4.1. Обработка ошибок соединения

Ошибкой соединения считается любая ошибка, препятствующая дальнейшей обработке уровня кадров или повреждающая состояние соединения.

Конечной точке, столкнувшейся с ошибкой соединения, следует сначала передать кадр GOAWAY (параграф 6.8) с идентификатором последнего потока, полученного без ошибок от партнера. Кадр GOAWAY включает код ошибки, указывающий причину разрыва соединения. После отправки кадра GOAWAY конечная точка должна закрыть соединение TCP.

Возможны ситуации, когда нет гарантии получения кадра GOAWAY принимающей стороной (в параграфе 6.6 [RFC7230] описано, как незамедлительный разрыв может вызывать потерю данных). В случае ошибки соединения GOAWAY обеспечивает лишь попытку сообщить партнеру о причине разрыва соединения.

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

5.4.2. Обработка ошибок потока

Ошибки потока относятся к конкретному потоку и не затрагивают работу других потоков.

Конечная точка, обнаружившая ошибку потока, передает кадр RST_STREAM (параграф 6.4) с идентификатором потока, в котором возникла ошибка. Кадр RST_STREAM включает код, обозначающий тип ошибки.

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

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

Для предотвращения петель конечным точкам недопустимо передавать кадры RST_STREAM в ответ на получение RST_STREAM.

5.4.3. Разрыв соединения

Если соединение TCP закрывается или сбрасывается, а потоки остаются в открытом (open) или полузакрытом (half-closed) состоянии, затронутые этим потоки невозможно восстановить автоматически (см. параграф 8.1.4).

5.5. Расширения HTTP/2

HTTP/2 допускает расширения протокола. В рамках описанных в этом параграфе ограничений протокольные расширения могут применяться для предоставления дополнительных услуг или изменения некоторых аспектов протокола. Расширения действуют только в рамках одного соединения HTTP/2.

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

В расширениях разрешается использовать новые кадры (параграф 4.1), новые параметры (параграф 6.5.2) или новые коды ошибок (раздел 7). Для поддержки этих расширений организованы новые реестры: тип кадров (параграф 11.2), параметры (параграф 11.3), коды ошибок(параграф 11.4).

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

Расширения, которые могут менять семантику существующих компонент протокола, должны согласовываться до начала использования. Например, расширение, которое меняет схему кадра HEADERS нельзя применять, пока партнер не сообщил о возможности их восприятия. В таких случаях может потребоваться также согласования начала использования измененной схемы. Отметим, что предположение об использовании управления потоком для каких-либо кадров, отличных от DATA, является таким изменением семантики и может применяться лишь после согласования.

Этот документ не задает конкретного метода согласования использования расширений, но отмечает, что для этого могут служить настройки (параграф 6.5.2). Если оба партнера устанавливают значение, которое показывает готовность использовать расширение, это расширение может применяться. При использовании настроек для согласования расширения начальное значение должно определяться с запретом расширения по умолчанию.

6. Определения кадров

Данная спецификация определяет множество типов кадров, каждый из которых идентифицируется уникальным 8-битовым кодом типа. Каждый тип кадров служит своим целям в процессе организации и поддержки соединения в целом и его отдельных потоков.

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

6.1. DATA

Кадры DATA (type=0x0) передают произвольные последовательности октетов переменного размера, связанные с потоком. Например, один или множество кадров DATA может быть использован для передачи данных запроса или отклика HTTP.

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

+---------------+
|Pad Length? (8)|
+---------------+-----------------------------------------------+
|                            Data (*)                         ...
+---------------------------------------------------------------+
|                           Padding (*)                       ...
+---------------------------------------------------------------+

Рисунок 6. Информация кадра DATA

Поля кадров DATA перечислены ниже.

Pad Length

8-битовое поле, содержащее размер заполнения кадра в октетах. Это поле является условным (указано символом ? на рисунке) и присутствует только при установленном флаге PADDED.

Data

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

Padding

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

Ниже перечислены флаги, определенные для кадров DATA.

END_STREAM (0x1)

Установленный бит 0 показывает, что этот кадр является последним, который данная конечная точка передала для указанного потока. Установка этого флага вызывает переход потока в полузакрытое (half-closed) или закрытое (closed) состояние (параграф 5.1).

PADDED (0x8)

Установленный бит 3 указывает на присутствие поля Pad Length и октетов заполнения, указанных им.

Кадр DATA должны быть связаны с потоком. В ответ на кадр DATA с идентификатором потока 0x0 получатель должен передать сигнал об ошибке соединения (параграф 5.4.1) типа PROTOCOL_ERROR.

Для кадров DATA применяется управление потоком данных и они могут передавать только в потоках с состоянием open или half-closed (remote). При управлении потоком данных учитывается вся информация кадра DATA, включая поля Pad Length и Padding при их наличии. Если кадр DATA принят в потоке, состояние которого является open или half-closed (local), получатель должен ответить индикацией ошибки потока (параграф 5.4.2) типа STREAM_CLOSED.

Общее число октетов заполнения определяется значением поля Pad Length. Если размер заполнения совпадает с размером данных в кадре или превышает его, получатель должен трактовать это как ошибку соединения (параграф 5.4.1) типа PROTOCOL_ERROR.

Примечание. Размер кадра может быть увеличен на один октет путем включения поля Pad Length = 0.

6.2. HEADERS

Кадры HEADERS (type=0x1) служат для создания потоков (параграф 5.1) и для передачи фрагментов блока заголовков. Кадры HEADERS могут передаваться в потоки с состоянием idle, reserved (local), open или half-closed (remote).

+---------------+
|Pad Length? (8)|
+-+-------------+-----------------------------------------------+
|E|                 Stream Dependency? (31)                     |
+-+-------------+-----------------------------------------------+
|  Weight? (8)  |
+-+-------------+-----------------------------------------------+
|                   Header Block Fragment (*)                 ...
+---------------------------------------------------------------+
|                           Padding (*)                       ...
+---------------------------------------------------------------+

Рисунок 7. Информация кадра HEADERS

Элементы данных кадров HEADERS приведены ниже.

Pad Length

8-битовое поле, содержащее размер заполнения кадра в октетах. Это поле присутствует только при установленном флаге PADDED.

E

Однобитовый флаг, указывающий на исключительную зависимость потока (см. параграф 5.3). Это поле присутствует лишь при установленном флаге PRIORITY.

Stream Dependency

31-битовый идентификатор потока, от которого зависит данный поток (см. параграф 5.3). Это поле присутствует лишь при установленном флаге PRIORITY.

Weight

8-битовое целое число без знака, представляющее вес приоритета для потока (см. параграф 5.3). Добавление 1 к значению поля дает вес от 1 до 256. Это поле присутствует лишь при установленном флаге PRIORITY.

Header Block Fragment

Фрагмент блока заголовка (параграф 4.3).

Padding

Октеты заполнения.

Ниже перечислены флаги, определенные для кадров HEADERS.

END_STREAM (0x1)

Установленный бит 0 показывает, что блок заголовка (параграф 4.3) является последним, который данная конечная точка передала для указанного потока.

Кадры HEADERS передают флаги END_STREAM, указывающие конец потока. Однако за кадром HEADERS с установленным флагом END_STREAM могут следовать кадры CONTINUATION того же потока. Логически кадры CONTINUATION являются частью кадра HEADERS.

END_HEADERS (0x4)

Установленный бит 2 показывает, что кадр содержит целый блок заголовка (параграф 4.3) и за ним не следует кадров CONTINUATION.

За кадром HEADERS со сброшенным флагом END_HEADERS должен следовать кадр CONTINUATION для того же потока. Получатель должен трактовать прием другого типа кадра или кадра в другом потоке как ошибку соединения (параграф 5.4.1) типа PROTOCOL_ERROR.

PADDED (0x8)

Установленный бит 3 указывает на присутствие поля Pad Length и октетов заполнения, указанных им.

PRIORITY (0x20)

Установленный бит 5 говорит о присутствии полей Exclusive Flag (E), Stream Dependency и Weight (см. параграф 5.3).

Данные кадра HEADERS включают блок заголовка (параграф 4.3). Если этот блок не помещается в кадр HEADERS, он продолжается в кадре CONTINUATION (параграф 6.10).

HEADERS должны привязываться к потокам. В ответ на кадр HEADERS с идентификатором потока 0x0 получатель должен передать сигнал об ошибке соединения (параграф 5.4.1) типа PROTOCOL_ERROR.

Кадр HEADERS меняет состояние соединения в соответствии с параграфом 4.3.

Кадры HEADERS могут включать заполнение. Поля заполнения идентичны используемым в кадрах DATA (параграф 6.1). Заполнение, размер которого превышает размер оставшийся после размещения фрагмента блока заголовка, должен трактоваться как PROTOCOL_ERROR.

Информация о приоритете в кадрах HEADERS логически эквивалентна отдельному кадру PRIORITY, но ее включение в HEADERS позволяет предотвратить ошибочную приоритизацию при создании нового потока. Поля приоритизации в кадрах HEADERS, следующих за первым в потоке, меняют приоритизацию потока (параграф 5.3.3).

6.3. PRIORITY

Кадр PRIORITY (type=0x2) задает предложенный отправителем приоритет для потока (параграф 5.3). Эти кадры могут передаваться при любом состоянии потоков, включая бездействующие (idle) и закрытые (closed).

+-+-------------------------------------------------------------+
|E|                  Stream Dependency (31)                     |
+-+-------------+-----------------------------------------------+
|   Weight (8)  |
+-+-------------+

Рисунок 8. Информация кадра PRIORITY

Информационные поля кадра PRIORITY показаны на рисунке.

E

Однобитовый флаг, указывающий на исключительную зависимость потока (см. параграф 5.3).

Stream Dependency

31-битовый идентификатор потока, от которого зависит данный поток (см. параграф 5.3).

Weight

8-битовое целое число без знака, представляющее вес приоритета для потока (см. параграф 5.3). Добавление 1 к значению поля дает вес от 1 до 256.

Для кадров PRIORITY не определено каких-либо флагов.

Кадр PRIORITY всегда идентифицирует поток. В ответ на кадр PRIORITY с идентификатором потока 0x0 получатель должен передать сигнал об ошибке соединения (параграф 5.4.1) типа PROTOCOL_ERROR.

Кадр PRIORITY может быть передан в любом состоянии потока, однако он не может передаваться между последовательными кадрами, составляющими один блок заголовка (параграф 4.3). отметим, что этот кадр может приходить после завершения обработки или передачи кадра и в результате не повлияет на указанный поток. Для потоков в состоянии half-closed (remote) или closed этот кадр может влиять лишь на обработку указанного потока и зависимых от него потоков, не оказывая влияния на передачу самого кадра в этом потоке.

Кадр PRIORITY может быть передан в потоки, находящиеся в состоянии idle или closed. Это позволяет изменить приоритизацию группы зависимых потоков, поменяв приоритет неиспользуемого или закрытого родительского потока.

Кадры PRIORITY с размером, отличным от 5 октетов, должны трактоваться как ошибка потока (параграф 5.4.2) типа FRAME_SIZE_ERROR.

6.4. RST_STREAM

Кадр RST_STREAM (type=0x3) позволяет незамедлительно прервать поток. RST_STREAM передается для запроса разрыва потока или индикации возникшей ошибки.

+---------------------------------------------------------------+
|                        Error Code (32)                        |
+---------------------------------------------------------------+

Рисунок 9. Информация кадра RST_STREAM

Кадр RST_STREAM содержит одно 32-битовое целое число без знака, указывающее код ошибки (параграф 7), который показывает причину прерывания потока.

Для кадров RST_STREAM не определено каких-либо флагов.

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

Кадр RST_STREAM должен быть связан с потоком. В ответ на кадр RST_STREAM с идентификатором потока 0x0 получатель должен передать сигнал об ошибке соединения (параграф 5.4.1) типа PROTOCOL_ERROR.

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

Кадры RST_STREAM с размером, отличным от 4 октетов, должны трактоваться как ошибка потока (параграф 5.4.2) типа FRAME_SIZE_ERROR.

6.5. SETTINGS

Кадры SETTINGS (type=0x4) служат для передачи конфигурационных параметров, воздействующих на коммуникации конечной точки, типа предпочтений и ограничений в поведении партнера. Кадры SETTINGS служат также для подтверждения приема таких параметров. Отдельные параметры из кадров SETTINGS могут называться также «установками» (setting).

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

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

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

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

ACK (0x1)

Установленный бит 0 показывает, что кадр подтверждает прием и применение кадра SETTINGS от партнера. При установленном флаге поля данных (payload) кадра SETTINGS должны быть пустыми. Прием кадра SETTINGS с флагом ACK и отличным от 0 полем размера должен трактоваться как ошибка соединения (параграф 5.4.1) типа FRAME_SIZE_ERROR. Дополнительная информация приведена в параграфе 6.5.3. Синхронизация настроек.

Кадры SETTINGS всегда относятся к соединению, а не к отдельным потокам. Поле идентификатора потока в кадрах SETTINGS должно иметь нулевое значение (0x0). При получении кадра SETTINGS с отличным от 0 идентификатором потока конечная точка должна ответить сигналом об ошибке соединения (параграф 5.4.1) типа PROTOCOL_ERROR.

Кадры SETTINGS влияют на состояние соединения. Некорректно сформированные или неполные кадры SETTINGS должны трактоваться как ошибка соединения (параграф 5.4.1) типа PROTOCOL_ERROR.

Кадры SETTINGS с размером, не кратным 6 октетам, должны считаться ошибкой соединения (параграф 5.4.1) типа FRAME_SIZE_ERROR.

6.5.1. Формат SETTINGS

Информационные поля кадра SETTINGS могут (но не обязаны) включать параметры, каждый из которых включает 16-битовый идентификатор и 32-битовое значение.

+-------------------------------+
|       Identifier (16)         |
+-------------------------------+-------------------------------+
|                        Value (32)                             |
+---------------------------------------------------------------+

Рисунок 10. Информация кадра SETTINGS

6.5.2. Параметры SETTINGS

Определенные настоящим документом параметры перечислены ниже.

SETTINGS_HEADER_TABLE_SIZE (0x1)

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

SETTINGS_ENABLE_PUSH (0x2)

Эта установка может служить для запрета выталкивания данных сервером (параграф 8.2). Конечной точке недопустимо передавать кадр PUSH_PROMISE, если она получила этот параметр со значением 0. Конечная точка, установившая для этого параметра значение 0 и имеющая подтверждение этого, должна трактовать получение кадра PUSH_PROMISE, как ошибку соединения (параграф 5.4.1) типа PROTOCOL_ERROR.

В качестве начального значения параметра используется 1, что показывает возможность использования на сервере выталкивания данных. Все значения этого параметра, кроме 0 и 1, должны считаться ошибкой соединения (параграф 5.4.1) типа PROTOCOL_ERROR.

SETTINGS_MAX_CONCURRENT_STREAMS (0x3)

Показывает максимальное число потоков, которые будет разрешать отправитель. Это ограничение является направленным и указывает число потоков, которые отправитель позволяет создавать получателю. Изначально для этого значения не задано ограничений. Рекомендуется устанавливать для этого параметра значение не менее 100 чтобы не возникало неоправданного ограничения параллельной работы.

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

SETTINGS_INITIAL_WINDOW_SIZE (0x4)

Показывает размер начального окна отправителя (в октетах) для управления потоком данных на уровне потока. Начальное значение составляет 2¹⁶-1 (65 535) октетов.

Этот параметр влияет на размер окна для всех потоков (см. параграф 6.9.2).

Значения, превышающие максимальный размер окна управления потоком данных 2³¹-1, должны считаться ошибкой соединения (параграф 5.4.1) типа FLOW_CONTROL_ERROR.

SETTINGS_MAX_FRAME_SIZE (0x5)

Показывает максимальный размер данных (payload) в кадре, которые отправитель готов получать (в октетах).

Начальное значение составляет 2¹⁴ (16 384) октетов. Анонсируемые конечной точкой значения должны лежать в диапазоне от этого начального значения до максимального разрешенного размера кадра (2²⁴-1 или 16 777 215 октетов), включительно. Выходящие за предел этого диапазона значения должны считаться ошибкой соединения (параграф 5.4.1) типа PROTOCOL_ERROR.

SETTINGS_MAX_HEADER_LIST_SIZE (0x6)

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

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

Конечная точка, получившая кадр SETTINGS с неизвестными или неподдерживаемыми идентификаторами, должна игнорировать такой кадр.

6.5.3. Синхронизация настроек

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

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

Если отправитель кадра SETTINGS не получает подтверждения в течение разумного интервала, он может передать сигнал об ошибке соединения (параграф 5.4.1) типа SETTINGS_TIMEOUT.

6.6. PUSH_PROMISE

Кадры PUSH_PROMISE (type=0x5) служат для упреждающего уведомления конечной точки-партнера об инициировании потоков. Кадр PUSH_PROMISE включает 31-битовый беззнаковый индикатор потока, который конечная точка планирует открыть, вместе с набором заголовков, обеспечивающих для потока дополнительный контекст. Использование кадров PUSH_PROMISE подробно описано в параграфе 8.2.

+---------------+
|Pad Length? (8)|
+-+-------------+-----------------------------------------------+
|R|                  Promised Stream ID (31)                    |
+-+-----------------------------+-------------------------------+
|                   Header Block Fragment (*)                 ...
+---------------------------------------------------------------+
|                           Padding (*)                       ...
+---------------------------------------------------------------+

Рисунок 11. Информация кадра PUSH_PROMISE

Информационные поля кадра PUSH_PROMISE описаны ниже.

Pad Length

8-битовое поле, содержащее размер заполнения кадра в октетах. Это поле присутствует только при установленном флаге PADDED.

R

Один резервный бит.

Promised Stream ID

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

Header Block Fragment

Фрагмент блока заголовка (параграф 4.3), содержащий поля заголовка запроса.

Padding

Октеты заполнения.

Ниже описаны флаги, определенные для кадров PUSH_PROMISE.

END_HEADERS (0x4)

Установленный бит 2 показывает, что этот кадр целиком содержит блок заголовка (параграф 4.3) и за ним не следует кадров CONTINUATION.

Кадр PUSH_PROMISE без флага END_HEADERS должен сопровождаться последующим кадром CONTINUATION для того же потока. Получатель должен считать получение вслед за таким кадром END_HEADERS кадра другого типа или кадра для другого потока ошибкой соединения (параграф 5.4.1) типа PROTOCOL_ERROR.

PADDED (0x8)

Установленный бит 3 говорит о наличии поля Pad Length и соответствующего размера поля заполнения.

Кадры PUSH_PROMISE должны передаваться только в инициированный партнером поток, находящийся в состоянии open или half-closed (remote). Идентификатор потока в кадре PUSH_PROMISE указывает поток, с которым кадр связан. Получение такого кадра с идентификатором потока 0x0 должен считаться ошибкой соединения (параграф 5.4.1) типа PROTOCOL_ERROR.

Предложенные потоки не требуется применять в том порядке, в котором они были обещаны. Кадры PUSH_PROMISE лишь резервируют идентификаторы потока для последующего использования.

Кадры PUSH_PROMISE недопустимо передавать, если для партнера установлено значение SETTINGS_ENABLE_PUSH = 0. Конечная точка с такой установкой, если она была подтверждена, должна считать получение кадра PUSH_PROMISE ошибкой соединения (параграф 5.4.1) типа PROTOCOL_ERROR.

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

Кадры PUSH_PROMISE меняют состояние соединения двумя путями. Во-первых, включение блока заголовка (параграф 4.3) может поменять состояние, поддерживаемое в части сжатия заголовков. Во-вторых, PUSH_PROMISE также резервирует поток для последующего использования, переводя предложенный поток в состояние reserved. Отправителю недопустимо передавать кадр PUSH_PROMISE в поток, который не находится в состоянии open или half-closed (remote), отправитель должен обеспечить пригодность предложенного потока для выбора в качестве нового (параграф 5.1.1) (т. е., предложенный поток должен находиться в состоянии idle).

Поскольку кадр PUSH_PROMISE резервирует поток, игнорирование PUSH_PROMISE делает состояние потока неопределенным. Получатель кадра PUSH_PROMISE в потоке с состоянием отличным от open и half-closed (local) должен считать это ошибкой соединения (параграф 5.4.1) типа PROTOCOL_ERROR. Однако конечная точка, передавшая RST_STREAM в соответствующий поток, должна обрабатывать полученные кадры PUSH_PROMISE, как будто они приняты до того, как был отправлен и обработан кадр RST_STREAM.

Получатель должен считать кадр PUSH_PROMISE, предлагающий недопустимый идентификатор потока (параграф 5.1.1), ошибкой соединения (параграф 5.4.1) типа PROTOCOL_ERROR. Отметим, что недопустимыми считаются идентификаторы потоков, которые не находятся в состоянии idle.

Кадры PUSH_PROMISE могут включать заполнение. Поля и флаги заполнения идентичны описанным для кадров DATA (параграф 6.1).

6.7. PING

Кадры PING (type=0x6) обеспечивают механизм измерения минимального времени кругового обхода от отправителя, а также проверки работоспособности соединения. Кадры PING может передавать любая из конечных точек.

+---------------------------------------------------------------+
|                                                               |
|                      Opaque Data (64)                         |
|                                                               |
+---------------------------------------------------------------+

Рисунок 12. Информация кадра PING

В дополнение к заголовку кадр PING должен содержать 8 октетов не обрабатываемых (opaque) данных в информационном поле. Отправитель может выбирать содержимое этого поля произвольным способом.

Получатель кадра PING без флага ACK должен передать в ответ кадр PING с установленным флагом ACK и исходным информационным полем (payload). Откликам PING следует отдавать приоритет по отношению к другим кадрам.

Для кадров PING определен описанный ниже флаг.

ACK (0x1)

Установленный бит 0 показывает, что данный кадр PING является откликом на запрос PING. Конечные точки должны устанавливать этот флаг в откликах PING. Конечным точкам недопустимо отвечать на кадры PING с установленным флагом.

Кадры PING не связываются с каким-либо потоком. Получение кадра PING с отличным от 0x0 идентификатором потока должно считаться ошибкой соединения (параграф 5.4.1) типа PROTOCOL_ERROR.

Получение кадра PING с отличным от 8 полем размера должно считаться ошибкой соединения (параграф 5.4.1) типа FRAME_SIZE_ERROR.

6.8. GOAWAY

Кадры GOAWAY (type=0x7) служат для инициирования разрыва соединения или сигнализации о серьезной ошибке. GOAWAY позволяет конечной точке аккуратно прекратить восприятие новых потоков, продолжая обработку ранее созданы до их завершения. Это важно для административных операций типа обслуживания серверов.

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

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

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

Конечным точкам следует всякий раз передавать кадр GOAWAY перед завершением соединения, чтобы удаленная сторона могла понимать какие из потоков будут обработаны. Например, если клиент HTTP передает запрос POST в тот же момент, когда сервер закрывает соединение, клиент просто не может знать начал ли сервер обработку этого запроса, если сервер не передаст кадр GOAWAY, показывающий какие потоки будут обработаны.

При некорректном поведении партнера конечная точка может закрыть соединение без отправки кадра GOAWAY.

Кадр GOAWAY не обязательно присутствует закрытию соединения непосредственно. Получателю кадра GOAWAY, который больше не намерен использовать соединение, следует передать кадр GOAWAY перед разрывом соединения.

+-+-------------------------------------------------------------+
|R|                  Last-Stream-ID (31)                        |
+-+-------------------------------------------------------------+
|                      Error Code (32)                          |
+---------------------------------------------------------------+
|                  Additional Debug Data (*)                    |
+---------------------------------------------------------------+

Рисунок 13. Информация кадра GOAWAY

Для кадров GOAWAY не определено каких-либо флагов.

Кадры GOAWAY связаны с соединением, а не с конкретным потоком. Конечная точка должна считать кадры GOAWAY с отличным от 0x0 идентификатором потока ошибкой соединения (параграф 5.4.1) типа PROTOCOL_ERROR.

Идентификатор последнего потока в кадре GOAWAY указывает наибольший номер потока, для которого отправитель GOAWAY может предпринимать те или иные действия. Все потоки, вплоть до указанного значения идентификатора (включая его) будут так или иначе обработаны. Для последнего потока может быть указано значение 0, если потоки больше не будут обрабатываться совсем.

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

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

В потоках с меньшими или равным последнему значениями идентификаторов, которые не были полностью закрыты до разрыва соединения, попытки запросов, транзакций и иных протокольных действий невозможны, за исключением идемпотентных⁸ запросов типа HTTP GET, PUT или DELETE. Любые протокольные действия с потоками, идентификаторы которых превышают последний, можно безопасно повторить в новом соединении.

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

При изменении ситуации конечная точка может передать множество кадров GOAWAY. Например, конечная точка, передавшая кадр GOAWAY с кодом NO_ERROR, в процессе аккуратного разрыва соединения может столкнуться с обстоятельствами, требующими немедленно разорвать соединение. Идентификатор последнего потока из полученного сообщения GOAWAY показывает поток, до которого может продолжаться обработка. Конечным точкам недопустимо увеличивать значение идентификатора последнего потока, поскольку партнеры могут уже повторить необработанные запросы через другое соединение.

Клиент, не способный повторять запросы, будет терять все запросы, которые были «на лету» в момент разрыва соединения сервером. Это верно и для промежуточных устройств (посредников), которые могут не обслуживать клиентов, использующих HTTP/2. Серверу, который пытается аккуратно завершить соединение, следует передать начальный кадр GOAWAY с идентификатором последнего потока 2³¹-1 и кодом NO_ERROR. Это информирует клиента о неизбежности разрыва соединения и запрете отправки новых запросов. Выждав время для находящихся в процессе передачи запросов на создание потока (хотя бы один интервал кругового обхода), сервер может передать другой кадр GOAWAY с обновленным идентификатором последнего потока. Это позволяет разорвать соединение без потери запросов.

После передачи кадра GOAWAY отправитель может отбрасывать кадры от потоков, инициированных его получателем, если они содержат идентификаторы сегментов с номерами выше последнего. Однако кадры, меняющие состояние соединения, не могут быть полностью проигнорированы. Например, кадры HEADERS, PUSH_PROMISE и CONTINUATION должны пройти минимальную обработку для поддержки согласованности состояния сжатия заголовков (см. параграф 4.3). Кадры DATA должны учитываться в окне управления потоком данных соединения. Отказ от обработки указанных кадров может нарушать синхронизацию состояний управления потоком данных и сжатия заголовков.

Кадр GOAWAY содержит также 32-битовый код ошибки (параграф 7), указывающий причину разрыва соединения.

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

6.9. WINDOW_UPDATE

Кадры WINDOW_UPDATE (type=0x8) служат для реализации управления потоком данных (см. параграф 5.2).

Управление потоком данных осуществляется на двух уровнях — отдельные потоки и соединение в целом.

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

Управление потоком данных применяется лишь для кадров, обозначенных в качестве управляемых. Этот документ определяет единственный тип управляемых кадров — DATA. Кадры, не включаемые в управление потоком данных, должны восприниматься и обрабатываться, пока получатель способен выделять ресурсы для их обслуживания. Получатель может указать на ошибку потока (параграф 5.4.2) или соединения (параграф 5.4.1) типа FLOW_CONTROL_ERROR, если он не способен воспринять кадр.

+-+-------------------------------------------------------------+
|R|              Window Size Increment (31)                     |
+-+-------------------------------------------------------------+

Рисунок 14. Информация кадра WINDOW_UPDATE

Информационное поле (payload) кадра WINDOW_UPDATE представляет собой один резервный бит и 31-битовое целое число без знака, указывающее число октетов, которые отправитель может передать в дополнение к имеющемуся окну управления потоком данных. Допустимые значения добавок к окну управления потоком данных лежат в диапазоне от 1 до 2³¹-1 (2 147 483 647) октетов.

Для кадров WINDOW_UPDATE не определено каких-либо флагов.

Кадр WINDOW_UPDATE может относиться к конкретному потоку или соединению в целом. В первом случае в кадре указывается идентификатор соответствующего потока, во втором идентификатор имеет значение 0.

Получатель должен считать кадр WINDOW_UPDATE с нулевым инкрементом окна управления потоком данных ошибкой потока (параграф 5.4.2) типа PROTOCOL_ERROR или ошибкой соединения (параграф 5.4.1), если кадр относится к соединению в целом.

Кадр WINDOW_UPDATE может быть передан отправителем кадра с флагом END_STREAM. В таких случаях получатель может принять кадр WINDOW_UPDATE через поток в состоянии half-closed (remote) или closed. Недопустимо считать этот случай ошибкой (см. параграф 5.1).

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

Кадры WINDOW_UPDATE с размером, отличающимся от 4 октетов, должны считаться ошибкой соединения (параграф 5.4.1) типа FRAME_SIZE_ERROR.

6.9.1. Окно управления потоком данных

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

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

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

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

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

Отправитель, получив кадр WINDOW_UPDATE, увеличивает соответствующее окно на указанный в кадре размер. Отправителю недопустимо увеличивать размер окна управления потоком данных сверх 2³¹-1 октетов. Если отправитель получает кадр WINDOW_UPDATE со значением, приводящим к нарушению этого предела, он должен разорвать поток или соединение, к которому это относится. Для потоков в таких случаях отправитель передает RST_STREAM с кодом ошибки FLOW_CONTROL_ERROR, для соединений — кадр GOAWAY с кодом ошибки FLOW_CONTROL_ERROR.

Кадры, подлежащие управлению потоком от отправителя и кадры WINDOW_UPDATE от получателя не имеют какой-либо синхронизации. Это позволяет получателю активно обновлять размер окна, сохраняемый отправителем, для предотвращения «замораживания» потока.

6.9.2. Начальный размер окна управления потоком данных

При первоначальной организации соединения HTTP/2 новые потоки создаются с начальным окном управления потоком данных в в 65535 октетов. Размер окна управления потоком данных для всего соединения также составляет 65535 октетов. Обе конечных точки могут установить начальный размер окна для новых потоков, включая значение SETTINGS_INITIAL_WINDOW_SIZE в кадр SETTINGS, формирующий часть префикса соединения. Размер окна управления потоком данных для соединения в целом можно изменить лишь с помощью кадров WINDOW_UPDATE.

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

Кроме изменения размера окна управления потоком данных для еще не созданных потоков кадр SETTINGS может менять размер начального окна для потоков с уже активным окном управления потоком данных (т. е., потоков в состоянии open или half-closed (remote)). При изменении SETTINGS_INITIAL_WINDOW_SIZE получатель должен исправить размер окна управления потоком данных для всех потоков, которые он поддерживает, на разницу между новым и прежним значением.

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

Например, если клиент передал 60 KB данных сразу после организации соединения, а сервер установил для начального окна размер 16 KB, клиент получит для доступного в окне управления потоком пространства отрицательное значение -44 KB при получении кадра SETTINGS. Клиент сохраняет отрицательный размер окна управления потоком данных, пока кадры WINDOW_UPDATE не восстановят положительное значение и лишь после этого клиент может возобновить передачу.

Кадры SETTINGS не могут менять окно управления потоком данных соединения.

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

6.9.3. Снижение размера окна управления для потока

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

После отправки кадра SETTINGS, уменьшающего окно управления потоком данных, получатель может продолжать обработку потоков, выходящих за пределы окна. Это разрешение не позволяет получателю незамедлительно снизить объем доступного для окон управления потоком данных пространства памяти. Обработка этих потоков может быть «заморожена», поскольку отправителю для продолжения передачи будут требоваться кадры WINDOW_UPDATE. Получатель может вместо этого передать RST_STREAM с кодом ошибки FLOW_CONTROL_ERROR для соответствующих потоков.

6.10. CONTINUATION

Кадры CONTINUATION (type=0x9) служат для продолжения последовательности фрагментов блока заголовка (параграф 4.3). Может передаваться любое число кадров CONTINUATION, пока такому кадру предшествует кадр HEADERS, PUSH_PROMISE или CONTINUATION без флага END_HEADERS.

+---------------------------------------------------------------+
|                   Header Block Fragment (*)                 ...
+---------------------------------------------------------------+

Рисунок 15. Информация кадра CONTINUATION

Информационное поле кадра CONTINUATION содержит фрагмент блока заголовка (параграф 4.3).

Для кадров CONTINUATION определен один флаг, описанный ниже.

END_HEADERS (0x4)

Установленный бит 2 показывает, что данный кадр завершает блок заголовка (параграф 4.3).

Если флаг END_HEADERS не установлен, за этим кадром должен следовать другой кадр CONTINUATION. Получатель должен в таких случаях считать получение любого другого типа кадра или кадра в другом потоке ошибкой соединения (параграф 5.4.1) типа PROTOCOL_ERROR.

Кадр CONTINUATION меняет состояние соединения, как описано в параграфе 4.3.

Кадры CONTINUATION должны быть привязаны к потокам. Прием кадра CONTINUATION с полем идентификатора потока 0x0 получатель должен считать ошибкой соединения (параграф 5.4.1) типа PROTOCOL_ERROR.

Кадру CONTINUATION должен предшествовать кадр HEADERS, PUSH_PROMISE или CONTINUATION без флага END_HEADERS. Нарушение этого правила получатель должен считать ошибкой соединения (параграф 5.4.1) типа PROTOCOL_ERROR.

7. Коды ошибок

Коды ошибок указываются 32-битовыми полями в кадрах RST_STREAM и GOAWAY для передачи информации о причине ошибки потока или соединения.

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

Определенные в данной спецификации коды ошибок приведены ниже.

NO_ERROR (0x0)

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

PROTOCOL_ERROR (0x1)

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

INTERNAL_ERROR (0x2)

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

FLOW_CONTROL_ERROR (0x3)

Конечная точка обнаружила нарушение ее партнером протокола управления потоком данных.

SETTINGS_TIMEOUT (0x4)

Конечная точка передала кадр SETTINGS, но не получила своевременного отклика (см. параграф 6.5.3. Синхронизация настроек).

STREAM_CLOSED (0x5)

Конечная точка получила кадр после того, как поток был наполовину закрыт (half-closed).

FRAME_SIZE_ERROR (0x6)

Конечная точка получила кадр с неприемлемым размером.

REFUSED_STREAM (0x7)

Конечная точка отвергла поток до выполнения какой-либо прикладной обработки (см. параграф 8.1.4).

CANCEL (0x8)

Используется конечной точкой для индикации того, что поток больше не требуется.

COMPRESSION_ERROR (0x9)

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

CONNECT_ERROR (0xa)

Соединение, организованное по запросу CONNECT (параграф 8.3) было сброшено или аварийно завершено.

ENHANCE_YOUR_CALM (0xb)

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

INADEQUATE_SECURITY (0xc)

Свойства нижележащего транспорта не соответствуют требованиям безопасности (см. параграф 9.2).

HTTP_1_1_REQUIRED (0xd)

Конечная точка требует использования HTTP/1.1 вместо HTTP/2.

Недопустимо запускать какую-либо специальную обработку не известных или не поддерживаемых кодов ошибок. Их можно трактовать, как INTERNAL_ERROR.

8. Обмен сообщениями HTTP

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

Таким образом, спецификации и требования к семантике и содержимому HTTP/1.1 (Semantics and Content) [RFC7231], условным запросам (Conditional Requests) [RFC7232], запросам части документа (Range Requests) [RFC7233], кэшированию (Caching) [RFC7234] и проверке подлинности (Authentication) [RFC7235] остаются применимыми в HTTP/2. Отдельные части синтаксиса сообщений и маршрутизации HTTP/1.1 (Message Syntax and Routing) [RFC7230], типа схем URI для HTTP и HTTPS также применимы в HTTP/2, но выражение их семантики для этого протокола отличается и описано ниже.

8.1. Обмен запросами и откликами HTTP

Клиент передает запрос HTTP на организацию нового потока, указывая не использованный ранее идентификатор потока (параграф 5.1.1). Сервер передает отклик HTTP с запрошенным идентификатором потока.

Сообщение HTTP (запрос или отклик) включает:

1. отклики (и только они) могут включать один или множество кадров HEADERS (за каждым может следовать один или множество кадров CONTINUATION), содержащих заголовки информационных (1xx) откликов HTTP (см. параграф 3.2 в [RFC7230] и параграф 6.2 в [RFC7231]);

2. один кадр HEADERS (за которым может следовать один или множество кадров CONTINUATION), содержащий заголовки сообщения (см. параграф 3.2 в [RFC7230]);

3. может содержать кадры DATA с информационными полями (payload) сообщения (см. параграф 3.3 в [RFC7230]);

4. дополнительно может содержать один кадр HEADERS, за которым могут следовать кадры CONTINUATION, с трейлерной частью (trailer-part), если она имеется (см. параграф 4.1.2 в [RFC7230]).

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

Другие кадры (из любого потока) недопустимо помещать между кадром HEADERS и следующими за ним кадрами CONTINUATION.

HTTP/2 использует кадры DATA для передачи информационного содержимого сообщений. В HTTP/2 недопустимо использовать описанное в параграфе 4.1 [RFC7230] chunked-кодирование передачи.

Трейлерный (задние) поля заголовка передаются в блоке заголовка, который также завершает поток. Текой блок заголовка представляет собой последовательность, начинающуюся с кадра HEADERS, за которым может следовать один или несколько кадров CONTINUATION, при этом кадр HEADERS включает флаг END_STREAM. Блоки заголовка после первого, которые не завершают поток, не являются частью запроса или отклика HTTP.

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

Обмен HTTP запрос-отклик полностью занимает один поток. Запрос начинается с кадра HEADERS, который переводит поток в состояние open. Завершается запрос кадром с флагом END_STREAM, который переводит поток в состояние half-closed (local) для клиента и half-closed (remote) для сервера. Отклик начинается с кадра HEADERS и завершается кадром с флагом END_STREAM, который переводит поток в состояние closed .

Отклик HTTP завершается после того, как сервер передаст (или клиент получит) кадр с флагом END_STREAM (включая все кадры CONTINUATION, требуемые для завершения блока заголовка). Сервер может передать полный отклик до того, как клиент полностью передаст запрос, если отклик не зависит от какой-либо части запроса, которая еще не передана и не получена. Когда это справедливо, сервер может запросить у клиента прерывание запроса без ошибки путем отправки RST_STREAM с кодом NO_ERROR после передачи всего отклика (т. е., кадра с флагом END_STREAM). Клиенту недопустимо отбрасывать отклики в результате получения RST_STREAM, хотя клиент всегда может по своему разумению отбрасывать отклики в связи с другими причинами.

8.1.1. Обновление HTTP/2

HTTP/2 прекращает поддержку информационного кода состояния 101 (Switching Protocols), описанного в параграфе 6.2.2 [RFC7231].

Семантика кода 101 не применима к протоколам с мультиплексированием. Другие протоколы способны применять те же механизмы, которые в протоколе HTTP/2 служат для согласования его использования (см. параграф 3).

8.1.2. Поля заголовка HTTP

Информация в полях заголовка HTTP представляется в форме последовательности пар «ключ — значение» (key-value). Список зарегистрированных полей заголовков HTTP можно найти в реестре Message Header Field, доступном по ссылке https://www.iana.org/assignments/message-headers.

Как и в HTTP/1.x, имена полей заголовка представляются строками символов ASCII, которые сравниваются без учета регистра символов. Однако при кодировании в HTTP/2 имена полей заголовка должны приводиться к нижнему регистру. Запросы и отклики, содержащие заглавные буквы в именах полей заголовков, должны считаться некорректно сформированными (параграф 8.1.2.6).

8.1.2.1. Поля псевдозаголовка

Хотя в HTTP/1.x используется стартовая строка сообщения (см. параграф 3.1 в [RFC7230]) для передачи целевого идентификатора URI, метода запроса и кода состояния в отклике, в для этого HTTP/2 служат специальные поля псевдозаголовка, начинающиеся с символа двоеточия («:», ASCII 0x3a).

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

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

Все поля псевдозаголовка должны размещаться в блоке заголовка до обычных полей заголовка. Любые запросы и отклики с полями псевдозаголовка после полей обычного заголовка должны считаться ошибкой форматирования (параграф 8.1.2.6).

8.1.2.2. Поля заголовка, относящиеся к соединению

HTTP/2 не использует поле заголовка Connection для индикации связанных с соединением полей заголовка, в этом протоколе относящиеся к соединению метаданные передаются иными способами. Конечный точкам недопустимо создавать сообщение HTTP/2 с относящимися к соединению полями заголовка. При получении сообщения с такими полями оно должно считаться некорректно сформированным (параграф 8.1.2.6).

Единственным исключением является поле TE, которое может присутствовать в заголовках запросов HTTP/2, но в это поле недопустимо включать какие-либо значения кроме trailers.

Это означает, что промежуточные узлы, преобразующие сообщения HTTP/1.x в HTTP/2 должны удалять все поля заголовка, указанные в поле Connection вместе с этим полем. Таким промежуточным узлам следует также удалять все относящиеся к соединению поля заголовка типа Keep-Alive, Proxy-Connection, Transfer-Encoding и Upgrade, даже если они не указаны в поле Connection.

Примечание. HTTP/2 осознанно не поддерживает обновление до других протоколов. Методы согласования, описанные в разделе 3, считаются достаточными для согласования использования дополнительных протоколов.

8.1.2.3. Поля псевдозаголовка запроса

Поля псевдозаголовков, определенные для запросов HTTP/2 перечислены ниже.

• Поле :method включает метод HTTP (раздел 4 [RFC7231]).

• Поле :scheme включает относящуюся к схеме часть целевого идентификатора URI (параграф 3.1 [RFC3986]).

  Значения поля :scheme не ограничиваются схемами http и https для идентификаторов URI. Прокси-серверы и шлюзы могут транслировать запросы для схем, не относящихся к HTTP, позволяя использовать HTTP для взаимодействия с другими (не HTTP) службами.

• Поле :authority включает часть authority идентификатора URI (параграф 3.2 [RFC3986]). Недопустимо включение в это поле отмененной субкомпоненты userinfo для URI со схемой http или https.

  Для обеспечения гарантии точно воспроизведения строки запроса HTTP/1.1 это поле должно опускаться при трансляции запросов HTTP/1.1, в которых цель запроса указана в форме origin или asterisk (см. параграф 5.3 в [RFC7230]). Клиентам, генерирующим запросы HTTP/2 непосредственно, следует использовать поле псевдозаголовка :authority вместо поля заголовка Host. Промежуточные узлы, преобразующие запрос HTTP/2 в HTTP/1.1, должны создавать поле заголовка Host, если его нет в запросе, путем копирования содержимого поля псевдозаголовка :authority.

• Поле :path включает части path и query целевого идентификатора URI (path-absolute и необязательная компонента из символа ? И следующей за ним части query, как описано в параграфах 3.3 и 3.4 [RFC3986]). Запрос в форме звездочки (asterisk) включает символ * для поля псевдозаголовка :path.

  Недопустимо оставлять это поле пустым для идентификаторов URI со схемой http или https. Идентификаторы URI со схемами http и https, не содержащие компоненты path, должны включать значение /. Исключением из этого правила является запрос OPTIONS для http или https URI, который не включает компоненты path. Эти запросы должны включать поле псевдозаголовка :path со значением * (см. параграф 5.3.4 [RFC7230]).

Все запросы HTTP/2, за исключением CONNECT (параграф 8.3), должны включать в точности по одному приемлемому значению для полей псевдозаголовка :method, :scheme и :path. Запросы HTTP с пропущенными обязательными полями псевдозаголовка считаются некорректно сформированными (параграф 8.1.2.6).

HTTP/2 не определяет способа передачи идентификатора версии, который включается в строку запроса HTTP/1.1.

8.1.2.4. Поля псевдозаголовка отклика

Для откликов HTTP/2 определено одно поле псевдозаголовка :status, которое включает код состояния HTTP (см. раздел 6 в [RFC7231]). Это поле должно включаться во все отклики, которые в противном будут считаться некорректно сформированными (параграф 8.1.2.6).

HTTP/2 не определяет способа передачи идентификатора версии, который включается в строку состояния HTTP/1.1.

8.1.2.5. Сжатие поля Cookie в заголовке

В полях заголовка Cookie [COOKIE] используется точка с запятой (;) для разделения cookie-пар (или «крошек» — crumbs). Для этого поля не выполняется правило создания списков в HTTP (см. параграф 3.2.2 в [RFC7230]), что препятствует разбиению cookie-пар на разные пары «имя-значение» (name-value). Это может существенно снижать эффективность сжатия при обновлении отдельных cookie-пар.

Для повышения эффективности сжатия поле заголовка Cookie можно разделить на отдельные поля заголовка, каждое их которых включает одну или множество cookie-пар. Если после декомпрессии имеется множество полей Cookie, они должны быть собраны (конкатенация) в одну строку октетов с двухоктетными разделителями 0x3B, 0x20 (точка с запятой и пробел — строка ASCII «; ») до их передачи в не относящийся к HTTP/2 контекст типа соединения HTTP/1.1 или серверного приложения базового HTTP.

Следовательно приведнные ниже два списка полей Cookie семантически эквивалентны.

     cookie: a=b; c=d; e=f

     cookie: a=b
     cookie: c=d
     cookie: e=f

8.1.2.6. Запросы и отклики с некорректным форматом

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

Запрос или отклик с информационными полями (payload) может включать в заголовок поле размера содержимого. Если значение этого поля не соответствует сумме размеров информационных полей в кадрах DATA с содержимым, такой запрос или отклик считается некорректно сформированным. Отклик, для которого не определены информационные поля, как описано в параграфе 3.3.2 [RFC7230], может иметь отличное от 0 поле размера содержимого даже при отсутствии содержимого в кадрах DATA.

Промежуточным узлам, обрабатывающим запросы или отклики HTTP (т. е., всем промежуточным узлам, не выступающим в качестве туннеля) недопустимо пересылать запросы или отклики, сформированные некорректно. Обнаруженные запросы или отклики этого вида должны считаться ошибкой потока (параграф 5.4.2) типа PROTOCOL_ERROR.

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

8.1.3. Примеры

В этом параграфе приведены запросы и отклики HTTP/1.1 и эквивалентные запросы и отклики HTTP/2.

Запрос HTTP GET включает поля заголовка запроса без информационного элемента в теле и, следовательно, передается в одном кадре HEADERS, за которым могут следовать кадры CONTINUATION, содержащие упорядоченный блок полей заголовка запроса. Приведенный ниже кадр HEADERS имеет флаги END_HEADERS и END_STREAM, а кадры CONTINUATION не передаются.

     GET /resource HTTP/1.1           HEADERS
     Host: example.org          ==>     + END_STREAM
     Accept: image/jpeg                 + END_HEADERS
                                          :method = GET
                                          :scheme = https
                                          :path = /resource
                                          host = example.org
                                          accept = image/jpeg

Подобно этому, отклик, включающий только поля заголовка, передается в кадре HEADERS (за которым также могут следовать кадры CONTINUATION), содержащем упорядоченный блок полей заголовка отклика.

     HTTP/1.1 304 Not Modified        HEADERS
     ETag: "xyzzy"              ==>     + END_STREAM
     Expires: Thu, 23 Jan ...           + END_HEADERS
                                          :status = 304
                                          etag = "xyzzy"
                                          expires = Thu, 23 Jan ...

Запрос HTTP POST, включающий заголовок запроса и информацию (payload), передается в кадре HEADERS, за которым могут следовать кадры CONTINUATION, содержащие поля заголовка запроса, а также следует один или множество кадров DATA. В последнем кадре CONTINUATION (или кадре HEADERS) устанавливается флаг END_HEADERS, а в последнем кадре DATA — флаг END_STREAM.

     POST /resource HTTP/1.1          HEADERS
     Host: example.org          ==>     - END_STREAM
     Content-Type: image/jpeg           - END_HEADERS
     Content-Length: 123                  :method = POST
                                          :path = /resource
     {двоичные данные}                    :scheme = https

                                      CONTINUATION
                                        + END_HEADERS
                                          content-type = image/jpeg
                                          host = example.org
                                          content-length = 123

                                      DATA
                                        + END_STREAM
                                      {двоичные данные}

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

Отклик, включающий поля заголовка и данные (payload) передается в форме кадра HEADERS, за которым могут следовать кадры CONTINUATION, а затем один или множество кадров DATA, в последнем из которых установлен флаг END_STREAM.

     HTTP/1.1 200 OK                  HEADERS
     Content-Type: image/jpeg   ==>     - END_STREAM
     Content-Length: 123                + END_HEADERS
                                          :status = 200
     {двоичные данные}                    content-type = image/jpeg
                                          content-length = 123

                                      DATA
                                        + END_STREAM
                                      {двоичные данные}

Информационные отклики с кодом состояния 1xx, отличным от 101, передаются в форме кадра HEADERS, за которым могут следовать кадры CONTINUATION.

Трейлерные поля заголовка передаются в виде блока заголовка после блока заголовка запроса или отклика и всех кадров DATA. Кадры HEADERS с трейлерным блоком заголовка имеют флаг END_STREAM.

Приведенный ниже пример включает код состояния 100 (Continue), который передается в откликах на запросы с маркером 100-continue в поле заголовка Expect, и трейлерные поля заголовка.

     HTTP/1.1 100 Continue            HEADERS
     Extension-Field: bar       ==>     - END_STREAM
                                        + END_HEADERS
                                          :status = 100
                                          extension-field = bar

     HTTP/1.1 200 OK                  HEADERS
     Content-Type: image/jpeg   ==>     - END_STREAM
     Transfer-Encoding: chunked         + END_HEADERS
     Trailer: Foo                         :status = 200
                                          content-length = 123
     123                                  content-type = image/jpeg
     {двоичные данные}                    trailer = Foo
     0
     Foo: bar                         DATA
                                        - END_STREAM
                                      {двоичные данные}

                                      HEADERS
                                        + END_STREAM
                                        + END_HEADERS
                                          foo = bar

8.1.4. Механизмы обеспечения надежности для запросов HTTP/2

В HTTP/1.1 клиент HTTP не способен повторить неидемпотентный запрос при возникновении ошибки, поскольку у него нет способа определения причины ошибки. До возникновения ошибки на сервере могла быть выполнена некоторая обработка и повторный запроса моет привести к нежелательным эффектам.

HTTP/2 обеспечивает два механизма предоставления клиенту гарантии того, что запрос не был обработан:

• кадр GOAWAY показывает наибольший номер потока, который мог быть обработан, поэтому для запроса с большим номером гарантируется безопасность повтора;

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

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

Серверу недопустимо указывать, что поток не обработан, пока он не может этот факт гарантировать. Если кадры потока переданы прикладному уровню для любого потока, для этого потока недопустимо использовать REFUSED_STREAM, а кадр GOAWAY должен включать идентификатор потока, который не меньше идентификатора данного потока.

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

8.2. Выталкивание на сервере

HTTP/2 позволяет серверам отправлять с упреждением (или «выталкивать» — push) отклики (вместе с соответствующими «ожидаемыми» — promised — запросами), связанные с предыдущим запросом этого клиента. Это может быть полезно в тех случаях, когда сервер знает о наличии у него откликов для полного ответа на исходный запрос.

Клиент может запросить отключение выталкивания на сервере, однако это нужно независимо согласовывать для каждого этапа пересылки (hop). Для индикации запрета выталкивания служит установка SETTINGS_ENABLE_PUSH = 0.

Ожидаемые запросы должны быть кэшируемыми (см. параграф 4.2.3 в [RFC7231]), должны быть безопасными (см. параграф 4.2.1 в [RFC7231]) и в них недопустимо включать тело запроса. Клиент, получающий ожидаемый запрос, который не является кэшируемым является заведомо небезопасным или указывает наличие тела запроса, должен сбросить предложенный (promised) поток с ошибкой потока (параграф 5.4.2) типа PROTOCOL_ERROR. Отметим, что это может приводить к сбросу предложенного потока, если клиент не считает недавно определенный метод безопасным.

Вытолкнутые сервером отклики, которые являются кэшируемыми (см. раздел 3 в [RFC7234]), могут сохраняться клиентами, реализующими HTTP-кэш. Вытолкнутые отклики считаются в должной мере проверенными на сервере-источнике (например, если присутствует директива no-cache, как описано в параграфе 5.2.2 [RFC7234]), пока поток, указанный идентификатором предложенного потока, остается открытым.

Некэшируемые вытолкнутые отклики недопустимо сохранять в каком-либо кэше HTTP. Их можно сделать доступными приложению отдельным способом.

Сервер должен включать значение в поле псевдозаголовка :authority, для которого сервер является полномочным (см. параграф 10.1). Клиент должен трактовать PUSH_PROMISE, для которого сервер не является полномочным, как ошибку потока (параграф 5.4.2) типа PROTOCOL_ERROR.

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

Клиент не может использовать выталкивания. Поэтому сервер, получивший кадр PUSH_PROMISE, должен считать это ошибкой соединения (параграф 5.4.1) типа PROTOCOL_ERROR. Клиенты должны отвергать любые попытки изменить установку для SETTINGS_ENABLE_PUSH отличных от нуля значений, трактуя сообщение как ошибку соединения (параграф 5.4.1) типа PROTOCOL_ERROR.

8.2.1. Запросы на выталкивание

Выталкивание на сервере семантически эквивалентно ответу сервера на запрос, однако в этом случае сам запрос также передает сервер в форме кадра PUSH_PROMISE.

Кадр PUSH_PROMISE включает блок заголовка, содержащий полный набор полей заголовков запроса, которые сервер присваивает этому запросу. Невозможно вытолкнуть отклик на запрос, включающий тело запроса (request body).

Обещанные⁹ запросы всегда связываются с явным запросом от клиента. Кадры PUSH_PROMISE, передаваемые сервером, отправляются в поток такого явного запроса. Кадр PUSH_PROMISE включает также обещанный (promised) идентификатор потока, который выбирается из доступных серверу идентификаторов потоков (см. параграф 5.1.1).

Поля заголовка в PUSH_PROMISE и любых последующих кадрах CONTINUATION должны быть действительным и полным набором полей заголовка запроса (параграф 8.1.2.3). Сервер должен включить в поле псевдозаголовка :method действительный и безопасный метод. Если клиент получает PUSH_PROMISE без действительного и полного набора полей или поле псевдозаголовка :method не является безопасным, он должен указать в ответе ошибку потока (параграф 5.4.2) типа PROTOCOL_ERROR.

Серверу следует передавать кадры PUSH_PROMISE (параграф 6.6) до отправки каких-либо кадров, ссылающихся на обещанные (promised) отклики. Это позволяет избежать ситуаций ввода клиентом запроса до получения каких-либо кадров PUSH_PROMISE.

Например, если сервер получает запрос на документ, содержащий встроенные ссылки на множество файлов с изображениями, и сервер решил «вытолкнуть» эти дополнительные изображения клиенту, отправка кадров PUSH_PROMISE до передачи кадров DATA, содержащих ссылки на эти изображения, гарантирует, что клиент может узнать о выталкивании ресурсов до того, как обнаружит ссылки на них. Аналогично, если сервер выталкивает отклики, упомянутые в блоке заголовка (например, в полях заголовка Link), отправка PUSH_PROMISE до передачи блока заголовка гарантирует, что клиент не будет запрашивать эти ресурсы.

Передача кадров PUSH_PROMISE клиентом недопустима.

Кадры PUSH_PROMISE могут передаваться сервером в отклике на любой инициированный клиентом поток, но поток должен находиться в состоянии open или half-closed (remote) по отношению к серверу. Кадры PUSH_PROMISE чередуются с кадрами, которые содержат ответ, но они не могут чередоваться с кадрами HEADERS и CONTINUATION, которые содержат один блок заголовка.

Отправка кадра PUSH_PROMISE создает новый поток и переводит его в состояние reserved (local) для сервера и reserved (remote) для клиента.

8.2.2. Отклики Push

После отправки кадра PUSH_PROMISE сервер может начать доставку вытолкнутого отклика как отклика (параграф 8.1.2.4) в инициированном сервером потоке, который использует обещанный идентификатор потока. Сервер использует этот поток для передачи отклика HTTP, используя последовательность кадров, определенную в параграфе 8.1. Этот поток становится «полузакрытым» для клиента (параграф 5.1) после передачи начального кадра HEADERS.

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

Если клиент по какой-либо причине принимает решение о нежелании получать выталкиваемые сервером отклики или сервер слишком долго не начинает отправку обещанного отклика, клиент может передать кадр RST_STREAM с кодом CANCEL или REFUSED_STREAM и указанием идентификатора выталкиваемого потока.

Клиент может использовать параметр SETTINGS_MAX_CONCURRENT_STREAMS для ограничения числа откликов, которые будут одновременно выталкиваться сервером. Анонсирование SETTINGS_MAX_CONCURRENT_STREAMS = 0 запрещает серверу выталкивать отклики, предотвращая создание ненужных потоков. Это не запрещает серверу передавать кадры PUSH_PROMISE; клиенты должны сбрасывать нежелательные потоки.

Клиенты, получающие вытолкнутый отклик, должны проверить полномочность сервера (см. параграф 10.1) или разрешение прокси, предоставившему такой отклик, выполнять эту операцию для соответствующего запроса. Например, серверу, который предоставляет сертификат лишь для example.com DNS-ID или Common Name, не разрешено выталкивать отклик для https://www.example.org/doc.

Отклик для потока PUSH_PROMISE начинается с кадра HEADERS, который сразу переводит поток в состояние half-closed (remote) для сервера и half-closed (local) для клиента, и завершается кадром с END_STREAM, который переводит поток в состояние closed.

Примечание. Клиент никогда не передает кадров с флагом END_STREAM для «серверного выталкивания».

8.3. Метод CONNECT

В HTTP/1.x используется псевдометод CONNECT ([RFC7231], параграф 4.3.6) для преобразования соединения HTTP в туннель к удаленному хосту. CONNECT применяется в основном HTTP для организации сессии TLS с исходным сервером при взаимодействии с ресурсами https.

В HTTP/2 метод CONNECT служит для организации туннеля с удаленным хостом через один поток HTTP/2 с похожими целями. Отображение поля заголовка HTTP работает в соответствии с описанием параграфа «8.1.2.3. Поля псевдозаголовка запроса» с некоторыми отличиями, указанными ниже.

• В поле псевдозаголовка :method устанавливается значение CONNECT.

• Поля псевдозаголовка :scheme и :path должны быть опущены.

• Поле псевдозаголовка :authority указывает хост и порт для соединения (эквивалент authority-form в request-target запросов CONNECT, см. параграф 5.3 в [RFC7230]).

Запрос CONNECT, не соответствующий этим ограничениям, считается некорректно сформированным (параграф 8.1.2.6).

Прокси, поддерживающие метод CONNECT, организуют соединение TCP [TCP] с сервером, указанным полем псевдозаголовка :authority. После организации соединения прокси передает клиенту кадр HEADERS с кодом состояния 2xx, как определено в параграфе 4.3.6 [RFC7231].

После начальных кадров HEADERS, переданных каждым партнером, все последующие кадры DATA соответствуют данным, отправленным в соединение TCP. Данные из всех кадров DATA, отправленных клиентом, передаются посредником серверу TCP, а данные от сервера TCP собираются посредником в кадры DATA. Типы кадров, отличающиеся от DATA и кадров управления потоком (RST_STREAM, WINDOW_UPDATE и PRIORITY) недопустимо передавать в подключенный поток и при получении они должны считаться ошибками потока (параграф 5.4.2).

Соединение TCP может быть закрыто любым из партнеров. Флаг END_STREAM в кадре DATA считается эквивалентом бита TCP FIN. Предполагается, что клиент передает кадр DATA с флагом END_STREAM после приема кадра, содержащего флаг END_STREAM. Прокси, получивший кадр DATA с флагом END_STREAM, передает присоединенные данные с флагом FIN в последнем сегменте TCP. Прокси, получивший сегмент TCP с флагом FIN, передает кадр DATA с флагом END_STREAM. Отметим, что заключительный сегмент TCP или кадр DATA может быть пустым.

Ошибки соединения TCP указываются с помощью RST_STREAM. Прокси считает любую ошибку в соединении TCP, где принят сегмент с установленным битом RST, ошибкой потока (параграф 5.4.2) типа CONNECT_ERROR. Поэтому прокси должен передавать сегмент TCP с флагом RST при обнаружении ошибки потока или соединения HTTP/2.

9. Дополнительные требования HTTP

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

9.1. Управление соединением

Соединения HTTP/2 являются постоянными. Для повышения производительности предполагается, что клиенты не будут закрывать соединения, пока не решат, что сервер больше не нужен (например, уход с конкретной web-страницы) или сервер сам не закроет соединение.

Клиентам не следует открывать более одного соединения HTTP/2 для данной пары хоста и номера порта, где хост выводится из URI, выбранной альтернативной службы [ALT-SVC] или настроенного прокси.

Клиент может создавать дополнительные соединения на замену, вместо соединений, у которых заканчивается пространство доступных идентификаторов потоков (параграф 5.1.1), для обновления ключевого материала соединения TLS или взамен соединения, где возникли ошибки (параграф 5.4.1).

Клиент может открыть несколько соединений с одним адресом IP и портом TCP, используя разные значения SNI¹⁰ [TLS-EXT] для получения разных сертификатов TLS, но следует избегать создания нескольких соединений с одинаковой конфигурацией.

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

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

Соединения, организованные с исходным сервером напрямую или через туннель, созданный с помощью метода CONNECT (параграф 8.3), можно использовать повторно для запросов с множеством разных компонент URI authority. Повторное соединение может применяться, пока исходный сервер остается полномочным (параграф 10.1). Для соединений TCP без TLS это зависит от наличия хоста с именем, преобразующимся в такой же адрес IP.

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

Исходный сервер может представить сертификат с множеством атрибутов или имен subjectAltName с шаблонами, один из которых действует для полномочий (authority) из URI. Например, сертификат с subjectAltName = *.example.com может разрешить использование того же соединения для запроса URI, начинающегося с https://a.example.com/ или https://b.example.com/.

В некоторых случаях повторное использование соединения для разных источников может приводить к передаче запроса неподходящему исходному серверу. Например, промежуточное устройство может разорвать соединение TLS, если это устройство применяет расширение TLS SNI [TLS-EXT] для выбора исходного сервера. Это означает, что клиент может отправить конфиденциальную информацию серверу, который не предполагался целью запроса, хотя этот сервер и является полномочным.

Сервер, не желающий разрешать клиентам повторные соединения, может указать, что он не является полномочным для запроса, путем отправки кода 421 (Misdirected Request) в ответе на запрос (см. параграф 9.1.2).

Клиент, настроенный на использование прокси через HTTP/2, направляет запросы этому посреднику через одно соединение, т. е. все запросы, передаваемые через прокси, используют одно соединение с посредником.

9.1.2. Код состояния 421 (ошибочно направленный запрос)

Код 421 (Misdirected Request — ошибочно направленный запрос) указывает, что запрос был направлен на сервер, не способный создать отклик. Этот код может быть передан сервером, не настроенным на передачу откликов для комбинации scheme и authority, включенных в URI запроса¹¹.

Клиент, получивший код 421 от сервера может повторить запрос (в зависимости от того, является ли метод запроса идемпотентным) через другое соединение. Это возможно при повторном использовании соединения (параграф 9.1.1) или при выборе другого сервиса [ALT-SVC].

Этот код состояния недопустимо генерировать прокси.

9.2. Использование возможностей TLS

Реализации HTTP/2 должны применять TLS версии 1.2 [TLS12] или выше при работе HTTP/2 через TLS. Следует выполнять общие рекомендации по использованию TLS [TLSBCP] с дополнительными ограничениями, присущими HTTP/2.

Реализация TLS должна поддерживать расширение SNI [TLS-EXT] для TLS. Клиенты HTTP/2 должны указывать имя целевого домена при согласовании TLS.

От систем HTTP/2, согласующих TLS 1.3 и выше, требуется лишь поддержка использования расширения SNI, для систем TLS 1.2 имеются дополнительные требования, приведенные в следующих параграфах. Реализациям настоятельно рекомендуется применять по умолчанию соответствующие параметры, но в конечном итоге система сама отвечает за соответствие требованиям.

9.2.1. Возможности TLS 1.2

В этом параграфе описаны ограничения набора функций TLS 1.2, которые могут быть применены в HTTP/2. Из-за ограничений развертываемых систем отказы при согласовании TLS могут быть не возможны, если не выполняются приведенные здесь ограничения. Конечная точка может незамедлительно разорвать соединение HTTP/2, в котором не выполняются эти требования TLS, с возвратом ошибки соединения (параграф 5.4.1) типа INADEQUATE_SECURITY.

В системах HTTP/2 на основе TLS 1.2 сжатие должно быть отключено. Компрессия TLS может приводить к раскрытию информации, которая в иных условиях не была бы раскрыта [RFC3749]. Базовая компрессия не нужна, поскольку HTTP/2 обеспечивает функции сжатия, которые лучше осведомлены о контексте и поэтому больше подходят для использования в целях повышения производительности, безопасности или улучшения иных свойств.

Системы HTTP/2 на основе TLS 1.2 должны запрещать повторное согласование. Конечная точка должна трактовать повторное согласование TLS как ошибку соединения (параграф 5.4.1) типа PROTOCOL_ERROR. Отметим, что запрет повторного согласования может приводить к возникновению долгоживущих, не используемых соединений по причине ограничения числа сообщений, разрешенных для шифрования базовому шифронабору.

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

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

Реализации должны поддерживать обмен эфемерными ключами размером не менее 2048 битов для шифров, использующих эфемерное конечное поле DHE¹² [TLS12], и 224 битов для шифров, использующих эфемерные эллиптические кривые ECDHE¹³ [RFC4492]. Клиенты должны воспринимать DHE размером до 4096 битов. Конечные точки могут считать согласование ключей, размер которых меньше нижнего предела, как ошибку соединения (параграф 5.4.1) типа INADEQUATE_SECURITY.

9.2.2. Шифры TLS 1.2

В системах HTTP/2 на базе TLS 1.2 не следует использовать какие-либо шифры из числа включенных в «черный список» (Приложение A).

Конечные точки могут возвращать ошибку соединения (параграф 5.4.1) типа INADEQUATE_SECURITY при попытке использования шифров из «черного списка». Системы, выбравшие использование таких шифров, рискуют столкнуться с сообщениями об ошибках, если они не знают, что партнеры воспримут такие шифры.

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

«Черный список» включает шифры, которые в TLS 1.2 являются обязательными, а это означает, что системы TLS 1.2 могут иметь не пересекающиеся наборы разрешенных шифров. Для предотвращения этой проблемы, вызывающей отказы при согласовании TLS, системы HTTP/2, использующие TLS 1.2, должны поддерживать шифр TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] с эллиптической кривой P-256 [FIPS186].

Отметим, что клиенты могут анонсировать поддержку шифров из «черного списка» для возможности соединений с серверами, которые не поддерживают HTTP/2. Это позволяет серверу выбрать HTTP/1.1 с шифром из «черного списка» HTTP/2. Однако это может приводить к согласованию с HTTP/2 с шифром из «черного списка», если прикладной протокол и шифр выбираются независимо.

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

10.1. Полномочия сервера

HTTP/2 опирается на определение полномочий в HTTP/1.1 для решения вопроса о полномочиях сервера предоставлять данный отклик (см. параграф 9.1 в [RFC7230]). Это зависит от локальной трансляции имени в схеме URI «http» и полномочий аутентифицированного сервера для схемы «https» (см. раздел 3 в [RFC2818]).

10.2. Кросспротокольные атаки

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

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

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

Открытая (без шифрования) версия HTTP/2 имеет минимальную защиту от кросспротокольных атак. Префикс соединения (параграф 3.5) содержит строку, предназначенную для того, чтобы запутать серверы HTTP/1.1, но никакой специальной защиты для других протоколов не предусмотрено. Сервер, готовый игнорировать части запроса HTTP/1.1, содержащие поле заголовка Upgrade в дополнение к клиентскому префиксу соединения, может подвергаться кросспротокольным атакам.

10.3. Атаки с промежуточной инкапсуляцией

Кодирование поля заголовка HTTP/2 позволяет указывать имена, которые не являются разрешенными именами полей в синтаксисе сообщений Internet, используемом HTTP/1.1. Запросы и отклики с недопустимыми именами полей должны считаться некорректно сформированными (параграф 8.1.2.6). Поэтому посредник не может транслировать запрос или отклик HTTP/2, содержащий недопустимое имя поля, в сообщение HTTP/1.1.

Аналогично, HTTP/2 разрешает значения полей, которые не действительны. Хотя большинство значений, которые могут быть закодированы, не меняют синтаксический анализ поля заголовка, символы возврата каретки (CR, ASCII 0xd), перевода строки (LF, ASCII 0xa) и nul-символ (NUL, ASCII 0x0) могут использоваться атакующим при дословной трансляции. Любой запрос или отклик с символами, которые не разрешены в поле заголовка, должен считаться некорректно сформированным (параграф 8.1.2.6). Разрешенные символы определены правилом field-content ABNF а параграфе 3.2 [RFC7230].

10.4. Кэшируемость вытолкнутых откликов

Выталкиваемые отклики не имеют явного запроса от клиента, запрос предоставляется сервером в кадре PUSH_PROMISE.

Кэширование вытолкнутых откликов возможно на основе рекомендаций, представленных исходным сервером в поле заголовка Cache-Control. Однако при этом могут возникать проблемы, если на одном серверном хосте имеется несколько арендаторов. Например, сервер может предлагать каждому из множества пользователей небольшую часть своего пространства URI.

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

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

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

Соединению HTTP/2 для работы может потребоваться больше ресурсов, нежели соединению HTTP/1.1. Использование сжатия заголовков и управления потоком данных зависит от выделения ресурсов для сохранения большего числа состояний. Настройки этих функций гарантируют строгое ограничение выделяемой памяти.

Число кадров PUSH_PROMISE таким способом не ограничивается. Клиентам, воспринимающим выталкивание от сервера, следует ограничить число потоков, которым разрешено находиться в состоянии reserved (remote). Избыточное число выталкиваемых сервером потоков может считаться ошибкой потока (параграф 5.4.2) типа ENHANCE_YOUR_CALM.

Возможности обработки не могут ограничиваться так же эффективно, как возможности хранения состояний.

Кадры SETTINGS могут использоваться для принуждения партнера затрачивать на обработку дополнительное время. Это можно сделать путем бессмысленного изменения параметров SETTINGS, установки множества неопределенных параметров или многократного изменения одного и того же параметра в кадре. Кадры WINDOW_UPDATE или PRIORITY могут быть использованы для принуждения к ненужному расходу ресурсов.

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

Сжатие заголовков также позволяет потерю ресурсов на обработку. Возможные варианты злоупотреблений сжатием описаны в разделе 7 [COMPRESSION].

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

Все эти возможности — изменение SETTINGS, мелкие кадры, сжатие заголовков — могут применяться легитимно. Они создают угрозы лишь при ненужном или чрезмерном использовании.

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

10.5.1. Ограничения размера блока заголовков

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

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

Сервер, который получает блок заголовков с размером больше, чем он готов обрабатывать, может передать отклик HTTP 431 (Request Header Fields Too Large) [RFC6585]. Клиент может отбрасывать отклики, которые он не способен обработать. Блок заголовков должен обрабатываться для поддержки согласованного состояния соединения, пока соединение не закрыто.

10.5.2. Проблемы CONNECT

Метод CONNECT позволяет создать непропорциональную нагрузку на прокси, поскольку создание потоков является «недорогим» в сравнении с созданием и поддержкой соединений TCP. Прокси-сервер может также поддерживать некоторые ресурсы соединения TCP после закрытия потока, который передает запрос CONNECT, поскольку исходящее соединение TCP остается в состоянии TIME_WAIT. В результате прокси не может ограничивать ресурсы, потребляемые запросами CONNECT, на основании SETTINGS_MAX_CONCURRENT_STREAMS.

10.6. Использование сжатия

Компрессия может позволить атакующему восстановить секретные данные, которые были сжаты в одном контексте с данными, контролируемыми злоумышленником. HTTP/2 позволяет сжимать поля заголовков (параграф 4.3) и рассмотренные ниже проблемы присущи также к использованию сжатого кодирования содержимого HTTP (см. параграф 3.1.2.1 в [RFC7231]).

Имеются очевидные атаки на компрессию, использующие характеристики web (например, [BREACH]). Атакующий инициирует множество запросов, содержащих разный открытый текст, наблюдая размер полученного шифрованного текста, который будет короче при корректном предположении о секрете.

Реализациям, взаимодействующим по защищенному каналу, недопустимо совместно сжимать содержимое конфиденциальных и контролируемых атакующим данных, если для каждого источника данных не применяется отдельный словарь. Недопустимо применять сжатие, если источник данных не может быть надежно определен. Базовое сжатие потока, например, обеспечиваемое TLS, недопустимо применять с HTTP/2 (см. параграф 9.2).

Дополнительное рассмотрение вопросов, связанных со сжатием полей заголовков, приведено в [COMPRESSION].

10.7. Использование заполнения

Заполнение в HTTP/2 не предназначено для замены заполнений «общего назначения», таких как в TLS [TLS12]. Избыточное заполнение может даже быть контрпродуктивным. Корректность использования заполнения может зависеть от информации о дополняемых данных.

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

Заполнение может служить для сокрытия точного размера содержимого кадра и применяться для смягчения некоторых типичных для HTTP атак, например, атак, где сжатое содержимое включает контролируемые злоумышленником открытые данные вместе с секретной информацией (например, [BREACH]).

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

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

10.8. Вопросы приватности

Некоторые характеристики HTTP/2 предоставляют наблюдателю возможность сопоставить действия одного клиента или сервера в течение временного интервала. Это включает значения параметров, способ управления окнами контроля потока данных, способы указания приоритета для потоков, время реакции на «раздражители» и обработку любых свойств, управляемых параметрами.

Наблюдая различия в поведении, злоумышленник может создать «отпечатки» для каждого клиента, как указано в параграфе 1.8 [HTML5].

Предпочтение HTTP/2 использовать единственное соединение TCP позволяет сопоставить активность пользователей на сайте. Повторное использование соединений для разных источников позволяет отслеживать эти источники.

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

11. Согласование с IANA

Добавляется строка идентификации протокола HTTP/2 в реестр «Application-Layer Protocol Negotiation (ALPN) Protocol Ids», организованный [TLS-ALPN].

Этот документ организует реестры для типов кадров, параметров и кодов ошибок, представленные ниже.

Этот документ регистрирует поле заголовка HTTP2-Settings для использования в HTTP, а также код состояния 421 (Misdirected Request).

Документ регистрирует метод PRI для использования в HTTP с целью предотвращения конфликтов с префиксами соединений (параграф 3.5).

11.1. Регистрация идентификационных строк HTTP/2

Этот документ определяет две регистрации для идентификации протокола HTTP/2 (см. параграф 3.3) в реестре «Application-Layer Protocol Negotiation (ALPN) Protocol Ids», организованном [TLS-ALPN].

Строка «h2» указывает использование HTTP/2 на базе TLS.

Protocol:  HTTP/2 over TLS
Identification Sequence:  0x68 0x32 ("h2")
Specification:  This document

Строка «h2c» указывает использование HTTP/2 на базе TCP без шифрования.

Protocol:  HTTP/2 over TCP
Identification Sequence:  0x68 0x32 0x63 ("h2c")
Specification:  This document

11.2. Реестр типов кадров

Этот документ организует реестр типов кадров HTTP/2. Реестр «HTTP/2 Frame Type» содержит 8-битовые значения, выделяемые по процедуре «IETF Review» или «IESG Approval» [RFC5226] для диапазона значений 0x00 — 0xef. Диапазон 0xf0 — 0xff зарезервирован для экспериментов (Experimental Use).

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

Frame Type:  Имя или метка для типа кадров.
Code:  8-битовый код, выделенный для типа кадра.
Specification:  Ссылка на спецификацию, включающую описание схемы кадра, его семантику и используемые флаги, которые присутствуют в зависимости от значения типа флага.

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

 

Тип кадра	Код	Параграф
DATA	0x0	6.1
HEADERS	0x1	6.2
PRIORITY	0x2	6.3
RST_STREAM	0x3	6.4
SETTINGS	0x4	6.5
PUSH_PROMISE	0x5	6.6
PING	0x6	6.7
GOAWAY	0x7	6.8
WINDOW_UPDATE	0x8	6.9
CONTINUATION	0x9	6.10

 

11.3. Реестр параметров

Этот документ организует реестр параметров HTTP/2. Реестр «HTTP/2 Settings» содержит 16-битовые значения, выделяемые по процедуре «Expert Review» [RFC5226] из диапазона 0x0000 — 0xefff. Значения 0xf000 — 0xffff зарезервированы для экспериментов (Experimental Use).

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

Name:  Символьное имя параметра (необязательно).
Code:  16-битовый код параметра.
Initial Value:  Начальное значение параметра.
Specification:  Необязательная ссылка на спецификацию, описывающую параметр.

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

 

Имя	Код	Начальное значение	Спецификация
HEADER_TABLE_SIZE	0x1	4096	Параграф 6.5.2
ENABLE_PUSH	0x2	1	Параграф 6.5.2
MAX_CONCURRENT_STREAMS	0x3	(бесконечность)	Параграф 6.5.2
INITIAL_WINDOW_SIZE	0x4	65535	Параграф 6.5.2
MAX_FRAME_SIZE	0x5	16384	Параграф 6.5.2
MAX_HEADER_LIST_SIZE	0x6	(бесконечность)	Параграф 6.5.2

 

11.4. Реестр кодов ошибок

Этот документ организует реестр кодов ошибок для HTTP/2. Реестр «HTTP/2 Error Code» содержит 32-битовые значения кодов и пополняется на основе процедуры «Expert Review» [RFC5226].

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

В новых регистрациях рекомендуется указывать приведенную ниже информацию.

Name:  Имя для кода ошибки. Задание имен для ошибок не является обязательным.
Code:  32-битовый код ошибки.
Description:  Краткое описание семантики кода (более подробное, если спецификации нет). 
Specification:  Необязательная ссылка на спецификацию, определяющую код ошибки.

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

Имя	Код	Описание	Спецификация
NO_ERROR	0x0	Аккуратное завершение	Раздел 7
PROTOCOL_ERROR	0x1	Обнаружена протокольная ошибка	Раздел 7
INTERNAL_ERROR	0x2	Отказ реализации	Раздел 7
FLOW_CONTROL_ERROR	0x3	Превышение предела, заданного для управления потоком данных	Раздел 7
SETTINGS_TIMEOUT	0x4	Установки не подтверждены	Раздел 7
STREAM_CLOSED	0x5	Получен кадр для закрытого потока	Раздел 7
FRAME_SIZE_ERROR	0x6	Некорректный размер кадра	Раздел 7
REFUSED_STREAM	0x7	Поток не обработан	Раздел 7
CANCEL	0x8	Поток прерван	Раздел 7
COMPRESSION_ERROR	0x9	Состояние компрессии не обновлено	Раздел 7
CONNECT_ERROR	0xa	Ошибка соединения TCP для метода CONNECT	Раздел 7
ENHANCE_YOUR_CALM	0xb	Выход за пределы возможностей обработки	Раздел 7
INADEQUATE_SECURITY	0xc	Согласованные параметры TLS не приемлемы	Раздел 7
HTTP_1_1_REQUIRED	0xd	Требуется использовать HTTP/1.1 для запроса	Раздел 7

11.5. Регистрация поля заголовка HTTP2-Settings

Этот документ регистрирует поле заголовка HTTP2-Settings в реестре Permanent Message Header Field Names [BCP90].

Header field name:  HTTP2-Settings
Applicable protocol:  http
Status:  standard
Author/Change controller:  IETF
Specification document(s):  Section 3.2.1 of this document
Related information:  This header field is only used by an HTTP/2
      client for Upgrade-based negotiation.

11.6. Регистрация метода PRI

Этот документ регистрирует метод PRI в реестре HTTP Method Registry, параграф 8.1 [RFC7231].

Method Name:  PRI
Safe:  Yes
Idempotent:  Yes
Specification document(s):  Section 3.5 of this document
Related information:  This method is never used by an actual client.
      This method will appear to be used when an HTTP/1.1 server or
      intermediary attempts to parse an HTTP/2 connection preface.

11.7. Код состояния 421 (Misdirected Request)

Этот документ регистрирует код состояния HTTP 421 (Misdirected Request) в реестре HTTP Status Codes, параграф 8.2 [RFC7231].

Status Code:  421
Short Description:  Misdirected Request
Specification:  Section 9.1.2 of this document

11.8. Обновление маркера h2c

Этот документ регистрирует маркер обновления h2c в реестре HTTP Upgrade Tokens, параграф 8.6 [RFC7230].

Value:  h2c
Description:  Hypertext Transfer Protocol version 2 (HTTP/2)
Expected Version Tokens:  None
Reference:  Section 3.2 of this document

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

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

[COMPRESSION] Peon, R. and H. Ruellan, «HPACK: Header Compression for HTTP/2», RFC 7541, DOI 10.17487/RFC7541, May 2015, <http://www.rfc-editor.org/info/rfc7541>.

[COOKIE] Barth, A., «HTTP State Management Mechanism», RFC 6265, DOI 10.17487/RFC6265, April 2011, <http://www.rfc-editor.org/info/rfc6265>.

[FIPS186] NIST, «Digital Signature Standard (DSS)», FIPS PUB 186-4, July 2013, <http://dx.doi.org/10.6028/NIST.FIPS.186-4>.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2818] Rescorla, E., «HTTP Over TLS», RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.

[RFC4648] Josefsson, S., «The Base16, Base32, and Base64 Data Encodings», RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.

[RFC5234] Crocker, D., Ed. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, DOI 10.17487/ RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.

[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing», RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.

[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content», RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.

[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests», RFC 7232, DOI 10.17487/RFC7232, June 2014, <http://www.rfc-editor.org/info/rfc7232>.

[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Range Requests», RFC 7233, DOI 10.17487/RFC7233, June 2014, <http://www.rfc-editor.org/info/rfc7233>.

[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Caching», RFC 7234, DOI 10.17487/RFC7234, June 2014, <http://www.rfc-editor.org/info/rfc7234>.

[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Authentication», RFC 7235, DOI 10.17487/RFC7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>.

[TCP] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.

[TLS-ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, «Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension», RFC 7301, DOI 10.17487/RFC7301, July 2014, <http://www.rfc-editor.org/info/rfc7301>.

[TLS-ECDHE] Rescorla, E., «TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)», RFC 5289, DOI 10.17487/RFC5289, August 2008, <http://www.rfc-editor.org/info/rfc5289>.

[TLS-EXT] Eastlake 3rd, D., «Transport Layer Security (TLS) Extensions: Extension Definitions», RFC 6066, DOI 10.17487/RFC6066, January 2011, <http://www.rfc-editor.org/info/rfc6066>.

[TLS12] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.2», RFC 5246, DOI 10.17487/ RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.

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

[ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, «HTTP Alternative Services», Work in Progress¹⁴, draft-ietf-httpbis-alt-svc-06, February 2015.

[BCP90] Klyne, G., Nottingham, M., and J. Mogul, «Registration Procedures for Message Header Fields», BCP 90, RFC 3864, September 2004, <http://www.rfc-editor.org/info/bcp90>.

[BREACH] Gluck, Y., Harris, N., and A. Prado, «BREACH: Reviving the CRIME Attack», July 2013, <http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf>.

[HTML5] Hickson, I., Berjon, R., Faulkner, S., Leithead, T., Doyle Navara, E., O’Connor, E., and S. Pfeiffer, «HTML5», W3C Recommendation REC-html5-20141028, October 2014, <http://www.w3.org/TR/2014/REC-html5-20141028/>.

[RFC3749] Hollenbeck, S., «Transport Layer Security Protocol Compression Methods», RFC 3749, DOI 10.17487/RFC3749, May 2004, <http://www.rfc-editor.org/info/rfc3749>.

[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, «Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)», RFC 4492, DOI 10.17487/RFC4492, May 2006, <http://www.rfc-editor.org/info/rfc4492>.

[RFC6585] Nottingham, M. and R. Fielding, «Additional HTTP Status Codes», RFC 6585, DOI 10.17487/RFC6585, April 2012, <http://www.rfc-editor.org/info/rfc6585>.

[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, Ed., «TCP Extensions for High Performance», RFC 7323, DOI 10.17487/RFC7323, September 2014, <http://www.rfc-editor.org/info/rfc7323>.

[TALKING] Huang, L., Chen, E., Barth, A., Rescorla, E., and C. Jackson, «Talking to Yourself for Fun and Profit», 2011, <http://w2spconf.com/2011/papers/websocket.pdf>.

[TLSBCP] Sheffer, Y., Holz, R., and P. Saint-Andre, «Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)», BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.

Приложение A. «Черный список» шифров TLS 1.2

Реализация HTTP/2 может считать согласование любого из перечисленных ниже шифров с TLS 1.2 ошибкой соединения (параграф 5.4.1) типа INADEQUATE_SECURITY:

• TLS_NULL_WITH_NULL_NULL;

• TLS_RSA_WITH_NULL_MD5;

• TLS_RSA_WITH_NULL_SHA;

• TLS_RSA_EXPORT_WITH_RC4_40_MD5;

• TLS_RSA_WITH_RC4_128_MD5;

• TLS_RSA_WITH_RC4_128_SHA;

• TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5;

• TLS_RSA_WITH_IDEA_CBC_SHA;

• TLS_RSA_EXPORT_WITH_DES40_CBC_SHA;

• TLS_RSA_WITH_DES_CBC_SHA;

• TLS_RSA_WITH_3DES_EDE_CBC_SHA;

• TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA;

• TLS_DH_DSS_WITH_DES_CBC_SHA;

• TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA;

• TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA;

• TLS_DH_RSA_WITH_DES_CBC_SHA;

• TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA;

• TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA;

• TLS_DHE_DSS_WITH_DES_CBC_SHA;

• TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA;

• TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA;

• TLS_DHE_RSA_WITH_DES_CBC_SHA;

• TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA;

• TLS_DH_anon_EXPORT_WITH_RC4_40_MD5;

• TLS_DH_anon_WITH_RC4_128_MD5;

• TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA;

• TLS_DH_anon_WITH_DES_CBC_SHA;

• TLS_DH_anon_WITH_3DES_EDE_CBC_SHA;

• TLS_KRB5_WITH_DES_CBC_SHA;

• TLS_KRB5_WITH_3DES_EDE_CBC_SHA;

• TLS_KRB5_WITH_RC4_128_SHA;

• TLS_KRB5_WITH_IDEA_CBC_SHA;

• TLS_KRB5_WITH_DES_CBC_MD5;

• TLS_KRB5_WITH_3DES_EDE_CBC_MD5;

• TLS_KRB5_WITH_RC4_128_MD5;

• TLS_KRB5_WITH_IDEA_CBC_MD5;

• TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA;

• TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA;

• TLS_KRB5_EXPORT_WITH_RC4_40_SHA;

• TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5;

• TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5;

• TLS_KRB5_EXPORT_WITH_RC4_40_MD5;

• TLS_PSK_WITH_NULL_SHA;

• TLS_DHE_PSK_WITH_NULL_SHA;

• TLS_RSA_PSK_WITH_NULL_SHA;

• TLS_RSA_WITH_AES_128_CBC_SHA;

• TLS_DH_DSS_WITH_AES_128_CBC_SHA;

• TLS_DH_RSA_WITH_AES_128_CBC_SHA;

• TLS_DHE_DSS_WITH_AES_128_CBC_SHA;

• TLS_DHE_RSA_WITH_AES_128_CBC_SHA;

• TLS_DH_anon_WITH_AES_128_CBC_SHA;

• TLS_RSA_WITH_AES_256_CBC_SHA;

• TLS_DH_DSS_WITH_AES_256_CBC_SHA;

• TLS_DH_RSA_WITH_AES_256_CBC_SHA;

• TLS_DHE_DSS_WITH_AES_256_CBC_SHA;

• TLS_DHE_RSA_WITH_AES_256_CBC_SHA;

• TLS_DH_anon_WITH_AES_256_CBC_SHA;

• TLS_RSA_WITH_NULL_SHA256;

• TLS_RSA_WITH_AES_128_CBC_SHA256;

• TLS_RSA_WITH_AES_256_CBC_SHA256;

• TLS_DH_DSS_WITH_AES_128_CBC_SHA256;

• TLS_DH_RSA_WITH_AES_128_CBC_SHA256;

• TLS_DHE_DSS_WITH_AES_128_CBC_SHA256;

• TLS_RSA_WITH_CAMELLIA_128_CBC_SHA;

• TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA;

• TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA;

• TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA;

• TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA;

• TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA;

• TLS_DHE_RSA_WITH_AES_128_CBC_SHA256;

• TLS_DH_DSS_WITH_AES_256_CBC_SHA256;

• TLS_DH_RSA_WITH_AES_256_CBC_SHA256;

• TLS_DHE_DSS_WITH_AES_256_CBC_SHA256;

• TLS_DHE_RSA_WITH_AES_256_CBC_SHA256;

• TLS_DH_anon_WITH_AES_128_CBC_SHA256;

• TLS_DH_anon_WITH_AES_256_CBC_SHA256;

• TLS_RSA_WITH_CAMELLIA_256_CBC_SHA;

• TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA;

• TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA;

• TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA;

• TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA;

• TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA;

• TLS_PSK_WITH_RC4_128_SHA;

• TLS_PSK_WITH_3DES_EDE_CBC_SHA;

• TLS_PSK_WITH_AES_128_CBC_SHA;

• TLS_PSK_WITH_AES_256_CBC_SHA;

• TLS_DHE_PSK_WITH_RC4_128_SHA;

• TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA;

• TLS_DHE_PSK_WITH_AES_128_CBC_SHA;

• TLS_DHE_PSK_WITH_AES_256_CBC_SHA;

• TLS_RSA_PSK_WITH_RC4_128_SHA;

• TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA;

• TLS_RSA_PSK_WITH_AES_128_CBC_SHA;

• TLS_RSA_PSK_WITH_AES_256_CBC_SHA;

• TLS_RSA_WITH_SEED_CBC_SHA;

• TLS_DH_DSS_WITH_SEED_CBC_SHA;

• TLS_DH_RSA_WITH_SEED_CBC_SHA;

• TLS_DHE_DSS_WITH_SEED_CBC_SHA;

• TLS_DHE_RSA_WITH_SEED_CBC_SHA;

• TLS_DH_anon_WITH_SEED_CBC_SHA;

• TLS_RSA_WITH_AES_128_GCM_SHA256;

• TLS_RSA_WITH_AES_256_GCM_SHA384;

• TLS_DH_RSA_WITH_AES_128_GCM_SHA256;

• TLS_DH_RSA_WITH_AES_256_GCM_SHA384;

• TLS_DH_DSS_WITH_AES_128_GCM_SHA256;

• TLS_DH_DSS_WITH_AES_256_GCM_SHA384;

• TLS_DH_anon_WITH_AES_128_GCM_SHA256;

• TLS_DH_anon_WITH_AES_256_GCM_SHA384;

• TLS_PSK_WITH_AES_128_GCM_SHA256;

• TLS_PSK_WITH_AES_256_GCM_SHA384;

• TLS_RSA_PSK_WITH_AES_128_GCM_SHA256;

• TLS_RSA_PSK_WITH_AES_256_GCM_SHA384;

• TLS_PSK_WITH_AES_128_CBC_SHA256;

• TLS_PSK_WITH_AES_256_CBC_SHA384;

• TLS_PSK_WITH_NULL_SHA256;

• TLS_PSK_WITH_NULL_SHA384;

• TLS_DHE_PSK_WITH_AES_128_CBC_SHA256;

• TLS_DHE_PSK_WITH_AES_256_CBC_SHA384;

• TLS_DHE_PSK_WITH_NULL_SHA256;

• TLS_DHE_PSK_WITH_NULL_SHA384;

• TLS_RSA_PSK_WITH_AES_128_CBC_SHA256;

• TLS_RSA_PSK_WITH_AES_256_CBC_SHA384;

• TLS_RSA_PSK_WITH_NULL_SHA256;

• TLS_RSA_PSK_WITH_NULL_SHA384;

• TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256;

• TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA256;

• TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA256;

• TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA256;

• TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256;

• TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256;

• TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256;

• TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA256;

• TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA256;

• TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256;

• TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256;

• TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256;

• TLS_EMPTY_RENEGOTIATION_INFO_SCSV;

• TLS_ECDH_ECDSA_WITH_NULL_SHA;

• TLS_ECDH_ECDSA_WITH_RC4_128_SHA;

• TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA;

• TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA;

• TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA;

• TLS_ECDHE_ECDSA_WITH_NULL_SHA;

• TLS_ECDHE_ECDSA_WITH_RC4_128_SHA;

• TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA;

• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA;

• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA;

• TLS_ECDH_RSA_WITH_NULL_SHA;

• TLS_ECDH_RSA_WITH_RC4_128_SHA;

• TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA;

• TLS_ECDH_RSA_WITH_AES_128_CBC_SHA;

• TLS_ECDH_RSA_WITH_AES_256_CBC_SHA;

• TLS_ECDHE_RSA_WITH_NULL_SHA;

• TLS_ECDHE_RSA_WITH_RC4_128_SHA;

• TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA;

• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA;

• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA;

• TLS_ECDH_anon_WITH_NULL_SHA;

• TLS_ECDH_anon_WITH_RC4_128_SHA;

• TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA;

• TLS_ECDH_anon_WITH_AES_128_CBC_SHA;

• TLS_ECDH_anon_WITH_AES_256_CBC_SHA;

• TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA;

• TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA;

• TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA;

• TLS_SRP_SHA_WITH_AES_128_CBC_SHA;

• TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA;

• TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA;

• TLS_SRP_SHA_WITH_AES_256_CBC_SHA;

• TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA;

• TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA;

• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256;

• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384;

• TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256;

• TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384;

• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256;

• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384;

• TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256;

• TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384;

• TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256;

• TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384;

• TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256;

• TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384;

• TLS_ECDHE_PSK_WITH_RC4_128_SHA;

• TLS_ECDHE_PSK_WITH_3DES_EDE_CBC_SHA;

• TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA;

• TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA;

• TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256;

• TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384;

• TLS_ECDHE_PSK_WITH_NULL_SHA;

• TLS_ECDHE_PSK_WITH_NULL_SHA256;

• TLS_ECDHE_PSK_WITH_NULL_SHA384;

• TLS_RSA_WITH_ARIA_128_CBC_SHA256;

• TLS_RSA_WITH_ARIA_256_CBC_SHA384;

• TLS_DH_DSS_WITH_ARIA_128_CBC_SHA256;

• TLS_DH_DSS_WITH_ARIA_256_CBC_SHA384;

• TLS_DH_RSA_WITH_ARIA_128_CBC_SHA256;

• TLS_DH_RSA_WITH_ARIA_256_CBC_SHA384;

• TLS_DHE_DSS_WITH_ARIA_128_CBC_SHA256;

• TLS_DHE_DSS_WITH_ARIA_256_CBC_SHA384;

• TLS_DHE_RSA_WITH_ARIA_128_CBC_SHA256;

• TLS_DHE_RSA_WITH_ARIA_256_CBC_SHA384;

• TLS_DH_anon_WITH_ARIA_128_CBC_SHA256;

• TLS_DH_anon_WITH_ARIA_256_CBC_SHA384;

• TLS_ECDHE_ECDSA_WITH_ARIA_128_CBC_SHA256;

• TLS_ECDHE_ECDSA_WITH_ARIA_256_CBC_SHA384;

• TLS_ECDH_ECDSA_WITH_ARIA_128_CBC_SHA256;

• TLS_ECDH_ECDSA_WITH_ARIA_256_CBC_SHA384;

• TLS_ECDHE_RSA_WITH_ARIA_128_CBC_SHA256;

• TLS_ECDHE_RSA_WITH_ARIA_256_CBC_SHA384;

• TLS_ECDH_RSA_WITH_ARIA_128_CBC_SHA256;

• TLS_ECDH_RSA_WITH_ARIA_256_CBC_SHA384;

• TLS_RSA_WITH_ARIA_128_GCM_SHA256;

• TLS_RSA_WITH_ARIA_256_GCM_SHA384;

• TLS_DH_RSA_WITH_ARIA_128_GCM_SHA256;

• TLS_DH_RSA_WITH_ARIA_256_GCM_SHA384;

• TLS_DH_DSS_WITH_ARIA_128_GCM_SHA256;

• TLS_DH_DSS_WITH_ARIA_256_GCM_SHA384;

• TLS_DH_anon_WITH_ARIA_128_GCM_SHA256;

• TLS_DH_anon_WITH_ARIA_256_GCM_SHA384;

• TLS_ECDH_ECDSA_WITH_ARIA_128_GCM_SHA256;

• TLS_ECDH_ECDSA_WITH_ARIA_256_GCM_SHA384;

• TLS_ECDH_RSA_WITH_ARIA_128_GCM_SHA256;

• TLS_ECDH_RSA_WITH_ARIA_256_GCM_SHA384;

• TLS_PSK_WITH_ARIA_128_CBC_SHA256;

• TLS_PSK_WITH_ARIA_256_CBC_SHA384;

• TLS_DHE_PSK_WITH_ARIA_128_CBC_SHA256;

• TLS_DHE_PSK_WITH_ARIA_256_CBC_SHA384;

• TLS_RSA_PSK_WITH_ARIA_128_CBC_SHA256;

• TLS_RSA_PSK_WITH_ARIA_256_CBC_SHA384;

• TLS_PSK_WITH_ARIA_128_GCM_SHA256;

• TLS_PSK_WITH_ARIA_256_GCM_SHA384;

• TLS_RSA_PSK_WITH_ARIA_128_GCM_SHA256;

• TLS_RSA_PSK_WITH_ARIA_256_GCM_SHA384;

• TLS_ECDHE_PSK_WITH_ARIA_128_CBC_SHA256;

• TLS_ECDHE_PSK_WITH_ARIA_256_CBC_SHA384;

• TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256;

• TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384;

• TLS_ECDH_ECDSA_WITH_CAMELLIA_128_CBC_SHA256;

• TLS_ECDH_ECDSA_WITH_CAMELLIA_256_CBC_SHA384;

• TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256;

• TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384;

• TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256;

• TLS_ECDH_RSA_WITH_CAMELLIA_256_CBC_SHA384;

• TLS_RSA_WITH_CAMELLIA_128_GCM_SHA256;

• TLS_RSA_WITH_CAMELLIA_256_GCM_SHA384;

• TLS_DH_RSA_WITH_CAMELLIA_128_GCM_SHA256;

• TLS_DH_RSA_WITH_CAMELLIA_256_GCM_SHA384;

• TLS_DH_DSS_WITH_CAMELLIA_128_GCM_SHA256;

• TLS_DH_DSS_WITH_CAMELLIA_256_GCM_SHA384;

• TLS_DH_anon_WITH_CAMELLIA_128_GCM_SHA256;

• TLS_DH_anon_WITH_CAMELLIA_256_GCM_SHA384;

• TLS_ECDH_ECDSA_WITH_CAMELLIA_128_GCM_SHA256;

• TLS_ECDH_ECDSA_WITH_CAMELLIA_256_GCM_SHA384;

• TLS_ECDH_RSA_WITH_CAMELLIA_128_GCM_SHA256;

• TLS_ECDH_RSA_WITH_CAMELLIA_256_GCM_SHA384;

• TLS_PSK_WITH_CAMELLIA_128_GCM_SHA256;

• TLS_PSK_WITH_CAMELLIA_256_GCM_SHA384;

• TLS_RSA_PSK_WITH_CAMELLIA_128_GCM_SHA256;

• TLS_RSA_PSK_WITH_CAMELLIA_256_GCM_SHA384;

• TLS_PSK_WITH_CAMELLIA_128_CBC_SHA256;

• TLS_PSK_WITH_CAMELLIA_256_CBC_SHA384;

• TLS_DHE_PSK_WITH_CAMELLIA_128_CBC_SHA256;

• TLS_DHE_PSK_WITH_CAMELLIA_256_CBC_SHA384;

• TLS_RSA_PSK_WITH_CAMELLIA_128_CBC_SHA256;

• TLS_RSA_PSK_WITH_CAMELLIA_256_CBC_SHA384;

• TLS_ECDHE_PSK_WITH_CAMELLIA_128_CBC_SHA256;

• TLS_ECDHE_PSK_WITH_CAMELLIA_256_CBC_SHA384;

• TLS_RSA_WITH_AES_128_CCM;

• TLS_RSA_WITH_AES_256_CCM;

• TLS_RSA_WITH_AES_128_CCM_8;

• TLS_RSA_WITH_AES_256_CCM_8;

• TLS_PSK_WITH_AES_128_CCM;

• TLS_PSK_WITH_AES_256_CCM;

• TLS_PSK_WITH_AES_128_CCM_8;TLS_PSK_WITH_AES_256_CCM_8

Примечание. Этот список создан из множества зарегистрированных шифров TLS на момент подготовки этого документа. Список включает шифры, которые не предлагают обмена эфемерными ключами, а также шифры, основанные на TLS null, потоковом и блочном шифровании (как определено в параграфе 6.2.3 [TLS12]). Могут существовать дополнительные шифры с такими свойствами, они не запрещаются явно.

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

Этот документ включает существенный вклад перечисленных ниже людей.

• Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham, Alyssa Wilk, Costin Manolache, William Chan, Vitaliy Lvin, Joe Chan, Adam Barth, Ryan Hamilton, Gavin Peters, Kent Alstad, Kevin Lindsay, Paul Amer, Fan Yang, и Jonathan Leighton (участники SPDY).

• Gabriel Montenegro и Willy Tarreau (механизм Upgrade).

• William Chan, Salvatore Loreto, Osama Mazahir, Gabriel Montenegro, Jitu Padhye, Roberto Peon и Rob Trace (управление потоком данных).

• Mike Bishop (расширяемость).

• Mark Nottingham, Julian Reschke, James Snell, Jeff Pinner, Mike Bishop и Herve Ruellan (существенные редакторские правки).

• Kari Hurtta, Tatsuhiro Tsujikawa, Greg Wilkins, Poul-Henning Kamp и Jonathan Thackray.

• Alexey Melnikov, который был редактором этого документа в 2013 году.

Существенная часть вклада Martin была поддержана компанией Microsoft, пока он там работал.

Японское сообщество HTTP/2 внесло важный вклад, включая множество реализаций, а также технических и редакторских правок.

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

Mike Belshe

BitGo

EMail: mike@belshe.com

Roberto Peon

Google, Inc

EMail: fenix@google.com

Martin Thomson (редактор)

Mozilla

331 E Evelyn Street

Mountain View, CA 94041

United States

EMail: martin.thomson@gmail.com

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

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

nmalykh@gmail.com

Отменен RFC 9110.

Internet Engineering Task Force (IETF)                 R. Moskowitz, Ed.
Request for Comments: 7401                                HTT Consulting
Obsoletes: 5201                                                  T. Heer
Category: Standards Track              Hirschmann Automation and Control
ISSN: 2070-1721                                                P. Jokela
                                            Ericsson Research NomadicLab
                                                            T. Henderson
                                                University of Washington
                                                              April 2015

Host Identity Protocol Version 2 (HIPv2)

Протокол отождествления хостов версии 2 (HIPv2)

PDF

Аннотация

Этот документ определяет детали протокола отождествления хостов (Host Identity Protocol или HIP). Протокол HIP позволяет соответствующим хостам безопасно организовывать и поддерживать общее состояние уровня IP, что позволяет разделить роли идентификатора и «локатора» для адресов IP, обеспечивая непрерывность связи при смене адреса IP. Протокол HIP основан на обмене ключами Diffie-Hellman с использованием открытых ключей в качестве идентификаторов из нового пространства имён Host Identity для взаимной аутентификации партнёров. Протокол рассчитан на устойчивость а атакам на отказ в обслуживании (denial-of-service или DoS) и перехвату с участием человека (man-in-the-middle или MitM). При использовании с другим подходящим протоколом защиты, таким как ESP (Encapsulating Security Payload), протокол обеспечивает защиту целостности и может обеспечивать шифрование для протоколов вышележащего уровня (например, TCP или UDP).

Этот документ отменяет RFC 5201 и решает отмеченные IESG проблемы, в частности, вопрос гибкости шифрования. Документ также учитывает опыт реализации RFC 5201.

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

Документ относится к категории Internet Standards Track.

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

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

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

Авторские права (Copyright (c) 2015) принадлежат 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. Введение

Этот документ задаёт детали протокола отождествления хостов (HIP). Высокоуровневое описание протокола и его архитектуры HIP представлено в отдельном документе [HIP-ARCH]. Вкратце, архитектура HIP предлагает альтернативу двойному использованию адресов IP как «локаторов» (меток маршрутизации) и «идентификаторов» (обозначения конечных точек — хостов). В HIP применяются открытые ключи или пары ключей (открытый и секретный) в качестве идентификаторов хостов, к которым привязаны вышележащие протоколы вместо адресов IP. Благодаря применению открытых ключей (и их представлений) в качестве идентификаторов хостов, хосты могут напрямую аутентифицировать динамическую смены адресов IP, а при желании можно использовать строгую проверку подлинности между хостами на уровне стека TCP/IP.

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

• «Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)» [RFC7402] описывает применение протокола ESP для защиты целостности и необязательного шифрования.

• «Host Mobility with the Host Identity Protocol» [HIP-HOST-MOB] определяет поддержку мобильности хостов в HIP.

• «Host Identity Protocol (HIP) Domain Name System (DNS) Extension» [HIP-DNS-EXT] определяет расширение DNS для включения данных Host Identity.

• «Host Identity Protocol (HIP) Rendezvous Extension» [HIP-REND-EXT] задаёт использование механизма «встречи» (rendezvous) для связи с мобильными хостами HIP.

С момента разработки базового обмена HIP были достигнуты успехи в криптографии и атаках на криптосистемы, в результате чего потребовалось обеспечить гибкость криптографических протоколов, т. е. возможность переключения с одного криптографического примитива на другой стала частью таких протоколов. Важно поддерживать разумный набор базовых алгоритмов для разных вариантов применения и обеспечить возможность отказа от алгоритмов, для которых были обнаружены уязвимости. Это обновление базового обмена обеспечивает требуемую криптографическую гибкость при борьбе с атаками на понижение, которые становятся возможными в результате гибкости. Кроме того, добавлена поддержка эллиптических кривых с использованием Elliptic Curve DSA (ECDSA) и Elliptic Curve Diffie-Hellman (ECDH).

1.1. Новое пространство имён и идентификаторы

Протокол HIP вводит новое пространство имён Host Identity (отождествление хостов), некоторые аспекты которого рассмотрены в описании архитектуры HIP[HIP-ARCH].

Имеется два основных представления отождествления хоста — полное (Host Identity или HI) и тег отождествления (Host Identity Tag или HIT). HI является открытым ключом и напрямую представляет отождествление хоста. Поскольку имеются разные алгоритмы открытых ключей, использующие разный размер ключа, HI напрямую не подходит в качестве идентификатора пакета или индекса связанных с реализацией структур состояний, требуемых для поддержки HIP. Поэтому применяется хэш от HI или тег отождествления хоста (HIT) в качестве рабочего представления. Тег HIT имеет размер 128 битов и применяется в заголовках HIP и для индексирования соответствующих состояний на конечных хостах. У HIT есть важное свойство защиты — самосертификация (см. 3. Отождествление HI и его структура).

1.2. Базовый обмен HIP (BEX)

Базовый обмен HIP — это двухсторонний криптографический протокол, используемый для организации между хостами коммуникационного контекста. Базовый обмен включает 4 пакета и совместим с SIGMA [KRA03]. Первая сторона обмена называется Инициатором (Initiator), вторая — Ответчиком (Responder). Протокол выполняет обмен ключами Diffie-Hellman (DH) [DIF76] во втором и третьем пакетах, а также аутентифицирует стороны в третьем и четвертом. Применение 4 пакетов повышает устойчивость HIP к DoS-атакам и позволяет Ответчику не устанавливать состояние, пока не будут проверены адрес IP и криптографическая головоломка (puzzle). Ответчик начинает обмен puzzle по втором пакете, а Инициатор завершает его в третьем до того, как ответчик сохранит какое-либо состояние из обмена.

В обмене может применяться вывод DH для шифрования Host Identity Инициатора в третьем пакете (хотя в работе Aura и др. [AUR05] отмечено, что такая операция может мешать работе промежуточных устройств с проверкой пакетов) или Host Identity можно передать без шифрования. Host Identity Ответчика не защищается. Следует отметить, что теги HIT Инициатора и Ответчика передаются в пакетах открыто, что позволяет перехватчику, имеющему сведения о сторонах взаимодействие, идентифицировать их по тегам HIT. Следовательно, шифрование HI любой из сторон не обеспечивает защиты от таких аткак.

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

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

HIP разработан как протокол сквозной аутентификации и организации ключей для использования с ESP [RFC7402] и другими протоколами сквозной защиты. Базовый протокол не охватывает все детали управления правилами, присутствующие в обмене ключами IKE (Internet Key Exchange) [RFC7296] и позволяющие IKE поддерживать сложные правила на шлюзах. Поэтому HIP не является полнофункциональной заменой IKE.

1.3. Структура документа

В разделе 2 определены некоторые ключевые слова, обозначения и термины, применяемые в документе, в разделе 3 определена структура Host Identity и различных представлений. В разделе 4 приведён обзор протокола базового обмена HIP, а разделы 5 и 6 описывают формат пакетов и правила их обработки. В разделах 7, 8 и 9 обсуждаются правила, безопасность и взаимодействие с IANA.

2. Термины и определения

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

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

2.2. Обозначения

[x]

Указывает, что значение x является необязательным.

{x}

Указывает, что значение x является шифрованным.

X(y)

Указывает, что y является параметром X.

<x>i

Указывает, что имеется i элементов x.

—>

Связь от Инициатора к Ответчику (запросы).

<—

Связь от Ответчика к Инициатору (отклики).

|

Объединение (конкатенация).

Ltrunc (H(x), #K)

Указывает #K младших битов результата хэш-функции H от входных данных x.

2.3. Определения

HIP base exchange (BEX) — базовый обмен HIP

Согласование для организации новой ассоциации HIP.

Host Identity (HI) — отождествление хоста

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

Host Identity Tag (HIT) — тег отождествления хоста

Сокращение HI в формате IPv6, создаваемое путём хэширования HI (см. 3.1. Тег отождествления хоста (HIT)).

HIT Suite — комплект HIT

HIT Suite группирует все криптоалгоритмы, которые нужны для генерации и применения HI и его тега HIT. В частности, это 1) алгоритм подписи с открытым ключом, 2) хэш-функция и 3) отсечка (см. Приложение E. HIT Suite и генерация HIT).

HIP association — ассоциация HIP

Общее состояние двух партнёров после завершения BEX.

HIP packet — пакет HIP

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

Initiator — Инициатор

Хост, инициирующий BEX. Эта роль обычно теряется по завершении BEX.

Responder — Ответчик

Хост, отвечающий Инициатору BEX. Эта роль обычно теряется по завершении BEX.

Responder’s HIT hash algorithm (RHASH) — алгоритм хэширования HIT ответчика

Алгоритм хэширования, применяемый в документе для разных расчётов хэш-значений, а также для генерации тега HIT Ответчика. RHASH является хэш-функцией, определяемой HIT Suite тега HIT Ответчика (см. 5.2.10. HIT_SUITE_LIST).

Length of the Responder’s HIT hash algorithm (RHASH_len) — размер вывода алгорита RHASH

Естественный размер вывода RHASH в битах.

Signed data — подписанные данные

Подписанные данные защищаются цифровой подписью, созданной отправителем с применением секретного ключа его HI.

KDF — функция вывода ключей

Функция вывода ключей (Key Derivation Function или KDF) служит для создания симметричных ключей в обмене DH.

KEYMAT — ключевой материал

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

3. Отождествление HI и его структура

В этом разделе рассматриваются свойства Host Identity и Host Identity Tag, а также определяется их точный формат. В протоколе HIP открытый ключ асимметричной пары ключей служит отождествлением хоста HI. Соответственно, сам хост определяется как объект, содержащий секретный ключ пары. Более подробное описание различий между отождествлением и соответствующим идентификатором приведено в документе по архитектуре HIP [HIP-ARCH].

Реализации HIP должны поддерживать алгоритм открытых ключей RSA (Rivest Shamir Adleman) [RSA] и алгоритм ECDSA (Elliptic Curve Digital Signature Algorithm) для генерации HI, как указано в параграфе 5.2.9. Могут также поддерживаться дополнительные алгоритмы.

Хешированное кодирование HI — тег HIT — применяется в протоколах для представления Host Identity. HIT имеет размер 128 битов и три важных свойства: i) размер совпадает с размером адреса IPv6, что позволяет применять его в адресных полях API и протоколов с фиксированным размером, ii) тег сам сертифицирует себя (т. е. по данному HIT сложно расчетным путём найти соответствующий ключ Host Identity) и iii) вероятность совпадения HIT у двух хостов (конфликт) очень мала, поэтому злоумышленнику не удастся найти конфликт с используемым тегом HIT. Более подробное описание свойств безопасности HIT приведено в [HIP-ARCH].

Структура HIT определена в [RFC7343]. HIT — это наложенный маршрутизируемый криптографический хэш-идентификатор (Overlay Routable Cryptographic Hash Identifier или ORCHID), состоящий из 3 частей. Назначаемый IANA префикс служит для того, чтобы отличать теги от адресов IPv6. 4-битовый код указывает алгоритм, применяемый для генерации HI и хэшированного представления HI. Третьей частью является 96-битовое хэш-представление Host Identity. Кодирование алгоритма генерации ORCHID и точный алгоритм генерации хэш-представления заданы в Приложении E и [RFC7343].

Передача HI и HIT в заголовках пакетов пользовательских данных повышает издержки для этих пакетов, поэтому передача указанных значений не предполагается в каждом пакете и применяются иные методы сопоставления пакетов с HI. В некоторых случаях можно применять HIP без дополнительных заголовков в пользвательских пакетах данных. Например, при использовании ESP для защиты трафика данных индекс параметров защиты (Security Parameter Index или SPI) в заголовке ESP может служить для сопоставления защифрованного пакета данных с ассоциацией HIP.

3.1. Тег отождествления хоста (HIT)

128-битовый тег HIT — это хэшированное значение HI. Использование хэшированного представления идентификатора обеспечивает два преимущества по сравнению открытым ключом отождествления хоста, имеющим переменный размер. Во-первых, фиксированный размер HIT позволяет сохранить контроль за размером пакетов и упрощает кодирование протоколов. Во-вторых, он обеспечивает согласованный формат протокола, не зависящий от применяемой технологии отождествления.

RFC 7343 [RFC7343] задаёт 128-битовые идентификаторы на основе хэш-значений, называемые ORCHID. Префикс для этих идентификаторов, выделенный из блока адресов IPv6, также определён в [RFC7343]. Тег HIT является одним из типов ORCHID.

Этот документ расширяет исходную, экспериментальную спецификацию HIP [RFC5201] мерами обеспечения криптографической гибкости. Одна из таких мер разрешает использовать разные хэш-функции для генерации тегов HIT. HIT Suite группирует наборы алгоритмов, которые нужны для создания и применения конкретного HIT, и указываются эти группы с помощью HIT Suite ID, передаваемых в поле алгоритма OGA (ORCHID Generation Algorithm) идентификатора ORCHID. С помощью HIT Suite ID в поле OGA ID хост может определить по тегу HIT другого хоста, поддерживает ли тот необходимые алгоритмы хэширования и подписи для создания ассоциации HIP с этим хостом.

3.2. Создание HIT из HI

Теги HIT должны создаваться в соответствии с методом генерации ORCHID, описанным в [RFC7343], с идентификатором контекста 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA (случайное значение, созданное редактором данной спецификации) и входных данных, представляющих поле Host Identity (см. параграф 5.2.9) в данных пакета HIP. Хэш-функцию, алгоритм подписи и алгоритм генерации HIT из HI определяет набор HIT Suite (см. параграф 5.2.10), который указывается 4 битами поля OGA ID в идентификаторе ORCHID. В настоящее время для создания HIT определены усеченные алгоритмы SHA-1, SHA-384 и SHA-256 [FIPS.180-4.2012].

Для отождествлений, являющихся открытыми ключами RSA, DSA (Digital Signature Algorithm) [FIPS.186-4.2013] или ECDSA (Elliptic Curve DSA), вводом ORCHID служит кодирование открытого ключа, указанное в поле Host Identity параметра HOST_ID (см. параграф 5.2.9). Этот документ определяет 4 алгоритма: RSA, DSA, ECDSA, ECDSA_LOW. Профиль ECDSA_LOW предназначен для устройств с малой вычислительной мощностью, поэтому применим однин из указанных ниже вариантов.

Открытый ключ RSA кодируется в соответствии с разделом 2 в [RFC3110], принимая конкатенацию полей размера экспоненты (e_len), показателя (e) и модуля (n). Размер n_len модуля n может быть определён из общего размера HI и предшествующих полейHI, включая показатель степени (e). Таким образом, входные данные для генерации HIT имеют такой же размер, как HI. Поля должны кодироваться в сетевом порядке байтов, как указано в [RFC3110].

Открытый ключ DSA кодируется в соответствии с разделом 2 в [RFC2536], принимая конкатенацию полей T, Q, P, G, Y. Таким образом, размер хэшируемых данных составляет 1 + 20 + 3 * 64 + 3 * 8 * T октетов, где T — параметр размера, определённый в [RFC2536]. Этот параметр влияет на размеры полей, поэтому для него должно выбираться минимальное значение, позволяющее поместить P, G и Y. Поля должны кодироваться в сетевом порядке байтов, как указано в [RFC2536].

Открытые ключи ECDSA кодируются в соответствии с параграфом 4.2 и разделом 6 в [RFC6090].

В Приложении B представлен псевдокод, иллюстрирующий кодирование открытых ключей.

4. Обзор протокола

В этом разделе приведено упрощенно описание работы протокола HIP без рассмотрения формата пакетов и этапов обработки, которые приведены в разделах 5 и 6, являющихся нормативными.

Для протокола HIP агентство IANA выделило номер 139.

Заголовок данные HIP (параграф 5.1) может передаваться в каждой дейтаграмме IP. Однако эти заголовки достаточно велики (40 байтов), поэтому желательно «сжимать» заголовки HIP, передавая их лишь в пакетах управления при организации или смене состояния ассоциации HIP. Фактический метод «сжатия» и сопоставления пакетов с имеющимися ассоциациями (при их наличии) определяется отдельными документами, описывающими форматы и методы транспортировки. Все реализации HIP должны поддерживать транспортный формат ESP для HIP [RFC7402].

4.1. Создание HIP-ассоциации

Система, начинающая базовый обмен HIP считается Инициатором (Initiator), а её партнёр — Ответчиком (Responder). Это различие обычно утрачивается по завершении базового обмена и любая их сторон может стать Инициатором в будущих коммуникациях.

Базовый обмен HIP служит для организации состояния между Инициатором и Ответчиком. Первый пакет (I1) начинает обмен, а 3 оставшихся (R1, I2, R2) реализуют аутентифицированный обмен ключами Diffie-Hellman (DH) [DIF76] для генерации сеансовых ключей. В двух первых пакетах хосты согласуют набор криптографических идентификаторов и алгоритмы, которые применяются после обмена. В процессе обмена ключами DH создаётся фрагмент ключевого материала, из которого выводятся ключи ассоциации HIP с помощью функции вывода ключей (Key Derivation Function или KDF). Если нужны другие криптографические ключи, например, для использования с ESP, предполагается их вывод из того же ключевого материала с использованием KDF.

Инициатор сначала передаёт Ответчику запускающий пакет I1, который содержит его тег HIT и может включать HIT Ответчика, если этот тег известен. Кроме того, пакет I1 инициализирует согласование группы DH, используемой для создания ключевого материала, поэтому пакет I1 включает список идентификаторов групп DH, поддерживаемых Инициатором. Отметим, что в некоторых случаях возможна замена этого пакета иным триггером и в таких случаях протокол начинает с передачи Ответчиком пакета R1, при этом должен указываться механизм передачи списка поддерживаемых Инициатором групп DH (например, использование принятой по умолчанию группы).

Второй пакет (R1) фактически начинает аутентифицированный обмен DH. Этот пакет содержит «головоломку» (puzzle), являющуюся криптографической задачей которую Инициатор должен решить для продолжения обмена. Уровень сложности этой задачи можно настраивать в зависимости от степени доверия к Инициатору, текущей нагрузки и других факторов. В дополнение к этому R1 содержит параметр DH для Ответчика и список поддерживаемых Ответчиком криптографических алгоритмов. На основе этого Инициатор может продолжить, прервать или перезапустить базовый обмен с соответствующим набором криптографических алгоритмов. Пакет R1 также включает подпись для выбранных частей сообщения. Некоторые поля не включаются в подпись для поддержки создаваемых заранее пакетов R1.

В пакете I2 Инициатор должен указать решение головоломки и при отсутствии верного решения пакет I2 будет отброшен. I2 включает также параметр DH с информацией, требуемой Ответчику. Инициатор подписывает пакет I2.

Пакет R2 подтверждает получение I2 и завершает базовый обмен. Ответчик подписывает этот пакет.

Базовый обмен показан на рисунке 1, где key указывает открытый ключ Host Identity, а sig — подпись с использованием этого ключа. Некоторые параметр пакета на рисунке не показаны.

   Инициатор                              Ответчик

                I1: список DH
              -------------------------->
                                          выбор готового R1
                R1: puzzle, DH, key, sig
              <-------------------------
проверка подписи                          состояния пока нет
решение головоломки
              I2: решение, DH, {key}, sig
              -------------------------->
расчет DH                                 проверка решения
                                          проверка подписи
                        R2: sig
              <--------------------------
проверка подписи                          расчет DH

Рисунок 1. Базовый обмен HIP (BEX).

4.1.1. Механизм HIP Puzzle

Механизм HIP Puzzle предназначен для защиты Ответчика от DoS и позволяет Ответчику задержать создание состояния до получения пакета I2. Кроме того, головоломка позволяет Ответчику использовать достаточно простые расчеты для проверки «искренности» Инициатора, требующие от того нескольких тактов CPU для решения задачи.

Головоломка позволяет Ответчику отложить создание состояния ассоциации до получения действительного пакета I2. Пакет I2 без верного решения задачи может быть отвергнут сразу после проверки решения Ответчиком. Решение можно проверить расчетом лишь одной хэш-функции, а непригодные решения могут быть отвергнуты до создания состояния и требующих ресурсов CPU проверки подписи и создания ключей DH. Меняя сложность головоломки, Ответчик может предотвратить DoS-атаки, нацеленные на рсход ресурсов CPU или памяти.

Ответчик может оставаться без состояния и отбрасывать большинство обманных пакетов I2, поскольку для решения задачи нужен HIT-тег Инициатора. Идея состоит в том, что у Ответчика имеется несколько (возможно переменное число) готовых пакетов R1, из которых он выбирает подходящий на основе сведений из пакета I1. Когда Ответчик получает пакет I2, он может проверить решение задачи с использованием HIT Инициатора. Это делает бессмысленным для атакующего сначала передать один пакет I1/R1, а затем генерировать множество фиктивных пакетов I2, как будто с разными HIT. Однако метод не защищает Ответчика от атак с использованием фиксированного значения HIT, против которых может применяться частичное создание локального состояния с запоминанием фактов отказа при проверке решения (один из вариантов описан в Приложении A). Реализациям Ответчика следует включать достаточный объем случайности в значения puzzle, чтобы предотвратить алгоритмические атаки [CRO03].

Ответчик может устанавливать сложность головоломки для Инициатора на основе уровня доверия к нему. Поскольку головоломка не учитывается при создании подписи, Ответчик может использовать созданные заранее пакеты R1 и передавать их в качестве головоломки для Инициатора. Ответчику следует применять эвристические методы обнаружения DoS-атак и устанавливать сложность головоломки (#K), как описано ниже.

4.1.2. Обмен Puzzle

Ответчик запускает обмен Puzzle, получив пакет I1. Ответчик предоставляет случайное значение #I и требует от Инициатора найти случайное значение #J. Для выбора нужного #J Инициатор должен создать конкатенацию #I, тегов HIT обеих сторон и #J, затем рассчитать хэш этой конкатенации, используя алгоритм RHASH. Младшие #K результата должны быть 0. Значение #K определяет сложность головоломки.

Для генерации верного #J Инициатор создаёт множество значений #J, пока не будет получена хеш-цель из нулей. Инициатору следует прерывать попытки только по истечении срока действия головоломки, заданного полем Lifetime в параметре PUZZLE (см. параграф 5.2.4). Ответчику требуется восстановить конкатенацию #I, тегов HIT и представленного #J, а затем рассчитать хэш для проверки корректности решения задачи Инициатором.

Для предотвращения атак с предварительным расчетом Ответчик должен выбирать значение #I так, чтобы Инициатор не мог угадать его. Кроме того, конструкция должна позволять Ответчику убедиться в том, что значение #I выбрано им, а не Инициатором. Пример реализации этого приведён в Приложении A.

Используя поле Opaque в PUZZLE (см. параграф 5.2.4) параметра ECHO_REQUEST_SIGNED (см. параграф 5.2.20) или ECHO_REQUEST_UNSIGNED (см. параграф 5.2.21), Ответчик может включить в R1 те или иные данные, которые Инициатор должен без изменений скопировать в соответствующий пакет I2. Ответчик может использовать необрабатываемые (opaque) данные для передачи части сведений локального состояния Инициатору и обратно, например, для проверки того, что I2 является откликом на переданный ранее R1. Ответчик может создавать эти данные разными способами, например, применяя шифрование или хэширование с неким секретом, переданное значение #I и возможно другие связанные данные. Используя тот же секрет, полученное значение #I (из пакета I2) и другие связанные данные (при наличии), Ответчик может убедиться, что это он передал #I Инициатору. Ответчик должен периодически менять применяемый секрет.

Ответчику рекомендуется генерировать новые секреты для головоломки и новые R1 каждые несколько минут. Кроме того, ему рекомендуется обеспечивать возможность проверки правильности решения головоломки в течение не меньше Lifetime секунд после смены секрета головоломки. Это гарантирует действительность головоломки в интервале от Lifetime до 2 * Lifetime секунд. Это не позволит атакующему воспользоваться старой головоломкой и предотвратит проблемы в сучаях, когда срок действия значение Lifetime сравнимо с задержкой в сети и временем решения головоломки.

Значение головоломки #I и решение #J служат входными данными для создания ключевого материала из обмена DH (см. параграф 6.5). Поэтому для того, чтобы ключевой материал различался, Ответчику не следует дважды использовать одно значение #I с теми же ключами DH для одного Инициатора. Такую уникальность можно обеспечить, например, с использованием счётчика в качестве дополнения входных данных при создании #I. Этот счётчик можно увеличивать для каждого обработанного пакета I1. Состояние счётчика можно передавать в поле Opaque в PUZZLE (см. параграф 5.2.4) параметра ECHO_REQUEST_SIGNED (см. параграф 5.2.20) или ECHO_REQUEST_UNSIGNED (см. параграф 5.2.21) без необходимости организации состояния.

Примечание. Разработчики протокола явно рассмотрели вопрос включения в R1 временной метки для защиты Инициатора от атак с повторным использованием (replay). Принято решение не включать метку для предотвращения проблем с глобальной синхронизацией часов.

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

4.1.3. Аутентифицированный обмен Diffie-Hellman с согласованием DH Group

Пакеты R1, I2, R2 реализуют стандартный аутентифицированный обмен DH. Ответчик передаёт один из своих открытых ключей DH и свой открытый ключ аутентификации (т. е. Host Identity) в пакете R1. Подпись в пакете R1 позволяет Инициатору убедиться в том, что пакет R1 создан Ответчиком. Однако, поскольку R1 создаётся заранее и не охватывает связанную с ассоциацией информацию из пакета I1, это не обеспечивает защиты от replay-атак.

Перед фактическим аутентифицированным обменом DH Инициатор указывает своё предпочтение по выбору групп DH в пакете I1 как отсортированный список идентификаторов групп DH. Пакет I1 не подписывается и , следовательно, список передаётся без аутентификации для предотвращения ресурсоемких расчётов при обработке пакета I1 на стороне Ответчика. На основе предпочтений Инициатора Ответчик указывает в пакете R1 наиболее подходящее открытое значение DH, а также присоединяет список своих предпочтений к пакету R1, чтобы передать Инициатору основания для выбора группы DH. Этот список передаётся в подписанной части пакета R1. Если выбор группы DH в пакете R1 не соответствует предпочтениям Инициатора и Ответчика, Инициатор может счесть, что список DH Group ID в пакете I1 был изменён (см. ниже).

Если Ответчик не поддерживает ни один из DH Group ID в пакете I1, он выбирает наиболее подходящую для себя группу DH, назависимо от предпочтений Инициатора, затем передаёт Инициатору пакет R1 с этой группой DH и списком поддерживаемых DH Group ID.

Инициатор получает в пакете R1 открытые значение DH и список групп DH Group ID, поддерживаемых Ответчиком. Этот список включается в подпись пакета R1 для предотвращения подмены. Инициатор сравнивает Group ID открытого значения DH в пакете R1 со списком поддерживаемых DH Group ID в пакетах R1 и своими предпочтениями, указанными в списке поддерживаемых DH Group ID. Инициатор продолжает обмен BEX лишь в том случае, когда Group ID открытого значения DH Ответчика является идентификатором наиболее предпочтительной группы, поддерживаемой Инициатором и Ответчиком. Иное говорит о воздейтсиии на ассоциацию атаки с понижением и Инициатор должен перезапустить базовый обмен новым пакетом I1 или прервать этот обмен. Если Ответчик выбрал группу DH, не поддерживаемую Инициатором, тот может прервать согласование или передать новый пакет I1 с другим списком поддерживаемых групп DH. Однако Инициатор должен проверить подпись пакета R1 до перезапуска или прерывания согласования. При некорректной подписи Инициатор должен просто игнорировать пакет R1.

Если предпочтения в части DH Group ID совпадают, Инициатор рассчитывает сеансовый ключ DH (Kij) и создаёт ассоциацию HIP используя материал из сеансового ключа (см. параграф 6.5). Ассоциация может также использоваться Инициатором для шифрования своего открытого ключа аутентификации, т. е. Host Identity. Результирующий пакет I2 содержит ключ DH Инициатора и его (возможно зашированный) открытый ключ аутентификации. Подпись сообщения I2 охватывает все параметры подписываемых диапазонов (см. параграф 5.2) без исключений, как для пакета R1.

Ответчик извлекает открытый ключ DH Инициатора из пакета I2, рассчитывает сеансовый ключ DH, создаёт соответствующую ассоциацию HIP и расшифровывает открытый ключ аутентификации Инициатора. После этого он может проверить подпись с использованием ключа аутентификации.

Финальное сообщение R2 завершает обмен BEX и защищает Инициатора от replay-атак, поскольку Ответчик использует общий ключ из обмена DH для создания хэшированного кода аутентификации сообщения (Hashed Message Authentication Code или HMAC), а также использует секретный ключ своего Host Identity для подписания пакета.

4.1.4. Защита HIP от повторного использования пакетов (Replay)

HIP включает описанные здесь механизмы для защиты от враждебного повторного использования пакетов (replay). Ответчики защищаются от повторного использования пакетов I1 благодаря ответам на I1 без сохранения состояния подписанными пакетами R1. Инициаторы защищены от повторов R1 с помощью монотонно возрастающих «счетчиков генерации R1» включаемых в пакеты R1. Ответчики защищены от воспроизведения обманных пакетов I2 механизмом головоломок (puzzle, см. параграф 4.1.1) и необязательными данными Opaque. Хосты защищены от повторного использования пакетов R2 и UPDATE применением менее дорогостоящей проверки HMAC до проверки подписи HIP.

Счетчик генерации R1 представляет собой монотонно возрастающее 64-битовое число, для которого может быть установлено любое начальное значение. Счётчик может работать на уровне всей системы, однако следует поддерживать отдельный счётчик для каждого отождествления Host Identity, если их несколько. Значение этого счётчика следует сохранять при перезагрузке системы и вызовах базового обмена HIP. Счётчик указывает текущее поколение головоломок. Реализации должны воспринимать головоломки текущего поколения и могут воспринимать их из предыдущих поколений. Локальный счётчик системы должен инкрементироваться не реже чем прекращается действие каждого прежнего R1. Локальному счетчику следует быть неснижаемым, поскольку в противном случае хост предоставит своим партнёрам возможность повторно использовать созданные ранее R1 с большими номерами.

Хост может получит несколько пакетов R1 в результате отправки нескольких I1 (см. параграф 6.6.1) или повторного использования старых R1. При передаче нескольких пакетов I1 одному хосту Инициатору следует выждать некоторое время (разумное значение — удвоенный ожидаемый интервал RTT) после получения первого R1, чтобы принять другие R1, а также следует отвечать на пакет R1 с наибольшим значением счётчика генерации R1. Если Инициатор обрабатывает R1 или уже передал пакет I2 (ждёт получения R2) и получает другой пакет R1 с большим значением счётчика, он может перезапустить обработку R1 для нового пакета R1, как будто он прибыл первым.

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

4.1.5. Отклонение базового обмена HIP

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

Если политика хоста не позволяет ему вступать в обмен HIP с Инициатором, хосту следует передать сообщение ICMP Destination Unreachable, Administratively Prohibited. Более сложный пакет HIP здесь не применяется, поскольку он открыват больше возможных DoS-атак, чем простое сообщение ICMP. Сообщение HIP NOTIFY не применяется, поскольку между хостами ещё нет ассоциации HIP.

4.1.6. Прерывание базового обмена HIP

Два хоста HIP могут столкнуться с ситуацией, когда они не могут завершить базовый обмен HIP из-за недостаточной поддержки криптографических алгоритмов, в частности HIT Suite и групп DH. После приёма пакета R1 Инициатор может определить, поддерживает ли Ответчик требуемые криптографические операции для создания ассоциации HIP. Инициатор может прервать обмен BEX после получения пакета R1, указывающего неподдерживаемый набор алгоритмов. Конкретные условия описаны ниже.

Пакет R1 содержит подписанный список идентификаторов HIT Suite, поддерживаемых Ответчиком, поэтому Инициатор может определить, поддерживает ли Ответчик тег HIT источника. Если HIT Suite ID из HIT Инициатора не содержится в списке HIT Suite пакета R1, Инициатор может прервать согласования, а также может перезапустить его, передав новый пакет I1 с тегом HIT источника, поддерживаемым Ответчиком.

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

4.1.7. Защита HIP от понижения

В атаках на понижение (downgrade) злоумышленник пытается незаметно манипулировать пакетами Инициатора и/или Ответчика с целью повлиять на результат криптографического согласования в процессе BEX в свою пользу. В результате жертвы могут выбрать более слабые криптографические алгоритмы, нежели они могли выбрать без вмешательства злоумышленника. Атаки с понижением могут быть успешны лишь в том случае, когда они остаются незамеченными и жертвы считают коммуникационный канал защищенным.

В HIP почти все пакеты параметров, связанные с криптографическим согласованием, имеют подпись. Этими параметрами нельзя манипулировать напрямую с атаках с понижением без аннулирования подписей. Однако подписанные пакеты могут подвегаться replay-атакам, где злоумышленник может воспользоваться старым пакетом BEX с устаревшим и слабым выбором криптоалгоритмов и передать такой пакет вместо свежего с набором более сильных алгоритмов. Такие атаки возможны на пакеты R1 и I2. Однако вопроизведенные пакеты R1 и I2 невозможно применить для успешного обмена HIP BEX, поскольку эти пакеты включают открытые значения DH Инициатора и Ответчика. Старые значения DH из воспроизводимых пакетов ведёт к недействительному ключевому материалу и несоответствию общих секретов, поскольку атакующий не может вывести действительный ключевой материал из открытых ключей DH в R1 и не может создать действительный код HMAC и подпись для воспроизводимого I2.

В отличие от первой версии HIP [RFC5201], версия 2, определённая в этом документе, начинает согласование групп DH уже в первом пакете BEX (I1). Пакеты I1 намеренно не защищены подписью для предотвращения загружающих CPU криптографических операций обработки лавины пакетов I1, направленных Ответчику. Поэтому список DH Group ID в пакете I1 можно подменить или изменить. Для предотвращения незаметных манипуляция с пакетами I1 Ответчик выбирает группу DH детерминированно и включает свой список DH Group ID в подписанную часть пакета R1. Инициатор может заметить попытку понижения, сравнивая список DH Group ID в пакете R1 со своими предпочтениями в пакете I1. Если выбор групп DH в пакете R1 не соответствует лучшему варианту из двух списков (DH ID Ответчика с высшим приоритетом имеется в списке DH от Инициатора), Инициатор может сделать заключение о подмене списка в пакете I1. В этом случае Инициатор может прервать обмен BEX или запустить его заново. Как отмечено выше, обнаружения downgrade-атаки достаточно для её предотвращения.

4.1.8. Режим HIP Opportunistic

Можно инициировать обмен HIP BEX, даже когда HI (и HIT) Ответчика неизвестен. В этом случае в начальном пакете I1 для HIT адресата указывается значение 0. Такой тип соединения называется режимом Opportunistic. Ответчик может иметь несколько HIT в результате поддержки нескольких HIT Suite. Поскольку HIT Suite Ответчика в режиме Opportunistic не определяется HIT получателя в пакете I1, Ответчик волен выбрать HIT любого из своих HIT Suite. Полный набор поддерживаемых Инициатором HIT Suite неизвестен Ответчику, поэтому ему следует выбирать HIT из того же HIT Suite, что и HIT Инициатора (указывается информацией HIT Suite в поле OGA ID тега HIT Инициатора), поскольку этот набор очевидно поддерживается Инициатором. Если Ответчик выбирает друго тег HIT, который не поддерживается Инициатором, Инициатор может перезапустить BEX пакетом I1 с HIT источника, содержащимся в списке HIT Suite Ответчика из пакета R1.

Отметим, что Инициатор не может проверить подпись пакета R1, если он не поддерживает HIT Suite Итветчика. Поэтому Инициатор должен считать пакеты R1 с неподдерживаемыми HIT Ответчика потенциально обманными и ему недопустимо использовать из непроверенных R1 какие-либо параметры за исключением HIT_SUITE_LIST. Кроме того, Инициатор, использующий HIT_SUITE_LIST from из непроверенного пакета R1 для определения возможного HIT источника должен убедиться, что HIT_SUITE_LIST из первого непроверенного пакета R1 совпадает с HIT_SUITE_LIST во тором пакете R1, для которого Инициатор поддерживает алгоритм подписи. Инициатор должен перезапустить обмен BEX новым пакетом I1, для которого алгоритм был указан в проверяемом R1, если два списка различаются. Эта процедура должна смягчить атаки на понижение.

С режимом Opportunistic связаны проблемы как безопасности, так и API, рассматриваемые ниже.

С учётом того, что Инициатор не знает HI Ответчика, должны быть подходящие вызовы API, позволяющие Инициатору напрямую или опосредованно запросить у базовой системы инициирование базового обмена HIP на основе «локаторов» (адресов). HI ответчика будет предварительно представлен в пакете R1 и аутентифицирован после получения и проверки пакета R2. Следовательно, HIT Ответчика можно передать приложению через новые механизмы API. Однако приложение с совместимым с прежними версиями API видит лишь локаторы, использованные при начальном контакте. В зависимости от желаемой семантики API, возникает ряд приведённых ниже проблем.

• Фактические локаторы могут измениться, если применяется сообщение UPDATE, даже при сохранении с точки зрения API ассоциации между двумя конкретными локаторами. Однако обновление локатора остаётся безопасным и ассоциация сохраняется между теми же узлами.

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

  Если у реализации HIP и приложения нет единого представления о составе ассоциации, это может происходить даже в рамках одной ассоциации. Например, реализация может не знать, когда следует сбросить состояние HIP для приложения на основе UDP.

Кроме того, здесь применим ряд соображений безопасности. Механизм счётчиков генерации будет менее эффективен для защиты от повторного использования пакетов R1 с учётом того, что Ответчик может выбрать воспроизведение произвольного HI, а не только полученного в пакете. Более важно, что обмен Opportunistic уязвим к MitM-атакам, поскольку у Инициатора нет сведений об открытом ключе партнёра. Чтобы оценить влияние этой уязвимости, она сравнивается с уязвимости современных коммуникаций без HIP.

Атакующий на пути между партнёрами может включиться в процесс (MitM), представляя свой идентификатор Инициатору, а затем создавая другую ассоциацию HIP в направлении Ответчика. Это возможно, если Инициатор использует режим Opportunistic, а Ответчик настроен на восприятие соединений от любого узла с поддержкой HIP. Атакующий вне пути не сможет организовать такую атаку, поскольку он не способен отвечать на сообщения базового обмена.

Эти свойства безопасности характерны для коммуникаций в современной сети Internet. Клиент, связывающийся с сервером без использования сквозной защиты, может обнаружить, что он взаимодействует с сервером через MitM в предположении готовности сервера взаимодействовать с кем угодно. При использовании сквозной защиты худшим, что может случиться как при использовании Opportunistic HIP так и в режиме без HIP (обычный IP) является отказ в обслуживании, когда элемент пути нарушает взаимодействие но не способен выполнить MitM-атаку.

Однако по завершении обмена Opportunistic протокол HIP обеспечивает защиту целостности и конфиденциальности и позволяет безопасно менять локаторы (адреса) конечных точек. В результате режим Opportunistic в HIP предлагает модель защиты «лучше, чем ничего» (better than nothing). Исходно базовый обмен, аутентифицированный в режиме Opportunistic, полагается на веру (leap of faith) и подвержен MitM-атакам, но последующие дейтаграммы, относящиеся к той же ассоциации HIP не могут быть скомпрометированы новой MitM-атакой. Кроме того, при уходе MitM с пути активной ассоциации атака будет обнаружена постфактум. Таким образом, можно считать, что режим Opportunistic в HIP не менее защищён, чем обычные коммуникации IP без защиты.

4.2. Обновление ассоциации HIP

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

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

Пакеты UPDATE защищены с помощью параметров HIP_MAC и HIP_SIGNATURE, поскольку обработка подписей UPDATE открывает возможность организации DoS-атак на промежуточные системы.

Пакеты UPDATE подтверждаются явно с помощью параметра, возвращающего полученный от партнера порядковый номер. Один пакет UPDATE может содержать как порядковый номер, так и 1 или несколько номеров подтверждения (т. е. подтверждения UPDATE от партнера). Формат пакетов UPDATE определён в параграфе 5.3.5.

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

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

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

Нет предыдущего состояния между системами.

Данные передаёт Инициатор. Процесс является стандартным базовым обменом 4 для создании ассоциации HIP.

Система с данными для передачи не имеет состояния с получателем, но у того остается ассоциация HIP.

Данные передаёт Инициатор, который действует как при отсутствии предшествующего состояния, передавая пакет I1 и получая R1. Когда Ответчик получает действительный пакет I2, старая ассоциация «обнаруживается» и удаляется, а вместо неё создаётся новая.

Система с данными для передачи имеет ассоциацию HIP, но ее нет у получателя.

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

Принимающему хосту следует передать пакет ICMP типа Parameter Problem для информирования отправителя об отсутствии ассоциации HIP (см. параграф 5.4) и он может инициировать новый обмен HIP BEX. Однако использование этих дополнительных механизмов зависит от реализации и политики. Если передающее приложение не ждёт отклика, система может передать в этом состоянии большое число пакетов, поэтому рекомендуется отправка 1 или нескольких пакетов ICMP. Однако частота таких откликов должна быть ограничена для предотвращения злоупотреблений (см. параграф 5.4).

4.4. Конечный автомат HIP

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

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

Этот документ расширяет конечный автомат [RFC5201] и добавляет вариант перезапуска, позволяющего согласовать криптографические алгоритмы. Расширение заключается в переходе из состояния I1-SENT обратно в это же состояние (перезапуск). Инициатору требуется запускать базовый обмен HIP снова, если Ответчик не поддерживает HIT Suite Инициатора. В этом случае Инициатор перезапускает базовый обмен HIP отправкой нового пакета I1 с HIT источника, поддерживаемым Ответчиком.

Разработчикам следует понимать, что рассмотренный здесь конечный автомат является лишь описанием и логика обработки может быть реализована разными способами. В разделе 6 правила обработки пакетов рассмотрены более подробно. Это описание сосредоточено лишь на пакетах HIP I1, R1, I2 и R2. Механизмы из других спецификаций (например, многоадресность или мобильность) могут добавлять состояния и переходы в конечный автомат.

4.4.1. Термины для конечного автомата

Unused Association Lifetime (UAL) — срок действия неиспользуемой ассоциации

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

Maximum Segment Lifetime (MSL) — максимальный срок действия сегмента

Максимальное время, которое предполагается для нахождения пакета HIP в сети. По умолчанию принято время 2 минуты, заимствованное из [RFC0793], поскольку это преобладающее допущение о сроке действия пакетов.

Exchange Complete (EC) — обмен завершен

Время, которое хост проводит в состоянии R2-SENT перед переходом в состояние ESTABLISHED. Это время составляет продолжительность тайм-аута повтора I2, умноженное на значение n приблизительно равное I2_RETRIES_MAX.

Receive ANYOTHER — получен другой пакет

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

4.4.2. Состояния HIP

Таблица 1. Состояния HIP.

Состояние	Описание
UNASSOCIATED	Запуск конечного автомата
I1-SENT	Запуск базового обмена
I2-SENT	Ожидание завершения базового обмена
R2-SENT	Ожидание завершения базового обмена
ESTABLISHED	Ассоциация HIP создана
CLOSING	Ассоциация HIP закрывается, данные передать невозможно
CLOSED	Ассоциация HIP закрыта, данные передать невозможно
E-FAILED	Отказ при базовом обмене HIP

4.4.3. Процессы состояний HIP

Поведение системы, находящейся в состоянии UNASSOCIATED, показано в таблице 2.

Таблица 2. Стартовое состояние UNASSOCIATED.

Триггер	Действие
Для передачи пользовательских данных нужна новая ассоциация HIP	Отправка I1 и переход в I1-SENT.
Получение I1	Передача R1 и сохранение UNASSOCIATED.
Получение I2, обработка	При успешной обработке передача R2 и переход в R2-SENT, в ином случае сохранение UNASSOCIATED.
Получение пользовательских данных для неизвестной ассоциации HIP	Необязательная передача ICMP (см. параграф 5.4) и сохранение UNASSOCIATED.
Получение CLOSE	Необязательная передача ICMP Parameter Problem и сохранение UNASSOCIATED.
Получение ANYOTHER	Отбрасывание пакета и сохранение UNASSOCIATED.

Поведение системы, находящейся в состоянии I1-SENT, показано в таблице 3.

Таблица 3. I1-SENT — инициализация базового обмена HIP.

Триггер	Действие
Получение I1 от Ответчика	Если локальный тег HIT меньше HIT партнера (см. параграф 6.5), пакет I1 отбрасывается, иначе передается R1. В обоих случаях сохраняется I1-SENT.
Получение I2, обработка	При успешной обработке передача R2 и переход в R2-SENT, иначе сохранение I1-SENT.
Получение R1, обработка	Если HIT Suite из локального HIT не поддерживается партнёром, выбор подходящего локального HIT, передача I1 и сохранение I1-SENT. При успешной обработке передача I2 и переход в I2-SENT, иначе сохранение I1-SENT.
Получение ANYOTHER	Отбрасывание пакета и сохранение I1-SENT.
Тайм-аут	Инкрементирование счётчика повторов. Если счётчик меньше I1_RETRIES_MAX, передача I1 и сохранение I1-SENT, если счётчик больше I1_RETRIES_MAX, переход в E-FAILED.

Поведение системы, находящейся в состоянии I2-SENT, показано в таблице 4.

Таблица 4. I2-SENT — ожидание завершения базового обмена HIP.

Триггер	Действие
Получение I1	Передача R1 и сохранение I2-SENT.
Получение R1, обработка	При успешной обработке передача I2. Сохранение I2-SENT
Получение I2, обработка	Если обработка успешна и локальный тег HIT меньше HIT партнера, отбрасывание I2 и сохранения I2-SENT. Если обработка успешна и локальный тег HIT больше партнеросного, передача R2 и переход в R2-SENT. При неудачной обработке сохраняется I2-SENT.
Получение R2, обработка	При успешной обработке переход в ESTABLISHED, иначе сохранение I2-SENT.
Получение CLOSE, обработка	При успешной обработке передача CLOSE_ACK и переход в CLOSED, иначе сохранение I2-SENT.
Получение ANYOTHER	Отбрасывание пакета и сохранение I2-SENT.
Тайм-аут	Инкрементирование счётчика повторов. Если счётчик меньше I2_RETRIES_MAX, передача I2 и сохранение I2-SENT, если счётчик больше I2_RETRIES_MAX, переход в E-FAILED.

Поведение системы, находящейся в состоянии R2-SENT, показано в таблице 5.

Таблица 5. R2-SENT — ожидание завершения HIP.

Триггер	Действие
Получение I1	Отбрасывание пакета и сохранение R2-SENT.
Получение I2, обработка	При успешной обработке передача I2. Сохранение R2-SENT
Получение R1	Отбрасывание пакета и сохранение R2-SENT.
Получение R2	Отбрасывание пакета и сохранение R2-SENT.
Получение данных или UPDATE	Переход в ESTABLISHED.
Тайм-аут завершения обмена	Переход в ESTABLISHED.
Получение CLOSE, обработка	При успешной обработке передача CLOSE_ACK и переход в CLOSED, иначе сохранение ESTABLISHED.
Получение CLOSE_ACK	Отбрасывание пакета и сохранение R2-SENT.
Получение NOTIFY	Обработка пакета и сохранение R2-SENT.

Поведение системы, находящейся в состоянии ESTABLISHED, показано в таблице 6.

Таблица 6. ESTABLISHED — ассоциация HIP создана.

Триггер	Действие
Получение I1	Передача R1 и сохранение ESTABLISHED.
Получение I2	Обработка головоломки и (возможно) проверка Opaque data. При успешной обработке передача R2, отбрасывание старой ассоциации HIP, создание новой и переход в R2-SENT, при отказе сохранение ESTABLISHED.
Получение R1	Отбрасывание пакета и сохранение ESTABLISHED.
Получение R2	Отбрасывание пакета и сохранение ESTABLISHED.
Получение пользовательских данных для ассоциации HIP	Обработка пакета и сохранение ESTABLISHED.
Нет пакетов в интервале UAL минут	Передача CLOSE и переход в CLOSING.
Получение UPDATE	Обработка пакета и сохранение ESTABLISHED.
Получение CLOSE, обработка	При успешной обработке send CLOSE_ACK и переход в CLOSED, при отказе сохранение ESTABLISHED.
Получение CLOSE_ACK	Отбрасывание пакета и сохранение ESTABLISHED.
Получение NOTIFY	Обработка пакета и сохранение ESTABLISHED.

Поведение системы, находящейся в состоянии CLOSING, показано в таблице 7.

Таблица 7. CLOSING — ассоциация HIP не использовалась в течение UAL минут.

Триггер	Действие
Для передачи данных пользователя нужна новая инкарнация ассоциации HIP	Передача I1 и переход в I1-SENT.
Получение I1	Передача R1 и сохранение CLOSING.
Получение I2, обработка	При успешной обработке передача R2 и переход в R2-SENT, иначе сохранение CLOSING.
Получение R1, обработка	При успешной обработке передача I2 и переход в I2-SENT, иначе сохранение CLOSING.
Получение CLOSE, обработка	При успешной обработке передача CLOSE_ACK, отбрасывание состояния и переход в CLOSED, иначе сохранение CLOSING.
Получение CLOSE_ACK, обработка	При успешной обработке отбрасывание состояния и переход в UNASSOCIATED, иначе сохранение CLOSING.
Получение ANYOTHER	Отбрасывание пакета и сохранение CLOSING.
Тайм-аут	Увеличение тайм-аута sum и сброс таймера. Если тайм-аут sum меньше UAL+MSL, повтор CLOSE и сохранение CLOSING. Если тайм-аут sum больше UAL+MSL, переход в UNASSOCIATED.

Поведение системы, находящейся в состоянии CLOSED, показано в таблице 8.

Таблица 8. CLOSED — передан CLOSE_ACK и при необходимости повторяется.

Триггер	Действие
Для передачи дейтаграммы нужна другая инкарнация ассоциации HIP	Передача I1 и сохранение CLOSED.
Получение I1	Передача R1 и сохранение CLOSED.
Получение I2, обработка	При успешной обработке передача R2 и переход в R2-SENT, иначе сохранение CLOSED.
Получение R1, обработка	При успешной обработке передача I2 и переход в I2-SENT, иначе сохранение CLOSED.
Получение CLOSE, обработка	При успешной обработке передача CLOSE_ACK. Сохранение CLOSED.
Получение CLOSE_ACK, обработка	При успешной обработке отбрасывание состояния и переход в UNASSOCIATED, иначе сохранение CLOSED.
Получение ANYOTHER	Отбрасывание пакета и сохранение CLOSED.
Тайм-аут (UAL+2MSL)	Отбрасывание состояния и переход в UNASSOCIATED

Поведение системы, находящейся в состоянии E-FAILED, показано в таблице 9.

Таблица 9. E-FAILED — отказ HIP при создании ассоциации с партнером.

Триггер	Действие
Ожидание в зависимости от реализации	Переход в UNASSOCIATED, после чего возможен повтор согласования.

4.4.4. Упрощённая диаграмма состояний HIP

На рисунке 2 показаны основные смены состояний. Переходы в результате приёма пакетов неявно предполагают их успешную аутентификацию или обработку.

                            +--+       +----------------------------+
      приём I1, передача R1 |  |       |                            |
                            |  v       v                            |
                          +--------------+  приём I2, передача R2   |
         +----------------| UNASSOCIATED |----------------+         |
дейтагр. |  +--+          +--------------+                |         |
для отпр.|  |  | Alg. not supported,                      |         |
отпр. I1 |  |  | передача I1                              |         |
  .      v  |  v                                          |         |
  .   +---------+  приём I2, передача R2                  |         |
+---->| I1-SENT |--------------------------------------+  |         |
|     +---------+            +----------------------+  |  |         |
|          | приём R1,       |приём I2, передача R2 |  |  |         |
|          v передача I2     |                      v  v  v         |
|       +---------+          |                    +---------+       |
|  +--->| I2-SENT |----------+     +--------------| R2-SENT |<---+  |
|  |    +---------+                |              +---------+    |  |
|  |          |  |прием R2         |     тайм-аут  |             |  |
|  |прием R1, |  |                 |  данных или EC|             |  |
|  |отпр. I2  +--|-----------------+               |    приём I2,|  |
|  |          |  |       +-------------+           |  передача R2|  |
|  |          |  +------>| ESTABLISHED |<----------+             |  |
|  |          |          +-------------+                         |  |
|  |          |            |  |  |      приём I2, передача R2    |  |
|  |          +------------+  |  +-------------------------------+  |
|  |          |               +-----------+                      |  |
|  |          |    нет пакетов в течение  |    +---+             |  |
|  |          |  UAL минут, передача CLOSE|    |   |тайм-аут     |  |
|  |          |                           v    v   |(UAL+MSL)    |  |
|  |          |                        +---------+ |повтор       |  |
+--|----------|------------------------| CLOSING |-+CLOSE        |  |
   |          |                        +---------+               |  |
   |          |                         | |   | |                |  |
   +----------|-------------------------+ |   | +----------------+  |
   |          |               +-----------+   +------------------|--+
   |          |               |приём CLOSE,     приём CLOSE_ACK  |  |
   |          +-------------+ |отпр. CLOSE_ACK  или тайм-аут     |  |
   |     приём CLOSE,       | |                 (UAL+MSL)        |  |
   |     передача CLOSE_ACK v v                                  |  |
   |                     +--------+  приём I2, передача R2       |  |
   +---------------------| CLOSED |------------------------------+  |
                         +--------+                                 |
                          ^ |  |                                    |
приём CLOSE,              | |  |             тайм-аут (UAL+2MSL)    |
передача CLOSE_ACK        +-+  +------------------------------------+

Рисунок 2. Состояния HIP.

4.5. Пользовательские данные

4.5.1. Расчёт псевдозаголовков TCP и UDP для пользовательских данных

При расчёте контрольных сумм TCP и UDP в пользовательских пакетах данных, проходящих через сокеты, привязанные к HIT, должен использоваться формат псевдозаголовка IPv6 [RFC2460], даже если фактический адрес в заголовке пакета является IPv4. Кроме того, в псевдозаголовке IPv6 должны использоваться теги HIT вместо адресов IPv6. Отметим, что псевдозаголовок для фактических данных HIP рассчитывается иначе (см. параграф 5.1.1).

4.5.2. Передача данных в пакетах HIP

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

4.5.3. Транспортные форматы

Фактический формат, применяемый для передачи пользовательских данных после базового согласования HIP, этот документ не задаёт. Такие транспортные форматы и методы будут описаны в отдельных документах. Все реализации HIP должны поддерживать по меньшей мере транспортный формат ESP для HIP [RFC7402]. Выбор транспортного формата происходит во время базового обмена. Ответчик указывает свои предпочтения для транспорта в параметре TRANSPORT_FORMAT_LIST пакета R1, а Инициатор выбирает один из форматов и включает соответствующий параметр HIP в пакет I2.

4.5.4. Перезагрузка, тайм-аут и перезапуск HIP

Имитация потери состояния является одной из возможных DoS-атак. Ниже описан процесс управления восстановлением состояния, не открывающий возможности для DoS-атак.

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

Если система получает пакет пользовательских данных, который не соответствует имеющейся ассоциации HIP, это может говорить о потере состояния при его сохранении у партнёра. Система может передать пакет ICMP типа Parameter Problem с полем Pointer, указывающим связанную с ассоциацией HIP информацию. Реакция на такие пакет зависит от реализации и среды её применения.

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

4.6. Распространение сертификатов

Этот документ не задаёт способы использования сертификатов и их передачи между хостами. Предполагается определение этих функций в будущей спецификации, как было сделано для HIP версии 1 (см. [RFC6253]). Однако значение типа параметра для переноса сертификатов зарезервировано (CERT, Type 768), см. параграф 5.2.

5. Формат пакетов

5.1. Формат данных

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header   | Header Length |0| Packet Type |Version| RES.|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Checksum             |           Controls            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Sender's Host Identity Tag (HIT)               |
|                                                               |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               Receiver's Host Identity Tag (HIT)              |
|                                                               |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                        HIP Parameters                         /
/                                                               /
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Все пакеты HIP начинаются с показанного ниже фиксированного заголовка.

Логически заголовок HIP является заголовком расширения IPv6, однако этот документ не описывает обработку значений Next Header, отличающихся от 59 (IPPROTO_NONE), означающего отсутствие последующих заголовков. Будущие документы могут задать поведение для других значений, однако текущие реализации должны игнорировать последующие данные при получении нереализованного значения Next Header.

Поле Header Length указывает общий размер HIP Header и HIP Parameters в 8-байтовых блоках без учёта первых 8 байтов. Поскольку заголовки HIP должны включать теги HIT отправителя и получателя, минимальное значение этого поля составляет 4, а максимальный размер поля HIP Parameters — (255 * 8) — 32 = 2008 байтов (см. параграф 5.1.3 по части фрагментации HIP). Отметим, что это задаёт дополнительное ограничение на размер параметров в поле HIP Parameters, независимо от максимального размера отдельных параметров.

Поле Packet Type указывает тип пакета HIP. Конкретные типы пакетов указаны ниже в соответствующих параграфах. При получении хостом HIP пакета HIP нераспознанного типа этот пакет должен отбрасываться.

Поле HIP Version занимает 4 бита, данный документ определяет версию 2. Предполагается увеличение номера версии лишь при внесении в протоколо изменений, не совместимых с прежней версией. Большинство расширений может обрабатываться за счёт определения новых типов пакетов, параметров или элементов управления Control (см. параграф 5.1.2). Три следующих бита зарезервированы на будущее и должны сбрасываться в 0 при передаче, а получатель должен игнорировать их.

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

Поля HIT всегда имеют размер 128 битов (16 байтов).

5.1.1. Контрольная сумма

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

Если для пакета HIP используется протокол IPv6, псевдозаголовок [RFC2460] содержит адреса отправителя и получателя IPv6, размер пакета HIP в поле Length псевдозаголовка, нулевое поле и номер протокола HIP (см. параграф 5.1) в поле Next Header. Поле Length указывает размер в байтах и может быть рассчитано из поля HIP Header Length

   (HIP Header Length + 1) * 8

В случае IPv4 используется формат псевдозаголовка IPv4 UDP [RFC0768]. В псевдозаголовке используются адреса отправителя и получателя из заголовка IP, нулевое поле, номер протокола HIP (см. раздел 4) и размер, определяемый как для IPv6.

5.1.2. Поле HIP Controls

Поле HIP Controls переносит информацию о структуре пакета и созможностях хоста. В настоящее время определён лишь 1 бит.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | | | | | | | | | | | |A|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

A — Anonymous

Установка этого бита говорит о том, что HI отправителя этого пакета является анонимным, т. е. не включён в каталог. Сохранять анонимные HI не следует. Партнёр, получивший анонимный HI в пакете R1 или I2, может отвергнуть этот пакет.

Остальные биты зарезервированы на будущее и должны сбрасываться в 0 при передаче, а получатель должен игнорировать их.

5.1.3. Поддержка фрагментации HIP

Реализация HIP должна поддерживать фрагментацию и сборку IP. Сборка фрагментов должна быть реализована для IPv4 и IPv6, а фрагментацию требуется реализовать для IPv4 (стек и сети IPv4 обычно делают это по умолчанию) и рекомендуется для IPv6. В сетях IPv6 минимальное значение MTU (1280 байтов) больше чем в IPv4. Большего размера MTU обычно достаточно для большинства пакетов HIP, поэтому фрагментация может не потребоваться. Если предполагается передача пакетов HIP больше минимального IPv6 MTU, реализация должна поддерживать создание фрагментов даже для IPv6.

В сетях IPv4 пакеты HIP могут сталкиваться с малым значением MTU на пути передачи. Поскольку базовый протокол HIP, заданный этим документов, не включает механизма использования нескольких дейтаграмм IP для одного пакета HIP, поддержка обнаружения MTU на пути не имеет значения для HIP в сетях IPv4. Понимающим HIP устройствам NAT следует выполнять фрагментацию и сборку для пакетов HIP.

Реализации HIP должны соблюдать осторожность в алгоритмах сборки фрагментов для устойчивости к DoS-атакам.

Использование цепочек сертификатов может приводить к фрагментации пакетов, а та может открывать возможность для DoS-атак [KAU03]. Можно применять схему «хэш и URL», определённую в [RFC6253] для HIP версии 1, чтобы избежать фрагментации и смягчить DoS-атаки.

5.2. Параметры HIP

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

TLV	Тип	Размер	Данные
R1_COUNTER	129	12	Счётчик генерации Puzzle.
PUZZLE	257	12	#K и Random #I.
SOLUTION	321	20	#K, Random #I и решение головоломки #J.
SEQ	385	4	Идентификатор пакета UPDATE.
ACK	449	переменный	Идентификатор пакета UPDATE.
DH_GROUP_LIST	511	переменный	Упорядоченный список DH Group ID, поддерживаемых хостом.
DIFFIE_HELLMAN	513	переменный	Открытый ключ.
HIP_CIPHER	579	переменный	Список алгоритмов шифрования HIP.
ENCRYPTED	641	переменный	Шифрованная часть пакета HIP.
HOST_ID	705	переменный	Host Identity с FQDN или NAI.
HIT_SUITE_LIST	715	переменный	Упорядоченный список HIT Suite, поддерживаемых Ответчиком.
CERT	768	переменный	Сертификат HI (задан в отдельном документе).
NOTIFICATION	832	переменный	Информационные сведения.
ECHO_REQUEST_SIGNED	897	переменный	Подписанные Opaque data для возврата
ECHO_RESPONSE_SIGNED	961	переменный	Подписанные Opaque data, возвращаемые по запросу.
TRANSPORT_FORMAT_LIST	2049	переменный	Упорядоченный список предпочтительных номеров типов транспорта HIP.
HIP_MAC	61505	переменный	Код аутентификации сообщения HMAC с ключевым материалом из KEYMAT.
HIP_MAC_2	61569	переменный	Код аутентификации сообщения HMAC с ключевым материалом из KEYMAT. В отличие от HIP_MAC, в расчёт HIP_MAC_2 включается параметр HOST_ID.
HIP_SIGNATURE_2	61633	переменный	Подпись, используемая в пакете R1.
HIP_SIGNATURE	61697	переменный	Подпись, используемая в пакете R1.
ECHO_REQUEST_UNSIGNED	63661	переменный	Opaque data для возврата после подписи
ECHO_RESPONSE_UNSIGNED	63425	переменный	Opaque data, возвращаемые по запросу, после подписи.

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

Диапазон типов	Назначение
0 — 1023	Согласование.
1024 — 2047	Резерв.
2048 — 4095	Параметры, относящиеся к транспортным форматам HIP.
4096 — 8191	Подписываемые параметры, выделенные соответствующими спецификациями.
8192 — 32767	Резерв.
32768 — 49151	Подписываемые параметры. Резерв для приватного использования.
49152 — 61439	Резерв.
61440 — 62463	Подписи и (подписанные) MAC.
62464 — 63487	Параметры, для которых не применяются подписи и MAC.
63488 — 64511	Rendezvous и ретрансляция.
64512 — 65023	Параметры, для которых не применяются подписи и MAC.
65024 — 65535	Резерв.

Процедура определения новых параметров описана в параграфе 5.2.2. Диапазон от 32768 (215) до 49151 (215 + 214) зарезервирован для приватного использования (Reserved for Private Use) и типы из него следует выбирать случайным образом для снижения вероятности конфликтов.

5.2.1. Формат TLV

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

Параметры типов 2048 — 4095 относятся к транспортному формату. В настоящее время определён лишь формат ESP [RFC7402].

Все параметры TLV имеют размер (с учётом полей Type и Length), кратный 8 байтам. При необходимости в параметр должно добавляться заполнение до кратного 8 байтам размера. Это правило обеспечивает корректное выравнивание данных. В байтах заполнения отправитель должен устанавливать значение 0, а получателю не следует проверять эти значения.

Поле Length указывает размер поля Contents (в байтах), поэтому общий размер параметра TLV (поля Type, Length, Contents, Padding) связан со значением поля Length выражением 11 + Length — (Length + 3) % 8, где % указывает деление по модулю.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type            |C|             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
/                          Contents                             /
/                                               +-+-+-+-+-+-+-+-+
|                                               |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Код типа параметра размером 16 битов, бит C является частью поля Type.

C

Бит критичности параметра. Устанавливается (1) для параметров, которые получатель должен распознавать, и сбрасывается в остальных случаях. Бит C является частью поля Type, поэтому критичные параметры всегда имеют нечетное значение типа, некритичные — четное.

Length

Размер поля Contents в байтах. Поля Type, Length, Padding не учитываются.

Contents

Зависит от типа параметра.

Padding

Заполнение до 7 байтов при необходимости.

Критические параметры (нечетное значение типа) должны распознаваться получателем. Если получатель встречает неизвестные критический параметр, дальнейшая обработка пакета недопустима. Получатель может передать сообщение ICMP или пакет NOTIFY, как указано в параграфе 4.3. Некритические параметры можно игнорировать и получателю, встретившему такой неизвестный параметр, следует продолжать обработку пакета, как будто параметра нет.

5.2.2. Определение новых параметров

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

1. Младший бит (C) в коде типа служит для указания критических параметров. Поэтому типы с нечетным номером всегда задают критические параметры.

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

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

4. Правила выделения кодов Type приведены в разделе 9.

5.2.3. R1_COUNTER

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Reserved, 4 байта                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                R1 generation counter, 8 байтов                |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

129

Length

12

R1 generation counter

Текущее поколение действительных головоломок.

Параметр R1_COUNTER содержит 64-битовое целое число без знака с сетевым порядком байтов, указывающее текущее поколение действительных головоломок. Отправителю следует периодически инкрементировать этот счётчик. рекомендуется инкрементировать счётчик не реже отмены старых значений PUZZLE, чтобы значения SOLUTION для них больше не принимались.

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

5.2.4. PUZZLE

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  #K, 1 byte   |    Lifetime   |        Opaque, 2 bytes        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Random #I, RHASH_len / 8 байтов          |
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

257

Length

4 + RHASH_len / 8

#K

Число проверяемых битов.

Lifetime

Срок действия головоломки — 2^{(Lifetime — 32)} секунд.

Opaque

Данные, установленные Ответчиком для индексирования головоломки.

Random #I

Случайное значение размером RHASH_len битов.

Random #I представляется целым числом размером n битов (n = RHASH_len), а #K и Lifetime — 8-битовыми целыми числами с сетевым порядком байтов.

Параметр PUZZLE указывает сложность головоломки #K и n-битовое случайное целое число Random #I. Поле Lifetime указывает время, в течение которого действует решение головоломки, и ограничивает время, которое Инициатор может потратить на решение задачи. Срок действия указывается степенью 2 и фактический срок составляет 2^{(Lifetime — 32)} секунд. Задача может быть дополнена параметром ECHO_REQUEST_SIGNED или ECHO_REQUEST_UNSIGNED, включаемым в пакет R1. Содержимое запроса возвращается в параметре ECHO_RESPONSE_SIGNED или ECHO_RESPONSE_UNSIGNED, позволяя Ответчику использовать значение как часть обработки головоломки.

Поля Opaque и Random #I не учитываются в параметре HIP_SIGNATURE_2.

5.2.5. SOLUTION

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  #K, 1 byte   |   Reserved    |        Opaque, 2 bytes        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Random #I, n байтов                      |
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Puzzle solution #J, RHASH_len / 8 байтов             |
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

321

Length

4 + RHASH_len / 4

#K

Число проверяемых битов.

Reserved

0 при передаче, игнорируется при получении.

Opaque

Копируется без изменений из полученного параметра PUZZLE.

Random #I

Случайное значение размером RHASH_len битов.

Puzzle solution #J

Случайное значение размером RHASH_len битов.

Random #I и Random #J представляются целами числами без знака размером n битов (n = RHASH_len), а #K — 8-битовое целое число без знака. Все числа используют сетевой порядок байтов.

Параметр SOLUTION содержит решение головоломки. Он возвращает случайное значение сложности #K, поле Opaque и целочисленное представление головоломки #I.

5.2.6. DH_GROUP_LIST

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DH GROUP ID #1| DH GROUP ID #2| DH GROUP ID #3| DH GROUP ID #4|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DH GROUP ID #n|                Padding                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

511

Length

Число DH Group ID.

DH GROUP ID

Идентификатор группы DH, поддерживаемой хостом. Список ID упорядочивается по предпочтениям хоста. Возможные DH Group ID указываются в параметре DIFFIE_HELLMAN. Размер DH Group ID составляет 1 октет.

Параметр DH_GROUP_LIST содержит список поддерживаемых хостом DH Group ID. Инициатор передаёт DH_GROUP_LIST в пакете I1, а Ответчик Responder передаёт свой список в подписанной чати пакета R1. DH Group ID в DH_GROUP_LIST указываются в порядке снижения предпочтений хоста, передающего список. Информация в DH_GROUP_LIST позволяет Ответчику выбрать предпочтительную группу DH, поддерживаемую Инициатором. На основе DH_GROUP_LIST в пакете R1 Инициатор может определить, выбрал ли Ответчик наилучший вариант из числа предпочитается обеими сторонами. Если Ответчик выбрал не лучший вариант, Инициатор может считать это попыткой атаки на понижение (см. параграф 4.1.7).

При выборе группы DH для параметра DIFFIE_HELLMAN в пакете R1 Ответчик должен выбрать первый идентификатор DH Group ID из своего DH_GROUP_LIST в пакете R1, который совместим с одним из Suite ID списке Инициатора DH_GROUP_LIST из пакета I1. Ответчику недопустимо выбирать какой-либо иной DH Group ID из числа содержащихся в обоих списках во избежание незамеченной атаки на понижение.

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

5.2.7. DIFFIE_HELLMAN

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Group ID    |      Public Value Length      | Public Value  /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                               |            Padding            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

513

Length

Размер в октетах без учёта Type, Length, Padding.

Group ID

Указывает значения для p и g, а также KDF.

Public Value Length

Размер следующего поля Public Value в октетах.

Public Value

Открытый ключ DH отправителя.

Один параметр DIFFIE_HELLMAN может быть включён в выбранный пакет HIP на основе выбранного идентификатора DH Group ID (параграф 5.2.6). Ниже перечислены определённые в настоящее время Group ID со значениями.

Группа	KDF	Значение
Резерв		0
Отменена		1
Отменена		2
1536-bit MODP group [RFC3526]	HKDF [RFC5869]	3
3072-bit MODP group [RFC3526]	HKDF [RFC5869]	4
Отменена		5
Отменена		6
NIST P-256 [RFC5903]	HKDF [RFC5869]	7
NIST P-384 [RFC5903]	HKDF [RFC5869]	8
NIST P-521 [RFC5903]	HKDF [RFC5869]	9
SECP160R1 [SECG]	HKDF [RFC5869]	10
2048-битовая группа MODP [RFC3526]	HKDF [RFC5869]	11

Группы MODP DH определены в [RFC3526], группы ECDH 7-9 — в [RFC5903] и [RFC6090], ECDH 10 описана в Приложении D. Любые группы ECDH, используемые с HIP, должны иметь коэффициент (co-factor) 1.

Group ID указывает также функцию вывода ключей для создания симметричных ключей для HMAC и симметричного шифрования из обмена ключами DH (см. параграф 6.5).

Реализации HIP должны поддерживать Group ID 3. 160-битовая группа SECP160R1 может применяться при невысоких требованиях к защите (например, для просмотра web) или при ограниченных возможностях оборудования (например, в некоторых PDA). Разработчикам следует реализовать Group ID 4 и 8.

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

5.2.8. HIP_CIPHER

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Cipher ID #1         |          Cipher ID #2         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Cipher ID #n         |             Padding           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

579

Length

Размер в октетах без учёта Type, Length, Padding.

Cipher ID

Идентификатор алгоритма, используемого для шифрования параметра ENCRYPTED. Ниже перечислены определённые в настоящее время Cipher ID.

Suite ID	Значение
Резерв	0
NULL-ENCRYPT	1 ([RFC2410])
AES-128-CBC	2 ([RFC3602])
Резерв	3 (не используется)
AES-256-CBC	4 ([RFC3602])

Отправитель параметра HIP_CIPHER должен обеспечить в нем не более 6 полей Cipher ID, а получатель должен быть готов обрабатывать параметры, содержащие более 6 полей Cipher ID, воспринимая из них 6 первых и отбрасывая остальные. Ограничение числа Cipher ID определяет максимальный размер параметра HIP_CIPHER. По умолчанию параметр HIP_CIPHER должен включать хотя бы один обязательный Cipher ID. Может применяться параметр конфигурации для переопределения администратором заданного по умолчанию идентификатора.

Ответчик указывает поддерживаемые и желаемые Cipher ID (до 6) в порядке предпочтения в пакете R1, а Инициатор должен выбрать из них лишь один Cipher ID, который применяется для генерации параметра ENCRYPTED.

Обязательная реализация — AES-128-CBC. Разработчикам следует поддерживать NULL-ENCRYPT для тестирования и отладки, но недопустимо предлагать или воспринимать его, если явно не задано тестирование или отладка HIP.

5.2.9. HOST_ID

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          HI Length            |DI-Type|      DI Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Algorithm            |         Host Identity         /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                               |       Domain Identifier       /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                                               |    Padding    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

705

Length

Размер в октетах без учёта Type, Length, Padding.

HI Length

Размер поля Host Identity в октетах.

DI-Type

Тип следующего поля Domain Identifier.

DI Length

Размер поля Domain Identifier в октетах.

Algorithm

Индекс используемого алгоритма.

Host Identity

Фактическое значение Host Identity.

Domain Identifier

Идентификатор отправителя.

Определённые в настоящее время значения DI-Type приведены в таблице.

Тип	Значение
Не включено	0
FQDN	1
NAI	2

FQDN

Полное доменное имя (Fully Qualified Domain Name) в двоичном формате.

NAI

Идентификатор доступа в сеть (Network Access Identifier).

Формат FQDN определён в параграфе 3.1 RFC 1035 [RFC1035], формат NAI — в [RFC4282].

Хост может связать Host Identity с одним Domain Identifier в параметре HOST_I. При отсутствии Domain Identifier (DI-Type = 0), в поле DI Length также устанавливается 0.

Определённые в настоящее время HI Algorithm перечислены ниже.

Профили алгоритмов	Значения
Резерв	0
DSA	3 [FIPS.186-4.2013] (рекомендуется)
RSA	5 [RFC3447] (требуется)
ECDSA	7 [RFC4754] (требуется)
ECDSA_LOW	9 [SECG] (рекомендуется)

Для ключей DSA, RSA, ECDSA следует применять профили, содержащие по меньшей мере 112 битов «силы защиты» (как определено в [NIST.800-131A.2011]). Для дополнения подписи RSA должно применяться заполнение по методу вероятностной схемы подписи (Probabilistic Signature Scheme или PSS) [RFC3447].

Host Identity выводится из формата DNSKEY для RSA и DSA. Для этого применяется поле Public Key части RDATA из RFC 4034 [RFC4034]. Для криптографии на основе эллиптических кривых (Elliptic Curve Cryptography или ECC) выделены два профиля — ECDSA и ECDSA_LOW. ECC содержит кривые, одобренные NIST и определённые в RFC 4754 [RFC4754]. Профиль ECDSA_LOW определён для устройств с ограниченными вычислительными возможностями и использует более короткие кривые из Standards for Efficient Cryptography Group [SECG]. При использовании ECDSA с HIP должен применяться коэффициент 1.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          ECC Curve            |                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                         Public Key                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Для ECDSA и ECDSA_LOW отождествление хоста (Host Identity) представляется двумя полями.

ECC Curve

Метка кривой.

Public Key

Открытый ключ в форме строки октетов Represented [RFC6090].

Для хостов, применяющих ECDSA в качестве алгоритма, требуются указанные ниже кривые ECC.

Алгоритм	Кривая	Значения
ECDSA	Резерв	0
ECDSA	NIST P-256	1 [RFC4754]
ECDSA	NIST P-384	2 [RFC4754]

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

Алгоритм	Кривая	Значения
ECDSA_LOW	Резерв	0
ECDSA_LOW	SECP160R1	1 [SECG]

5.2.10. HIT_SUITE_LIST

Параметр HIT_SUITE_LIST содержит список поддерживаемых Ответчиком HIT Suite ID. Ответчик передает HIT_SUITE_LIST в подписанной части пакета R1. На основе HIT_SUITE_LIST Инициатор может определить, какие наборы из исходного списка HIT Suite ID поддерживает Ответчик.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     ID #1     |     ID #2     |     ID #3     |     ID #4     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     ID #n     |                Padding                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

715

Length

Число HIT Suite ID

ID

Однооктетный идентификатор HIT Suite, поддерживаемого хостом. Список идентификаторов упорядочивается по уровню предпочтения. 4 старших бита поля ID соответствуют HIT Suite ID в поле ORCHID OGA ID, а младшие биты являются резервными и устанавливаются отправителем в 0. Получение ID с отличными от 0 четырьмя младшими битами следует считать ошибкой, которая может вести к отправке NOTIFICATION типа UNSUPPORTED_HIT_SUITE.

HIT Suite ID индексирует HIT Suite, включающие алгоритмы подписи, как указано в параграфе 5.2.9, и хэш-функции.

Поле ID в HIT_SUITE_LIST является 8-битовым в отличие от 4-битовых HIT Suite ID и OGA ID в ORCHID. Это предназначено для расширения пространства HIT Suite ID, если 16 доступных значений будет недостаточно. В этом случае значение 0 (одно из 16) указывает, что 4 дополнительных бита ORCHID будут служить для кодирования HIT Suite ID. Текущие 4-битовые HIT Suite ID используют лишь старшие биты поля I, а в будущих документах может быть определено использование 4 младших битов поля ID.

Ниже перечислены определённые в настоящее время HIT Suite ID и связи между 4-битовыми ID, применяемыми в поле OGA ID, и 8-битовым представлением в HIT_SUITE_LIST ID.

HIT Suite	4-битовый идентификатор	8-битовое кодирование
Резерв	0	0x00
RSA,DSA/SHA-256	1	0x10 (требуется)
ECDSA/SHA-384	2	0x20 (рекомендуется)
ECDSA_LOW/SHA-1	3	0x30 (рекомендуется)

В таблице 10 комбинации HIT Suite представлены более подробно. Каждый алгоритм генерации принимает на входе идентификатор HI, как указано в параграфе 3.2. Результат размером 96 битов напрямую используется в ORCHID.

Таблица 10. Наборы HIT Suite.

Индекс	Хэш-функция	HMAC	Семейство алгоритмов подписи	Описание
0				Резерв
1	SHA-256	HMAC-SHA-256	RSA, DSA	RSA или DSA HI хешируется SHA-256 и отсекается до 96 битов.
2	SHA-384	HMAC-SHA-384	ECDSA	ECDSA HI хешируется SHA-384 и отсекается до 96 битов.
3	SHA-1	HMAC-SHA-1	ECDSA_LOW	ECDSA_LOW HI хешируется SHA-1 и отсекается до 96 битов.

Хэш Ответчика, как указано в HIT Suite, определяет код HMAC, применяемый для функции RHASH. В настоящее время определены кода HMAC-SHA-256 [RFC4868], HMAC-SHA-384 [RFC4868], HMAC-SHA-1 [RFC2404].

5.2.11. TRANSPORT_FORMAT_LIST

Параметр TRANSPORT_FORMAT_LIST содержит список поддерживаемых Ответчиком форматов транспорта HIP (TF) и передаётся в подписанной части пакета R1. На основе TRANSPORT_FORMAT_LIST Инициатор выбирает 1 подходящий транспорт в своём пакете отклика.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          TF type #1           |           TF type #2          /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/          TF type #n           |             Padding           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

2049

Length

Удвоенное число типов TF.

TF Type

Тип транспортного формата (TF), поддерживаемого хостом. Номера типов соответствуют номерам параметров HIP для соответствующего транспорта. Список TF упорядочивается по предпочтениям отправителя.

Типы TF индексируют соответствующие параметры HIP для формата транспорта из диапазона 2050 — 4095. Параметры и их применение задают отдельные документы. В настоящее время определён лишь транспорт IPsec ESP [RFC7402].

Для каждого указанного типа TF отправитель TRANSPORT_FORMAT_LIST должен включить в пакет HIP соответствующий параметр формата транспорта. Получатель должен игнорировать тип TF в TRANSPORT_FORMAT_LIST при отсутствии в пакете соответствующего параметра транспортного формата.

5.2.12. HIP_MAC

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                             HMAC                              |
/                                                               /
/                               +-------------------------------+
|                               |            Padding            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

61505

Length

Размер в октетах без учёта Type, Length, Padding.

HMAC

Код HMAC рассчитанный для пакета HIP без учёта HIP_MAC и последующих параметров, таких как HIP_SIGNATURE, HIP_SIGNATURE_2, ECHO_REQUEST_UNSIGNED, ECHO_RESPONSE_UNSIGNED. В поле Checksum должно устанавливаться значение 0, а поле HIP Header Length в базовом заголовке HIP должно рассчитываться без учёта исплюченных при вычислении HMAC параметров. Размер HMAC является естественным размером вывода применяемой хэш-функции.

HMAC использует RHASH как алгоритм хэширования. Расчёт и проверка описаны в параграфе 6.4.1.

5.2.13. HIP_MAC_2

HIP_MAC_2 — это код MAC пакета и HI отправителя в форме параметра HOST_ID, когда этот параметр фактически в пакет не включен. Структура параметра описана в параграфе 5.2.12.

Type

61569

Length

Размер в октетах без учёта Type, Length, Padding.

HMAC

Код HMAC рассчитанный для пакета HIP без учёта HIP_MAC_2 и последующих параметров, таких как HIP_SIGNATURE, HIP_SIGNATURE_2, ECHO_REQUEST_UNSIGNED, ECHO_RESPONSE_UNSIGNED. В поле Checksum должно устанавливаться значение 0, а поле HIP Header Length в базовом заголовке HIP должно рассчитываться без учёта исплюченных при вычислении HMAC параметров. Размер HMAC является естественным размером вывода применяемой хэш-функции.

HMAC использует RHASH как алгоритм хэширования. Расчёт и проверка описаны в параграфе 6.4.1.

5.2.14. HIP_SIGNATURE

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    SIG alg                    |            Signature          /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                               |             Padding           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

61697

Length

Размер в октетах без учёта Type, Length, Padding.

SIG alg

Алгоритм подписи.

Signature

Подпись рассчитывается для пакета HIP без параметра HIP_SIGNATURE и следующих за ним параметров. При расчёте подписи для поля Checksum должно устанавливаться значение 0, а поле HIP Header Length в базовом заголовке HIP должно рассчитываться лишь до начала параметра HIP_SIGNATURE.

Алгоритм подписи определён в параграфе 5.2.9. Поле Signature кодируется в зависимости от применяемого алгоритма (например, в соответствии с [RFC3110] для RSA/SHA-1, [RFC5702] для RSA/SHA-256, [RFC2536] для DSA, [RFC6090] для ECDSA). Расчёт и проверка HIP_SIGNATURE описаны в параграфе 6.4.2.

5.2.15. HIP_SIGNATURE_2

HIP_SIGNATURE_2 исключает переменные параметры пакета R1 для создания R1 заранее. Структура параметра описана в параграфе 5.2.14.

Type

61633

Length

Размер в октетах без учёта Type, Length, Padding.

SIG alg

Алгоритм подписи.

Signature

В пакете R1 с параметром HIP_SIGNATURE_2 поля HIT Инициатора, Checksum, а также Opaque и Random #I в PUZZLE должны иметь значение 0 при расчёте подписи HIP_SIGNATURE_2. Поле HIP Header Length в базовом заголовке HIP должно быть скорректировано, как будто при расчёте подписи параметра HIP_SIGNATURE_2 не было в пакете, т. е. HIP Header Length указывает при проверке и подписывании начало HIP_SIGNATURE_2.

Обнуление HIT Инициатора позволяет создать пакеты R1 заранее для минимизации последствий возможных DoS-атак. Обнуление Random #I и Opaque в параметре PUZZLE позволяет динамически заполнять эти поля в заранее созданных R1. Расчёт и проверка HIP_SIGNATURE_2 описаны в параграфе 6.4.2.

5.2.16. SEQ

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Update ID                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

385

Length

4

Update ID

32-битовый порядковый номер.

Update ID является целым числом без знака с сетевым порядком байтов и хост устанавливает для него значение 0 при переходе в состояние ESTABLISHED. Update ID действует в одной ассоциации HIP, не переходя в другие ассоциации или хосты. Update ID увеличивается на 1 перед каждым пакетом UPDATE, передаваемым хостом. В первом UPDATE от хоста Update ID = 0.

5.2.17. ACK

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       peer Update ID 1                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                       peer Update ID n                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

449

Length

Размер в октетах без учёта Type, Length

peer Update ID

32-битовый порядковый номер, соответствующий полю Update ID в подтверждаемом пакете.

Параметр ACK включает одно или несколько полей Update ID для полученных от партнёра пакетов. Число полей определяется делением поля Length на 4.

5.2.18. ENCRYPTED

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Reserved                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              IV                               /
/                                                               /
/                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
/                        Encrypted data                         /
/                                                               /
/                               +-------------------------------+
/                               |            Padding            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

641

Length

Размер в октетах без учёта Type, Length, Padding

Reserved

0 при передаче, игнорируется при получении.

IV

Вектор инициализации (при необходимости), размер которого выводится из HIP_CIPHER.

Encrypted data

Данные, зашифрованные с использованием алгоритма, указанного параметром HIP_CIPHER.

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

Поле Encrypted data содержит шифрованный вывод конкатенации параметров HIP. Каждый из этих «внутренних» параметров дополняется в соответствии с правилами параграфа 5.2.1. В результате размер конкатенации параметров кратен 8 байтам.

Некоторые алгоритмы шифрования требуют, чтобы размер шифруемых данных был кратным размеру блока шифрования. В этом случае упомянутый выше блок должен включать дополнительное заполнение до нужного размера (кратного размеру блока шифрования). Алгоритм шифрования может задавать заполнение, отличное от 0, например, в AES [FIPS.197.2001] применяется схема заполнения PKCS5 (см. параграф 6.1.1 в [RFC2898]) где для заполнения n байтов применяется значение n. Это даёт блок «нешифрованных данных», которые преобразуются в «шифрованный блок». Дополнительное заполнение добавляется к набору параметров для выполнения требований к выравниванию шифруемых блоков и не учитывается в полях HIP TLV Length, а после расшифровки удаляется.

Отметим, что размер данных после шифрования может отличаться от исходного, поскольку при шифровании может применяться сжатие или дополнение данных. По завершении процесса шифрования поле Encrypted data готово для включения в параметр. При необходимости добавляется поле Padding для выравнивания (см. параграф 5.2.1).

5.2.19. NOTIFICATION

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

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Reserved             |      Notify Message Type      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               /
/                   Notification Data                           /
/                                               +---------------+
/                                               |     Padding   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

832

Length

Размер в октетах без учёта Type, Length, Padding.

Reserved

0 при передаче, игнорируется при получении.

Notify Message Type

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

Notification Data

Информация или сведения об ошибке, дополняющие Notify Message Type и зависящие от типа (см. ниже).

Сведения из уведомлений могут включать сообщения об ошибках, указывающие причину отказа при создании HIP Security Association, а также информацию о состоянии, которую реализация HIP хочет передать партнеру. Список уведомлений со значениями Notify Message Type приведён ниже. Пакет HIP может включать несколько параметров NOTIFICATION при необходимости передать несколько разных уведомлений. Для предотвращения некоторых типов атак Ответчику следует избегать отправик NOTIFICATION хосту, который не прошёл проверку с помощью головоломки (puzzle solution).

Notify Message Type из диапазона 0-16383 предназначены для информирования об ошибках, а 16384-65535 — для сведений о состоянии. Реализации, получившей пакет NOTIFY с Notify Message Type, указывающим ошибку, в ответ на пакет запроса (например, I1, I2, UPDATE) следует считать, что соответствующий запрос привел к полному отказу. Неизвестные типы ошибок должны игнорироваться, но это следует вносить в системный журнал.

В настоящее время Notify Message Type из диапазона 1-10 служат для информирования об ошибках в структуре пакетов, 11-20 — о проблемах в параметрах.

Поле Notification Data в параметре NOTIFICATION, где Notify Message Type относится к диапазону состояний, должно игнорироваться, если оно не распознано.

Notify Message Type для ошибок

UNSUPPORTED_CRITICAL_PARAMETER_TYPE 1

Передаётся для нераспознанного параметра с установленным битом C. В поле Notification Data указывается 2-октетный типа параметра.

INVALID_SYNTAX 7

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

NO_DH_PROPOSAL_CHOSEN 14

Ни один из предложенных Group ID не приемлем.

INVALID_DH_CHOSEN 15

Поле DH Group ID не соответствует предложенным Ответчиком.

NO_HIP_PROPOSAL_CHOSEN 16

Ни один из предложенных HIT Suite или HIP Encryption Algorithm не приемлем.

INVALID_HIP_CIPHER_CHOSEN 17

HIP_CIPHER Crypto ID не соответствует предложенным Ответчиком.

UNSUPPORTED_HIT_SUITE 20

Передаётся в ответ на I1 или R1, для которого HIT Suite не поддерживается.

AUTHENTICATION_FAILED 24

Передаётся при ошибке в подписи HIP, за исключением случаев отказа при проверке подписи в NOTIFY.

CHECKSUM_FAILED 26

Передаётся при ошибке в контрольной сумме HIP.

HIP_MAC_FAILED 28

Передаётся при ошибке в HIP HMAC.

ENCRYPTION_FAILED 32

Ответчик не смог расшифровать параметр ENCRYPTED.

INVALID_HIT 40

Передаётся при отказе в процессе проверки HIT партнёра по соответствующему HI.

BLOCKED_BY_POLICY 42

Ответчик не хочет воспринимать ассоциацию в соответствии с политикой (например, при получении HIT = NULL, если политика не разрешает режим Opportunistic).

RESPONDER_BUSY_PLEASE_RETRY 44

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

Notify Message Type для состояния

I2_ACKNOWLEDGEMENT 16384

Ответчик получил пакет I2 от Инициатора, но его пришлось поместить в очередь на обработку. Головоломка была решена верно и Ответчик хочте организовать ассоциацию, но в данный момент в очереди находится некотрое число пакетов I2. Пакет R2 передаётся после обработки I2.

5.2.20. ECHO_REQUEST_SIGNED

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Opaque data (переменный размер)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

897

Length

Размер Opaque data в октетах.

Opaque data

Неанализируемый данные, которые имеют смысл лишь для узла, передавшего ECHO_REQUEST_SIGNED и получившего в ответ ECHO_RESPONSE_SIGNED или ECHO_RESPONSE_UNSIGNED

Параметр ECHO_REQUEST_SIGNED содержит неанализируемый блок данных (blob) которые отправитель хочет получить обраьно в соответствующем отклике.

ECHO_REQUEST_SIGNED и соответствующие параметры отклика могут использоваться узлом для любых целей, когда он хочет передать то или иное состояние в запросе и получить его обратно в пакете отклика. Параметр ECHO_REQUEST_SIGNED учитывается в HIP_MAC и SIGNATURE. Пакет HIP может содержать лишь 1 параметр ECHO_REQUEST_SIGNED и может включать несколько параметров ECHO_REQUEST_UNSIGNED. Откликом на ECHO_REQUEST_SIGNED должен быть ECHO_RESPONSE_SIGNED.

5.2.21. ECHO_REQUEST_UNSIGNED

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Opaque data (переменный размер)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

63661

Length

Размер Opaque data в октетах.

Opaque data

Неанализируемые (opaque) данные, которые предполагаются осмысленными лишь для узла, передавшего ECHO_REQUEST_UNSIGNED и получающего соответствующий параметр ECHO_RESPONSE_UNSIGNED.

ECHO_REQUEST_UNSIGNED содержит неанализируемый блок данных (blob), которые отправитель желает получить обратно в отклике.

ECHO_REQUEST_UNSIGNED и соответствующий отклик могут служить для любых целей, когда узел хочет передать в запросе некоторое состояние и получить его обратно в пакете отклика. ECHO_REQUEST_UNSIGNED не учитывается в HIP_MAC и SIGNATURE. Пакет HIP может включать 1 или несколько параметров ECHO_REQUEST_UNSIGNED. Промежуточные устройства могут добавлять параметры ECHO_REQUEST_UNSIGNED в проходящие через них пакеты HIP. Создатель ECHO_REQUEST_UNSIGNED (конечный хост или промежуточное устройство) должен создавать поле Opaque так, чтобы можно было обнаружить и удалить соответствующий параметр ECHO_RESPONSE_UNSIGNED.

В ответ на параметр ECHO_REQUEST_UNSIGNED должен передаваться параметр ECHO_RESPONSE_UNSIGNED.

5.2.22. ECHO_RESPONSE_SIGNED

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Opaque data (переменный размер)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

961

Length

Размер Opaque data в октетах.

Opaque data

Неанализируемые (opaque) данные, которые копируются из параметра ECHO_REQUEST_SIGNED или ECHO_REQUEST_UNSIGNED, вызвавшего этот отклик.

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

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

5.2.23. ECHO_RESPONSE_UNSIGNED

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Type              |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Opaque data (переменный размер)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

63425

Length

Размер Opaque data в октетах.

Opaque data

Неанализируемые (opaque) данные, которые копируются из параметра ECHO_REQUEST_SIGNED или ECHO_REQUEST_UNSIGNED, вызвавшего этот отклик.

ECHO_RESPONSE_UNSIGNED содержит неанализируемый блок данных (blob), которые отправитель ECHO_REQUEST_SIGNED или ECHO_REQUEST_UNSIGNED желает получить обратно. Эти данные копируются из соответствующего параметра запроса.

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

5.3. Пакеты HIP

Имеется 8 основных пакетов HIP (Таблица 11), из которых 4 обеспечивают базовый обмен HIP, 1 служит для обновления, 1 — для уведомлений и 2 для закрытия ассоциации HIP. Поддержка пакетов типа NOTIFY не обязательна, остальные пакеты HIP, перечисленные в таблице 11, должны поддерживаться.

Таблица 11. Типы пакетов HIP.

Тип пакета	Название пакета
1	I1 — пакет Инициатора HIP
2	R1 — пакет Ответчика HIP
3	I2 — второй пакет Инициатора HIP
4	R2 — второй пакет Ответчика HIP
16	UPDATE — пакет HIP Update
17	NOTIFY — пакет HIP Notify
18	CLOSE — пакет HIP Association Closing
19	CLOSE_ACK — пакет HIP Closing Acknowledgment

Пакеты включают фиксированный заголовок (параграф 5.1), за которым могут следовать параметры в формате TLV.

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

Используемые в описаниях пакетов обозначения приведены в параграфе 2.2.

В будущем после заголовка HIP могут быть размещены данные вышележащего уровня. Поле Next Header в заголовке указывает наличие дополнительных данных после заголовка HIP. Пакеты HIP недопустимо фрагментировать на несколько заголовков расширения путём установки в поле Next Header заголовка HIP номера протокола HIP. Это ограничивает размер дополнительных данных в пакете.

5.3.1. I1 — пакет Инициатора HIP

Заголовок HIP для пакета I1 имеет вид

       Packet Type = 1
       SRC HIT = HIT Инициатора
       DST HIT = HIT Ответчика или NULL

     IP ( HIP ( DH_GROUP_LIST ) )

Пакет I1 содержит фиксированный заголовок HIP и список Инициатора DH_GROUP_LIST. Битов управления нет.

Инициатор получает HIT Ответчика из запроса DNS или FQDN Ответчика (см. [HIP-DNS-EXT]), иного репозитория или локальной таблицы. Если Инициатор не знает HIT Ответчика, от может проробовать режим Opportunistic (параграф 4.1.8), установив значение NULL (все нули) как HIT Ответчика.

Поскольку пакет I1 легко подделать (даже подписанный), не предпинимается попыток усложнить его создание и обработку.

Инициатор включает параметр DH_GROUP_LIST в пакет I1 для информирования ответчика о предпочитаемых DH Group ID. Отметим, что DH_GROUP_LIST в пакетах I1 не учитывается в подписи пакета.

Реализации должны быть способны обрабатывать «шквал» пакетов I1, отбрасывая одинаковые пакеты, прибывшие близко по времени.

5.3.2. R1 — пакет Ответчика HIP

Заголовок HIP для пакета R1 имеет вид

       Packet Type = 2
       SRC HIT = HIT Ответчика
       DST HIT = HIT Инициатора

     IP ( HIP ( [ R1_COUNTER, ]
                PUZZLE,
                DIFFIE_HELLMAN,
                HIP_CIPHER,
                HOST_ID,
                HIT_SUITE_LIST,
                DH_GROUP_LIST,
                [ ECHO_REQUEST_SIGNED, ]
                TRANSPORT_FORMAT_LIST,
                HIP_SIGNATURE_2 )
                <, ECHO_REQUEST_UNSIGNED >i)

Бит управления A должен устанавливаться если идентификатор HI Ответчика является анонимным.

Тег HIT Инициатора должен совпадать с одним из полученных в пакете I1, если R1 является откликом на I1. Если у Ответчика имеется несколько HI, используемый HIT Ответчика должен соответствовать запросу Инициатора. Если Инициатор использует режим Opportunistic, Ответчик может свободно выбирать из HI (см. параграф 4.1.8).

Счётчик генерации пакетов R1 служит для определения текущего действительного поколения головоломок. Значение счётчика увеличивается периодически и рекомендуется увеличивать его не реже, чем перестают восприниматься решения прежних голововломок. Головоломка содержит случайное значение Random #I и сложность #K. Сложность указывает число младших битов в результате хэширования головоломки, которые должны быть нулями (см. параграф 4.1.2). Random #I не учитывается в подписи и должно считаться 0 при создании подписи, чтобы отправитель мог установить #I в подготовленном заранее пакете R1 перед его отправкой партнеру.

Ответчик выбирает DIFFIE_HELLMAN Group ID и Public Value в соответствии с предпочтениями Инициатора, указанными параметром DH_GROUP_LIST в пакете I1. Ответчик возвращает свои предпочтения, на основе которых он выбрал открытое значение DH, в DH_GROUP_LIST. Это позволяет Инициатору определить, не был ли список DH_GROUP_LIST в его пакете I1 изменён атакующим.

Открытое значение DH является эфемерным и значения не следует неоднократно применять в разных ассоциациях HIP. Как только Ответчик получил действительный отклик на пакет R1, значение DH следует исключить. Возможна передача Ответчиком одного значения DH одновременно разным хостам в соответствующих пакетах R1 и такие отклики также следует воспринимать. Однако в качестве защиты от «шквала» пакетов I1 реализация может предложить и неоднократно использовать одно значение DH (если этого не избежать) в течение некоторого времени, например, 15 минут. Используя небольшое число разных головоломок для данного значения DH, пакеты R1 можно подготовить заранее и передавать со скоростью получения пакетов I1. Процессу сборки мусора (scavenger) следует очищать неиспользуемые значения DH и головоломки.

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

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

Если Ответчик применяет одну пару ключей DH для нескольких согласования, он должен позаботиться о предотвращении атак на мелкие подгруппы [RFC2785]. Для этого при получении I2 Ответчику следует проверить открытый ключ DH Инициатора, как указано в параграфе 3.1 [RFC2785]. Если проверка не прошла, Ответчику недопустимо создавать общий ключ DH и он должен прервать HIP BEX.

Параметр HIP_CIPHER содержит алгоритмы, поддерживаемые Ответчиком для шифрования содержимого параметра ENCRYPTED, в порядке предпочтительности. Все реализации должны поддерживать AES [RFC3602].

Параметр HIT_SUITE_LIST содержит упорядоченный список предпочитаемых и поддерживамых Ответчиком HIT Suite. Этот список позволяет Инициатору определить соответствует ли его HIT источника поддерживаемому Ответчиком набору.

Параметры ECHO_REQUEST_SIGNED и ECHO_REQUEST_UNSIGNED содержат данные, которые отправитель хочет получить неизменными обратно в параметре ECHO_RESPONSE_SIGNED или ECHO_RESPONSE_UNSIGNED. Пакет R1 можен (но не обязан) влючать один или несколько параметров ECHO_REQUEST_UNSIGNED, как указано в параграфе 5.2.21.

Параметр TRANSPORT_FORMAT_LIST содержит упорядоченный список предпочитаемых и поддерживаемых Ответчиком транспортных форматов. Этот список позволяет Инициатору и Ответчику согласовать общий способ защиты данных (payload). Параметр описан в параграфе 5.2.11.

Подпись рассчитывается для пакета HIP, как указано в параграфе 5.2.15. Это Ответчику заранее создать пакеты R1. Инициатору следует проверять подпись и он должен проверить соответствие HI Ответчика ожидаемому значению.

5.3.3. I2 — второй пакет Инициатора HIP

Заголовок HIP для пакета I2 имеет вид

       Packet Type = 3
       SRC HIT = HIT Инициатора
       DST HIT = HIT Ответчика

     IP ( HIP ( [R1_COUNTER,]
                SOLUTION,
                DIFFIE_HELLMAN,
                HIP_CIPHER,
                ENCRYPTED { HOST_ID } or HOST_ID,
                [ ECHO_RESPONSE_SIGNED, ]
                TRANSPORT_FORMAT_LIST,
                HIP_MAC,
                HIP_SIGNATURE
                <, ECHO_RESPONSE_UNSIGNED>i ) )

Действителен бит управления A, который должен устанавливаться, если HI Инициатора является анонимным.

Теги HIT должны соответствовать указанным в R1.

При наличии в пакете R1 параметра R1_COUNTER Инициатор должен скопировать полученный в R1 параметр в I2.

Параметр Solution содержит Random #I из пакета R1 и рассчитанное значение #J. Младшие #K битов RHASH(#I | … | #J) должны иметь значение 0.

Значение DH является эфемерным. Если расчёт выполняется заранее, процессу сборки мусора следует очищать неиспользуемые значения DH. Ответчик может повторно использовать значения DH при некоторых условиях, как указано в параграфе 5.3.2.

HIP_CIPHER содержит один шифронабор, выбранный Инициатором, который тот использует для шифрования параметров ENCRYPTED. Выбранный шифр должен соответствовать одному из предложенных Ответчиком в пакете R1. Все реализации должны поддерживать AES [RFC3602].

HI Инициатора может быть зашифрован с использованием алгоритма HIP_CIPHER. Ключевой материал выводится из обмена DH, как указано в параграфе 6.5.

ECHO_RESPONSE_SIGNED и ECHO_RESPONSE_UNSIGNED содержат неанализируемые (opaque) данные из соответствующих параметров эхо-запроса.

TRANSPORT_FORMAT_LIST содержит один тип формата транспорта, выбранный Инициатором. Выбранный тип должен соответствовать одному из предложенных Ответчиком в пакете R1. В настоящее премя определён лишь транспортный формат ESP ([RFC7402]).

Значение HMAC в параметре HIP_MAC рассчитывается для всего пакета HIP за исключением параметров после HIP_MAC, как указано в параграфе 6.4.1. Ответчик должен проверять HIP_MAC.

Подпись рассчитывается для всего пакета HIP за исключением параметров после HIP_SIGNATURE, как описано в параграфе 5.2.14. Ответчик должен проверять подпись, используя HI из пакета или идентификатор HI полученный иным способом.

5.3.4. R2 — второй пакет Ответчика HIP

Заголовок HIP для пакета R2 имеет вид

       Packet Type = 4
       SRC HIT = HIT Ответчика
       DST HIT = HIT Инициатора

     IP ( HIP ( HIP_MAC_2, HIP_SIGNATURE ) )

Битов управления нет.

HIP_MAC_2 рассчитывается для всего пакета HIP объединённого (конкатенация) с параметром Ответчика HOST_ID. После расчёта HMAC параметр HOST_ID удаляется, процедура описана в параграфе 6.4.1.

Подпись рассчитывается для всего пакета HIP.

Инициатор должен проверять HIP_MAC и подпись.

5.3.5. UPDATE — пакет обновления HIP

Заголовок HIP для пакета UPDATE имеет вид

       Packet Type = 16
       SRC HIT = HIT отправителя
       DST HIT = HIT получателя

     IP ( HIP ( [SEQ, ACK, ] HIP_MAC, HIP_SIGNATURE ) )

Битов управления нет.

Пакет UPDATE содержит обязательные параметры HIP_MAC и HIP_SIGNATURE, а также необязательные параметры.

Пакет UPDATE может включать 1 параметр SEQ, наличие которого указывает, что получатель должен подтвердить UPDATE. Пакет UPDATE без параметра SEQ, содержащий лишь параметр ACK является просто подтверждением предыдущего UPDATE и его недопустимо подтверждать отдельным параметром ACK. Пакеты UPDATE, содержащие лишь параметр ACK, не требуют обработки в порядке, соответствующем другим пакетам UPDATE. Пакет UPDATE, не включающий параметр SEQ или ACK, является недействительным и для таких неподтверждаемых обновлений должны применяться пакеты NOTIFY.

Пакет UPDATE может включать параметр ACK, содержащий порядковый номер SEQ из подтверждаемого пакета UPDATE. Хост может подтверждать сразу несколько пакетов UPDATE, например, параметр ACK может содержать два полученных последними значения SEQ для устойчивости к потере пакетов. Значения ACK не кумулятивны и для каждого полученного уникального SEQ требуется по меньшей мере одно соответствующее значения ACK в отклике. Полученные избыточные параметры ACK игнорируются. Хосты должны реализовать обработку параметров ACK с несколькими порядковыми номерами SEQ, даже если они не реализуют отправку параметров ACK с несколькими SEQ.

Пакет UPDATE может включать оба параметра SEQ и ACK. В общем случае пакеты UPDATE с параметром SEQ следует подтверждать по завершении обработки UPDATE. Хост может задержать UPDATE с параметром ACK на короткое время, чтобы совместить ACK, подобно отложенным подтверждениям в TCP.

Отправитель может отказаться от гарантированной передачи конкретного UPDATE (например, при перегрузке событиями). В соответствии с семантикой получатель должен подтверждать UPDATE, но отправитель может не заботиться о получении параметра ACK.

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

5.3.6. NOTIFY — пакет уведомления HIP

Пакет NOTIFY может служить для предоставления информации партнёру. Обычно пакеты NOTIFY применяются для указания некоторых ошибок протокола или отказов при согласовании. Пакеты NOTIFY не подтверждаются. Получатель может обработать пакет лишь как информационный и не следует менять состояние HIP (см. параграф 4.4.2) на основе лишь получения пакета NOTIFY.

Заголовок HIP для пакета NOTIFY имеет вид

       Packet Type = 17
       SRC HIT = HIT отправителя
       DST HIT = HIT получателя или 0, если тег неизвестен

     IP ( HIP (<NOTIFICATION>i, [HOST_ID, ] HIP_SIGNATURE) )

Битов управления нет.

Пакеты NOTIFY служат для передачи одного или нескольких параметров NOTIFICATION.

5.3.7. CLOSE — пакет закрытия ассоциации HIP

Заголовок HIP для пакета CLOSE имеет вид

       Packet Type = 18
       SRC HIT = HIT отправителя
       DST HIT = HIT получателя

     IP ( HIP ( ECHO_REQUEST_SIGNED, HIP_MAC, HIP_SIGNATURE ) )

Битов управления нет.

Отправитель должен включать параметр ECHO_REQUEST_SIGNED, используемый для проверки CLOSE_ACK, полученного в отклие, а также HIP_MAC и подпись (для всего пакета HIP).

Получатель должен отвечать пакетом CLOSE_ACK с параметром ECHO_RESPONSE_SIGNED, соответствующим ECHO_REQUEST_SIGNED.

5.3.8. CLOSE_ACK — пакет подтверждения закрытия HIP

Заголовок HIP для пакета CLOSE_ACK имеет вид

       Packet Type = 19
       SRC HIT = HIT отправителя
       DST HIT = HIT получателя

     IP ( HIP ( ECHO_RESPONSE_SIGNED, HIP_MAC, HIP_SIGNATURE ) )

Битов управления нет.

Отправитель должен включать в пакет HMAC и подпись (для всего пакета HIP). Получатель должен проверить ECHO_RESPONSE_SIGNED, а также HIP_MAC и подпись, если у него есть статус ассоциации HIP.

5.4. Сообщения ICMP

Когда реализация HIP обнаруживает проблему со входящим пакетом и не может определить отправителя или не имееет с отправителем ассоциации HIP, она может ответить пакетом ICMP. Частота отправки таких откликов должна быть ограничена в соответствии с [RFC4443]. В большинстве случаев пакет ICMP имеет тип Parameter Problem (12 для ICMPv4, 4 для ICMPv6) с полем Pointer, указывающим вызвавшее генерацию сообщения ICMP поля.

5.4.1. Недействительная версия

Если реализация HIP получает пакет HIP с нераспознанным номером версии HIP, ей следует отвечать пакетом ICMP типа Parameter Problem с полем Pointer, указывающим байт Version/RES. в заголовке пакета HIP. Частоту передачи таких пакетов следует ограничивать.

5.4.2. Другие проблемы в заголовке HIP и структуре пакета

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

5.4.3. Неверное решение Puzzle

Если реализация HIP получает пакет I2 с неверным решением головоломки, её поведение зависит от версии протокола IP. В случае IPv6 рееализации следует отвечать пакетом ICMP типа Parameter Problem с полем Pointer, указывающим начало поля Puzzle solution #J в параметре SOLUTION пакета HIP. При использовании IPv4 реализация может ответить пакетом ICMP типа Parameter Problem, копируя из пакета I2 достаточно байтов, чтобы поместить параметр SOLUTION в сообщение ICMP и указывая в поле Pointer начало поля Puzzle solution #J, как для IPv6. Отметим, что размер сообщения ICMPv4 будет превышать обычный размер ICMPv4, определённый в [RFC0792].

5.4.4. Несуществующая ассоциация HIP

Если реализация HIP получает пакет CLOSE, UPDATE или иной пакет, для обслуживания которого нужна ассоциация, а тег HIT отправителя или получателя не соответствует имеющимся ассоциациям HIP, реализация может ответить пакетом ICMP типа Parameter Problem, ограничивая скорость передачи таких пакетов. Поле Pointer в пакете ICMP Parameter Problem должно указывать начало первого тега HIT, который не соответствует имеющимся ассоциациям.

Хосту недопустимо отвечать такими сообщениями ICMP на пакеты I1, R2, I2, R2, NOTIFY. При определении нового типа пакетов в спецификации следует указать правила в части передачи этого типа сообщений ICMP.

6. Обработка пакетов

На каждом хосте предполагается одна реализация HIP, которая поддерживает HIP-ассоциации хоста и обслуживает запросы на создание новых ассоциаций. Каждая ассоциация управляется концептуальным конечным автоматом, состояния которого определены в параграфе 4.4. Реализация HIP может одновременно поддерживать ассоциации HIP с несколькими хостами и даже может иметь несколько активных ассоциаций с одним хостом, различаемых по тегам HIT. Однако для любой пары HIT невозможно создать более одной ассоциации HIP одновременно, поэтому единственным способом организации между парой хостов нескольких ассоциаций является использование разных HIT.

Обработка пакетов зависит от состояния ассоциаций HIP по отношению к аутентифицированному или представляющемуся инициатором партнёру. Реализация HIP проверяет наличие активной ассоциации с отправителем пакета на основе тегов HIT. Если данные передаются в конкретном транспортном формате, сопоставление пакетов с имеющимися ассоциациями задаёт спецификация транспортного формата.

6.1. Обработка исходящих данных приложения

Приложение на хосте HIP может передавать свои данные, используя идентификатор, заданный через базовый API. Интерфейс API может быть совместимым с прежними версиями (см. [RFC5338]), используя идентификаторы подобно адресам IP, или полностью новым, обеспечивающим расширенные функции для Host Identity. В зависимости от реализации HIP предоставляемый приложению идентификатор может различаться, например, это может быть HIT или адрес IP.

Точный формат и метод передачи пользовательских данных от хоста-источника HIP к адресату HIP определяется соответствующей спецификацией транспортного формата. В сеть данные передаются с использованием подходящих IP-адресов отправителя и получателя.

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

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

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

2. Если в дейтаграмме адрес источника не задан, реализация должна выбрать для дейтаграммы подходящий тег HIT в соответствии с локальной политикой.

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

4. При наличии активной ассоциации HIP для данной пары HIT отправителя и получателя исходящая дейтаграмма передаётся на транспортную обработку. Форматы транспорта определяют отдельные документы, а транспорт ESP для HIP является обязательным во всех реализациях HIP.

5. Перед отправкой пакета теги HIT в дейтаграмме заменяются адресами IP. Для IPv6 следует применять правила [RFC6724]. Отметим, что этап преобразования HIT в адрес IP может выполняться в другой точке стека протоколов, например, перед инкапсуляцией пакета в выходной формат.

6.2. Обработка входящих данных приложения

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

1. Входящая дейтаграмма сопоставляется с имеющимися ассоциациями HIP обычно с использованием информации из пакета. Например, это можно сделать по ESP SPI (Security Parameter Index).

2. Транспортный формат декапсулируется соответствующим способом, давая в результате пакет, подобный обычному (нешифрованному) пакету IP. По возможности на этом этапе следует также проверить, был ли пакет действительно передан (однократно) удаленным хостом HIP, указанным ассоциацией HIP. Метод проверки может меняться в зависимости от режима транспорта. Хотя HI (а также HIT) применяется в качестве идентификатора вышележащего уровня, метод проверки должен подтвердить, что пакет был передан узлом с корректным отождествлением, которое действительно отобразается на соответствующий тег HIT. Для транспорта ESP [RFC7402] проверка выполняется с использованием значения SPI в пакете данных путём поиска соответствующей защищённой связи SA со связанным тегом HIT и ключом, а также расшифровкой пакета с использованием связанного ключа.

3. Адрес IP в дейтаграмме заменяется тегом HIT, связанным с ассоциацией HIP. Отметим, что преобразование адреса IP в тег HIT может выполняться в другом месте стека протоколов.

4. Дейтаграмма доставляется вышележащему уровню (например, UDP или TCP). При демультиплексировании дейтаграммы сокет вылележащего уровня выбирается по тегу HIT.

6.3. Решение головоломки

В этом параграфе рассматривается решение головоломки (puzzle). В пакете R1 значения #I и #K передаются в сетевом порядке байтов, равно как значения #I и #J в пакете I2. Хэш-значение создаётся путём применения алгоритма RHASH к конкатенации (в сетевом порядке) указанных ниже данных.

n-битовое случайное значение #I (n = RHASH_len) с сетевым порядком байтов как в пакетах R1 и I2.

128-битовый тег HIT Инициатора с сетевым порядком байтов как в HIP Payload внутри пакетов R1 и I2.

128-битовый тег HIT Ответчика с сетевым порядком байтов как в HIP Payload внутри пакетов R1 и I2.

n-битовое случайное значение #J (n = RHASH_len) с сетевым порядком байтов как в пакетах R1 и I2.

В действительном решении головоломки #K младших битов результирующего дайджеста RHASH должны быть 0.

Примечания.

1. Размер хэшируемых данных зависит от размера результата хэш-функции RHASH у Ответчика.

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

3. Порядок тегов HIT Инициатора и Ответчика различается в пакетах R1 и I2 (см. параграф 5.1). Нужно соблюдать осторожность при копировании значений на вход функции хэширования.

4. Для головоломки #I может существовать множество верных решений #J.

Ниже указаны процедуры обработки в предположении использования Ответчиком заранее созданных пакетов R1.

Предварительные расчеты Ответчика

Установка сложности головоломки #K.

Создание подписанных пакетов R1 и кэширование их.

Ответчик

Выбор подходящего R1 из кэша.

Генерация случайного значения #I.

Отправка #I и #K в пакете R1.

Сохранение #I и #K на некоторое время (delta).

Инициатор

Повторение попыток решить головоломку, пока не будет найдено соответствующее значение #J:

Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K ) == 0

Отправка #I и #J в пакете I2.

Ответчик

Проверка того, что полученное значение #I было сохранено.

Определение верного #K на основе #I.

Расчет V := Ltrunc( RHASH( #I | HIT-I | HIT-R | #J ), #K )

Отключение при V != 0

Восприятие при V == 0

6.4. Расчёт и проверка HIP_MAC и SIGNATURE

В последующих параграфах определены действия по обработке параметров HIP_MAC, HIP_MAC_2, HIP_SIGNATURE, HIP_SIGNATURE_2. Параметр HIP_MAC_2 содержится в пакетах R2, HIP_SIGNATURE_2 — в R1, а HIP_SIGNATURE и HIP_MAC — в других пакетах HIP.

6.4.1. Расчёт HMAC

Для HMAC применяется функция хэширования RHASH, тип которой зависит от HIT Suite у Ответчика. В HIT Suite RSA/DSA/SHA-256 применяется HMAC-SHA-256 [RFC4868], в ECDSA_LOW/SHA-1 — HMAC-SHA-1 [RFC2404], в ECDSA/SHA-384 — HMAC-SHA-384 [RFC4868].

Описанный ниже процесс применим к параметрам HIP_MAC и HIP_MAC_2. При обработке HIP_MAC_2 отличие от расчётов для HIP_MAC включает псевдо-поле HOST_ID с информацией Ответчика, переданной ранее в пакете R1.

Инициатору и Ответчику следует проявлять осторожность при проверке и расчёте HIP_MAC_2. В частности, Инициатор должен сохранять HOST_ID в точности, как было в пакете R1, пока не получит параметр HIP_MAC_2 в пакете R2.

Расчёт HIP_MAC выполняется как

   HMAC: { HIP header | [ Parameters ] }

где Parameters включает все параметры пакета HIP с типами от 1 до (тип HIP_MAC — 1).

При расчёте HIP_MAC применяются два правила:

• в заголовке HIP устанавливается Checksum = 0;

• в заголовке HIP отсчёт поля Header Length начинается от начала параметра HIP_MAC.

Порядок параметров описан в параграфе 5.2.1.

Расчёт HIP_MAC_2 выполняется как

   HIP_MAC_2: { HIP header | [ Parameters ] | HOST_ID }

где Parameters включает все параметры пакета HIP с типами от 1 до (тип HIP_MAC_2 — 1).

При расчёте HIP_MAC_2 применяются три правила:

• в заголовке HIP устанавливается Checksum = 0;

• в заголовке HIP отсчёт поля Header Length начинается от начала параметра HIP_MAC_2 и увеличивается на размер конкатенации HOST_ID (включая поля Type и Length);

• параметр HOST_ID имет именно ту форму, в которой он был получен в пакете R1 от Ответчика.

Порядок параметров описан в параграфе 5.2.1, за исключением того, что параметр HOST_ID в этом расчёте добавляется в конце.

Параметр HIP_MAC определён в параграфе 5.2.12, а HIP_MAC_2 — в параграфе 5.2.13. Процесс расчёта и проверки HMAC (для HIP_MAC и HIP_MAC_2, пока для HIP_MAC_2 не указано иное) описан ниже

Отправитель пакета

1. Создаётся пакет HIP без HIP_MAC, HIP_SIGNATURE, HIP_SIGNATURE_2 и иных параметров, значение типа которых превышает значение типа параметра HIP_MAC.

2. При расчёте HIP_MAC_2 в конец пакета добавляется параметр HOST_ID (Ответчик).

3. При расчёте HIP_MAC_2 в поле Header Length заголовка HIP учитывается параметр HOST_ID.

4. Рассчитывается HMAC с использованием ключа HIP-gl или HIP-lg, выведенного из KEYMAT в соответствии с параграфом 6.5.

5. Для HIP_MAC_2 параметр HOST_ID удаляется из пакета.

6. В пакет добавляется параметр HIP_MAC и другие параметры, значение типа которых больше значения типа HIP_MAC (HIP_MAC_2), включая возможные параметры HIP_SIGNATURE и HIP_SIGNATURE_2.

7. Заново рассчитывается значение поля Length в заголовке HIP.

Получатель пакета

1. Проверка поля HIP Header Length.

2. Удаляется параметр HIP_MAC или HIP_MAC_2, а также последующие параметры с большими значениями типа, включая возможные параметры HIP_SIGNATURE или HIP_SIGNATURE_2 с сохранением содержимого, которое может потребоваться позднее.

3. В случае HIP_MAC_2 создаётся и добавляется в пакет параметр HOST_ID (с информацией Ответчика). Параметру HOST_ID следует совпадать с полученные ранее от Ответчика значением.

4. Пересчитывается размер пакета HIP в заголовке HIP и очищается поле Checksum (0). В случае HIP_MAC_2 размер рассчитывается с учетом поля HOST_ID.

5. Рассчитывается HMAC с использованием ключа HIP-gl или HIP-lg, выведенного из KEYMAT в соответствии с параграфом 6.5 и сравнивается с полученным HMAC.

6. В полях Checksum и Header Length заголовка HIP устанавливаются исходные значения. Отметим, что значения Checksum и Length после этого становятся некорректными.

7. В случае HIP_MAC_2 из пакета удаляется параметр HOST_ID перед дальнейшей обработкой.

6.4.2. Расчёт подписи

Приведённая ниже процедура применима к параметрам HIP_SIGNATURE и HIP_SIGNATURE_2. При обработке HIP_SIGNATURE_2 отличием является использование параметра HIP_SIGNATURE_2 и HIT Инициатора, а также очистка (0) полей PUZZLE Opaque и Random #I перед расчетом подписи. Параметр HIP_SIGNATURE определён в параграфе 5.2.14, HIP_SIGNATURE_2 — в параграфе 5.2.15.

Расчёт HIP_SIGNATURE и HIP_SIGNATURE_2 выполняется как

   HIP_SIGNATURE: { HIP header | [ Parameters ] }

где Parameters включает параметры пакета HIP с типами от 1 до (тип HIP_SIGNATURE — 1).

При расчёте подписи применяются два правила:

• в заголовке HIP устанавливается Checksum = 0;

• в заголовке HIP отсчёт поля Header Length начинается от начала параметра HIP_SIGNATURE.

Порядок параметров описан в параграфе 5.2.1.

   HIP_SIGNATURE_2: { HIP header | [ Parameters ] }

где Parameters включает параметры пакета HIP с типами от 1 до (тип HIP_SIGNATURE_2 — 1).

При расчёте подписи применяются три правила:

• в заголовке HIP устанавливается Checksum = 0 и HIT = 0 (для Ответчика).

• в заголовке HIP отсчёт поля Header Length начинается от начала параметра HIP_SIGNATURE_2;

• В параметре PUZZLE для полей Opaque и Random #I устанавливается значение 0.

Порядок параметров описан в параграфе 5.2.1.

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

Отправитель пакета

1. Создаётся пакет HIP без параметра HIP_SIGNATURE и следующих за ним параметров.

2. Рассчитывается поле Length и устанавливается Checksum = 0 в заголовке HIP. Для HIP_SIGNATURE_2 устанавливается HIT Инициатора в заголовке HIP, а также поля Opaque и Random #I в параметре PUZZLE.

3. Рассчитывается подпись с использованием секретного ключа, соответствующего HI (открытый ключ).

4. В пакет добавляется параметр HIP_SIGNATURE.

5. Добавляются параметры, следующие за HIP_SIGNATURE.

6. Пересчитывается поле Length в заголовке HIP и рассчитывается поле Checksum.

Получатель пакета

1. Проверяется поле Length и контрольная сумма в заголовке HIP.

2. Сохраняется содержимое HIP_SIGNATURE и следующих за ним параметров, после чего они удаляются.

3. Пересчитывается поле Length в заголовке HIP и устанавливается Checksum = 0. Для HIP_SIGNATURE_2 устанавливается HIT Инициатора в заголовке HIP, а также 0 для Opaque и Random #I в параметре PUZZLE.

4. Вычисляется подпись и сравнивается с полученной с использованием HI (открытй ключ) отправителя пакета.

5. Восстанавливается исходный пакет путём добавления удалённых параметров (п. 2) и восстановления сброшенных в 0 значений (п. 3).

При проверке может использоваться идентификатор HI из пакета HIP, HI полученный с помощью запроса DNS, если в параметре HOST_ID получено имя FQDN, или HI из иного источника.

6.5. Генерация HIP KEYMAT

Ключевой материал HIP выводится из сеансового ключа DH (Kij), создаваемого в процессе базового обмена HIP (см. параграф 4.1.3). Инициатор имеет ключ Kij при создании пакета I2, а Ответчик получает Kij в пакете I2, поэтому пакет I2 уже может содержать шифрованную информацию.

KEYMAT выводится путём подачи Kij в функцию вывода ключей, указанную DH Group ID. Этот документ определяет единственную функцию вывода ключей на основе хэширования (Hash-based Key Derivation Function или HKDF) [RFC5869] с использованием функции RHASH. Новые DH Group ID и соответствующие функции распределения ключей могут определять другие документы.

Ниже приведено более подробное описание вывода ключевого материала с использованием HKDF. Пусть

   info    = sort(HIT-I | HIT-R)
   salt    =  #I | #J

Sort(HIT-I | HIT-R) определяется как конкатенация двух тегов HIT в сетевом порядке байтов, при этом меньшее значение HIT предшествует большему. Теги сравниваются как положительные (без знака) 128-битовые целые числа с сетевым порядком байтов. Значения #I и #J берутся из головоломки и её решения, которые были переданы в сообщениях R1 и I2 при создании ассоциации HIP. Оба хоста сохраняют значения #I и #J в ассоциации HIP для применения в будущем.

Исходные ключи выводятся последовательно в порядке, определяемом численным сравнением тегов HIT, как указано выше. HOST_g указывает хост с большим значением HIT, HOST_l — с меньшим. Ниже показан порядок вывода четырёх начальных ключей.

Ключ шифрования HIP-gl для параметра ENCRYPTED хоста HOST_g.

Ключ защиты целостности (HMAC) HIP-gl для исходящих пакетов HIP хоста HOST_g.

Ключ шифрования HIP-lg для параметра ENCRYPTED хоста HOST_l.

Ключ защиты целостности (HMAC) HIP-lg для исходящих пакетов HIP хоста HOST_l.

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

AES 128 или 256 битов

SHA-1 160 битов

SHA-256 256 битов

SHA-384 384 бита

NULL 0 битов

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

6.6. Инициирование базового обмена HIP

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

Реализация готовит пакет I1 и передаёт его по IP-адресу партнёра, который может быть получен традиционным способом, например, через DNS. Содержимое пакета I1 описано в параграфе 5.3.1. Выбор используемых Host Identity для Инициатора и Ответчика, если их несколько, обычно определяет политика. Ниже приведены концептуальные правила запуска базового обмена HIP.

1. Инициатор получает один или несколько тегов HIT Ответчика и один или несколько адресов с помощью запроса DNS по FQDN Ответчика, из иного репозитория или локальной базы данных. Если Инициатор не знает HIT Ответчика, он может попытаться использовать значение NULL в качестве HIT Ответчика (см. параграф 4.1.8. Режим HIP Opportunistic). Если у Инициатора есть выбор из нескольких HIT Ответчика, он выбирает HIT, для которого поддерживает HIT Suite.

2. Инициатор передаёт пакет I1 по одному из адресов Ответчика в соответствии с локальной политикой.

3. Инициатор включает в пакет I1 список DH_GROUP_LIST. Выбор и порядок DH Group ID в списке должен быть сохранен Инициатором, поскольку это потребуется при обработке пакета R1. В большинстве случаев предпочтения для групп DH будут статическими и не требуется хранить их для каждой ассоциации.

4. После передачи пакета I1 отправитель переходит в состояние I1-SENT и запускает таймер, значение которого следует выбирать больше наихудшего ожидаемого RTT. Отправителю также следует увеличить на 1 счётчик попыток, связанный с I1.

5. По завершению отсчёта таймера отправителю следует повторить пакет и заново запустить таймер, повторяя это до I1_RETRIES_MAX раз.

6.6.1. Параллельная отправка нескольких пакетов I1

Для минимизации задержки при создании ассоциации реализация может передать один и тот же пакет I1 по нескольким адресам Ответчика, однако недопустимо параллельно отправлять пакет более чем по трём (3) адресам Ответчика. Кроме того, при повторе по тайм-ауту реализация должна воздерживаться от передачи одного пакета I1 по нескольким адресам, т. е. при повторе инициализации соединения по тайм-ауту недопустимо передавать пакет I1 по нескольким адресам получателя. Эти ограничения предназначены для предотвращения перегрузки сети и возможных DoS-атак, например, когда кто-то заявил сотни или тысячи адресов, что может породить огромное число пакетов от Инициатора.

Поскольку не гарантируется, что Ответчик различит дубликаты пакетов I1, полученные по разным адресам (он не поддерживает состояния при отправке пакетов R1), Инициатор может получить несколько пакетов R1.

Инициатору следует выбрать предпочтительный адрес получателя по адресам отправителя в принятых пакетах R1 и использовать свой предпочтительный адрес в качестве источника для пакета I2. Правила обработки R1 даны в параграфе 6.8.

6.6.2. Обработка входящих сообщений ICMP Protocol Unreachable

Хост может получить сообщение ICMP Destination Protocol Unreachable в ответ на пакет HIP I1. Это может говорить о том, что партнёр не поддерживает HIP или указывать попытку атаки с целью обмануть Инициатора.

При получении системой сообщения ICMP Destination Protocol Unreachable в процессе ожидания пакета R1 недопустимо прерывать ожидание. Можно игнорировать сообщение ICMP и передать ещё несколько пакетов I1, а также можно счетсть сообщение ICMP намеком на то, что партнёр возможно не поддерживает HIP и вернуться в состояние UNASSOCIATED раньше, чем в ином случае. Однако хост должен, как минимум, продолжить ожидание пакета R1 в течение разумного времени до перехода в состояние UNASSOCIATED.

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

Реализации следует отвечать на I1 пакетом R1, за исключением случаев, когда она не хочет или не способна организовать ассоциацию HIP. Если реализация не может создать ассоциацию HIP, хосту следует передать сообщение «ICMP Destination Protocol Unreachable, Administratively Prohibited» по IP-адресу отправителя пакета I1. Если реализация не хочет создавать ассоциацию HIP, хост может игнорировать пакет I1. Это может быть, например, в случае DoS-атаки с пакетами I1.

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

Ниже приведены концептуальные правила отклика на пакет I1.

1. Ответчик должен убедиться, что HIT Ответчика в полученном пакете I1 совпадает с одним из его тегов HIT или имеет значение NULL. В противном случае он должен отбросить пакет.

2. Если Ответчик находится в состоянии ESTABLISHED, он может ответить пакетом R1, приготовиться к отбрасыванию имеющейся защищённой связи HIP с партнёром и сохранить состояние ESTABLISHED.

3. Если Ответчик находится в состоянии I1-SENT, он должен сравнить HIT отправителя со своим (получатель) HIT. Если HIT отправителя больше, следует отбросить пакет I1 и сохранить состояние I1-SENT. Если HIT отправителя меньше, следует передать пакет R1 и сохранить состояние I1-SENT. Сравнение HIT описано в параграфе 6.5.

4. Если реализация принимает решение ответить на I1 пакетом R1, она создаёт новый пакет R1 или выбирает заранее созданный, как описано в параграфе 5.3.2. Создаётся или выбирается пакет R1 с наиболее предпочтительным открытым ключом DH, который также включён в DH_GROUP_LIST пакета I1. Если нет подходящего DH Group ID в DH_GROUP_LIST пакета I1, пакет R1 передается с любым подходящим открытым ключом DH.

5. Если в пакете I1 тег HIT Ответчика имеет значение NULL, Ответчик выбирает HIT с тем же HIT Suite как у HIT Инициатора. Если Ответчик не поддерживает такой HIT Suite, ему следует выбрать требуемый HIT Suite (параграф 5.2.10), которым в настоящее время служит RSA/DSA/SHA-256. В остальном выбор HIT определяет локальная политика.

6. Ответчик указывает поддерживаемые форматы транспорта HIP в списке TRANSPORT_FORMAT_LIST, как указано в параграфе 5.2.11. Ответчик должен указать по меньше мере один формат транспорта для данных.

7. Ответчик передаёт пакет R1 по IP-адресу отправителя пакета I1.

6.7.1. Управление пакетами R1

Все совместимые реализации должны поддерживать создание пакетов R1. Даже если устройство настроено лиши на инициирование ассоциаций, оно должно быть способно обрабатывать пакеты I1 в случаях восстановления при потере состояния или завершении срока действия ключа. Пакеты R1 можно создавать заранее. Пакет R1 можно использовать повторно в течение короткого интервала Delta T, зависящего от реализации, и использованные пакеты следует отменять и не применять больше после получения действительного пакета I2 от Инициатора. При шквале пакетов I1 пакеты R1 можно применять за пределами обычного Delta T. Сведения R1 недопустимо отбрасывать до завершения интервале Delta S (зависит от реализации) после того, как пакет R1 больше не предлагается. Предполагается, что Delta S — это максимальное время, требуемое для того, чтобы последний пакет I2 в ответ на R1 прибыл к Ответчику.

Реализации, поддерживающие несколько групп DH, могут заранее создавать R1 для каждой поддерживаемой группы, чтобы быстро обрабатывать входящие пакеты I1 с разными DH Group ID в DH_GROUP_LIST.

Реализация может сохранять сведения о полученных пакетах I1 и сопоставлять с ними пакеты I2 (см. параграф 4.1.1).

6.7.2. Обработка сообщений с некорректным форматом

Если реализация получает пакет I1 с ошибками формата, ей не следует отвечать сообщением NOTIFY, поскольку это откпывает возможность для DoS-атак. Вместо этого можно ответить пакетов ICMP, как указано в параграфе 5.4.

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

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

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

Ниже приведены концептуальные правила отклика на пакет R1.

1. Получившая пакет R1 система должна сначала проверить, отправляла ли она его источнику пакет I1 (т. е. наличие ассоциации HIP в состоянии I1-SENT, связанной с HIT из R1). Если пакет I1 не был передан в режиме Opportunistic mode (см. параграф 4.1.8), адрес IP из полученного пакета R1 следует игнорировать при обработке R1 и при поиске ассоциации HIP полученный пакет R1 следует сопоставлять лишь с ассоциациями, использующими HIT. При наличии соответствия системе следует обработать пакет R1, как указано ниже.

2. В ином случае, если состояние системы отличается от I1-SENT и I2-SENT относительно HIT в пакете R1, ей следует просто отбросить пакет R1 и сохранить текущее состояние.

3. Если ассоциация HIP имеет состояние I1-SENT или I2-SENT, полученный тег HIT Инициатора должен совпадать с HIT в исходном пакете I1. Кроме того, HIT Ответчика должен совпадать с указанным в I1, если там не было NULL HIT.

4. Системе следует проверить подпись R1, как указано в параграфе 5.2.15, до обработки пакета.

5. Если ассоциация HIP имеет состояние I1-SENT и имеется несколько действительных пакетов R1, система должна выбрать из них пакет с наибольшим значением счётчика генерации R1.

6. Система должна проверить наличие HIT Suite Инициатора в параметре HIT_SUITE_LIST пакета R1 (поддержка HIT Suite Ответчиком). Если Ответчик поддерживает HIT Suite, обработка продолжается нормально, в противном случае система может сохранить состояние I1-SENT и повторно запустить BEX, передав новый пакет I1 с HIT Инициатора, поддерживаемым Ответчиком и, следовательно, включённым в HIT_SUITE_LIST пакета R1. Система может прервать BEX, если нет подходящего HIT источника. Системе следует подождать некоторое время для получения других пакетов R1 с большим значением счётчика генерации или иными HIT и HIT Suite, прежде чем перезапустить или прервать BEX.

7. Система должна убедиться, что DH Group ID в параметре DIFFIE_HELLMAN сообщения R1 совпадает с первым DH Group ID в DH_GROUP_LIST Ответчика в пакете R1, а также соответствует значению, включенному Инициатором в список DH_GROUP_LIST пакета I1. Если DH Group ID из параметра DIFFIE_HELLMAN не соответствует наилучшему выбору Ответчика, Инициатор может счесть, что список DH_GROUP_LIST в пакете I1 был намеренно изменен. В таком случае Инициатор может передать новый пакет I1, однако ему не следует менять предпочтения в DH_GROUP_LIST нового пакета I1. Инициатор может также прервать обмен HIP.

8. Если ассоциация HIP имеет состояние I2-SENT, система может вернуться в I1-SENT и обработать принятый пакет R1, если значение счётчика генерации R1 в нем больше, чем в ранее обработанном пакете R1.

9. В пакете R1 может быть установлен бит A и в этом случае система может отвергнуть (отбросить) пакет R1 и вернуться в состояние UNASSOCIATED. Системе следует рассматривать отбрасывание R1 лишь в случае использования ею NULL HIT в пакете I1. Если бит A установлен, HIT Ответчика является анонимным и его не следует хранить постоянно.

10. Системе следует попытаться сравнить HIT с полученным Host Identity, используя Host Identity для создания HIT и сравнения с HIT отправителя.

11. Система должна сохранить полученное значение счётчика генерации R1 для последующих операций.

12. Система пытается решить головоломку из пакета R1. Поиск решения должен прерываться по истечении срока действия головоломки. Если найти решение не удалось, реализация может повторить передачу I1 с учётом ограничений или прервать базовый обмен HIP.

13. Система рассчитывает стандартный ключевой материал Diffie-Hellman в соответствии с открытым значением и Group ID из параметра DIFFIE_HELLMAN. Ключевой материал DH Kij служит для извлечения ключей в соответствии с параграфом 6.5.

14. Система выбирает HIP_CIPHER ID из вариантов, предложенных в пакете R1, и использует выбранные значения при создании и применении ключей шифрования, а также при отправке пакета I2. Если предложенные варианты не подходят системе, она может повторить отправку I1 или прервать обмен HIP.

15. Система выбирает подходящий формат транспорта из списка TRANSPORT_FORMAT_LIST и включает соответствующий параметр транспортного формата в последующий пакет I2.

16. Система инициализирует оставшиеся переменные в соответствующем состоянии, включая счётчики Update ID.

17. Система готовит и передаёт пакет I2, как указано в параграфе 5.3.3.

18. Системе следует запустить таймер, для которого следует устанавливать значение больше худшего ожидаемого RTT, и она должна инкрементировать счётчик попыток, связанных с I2. Отправителю следует повторить пакет I2 по завершении отсчёта таймера и перезапустить таймер вплоть до I2_RETRIES_MAX раз.

19. Если система имеет состояние I1-SENT, ей нужно перейти в I2-SENT, в иных случаях состояние не меняется.

6.8.1. Обработка сообщений с некорректным форматом

При получении пакета R1 с некорректным форматом реализация должна отбросить его. Отправка NOTIFY или ICMP не поможет, поскольку отправитель пакета R1 обычно не имеет состояния. Реализации следует подождать возможного получения корректного пакета R1 и можно начать заново, передав новый пакет I1.

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

При получении пакета I2 система может выполнить начальную проверку соответствия пакета I2 переданному ранее пакету R1, если Ответчик хранит такое состояние. Например, отправитель может проверить, отправлен ли пакет I2 с адреса или HIT, откуда Ответчик недавно получил пакет I1. Пакет R1 может включать необрабатываемые (opaque) данные, которые возвращаются в пакете I2. Если пакет I2 кажется подозрительным, система может отбросить его.

Затем реализации следует обработать пакет I2. Это включает проверку решения головоломки, создание ключа DH, возможно расшифровку Host Identity Инициатора, проверку подписи и, наконец, отправку пакета R2.

Ниже приведены концептуальные правила отклика на пакет I2.

1. Система может выполнить проверки, чтобы убедиться в соответствии I2 недавно переданному пакету R1. Провирки зависят от реализации, пример представлен в Приложении A.

2. Система должна убедиться, что HIT Ответчика соответствует одному из его тегов HIT и должна отбросить пакет при несоответствии.

3. Система должна убедиться в поддержке HIT Инициатора. Ответчику следует отбрасывать пакеты I2 с неподдерживаемыми HIT Инициатора.

4. Если конечный автомат системы находится в состоянии R2-SENT, система может проверить сходство полученного пакета I2 с пакетом, вызвавшим переход в R2-SENT. Если пакеты похожи, система может повторить переданный ранее пакет R2 и сбросить таймер R2-SENT, сохранив состояние R2-SENT.

5. Если конечный автомат системы находится в состоянии I2-SENT, система должна сравнить локальный тег HIT с тегом отправителя (подобно описанию в параграфе 6.5). Если локальный тег HIT меньше HIT отправителя, следует отбросить пакет I2, использовать партнерский ключ DH и #I из полученного ранее пакета R1, а также взять локальный ключ DH и #J из переданного ранее пакета I2. В ином случае системе следует обработать полученный пакет I2 и отбросить ключевой материал DH Kij, который могу быть выведен при отправке предыдущего пакета I2. Партнерский ключ DH и #J берутся из свежепринятого пакета I2, локальный ключ DH и #I — из переданного ранее пакета R1.

6. Если конечный автомат системы находится в состоянии I1-SENT и теги HIT а пакете I2 соответствуют указанным в переданном ранее пакете I1, система использует принятый пакет I2 как основу для создаваемой ассоциации HIP и прекращает отправку пакетов I1 (при условии прохождения указанных ниже проверок I2).

7. Если конечный автомат системы находится в состоянии, отличном от R2-SENT, системе следует проверить попадание значения счётчика генерации R1, возвращённого в I2 (при наличии), в допустимый диапазон. Реализации должны воспринимать головоломки из текущего поколения и могут воспринимать более ранние. Если значение счётчика генерации в пакете I2 выходит за допустимые пределы, пакет I2 является устаревшим (возможно повторно использованным и его следует отбросить.

8. Система должна проверить решение головоломки (параграф 5.3.3), рассчитав хэш по алгоритму RHASH.

9. Пакет I2 должен иметь 1 значение в параметре HIP_CIPHER, которое должно совпадать с одним из значений, предложенных Инициатором в пакете R1.

10. Система должна вывести ключевой материал DH Kij на основе открытого значения и Group ID в параметре DIFFIE_HELLMAN. Этот материал применяется для создания ключей ассоциации HIP, как указано в параграфе 6.5. Если DH Group ID не поддерживается, пакет I2 просто отбрасывается.

11. Зашифрованный идентификатор HOST_ID расшифровывается с ключом Инициатора, определенным в параграфе 6.5. Если расшированные данные отличаются от HOST_ID, пакет I2 просто отбрасывается.

12. Реализации следует также проверить соответствие HIT Инициатора в пакете I2 значению Host Identity, переданному в пакете I2 (некоторые промежуточные устройства не способны выполнить такую проверку).

13. Система должна обработать параметр TRANSPORT_FORMAT_LIST. Спецификацию обработки транспортных параметров задают отдельные документы (например, [RFC7402]).

14. Система должна проверить HIP_MAC в соответствии с процедурами параграфа 5.2.12.

15. Система должна проверить HIP_SIGNATURE в соответствии с параграфами 5.2.14 и 5.3.3.

16. Если указанные выше проверки прошли, система продолжает обработку I2, в противном случае она отбрасывает пакет I2 и не меняет состояние конечного автомата.

17. В пакете I2 может быть установлен бит A и в этом случае система может отвергнуть (отбросить) пакет I2, возвратив конечный автомат в состояние UNASSOCIATED. При установленном бите A тег HIT Инициатора не следует хранить постоянно.

18. Система инициализирует оставшиеся переменные в соответствующем состоянии, включая счётчики Update ID.

19. Если после успешной обработки I2 конечный автомат находится в состоянии UNASSOCIATED, I1-SENT, I2-SENT или R2-SENT, передаётся пакет R2 и конечный автомат переходит в состояние R2-SENT.

20. Если после успешной обработки I2 конечный автомат находится в состоянии ESTABLISHED, старая ассоциация HIP сбрасывается и создаётся новая, передаётся пакет R2 и конечный автомат переходит в состояние R2-SENT.

21. При переходе конечного автомата в состояние R2-SENT система запускает таймер. Состояние конечного автомата меняется на ESTABLISHED, если через входящую ассоциацию HIP получены данные или принят пакет UPDATE (или иной пакет, указывающий переход удалённого партнёра в состояние ESTABLISHED). По завершении отсчёта таймера (с учётом максимального числа повторов I2) конечный автомат переходит в состояние ESTABLISHED.

6.9.1. Обработка сообщений с некорректным форматом

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

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

Пакет R2, полученный в состоянии UNASSOCIATED, I1-SENT или ESTABLISHED будет отбрасываться без смены состояния конечного автомата. В состоянии I2-SENT пакет R2 должен обрабатываться.

Ниже приведены концептуальные правила отклика на пакет R2.

1. Если состояние системы отличается от I2-SENT, пакет R2 просто отбрасывается.

2. Система должна убедиться, что применяемые теги HIT соответствуют полученным в пакете R1, вызвавшем переход в состояние I1-SENT.

3. Система должна проверить HIP_MAC_2 в соответствии с процедурами параграфа 5.2.13.

4. Система должна проверить подпись HIP в соответствии с процедурами параграфа 5.2.14.

5. Отказ при любой из указанных выше проверок с высокой вероятностью говорит о MitM или иной атаке. Системе следует вести себя подобающим образом в соответствии с локальной политикой.

6. После успешной обработки пакета R2 конечный автомат переходит в состояние ESTABLISHED.

6.11. Передача пакетов UPDATE

Хост передаёт пакет UPDATE для обновления сведений, связанных с ассоциацией HIP. Возможно много вариантов применения этого пакета, например, управление мобильностью или смена ключей в имеющейся ESP SA. Ниже описаны концептуальные правила передачи пакетов UPDATE партнеру. В других документах моугт быть определены дополнительные применения пакетов UPDATE.

Последовательность пакетов UPDATE указывается параметром SEQ. Перед отправкой UPDATE система сначала проверяет, не осталось ли незавершенный пакетов UPDATE, которые могут помешать обработке нового пакета. Когда обработки ожидает (не подтверждены) несколько пакетов UPDATE, отправитель должен считать, что получатель может обрабатывать их в произвольном порядке. Поэтому новые пакеты UPDATE, зависящие от приёма и обработки предыдущих UPDATE, должны откладываться до получения требуемых подтверждений ACK. Одним из способов предотвращения конфликтов является разрешение иметь лишь один необработанный пакет UPDATE в каждый момент времени. Однако разрешение нескольких UPDATE может повысить производительность мобильных и многоадресных (многодомных) протоколов.

Ниже приведены концептуальные правила передачи пакетов UPDATE.

1. Первый пакет UPDATE передаётся с Update ID = 0. В иных случаях система сама устанавливает Update ID, увеличивая значение в каждом переданном пакете.

2. Система создаёт пакет UPDATE с параметром SEQ, содержащим текущее значение Update ID. Пакет может также включать параметры ACK, подтверждающие Update ID из предыдущих UPDATE SEQ от партнера.

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

4. По завершении отсчёта таймера пакет UPDATE передаётся заново до UPDATE_RETRY_MAX раз. Для последующих повторов таймер UPDATE следует экспоненциально увеличивать. Если после UPDATE_RETRY_MAX попыток не было получено подтверждения, ассоциация HIP считается разорванной и конечный автомат следует перевести из состояния ESTABLISHED в CLOSING, как указано в параграфе 4.4.4. Таймер UPDATE останавливается при получении от партнёра ACK с подтверждением UPDATE.

6.12. Приём пакетов UPDATE

Обработка полученного системой пакета UPDATE зависит от состояния ассоциации HIP, а также наличия и значений параметров SEQ и ACK. Обычно сообщения UPDATE содержать также необязательные параметры, обработка которых описана в отдельных документах.

Для каждой ассоциации хост сохраняет следующий ожидаемый идентификатор обновления от партнёра (peer Update ID), начальное значение которого равно 0. Сравнение номеров (больше, меньше) выполняется в циклическом пространстве номеров, поэтому должна выполняться соответствующая обработка перехода через максимум (2³²).

Отправитель может передать несколько остающихся сообщений UPDATE и они обрабатываются в полядке их приёма получателем (т. е. без восстановления порядка). При обработке сообщений UPDATE без соблюдения порядка получатель должен отслеживать, какие сообщения UPDATE были обработаны ранее, чтобы дубликаты и повторы пожтверждались без дополнительной обработки. Получатель может задать окно приёма для Update ID, которые он желает обрабатывать в данный момент и отбрасывать сообщения UPDATE, не попадающие в это окно.

Ниже приведены концептуальные правила обработки принимаемых пакетов UPDATE.

1. При отсутствии соответствующей ассоциации HIP реализация может ответить сообщением ICMP Parameter Problem, как указано в параграфе 5.4.4.

2. Если ассоциация находится в состоянии ESTABLISHED и присутствует параметр SEQ (но не ACK), обработка UPDATE и отклик на пакет выполняются в соответствии с параграфом 6.12.1.

3. Если ассоциация находится в состоянии ESTABLISHED и присутствует параметр ACK (но не SEQ), обработка UPDATE выполняется в соответствии с параграфом 6.12.2.

4. Если ассоциация находится в состоянии ESTABLISHED и в UPDATE присутствуют параметры ACK и SEQ, сначала обрабатывается ACK в соответствии с параграфом 6.12.2, затем — остальная часть UPDATE в соответствии с параграфом 6.12.1.

6.12.1. Обработка параметра SEQ в принятом пакете UPDATE

Ниже приведены концептуальные правила обработки параметра SEQ в принятом пакете UPDATE.

1. Если Update ID в принятом SEQ не является следующим в последовательности Update ID и превышает верхнюю границу окна приёма для новых UPDATE, пакет должен отбрасываться.

2. Если Update ID в принятом SEQ соответствует недавно обработанному UPDATE, пакет считается повторным. Проверку HIP_MAC (следующий шаг) недопустимо пропускать (хотя приемлемо побайтовое сравнение полученного пакета с сохраненным). Хосту рекомендуется кэшировать пакеты UPDATE, переданные с ACK, для предотвращения издержек, связанных с созданием нового пакета ACK в ответ на повторный пакет UPDATE. Система должна снова подтверждать (очевидные) повторы UPDATE, но следует также учитывать ограничение частоты откликов на повторы для защиты от replay-атак.

3. Система должна проверить HIP_MAC в пакете UPDATE и при несовпадении должна отбросить пакет.

4. Система может проверить SIGNATURE в пакете UPDATE. При несовпадении пакет следует отбросить, записав в журнал сообщение об ошибке.

5. Если обрабатывается новый параметр SEQ, после этого обрабатываются параметры UPDATE. Система должна записать Update ID из принятого параметра SEQ для защиты от повторного использования.

6. Подготавливается и передаётся партнёру пакет подтверждения UPDATE с параметром ACK. Этот параметр может включаться в отдельный пакет UPDATE или присоединяться к UPDATE с параметром SEQ, как указано в параграфе 5.3.5. Параметр ACK может подтверждать несколько Update ID от партнера.

6.12.2. Обработка параметра ACK в принятом пакете UPDATE

Ниже приведены концептуальные правила обработки параметра ACK в принятом пакете UPDATE.

1. Порядковый номер в ACK должен соответствовать переданному ранее пакету UPDATE, который ещё не подтвержден. Если совпадения не найдено или ACK не подтверждает новый пакет UPDATE, тогда должен быть отброшен прежний пакет (при отсутствии параметра SEQ) или выполнена обработка в соответствии с параграфом 6.12.1.

2. Система должна проверить HIP_MAC в пакете UPDATE и при несовпадении должна отбросить пакет.

3. Система может проверить SIGNATURE в пакете UPDATE. При несовпадении пакет следует отбросить, записав в журнал сообщение об ошибке.

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

6.13. Обработка пакетов NOTIFY

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

6.14. Обработка пакетов CLOSE

Получив сообщение CLOSE, хост отвечает сообщением CLOSE_ACK и переходит в состояние CLOSED (достоверность CLOSE проверяется с использованием HIP_MAC и SIGNATURE). Эта обработка выполняется независимо от нахождения ассоциации HIP в состоянии CLOSING, чтобы можно было обработать отправленные обеими сторонами сообщения CLOSE. Ассоциация HIP не сбрасывается до перехода хоста в состояние UNASSOCIATED.

После запуска процесса закрытия любая новая потребность в отправке данных вызывает создание новой ассоциации HIP, начиная с отправки пакета I1.

При отсутствии соответствующей ассоциации HIP пакет CLOSE отбрасывается.

6.15. Обработка пакетов CLOSE_ACK

При получении сообщения CLOSE_ACK хост проверяет, что он находится в состоянии CLOSING или CLOSED, а CLOSE_ACK является откликом на CLOSE. Хост может сопоставлять сообщения CLOSE_ACK с CLOSE, сравнивая значение ECHO_REQUEST_SIGNED (в пакете CLOSE) с ECHO_RESPONSE_SIGNED (в пакете CLOSE_ACK).

CLOSE_ACK содержит параметры HIP_MAC и SIGNATURE для проверки. Состояние сбрасывается при переходе в UNASSOCIATED и после этого хост может отвечать параметром ICMP Parameter Problem на входящие сообщения CLOSE (см. параграф 5.4.4).

6.16. Обработка потери состояния

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

7. Правила HIP

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

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

Значение #K в HIP R1 следует выбирать с осторожностью. Слишком высокие значения #K будут мешать клиентам со слабым CPU, поскольку они не смогут решить головоломку за разумное время. Значение #K следует повышать лишь в том случае, когда Ответчик сильно загружен, т. е. больше не может обрабатывать все входящие согласования HIP. Если Ответчик не загружен сильно, следует устанавливать #K = 0.

Ответчикам, которые работают лишь с заданными Инициаторами, нужны списки управления доступом (Access Control List или ACL), указывающие хосты, от которых они воспринимают базовый обмен HIP, а также предпочтительный формат транспорта и локальный срок действия. В таких ACL следует поддерживать шаблоны, в том числе на общедоступных или предоставляющих анонимные услуги Ответчиках.

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

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

В DoS-атаках часто используется преимущество асимметрии издержек на создание ассоциации. Одним из примеров такой асимметрии является необходимость сохранения Ответчиком локального состояния при возможности Инициатора обходиться без установки состояния. HIP не пытается повысить издержки при создании ассоциации для Инициатора, но пытается снизить их для Ответчика. Это достигается за счёт того, что Ответчик запускает трехэтапный обмен вместо Инициатора, что делает обмен HIP 4-пакетным. При этом первый пакет Ответчика (R1) может быть подготовлен заранее и Ответчик может применять заготовленные пакеты многократно, пока тот или иной Инициатор не предоставит действительный отклик на такой пакет R1. В случае лавины потоков I1 хост может многократно применять одно значение DH, даже если какой-либо Инициатор предоставил действительный отклик с этим значением DH. Однако такое поведение не рекомендуется и его следует избегать. Использование одних значений Diffie-Hellman и случайного значения головоломки #I сопряжено с некоторым риском и нужно соблюдать баланс между таким риском и возможным шквалом пакетов HIP I1.

Смещение издержек создания состояния к Инициатору при создании пакетов HIP I2 представляет собой другую DoS-атаку. Злоумышленник может подделать пакет I1 и Ответчик передаст ему пакет HIP R1. Это позволяет предположительно связать Инициатора с оценкой пакета HIP R1 и созданием пакета I2. Защитой от таких атак является простое игнорирование пакетов R1, которые не соответствуют переданным I1 (параграф 6.8, п. 1).

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

Другим типом DoS-атак является лавинная отправка обменных пакетов I2. Когда атакующий Инициатор решил головоломку, он может передавать пакеты с подставным IP-адресом отправителя, включающие недействительную подпись HIP или недействительные шифрованные данные HIP (в параметре ENCRYPTED). Это потребует от Ответчика расхода ресурсов для определения того, что пакет I2 не может быть обработан полностью. Защитой от таких атак является отбрасывание пакетов I2 с данным решением головоломки после приёма N некорректных пакетов I2. Это остановит атаку и злоумышленнику потербуется запросить другой пакет R1 для её продолжения. Ответчик может во время таких атак увеличивать значение #K. Для сохранения списка решений из некорректных пакетов Ответчику требуется сохранять состояние для этих пакетов I2, пока не увеличится значения счетчика R1. Поскольку некорректные пакеты обычно отфильтровываются по контрольной сумме до проверки подписи, в «черный список» помещаются лишь решения головоломки из пакетов, которые созданы для прохождения проверки контрольной суммы и головоломки. Кроме того, перед созданием новой записи в списке требуется верное решение головоломки, поэтому для лавинной атаки на «черный список» злоумышленнику придётся сначала решить головоломки.

Ещё одним вариантом DoS-атаки является имитация перезапуска состояния после перезагрузки одного из партнёров. Перезапускающийся хост передаёт партнёрам пакеты I1, на которые те будут отвечать пакетом R1 даже находясь в состоянии ESTABLISHED. Если пакет I1 является обманным, принятый пакет R1 будет неожиданным для хоста, чей адрес использован в обманном пакете, и будет отброшен как в описанном выше случае.

Четвёртый вариант DoS-атаки заключается в имитации разрыва ассоциации HIP. Протокол HIP полагается на таймеры и обмен CLOSE/CLOSE_ACK для явного сигнала о завершении ассоциации HIP. Поскольку сообщения CLOSE и CLOSE_ACK содержат HIP_MAC, посторонний не может закрыть соединение. Наличие параметра SIGNATURE позволяет промежуточным устройствам (например, межсетевым экранам, трансляторам NAT на основе SPI) просматривать эти сообщения и отбрасывать соответствующее состояние. Однако необязательный ответ на сообщение CLOSE пакетом ICMP Parameter Problem (см. параграф 5.4.4) может позволить атакующему подменить IP-адрес отправителя для отправки сообщений CLOSE, запускающих атаку с отражением.

Пятой формой DoS-атаки является повторное использование пакетов R1 с целью вынудить Инициатора решать устаревшие головоломки с потерей синхронизации с Ответчиком. Монотонно возрастающий счётчик R1 предназначен для защиты от таких атак (см. параграф 4.1.4).

Защититься от MitM-атак (перехват с участием человека) сложно без сторонней аутентификации. Опытный злоумышленник MitM может легко справиться со всеми частями HIP, однако протокол HIP опосредованно обеспечивает защиту от MitM-атак. Если HI Ответчика получен из подписанной зоны DNS, сертификата или иным защищённым способом, Инициатор может использовать его для проверки пакета HIP R1.

Аналогично, если HI Инициатора хранится в защищённой зоне DNS, доверенном сертификате или получен иным защищённым способом, Ответчик может получить HI (после получения пакета HIP I2) и проверить, можно ли доверять HI.

В этом документе представлена концепция режима HIP opportunistic, но документ не задаёт семантику такой организации соединения для приложений. Как отмечено в параграфе 4.1.8, имеются некоторые опасения по поводу режима opportunistic.

Сообщения NOTIFY применяются лишь с информационными целями и не подтверждаются. Реализация HIP не может полагаться лишь на сведения из NOTIFY, поскольку эти пакеты можно использовать повторно (replay). Реализации не следует менять какие-либо данные о состоянии на основе лишь полученного сообщения NOTIFY.

Поскольку протокол HIP будут поддерживать не все хосты, предполагается использование сообщений ICMP Destination Protocol Unreachable для организации DoS-атак. Атака на Инициатора будет выглядеть так, будто Ответчик не поддерживает HIP, но вскоре после приёма сообщения ICMP Инициатор получит действительный пакет HIP R1. Поэтому для защиты от таких атак Инициатору не следует реагировать на сообщение ICMP в течение некоторого времени, пока не будет получен реальный пакет HIP R1 от Ответчика. Аналогичная атака на Ответчик более сложна. Обычно, если принятое Ответчиком сообщение I1 является обманным сообщением от злоумышленника, Ответчик может получить сообщение ICMP с IP-адреса, по которому было передано сообщение R1. Однако изощренный злоумышленник может попытаться воспользоваться этим с целью прервать базовый обмен HIP с помощью передачи Ответчику такого сообщения ICMP до того, как Инициатор сможет отправить действительный пакет I2. Поэтому Ответчику не следует реагировать на такие сообщения ICMP. В частности, ему не следует удалять какое-либо минимальное состояние, созданное при отправке пакета HIP R1 (если оно было создано), а следует дождаться получения действительного пакета HIP I2 или естественного тайм-аута (если пакеты R1 отслеживаются). Точно так же Инициатору следует игнорировать любые сообщения ICMP в процессе ожидания пакета HIP R2 и следует удалять какие-либо ожидающие состояния лишь по естественному тайм-ауту.

9. Взаимодействие с IANA

Агентство IANA зарегистрировало номер протокола 139 для Host Identity Protocol и включило его в реестры IPv6 Extension Header Types [RFC7045] и Assigned Internet Protocol Numbers. Ссылка на [RFC5201] в обоих реестрах заменена ссылкой на данную спецификацию.

Ссылка на [RFC5201] для 128-битового значения 0xF0EF F02F BFF4 3D0F E793 0C3C 6E61 74EA в пространстве имён CGA Message Type [RFC3972] заменена ссылкой на данную спецификацию.

В реестр Host Identity Protocol (HIP) Parameters были внесены перечисленные ниже изменения. Многие изменения связаны с заменой ссылки на [RFC5201] ссылкой на данную спецификацию, но имеются и другие отличия. Терминология выделения значений определена в [RFC5226], имеющиеся упоминания IETF Consensus заменены на IETF Review в соответствии с [RFC5226].

HIP Version — версия HIP

Этот документ добавляет в реестр значение 2. Для значения 1 сохранена ссылка на [RFC5201].

Packet Type — тип пакета

7-битовое поле Packet Type в протоколе HIP описывает тип протокольного сообщения HIP. Поле определено в параграфе 5.1. Все имеющиеся ссылки на [RFC5201] заменены ссылками на эту спецификацию. Остальные значения сохранены.

HIT Suite ID — идентификатор набора HIT

Эта спецификация создаёт новый реестр HIT Suite ID. Он отличается от имеющегося реестра Suite ID, который сохранен для протокола версии 1 [RFC5201] (этот реестр закрыт для новых регистрация).

4-битовое значение HIT Suite ID использует поле OGA ID из ORCHID для указания типа HIT. Этот документ определяет три HIT Suite (см. параграф 5.2.10).

HIT Suite ID также передаётся в 4 старших битах поля ID в параметре HIT_SUITE_LIST, а 4 младших бита зарезервированы для будущих расширений пространства HIT Suite ID (сверх 16 значений).

В настоящее время HIT Suite использует лишь 4 бита, поскольку они передаются в HIT. Расширение числа битов в HIT Suite ID снижает криптостойкость HIT. Значения HIT Suite ID следует выделять с осторожностью для экономии пространства значений. Более того, отмененные идентификаторы следует выделять повторно по прошествии достаточного времени. Если 15 значений Suite ID (значение 0 исходно является резервным) окажется не достаточно, можно использовать большее число HIT Suite ID с помощью резервного значения HIT Suite ID = 0 для индикации большего числа битов. Параметр HIT_SUITE_LIST уже поддерживает 8-битовые HIT Suite ID, если они нужны. Однако [RFC7343] в настоящее время не поддерживает такое расширение. Предлагается сначала воспользоваться методом «опрокидывания» (rollover), описанным а Приложении E. Возможные расширения пространства HIT Suite ID до 8 битов и новые значения HIT Suite ID выделяются по процедуре IETF Review.

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

Parameter Type — тип параметра

16-битовое поле Type в параметре HIP описывает тип параметра (определено в параграфе 5.2.1). Текущие значения типов рассматриваются в параграфах 5.2.3 — 5.2.23. Реестр Parameter Types обновлён, как описано ниже.

Добавлено значение 129 для параметра R1_COUNTER со ссылкой на эту спецификацию, а имеющееся значение 128 для этого параметра сохранено со ссылкой на [RFC5201]. Это документирует изменение, внесенной в версии 2 для данного протокола. Для ясности имя значения 128 было сменено на R1_Counter (v1 only).

Добавлено значение 579 для нового типа HIP_CIPHER со ссылкой на эту спецификацию. Этот тип параметра функционально заменяет тип HIP_TRANSFORM (577), который сохранен со ссылкой на [RFC5201]. Для ясности имя значения 577 заменено на HIP_TRANSFORM (v1 only).

Добавлено значение 715 для HIT_SUITE_LIST со ссылкой на эту спецификацию.

Добавлено значение 2049 для TRANSPORT_FORMAT_LIST со ссылкой на эту спецификацию.

Имя типа HMAC (61505) заменено на HIP_MAC, а HMAC_2 (61569) — на HIP_MAC_2 со ссылками на эту спецификацию.

Для остальных типов со ссылками на [RFC5201] эти ссылки были обновлены с указанием данного документа, а типы со ссылками на иные RFC оставлены без изменений.

Типы 32768 — 49151 (не 49141 — значение, указанное в прежней таблице) были зарезервированы для приватного использования (Reserved for Private Use). Реализациям следует выбирать типы из этого диапазона случайно для снижения вероятности конфликтов. При этом следует использовать метод, обеспечивающий фактическую случайность (например, бросание монеты).

Указанная ранее процедура выделения в порядке запросов с требованием спецификации (First Come First Served with Specification Required) заменена на Specification Required (нужна спецификация).

Group ID — идентификатор группы

8-битовые значения Group ID применяются в параметрах DIFFIE_HELLMAN и DH_GROUP_LIST (параграф 5.2.7). Реестр обновлён с учётом новых значений, определённых в параграфе 5.2.7, устаревшие значения сохранены в реестре с пометкой DEPRECATED и ссылкой на [RFC5201]. Новые значения выделяются по процедуре IETF Review.

HIP Cipher ID — идентификатор шифра HIP

16-битовые значения Cipher ID в параметре HIP_CIPHER определены в параграфе 5.2.8. Это новый реестр. Значения из неиспользуемого и резервного пространства выделяются по процедуре IETF Review.

DI-Type — тип DI

4-битовые значения DI-Type в параметре HOST_ID определены в параграфе 5.2.9. Новые значения выделяются по процедуре IETF Review. Имеющиеся значения со ссылкой на [RFC5201] обновлены с указанием этой спецификации.

HI Algorithm — алгоритм HI

16-битовые значения Algorithm в параметре HOST_ID определены в параграфе 5.2.9. Это новый реестр. Значения из неиспользуемого и резервного пространства выделяются по процедуре IETF Review.

ECC Curve Label — метка кривой ECC

Когда для HI Algorithm в параметре HOST_ID определено значение ECDSA или ECDSA_LOW, нужен новый реестр для значений ECC Curve Label, определённых в параграфе 5.2.9. Это может быть сделано созданием двух определяемых алгоритмом субреестров с именами ECDSA Curve Label и ECDSA_LOW Curve Label. Новые значения выделяются по процедуре IETF Review.

Notify Message Type — тип сообщения Notify

16-битовые значения Notify Message Type в параметре NOTIFICATION определены в параграфе 5.2.19.

Notify Message Type от 1 до 10 служат для информирования об ошибках в структуре пакета, 11-20 — о проблемах в параметрах, содержащих относящийся к криптографии материал, 21-30 — о проблемах при аутентификации или проверке целостности пакета. Типы выше 30 служат для информирования об иных типах ошибок или событиях.

Процедуры регистрации были обновлены. Для значений 1-50 сохраняется процедура IETF Review, для 51-8191 применяется процедура Specification Required. Для диапазона 8192-16383 сохранен статус Reserved for Private Use, для 16384-40959 применяется процедура Specification Required, а для 40960-65535 сохранен статус Reserved for Private Use.

В имеющийся реестр внесены указанные ниже изменения и ссылки на [RFC5201] заменены ссылками на эту спецификацию.

Тип INVALID_HIP_TRANSFORM_CHOSEN переименован в INVALID_HIP_CIPHER_CHOSEN с прежним значением 17.

Добавлено значение 20 для типа UNSUPPORTED_HIT_SUITE.

Тип HMAC_FAILED переименован в HIP_MAC_FAILED с прежним значением 28.

Тип SERVER_BUSY_PLEASE_RETRY переименован в RESPONDER_BUSY_PLEASE_RETRY с прежним значением 44.

10. Отличия от RFC 5201

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

Этот документ задаёт протокол HIP версии 2, который не совместим с HIP версии 1 [RFC5201]. Основными техническими изменениями являются включение дополнительных функций криптографической гибкости, а также обновление обязательных и дополнительных алгоритмов, включая поддержку эллиптических кривых с помощью алгоритмов Elliptic Curve DSA (ECDSA) и Elliptic Curve Diffie-Hellman (ECDH). Обновлены обязательные для реализации криптоалгоритмы, включая замену HMAC-SHA-1 на HMAC-SHA-256 и алгоритма подписи RSA/SHA-1 на RSASSA-PSS, а также добавление ECDSA к RSA в качестве обязательного типа открытых ключей. Эта версия HIP согласована с пересмотром ORCHID [RFC7343].

Ниже перечислены изменения, внесённые в работу протокола.

• Впараграфе 4.1.3 описан новый процесс для согласования группы Diffie-Hellman (аспект криптографической гибкости). Инициатор может указать предпочтения при выборе группы DH в пакете I1 и предложить несколько вариантов. Ответчик возвращает свои предпочтения на основе локальной политики и предложения Инициатора. Если предложенный Ответчиком выбор не устраивает Инициатора (неподдерживаемый алгоритм), он может запустить базовый обмен заново.

• Другим аспектом криптографической гибкости является добавления возможности применять разные криптографические хэш-функции для создания HIT. Для поддержки этого была введена терминология алгоритма хэширования для HIT Ответчика (RHASH). Кроме того, были добавлены HIT Suite для группировки набора криптографических алгоритмов, применяемых совместно для подписи открытого ключа, функции хэширования и отсечки хэш-значений. Применение HIT Suite ограничивает комбинации при выборе алгоритмов для различных функций. Идентификаторы HIT Suite ID связаны с полем ORCHID OGA ID ([RFC7343]).

• The puzzle mechanism has been slightly changed, in that the #I parameter depends on the HIT hash function (RHASH) selected, and the specification now advises against reusing the same #I value to the same Initiator; more details are provided in Sections 4.1.2 and 5.2.4).

• Параграф 4.1.4 расширен разъяснением деталей перехода счётчика генерации R1 через максимум и сброса.

• Добавлен параграф 4.1.6 с описанием процедур прерывания базового обмена HIP.

• В параграфе 4.1.7 даны рекомендации по предотвращению атак на снижение стойкости криптоалгоритмов.

• В параграфе 4.1.8 обновлено описание режима Opportunistic с учётом криптографической гибкости за счёт процедур выбора HIT.

• Обновлено описание генерации HIP KEYMAT в параграфе 6.5 с учётом согласования функции вывода ключей.

• Обновлено описание обработки пакетов I1, R1, I2 с учётом новых параметров.

• Добавлено требование, в соответствии с которым хосты должны поддерживать обработку параметров ACK с несколькими порядковыми номерами SEQ, даже если они не поддерживают передачу таких параметров.

• Разъяснено, что в пакете R1 может присутствовать несколько параметров ECHO_REQUEST_UNSIGNED, а в I2 — несколько параметров ECHO_RESPONSE.

• Добавлены процедуры отклика на несоответствие версия сообщениями ICMP Parameter Problem.

• Обновлён раздел 8. Вопросы безопасности с удалением атак, которые более не считаются возможными.

• Использование бита Anonymous для возможности применения анонимного Host Identity отправителя поддерживается теперь не только в пакетах R1 и I2.

• Использование шифра NULL HIP CIPHER явно ограничено отладкой и тестированием HIP и поддержка алгоритма перестала быть обязательной.

Ниже перечислены изменения, внесённые в типы и кодирование параметров (параграф 5.2).

• Добавлены 4 типа: DH_GROUP_LIST, HIP_CIPHER, HIT_SUITE_LIST, TRANSPORT_FORMAT_LIST.

• 2 типа параметров переименованы — HMAC в HIP_MAC и HMAC2 в HIP_MAC_2.

• 1 тип признан устаревшим — HIP_TRANSFORM. Функционально он заменён типом HIP_CIPHER, имеющим несколько иную семантику (хеш-значения удалены и определяются параметром RHASH).

• Параметр TRANSPORT_FORMAT_LIST позволяет согласовать транспорт со списком, а не по порядку размещения в пакет HIP.

• Код типа для R1_COUNTER сменен со 128 на 129, поскольку сейчас параметр является критическим и должен возвращаться при его наличии в R1.

• Размер параметров PUZZLE и SOLUTION стал переменным и зависит от размера RHASH.

• Обновлены поддерживаемые идентификаторы Diffie-Hellman Group ID.

• Параметр HOST_ID сейчас требует указания Algorithm.

• Параметр NOTIFICATION поддерживает новые значения Notify Message Type.

• Поле алгоритма HIP_SIGNATURE увеличено в размере с 8 битов до 16 для выравнивания с HOST_ID.

• Спецификация уточняет, что параметр SEQ всегда содержит 1 идентификатор обновления, но ACK может подтверждать несколько идентификаторов обновлений.

• Удалено ограничение, требовавшее наличие лишь одного параметра ECHO_RESPONSE_UNSIGNED в каждом пакете HIP.

• Документ создаёт новый диапазон для выделения параметров, охватываемых подписью (при её наличии) и применяет его к новому параметру DH_GROUP_LIST.

• Документ разъясняет, что в пакете может быть несколько параметров NOTIFY.

Ниже перечислены изменения в содержимом пакетов (параграф 5.3).

• Пакет I1 сейчас включает DH_GROUP_LIST Инициатора.

• Пакет R1 сейчас включает параметры HIP_CIPHER, HIT_SUITE_LIST, DH_GROUP_LIST, TRANSPORT_FORMAT_LIST.

• Пакет I2 сейчас включает параметры HIP_CIPHER и TRANSPORT_FORMAT_LIST.

• Документ разъясняет, что пакеты UPDATE, не включающие параметр SEQ или ACK, недействительны.

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

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

[FIPS.180-4.2012] National Institute of Standards and Technology, «Secure Hash Standard (SHS)», FIPS PUB 180-4, March 2012, <http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf>.

[NIST.800-131A.2011] National Institute of Standards and Technology, «Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths», NIST SP 800-131A, January 2011, <http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf>.

[RFC0768] Postel, J., «User Datagram Protocol», STD 6, RFC 768, August 1980, <http://www.rfc-editor.org/info/rfc768>.

[RFC0793] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, September 1981, <http://www.rfc-editor.org/info/rfc793>.

[RFC1035] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2404] Madson, C. and R. Glenn, «The Use of HMAC-SHA-1-96 within ESP and AH», RFC 2404, November 1998, <http://www.rfc-editor.org/info/rfc2404>.

[RFC2410] Glenn, R. and S. Kent, «The NULL Encryption Algorithm and Its Use With IPsec», RFC 2410, November 1998, <http://www.rfc-editor.org/info/rfc2410>.

[RFC2460] Deering, S. and R. Hinden, «Internet Protocol, Version 6 (IPv6) Specification», RFC 2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.

[RFC2536] Eastlake 3rd, D., «DSA KEYs and SIGs in the Domain Name System (DNS)», RFC 2536, March 1999, <http://www.rfc-editor.org/info/rfc2536>.

[RFC3110] Eastlake 3rd, D., «RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)», RFC 3110, May 2001, <http://www.rfc-editor.org/info/rfc3110>.

[RFC3526] Kivinen, T. and M. Kojo, «More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)», RFC 3526, May 2003, <http://www.rfc-editor.org/info/rfc3526>.

[RFC3602] Frankel, S., Glenn, R., and S. Kelly, «The AES-CBC Cipher Algorithm and Its Use with IPsec», RFC 3602, September 2003, <http://www.rfc-editor.org/info/rfc3602>.

[RFC3972] Aura, T., «Cryptographically Generated Addresses (CGA)», RFC 3972, March 2005, <http://www.rfc-editor.org/info/rfc3972>.

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Resource Records for the DNS Security Extensions», RFC 4034, March 2005, <http://www.rfc-editor.org/info/rfc4034>.

[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, «The Network Access Identifier», RFC 4282, December 2005, <http://www.rfc-editor.org/info/rfc4282>.

[RFC4443] Conta, A., Deering, S., and M. Gupta, «Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification», RFC 4443, March 2006, <http://www.rfc-editor.org/info/rfc4443>.

[RFC4754] Fu, D. and J. Solinas, «IKE and IKEv2 Authentication Using the Elliptic Curve Digital Signature Algorithm (ECDSA)», RFC 4754, January 2007, <http://www.rfc-editor.org/info/rfc4754>.

[RFC4868] Kelly, S. and S. Frankel, «Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec», RFC 4868, May 2007, <http://www.rfc-editor.org/info/rfc4868>.

[RFC5702] Jansen, J., «Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC», RFC 5702, October 2009, <http://www.rfc-editor.org/info/rfc5702>.

[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, «Default Address Selection for Internet Protocol Version 6 (IPv6)», RFC 6724, September 2012, <http://www.rfc-editor.org/info/rfc6724>.

[RFC7343] Laganier, J. and F. Dupont, «An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)», RFC 7343, September 2014, <http://www.rfc-editor.org/info/rfc7343>.

[RFC7402] Jokela, P., Moskowitz, R., and J. Melen, «Using the Encapsulating Security Payload (ESP) Transport Format with the Host Identity Protocol (HIP)», RFC 7402, April 2015, <http://www.rfc-editor.org/info/rfc7402>.

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

[AUR05] Aura, T., Nagarajan, A., and A. Gurtov, «Analysis of the HIP Base Exchange Protocol», in Proceedings of the 10th Australasian Conference on Information Security and Privacy, July 2005.

[CRO03] Crosby, S. and D. Wallach, «Denial of Service via Algorithmic Complexity Attacks», in Proceedings of the 12th USENIX Security Symposium, Washington, D.C., August 2003.

[DIF76] Diffie, W. and M. Hellman, «New Directions in Cryptography», IEEE Transactions on Information Theory Volume IT-22, Number 6, pages 644-654, November 1976.

[FIPS.186-4.2013] National Institute of Standards and Technology, «Digital Signature Standard (DSS)», FIPS PUB 186-4, July 2013, <http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf>.

[FIPS.197.2001] National Institute of Standards and Technology, «Advanced Encryption Standard (AES)», FIPS PUB 197, November 2001, <http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf>.

[HIP-ARCH] Moskowitz, R., Ed., and M. Komu, «Host Identity Protocol Architecture», Work in Progress³, draft-ietf-hip-rfc4423-bis-09, October 2014.

[HIP-DNS-EXT] Laganier, J., «Host Identity Protocol (HIP) Domain Name System (DNS) Extension», Work in Progress⁴, draft-ietf-hip-rfc5205-bis-06, January 2015.

[HIP-HOST-MOB] Henderson, T., Ed., Vogt, C., and J. Arkko, «Host Mobility with the Host Identity Protocol», Work in Progress⁵, draft-ietf-hip-rfc5206-bis-08, January 2015.

[HIP-REND-EXT] Laganier, J. and L. Eggert, «Host Identity Protocol (HIP) Rendezvous Extension», Work in Progress⁶, draft-ietf-hip-rfc5204-bis-05, December 2014.

[KAU03] Kaufman, C., Perlman, R., and B. Sommerfeld, «DoS protection for UDP-based protocols», in Proceedings of the 10th ACM Conference on Computer and Communications Security, October 2003.

[KRA03] Krawczyk, H., «SIGMA: The ‘SIGn-and-MAc’ Approach to Authenticated Diffie-Hellman and Its Use in the IKE Protocols», in Proceedings of CRYPTO 2003, pages 400-425, August 2003.

[RFC0792] Postel, J., «Internet Control Message Protocol», STD 5, RFC 792, September 1981, <http://www.rfc-editor.org/info/rfc792>.

[RFC2785] Zuccherato, R., «Methods for Avoiding the «Small-Subgroup» Attacks on the Diffie-Hellman Key Agreement Method for S/MIME», RFC 2785, March 2000, <http://www.rfc-editor.org/info/rfc2785>.

[RFC2898] Kaliski, B., «PKCS #5: Password-Based Cryptography Specification Version 2.0», RFC 2898, September 2000, <http://www.rfc-editor.org/info/rfc2898>.

[RFC3447] Jonsson, J. and B. Kaliski, «Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1», RFC 3447, February 2003, <http://www.rfc-editor.org/info/rfc3447>.

[RFC3849] Huston, G., Lord, A., and P. Smith, «IPv6 Address Prefix Reserved for Documentation», RFC 3849, July 2004, <http://www.rfc-editor.org/info/rfc3849>.

[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, «Host Identity Protocol», RFC 5201, April 2008, <http://www.rfc-editor.org/info/rfc5201>.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.

[RFC5338] Henderson, T., Nikander, P., and M. Komu, «Using the Host Identity Protocol with Legacy Applications», RFC 5338, September 2008, <http://www.rfc-editor.org/info/rfc5338>.

[RFC5533] Nordmark, E. and M. Bagnulo, «Shim6: Level 3 Multihoming Shim Protocol for IPv6», RFC 5533, June 2009, <http://www.rfc-editor.org/info/rfc5533>.

[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, «IPv4 Address Blocks Reserved for Documentation», RFC 5737, January 2010, <http://www.rfc-editor.org/info/rfc5737>.

[RFC5869] Krawczyk, H. and P. Eronen, «HMAC-based Extract-and-Expand Key Derivation Function (HKDF)», RFC 5869, May 2010, <http://www.rfc-editor.org/info/rfc5869>.

[RFC5903] Fu, D. and J. Solinas, «Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2», RFC 5903, June 2010, <http://www.rfc-editor.org/info/rfc5903>.

[RFC6090] McGrew, D., Igoe, K., and M. Salter, «Fundamental Elliptic Curve Cryptography Algorithms», RFC 6090, February 2011, <http://www.rfc-editor.org/info/rfc6090>.

[RFC6253] Heer, T. and S. Varjonen, «Host Identity Protocol Certificates», RFC 6253, May 2011, <http://www.rfc-editor.org/info/rfc6253>.

[RFC7045] Carpenter, B. and S. Jiang, «Transmission and Processing of IPv6 Extension Headers», RFC 7045, December 2013, <http://www.rfc-editor.org/info/rfc7045>.

[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, «Internet Key Exchange Protocol Version 2 (IKEv2)», STD 79, RFC 7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.

[RSA] Rivest, R., Shamir, A., and L. Adleman, «A Method for Obtaining Digital Signatures and Public-Key Cryptosystems», Communications of the ACM 21 (2), pp. 120-126, February 1978.

[SECG] SECG, «Recommended Elliptic Curve Domain Parameters», SEC 2 Version 2.0, January 2010, <http://www.secg.org/>.

Приложение A. Использование головоломок Ответчиком

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

Ответчик создает секретное значение S, которое затем обновляет периодически. При этом Ответчик должен помнить 2 последних значения S. При каждой регенерации S счётчик генерации (R1_COUNTER) R1 увеличивается на 1.

Ответчик создаёт подписанный заранее пакет R1. Подписи для созданных заранее пакетов R1 должны пересчитываться при повторном расчёте ключа DH или смене значения R1_COUNTER при регенерации S.

Когда Инициатор передаёт пакет I1 для инициализации соединения, Ответчик получает из пакета тег HIT и адрес IP и генерирует значение #I для головоломки. Значение #I устанавливается для заранее подписанного пакета R1.

       #I = Ltrunc( RHASH ( S | HIT-I | HIT-R | IP-I | IP-R ), n)

где n = RHASH_len. Алгоритм RHASH совпадает с применяемым при генерации тега HIT для Ответчика.

Во входящем пакете I2 Ответчик получает сведения, требуемые для проверки решения головоломки: теги HIT, адреса IP и сведения об используемом значение S из R1_COUNTER. По этим значениям Ответчик может снова создать значение #I и сравнить его с полученным в пакете I2. Если значения #I совпадают, он может проверить решение головоломки, используя #I, #J и #K (сложность), в противном случае пакет I2 отбрасывается.

       V := Ltrunc( RHASH( I2.I | I2.hit_i | I2.hit_r | I2.J ), #K )
       если V != 0, пакет отбрасывается

Если решение головоломки верное, значения #I и #J сохраняются для последующего применения в качестве входных данных при генерации ключевого материала.

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

Приложение B. Генерация кодирования открытого ключа из HI

Приведённый ниже псевдокод иллюстрирует процесс генерации ключа шифрования из HI для RSA и DSA. Символ := указывает назначение (присваивание), += — добавление в конец. Псевдофункция encode_in_network_byte_order принимает два параметра — целое число (bignum) и размер в байтах, возвращая целое число в форме строки байтов заданного размера.

   switch ( HI.algorithm )
   {

   case RSA:
      buffer := encode_in_network_byte_order ( HI.RSA.e_len,
                ( HI.RSA.e_len > 255 ) ? 3 : 1 )
      buffer += encode_in_network_byte_order ( HI.RSA.e, HI.RSA.e_len )
      buffer += encode_in_network_byte_order ( HI.RSA.n, HI.RSA.n_len )

      break;

   case DSA:
      buffer := encode_in_network_byte_order ( HI.DSA.T , 1 )
      buffer += encode_in_network_byte_order ( HI.DSA.Q , 20 )
      buffer += encode_in_network_byte_order ( HI.DSA.P , 64 +
                                               8 * HI.DSA.T )
      buffer += encode_in_network_byte_order ( HI.DSA.G , 64 +
                                               8 * HI.DSA.T )
      buffer += encode_in_network_byte_order ( HI.DSA.Y , 64 +
                                               8 * HI.DSA.T )

      break;

   }

Приложение C. Примеры контрольных сумм для пакетов HIP

Контрольная сумма HIP для пакетов HIP задана в параграфе 5.1.1, контрольные суммы пакетов TCP и UDP, передаваемых через защищённые связи с поддержкой HIP, — в параграфе 4.5.1. Приведённые ниже примеры используют адреса [RFC3849] и [RFC5737], а также HIT с префиксом 2001:20, за которым следуют нули, а затем десятичное значение 1 и 2, соответственно.

Приведённый ниже пример предназначен лишь для тестирования расчёта контрольной суммы.

C.1. IPv6 HIP (пакет I1)

     Адрес отправителя:              2001:db8::1
     Адрес получателя:               2001:db8::2
     Размер пакета вышележ. уровня:  48              0x30
     Следующий заголовок:            139             0x8b
     Протокол Payload:               59              0x3b
     Размер заголовка:               5               0x5
     Тип пакета:                     1               0x1
     Версия:                         2               0x2
     Резерв:                         1               0x1
     Управление:                     0               0x0
     Контрольная сумма:              6750            0x1a5e
     HIT отправителя:                2001:20::1
     HIT получателя:                 2001:20::2
     Тип DH_GROUP_LIST:              511             0x1ff
     Размер DH_GROUP_LIST:           3               0x3
     DH_GROUP_LIST Group ID :        3,4,8

C.2. IPv4 HIP (пакет I1)

     Адрес отправителя:              192.0.2.1
     Адрес получателя:               192.0.2.2
     Размер пакета вышележ. уровня:  48              0x30
     Следующий заголовок:            139             0x8b
     Протокол Payload:               59              0x3b
     Размер заголовка:               5               0x5
     Тип пакета:                     1               0x1
     Версия:                         2               0x2
     Резерв:                         1               0x1
     Управление:                     0               0x0
     Контрольная сумма:              61902           0xf1ce
     HIT отправителя:                2001:20::1
     HIT получателя:                 2001:20::2
     Тип DH_GROUP_LIST:              511             0x1ff
     Размер DH_GROUP_LIST:           3               0x3
     DH_GROUP_LIST Group ID:         3,4,8

C.3. Сегмент TCP

Независимо от протокола IPv6 или IPv4 сокеты TCP и UDP используют формат псевдозаголовка IPv6 [RFC2460] с HIT вместо адресов IPv6.

     HIT отправителя:                2001:20::1
     Receiver's HIT:                 2001:20::2
     Размер пакета вышележ. уровня:  20              0x14
     Следующий заголовок:            6               0x06
     Порт отправителя:               65500           0xffdc
     Порт получателя:                22              0x0016
     Порядковый номер:               1               0x00000001
     Номер подтверждения:            0               0x00000000
     Смещение данных:                5               0x5
     Флаги:                          SYN             0x02
     Размер окна:                    65535           0xffff
     Контрольная сумма:              28586           0x6faa
     Указатель важности:             0               0x0000

Приложение D. 160-битовые группы ECDH и ECDSA

160-битовые группы ECDH и ECDSA SECP160R1 рассчитаны на симметричную стойкость 80 битов. Когда-то это считалось достаточным для защиты в течение года. Сегодня эти группы следует применять лишь для хостов с невысокой производительностью (например, встраиваемые устройства) и при низких требованиях к безопасности (например, не нужна долгосрочная защита конфиденциальности).

Приложение E. HIT Suite и генерация HIT

HIT как идентификатор ORCHID [RFC7343] состоит из трёх частей — 28-битовый префикс, 4-битовый код алгоритма генерации ORCHID (OGA) и хэш-значения, включающее Host Identity и идентификатор контекста. Индекс OGA указывает конкретный алгоритм, с помощью которого создаётся открытый ключ и 96-битовое хэшированное кодирование. OGA зависит от протокола и интерпретируется, как описано ниже, для всех протоколов, использующих общий с HIP идентификатор контекста. Группы HIP задают действительные комбинации алгоритмов подписи и хэширования в HIT Suite. Эти наборы HIT Suite указываются индексом, который передаётся в поле OGA ID идентификаторов ORCHID.

Набор применяемых HIT Suite будет расширяться по мере роста вычислительных возможностей и обнаружения уязвимостей в применяемых алгоритмах. Предполагается использование HIT Suite для внедрения новых наборов и отказа от старых, пока они ещё не стади опасными. Поскольку 4-битовое поле OGA ID позволяет иметь лишь 15 HIT Suite одновременно (HIT Suite ID = 0 является резервным), идентификаторы отмененных HIT Suite потребуется применять снова. В таких случаях может просходить «опрокидывание» (rollover) HIT Suite ID и недавно добавленный HIT Suite будет иметь меньший индекс, нежели его предшественник. «Опрокидование» фактически препятствует повторному использованию HIT Suite. Для плавного перехода следует отменять HIT Suite заблаговременно до повторного использования индекса HIT Suite.

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

HIT Suite в HIT Ответчика определяет RHASH и хэш-функцию, которая будет применяться для HMAC в пакетах HIP, а также семейство алгоритмов подписи для генерации HI. Список HIT Suite приведён в таблице 10.

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

Стремление создать протокол HIP возникло после заседания MALLOC на 43-й конференции IETF. Baiju Patel и Hilarie Orman реально помогли исходному автору Bob Moskowitz вывести HIP за рамки 5 абзацев идей. Протокол обрел зрелость благодаря значительному вкладу членов IETF. Самое главное, что цели разработки были чётко сформулированы и отличались от других работ в этом направлении. Особо следует отметить членов исследовательской группы IRTF NameSpace. Noel Chiappa внёс ценный влад на ранних этапах обсуждения обработки идентификаторов, а Keith Moore — толчок для обеспечения распознаваемости. Steve Deering призывал продолжать работу, поскольку стойкость могла служить подтверждением перспективности идей для исследовательской группы.

Много людей внесло вклад в работу — ценные советы по безопасности дал Steve Bellovin, Rob Austein следил за связанными с DNS частями, Call Kocher научил Bob Moskowitz, как сделать головоломки сложными для ответа Инициатору, но простыми для проверки Ответчиком. Bill Sommerfeld предложил концепцию днейрождения, которая позднее превратилась в счётчик генерации R1, для простого управления перезагрузкой. Erik Nordmark предложил механизм CLOSE для завершения соединений, Rodney Thayer и Hugh Daniels предоставили множество откликов. На ранних стадиях разработки документа John Gilmore заставлял Bob Moskowitz предлагать что-то важное.

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

Как обычно бывает в IETF, много людей внесло свой вклад в текст и идеи. Список этих людей включает Jeff Ahrenholz, Francis Dupont, Derek Fawcus, George Gross, Xin Gu, Rene Hummen, Miika Komu, Mika Kousa, Julien Laganier, Andrew McGregor, Jan Melen, Henrik Petander, Michael Richardson, Tim Shepard, Jorma Wall, Jukka Ylitalo. Приносим свои извинения тем, кого забыли включить в этот список.

После создания в начале 2004 г. рабочей группы HIP в документ было внесено множество изменений. В частности, исходный документ был поделен на две части, одна из которых описывала базовый обмен, а другая — использование ESP. Некоторые изменения протокола, предлоенные Aura и др. [AUR05], были добавлены на финальном этапе.

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

Robert Moskowitz (редактор)

HTT Consulting

Oak Park, MI

United States

EMail: rgm@labs.htt-consult.com

Tobias Heer

Hirschmann Automation and Control

Stuttgarter Strasse 45-51

Neckartenzlingen 72654

Germany

EMail: tobias.heer@belden.com

Petri Jokela

Ericsson Research NomadicLab

Jorvas FIN-02420

Finland

Phone: +358 9 299 1

EMail: petri.jokela@nomadiclab.com

Thomas R. Henderson

University of Washington

Campus Box 352500

Seattle, WA

United States

EMail: tomhend@u.washington.edu

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

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

nmalykh@protokols.ru