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

Internet Research Task Force (IRTF)                             A. Clemm
Request for Comments: 9315                                     Futurewei
Category: Informational                                     L. Ciavaglia
ISSN: 2070-1721                                                    Nokia
                                                         L. Z. Granville
                         Federal University of Rio Grande do Sul (UFRGS)
                                                             J. Tantsura
                                                               Microsoft
                                                            October 2022

Intent-Based Networking – Concepts and Definitions

Сеть на основе намерений – концепции и определения

PDF

Аннотация

Сети на основе намерений (Intent или Intent-Based) берут отрасль штурмом. Однако термины, связанные с такими сетями, часто применяются расплывчато и непоследовательно, во многих случаях перекрываясь и смешиваясь с другими концепциями (например, политика – policy). В этом документе разъяснён термин «намерение» (intent) и дан обзор связанной с ним функциональности. Цель состоит в содействии общему пониманию терминов, концепций и функциональности, которые могли бы послужить основой для дальнейших определений исследовательских и инженерных задач, а также их решения.

Документ является результатом работы группы IRTF Network Management Research Group (NMRG) и отражает согласованное мнение группы, получив множество подробных положительных отзывов от участников группы. Документ публикуется с информационными целями.

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

Документ не относится к категории Internet Standards Track и публикуется лишь для информации.

Документ является результатом работы IRTF¹. IRTF публикует результаты относящихся к Internet исследований и разработок. Эти результаты могут оказаться не пригодными для реализации. Данный RFC представляет согласованное мнение исследовательской группы Coding for Efficient Network Communications в рамках IRTF. Документы, одобренные для публикации IRSG, не претендуют на статус Internet Standard (см. раздел 2 в RFC 7841).

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

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

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

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

1. Введение

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

В прошлом интерес к управлению и операциям в рамках IETF был сосредоточен на характеристиках отдельных сетей и устройств. В стандартизации акцент обычно был смещён на инструменты управления, которые должны предоставляться сетевым устройствам. Ярким примером служит управление на основе SNMP [RFC3411] и более 200 MIB, заданных IETF за эти годы. Более свежие примеры включают определения моделей данных YANG [RFC7950] для таких аспектов, как настройка интерфейсов, списков управления доступом (Access Control List или ACL) и Syslog.

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

В соответствии с этим в IETF начали заниматься аспектами сквозного управления, выходящими за рамки отдельных изолированных устройств. Примеры включают задание моделей YANG для топологии сети [RFC8345] или введение моделей служб, применяемых системами оркестровки и контроллерами [RFC8309]. Большой интерес вызвало обсуждение вопросов самоуправления сетей в рабочей группе ANIMA. Такие сети движимы желанием снизить операционные расходы и упростить управление сетью в целом, что вступает в противоречие с необходимостью управлять одним устройством и одной функцией за раз. Хотя самоуправляемые сети предназначены для демонстрации свойств «самоуправления» (self-management), они по-прежнему требуют действий оператора или внешней системы для обеспечения операционных рекомендаций и сведений о целях, задачах и экземплярах служб, которые сеть должна обслуживать.

Эти входные данные и операционные рекомендации обычно называют намерениями (intent), а сеть, позволяющую операторам предоставить свои данные в форме намерений, – сетью на основе намерений (Intent-Based Network или IBN). Сеть, помогающую реализовать намерения, называют основанной на намерениях системой (Intent-Based System или IBS). Такие системы могут по разному проявлять себя, например, как контроллер, система управления, реализованная в виде приложения, которое работает на сервере или группе серверов, или набор распределенных в сети функций, совместно реализующих основанную на намерениях функциональность.

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

Такое представление стало популярным в отрасли и привело к разработке множества решений, предлагающий управление на основе намерений (Intent-Based Management), обещающее сервис-провайдерам целостное управление сетями с высоким уровнем абстракций как системой, состоящей из соединённых компонентов, а не набора независимых устройств (соединённых между собой). Такие предложения включают IBN и IBS (с полным жизненным циклом намерений), контроллеры программно управляемых сетей (Software-Defined Network или SDN), обеспечивающие единую точку управления и администрирования для сети, а также системы управления сетью и системы поддержки операций (Operations Support System или OSS).

Давно признано, что комплексные решения для управления не могут работать лишь на уровне отдельных устройств и конфигураций нижнего уровня. В этом смысле представление намерений не является совсем новым. В прошлом модель ITU-T для управления телекоммуникационной сетью (Telecommunications Management Network или TMN) представляла набор уровней управления, определяющий иерархию управления для сетевых элементов, сети, сетевых служб и бизнеса [M3010]. Операционные цели высокого уровня распространяются в модели сверху вниз. Связанная иерархия абстракций имеет решающее значение для разложения комплексного управления на отдельные области задач. Эта иерархия абстракций сопровождается информационной иерархией, которая на нижнем уровне касалась сведений, относящихся к конкретным устройствам, а на верхних уровнях включала, например, экземпляры сквозного сервиса. Аналогично концепция управления на основе правил (Policy-Based Network Management или PBNM) долгое время расхваливала возможность позволить пользователям² управлять сетями путём задания высокоуровневых правил управления, при этом системы управления автоматически «толковали» (rendering) эти правила, т. е. переводили их в конфигурации нижнего уровня и логику управления.

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

Следует отметить, что формулировка связанных с IBN исследовательских проблем выходит за рамки документа. Однако следует признать, что сети IBN стали важной темой в сообществе исследователей. Согласно IEEE Xplore [IEEEXPLORE] по состоянию на декабрь 2021 г за 10 лет с 2012 г. было опубликовано 1138 с термином intent, из которых 411 конкретно посвящены сетям. Только за период с 2020 г. было опубликовано 316 статей о «намерениях» и 153 – о сетях на основе намерений. Кроме того, проводятся семинары, посвящённые этой теме, такие как IEEE International Workshop on Intent-Based Networking [WIN21], а также специальные выпуски журналов [IEEE-TITS21]. Обзор текущих исследований представлен в [PANG20], где среди наиболее важных исследовательских задач указаны такие вопросы, как трансляция и понимание намерений, интерфейсы и безопасность.

2. Определения и сокращения

ACL

Access Control List – список управления доступом.

API

Application Programming Interface – интерфейс с прикладными программами.

IBA

Intent-Based Analytics – основанная на намерениях аналитика. Аналитика, определённая и выведенная из намерений пользователей и служащая для проверки предусмотренного состояния.

IBN

Intent-Based Network – сеть на базе намерений. Сеть, управляемая с использованием намерений.

IBS

Intent-Based System – система на базе намерений. Система, поддерживающая функции управления с помощью намерений.

Intent – намерения

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

Intent-Based Management – управление на базе намерений

Концепция управления на основе концепции намерений.

PBNM

Policy-Based Network Management – управление сетью на основе правил.

PDP

Policy Decision Point – точка принятия решений по правилам.

PEP

Policy Enforcement Point – точка применения правил (политики).

Policy – правила (политика)

Набор правил, определяющих выбор поведения системы.

Service Model – модель сервиса

Модель, представляющая услугу, которую сеть предоставляет пользователям.

SsoT

Single Source of Truth – единая точка доверия. Функциональный блок системы IBN, нормализующий намерения пользователей и служащий единым источником данных для нижележащих уровней.

Statement of Intent – заявление о намерениях

Спецификация отдельного аспекта или компонента намерений, называемая также заявлением намерений.

SvoT

Single Version of Truth – единая версия доверия.

User – пользователь

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

3. Концепции

Ниже представлен обзор концепция для намерений и управления на основе намерений (IBM), а также связанных с ними концепций моделей услуг и политики (и PBNM) и описаны их взаимоотношения с намерениями и IBM.

3.1. Намерения и управление на их основе

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

Термин intent был впервые введён в контексте самоуправляемых сетей (Autonomic Network), где он был определён как «абстрактная политика высокого уровня, применяемая для работы сети» [RFC7575]. В соответствии с этим определением намерения являются конкретным типом политики, предоставляемым пользователем для обеспечения руководства самоуправляемой сетью, которая в остальном работает без привлечения людей. Однако, чтобы термин «намерения» не рассматривался как синоним политики, нужно чётко указать отличие намерений от иных правил.

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

Управление на основе намерений (IBM) направлено на создание сетей, которые проще поддерживать и эксплуатировать и которые требуют минимального вмешательства извне. Сети (даже самоуправляемые) не являются ясновидящими и не могут автоматически узнавать, какие операционные цели и экземпляры сетевых служб нужно поддерживать. Иными словами, они не знают намерений провайдера, придающих смысл существованию сети. Все ещё требуется указывать сетям, что собой представляют такие намерения. При этом концепция намерений не ограничивается сетями с самоуправлением, такими как сети с автономной (самоуправляемой) плоскостью управления (Autonomic Control Plane) [RFC8994], а применимы к любым сетям.

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

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

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

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

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

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

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

• Обеспечить для услуг постоянную защиту пути на всех путях (желаемый результат с неочевидным способом его достижения).

• Генерировать на месте данные эксплуатации, администрирования и поддержки (Operations, Administration, and Maintenance или OAM) и сетевой телеметрии для последующего автономного анализа при каждом наблюдении значительных флуктуаций задержки на пути (выход за рамки события-условия-действия без задания степени значимости и собираемых данных).

• Направлять трафик в космической сети (Space Information Network) так, чтобы минимизировать зависимость от стратостатов, если предполагаемым получателем не является самолёт (не задан способ достижения, экстраполяция сценариев из [PANG20]).

• Для услуги «умный город» обеспечить использование сигналами светофором выделенных и резервируемых «срезов» (slice), чтобы избежать «общей судьбы» (желаемый результат с набором ограничений и дополнительной рекомендацией без указания способа достижения, экстраполяция сценария из [GHARBAOUI21]).

Ниже приведены примеры, не являющиеся выражением намерений (на естественном языке для простоты).

• Настроить на данном интерфейсе адрес IP (это настройка устройства и манипулирование «кнопками»).

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

• Настроить VPN с туннелем между A и B по пути P (это настройка сервиса).

• Запретить трафик к префиксу P1, если он не исходит от префикса P2 (правило доступа или межсетевого экрана, а не намерение).

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

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

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

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

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

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

3.2. Связанные концепции

3.2.1. Модели сервиса

Модель сервиса – это модель, представляющая услугу, обеспечиваемую пользователю сетью. В соответствии с [RFC8309] модель сервиса описывает услугу и её параметры независимым от реализации переносимым способом, который можно применять независимо от оборудования и операционной среды, где реализована услуга. Различают две категории – модель обслуживания клиентов (Customer Service Model) описывает экземпляр предоставляемой клиенту услуги, возможно требующей заказа, а модель предоставления услуги (Service Delivery Model) описывает реализацию услуги в имеющейся сетевой инфраструктуре.

Примерами могут служить услуги L3 VPN [RFC8299], Network Slice [NETWORK-SLICE] или локальный доступ в Internet. Модели сервиса представляют экземпляры служб как самостоятельные сущности. Службы имеют свои параметры, действия и жизненные циклы. Обычно экземпляр службы может быть привязан к конкретным пользователям коммуникационных услуг, которым могут быть выставлены счета за предоставляемые услуги.

Создание службы обычно включает несколько аспектов, указанных ниже.

• Пользователь (или северная система) определяет и/или запрашивает создание экземпляра службы.

• Выделяются ресурсы (адреса IP, номера AS, пулы VLAN или VxLAN, интерфейсы, полоса, память).

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

• Привязки между объектами верхнего и нижнего уровня, которые нужно поддерживать.

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

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

Созданные экземпляры моделей услуг отображаются на низкоуровневые модели сетей и устройств, например, экземпляры путей или конкретных конфигураций портов. Модель сервиса обычно включает также уровня служб и зависимости от нижележащих сетевых ресурсов, требуемых для предоставления услуги. Это упрощает управление, позволяя следовать зависимостям в действиях по устранению неполадок и анализу влияния, когда события в сети оцениваются с точки зрения воздействия на службы и клиентов. Службы обычно организуются и предоставляются «сверху вниз», что также упрощает отслеживание назначения сетевых ресурсов (композиция), а поиск и устранение неполадок выполняется «снизу вверх» (декомпозиция). Модели сервиса могут быть связаны с другими данными, не относящимися к сети, но обеспечивающими бизнес-контекст. Это включает сведения о клиентах (например, информация для выставления счетов), заказы услуг, каталоги служб, тарифы, договоры на обслуживание и соглашения об уровне обслуживания (Service Level Agreement или SLA), включая договорные соглашения по корректирующим действиям.

[SERVICE-MAPPING-YANG] служит примером модели данных, обеспечивающей отображение моделей обслуживания клиентов (например, L3VPN Service Model) на модели организации трафика (Traffic Engineering или TE, например, TE Tunnel или the Abstraction and Control of Traffic Engineered Networks Virtual Network).

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

3.2.2. Политика и управление сетью на её основе

Управление сетью на основе правил (PBNM) – это парадигма управления, разделяющие правила поведения системы и её функциональность. Это обещает снизить расходы на поддержку информационных и коммуникационных систем одновременно повышая гибкость и адаптивность при работе. Сегодня это лежит в основе множества архитектур и парадигм управления, включая основанные на SLA, требованиях бизнеса, самоуправляемые, адаптивные и самоподдерживающиеся [BOUTABA07]. Заинтересованным читателям рекомендуется обратиться к имеющейся литературе, включающей множество ссылок. Здесь представлен лишь краткий обзор.

В основе такого управления лежит концепция правил (политики). Имеется множество определений политики – правила, регулирующие выбор поведение системы [SLOMAN94], набор правил, применяемых для поддержки и управления сменой и поддержанием состояния одного или нескольких объектов [STRASSNER03]. Общим для большинства определений является то, что политика считается «правилом». Обычно определение правила включает событие (которое вызывает правило), набор условий (при выполнении которых происходят фактические действия) и одно или несколько выполняемых действий.

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

Политика обычно предполагает некую степень абстракции, чтобы справиться с неоднородностью сетевых устройств. Вместо правил для конкретных устройств, задающих события, условия и действия в терминах зависящих от устройства команд, параметров и моделей данных, политика определяется на более высоком уровне абстракции, включающем каноническую модель систем и устройств, к которым она применяется. Агент политики в контроллере или устройстве последовательно «разбирает» правила, т. е. транслирует каноническую модель в соответствующее устройству представление. Эта концепция позволяет применять одну политику для широкого класса устройств без необходимость создания множества вариантов. Иными словами, определение политики отделено от её реализации и исполнения. Это позволяет расширять операционный масштаб и даёт сетевым операторам и авторам политики возможность использовать абстракции более высокого уровня, нежели специфика устройств, и применять определения высокого уровня в разных сетевых доменах, сетях WAN, центрах обработки данных (ЦОД или DC) облаках общего пользования.

В PBNM обычно применяется выталкивание (push) – правила выталкиваются в устройства, где они разбираются и применяются. Операции выталкивания выполняет менеджер или контроллер, отвечающий за развёртывание политики в сети и отслеживание корректности работы правил. Возможна иная архитектура политики, например, управление на основе правил может включать компонент втягивания (pull) в котором решение о предпринимаемых действиях передаётся точке принятия решений (Policy Decision Point или PDP). PDP может размещаться вне управляемого устройства и обычно имеет глобальную видимость и контекст для принятия решений. Всякий раз при наблюдении устройством события, связанного с политикой, при отсутствии полного определения правила или возможности выбрать действие, устройство обращается к PDP за решением (принимаемым, например, в соответствии с условиями). Затем устройство применяет решение, полученное от PDP, исполняя политику и действуя как точка применения правил (Policy Enforcement Point или PEP). В любом случае архитектура PBNM обычно включает центральный элемент, распространяющий правила по сети или принимающий решения.

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

3.2.3. Различия между намерениями, политикой и моделями служб

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

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

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

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

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

4. Принципы

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

1. Единый источник (Single Source of Truth или SSoT) и одна версия (Single Version of Truth или SVoT) доверия. SSoT является важной частью IBS, позволяя выполнять несколько важных операций. В качестве SsoT системы служит набор проверенных выражений намерений. SsoT и записи рабочих состояний позволяют сравнивать предполагаемое/желаемое состояние с фактическим/операционным состоянием системы и определять различия между ними. SSoT и различия служат основой для корректирующих действий. Если в IBS имеются средства прогнозирования состояний, можно дополнительно разрабатывать стратегии предсказания, планирования и упреждающих действий в отношении любых тенденций расхождения с целью минимизации их влияния. Помимо предоставления средств для согласования работы системы, SSoT позволяет улучшить отслеживание для проверки, были ли и насколько хорошо выполнены исходные намерения и связанные с ними бизнес-цели для оценки влияния изменений в параметрах намерений, а также влияния и последствий происходящих в системе событий.

   Единая версия (или представление – View) доверия выводится из SSoT и может служить для выполнения таких операций, как запросы, опросы или фильтрация измеренных или полученных сопоставлением данных для создания так называемых «представлений» (view). Эти представления могут помогать пользователям IBS. Для создания заявления о намерениях как единого источника доверия система IBS должна следовать чётко заданным и хорошо документированным процессам и моделям. SSoT также называют неизменностью намерений [LENROW15].

2. Одно касание, но не один шаг. В идеальной системе IBS пользователь в той или иной форме выражает намерения, а система выполняет все последующие операции (одно касание). Можно представить и подход «без касания» (zero-touch), если IBS имеет возможности или средства распознавания намерений в любой форме данных. Однако это не должно отвлекать от того, что достижение корректно сформированного и правильного выражения намерений не является одношаговым (one-shot) процессом. Напротив, взаимодействие между пользователем и IBS следует организовывать как итерационный процесс. В зависимости от уровня абстракции выражение намерений исходно может содержать в той или иной степени неявные части, а также неточные или неизвестные параметры и ограничения. Роль IBS заключается в разборе, понимании и уточнении намерений для достижения чётко сформированного и действительного выражения намерений, которое система может использовать для операций исполнения и подтверждения. Процесс уточнения намерений может включать комбинацию итерационных шагов, вовлекающих пользователя в проверку предложенных уточнений и уточнение некоторых параметров и переменных, которые система не может вывести или узнать самостоятельно. Кроме того, IBS потребуется разрешение конфликтов в намерениях, чтобы помочь пользователю сделать верный выбор среди вариантов, которые могут иметь разные последствия.

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

4. Обучение. IBS – обучающаяся система. В отличие от императивных систем, таких как правила «событие-условие-действие» (Event-Condition-Action), где пользователь заранее задаёт ожидаемое поведение, в IBS пользователь лишь объявляет предполагаемое поведение системы, не указывая способов его достижения. Таким способом происходит передача рассуждений/рационализма от человека (знание предметной области) к системе. Эта передача когнитивных возможностей подразумевает наличие в IBS способов или средств обучения, рассуждения, а также представления знаний и управления ими. Способности IBS к обучению могут применяться для разных задач, таких как оптимизация разбора и уточнения намерений. Способность IBS к постоянному развитию создаёт условия для постоянного обучения и оптимизации. Другие когнитивные возможности, такие как планирование, также могут применяться в IBS для прогнозирования или предсказания будущих состояний системы и откликов на изменения намерений или условий в сети и соответствующей выработки планов по адаптации к этим изменениям при сохранении стабильности и эффективности системы, а также компромисса между стоимостью и надёжностью операций.

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

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

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

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

• Абстракция и связанная с ней виртуализация, не зависящие от деталей реализации.

• Настроенное на человека сетевое взаимодействие. IBN следует «говорить» на языке пользователя, не требуя от него «языка» устройств или сетей.

• Возможность объяснения как важная функция IBN, обнаружение и разрешение с помощью IBN конфликтов намерений, а также согласование желаний пользователя с фактическими возможностями сети.

• Встроенная поддержка, верификация и гарантии доверия.

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

5. Функциональность IBN

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

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

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

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

5.1. Реализация намерений

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

5.1.1. Восприятие намерений и взаимодействие с пользователями

Первый набор функций связан с восприятием намерений, т. е. их получением через взаимодействие с пользователями. Он представляет функции распознавания намерений из взаимодействия с пользователем, а также функции, позволяющие пользователю уточнить свои намерения и сформулировать их подходящим для IBS способом. Обычно эти функции выходят за рамки API, не основанных на намерениях, хотя некоторые из таких API также могут предоставляться (и требуются для взаимодействия с пользователем без участия человека, т. е. с другой машиной). Во многих случаях включается также набор интуитивно понятных и простых в обращении рабочих процессов, ведущих пользователя на этапе восприятия намерений, гарантируя сбор всех требуемых для моделирования и последовательной трансляции намерений. Они могут поддерживать нетрадиционное взаимодействие человека с машиной, где человек не просто даёт команды, а использует диалог «человек-машина» для разъяснения, указания ветвлений и компромиссов, а также для упрощения корректировок.

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

5.1.2. Трансляция намерений

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

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

5.1.3. Оркестровка намерений

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

5.2. Обеспечение намерений

Обеспечение намерений (Intent Assurance) связано с функциями, требуемые для гарантии соответствия сети, воспринятым намерениям.

5.2.1. Мониторинг

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

5.2.2. Оценка соответствия намерений

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

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

5.2.3. Действия по обеспечению соответствия

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

5.2.4. Абстракции, агрегирование, отчёты

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

6. Жизненный цикл

Намерения имеют жизненный цикл – они возникают, могут меняться со временем и отзываться в какой-то момент. Этот жизненный цикл тесно связан с функциями взаимодействия в концепции намерений. На рисунке 1 показан жизненный цикл намерений и его основные функции. Указанные в разделе 5 функции разделены (по вертикали) на 2 функциональные плоскости, отражающие различия между исполнением и обеспечением. Каждая плоскость разделена по горизонтали на 3 части, показывающие разные точки зрения и взаимодействие с разными ролями.

• Пользовательское пространство включает функции, связывающие сеть и IBS с пользователем-человеком. Это функции, позволяющие человеку сформулировать, а IBS – реализовать намерения. Здесь имеются также функции информирования о состоянии сети в части намерений, позволяющие пользователю оценить результат и его соответствие намерениям.

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

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

      Пользовательское   :       Пространство            :  Пространство
      пространство       :      трансляции (IBS)         :  сетевых
                         :                               :  операций
           +----------+  :  +----------+   +-----------+ : +-----------+
Восприятие |распознав.|---> |трансляция|-->|  обучение |-->| настройка/|
           |и генерац.|     |    и     |   |планирован.|   |предоставл.|
           |намерений |<--- |уточнение |   |воспроизвед| : |           |
           +----^-----+  :  +----------+   +-----^-----+ : +-----------+
                |        :                       |       :        |
   .............|................................|................|.....
                |        :                  +----+---+   :        v
                |        :                  |проверка|   :  +----------+
                |        :                  +----^---+ <----| отслежив.|
Обеспечение +---+---+    :  +---------+    +-----+---+   :  |наблюдение|
            | отчет | <---- |абстракц.|<---| анализ  | <----|          |
            +-------+    :  +---------+    |агрегиров|   :  +----------+
                         :                 +---------+   :

Рисунок 1. Жизненный цикл намерений.

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

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

• «Внешний» контур управления намерениями распространяется на пространство пользователя. Он включает действия пользователя и корректировку намерений на основе наблюдений и обратной связи от IBS.

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

7. Дополнительные соображения

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

Operational Intent – эксплуатационные намерения

Намерения, связанные с эксплуатационными целями оператора. Это соответствует исходному термину intent и концепциям данного документа.

Rule Intent – намерения для политики

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

Service Intent – намерения для сервиса

Синоним модели обслуживания клиентов [RFC8309].

Flow Intent – намерения для потока

Синоним цели уровня обслуживания (Service Level Objective) для данного потока.

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

8. Взаимодействие с IANA

Этот документ не требует действий IANA.

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

В этом документе описаны концепции и даны определения для основанных на намерениях сетей (Intent-Based Networking). Поэтому приведённые ниже соображения безопасности сохраняют высокий уровень, т. е указаны в виде принципов, рекомендаций или требований. Более подробное рассмотрение будет приведено в документах, задающих архитектуру и функциональность.

Безопасность в IBN имеет несколько аспектов:

• защита самой системы IBS;

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

• выражение правил или параметров безопасности в заявлениях о намерениях.

Защита IBS нацелена на обеспечения операционной безопасности IBS за счёт внедрения механизмов защиты и применения накопленного опыта. В контексте IBN такие механизмы и методы могут включать проверку намерений, предоставление возможности работать с намерениями лишь проверенным и уполномоченным пользователям, обнаружение фальсифицированных намерений и защиту от них. Такие механизмы могут включать внедрение нескольких уровней намерений. Например, намерения, связанные с защитой сети, следует помещать на «более глубокий» уровень, который при необходимости переопределяет намерения других уровней, а сам не может быть изменён обычными операциями и требует применения защищённых операций. Следует также рассмотреть применение дополнительных механизмов, таких как компоненты разъяснений, описывающие ветвления защиты и компромиссы, которые следует учитывать.

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

Выражение правил или связанных с безопасностью параметров намерений включает использование формализма намерений (высокоуровневые декларативные абстракции) или их частей для задания связанных с безопасностью аспектов:

• управление данными;

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

• уровни доступности ресурсов системы, защиты на путях пересылки, изоляция в функциях обработки;

• уровни шифрования;

• уполномоченные для выполнения операций.

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

По мере роста уровня понимания технологий IBN потребуется более тщательно анализировать вопросы безопасности.

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

[BOUTABA07] Boutaba, R. and I. Aib, “Policy-Based Management: A Historical Perspective”, Journal of Network and Systems Management (JNSM), Vol. 15, Issue 4, DOI 10.1007/s10922-007-9083-8, November 2007, <https://doi.org/10.1007/s10922-007-9083-8>.

[CLEMM20] Clemm, A., Faten Zhani, M., and R. Boutaba, “Network Management 2030: Operations and Control of Network 2030 Services”, Journal of Network and Systems Management (JNSM), Vol. 28, Issue 4, DOI 10.1007/s10922-020-09517-0, October 2020, <https://doi.org/10.1007/s10922-020-09517-0>.

[GHARBAOUI21] Gharbaoui, M., Martini, B., and P. Castoldi, “Implementation of an Intent Layer for SDN-enabled and QoS-Aware Network Slicing”, 2021 IEEE 7th International Conference on Network Softwarization (NetSoft), pp. 17-23, DOI 10.1109/NetSoft51509.2021.9492643, June 2021, <https://doi.org/10.1109/NetSoft51509.2021.9492643>.

[IEEE-TITS21] Garg, S., Guizani, M., Liang, Y-C., Granelli, F., Prasad, N., and R. R. V. Prasad, “Guest Editorial Special Issue on Intent-Based Networking for 5G-Envisioned Internet of Connected Vehicles”, IEEE Transactions on Intelligent Transportation Systems, Vol. 22, Issue 8, pp. 5009-5017, DOI 10.1109/TITS.2021.3101259, August 2021, <https://doi.org/10.1109/TITS.2021.3101259>.

[IEEEXPLORE] IEEE, “IEEE Xplore”, <https://ieeexplore.ieee.org/>.

[LENROW15] Lenrow, D., “Intent As The Common Interface to Network Resources”, Intent Based Network Summit 2015 ONF Boulder: IntentNBI, February 2015.

[M3010] ITU-T, “Principles for a telecommunications management network”, ITU-T Recommendation M.3010, February 2000.

[NETWORK-SLICE] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and J. Tantsura, “Framework for IETF Network Slices”, Work in Progress, Internet-Draft, draft-ietf-teas-ietf-network-slices-14, 3 August 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-ietf-network-slices-14>.

[PANG20] Pang, L., Yang, C., Chen, D., Song, Y., and M. Guizan, “A Survey on Intent-Driven Networks”, IEEE Access, Vol. 8, pp.22862-22873, DOI 10.1109/ACCESS.2020.2969208, January 2020, <https://doi.org/10.1109/ACCESS.2020.2969208>.

[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, “An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks”, STD 62, RFC 3411, DOI 10.17487/RFC3411, December 2002, <https://www.rfc-editor.org/info/rfc3411>.

[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., Carpenter, B., Jiang, S., and L. Ciavaglia, “Autonomic Networking: Definitions and Design Goals”, RFC 7575, DOI 10.17487/RFC7575, June 2015, <https://www.rfc-editor.org/info/rfc7575>.

[RFC7950] Bjorklund, M., Ed., “The YANG 1.1 Data Modeling Language”, RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[RFC8299] Wu, Q., Ed., Litkowski, S., Tomotaki, L., and K. Ogaki, “YANG Data Model for L3VPN Service Delivery”, RFC 8299, DOI 10.17487/RFC8299, January 2018, <https://www.rfc-editor.org/info/rfc8299>.

[RFC8309] Wu, Q., Liu, W., and A. Farrel, “Service Models Explained”, RFC 8309, DOI 10.17487/RFC8309, January 2018, <https://www.rfc-editor.org/info/rfc8309>.

[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, “A YANG Data Model for Network Topologies”, RFC 8345, DOI 10.17487/RFC8345, March 2018, <https://www.rfc-editor.org/info/rfc8345>.

[RFC8994] Eckert, T., Ed., Behringer, M., Ed., and S. Bjarnason, “An Autonomic Control Plane (ACP)”, RFC 8994, DOI 10.17487/RFC8994, May 2021, <https://www.rfc-editor.org/info/rfc8994>.

[SERVICE-MAPPING-YANG] Lee, Y., Ed., Dhody, Dhruv., Ed., Fioccola, G., Wu, Q., Ed., Ceccarelli, D., and J. Tantsura, “Traffic Engineering (TE) and Service Mapping YANG Data Model”, Work in Progress, Internet-Draft, draft-ietf-teas-te-service-mapping-yang-11, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-teas-te-service-mapping-yang-11>.

[SLOMAN94] Sloman, M., “Policy Driven Management for Distributed Systems”, Journal of Network and Systems Management (JNSM), Vol. 2, Issue 4, pp. 333-360, December 1994.

[STRASSNER03] Strassner, J., “Policy-Based Network Management”, August 2003.

[TR523] Open Networking Foundation, “Intent NBI – Definition and Principles”, ONF TR-523, October 2016.

[WIN21] Ciavaglia, L. and E. Renault, “1st International Workshop on Intent-Based Networking”, IEEE International Conference on Network Softwarization, June 2021, <https://netsoft2021.ieee-netsoft.org/program/workshops/win-2021/>.

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

Спасибо членам исследовательской группы IRTF Network Management (NMRG) за полезные дискуссии и отклики. В частности, авторы хотели бы поблагодарить Remi Badonnel, Walter Cerroni, Marinos Charalambides, Luis Contreras, Jerome Francois, Molka Gharbaoui, Olga Havel, Chen Li, William Liu, Barbara Martini, Stephen Mwanje, Jeferson Nobre, Haoyu Song, Peter Szilagyi, Csaba Vulkan за отклики и поддержку. Отдельная благодарность Remi Badonnel, Walter Cerroni, Jerome Francois, Molka Gharbaoui, Barbara Martini, Stephen Mwanje, Peter Szilagyi, Csaba Vulkan, сделавшим ещё один шаг и предоставившим рецензии.

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

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                A. Rodriguez-Natal
Request for Comments: 9306                                         Cisco
Updates: 8060                                                 V. Ermagan
Category: Experimental                                      Google, Inc.
ISSN: 2070-1721                                               A. Smirnov
                                                           V. Ashtaputre
                                                                   Cisco
                                                            D. Farinacci
                                                             lispers.net
                                                            October 2022

Vendor-Specific LISP Canonical Address Format (LCAF)

Фирменные LCAF

PDF

Аннотация

Этот документ описывает новый формат канонического представления адресов (Canonical Address Format или LCAF) протокола разделения идентификаторов и локаторов (Locator/ID Separation Protocol или LISP) для фирменных (Vendor-Specific) LCAF. Этот формат позволяет организациям применять своё кодирование LCAF. Документ обновляет RFC 8060.

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

Этот документ не является спецификацией Track и публикуется для проверки, экспериментальной реализации и оценки.

Документ определяет экспериментальный протокол для сообщества Internet. Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG². Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

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

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

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

Канонический формат адресов LISP (LCAF) [RFC8060] задаёт форму и представление адресов разных типов, которые могут применяться в реализациях протокола LISP [RFC9300] [RFC9301]. Однако в некоторых реализациях могут применяться особые форматы, не применимые в других реализациях. Этот документ расширяет [RFC8060], вводя фирменный формат (Vendor-Specific LCAF), определяющий способ создания адресов LCAF для использования в конкретных реализациях LISP. Этот документ также обновляет [RFC8060], задавая поведение для нераспознанных типов LCAF.

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

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

3. Нераспознанные типы LCAF

В [RFC8060] обработка неизвестных типов LCAF не описана. Этот документ обновляет [RFC8060], указывая, что любые нераспознанные типы LCAF, полученные в сообщении плоскости управления LISP, должны игнорироваться. Если игнорируются все локаторы, это эквивалентно приёму управляющего сообщения LISP с Locator Count = 0, как указано в [RFC9301]. Если EID-Prefix содержит лишь нераспознанные типы LCAF, управляющее сообщение LISP должно отбрасываться, а в системный журнал должна вноситься запись об этом (EID обозначает идентификатор конечной точки).

4. Фирменные LCAF

В Vendor-Specific LCAF используется уникальный идентификатор организации (IEEE Organizationally Unique Identifier или OUI) [IEEE.802] для предотвращения конфликтор при использовании LCAF. Формат Vendor-Specific LCAF показан на рисунке 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           AFI = 16387         |     Rsvd1     |     Flags     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = 255  |     Rsvd2     |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Rsvd3    |    Organizationally Unique Identifier (OUI)   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Internal format...                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 1. Фирменный LCAF.

Поля первых 8 октетов Vendor-Specific LCAF совпадают с полями базового формата LCAF, заданного в [RFC8060]. Поле Type должно иметь значение 255, выделенное IANA для фиременныхLCAF (см. 6. Взаимодействие с IANA). Значение поля Length учитывает поле Internal format, а также поля OUI и Rsvd3 как в [RFC8060]. Эти поля для Vendor-Specific LCAF описаны ниже.

Rsvd3

8-битовое резервное поле. Оно должно иметь значение 0 при передаче, а получатель должен игнорировать поле.

Organizationally Unique Identifier (OUI)

24-битовое поле OUI или идентификатора компании (Company ID или CID), выделенного агентством регистрации IEEE (Registration Authority или RA) в соответствии со стандартом IEEE Std 802 [IEEE.802]

Internal format

Поле переменного размера, не задаваемое этим документом. Каждый производитель или организация могут задавать свои форматы для использования в Vendor-Specific LCAF.

Тип Vendor-Specific LCAF не следует применять в системах, где взаимодействуют разные организации. Однако во многих случаях на практике две или более организации используют общую систему и тогда им требуется явно согласовать применение конкретных Vendor-Specific LCAF. В таких случаях вовлечённые организации должны тщательно оценить взаимодействия в конкретном развёртывании. Не рекомендуется применять значения OUI, не выделенные организации.

Если устройство LISP получает сообщение LISP, содержащее Vendor-Specific LCAF с неизвестным OUI, оно должно отбросить это сообщение и следует указать это событие в системном журнале.

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

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

6. Взаимодействие с IANA

В соответствии с рекомендациями [RFC8126] агентство IANA выделило для Vendor-Specific LCAF значение из реестра LISP Canonical Address Format (LCAF) Types, заданного в [RFC8060]).

Таблица 1. Назначение Vendor-Specific LCAF.

 

Значение	Имя типа LISP LCAF	Документ
255	Vendor Specific	RFC 9306, раздел 4

 

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

[IEEE.802] IEEE, “IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture”, DOI 10.1109/IEEESTD.2014.6847097, IEEE Std 802, July 2014, <https://ieeexplore.ieee.org/document/6847097>.

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, “LISP Canonical Address Format (LCAF)”, RFC 8060, DOI 10.17487/RFC8060, February 2017, <https://www.rfc-editor.org/info/rfc8060>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos, Ed., “The Locator/ID Separation Protocol (LISP)”, RFC 9300, DOI 10.17487/RFC9300, October 2022, <https://www.rfc-editor.org/info/rfc9300>.

[RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, Ed., “Locator/ID Separation Protocol (LISP) Control Plane”, RFC 9301, DOI 10.17487/RFC9301, October 2022, <https://www.rfc-editor.org/info/rfc9301>.

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

Авторы признательны Joel Halpern, Luigi Iannone, Alvaro Retana за предложения и рекомендации.

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

Alberto Rodriguez-Natal

Cisco

Spain

Email: natal@cisco.com

 

Vina Ermagan

Google, Inc.

1600 Amphitheatre Parkway

Mountain View, CA 94043

United States of America

Email: ermagan@gmail.com

 

Anton Smirnov

Cisco

Diegem

Belgium

Email: asmirnov@cisco.com

 

Vrushali Ashtaputre

Cisco

San Jose, CA

United States of America

Email: vrushali@cisco.com

 

Dino Farinacci

lispers.net

San Jose, CA

United States of America

Email: farinacci@gmail.com

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

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

nmalykh@protokols.ru

---

Internet Engineering Task Force (IETF)                     F. Maino, Ed.
Request for Comments: 9305                                         Cisco
Category: Standards Track                                       J. Lemon
ISSN: 2070-1721                                                         
                                                              P. Agarwal
                                                                Innovium
                                                                D. Lewis
                                                                M. Smith
                                                                   Cisco
                                                            October 2022

Locator/ID Separation Protocol (LISP) Generic Protocol Extension

Расширение базового протокола LISP

PDF

Аннотация

В этом документе описаны расширения плоскости данных протокола разделения локаторов и идентификаторов (Locator/ID Separation Protocol или LISP) путём изменения заголовка LISP для поддержки многопротокольной инкапсуляции и расширения возможностей протокола.

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

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG². Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

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

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

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

Плоскость данных LISP задана в [RFC9300] и определяет формат инкапсуляции для передачи пакетов IPv4 и IPv6 (далее IP) с использованием заголовка LISP и внешнего транспорта UDP/IP.

Заголовок плоскости данных LISP не указывает инкапсулируемый протокол, поэтому в настоящее время инкапсуляция применяется лишь для пакетов IP. Другие протоколы, прежде всего, VXLAN³ [RFC7348] (определяющий формат заголовка, аналогичный LISP) применяются для инкапсуляции протоколов канального уровня (Layer 2 или L2), таких как Ethernet.

Этот документ залает расширение заголовка LISP, определённого в [RFC9300], для указания внутреннего протокола, что позволяет инкапсулировать Ethernet, IP или иной нужный протокол, сохраняя совместимость с имеющимися развёртываниями LISP.

Применяется флаг заголовка LISP (бит P) для указания наличия 8-битового поля Next Protocol. При наличии этого поля оно занимает 8 битов, выделенных в [RFC9300] для функций Echo-Noncing и Map-Versioning. Эти две функции становятся недоступными при использовании бита P. Однако можно задать подходящий промежуточные (shim) заголовки расширения базового протокола LISP (LISP Generic Protocol Extension или LISP-GPE) для задания возможностей, эквивалентных Echo-Noncing и Map-Versioning.

Поскольку все резервные биты заголовка плоскости данных LISP уже заняты, LISP-GPE можно использовать также для расширения заголовка плоскости данных LISP путём задания промежуточных заголовокв Next Protocol, реализующих новые функции плоскости данных, не поддерживаемые в заголовке LISP. Например, используя заголовок основанных на группах правил (Group-Based Policy или GBP) header [VXLAN-LISP] или IOAM⁴ [VXLAN-GPE] с LISP-GPE, можно рассмотреть расширение для поддержки в плоскости данных функций GBP или метаданных IOAM.

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

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

1.2. Определения терминов

В этом документе используются термины, определённые в [RFC9300].

2. Заголовок LISP без расширений протокола

Как описано в разделе 1, заголовок LISP не включает идентификатор протокола, указывающий тип передаваемого содержимого (payload). Поэтому в LISP передаются только пакеты IP.

Заголовок LISP [RFC9300] содержит набор флагов (часть их зарезервирована), поле Nonce/Map-Version и поле Instance ID/Locator-Status-Bits. Флаги обеспечивают гибкое кодирование полей. Отметим, что бит 5 остался последним резервным флагом заголовка LISP.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|R|K|K|            Nonce/Map-Version                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Instance ID/Locator-Status-Bits               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 1. Заголовок LISP.

3. Расширение базового протокола LISP (LISP-GPE)

Этот документ задаёт два изменения заголовков LISP для поддержки многопротокольной инкапсуляции – флаг P и поле Next Protocol. Документ задаёт поведение протокола при установленном (1) флаге P, а сброшенный (0) бит P прежнее поведение. Заголовок LISP-GPE показан на рисунке 2 и описан ниже.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|P|K|K|        Nonce/Map-Version/Next Protocol        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Instance ID/Locator-Status-Bits               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 2. Заголовок LISP-GPE.

P

Бит 5 задан как флаг Next Protocol, установка (1) которого говорит о наличии 8-битового поля Next Protocol. Сброшенный (0) бит указывает, что заголовок LISP полностью соответствует определению [RFC9300].

При установленном флаге P биты N, E, V и биты 8-23 поля Nonce/Map-Version/Next Protocol должны сбрасываться (0) при отправке, а получатель должен игнорировать их. Свойства, эквивалентные реализованным с помощью битов N, E, и V в [RFC9300], такие как Echo-Noncing и Map-Versioning, можно обеспечить путём задания подходящих промежуточных заголовков LISP-GPE.

 0 x 0 0 x 1 x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|P|K|K|             0x0000            | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Instance ID/Locator-Status-Bits               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 3. LISP-GPE с установленным битом P.

Заголовок LISP-GPE с установленным флагом P показан на рисунке 3.

Next Protocol

При установленном (1) флаге P младшие 8 битов первого 32-битового слова служат полем Next Protocol, указывающим протокол, инкапсулируемый в поле данных пакета.

Этот документ определяет указанные ниже значения Next Protocol.

   0x00:  резерв
   0x01:  IPv4
   0x02:  IPv6
   0x03:  Ethernet
   0x04:  Network Service Header (NSH) [RFC8300]
   0x05 - 0x7D:  не распределены
   0x7E и 0x7F:  эксперименты и тестирование
   0x80 - 0xFD:  не распределены (shim-заголовки)
   0xFE, 0xFF:  эксперименты и тестирование (shim-заголовки)

Эти значения внесены в реестр IANA LISP-GPE Next Protocol, как указано в параграфе 6.1.

Значения Next Protocol 0x7E, 0x7F, 0xFE, 0xFF выделены для экспериментов и тестирования в [RFC3692], значения 0x80 – 0xFD – для протоколов, кодируемых как промежуточные (shim) заголовки. Все такие протоколы должны использовать структуру заголовка, показанную на рисунке 4, которая включает поле Next Protocol. При использовании shim-заголовков с другими протоколами, указанными значениями Next Protocol от 0x00 до 0x7F, промежуточные заголовки должны быть первыми.

Промежуточные заголовки позволяют поэтапно внедрять новые функции GPE, сохраняя их понятную данной реализации туннельного маршрутизатора (Tunnel Router или xTR) обработку на «быстром» пути (обычно ASIC⁵) и переводя новые функции GPE на «медленный» путь.

 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    | Next Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                    Protocol-Specific Fields                   ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 4. Shim-заголовок.

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

Type

Служит для идентификации различных сообщений данного протокола.

Length

Ращмер протокольного сообщения в 4-октетных блоках без учёта первых 4 октетов.

Reserved

Зарезервировано для протокола, определённого в этом сообщении.

Next Protocol

Указывает протокол для инкапсулируемых данных (payload). Значения протоколов указаны в реестре IANA LISP-GPE Next Protocol (параграф 6.1).

4. Вопросы реализации и внедрения

4.1. Заявление о применимости

LISP-GPE, как протокол инкапсуляции на обснове UDP, соответствует рекомендациям по использованию UDP из [RFC8085]. Применимость этих рекомендаций зависит от базовой сети IP и природы инкапсулируемых данных.

В [RFC8085] описано два варианта примерения приложений UDP для 1) общедоступной сети Internet и 2) контролируемой среды. Контролируемая среда предполагает один административный домен или набор смежных взаимодействующих доменов. Сетью в контролируемой среде можно управлять для создания определённых рабочих условий, а в общедоступной сети Internet это невозможно. Поэтому требования к туннельным протоколам для контролируемых сред задают меньше ограничений, чем для работы в общедоступной сети Internet.

Сфера применимости LISP-GPE совпадает с набором вариантов использования, указанных в [RFC9300] для протокола плоскости данных LISP. Общим свойством этих вариантов применения является наличие большого набора взаимодействующих элементов, стремящимися обмениваться данными через общедоступную сеть Internet или иные крупные инфраструктуры IP с отделением адресации и топологии взаимодействующих элементов от топологии, маршрутизации и адресации базовой сети и Internet.

Расширение LISP-GPE рассчитано на реализацию в сетевых средах, управляемых одним оператором или операторами взаимодействующих смежных сетей, которые соответствуют определению контролируемых сред в [RFC8085].

Для целей этого документа контролируемая среда с управляемым трафиком (Traffic-Managed Controlled Environment или TMCE), описанная в [RFC8086], рассматривается как сеть IP с организацией трафика (traffic-engineered) и/или иным управлением (например, применением ограничителей скорости трафика) для предотвращения перегрузки. Значительная часть текста этого разела заимствована из [RFC8086].

Операторы сетей отвечают за соблюдение требований и рекомендаций этого раздела в своих системах с LISP-GPE.

4.2. Функциональность контроля перегрузок

LISP-GPE не предоставляет функций контроля перегрузки и полагается в этом плане инкапсулированный протокол (payload). Поэтому требуется использовать LISP-GPE с трафиком, для которого имеется контроль перегрузок, или внутри сети с управлением трафиком для предотвращения перегрузок (TMCE). Оператор сети с управлением трафиком (TMCE) может избежать перегрузок за счёт тщательной настройки своих сетей, ограничения скорости пользовательского трафика и его организации в соответствии с возможностями сетевых путей.

С учётом приведённых выше рекомендаций новые инкапсулируемые данные при регистрации в LISP-GPE должны сопровождаться набором рекомендаций, выведенных из раздела 5 в [RFC9300]. Такие новые протоколы следует разрабатывать с явными сигналами контроля перегрузки от нижележащего протокола в IP. После этого межсетевой уровень IP может выступать уровнем переноса для доставки уведомлений от перегруженных узлов, не понимающих бит IP, наверх до транспортного уровня (L4). Следуя рекомендациям [ENCAP-GUIDE], создатели подсетей могут разрешить протоколу L2 участие в контроле перегрузок без отбрасывания пакетов путём распространения получателям данных явного контроля перегрузок (Explicit Congestion Notification или ECN) [RFC3168].

4.3. Контрольная сумма UDP

Для данных IP (payload) в параграфе 5.3 [RFC9300] задана обработка контрольных сумм UDP с предложением к разработчикам учитывать рекомендации по контрольным суммам UDP из параграфа 3.4 в [RFC8085], когда они хотят защитить от повреждений заголовки UDP и LISP.

Для защиты целостности заголовков LISP-GPE, опций и данных (например, для предотвращения доставки данных в систему другого арендатора при повреждении поля данных) следует использовать внешнюю контрольную сумму UDP с LISP-GPE при транспортировке по протоколу IPv4. Контрольная сумма UDP обеспечивает статистические гарантии сохранности содержимого в процессе доставки. Такие проверки целостности не являются криптографически строгими и не предназначены для обнаружения ошибок на физическом уровне или враждебного изменения дейтаграмм (см. параграф 3.4 в [RFC8085]). В системах, где такой риск возникает, операторам следует использовать дополнительные механизмы защиты целостности данных, такие как IPsec.

Оператор может отказаться от применения контрольных сумм UDP (использовать нулевую сумму), если защита целостности пакетов LISP-GPE обеспечивается другими механизмами, такими как IPsec, или выполняется одно из условий параграфа 4.3.1 (a, b или c).

4.3.1. Обработка нулевой контрольной суммы UDP для IPv6

По умолчанию контрольная сумма UDP должна использоваться при доставке LISP-GPE по протоколу IPv6. Конечную точку туннеля можно настроить на использование нулевой контрольной суммы UDP, если выполняются дополнительные требования, указанные в этом параграфе.

При использовании LISP-GPE с протоколом IPv6 контрольная сумма UDP служит для защиты заголовков IPv6, UDP и LISP-GPE, а также данных от возможных повреждений. Таким образом, по умолчанию для LISP-GPE должна применяться контрольная сумма UDP при доставке через IPv6. Оператор может настроить работу с нулевой контрольной суммой UDP при работе в контролируемой среде с управлением трафиком, как указано в параграфе 4.1, если выполняется какое-либо из приведённых ниже условий.

1. Известно, что повреждение пакетов крайне маловероятно (возможно, на основе сведений оператора о применяемом в базовой сети оборудовании) и оператор принимает риск незамеченного повреждения пакетов.

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

3. Данные LISP-GPE передаются приложениям, устойчивым к ошибочной доставке и повреждениям пакетов (возможно, за счёт проверки контрольных сумм вышележащих уровней или надёжного повтора передачи).

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

1. Использование контрольной суммы UDP при работе по протоколу IPv6 должно быть по умолчанию включено для всех туннелей LISP-GPE.

2. Если LISP-GPE применяется с нулевой контрольной суммой UDP по протоколу IPv6, реализации xTR должны соблюдать все требования, указанные в разделе 4 [RFC6936] и требование 1 из раздела 5 в [RFC6936].

3. Выходным маршрутизаторам туннелей (Egress Tunnel Router или ETR), декапсулирующим пакеты, следует проверять, что адреса отправителя и получателя IPv6 действительны для туннеля LISP-GPE, настроенного на использование нулевой контрольной суммы UDP, и отбрасывать не прошедшие проверку пакеты.

4. Входные маршрутизаторы туннелей (Ingress Tunnel Router или ITR), инкапсулирующие пакеты, могут использовать разные адреса отправителя IPv6 для каждого туннеля LISP-GPE с нулевой контрольной суммой UDP, чтобы усилить проверку адреса отправителя IPv6 декапсулятором (т. е. один и тот же адрес отправителя IPv6 не применяется для нескольких адресов получателей IPv6, как индивидуальных, так и групповых). Если это невозможно, рекомендуется применять каждый адрес отправителя для как можно меньшего числа туннелей LISP-GPE с нулевой контрольной суммой UDP.

5. Следует принимать меры для предотвращения выхода туннельного трафика LISP-GPE по протоколу IPv6 с нулевой контрольной суммой UDP в общедоступную сеть Internet. Такими мерами являются фильтры пакетов на выходных маршрутизаторах-посредниках (Proxy Egress Tunnel Router или PETR) и физическое или логическое отделение сети LISP от общедоступных сетей Internet.

Приведённые выше требования не меняют требований [RFC6935], [RFC6936], [RFC8200].

Требование проверки адреса отправителя IPv6 в дополнение к проверке адреса получателя IPv6, а также рекомендации не использовать один адрес отправителя IPv6 для разных туннелей LISP-GPE совместно несколько смягчают отсутствие охвата контрольной суммой UDP в заголовке IPv6. В среде с управляемым трафиком, соответствующей хотя бы 1 из приведённых в начале параграфа требований, обеспечиваются дополнительные гарантии.

4.4. DSCP, ECN, TTL, 802.1Q

При инкапсуляции пакетов IP (включая Ethernet) документ [RFC2983] обеспечивает руководство по отображению кодов дифференцированного обслуживания (Differentiated Services Code Point или DSCP) между внутренними и внешними заголовками IP. При использовании сетевой виртуализации обычно лучше всего подходит модель Pipe. Значение DSCP в туннельном заголовке устанавливается на основе правил (оно может быть фиксированным, зависеть от класса трафика во внутреннем заголовке или определяться иным механизмом группировки трафика). Могут быть применимы некоторые аспекты модели Uniform (она трактует внутреннее и внешнее значения DSCP как одно поле, выполняя копирование на входе и выходе), такие как возможность перемаркировки внутреннего заголовка на выходе туннеля на основе транзитной маркировки. Однако модель Uniform концептуально не согласуется с виртуализацией сети в части строгой изоляции инкапсулированного трафика от физической сети.

В [RFC6040] описан механизм раскрытия возможностей ECN в туннелях IP и распространения маркеров на внутренние пакеты. Такому поведению должны следовать пакеты IP, инкапсулированные в LISP-GPE.

Хотя обе модели Uniform и Pipe пригодны для TTL (Hop Limit для IPv6) при обработке туннельных пакетов IP, модель Pipe лучше подходит для виртуализации сетей. В [RFC2003] даны рекомендации по обработке TTL внутренних и внешних заголовков IP, этот подход ближе к модели Pipe и рекомендуется для приложений виртуализации сетей с использованием LISP-GPE.

При выполнении маршрутизатором LISP-GPE инкапсуляции Ethernet внутреннее значение 3-битового кода приоритета (Priority Code Point или PCP) 802.1Q [IEEE.802.1Q_2014] может отображаться в код DSCP поля дифференцированного обслуживания (Differentiated Services или DS) внешнего заголовка, определённое в [RFC2474]. Поле идентификатора VLAN 802.1Q (VLAN Identifier или VID) [IEEE.802.1Q_2014] может отображаться в поле идентификатора экземпляра LISP (Instance ID или IID) или применяться для его установки.

В разделе 7 рассмотрены вопросы защиты целостности для развёртываний, таких как общедоступная сеть Internet, связанные с атаками извне пути.

5. Совместимость с прежними версиями

LISP-GPE использует порт получателя UDP 4341, выделенный для LISP.

При инкапсуляции пакетов IP для маршрутизатора, не поддерживающего LISP-GPE, флаг P должен сбрасываться (0), т. е. заданный этим документом формат инкапсуляции недопустимо применять для маршрутизаторов, не указавших поддержку этой спецификации, поскольку такие маршрутизаторы будут игнорировать флаг P (как указано в [RFC9300]) и в результате ошибочно интерпретировать другие поля заголовка LISP, что может приводить к значимым ошибкам.

5.1. Обнаружение возможностей ETR

Обнаружение поддержки LISP-GPE маршрутизаторами xTR выходит за рамки этого документа. С учётом того, что областью применимости LISP-GPE являются контролируемые среды с управлением трафиком, для этого могут применяться механизмы настройки ITR и ETR (xTR).

6. Взаимодействие с IANA

6.1. Реестр LISP-GPE Next Protocol

Агентство IANA создало реестр LISP-GPE Next Protocol, содержащий 8-битовые значения. В таблице 1 приведены значения Next Protocol, заданные этим документом. Новые значения выделяются по процедуре Specification Required [RFC8126]. Протоколы, которым выделяются значения, не обязательно относятся к категории IETF Standards Track.

Таблица 1.

 

Next Protocol	Описание	Документ
0x00	Резерв	RFC 9305
0x01	IPv4	RFC 9305
0x02	IPv6	RFC 9305
0x03	Ethernet	RFC 9305
0x04	NSH	RFC 9305
0x05-0x7D	Не выделены
0x7E-0x7F	Эксперименты и тестирование	RFC 9305
0x80-0xFD	Не выделены (shim-заголовки)
0xFE-0xFF	Эксперименты и тестирование (shim-заголовки)	RFC 9305

 

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

Соображения безопасности для LISP-GPE похожи на вопросы безопасности и методы смягчения проблем для LISP, описанные в [RFC7835].

Как другие варианты инкапсуляции с применением необязательных расширений, LISP-GPE подвергается воздействию злоумышленников, размещённых на пути доставки, которые могут пытаться изменить пакеты (включая флаг P) для удаления или изменения частей данных (payload) или заявления инкапсуляции иного протокола. Следует применять типовые методы защиты целостности (например, IPsec) в сочетании с LISP-GPE для расширений протоколов, которым нужна защита от злоумышленников на пути доставки.

При использовании LISP-GPE такие проблемы, как подмена плоскости данных, лавинные атаки и перенаправление трафика, могут зависеть от конкретного инкапсулируемого протокола.

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

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

[IEEE.802.1Q_2014] IEEE, “IEEE Standard for Local and metropolitan area networks–Bridges and Bridged Networks”, IEEE Std 802.1Q-2014, December 2014, <https://ieeexplore.ieee.org/document/6991462>.

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC6040] Briscoe, B., “Tunnelling of Explicit Congestion Notification”, RFC 6040, DOI 10.17487/RFC6040, November 2010, <https://www.rfc-editor.org/info/rfc6040>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos, Ed., “The Locator/ID Separation Protocol (LISP)”, RFC 9300, DOI 10.17487/RFC9300, October 2022, <https://www.rfc-editor.org/info/rfc9300>.

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

[ENCAP-GUIDE] Briscoe, B. and J. Kaippallimalil, “Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP”, Work in Progress, Internet-Draft, draft-ietf-tsvwg-ecn-encap-guidelines-17, 11 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-encap-guidelines-17>.

[RFC2003] Perkins, C., “IP Encapsulation within IP”, RFC 2003, DOI 10.17487/RFC2003, October 1996, <https://www.rfc-editor.org/info/rfc2003>.

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers”, RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.

[RFC2983] Black, D., “Differentiated Services and Tunnels”, RFC 2983, DOI 10.17487/RFC2983, October 2000, <https://www.rfc-editor.org/info/rfc2983>.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, “The Addition of Explicit Congestion Notification (ECN) to IP”, RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.

[RFC3692] Narten, T., “Assigning Experimental and Testing Numbers Considered Useful”, BCP 82, RFC 3692, DOI 10.17487/RFC3692, January 2004, <https://www.rfc-editor.org/info/rfc3692>.

[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, “IPv6 and UDP Checksums for Tunneled Packets”, RFC 6935, DOI 10.17487/RFC6935, April 2013, <https://www.rfc-editor.org/info/rfc6935>.

[RFC6936] Fairhurst, G. and M. Westerlund, “Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums”, RFC 6936, DOI 10.17487/RFC6936, April 2013, <https://www.rfc-editor.org/info/rfc6936>.

[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, “Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks”, RFC 7348, DOI 10.17487/RFC7348, August 2014, <https://www.rfc-editor.org/info/rfc7348>.

[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, “Locator/ID Separation Protocol (LISP) Threat Analysis”, RFC 7835, DOI 10.17487/RFC7835, April 2016, <https://www.rfc-editor.org/info/rfc7835>.

[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, “UDP Usage Guidelines”, BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.

[RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, “GRE-in-UDP Encapsulation”, RFC 8086, DOI 10.17487/RFC8086, March 2017, <https://www.rfc-editor.org/info/rfc8086>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8200] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., “Network Service Header (NSH)”, RFC 8300, DOI 10.17487/RFC8300, January 2018, <https://www.rfc-editor.org/info/rfc8300>.

[VXLAN-GPE] Brockners, F., Bhandari, S., Govindan, V., Pignataro, C., Gredler, H., Leddy, J., Youell, S., Mizrahi, T., Kfir, A., Gafni, B., Lapukhov, P., and M. Spiegel, “VXLAN-GPE Encapsulation for In-situ OAM Data”, Work in Progress, Internet-Draft, draft-brockners-ippm-ioam-vxlan-gpe-03, 4 November 2019, <https://datatracker.ietf.org/doc/html/draft-brockners-ippm-ioam-vxlan-gpe-03>.

[VXLAN-LISP] Lemon, J., Ed., Maino, F., Smith, M., and A. Isaac, “Group Policy Encoding with VXLAN-GPE and LISP-GPE”, Work in Progress, Internet-Draft, draft-lemon-vxlan-lisp-gpe-gbp-02, 30 April 2019, <https://datatracker.ietf.org/doc/html/draft-lemon-vxlan-lisp-gpe-gbp-02>.

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

Особая благодарность Dino Farinacci за руководство и детальный обзор. Спасибо Tom Herbert за обсуждение и назначение кодов для экспериментов и тестирования.

Участники работы

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

Darrel Lewis

Cisco Systems, Inc.

 

Fabio Maino

Cisco Systems, Inc.

 

Paul Quinn

Cisco Systems, Inc.

 

Michael Smith

Cisco Systems, Inc.

 

Navindra Yadav

Cisco Systems, Inc.

 

Larry Kreeger

 

Jennifer Lemon

Broadcom

 

Puneet Agarwal

Innovium

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

Fabio Maino (editor)

Cisco Systems

San Jose, CA

United States of America

Email: fmaino@cisco.com

 

Jennifer Lemon

Email: jalemon@meus.us

 

Puneet Agarwal

Innovium

United States of America

Email: puneet@acm.org

 

Darrel Lewis

Cisco Systems

San Jose, CA

United States of America

Email: darlewis@cisco.com

 

Michael Smith

Cisco Systems

San Jose, CA 95134

United States of America

Email: michsmit@cisco.com

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

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

nmalykh@protokols.ru

---

Internet Engineering Task Force (IETF)                          F. Maino
Request for Comments: 9303                                 Cisco Systems
Category: Standards Track                                     V. Ermagan
ISSN: 2070-1721                                             Google, Inc.
                                                             A. Cabellos
                                    Universitat Politecnica de Catalunya
                                                               D. Saucez
                                                                   Inria
                                                            October 2022

Locator/ID Separation Protocol Security (LISP-SEC)

Защита протокола LISP

PDF

Аннотация

Этот документ описывает защиту протокола разделения идентификаторов и локаторов (Locator/ID Separation Protocol Security или LISP-SEC), представляющую собой набор механизмов аутентификации, защиты целостности и защиты от повторного использования (anti-replay) для данных отображений идентификаторов конечных точек на локаторы маршрутизации LISP (Endpoint-ID-to-Routing-Locator или EID-RLOC), передаваемых процессами поиска сопоставлений. LISP-SEC также позволяет проверять полномочность заявления префиксов EID-Prefix в сообщениях Map-Reply.

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

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG². Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

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

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

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

Протокол разделения идентификаторов и локаторов (Locator/ID Separation Protocol или LISP) [RFC9300] [RFC9301] является протоколом сетевого уровня, позволяющим разделить адреса IP на два независимых пространства – идентификаторы конечных точек (Endpoint Identifier или EID) и локаторы маршрутизации (Routing Locator или RLOC). Сопоставления EID с RLOC хранятся в базе данных и системе отображения LISP Mapping System, будучи доступными через процесс поиска Map-Request/Map-Reply. Если эти отображения EID-RLOC, передаваемые с сообщениях Map-Reply, не имеют защиты целостности, злоумышленник может манипулировать ими и захватывать коммуникации, выдавать себя за нужный EID, создавать атаки на службы (Denial-of-Service или DoS), в том числе, распределенные (Distributed Denial-of-Service или DDoS). При передаче Map-Reply без проверки подлинности враждебный элемент LISP может перезаявить EID-Prefix и перенаправить трафик. Модель угроз LISP-SEC, описанная в разделе 4, создана на основе модели угроз LISP, заданной в [RFC7835] и включающей подробное описание атак с перезаявлением (overclaiming).

Этот документ задаёт набор механизмов безопасности LISP-SEC, обеспечивающих аутентификацию источников, защиту целостности и защиту от повторного использования (anti-replay) для данных отображений EID-RLOC в LISP, передаваемых процессами поиска сопоставлений. LISP-SEC также позволяет проверять полномочность заявления EID-Prefix в сообщениях Map-Reply, гарантируя, что отправитель Map-Reply, указывающий местоположение для данного EID-Prefix, имеет право делать это в соответствии с регистрацией EID-Prefix на Map-Server. Защита Map-Register и Map-Notify, включая право элемента LISP регистрировать EID-Prefix или заявлять о его присутствии в RLOC, выходит за рамки LISP-SEC, поскольку эти протоколы защищены механизмами, заданными в [RFC9301]. Однако LISP-SEC расширяет сообщения Map-Register, позволяя входным маршрутизаторам туннелей (Ingress Tunnel Router или ITR) работать с Map-Request без LISP-SEC. Рассмотрение вопросов безопасности приведено в разделе 7.

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

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

3. Определения терминов

One-Time Key (OTK) – одноразовый ключ

Эфемерный случайно сгенерированный ключ, применяемый в одном обмене Map-Request – Map-Reply.

ITR One-Time Key (ITR-OTK) – одноразовый ключ ITR

Одноразовый ключ, созданный ITR.

MS One-Time Key (MS-OTK) – одноразовый ключ MS

Одноразовый ключ, созданный сервером отображений (Map-Server).

Authentication Data (AD) – данные аутентификации

Метаданные, включаемые в заголовок инкапсулированного управляющего сообщения LISP (Encapsulated Control Message или ECM), как указано в [RFC9301], или в сообщение Map-Reply, для поддержки защиты конфиденциальности и целостности, а также проверки полномочности EID-Prefix.

OTK Authentication Data (OTK-AD) – данные аутентификации OTK

Часть данных аутентификации в ECM, относящаяся к одноразовому ключу.

EID Authentication Data (EID-AD) – данные аутентификации EID

Часть данных аутентификации ECM и Map-Reply, применяемая для проверки полномочности EID-Prefix.

Packet Authentication Data (PKT-AD) – данные аутентификации пакета

Часть данных аутентификации Map-Reply, служащая для защиты целостности сообщения Map-Reply.

Определения других терминов, включая Map-Request, Map-Reply, Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map-Server (MS), Map-Resolver (MR), приведены в спецификации LISP [RFC9301].

4. Модель угроз LISP-SEC

LISP-SEC устраняет угрозы плоскости управления, описанные в параграфах 3.7 и 3.8 [RFC7835], которые нацелены на отображений EID-RLOC, включая манипуляции с сообщениями Map-Request и Map-Reply, а также злонамеренные перезаявления ETR EID-Prefix. LISP-SEC принимает 2 основных допущения: предполагается, что (1) LISP Mapping System доставляет сообщения Map-Request предусмотренному ETR, как указано EID, и (2) невозможна организация атак на пути внутри LISP Mapping System. Защита Mapping System от атак на пути зависит от конкретной системы отображения и выходит за рамки этого документа. Хотя LISP-SEC позволяет обнаруживать атаки с перезаявлением EID-Prefix, предполагается, что Map-Server могут проверять при регистрации полномочия для EID-Prefix.

В соответствии с моделью угроз из [RFC7835], в LISP-SEC предполагается, что атаки любого типа, включая атаки в пути, могут организовываться вне границ LISP Mapping System. Атакующий в пути за пределами LISP Mapping System может, например, перехватывать сообщения Map-Request и Map-Reply, подменяя отождествления узлов LISP. Другой тип атак в пути, называемых атаками с перезаявлением (overclaiming), может быть организован вредоносным ETR, заявляющим EID-Prefix, для которых у него нет полномочий. Это позволяет ETR перенаправить трафик.

5. Протокольные операции

Целью механизмов защиты, заданных в [RFC9301], является предотвращение несанкционированной вставки данных отображения за счёт аутентификации источника и защиты целостности для сообщений Map-Register, а также использования nonce для обнаружения незапрошенных сообщений Map-Reply от злоумышленников вне пути.

LISP-SEC базируется на механизмах защиты из [RFC9301] для предотвращения угроз, описанных в разделе 4, путём использования доверительных отношений между элементами LISP [RFC9301], участвующими в обмене сообщениями Map-Request и Map-Reply. Эти отношения доверия (см. 7. Вопросы безопасности и [RFC9301]) применяются для защищённого распространения (8.4. Функции Key Wrap для каждого сообщения одноразового ключа (OTK), обеспечивающего аутентификацию источника, защиту целостности и предотвращения повторного использования данных отображения в процессе поиска сопоставлений и это обеспечивает эффективную защиту от атак с перезаявлением (overclaiming). Обработка параметров защиты в процессе обмена сообщениями Map-Request и Map-Reply описана ниже.

• Для каждого сообщения Map-Request создаётся новый ключ ITR-OTK, который сохраняется в ITR и защищённо передаётся серверу Map-Server.

• Map-Server использует ITR-OTK для расчёта хэшированного кода аутентификации сообщения (Hashed Message Authentication Code или HMAC) [RFC2104], который защищает целостность данных отображения, известных Map-Server, в случае атак с перезаявлением. Map-Server также выводит новый ключ MS-OTK, который передаётся ETR, путём применения KDF (например, [RFC5869]) к ITR-OTK.

• ETR использует MS-OTK для расчёта HMAC, который защищает целостность Map-Reply, переданного ITR.

• ITR использует сохранённый ключ ITR-OTK для проверки целостности данных отображения, предоставленных Map-Server и ETR, и отсутствия атак с перезаявлением на пути между Map-Server и ITR.

В разделе 6 дано подробное описание управляющих сообщений LISP-SEC и их обработки, а в оставшейся части этого параграфа описан поток операций протокола LISP на каждом объекте, вовлеченном в обмен Map-Request и Map-Reply.

1. ITR при необходимости передать сообщение Map-Request генерирует и сохраняет OTK (ITR-OTK). Этот ключ ITR-OTK шифруется и включается в сообщение ECM, содержащее Map-Request для Map-Resolver.

2. Map-Resolver декапсулирует ECM, расшифровывает ITR-OTK (если нужно) и пересылает через Mapping System полученное сообщение Map-Request и ITR-OTK как часть нового ECM. LISP Mapping System доставляет ECM подходящему Map-Server, указанному EID получателя в Map-Request.

3. На Map-Server настроены локальные отображения и данные политики для ETR, отвечающего за EID получателя. Используя конфигурационные сведения, Map-Server после декапсуляции ECM находит наиболее подходящий (longest-match) EID-Prefix, включающий EID, запрошенный в принятом Map-Request. Map-Server добавляет этот EID-Prefix вместе с кодом HMAC, рассчитанным с помощью ITR-OTK в новое сообщение ECM, которое содержит полученное сообщение Map-Request.

4. Map-Server выводит новый ключ MS-OTK, применяя KDF к ITR-OTK. MS-OTK включается в сообщение ECM, которое Map-Server использует для пересылки Map-Request маршрутизатору ETR.

5. Если Map-Server работает в режиме посредника (proxy), как указано в [RFC9301], ETR не привлекается к созданию Map-Reply и пп. 6 и 7 пропускаются. В этом случае Map-Server создаёт Map-Reply от имени ETR, как описано в параграфе 6.7.2. Генерация Map-Reply посредником.

6. ETR при получении инкапсулированного в ECM сообщения Map-Request от Map-Server расшифровывает MS-OTK (если нужно) и формирует Map-Reply с данными отображения EID-RLOC, как указано в [RFC9301].

7. ETR рассчитывает HMAC для Map-Reply с ключом MS-OTK для защиты целостности всего сообщения Map-Reply, а также копирует сведения о полномочности EID-Prefix, которые Map-Server включил в инкапсулированный в ECM запрос Map-Request сообщения Map-Reply. После этого ETR передаёт сообщение Map-Reply запрашивающему ITR.

8. ITR при получении Map-Reply использует сохранённый локально ключ ITR-OTK для проверки целостности сведений о полномочности EID-Prefix из Map-Reply, включённых сервером Map-Server. Затем ITR рассчитывает MS-OTK применяя ту же функцию KDF (указана в инкапсулированном в ECM сообщении Map-Reply), которую использовал Map-Server и проверяет целостность Map-Reply.

6. Детали управляющих сообщений LISP-SEC

Метаданные LISP-SEC, связанные с Map-Request, передаются в сообщении ECM, содержащем Map-Request, а метаданные, связанные с Map-Reply, в самом сообщении Map-Reply.

Эта спецификация использует HMAC в различных местах, как описано ниже. Реализации LISP-SEC должны поддерживать функцию HMAC AUTH-HMAC-SHA-256-128 [RFC6234]. В развёртываниях LISP-SEC следует применять функцию AUTH-HMAC-SHA-256-128, за исключением случаев, когда реализация поддерживает лишь AUTH-HMAC-SHA-1-96 [RFC2104].

6.1. Расширения ECM LISP-SEC

В LISP-SEC применяются сообщения ECM, определённые в [RFC9301], с установленным (1) битом S для индикации включения в заголовок LISP данных аутентификации (Authentication Data или AD). Формат LISP-SEC ECM AD показан на рисунке 1. OTK-AD обозначает данные аутентификации одноразового ключа, а EID-AD – данные аутентификации EID.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  ECM AD Type  |   Unassigned  |        Requested HMAC ID      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\
|              OTK Length       |     Key ID    | OTK Wrap. ID  | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
|                       One-Time-Key Preamble ...               | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+OTK-AD
|                   ... One-Time-Key Preamble                   | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~                      One-Time Key (128 bits)                  ~/
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+
|           EID-AD Length       |           KDF ID              |     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |
| Record Count  |E| Unassigned  |         EID HMAC ID           |EID-AD
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\    |
|  Unassigned   | EID mask-len  |           EID-AFI             | |   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec |
~                          EID-Prefix ...                       ~ |   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/    |
~                            EID HMAC                           ~     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+

Рисунок 1. Данные аутентификации LISP-SEC ECM.

ECM AD Type

1 (LISP-SEC Authentication Data), см. раздел 8. Взаимодействие с IANA.

Unassigned

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

Requested HMAC ID

Алгоритм HMAC, который будет применяться для защиты отображений, запрошенных ITR. Разрешённые значения указаны в реестре LISP-SEC Authentication Data HMAC ID (параграф 8.3). Подробности даны в параграфе 6.4.

OTK Length

Число байтов в OTK-AD, включая OTK Preamble и OTK.

Key ID

Идентификатор распространённого заранее ключа, совместно используемого ITR и Map-Resolver, а также Map-Server и ETR. Такие ключи выводятся из заранее распространённого секрета для шифрования и защиты целостности OTK. Key ID позволяет менять распространённые заранее секреты без нарушения работы.

OTK Wrapping ID (OTK Wrap. ID)

Идентификатор функции вывода ключа (KDF) и алгоритма упаковки ключей (key wrapping), применяемых для шифрования OTK. Разрешённые значения указаны в реестре LISP-SEC Authentication Data Key Wrap ID (параграф 8.4). Подробности даны в параграфе 6.5. Шифрование и расшифровка OTK.

One-Time-Key Preamble

Устанавливается 0, если OTK не шифруется. При шифровании OTK это поле может передавать дополнительные метаданные от операции упаковки ключа. Когда 128-битовый ключ OTK передаётся без шифрования распознавателем Map-Resolver, в OTK Preamble устанавливается значение 0x0000000000000000 (64 бита). Подробности даны в параграфе 6.5.1. Нешифрованный OTK.

One-Time-Key

OTK, упакованный в соответствии с OTK Wrapping ID. См. параграф 6.5. Шифрование и расшифровка OTK.

EID-AD Length

Число байтов EID-AD. ITR должен указывать EID-AD Length = 4, поскольку он заполняет лишь поле KDF ID, не используя остальные части EID-AD. Данные EID-AD могут включать несколько EID-Record, каждая из которых занимает 4 байта плюс размер EID-Prefix с кодированием AFI.

KDF ID

Идентификатор функции вывода ключей (KDF), используемой для создания MS-OTK. Разрешённые значения указаны в реестре LISP-SEC Authentication Data Key Derivation Function ID (параграф 8.5). Подробности даны в параграфе 6.7. Обработка в Map-Server.

Record Count

В соответствии с параграфом 5.2 в [RFC9301].

E

Бит ETR-Cant-Sign, установка (1) которого указывает ITR, что хотя бы 1 из ETR, полномочных для EID-Prefix из этого Map-Reply, не включил LISP-SEC. Флаг может устанавливать только Map-Server (см. параграф 6.7).

Unassigned

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

EID HMAC ID

Идентификатор алгоритма HMAC, применяемого для защиты целостности EID-AD. Это поле устанавливает только Map-Server, рассчитывающий EID-Prefix HMAC (см. параграф 6.7.1).

EID mask-len

В соответствии с параграфом 5.2 в [RFC9301].

EID-AFI

В соответствии с параграфом 5.2 в [RFC9301].

EID-Prefix

В соответствии с параграфом 5.2 в [RFC9301].

EID HMAC

Код HMAC для EID-AD, рассчитанный и установленный Map-Server (см. параграф 6.7.1).

6.2. Расширения Map-Reply LISP-SEC

LISP-SEC использует сообщение Map-Reply, определённое в [RFC9301], с Type = 2 и установленным (1) битом S для индикации наличия в сообщении данных аутентификации (AD). Формат LISP-SEC Map-Reply AD показан на рисунке 2. PKT-AD – это данные аутентификации пакета, охватывающие содержимое Map-Reply.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  MR AD Type   |                Unassigned                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+
|           EID-AD Length       |           KDF ID              |     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     |
| Record Count  |   Unassigned  |         EID HMAC ID           |EID-AD
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\    |
|  Unassigned   | EID mask-len  |           EID-AFI             | |   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec |
~                          EID-Prefix ...                       ~ |   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/    |
~                            EID HMAC                           ~     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+
|         PKT-AD Length         |         PKT HMAC ID           |\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~                            PKT HMAC                           ~PKT-AD
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+/

Рисунок 2. Данные аутентификации LISP-SEC Map-Reply.

MR AD Type

1 (LISP-SEC Authentication Data). См. 8. Взаимодействие с IANA.

EID-AD Length

Число байтов в EID-AD (см. 6.1. Расширения ECM LISP-SEC).

KDF ID

Идентификатор функции KDF, используемой для вывода MS-OTK (см. 6.1. Расширения ECM LISP-SEC).

Record Count

Число записей в сообщении Map-Reply (см. 6.1. Расширения ECM LISP-SEC).

Unassigned

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

EID HMAC ID

Идентификатор алгоритма HMAC, применяемого для защиты целостности EID-AD (см. 6.1. Расширения ECM LISP-SEC).

EID mask-len

Размер маски для EID-Prefix (см. 6.1. Расширения ECM LISP-SEC).

EID-AFI

См. 6.1. Расширения ECM LISP-SEC.

EID-Prefix

См. 6.1. Расширения ECM LISP-SEC.

EID HMAC

См. 6.1. Расширения ECM LISP-SEC.

PKT-AD Length

Число байтов в PKT-AD.

PKT HMAC ID

Идентификатор алгоритма HMAC, применяемого для защиты целостности Map-Reply (см. 6.5. Шифрование и расшифровка OTK).

PKT HMAC

Код HMAC всего пакета Map-Reply для защиты его целостности, включая данные LISP-SEC AD (из поля Map-Reply Type в поле PKT HMAC), позволяющие аутентифицировать сообщение.

6.3. Расширения Map-Register LISP-SEC

Бит S в сообщении Map-Register (см. [RFC9301]) указывает серверу Map-Server, что регистрируемый ETR поддерживает LISP-SEC. ETR с поддержкой LISP-SEC должен устанавливать (1) флаг S в сообщениях Map-Register.

6.4. Обработка в ITR – генерация Map-Request

При создании Map-Request маршрутизатор ITR генерирует случайный ключ ITR-OTK, сохраняя его локально до получения соответствующего Map-Reply (6.9. Обработка в ITR – приём Map-Reply) вместе с nonce, создаваемым как указано в [RFC9301].

ITR может использовать поле KDF ID для указания рекомендуемого алгоритма KDF в соответствии с локальными правилами. Map-Server может переопределить KDF ID, если он не поддерживает рекомендованный ITR алгоритм (6.7. Обработка в Map-Server). Значение KDF NOPREF (0) может служить для указания отсутствия у ITR предпочтительного KDF ID.

Для пути между ITR и Map-Resolver должна обеспечиваться защита конфиденциальности и целостности с помощью ITR-OTK. Это можно реализовать путём шифрования ITR-OTK с использованием заранее распространённого секрета для ITR и Map-Resolver (6.5. Шифрование и расшифровка OTK) или включения DTLS [RFC9147] между ними.

Сообщения Map-Request (как задано в [RFC9301]) должны инкапсулироваться как управляющие сообщения LISP в ECM с установленным (1) флагом S для индикации наличия данных аутентификации (AD). Такие сообщения в этом документе называются дакже защищёнными (Protected) Map-Request.

ITR-OTK упаковывается с использованием алгоритма, указанного полем OTK Wrapping ID (шифрование OTK описано в параграфе 6.5). При выборе алгоритма NULL-KEY-WRAP-128 (8.4. Функции Key Wrap) и отсутствии иного механизма шифрования (например, DTLS) на пути между ITR и Map-Resolver, сообщение Map-Request должно отбрасываться, а в системном журнале следует оставлять соответствующую запись. Реализации могут включать механизмы предотвращения атак на истощение ресурсов системного журнала, но это выходит за рамки документа.

Поле Requested HMAC ID указывает алгоритм HMAC, предложенный для использования Map-Server и ETR с целью защиты целостности ECM AD и Map-Reply. HMAC ID со значением NONE (0) можно использовать, если у ITR нет пердпочтений для HMAC ID.

Поле KDF ID указывает функцию KDF, предложенную для использования на Map-Server при выводе MS-OTK. Можно указать KDF с идентификатором NONE (0), если у ITR нет предпочтений для KDF ID.

В поле EID-AD Length указывается значение 4, поскольку данные аутентификации (AD) не включают EID-Prefix AD и EID-AD содержит лишь поле KDF ID.

Если ITR напрямую соединён с Mapping System, такой как LISP+ALT [RFC6836], он выполняет функции ITR и Map-Resolver, пересылая защищённые Map-Request, как указано в 6.6. Обработка в Map-Resolver.

Обработка на Proxy ITR (PITRs) эквивалентна обработке на ITR, поэтому применяются описанные выше процедуры.

6.5. Шифрование и расшифровка OTK

Защита конфиденциальности и целостности MS-OTK должна обеспечиваться на пути между Map-Server и ETR. Это можно реализовать за счёт применения DTLS между Map-Server и ETR или шифрования MS-OTK с заранее распространенным секретом, известным Map-Server и ETR [RFC9301]. Точно так же должна обеспечиваться конфиденциальность и целостность ITR-OTK на пути между ITR и Map-Resolver, которая может быть достигнута такими же способами. Общий ключ ITR и Map-Resolver подобен общему ключу Map-Server и ETR.

В этом параграфе описана обработка OTK на пути ITR – Map-Resolver и Map-Server – ETR.

Важно отметить, что для предотвращения атак с перезаявлением от ETR общий ключ ITR и Map-Resolver должен быть независимым от общего ключа Map-Server и ETR.

OTK упаковывается с помощью алгоритма, указанного полем OTK Wrapping ID, которое задает:

• алгоритм Key Encryption Algorithm, применяемый для шифрования упаковываемого OTK;

• функцию вывода ключей KDF для создания ключа шифрования для каждого сообщения.

Реализации этой спецификации должны поддерживать OTK Wrapping ID AES-KEY-WRAP-128+HKDF-SHA256, задающий применение функции вывода ключей HKDF-SHA256, заданной в [RFC5869], для создания ключей шифрования каждого сообщения (per-msg-key), а также алгоритм упаковки ключей AES-KEY-WRAP-128 для шифрования 128-битовых OTK, в соответствии с [RFC3394].

Реализации этой спецификации должны поддерживать OTK Wrapping NULL- KEY-WRAP-128, применяемый для передачи нешифрованных 128-битовых OTK с преамбулой 0x0000000000000000 (64 бита).

Процесс упаковки для OTK Wrapping ID AES-KEY-WRAP-128+HKDF- SHA256 описан ниже.

1. KDF и алгоритмы упаковки ключей указываются значением поля OTK Wrapping ID. Начальные значения идентификаторов указаны в таблице 5.

2. Если выбран алгоритм NULL-KEY-WRAP-128 (8.4. Функции Key Wrap) и протокол DTLS не включён, сообщение Map-Request должно отбрасываться а в системный журнал следует вносить соответствующую запись. Разработчики могут реализовать механизмы защиты от истощения ресурсов системного журнала, но это выходит за рамки данного документа.

3. Заранее распространённый секрет, применяемый для вывода per-msg-key, представляется PSK[Key ID], указывающим распределенный заранее секрет, указанный индексом Key ID.

4. 128-битовый ключ шифрования рассчитывается, как показано ниже

   per-msg-key = KDF( nonce + s + PSK[Key ID] )

   где nonce – значение поля Nonce из Map-Request, s – строка OTK-Key-Wrap, а + указывает конкатенацию.

5. Ключ per-msg-key применяется для упаковки OTK с помощью AES-KEY-WRAP-128, как указано в параграфе 2.2.1 [RFC3394]. Для инициализации упаковки ключа AES (Key Wrap Initialization) должно использоваться значение 0xA6A6A6A6A6A6A6A6 (64 бита). Результатом упаковки ключа AES является 192-битовое значение, старшие 64 бита которого копируются в поле One-Time Key Preamble, а оставшиеся 128 младших битов – в поле One-Time Key данных аутентификации LISP-SEC AD.

При расшифровке ключа OTK получатель должен убедиться, что значение Initialization Value, полученное при расшифровке упакованного ключа AES, равно 0xA6A6A6A6A6A6A6A6. Если это не так, получатель должен отбросить сообщение целиком.

6.5.1. Нешифрованный OTK

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

При передаче 128-битового OTK без шифрования для OTK Wrapping ID устанавливается значение NULL_KEY_WRAP_128, а для OTK Preamble – 0x0000000000000000 (64 бита).

6.6. Обработка в Map-Resolver

При получении защищённого Map-Request распознаватель Map-Resolver декапсулирует ECM, расшифровывая ITR-OTK (если это нужно) в соответствии с параграфом 6.5. Шифрование и расшифровка OTK.

Защита конфиденциальности ITR-OTK и безопасность в целом после того, как Map-Request передаётся распознавателем Map-Resolver на Map-Server, зависит от применяемой Mapping System и выходит за рамки документа.

В системах отображения, где Map-Server соответствует [RFC9301], Map-Resolver создаёт новый заголовок ECM с установленным (1) битом S, который содержит нешифрованный ключ ITR-OTK, как указано в параграфе 6.5, и другие данные, полученные из ECM Authentication Data принятого инкапсулированного сообщения Map-Request.

Затем Map-Resolver пересылает серверу Map-Server полученное сообщение Map-Request, которое инкапсулируется с новым заголовком ECM, включающим недавно рассчитанные поля Authentication Data.

6.7. Обработка в Map-Server

При получении защищённого Map-Request сервер Map-Server обрабатывает его в соответствии с установкой битов S и P в Map-Register от полномочных для префикса ETR, как описано ниже.

При обработке Map-Request сервер Map-Server может переопределить поле KDF ID, если он не поддерживает функцию KDF, рекомендованную ITR. Обработка Map-Request должна выполняться в порядке, указанном в таблице 1, путём выполнения первого правила, соответствующего условиям, указанным в первом столбце.

Таблица 1. Обработка Map-Request.

Условия совпадения	Обработка
1. Хотя бы 1 ETR полномочен для EID-Prefix, включённого в Map-Request, зарегистрированный с битом P=1.	Map-Server должен генерировать защищённое LISP-SEC сообщение Map-Reply, как указано в параграфе 6.7.2. Бит ETR-Cant-Sign (E) в EID-AD должен быть сброшен (0).
2. Хотя бы 1 ETR полномочен для EID-Prefix, включённого в Map-Request, зарегистрированный с битом S=1.	Map-Server должен генерировать защищённое LISP-SEC инкапсулипрванное сообщение Map-Request (параграф 6.7.1) для передачи одному из полномочных ETR, зарегистрированных с установленным (1) битом S (и битом P=0). Если имеется хотя бы 1 ETR, зарегистрированный с S=0, флаг ETR-Cant-Sign (E) в EID-AD должен быть установлен (1) для указания ITR, что Map-Request без LISP-SEC может достичь ETR с отключённым LISP-SEC.
3. Все ETR полномочны для EID-Prefix, включённого в Map-Request, зарегистрированный с битом S=0.	Map-Server должен передать сообщение Negative Map-Reply, защищенное LISP-SEC, как описано в параграфе 6.7.2. Флаг ETR-Cant-Sign (E) должен быть установлен (1) для указания ITR, что Map-Request без LISP-SEC может достичь ETR с отключённым LISP-SEC.

Таким образом, ITR передающий Map-Request с защитой LISP-SEC всегда получает защищённые LISP-SEC отклики Map-Reply. Однако установленный (1) флаг ETR-Cant-Sign (E) указывает, что Map-Request без защиты LISP-SEC может достичь ETR, на которых нет LISP-SEC. Этот механизм позволяет ITR обрабатывать запросы без LISP-SEC, которые не защищены от угроз, указанных в разделе 4.

6.7.1. Генерация защищённых LISP-SEC сообщений Map-Request

Map-Server декапсулирует ECM и генерирует новые данные аутентификации ECM AD, включающие OTK-AD и EID-AD с сведениями о полномочиях EID-Prefix, которые в конечном итоге получены запрашивающим ITR. Map-Server обновляет OTK-AD, выводя новый ключ OTK (MS-OTK) из ITR-OTK, полученного с Map-Request. MS-OTK выводится с применением функции KDF, заданной полем KDF ID. Если указанный KDF ID алгоритм не поддерживается, Map-Server использует другой алгоритм с соответственно обновляет поле KDF ID. Сообщение Map-Request должно инкапсулироваться в ECM с установленным (1) битом S для индикации наличия данных аутентификации (AD).

MS-OTK упаковывается с помощью алгоритма, заданного полем OTK Wrapping ID (см. 6.5. Шифрование и расшифровка OTK). При использовании алгоритма NULL-KEY-WRAP-128 и отсутствии DTLS на пути между Map-Server и ETR сообщение Map-Request должно отбрасываться и это следует записывать в системный журнал.

Map-Server включает в EID-AD самый длинный из совпадающих зарегистрированных EID-Prefix для EID получателя и код HMAC для этого EID-Prefix. HMAC рассчитывается с ключом ITR-OTK из полученных ECM AD с применением алгоритма, выбранного в соответствии с полем Requested HMAC ID. Если Map-Server не поддерживает этот алгоритм, но применяет свой и указывает его в поле EID HMAC ID. При расчёте HMAC должны использоваться данные EID-AD целиком, от поля EID-AD Length до EID HMAC, которое для расчёта должно устанавливаться в 0.

Затем Map-Server пересылает инкапсулированное в ECM обновлённое сообщение Map-Request, содержащее OTK-AD, EID-AD и полученное сообщение Map-Request, полномочному ETR, как указано в [RFC9301].

6.7.2. Генерация Map-Reply посредником

Защищённое LISP-SEC сообщение Map-Reply от посредника генерируется в соответствии с [RFC9301] и имеет установленный (1) бит S. Map-Reply включает данные аутентификации AD с данными EID-AD, рассчитанными в соответствии с параграфом 6.7.1, а также данными PKT-AD, рассчитанными с соответствии с параграфом 6.8.

6.8. Обработка в ETR

При получении инкапсулированного в ECM сообщения Map-Request с установленным (1) битом S маршрутизатор ETR декапсулирует ECM. Поле OTK расшифровывается (если оно зашифровано) в соответствии с параграфом 6.5 для получения нешифрованного ключа MS-OTK. Затем ETR генерирует Map-Reply, как указано в [RFC9301] и включает в него данные аутентификации AD с EID-AD из принятого инкапсулированного Map-Request, а также PKT-AD.

Данные EID-AD копируются из Authentication Data в принятом инкапсулированном сообщении Map-Request. PKT-AD содержит код HMAC для всего пакета Map-Reply, созданный с ключом MS-OTK и алгоритмом HMAC, заданным в поле Requested HMAC ID полученного инкапсулированного Map-Request. Если ETR не поддерживает запрошенный алгоритм HMAC, он использует иной алгоритм, указывая его в поле PKT HMAC ID. Операция HMAC должна охватывать Map-Reply целиком, а для поля PKT HMAC при расчёте должно устанавливаться значение 0.

ETR передаёт сообщение Map-Reply запрашивающему ITR, как указано в [RFC9301].

6.9. Обработка в ITR – приём Map-Reply

В ответ на защищённое сообщение Map-Request маршрутизатор ITR ожидает получить Map-Reply с установленным (1) битом S, включающее EID-AD и PKT-AD. В противном случае ITR должен отбросить Map-Reply.

При получении Map-Reply маршрутизатор ITR должен проверить целостность EID-AD и PKT-AD, а при обнаружении нарушения должен отбросить Map-Reply. После обработки Map-Reply маршрутизатор ITR должен отбросить пару <nonce, ITR-OTK>, счязанную с Map-Reply.

Целостность EID-AD проверяется с применением ITR-OTK (сохранен локально на время этого обмена) для перерасчёта HMAC данных EID-AD с использованием алгоритма, заданного в поле EID HMAC ID. Если ITR указал Requested HMAC ID в своём сообщении Map-Request, а PKT HAMC ID в соответствующем Map-Reply отличается или ITR не указывал Requested HMAC ID в Map-Request, при этом PKT HMAC ID в соответствующем Map-Reply не поддерживается ITR, тот должен отбросить Map-Reply и передать (с учётом правил ограничения частоты из [RFC9301]) новое сообщение Map-Request с другим значением Requested HMAC ID в соответствии с локальной политикой ITR. Код HMAC вычисляется для всех данных EID-AD, начиная от EID-AD Length и заканчивая EID HMAC, при расчёте HMAC маршрутизатор ITR должен установить в поле EID HMAC значение 0.

Для проверки целостности PKT-AD сначала выводится MS-OTK из сохранённого локально ITR-OTK с применением алгоритма, заданного полем KDF ID. Это обусловлено тем, что при создании PKT-AD в ETR использовался ключ MS-OTK. Если ITR указал рекомендуемый KDF ID в своём Map-Request, а KDF ID из соответствующего Map-Reply отличается или ITR не указывал рекомендуемого KDF ID в своём Map-Request, тот должен отбросить Map-Reply и передать (с учётом правил ограничения частоты из [RFC9301]) новое сообщение Map-Request с другим значением KDF ID в соответствии с локальной политикой ITR. Реализации LISP-SEC должны поддерживать функцию KDF HKDF-SHA256, а развёртываниям LISP-SEC следует применять её, если в том же развёртывании нет более старой реализации, использующей HKDF-SHA1-128. Без согласования настройки вовлечённых элементов могут возникать дополнительные задержки, однако процесс сходится со временем, благодаря поддержке HKDF-SHA1-128 и HKDF-SHA256.

Затем выведенное значение MS-OTK применяется для пересчёта HMAC из PKT-AD с применением алгоритма, указанного в поле PKT HMAC ID. Если поле PKT HMAC ID не совпадает с Requested HMAC ID, ITR должен отбросить Map-Reply и передавать (с учётом правил ограничения частоты из [RFC9301]) новое сообщение Map-Request с другим значением Requested HMAC ID в соответствии с локальной политикой, пока не переберёт все поддерживаемые ITR значения HMAC ID. Несовпадение значений PKT HMAC ID и Requested HMAC ID не позволяет проверить Map-Reply.

Отдельная запись EID-Record в Map-Reply считается действительной, если (1) оба поля EID-AD и PKT-AD действительны и (2) непусто пересечение EID-Prefix в EID-Record из Map-Reply с одним из EID-Prefix из EID-AD. После идентификации действительности записи Map-Reply маршрутизатор ITR устанавливает для EID-Prefix в записи Map-Reply значение набора пересечений, рассчитанных ранее и добавляет EID-Record из Map-Reply в свой кэш EID-RLOC Map-Cache, как описано в [RFC9301]. Пример проверки записи Map-Reply представлен в параграфе 6.9.1.

[RFC9301] разрешает ETR передавать сообщения SMR (Solicit-Map-Request) напрямую ITR. Вызванное таким SMR сообщение Map-Request будет передаваться через Mapping System и поэтому будет защищено в соответствии с этой спецификацией, если она применяется. Если ITR воспринимает Map-Reply, прицепленные к Map-Request, и их содержимого ещё нет в его EID-RLOC Map-Cache, маршрутизатор должен передать Map-Request через Mapping System, чтобы проверить содержимое с помощью защищённого Map-Reply до использования.

6.9.1. Проверка записей в Map-Reply

Содержимое Map-Reply может включать записи EID-Record. Сообщение Map-Reply целиком подписано ETR с кодом HMAC PKT для защиты целостности и аутентификации источника EID-Prefix, заявляемых ETR. Поле Authentication Data в Map-Reply может включать несколько EID-Records в EID-AD. Данные EID-AD подписывает Map-Server кодом HMAC EID для защиты целостности и аутентификации источника EID-Prefix, вставленных Map-Server.

При получении Map-Reply с установленным (1) флагом S маршрутизатор ITR сначала проверяет коды HMAC для EID и PKT-AD. Несоответствии любого из HMAC следует записать в системный журнал, а Map-Reply недопустимо обрабатывать дальше. Реализации могут включать механизмы предотвращения атак с истощением ресурсов ведения журнала (это выходит за рамки документа). Если оба кода HMAC действительны, ITR выполняет проверку каждой EID-Record, заявленной ETR, путём расчёта пересечения каждого включённого EID-Prefix из Map-Reply с каждым из EID-Prefix в EID-AD. Запись EID-Record действительная лишь при непустом пересечении, в противном случае должна вноситься запись в системный журнал, а запись EID-Record должна отбрасываться. Реализации могут включать механизмы предотвращения атак с истощением ресурсов ведения журнала (выходит за рамки документа).

Например, для Map-Reply с тремя записями отображений EID-Prefix

      2001:db8:102::/48
      2001:db8:103::/48
      2001:db8:200::/40

EID-AD будет содержать 2 EID-Prefix

      2001:db8:103::/48
      2001:db8:203::/48

EID-Record с EID-Prefix 2001:db8:102::/48 не выбрана для использования ITR, поскольку она не включена ни в одну из EID-AD, подписанных Map-Server. В системный журнал должна помещаться запись об этом, а EID-Record должна быть отброшена. Реализации могут включать механизмы предотвращения атак с истощением ресурсов ведения журнала (выходит за рамки документа).

EID-Record с EID-Prefix 2001:db8:103::/48 выбрана для использования ITR, поскольку она соответствует второму EID-Prefix из EID-AD.

EID-Record с EID-Prefix 2001:db8:200::/40 не выбрана для использования ITR, поскольку она не включена ни в одну из EID-AD, подписанных Map-Server. В системный журнал должна помещаться запись об этом, а EID-Record должна быть отброшена. Реализации могут включать механизмы предотвращения атак с истощением ресурсов ведения журнала (выходит за рамки документа). В этом последнем случае ETR пытается перезаявить EID-Prefix 2001:db8:200::/40, но Map-Server разрешил только 2001:db8:203::/48; поэтому EID-Record отбрасывается.

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

Этот документ расширяет плоскость управления LISP, заданную в [RFC9301], поэтому соображения безопасности из этого документа применимы и здесь.

7.1. Безопасность системы отображения

Модель угроз LISP-SEC, описанная в разделе 4, предполагает, что система отображения LISP работает корректно и доставляет сообщения Map-Request серверу Map-Server, который полномочен для запрошенного EID.

Предполагается, что Mapping System обеспечивает конфиденциальность OTK и целостность данных Map-Reply. Однако способы защиты LISP Mapping System выходят за рамки этого документа.

Безопасность Map-Register, включая права элементов LISP регистрировать EID-Prefix или заявлять наличие RLOC также выходит за рамки LISP-SEC.

7.2. Генерация случайных значений

Ключи ITR-OTK должны генерироваться источником псевдослучайных (или строго случайных) значений с подобающей затравкой (seed). Рекомендации по созданию случайных значений представлены в [RFC4086].

7.3. Совмещение Map-Server и ETR

Если Map-Server совмещён с ETR, LISP-SEC не обеспечивает защиты от атак с перезаявлением со стороны этого ETR. Однако в этом конкретном случае, где ETR размещается в доверенной области Map-Server, атаки с перезаявлением от ETR не включены в модель угроз.

7.4. Внедрение LISP-SEC

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

Например, в некоторых других развёртываниях злоумышленники могут оказаться очень изощрёнными и это вынудит применять при внедрении очень строгие правила в части алгоритмов HMAC, воспринимаемых ITR.

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

7.5. Предоставление общих ключей

Предоставление ключей, совместно используемых парой ITR и Map-Resolver или ETR и Map-Server следует организовывать через инфраструктуру оркестровки, которая выходит за рамки этого документа. Рекомендуется периодически обновлять оба этих ключа, чтобы они не устаревали и злоумышленники не получали к ним несанкционированного доступа. Для общих ключей следует использовать непредсказуемые случайные значения.

7.6. Replay-атаки

Злоумышленники могут захватывать действительные сообщения Map-Request или Map-Reply и повторно использовать их (replay). Однако, как только ITR получает исходное сообщение Map-Reply, пара <nonce,ITR-OTK>, хранящаяся в ITR, отбрасывается. При получении воспроизводимого сообщения Map-Reply маршрутизатором ITR у него не будет пары <nonce,ITR-OTK>, соответствующей полученному Map-Reply и это сообщение будет отброшено.

При повторном использовании Map-Request элементы Map-Server, Map-Resolver и ETR должны выполнять расчёт LISP-SEC. С точки зрения ресурсов это эквивалентного легитимным расчётам LISP-SEC, поэтому кроме возможности организации DoS-атаки, злоумышленник не получает дополнительного эффекта, поскольку сообщение отбрасывается, как отмечено выше.

7.7. Приватность сообщений

Следует использовать DTLS [RFC9147] (в соответствии с [RFC7525]) для защиты приватности взаимодействий и предотвращения перехвата, изменения и подделки сообщений, передаваемых между ITR, Map-Resolver, Map-Server, ETR, если ключи OTK не шифруются иными средствами, например с использованием заранее распространённого секрета. Ответчик DTLS проверяет инициатора, что позволяет ITR проверить подлинность Map-Resolver, Map-Server – подлинность отвечающего ETR.

7.8. DoS и DDoS-атаки

LISP-SEC снижает риск атак DoS и DDoS, защищая целостность сообщений и проверяя подлинность источников Map-Request и Map-Reply, а также предотвращая перезаявление EID-Prefix вредоносными ETR, которое могло бы перенаправить трафик на большое число хостов.

8. Взаимодействие с IANA

Агентство IANA создало указанные в последующих параграфах субреестры в реестре Locator/ID Separation Protocol (LISP) Parameters. Во всех этих субреестрах новые значения выделяются по процедуре Specification Required, заданной в [RFC8126]. В рецензии экспертов (Expert Review) следует оценивать защитные свойства добавляемых функций, чтобы сохранялось строгое шифрования. Например, на момент создания этого документа применение функций на основе SHA-256 считалось достаточным для защиты. Могут потребоваться консультации со специалистами по безопасности.

8.1. Реестр типов ECM AD

Агентство IANA создало реестр LISP ECM Authentication Data Types со значениями от 0 до 255 для использования в расширениях LISP-SEC ECM (6.1. Расширения ECM LISP-SEC). Исходное содержимое реестра приведено в таблице 2.

Таблица 2. Типы LISP ECM Authentication Data.

 

Имя	Номер	Документ
Резерв	0	RFC 9303
LISP-SEC-ECM-EXT	1	RFC 9303

 

Значения 2 – 255 не выделены.

8.2. Реестр типов Map-Reply AD

Агентство IANA создало реестр LISP Map-Reply Authentication Data Types со значениями от 0 до 255 для использования в расширениях LISP-SEC Map-Reply (6.2. Расширения Map-Reply LISP-SEC). Исходное содержимое реестра приведено в таблице 3.

Таблица 3. Типы Map-Reply Authentication Data.

 

Имя	Номер	Документ
Резерв	0	RFC 9303
LISP-SEC-MR-EXT	1	RFC 9303

 

Значения 2 – 255 не выделены.

8.3. Функции HMAC

Агентство IANA создало реестр LISP-SEC Preferred Authentication Data HMAC IDs со значениями от 0 до 65535 для использования в качестве Requested HMAC ID, EID HMAC ID, PKT HMAC ID в данных аутентификации LISP-SEC AD. Исходное содержимое реестра приведено в таблице 4.

Таблица 4. Идентификаторы LISP-SEC Preferred Authentication Data HMAC.

 

Имя	Номер	Документ
NOPREF	0	RFC 9303
AUTH-HMAC-SHA-1-96	1	[RFC2104]
AUTH-HMAC-SHA-256-128	2	[RFC6234]

 

Значения 3 – 65535 не выделены.

8.4. Функции Key Wrap

Агентство IANA создало реестр LISP-SEC Authentication Data Key Wrap IDs со значениями от 0 до 65535 для использования в качестве идентификаторов алгоритма упаковки ключей OTK в LISP-SEC AD. Исходное содержимое реестра приведено в таблице 5.

Таблица 5. Идентификаторы LISP-SEC Authentication Data Key Wrap.

 

Имя	Номер	Key Wrap	KDF	Документ
Резерв	0	Нет	Нет	RFC 9303
NULL-KEY-WRAP-128	1	RFC 9303	None	RFC 9303
AES-KEY-WRAP-128+HKDF-SHA256	2	[RFC3394]	[RFC4868]	RFC 9303

 

Значения 3 – 65535 не выделены.

8.5. Функции вывода ключей

Агентство IANA создало реестр LISP-SEC Authentication Data Key Derivation Function IDs со значениями от 0 до 65535 для использования в качестве KDF ID. Исходное содержимое реестра приведено в таблице 6.

Таблица 6. Идентификаторы LISP-SEC Authentication Data Key Derivation Function.

 

Имя	Номер	Документ
NOPREF	0	RFC 9303
HKDF-SHA1-128	1	[RFC5869]
HKDF-SHA256	2	[RFC5869]

 

Значения 3 – 65535 не выделены.

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

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

[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication”, RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>.

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC3394] Schaad, J. and R. Housley, “Advanced Encryption Standard (AES) Key Wrap Algorithm”, RFC 3394, DOI 10.17487/RFC3394, September 2002, <https://www.rfc-editor.org/info/rfc3394>.

[RFC4868] Kelly, S. and S. Frankel, “Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec”, RFC 4868, DOI 10.17487/RFC4868, May 2007, <https://www.rfc-editor.org/info/rfc4868>.

[RFC5869] Krawczyk, H. and P. Eronen, “HMAC-based Extract-and-Expand Key Derivation Function (HKDF)”, RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/info/rfc5869>.

[RFC6234] Eastlake 3rd, D. and T. Hansen, “US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)”, RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/info/rfc6234>.

[RFC7525] 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, <https://www.rfc-editor.org/info/rfc7525>.

[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, “Locator/ID Separation Protocol (LISP) Threat Analysis”, RFC 7835, DOI 10.17487/RFC7835, April 2016, <https://www.rfc-editor.org/info/rfc7835>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, “The Datagram Transport Layer Security (DTLS) Protocol Version 1.3”, RFC 9147, DOI 10.17487/RFC9147, April 2022, <https://www.rfc-editor.org/info/rfc9147>.

[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos, Ed., “The Locator/ID Separation Protocol (LISP)”, RFC 9300, DOI 10.17487/RFC9300, October 2022, <https://www.rfc-editor.org/info/rfc9300>.

[RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, Ed., “Locator/ID Separation Protocol (LISP) Control Plane”, RFC 9301, DOI 10.17487/RFC9301, October 2022, <https://www.rfc-editor.org/info/rfc9301>.

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

[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, “Randomness Requirements for Security”, BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.

[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, “Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)”, RFC 6836, DOI 10.17487/RFC6836, January 2013, <https://www.rfc-editor.org/info/rfc6836>.

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

Авторы благодарны Luigi Iannone, Pere Monclus, Dave Meyer, Dino Farinacci, Brian Weis, David McGrew, Darrel Lewis, Landon Curt Noll за их полезные предложения в процессе подготовки этого документа.

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

Fabio Maino

Cisco Systems

San Jose, CA

United States of America

Email: fmaino@cisco.com

 

Vina Ermagan

Google, Inc.

1600 Amphitheatre Parkway

Mountain View, CA 94043

United States of America

Email: ermagan@gmail.com

 

Albert Cabellos

Universitat Politecnica de Catalunya

c/ Jordi Girona s/n

08034 Barcelona

Spain

Email: acabello@ac.upc.edu

 

Damien Saucez

Inria

2004 route des Lucioles – BP 93

Sophia Antipolis

France

Email: damien.saucez@inria.fr

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

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

nmalykh@protokols.ru

---

Internet Engineering Task Force (IETF)                       A. Cabellos
Request for Comments: 9299          Universitat Politecnica de Catalunya
Category: Informational                                   D. Saucez, Ed.
ISSN: 2070-1721                                                    Inria
                                                            October 2022

An Architectural Introduction to the Locator/ID Separation Protocol (LISP)

Архитектурное введение в протокол LISP

PDF

Аннотация

Этот документ описывает архитектуру протокола разделения идентификаторов и локаторов (Locator/ID Separation Protocol или LISP), упрощая понимание спецификаций LISP и обеспечивая базу для обсуждения деталей протоколов LISP. Документ служит введением, а подробные сведения приведены в спецификациях RFC 9300 и RFC 9301.

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

Документ не содержит стандарта Internet и публикуется с информациоными целями.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG². Не все документы, одобренные IESG претендуют на статус Internet Standard. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

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

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

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

Этот документ описывает архитектуру протокола разделения идентификаторов и локаторов (LISP) [RFC9300] [RFC9301], основные механизмы работы и принципы устройства. По сути, LISP основан на хорошо известной архитектурной идее освобождения от перегрузки семантики адресов IP. Как отметил Noel Chiappa [RFC4984], в настоящее время адреса IP указывают сразу топологическое местоположение точки подключения к сети и идентификацию узлов. Однако требования узлов и маршрутизации принципиально различаются. Системам маршрутизации нужна агрегируемость адресов и их топологическая значимость, а узлам требуется идентификация, независимая от конкретного местоположения [RFC4984].

LISP создаёт два раздельных пространства имён для идентификаторов конечных точек (Endpoint Identifier или EID) и локаторов маршрутизации (Routing Locator или RLOC). Оба пространства синтаксически идентичны современным адресам IPv4 и IPv6. Однако EID служат для однозначной идентификации узлов независимо от их топологического местоположения и обычно маршрутизируются внутри домена. Локаторы RLOC назначаются топологически и обычно маршрутизируются между доменами. С помощью LISP можно логически разделить границу Internet (места подключения узлов) и ядро (где происходит междоменная маршрутизация). Маршрутизаторы с поддержкой LISP соединяют эти логические пространства. LISP поддерживает базу данных, называемую системой сопоставления (Mapping System), для хранения и извлечения сведений о сопоставлении отождествлений и местоположений. Маршрутизаторы с поддержкой LISP обмениваются пакетами через ядро Internet, инкапсулируя их в нужное место.

• Локаторы RLOC имеют смысл лишь в базовой (underlay) сети, т. е. в ядре маршрутизации.

• EID имеют смысл лишь в наложенной сети, которая является связующей инкапсуляцией между маршрутизаторами с поддержкой LISP.

• На границе LISP идентификаторы EID сопоставляются с RLOC.

• В базовой сети RLOC служат сразу локаторами и идентификаторами.

• EID внутри сайта LISP служат идентификаторами и локаторами для других узлов этого сайта.

• EID внутри сайта LISP передаёт идентификатор и ограниченную семантику локатора узлам других сайтов LISP (т. е. достаточно локатора, чтобы понять, что EID является внешним для сайта).

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

Исходную мотивацию разработки LISP можно найти в проблеме расширяемости маршрутизации [RFC4984], где при полном развёртывании LISP ядро Internet будет заполнено RLOC, а механизмы организации трафика (Traffic Engineering или TE) будут вынесены в систему сопоставления. В таком варианте локаторы RLOC будут квазистатическими (т. е. меняющимися редко), что делает систему маршрутизации расширяемой [Quoitin], а EID могут перемещаться свободно, «не создавая пены» в базовой системе глобальной маршрутизации. В [RFC7215] рассмотрено влияние LISP на систему глобальной маршрутизации в процессе перехода. Однако разделение местоположения и идентификации, предлагаемое LISP, подходит и для применения в других случаях, таких как TE, многодомные подключения и мобильность узлов.

В этом документе описана архитектура и основные механизмы работы LISP, а также принципы разработки. Важно отметить, что документ не задаёт и не дополняет LISP. Заинтересованным читателям следует обратиться к спецификациям LISP ([RFC9300] и [RFC9301]), а также дополнительным документам ([RFC6831], [RFC6832], [RFC9302], [RFC6835], [RFC6836], [RFC7052]) для спецификации протокола и рекомендаций по развёртыванию LISP [RFC7215].

2. Определения терминов

Endpoint Identifier (EID) – идентификатор конечной точки

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

Routing Locator (RLOC) – локатор маршрутизации

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

Ingress Tunnel Router (ITR) – входной маршрутизатор туннеля

Поддерживающий LISP маршрутизатор, инкапсулирующий пакеты от сайта LISP в направлении ядра сети.

Egress Tunnel Router (ETR) – выходной маршрутизатор туннеля

Поддерживающий LISP маршрутизатор, декапсулирующий пакеты из ядра сети в направлении сайта LISP.

xTR

Машрутизатор, реализующий функции ITR и ETR.

Map-Request

Сигнальное сообщение LISP, служащее для запроса отображения EID на RLOC.

Map-Reply

Сигнальное сообщение LISP, служащее ответом на Map-Request и содержащее нужное отображение EID на RLOC.

Map-Register

Сигнальное сообщение LISP, служащее для регистрации отображения EID на RLOC.

Map-Notify

Сигнальное сообщение LISP, передаваемое в ответ на Map-Register для подтверждения корректного получения отображения EID на RLOC.

Этот документ описывает архитектуру LISP и не вносит новых терминов. Определения используемых терминов даны в [RFC9300], [RFC9301], [RFC6831], [RFC6832], [RFC9302], [RFC6835], [RFC6836], [RFC7052], [RFC7215].

3. Архитектура LISP

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

3.1. Принципы устройства протокола

Архитектура LISP основана на 4 базовых принципах.

Разделение локаторов и идентификаторов

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

Наложение

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

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

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

Возможность поэтапного развёртывания

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

3.2. Обзор архитектуры

LISP архитектурно отделяет ядро от периметра Internet, создавая два пространства имён – EID и RLOC. Периметр образуют сайты LISP (например, автономные системы – AS), использующие адреса EID. Идентификаторы EID – это адреса IPv4 или IPv6, однозначно указывающие конечные хосты, которые назначаются и настраиваются с использованием механизмов, существовавших на момент разработки протокола. В EID не включаются междоменные топологические данные и поэтому EID обычно маршрутизируются на периферии (внутри сайта LISP), но не в ядре. Взаимодействие сайтов LISP с сайтами и доменами без поддержки LISP в сети Internet описано в параграфе 3.5. Механизмы межсетевого взаимодействия.

Сайты LISP (на периметре) подключаются к межсетевому ядру Internet через поддерживающие LISP маршрутизаторы (например, граничные маршрутизаторы). Сайты LISP соединяются через межсетевое ядро Internet с использованием туннелей между поддерживающими LISP маршрутизаторами. Когда пакет от сайта LISP направлен в сеть ядра, он попадает в инкапсулированный туннель через входной маршрутизатор ITR. Пакеты из ядра сети на сайт LISP выходят из инкапсулированного туннеля через выходной маршрутизатор ETR. XTR – это маршрутизатор, выполняющий функции ITR и ETR. В этом контексте ITR инкапсулируют пакеты, а ETR декапсулируют их, следовательно LISP работает как наложение на имеющееся ядро Internet.

                       /-----------------\                 ---
                       |     Система     |                  |
                       .  сопоставления  |                  |Плоскость
                      -|                 |`,                |управления
                    ,' \-----------------/  .               |
                   /                         |             ---
   ,..,           -        _,....,,          |      ,..,    |
 /     `        ,'      ,-`        `',       |    /     `   |
/        \ +-----+   ,'              `,  +-----+ /        \ |
| Простр.|-| xTR |--/   Пространство  ,--| xTR |-| Простр.| |Плоскость
|  EID   |-|     |--|       RLOC      |--|     |-|  EID   | |данных
\        / +-----+  .                 /  +-----+ \        / |
 `.    .'            `.              ,'           `.    .'  |
   `'-`                `.,        ,.'               `'-`   ---
                          ``'''``
  Сайт LISP (периметр)      Core         Сайт LISP (периметр)

Рисунок 1. Схема архитектуры LISP.

При использовании LISP ядро работает с локаторами RLOC. Локатор RLOC – это адрес IPv4 или IPv6, назначенный интерфейсу маршрутизатора ITR или ETR в сторону ядра.

База данных (обычно распределенная), которую называют системой сопоставления (Mapping System), содержит сопоставления между EID и RLOC. Такие сопоставления связывают идентификаторы устройств, подключённых к сайту LISP (EID), с набором RLOC, настроенных на поддерживающих LISP маршрутизаторах, обслуживающих сайт. Кроме того, сопоставления включают правила TE и могут быть настроены на поддержку многодомности и распределения нагрузки. Система сопоставления LISP концептуально похожа на DNS и организована как распределенная по сети база данных множества организаций. В LISP маршрутизаторы ETR регистрируют сопоставления, а ITR извлекают их.

В архитектуре LISP уделено особое внимание поэтапному развёртыванию. С учётом того, что LISP представляет наложение на текущую архитектуру Internet, конечные хосты, а также внутридоменные и междоменные маршрутизаторы не требуют изменений. В существующей инфраструктуре требуется изменять лишь маршрутизаторы, соединяющие между собой пространства EID и RLOC. Кроме того, LISP требует развёртывания независимой системы сопоставления, такая распределенная база данных является новым элементом сети.

Ниже (Рисунок 2) представлена упрощённая последовательность потока пакетов между парой узлов, подключённых к сайтам LISP. Отметим, что типичные маршрутизаторы с поддержкой LISP – это xTR (ITR и ETR). Клиент HostA на рисунке передаёт пакет серверу HostB.

                         /----------------\
                         |     Система    |
                         |  сопоставления |
                        .|                |-
                       ` \----------------/ `.
                     ,`                       \
                    /                          `.
                  ,'         _,..-..,,           ',
                 /         -`         `-,          \
               .'        ,'              \          `,
               `        '                 \           '
           +-----+     |                   | RLOC_B1+-----+
    HostA  |     |    |    Пространство     |-------|     |  HostB
    EID_A--|ITR_A|----|        RLOC         |       |ETR_B|--EID_B
           |     | RLOC_A1                  |-------|     |
           +-----+     |                   | RLOC_B2+-----+
                        ,                 /
                         \               /
                          `',         ,-`
                             ``''-''``

Рисунок 2. Последовательность потока пакетов в LISP.

1. HostA извлекает EID_B для HostB, обычно запрашивая DNS и получая запись A или AAAA. Затем он создаёт пакет IP как в Internet. Пакет имеет адрес отправителя EID_A и адрес получателя EID_B.

2. Пакет пересылается в ITR_A сайта LISP с использованием стандартных внутридоменных механизмов.

3. ITR_A при получении пакета запрашивает систему сопоставления для получения локатора ETR_B, обслуживающего EID_B сервера HostB. Для этого служит управляющее сообщение LISP, называемое Map-Request. Сообщение содержит EID_B в качестве ключа поиска. В ответ ITR_A получает другое управляющее сообщение LISP – Map-Reply. Это сообщение содержит два локатора RLOC_B1 и RLOC_B2, а также правила TE – приоритет и вес для каждого локатора. Отметим, что при необходимости Map-Reply может включать большее число локаторов. ITR_A может кэшировать сопоставления в локальном хранилище для ускорения пересылки последующих пакетов.

4. ITR_A инкапсулирует пакет в сторону RLOC_B1 (выбирается в соответствии с приоритетом и весом в сопоставлении). Пакет имеет два заголовка IP. Внешний заголовок указывает RLOC_A1 как источник и RLOC_B1 – как получателя. Во внутреннем исходном заголовке пакета указан адрес источника EID_A и получателя EID_B. Затем ITR_A добавляет заголовок LISP. Более подробно процесс описан в параграфе 3.3.1. Инкапсуляция LISP.

5. Инкапсулированный пакет пересылается через межсетевое ядро как обычный пакет IP, оставляя EID невидимым для ядра.

6. При получении инкапсулированного пакета маршрутизатор ETR_B декапсулирует его и пересылает в HostB.

3.3. Плоскость данных

В этом параграфе приведено высокоуровневое описание плоскости данных LISP, детально заданной в [RFC9300]. Плоскость данных LISP отвечает за инкапсуляцию и декапсуляцию пакетов данных и кэширование соответствующего состояния пересылки. Основными элементами плоскости данных являются маршрутизаторы ITR и ETR. Оба типа маршрутизаторов поддерживают LISP и соединяют EID с пространством RLOC (ITR) и наоборот (ETR).

3.3.1. Инкапсуляция LISP

Маршрутизаторы ITR инкапсулируют пакеты данных в направлении ETR. Пакеты данных LISP инкапсулируются с использованием UDP (порт 4341). Порт отправителя ITR обычно выбирает с использованием хэш-значения квинтета (5-tuple) из внутреннего заголовка (для согласованности при спользовании нескольких путей, как в ECMP [RFC2992]) и игнорируется при получении. Пакеты данных LISP часто инкапсулируются в пакеты UDP с нулевой контрольной суммой [RFC6935] [RFC6936], которую нельзя проверить при получении, поскольку внутри пакета LISP имеется транспортный заголовок с проверяемой контрольной суммой. Использование нулевой контрольной суммы UDP при передаче по протоколу IPv6 для всех протоколов туннелирования, подобных LISP, регулируется заявлением о применимости из [RFC6936]. Если пакеты данных LISP инкапсулируются в пакеты UDP с ненулевой контрольной суммой, внешняя контрольная сумма проверяется при получении пакетов UDP как при обычной обработке UDP.

Пакеты с инкапсуляцией LISP включают также заголовок LISP (между внешним заголовком UDP и исходным заголовком IP). Заголовок LISP устанавливают маршрутизаторы ITR и вырезают ETR. Заголовок содержит сведения о достижимости (4.2. Достижимость RLOC) и поле Instance ID, служащее для разделения трафика разных арендаторов на сайте LISP, что позволяет применять на сайтах перекрывающуюся, но логически разделенную адресацию EID.

В результате LISP работает с 4 заголовками – внутренним заголовком от источника и 3 заголовками, которые LISP добавляет перед ним (от внешнего к внутреннему), как указано ниже.

1. Внешний заголовок IP с RLOC в качестве адресов отправителя и получателя. Этот заголовок создаёт маршрутизатор ITR и вырезает маршрутизатор ETR.

2. Заголовок UDP (порт 4341), обычно с нулевой контрольной суммой, создаваемый ITR и вырезаемый ETR.

3. Заголовок LISP со свойствами плоскости пересылки (такими как доступность) и полем Instance ID. Этот заголовок создаёт маршрутизатор ITR и вырезает маршрутизатор ETR.

4. Внутренний заголовок IP с EID в качестве адресов отправителя и получателя. Этот заголовок создаёт хост-источник и он сохраняется неизменным при обработке в плоскости данных LISP на ITR и ETR.

В некоторых случаях полезна повторная инкапсуляция и/или рекурсивные туннели для выбора конкретного пути через базовую сеть, например, для предотвращения перегрузки или отказа. Туннелирование с повторной инкапсуляцией является последовательным применением туннелей LISP и выполняется при удалении декапсулятором (ETR) заголовка LISP и новой инкапсуляции (ITR) с добавлением другого заголовка. Рекурсивные туннели являются вложенными и реализуются с использованием для пакета неоднократной инкапсуляции LISP. Такие функции реализуются маршрутизаторами с реинкапсуляцией туннелей (Re-encapsulating Tunnel Router или RTR). Маршрутизатор RTR можно считать выступающим сначала в роли ETR для декапсуляции пакетов, затем – в роли ITR с инкапсуляцией пакетов для другого локатора (см. [RFC9300] и [RFC9301]).

3.3.2. Состояние пересылки LISP

В архитектуре LISP маршрутизаторы ITR сохраняют лишь сведения, достаточные для маршрутизации проходящего через них трафика. Иными словами, ITR нужно лишь извлечь из системы сопоставления LISP отображения EID-Prefix (блок EID) на RLOC, применяемые для инкапсуляции пакетов. Такие сопоставления хранятся в локальном кэше, называемом LISP Map-Cache, для последующих пакетов, направляемых в тот же EID-Prefix. Отметим, что в случае перекрытия EID-Prefix маршрутизатор ITR может получить по запросу набор сопоставлений из запрошенного EID-Prefix и более конкретных EID-Prefix (см. параграф 5.5 в [RFC9301]). Отображения включают значения TTL, устанавливаемые ETR. Дополнительные сведения об управлении Map-Cache приведены в параграфе 4.1. Поддержка кэша.

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

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

3.4.1. Сопоставления LISP

Каждое отображение включает привязки EID-Prefix к набору RLOC, а также правила TE в виде приоритета и веса для RLOC. Приоритет позволяет ETR настроить активную и резервную политику, а вес служит для распределения нагрузки (трафика) между RLOC (по потокам).

Типичное сопоставление в LISP связывает EID в форме префиксов IP с набором RLOC тоде в форме адресов IP. Адреса IPv4 и IPv6 кодируюся с использованием подходящего идентификатора семейства адресов (Address Family Identifier или AFI) [RFC8060]. Однако LISP может поддерживать более общее кодирование адресов на канонического формату LISP (LISP Canonical Address Format или LCAF) [RFC8060]. С помощью такого обобщённого синтаксиса кодирования адресов LISP стремится обеспечить гибкость имеющихся и будущих приложений. Например, LCAF позволяет поддерживать адреса MAC (Media Access Control), географические координаты, имена ASCII и задаваемые приложением данные.

3.4.2. Интерфейс системы сопоставления

LISP задаёт стандартный интерфейс между плоскостями данных и управления в [RFC9301], включающий 2 сущности.

Map-Server – сервер сопоставлений

Компонент сетевой инфраструктуры, изучающий отображения через маршрутизаторы ETR и публикующий их в системе сопоставления LISP Mapping System. Обычно Map-Server не уполномочен отвечать на запросы, поэтому он пересылает их ETR. Однако сервер может работать в режиме посредника (proxy-mode), когда ETR делегирует ему право отвечать на запросы. Это полезно при ограниченности ресурсов ETR (например, CPU или питания).

Map-Resolver – распознаватель сопоставлений

Компонент сетевой инфраструктуры, соединяющий маршрутизатор ITR с системой сопоставления путём посредничества (proxying) для запросов, а иногда и откликов.

Интерфейс определяет 4 управляющих сообщения LISP, передаваемых в дейтаграммах UDP (порт 4342).

Map-Register

Эти сообщения применяются маршрутизаторами ETR для регистрации отображений в системе сопоставления и аутентифицируются с использованием общего для ETR и Map-Server ключа.

Map-Notify

По запросу ETR это сообщение передаёт Map-Server в ответ на сообщение Map-Register для подтверждения корректного получения отображения и передачи последнего состояния Map-Server для отображения EID на RLOC. В некоторых случаях Map-Notify может передаваться для прежних RLOC, если для EID зарегистрирован новый набор RLOC.

Map-Request

Это сообщение применяется маршрутизаторами ITR или распознавателями Map-Resolver для получения сопоставления данного EID.

Map-Reply

Это сообщение передаёт Map-Server или ETR в ответ на Map-Request, указывая найденное сопоставление. Следует отметить, что Map-Reply может содержать негативный отклик, если, например, запрошенный идентификатор EID не входит в пространство LISP EID. В таких случаях ITR обычно пересылает трафик как есть (без инкапсуляции) в сеть Internet. Это определено для поддержки поэтапного развёртывания LISP.

3.4.3. Система сопоставления

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

При выборе архитектуры системы сопоставления было рассмтрено множество механизмов создания распределенных систем – базы данных на основе графов в форме альтернативной логической топологии LISP (LISP Alternative Logical Topology или LISP-ALT) [RFC6836], иерархические базы данных в форме дерева делегированных баз данных LISP (LISP Delegated Database Tree или LISP-DDT) [RFC8111], монолитные базы данных в форме LISP Not-so-novel EID-to-RLOC Database (LISP-NERD) [RFC6837], плоские базы данных в форме распределенной хэш-таблицы LISP (LISP Distributed Hash Table или LISP-DHT) [LISP-SHDHT] [Mathy], и основанные на групповой передаче базы данных [LISP-EMACS]. Следует отметить, что в некоторых вариантах, таких как приватное развёртывание, система сопоставления может быть логически централизованной и обычно будет включать один Map-Server/Map-Resolver.

В последующих параграфах более подробно рассмотрены две из упомянутых систем сопоставления (LISP-ALT и LISP-DDT), которые были реализованы и развёрнуты.

3.4.3.1. LISP-ALT

LISP-ALT [RFC6836] была первой системой сопоставления, которая бала предложена, разработана и развёрнута в пилотной сети LISP. Она основана на распределенном наложении BGP с участием Map-Server и Map-Resolver. Узлы соединялись с партнёрами через статические туннели. Каждый вовлечённый Map-Server в топологии ALT анонсировал EID-Prefix, зарегистрированные обслуживаемыми ETR, что делало EID маршрутизируемыми в топологии ALT.

Когда маршрутизатору ITR нужно отображение, он передаёт Map-Request распознавателю Map-Resolver, который, используя топологию ALT, пересылает Map-Request в направлении Map-Server, отвечающего за сопоставление. При получении запроса Map-Server пересылает его маршрутизатору ETR, который отвечает напрямую ITR.

3.4.3.2. LISP-DDT

LISP-DDT [RFC8111] концептуально похожа на DNS – иерархический каталог, внутренняя структура которого отражает иерархическую природу адресного пространства EID. Иерархия DDT включает узлы DDT, формирующие дерево, листьями которого служат Map-Server. Наверху структууры размещается корень DDT, являющийся экземпляром узла DDT, соответствующим всему пространству адресов. Как и DNS, система DDT поддерживает множество избыточных узлов DDT и/или корней DDT. Распознаватели Map-Resolver являются клиентами иерархии DDT и могут обращаться к корню и другим узлам DDT.

                        /---------\
                        |         |
                        | DDT Root|
                        |   /0    |
                      ,.\---------/-,
                  ,-'`       |       `'.,
               -'`           |           `-
           /-------\     /-------\    /-------\
           |  DDT  |     |  DDT  |    |  DDT  |
           | Node  |     | Node  |    | Node  |  ...
           |  0/8  |     |  1/8  |    |  2/8  |
           \-------/     \-------/    \-------/
         _.                _.            . -..,,,_
       -`                -`              \        ````''--
+------------+     +------------+   +------------+ +------------+
| Map-Server |     | Map-Server |   | Map-Server | | Map-Server |
| EID-Prefix1|     | EID-Prefix2|   | EID-Prefix3| | EID-Prefix4|
+------------+     +------------+   +------------+ +------------+

Рисунок 3. Схематическое представление дерева DDT.

Префиксы и структура на рисунке 3 представлены лишь для иллюстрации.

Структура DDT на деле не индексирует EID-Prefix, индексируя взамен расширенные префиксы (Extended EID-Prefix или XEID-Prefix), которые являются просто конкатенацией нескольких полей (от старшего бита к младшему): Database-ID, Instance ID, Address Family Identifier и фактических EID-Prefix. Database-ID указывается для возможных в будущем требований повышения уровня иерархии и возможности создания нескольких отдельных деревьев баз данных.

При ответах на запрос LISP-DDT работает подобно DNS, но поддерживает лишь интерактивный поиск. Клиенты DDT (обычно Map-Resolver) создают запросы Map-Request к корневому узлу DDT, получая в ответ новое управляющее сообщение LISP – Map-Referral. Это сообщение содержит список RLOC набора узлов DDT, соответствующих настроенному делегированию XEID. Т. е. сведения в Map-Referral указывают потомка запрашиваемого узла DDT, у которого есть более конкретные сведения об интересующем префиксе XEID-Prefix. Этот процесс повторяется, пока клиент DDT не пройдёт структуру дерева (вниз) и не найдет Map-Server, обслуживающий искомый XEID. В этот момент клиент передаёт Map-Request и получает Map-Reply с сопоставлениями. Важно подчеркнуть, что клиенты DDT могут кэшировать сведения из Map-Referral, т. е. структуру DDT, чтобы сократить время извлечения сопоставлений [Jakab].

Система сопоставления DDT основана на ручной настройке, т. е. на Map-Resolver настраивается набор доступных корневых узлов DDT, а на узлах DDT – соответствующее делегирование XEID. Изменение настроек на узлах DDT требуется лишь при смене структуры дерева и настройки не зависят от динамики EID (выделения RLOC или смены правил TE).

3.5. Механизмы межсетевого взаимодействия

EID обычно идентичны адресам IPv4 или IPv6 и хранятся в системе сопоставления LISP. Однако они обычно не анонсируются в систему маршрутизации за пределами локального домена LISP. Поэтому для LISP нужен механизм межсетевого взаимодействия, позволяющий сайтам LISP взаимодействовать с сайтами, не понимающими LISP (и наоборот). Механизмы межсетевого взаимодействия LISP заданы в [RFC6832].

В LISP заданы две сущности для обеспечения межсетевого взаимодействия.

Proxy Ingress Tunnel Router (PITR) – маршрутизатор-посредник входного туннеля

PITR обеспечивают связность унаследованной сети Internet с сайтами LISP. PITR анонсируют в систему глобальной маршрутизации блоки EID-Prefix (с агрегированием при возможности) для привлечения трафика. Для каждого входящего пакета из источника вне сайта LISP (не EID) PITR использует инкапсуляцию LISP в направлении RLOC подходящего сайта LISP. Влияние PITR на размер таблицы маршрутизации зоны без принятого по умолчанию маршрута (Default-Free Zone или DFZ) в худшем случае похоже на ситуацию без применения LISP. EID-Prefix будут по возможности агрегироваться как PITR, так и системой глобальной маршрутизации.

Proxy Egress Tunnel Router (PETR) – маршрутизатор-посредник выходного туннеля

PETR обеспечивает связность сайта LISP с традиционной сетью Internet. В некоторых случаях сайты LISP не могут передавать инкапсулированные пакеты с локальным адресом EID в качестве источника в традиционную сеть Internet, например, когда краевой маршрутизатор провайдера (Provider Edge или PE) использует индивидуальную пересылку по обратному пути (Unicast Reverse Path Forwarding или uRPF) или промежуточная сеть между сайтом LISP и не понимающим LISP сайтом не поддерживает нужную версию IP (IPv4 или IPv6). В обоих PETR преодолевает такие ограничения за счёт инкапсуляции пакетов. Не существует конкретных правил распространения адресов PETR RLOC маршрутизаторам ITR.

Кроме того, LISP определяет механизмы для работы с приватными EID [RFC1918] через LISP-NAT [RFC6832]. В этом случае xTR заменяет приватное значение EID источника на маршрутизируемое. На момент написания документа продолжалась работа по прохождению через NAT, т. е. размещения xTRs за NAT с использованием немаршрутизируемых RLOC.

PITR, PETR, и LISP-NAT позволяют развёртывать LISP поэтапно, обеспечивая достаточную гибкость размещения временных между частями сети с поддержкой и без поддержки LISP и упрощая перенос этих границ со временем.

4. Механизмы работы LISP

В этом разделе описаны основные рабочие механизмы, определённые в LISP.

4.1. Поддержка кэша

Разделение плоскостей управления и данных в LISP с хранением сопоставлений в плоскости данных и использовании их для пересылки в плоскости управления требует локального кэширования в ITR для снижения сигнальных издержек (Map-Request/Map-Reply) и повышения скорости пересылки. Локальный кэш в ITR называют Map-Cache и применяют для пакетов с инкапсуляцией LISP. Map-Cache индексируется по парам (Instance ID, EID-Prefix) и содержит в основном набор RLOC со связанными правилами TE (приоритет и вес).

Для Map-Cache, как и иных случаев кэширования, нужны механизмы обеспечения когерентности, чтобы сведения оставались актуальными. LISP задает 3 основных механизма поддержки когерентности кэша.

Record Time To Live (TTL) – срок действия записи

Каждая запись сопоставления имеет поле TTL, задаваемое маршрутизатором ETR. По истечении TTL запись не может применяться ITR, пока не будет обновлена отправкой нового Map-Request.

Solicit-Map-Request (SMR) – запрос Map-Request

SMR служит явным механизмом обновеления данных сопоставления. В частности, можно передать специальный тип Map-Request по требованию ETR для запроса обновления сопоставлений. При получении сообщения SMR маршрутизатор ITR должен обновить привязки передавая Map-Request системе сопоставления. Использование SMR описано в [RFC9301].

Map-Versioning – версия сопоставления

Этот необязательный механизм добавляет в конец заголовка LISP пакетов данных номер версии отображения, используемой маршрутизатором xTR. При получении xTR пакета с инкапсуляцией LISP от удалённого xTR, можно узнать, не устарела ли локальная или удалённая версия Map-Cache. Если локальная версия устарела маршрутизатор передает Map-Request для удалённого EID, чтобы получить новое сопоставление. Если же обнаружно устаревание Map-Cache на удалённом xTR, маршрутизатор передаёт SMR для уведомления того о доступности нового сопоставления. Подробное описание процесса приведено в [RFC9302].

В некоторых случаях запись Map-Cache можно обновить заранее с помощью описанных ниже механизмов.

4.2. Достижимость RLOC

В большинстве случаев LISP работает с системой отображения на основе вытягивания (pull), например, DDT. Это обеспечивает сквозную архитектуру вытягивания и состояние сети храниться в плоскости управления, а плоскость данных извлекает его по запросу. Это влияет на распространение сведений о достижимости и живучести xTR, поскольку архитектура вытягивания требует явных механизмов распространения таких данных. Поэтому в LISP задан набор механизмов для информирования ITR и PITR о доступности кэшированных RLOC.

Locator-Status-Bits (LSBs) – биты состояния локатора

Метод LSBs является пассивным. Поле LSB передаётся в заголовках LISP пакетов данных и может устанавливаться маршрутизаторами ETR для указания активных и неактивных (up/down) RLOC сайта ETR. Эти сведения могут служить маршрутизаторам ITR подсказкой о доступности для выполнения дополнительной проверки. LSB не указывают статус доступности пути, а лишь дают подсказки о состоянии RLOC. Поэтому они не должны применяться в общедоступной сети Internet и следует связывать их с Map-Versioning для предотвращения «гонки», где LSB считаются относящимися не к тем RLOC, с которыми они связаны.

Echo-Nonce

Это пассивный метод, который может эффективно работать лишь при двухсторонних потоках данных между двумя взаимодействующими xTR. По сути, ITR добавляет в конце заголовка LISP пакетов данных случайное значение (nonce). Если путь и зондируемый локатор активны, ETR будет добавлять это же случайное значение в следующий пакет данных. Если этого не происходит, ITR может счесть локатор недоступным. При одностороннем трафике или несовпадении принимающего трафик ETR с передающим трафик назад маршрутизатором ITR нужны дополнительные механизмы. Механизм Echo-Nonce должен применяться лишь в доверенных средах, а не в общедоступной сети Internet.

RLOC-Probing – зондирование RLOC

Имеется механизм активного зондирования, когда ITR передают пробные пакеты конкретным локаторам. Это позволяет проверить как локатор, так и путь к нему. В частности, это делается путём отправки Map-Request (с некоторыми флагами) в плоскости данных (пространство RLOC) и ожидания Map-Reply, передаваемого также в плоскости данных. Активная природа RLOC-Probing обеспечивает эффективный механизм определения доступности и (в случае отказа) переключения на другой локатор. Кроме того, механизм обеспечивает полезную оценку RTT для задержек на пути, которую могут использовать другие сетевые алгоритмы.

Следует отметить, что RLOC-Probing и Echo-Nonce могут работать вместе. В частности, если nonce не возвращается, ITR не может определить на каком из направлений возник отказ. В этом случае ITR может использовать RLOC-Probing.

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

Сигналы ICMP

Базовая среда LISP – инфраструктура Internet – использует ICMP для сигналов о недоступности (среди прочего). LISP может использовать это и считать получение сообщений ICMP Network Unreachable или ICMP Host Unreachable подсказкой о возможной недоступности локатора, вызывающей дополнительную проверку.

Базовая маршрутизация

Протоколы BGP и IGP несут сведения о доступности. Маршрутизаторы с поддержкой LISP, имеющие доступ к данным базовой маршрутизации, могут использовать их для проверки доступности локатора.

4.3. Синхронизация ETR

Все ETR, полномочные для конкретного EID-Prefix, должны анонсировать запрашивающим одно и то же сопоставление. Это значит, что ETR должны знать о статусе RLOC в других ETR. Это называют синхронизацией ETR.

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

4.4. Обработка MTU

Поскольку LISP инкапсулирует пакеты, протоколу приходится иметь дело с превышением размера пакетов над MTU для пути между ITR и ETR. LISP определяет два механизма.

Без учёта состояния

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

С учётом состояния

ITR отслеживают значения MTU на путях к целевым локаторам на основании пакетов ICMP Too Big от промежуточных маршрутизаторов. Маршрутизаторы ITR передают сообщения ICMP Too Big для информирования отправителей об эффективном значении MTU. Кроме того, ITR могут применять механизмы определения MTU для пути (Path MTU Discovery или PMTUD) [RFC1191] или определение MTU на уровне пакетизавции (Packetization Layer Path MTU Discovery или PLPMTUD) [RFC4821] для отслеживания MTU в направлении локаторов.

В обоих случаях при невозможности фрагментировать пакеты (IPv4 с DF=1 или IPv6) ITR отбрасывает пакет и передаёт его отправителю сообщение ICMP Too Big.

5. Мобильность

Разделение локаторов и идентификаторов в LISP подходит для целей TE, где сайты LISP могут менять свои точки присоединения к Internet (т. е. RLOC) не затрацивая конечные точки и ядро Internet. В этом контексте граничные маршрутизаторы используют функциональность xTR, а конечные точки не знают о наличии LISP. Это похоже на Network Mobility [RFC3963], однако данный режим работы не обеспечивает «бесшовной» мобильности конечных точек между разными сайтами LISP, поскольку адрес EID может не маршрутизироваться в посещенном сайте. Тем не менее, LISP можно использовать для бесшовной мобильности IP, когда LISP реализован непосредственно на конечной точке или та перемещается к подключённому xTR. Тогда каждая конечная точка является xTR, а адрес EID – это один из предоставленных сетевому стеку, используемому приложениями, тогда как RLOC берётся из посещенной сети. Это похоже на функциональность Mobile IP ([RFC5944] и [RFC6275]).

При смене устройством своего локатора RLOC маршрутизатор xTR обновляет RLOC в своём локальном сопставлении и регистрирует его на своём Map-Server, обычно с малым значением TTL (1 минута). Чтобы избежать потребности в домашнем шлюзе, ITR также указывает смену RLOC всем удаленным устройствам, имеющим текущую связь с перемещенным устройством Сочетание обоих методов обеспечивает расширяемость системы, поскольку сигнализация строго ограничена Map-Server и хостами, с которыми имеется связь. В случае перемещения EID-Prefix может быть достаточно мелким, вплоть до /32 или /128 (IPv4 и IPv6, соответственно), в зависимости от конкретного применения (например, перенос подсети или одной виртуальной машиы или мобильного узла).

Разделение идентификатора и локатора, обеспечиваемое LISP, позволяет работать с другими решениями для мобильности L2 и L3.

6. Групповая передача

LISP поддерживает доставку групповых пакетов IP, переданных из пространства EID. Требуемые изменения протоколов групповой доставки указаны в [RFC6831].

LISP может создавать состояния групповой рассылки (для приёма и передачи) как в ядре, так и на сайтах. При использовании сигнализации для создания групповой рассылки на сайтах маршрутизаторы LISP инкапсулируют сообщения PIM Join/Prune от получателя к сайтам источников как индивидуальные пакеты. В ядре маршрутизаторы ETR создают новое сообщение PIM Join/Prune, адресованное RLOC маршрутизатора ITR, обслуживающего источник. Упрощённая последовательность приведена ниже.

1. Конечный хост, желающий присоединиться к групповому каналу передаёт отчёт IGMP. Групповые маршрутизаторы PIM на сайте LISP распространяют сообщения PIM Join/Prune (S-EID, G) в направлении ETR.

2. Сообщение Join поступает в ETR и маршрутизатор ETR создаёт два сообщения Join. Первое является индивидуальным пакетом с инкапсуляцией LISP для исходного сообщения Join в направлении RLOC обслуживающешл источник маршрутизатора ITR. Это сообщение создаёт групповое состояние (S-EID, G) на сайте источника. Второе сообщение Join содержит в качестве адреса получателя RLOC маршрутизатора ITR, обслуживающего источник (S-RLOC, G) и создаёт состояние групповой рассылки в ядре.

3. Групповые пакеты данных, созданные источником (S-EID, G) передаются от него к ITR. Маршрутизатор ITR инкапсулирует групповые пакеты в LISP. Внешний заголовок включает его RLOC (S-RLOC) как отправителя и исходный адрес multicast-группы (G) как получателя. Отметим, что групповые адреса являются логическими и не распознаются системой сопоставления. Затем групповые пакеты передаются через ядро в направлении принимающих ETR, которые декапсулируют пакеты и пересылают их по групповому состоянию на сайте.

Отметим, что внутренние и внешние групповые адреса обычно различаются за исключением особых случаев, когда базовый провайдер жёстко контролирует наложение. Спецификации LISP уже поддерживают все режимы PIM modes [RFC6831]. Кроме того, LISP может поддерживать другие механизмы сохранения групповых состояний.

Когда групповые источники и получатели имеются на сайтах LISP, а ядро сети между сайтами не обеспечивает поддержки групповой передачи, можно применять бессигнальный механизм для создания наложения, которое позволит передавать групповой трафик между сайтами и соединить деревья групповой рассылки на разных сайтах [RFC8378]. Регистрации с разных сайтов-получателей будут слиты в системе сопоставления для сборки списка групповой репликации, включающего все RLOC, ведущие к получателям для конкретной группы или группового канала. Список репликации для каждой конкретной групповой записи поддерживается как запись системы сопоставления LISP.

7. Варианты применения

7.1. Организация трафика

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

Отображение связывает список RLOC с EID-Prefix. Каждый локатор RLOC соответствует интерфейсу ETR (или набора ETR), способному корректно переслать трафик по EID из префикса. Для каждого RLOC в отображении указывается приоритет и вес. Приоритет служит для выбора предпочтительных для передачи пакетов RLOC (менее предпочтительные предоставляются для резервирования), а вес позволяет распределять нагрузку между RLOC с одинаковым приоритетом пропорционально заданному значению веса.

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

7.2. LISP для сосуществования с IPv6

Инкапсуляция LISP позволяет доставлять пакеты, использующие EID из данного пространства адресов (например, IPv6) в пакетах другого семейства адресов (например, IPv4). Отсутствие привязки между семействами адресов RLOC и EID делает LISP подходящим кандидатом, позволяющим, например, развернуть IPv6 через ядро без поддержки IPv6.

Например, два ЦОД, поддерживающие лишь IPv6 можно соединить через традиционную сеть IPv4 (Internet). Если граничные маршрутизаторы поддерживают LISP, передача пакетов между ЦОД выполняется без какой-либо трансляции, поскольку исходные пакеты IPv6 (в пространстве EID) LISP будет инкапсулировать и передавать в пакетах IPv4 традиционной сети Internet через IPv4 RLOC.

7.3. LISP для VPN

Обычно в одной физической инфраструктуре работает несколько виртуальных сетей. В таких ситуациях определение принадлежности пакета к виртуальной сети становится важной задачей и для этого часто применяются теги или метки. При использовании LISP пакеты можно различать по полю Instance ID. Когда ITR инкапсулирует пакет из определённой виртуальной сети (например, известной по VRF³ или VLAN), он помечает инкапсулированный пакет значением Instance ID, соответствующим виртуальной сети. Когда ETR получает пакет с Instance ID, он использует это поле для определения принадлежности пакета.

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

7.4. LISP для мобильности VM в ЦОД

Способ обеспечения бесшовной можильности виртуальных машин (VM) в ЦОД состоит в представлении опорной сети ЦОД как пространства RLOC, а подсетей с серверами, как пространство EID. Маршрутизаторы LISP помещаются на границе между магистралью и каждой подсетью серверов. При перемещении VM в другую подсеть она может (временно) сохранить прежний адрес для продолжения работы без сброса транспортных соединений. Когда xTR обнаруживает адрес источника из другой подсети, он регистрирует адрес в системе сопоставления. Для информирования других маршрутизаторов LISP о переносек виртуальной машины и её новом местоположении, чтобы избежать обходных путей через исходную подсеть, применяются такие механизмы, как сообщения Solicit-Map-Request.

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

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

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

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

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

Сопоставления являются центральным элементом LISP и должны приниматься все меры предосторожности для предотвращения вредоносных манипуляций или использования их злоумышленниками. Использование доверенных серверов Map-Server, строго соответствующих [RFC9301], и механизмов аутентификации, предоставляемых LISP-SEC [RFC9303], снижает риск атак на целостность сопоставлений. В более критических средах могут потребоваться меры защиты. Реализация защиты для данной системы сопоставления сильно зависит от архитектуры этой системы и модели угроз, предполагаемой для развёртывания. Поэтому безопасность системы сопоставления должна рассматриваться в соответствующих документах по архитектуре Mapping System.

Как и в других механизмах туннелирования промежуточные устройства на пути между ITR (или PITR) и ETR (или PETR) должны иметь механизмы снятия инкапсуляции для корректной проверки содержимого пакетов с инкапсуляцией LISP.

Как и другие механизчы инкапсуляции и сопоставления (map-and-encap), LISP разрешает «трехстороннюю» маршрутизацию (т. е. поток пакетов проходит через разные граничные маршрутизаторы в зависимости от направления). Это означает, что у промежуточных устройств может не быть полного представления о трафике, который они инспектируют или обрабатывают. Кроме того, пакеты с инкапсуляцией LISP маршрутизируются по внешним адресам IP (RLOC) и могут быть доставлены маршрутизатору ETR, который не отвечает за EID получателя пакета, или сетевому элементу, не являющемуся ETR. Снижение риска обеспечивается применением подходящих методов фильтрации, на элементах сети, которые могут получать неожиданные пакеты с инкапсуляцией LISP.

Дополнительные сведения о влиянии LISP на безопасность приведены в [RFC7835].

9. Взаимодействие с IANA

Этот документ не требует действий IANA.

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

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

[RFC1191] Mogul, J. and S. Deering, “Path MTU discovery”, RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>.

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, “Address Allocation for Private Internets”, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <https://www.rfc-editor.org/info/rfc1918>.

[RFC2992] Hopps, C., “Analysis of an Equal-Cost Multi-Path Algorithm”, RFC 2992, DOI 10.17487/RFC2992, November 2000, <https://www.rfc-editor.org/info/rfc2992>.

[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, “Network Mobility (NEMO) Basic Support Protocol”, RFC 3963, DOI 10.17487/RFC3963, January 2005, <https://www.rfc-editor.org/info/rfc3963>.

[RFC4821] Mathis, M. and J. Heffner, “Packetization Layer Path MTU Discovery”, RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.

[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., “Report from the IAB Workshop on Routing and Addressing”, RFC 4984, DOI 10.17487/RFC4984, September 2007, <https://www.rfc-editor.org/info/rfc4984>.

[RFC5944] Perkins, C., Ed., “IP Mobility Support for IPv4, Revised”, RFC 5944, DOI 10.17487/RFC5944, November 2010, <https://www.rfc-editor.org/info/rfc5944>.

[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, “Mobility Support in IPv6”, RFC 6275, DOI 10.17487/RFC6275, July 2011, <https://www.rfc-editor.org/info/rfc6275>.

[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, “The Locator/ID Separation Protocol (LISP) for Multicast Environments”, RFC 6831, DOI 10.17487/RFC6831, January 2013, <https://www.rfc-editor.org/info/rfc6831>.

[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, “Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites”, RFC 6832, DOI 10.17487/RFC6832, January 2013, <https://www.rfc-editor.org/info/rfc6832>.

[RFC6835] Farinacci, D. and D. Meyer, “The Locator/ID Separation Protocol Internet Groper (LIG)”, RFC 6835, DOI 10.17487/RFC6835, January 2013, <https://www.rfc-editor.org/info/rfc6835>.

[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, “Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)”, RFC 6836, DOI 10.17487/RFC6836, January 2013, <https://www.rfc-editor.org/info/rfc6836>.

[RFC6837] Lear, E., “NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database”, RFC 6837, DOI 10.17487/RFC6837, January 2013, <https://www.rfc-editor.org/info/rfc6837>.

[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, “IPv6 and UDP Checksums for Tunneled Packets”, RFC 6935, DOI 10.17487/RFC6935, April 2013, <https://www.rfc-editor.org/info/rfc6935>.

[RFC6936] Fairhurst, G. and M. Westerlund, “Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums”, RFC 6936, DOI 10.17487/RFC6936, April 2013, <https://www.rfc-editor.org/info/rfc6936>.

[RFC7052] Schudel, G., Jain, A., and V. Moreno, “Locator/ID Separation Protocol (LISP) MIB”, RFC 7052, DOI 10.17487/RFC7052, October 2013, <https://www.rfc-editor.org/info/rfc7052>.

[RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-Pascual, J., and D. Lewis, “Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations”, RFC 7215, DOI 10.17487/RFC7215, April 2014, <https://www.rfc-editor.org/info/rfc7215>.

[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, “Locator/ID Separation Protocol (LISP) Threat Analysis”, RFC 7835, DOI 10.17487/RFC7835, April 2016, <https://www.rfc-editor.org/info/rfc7835>.

[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, “LISP Canonical Address Format (LCAF)”, RFC 8060, DOI 10.17487/RFC8060, February 2017, <https://www.rfc-editor.org/info/rfc8060>.

[RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Smirnov, “Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)”, RFC 8111, DOI 10.17487/RFC8111, May 2017, <https://www.rfc-editor.org/info/rfc8111>.

[RFC8378] Moreno, V. and D. Farinacci, “Signal-Free Locator/ID Separation Protocol (LISP) Multicast”, RFC 8378, DOI 10.17487/RFC8378, May 2018, <https://www.rfc-editor.org/info/rfc8378>.

[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos, Ed., “The Locator/ID Separation Protocol (LISP)”, RFC 9300, DOI 10.17487/RFC9300, October 2022, <https://www.rfc-editor.org/info/rfc9300>.

[RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, Ed., “Locator/ID Separation Protocol (LISP) Control Plane”, RFC 9301, DOI 10.17487/RFC9301, October 2022, <https://www.rfc-editor.org/info/rfc9301>.

[RFC9302] Iannone, L., Saucez, D., and O. Bonaventure, “Locator/ID Separation Protocol (LISP) Map-Versioning”, RFC 9302, DOI 10.17487/RFC9302, October 2022, <https://www.rfc-editor.org/info/rfc9302>.

[RFC9303] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, “Locator/ID Separation Protocol Security (LISP-SEC)”, RFC 9303, DOI 10.17487/RFC9303, October 2022, <https://www.rfc-editor.org/info/rfc9303>.

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

[Jakab] Jakab, L., Cabellos-Aparicio, A., Coras, F., Saucez, D., and O. Bonaventure, “LISP-TREE: A DNS Hierarchy to Support the LISP Mapping System”, IEEE Journal on Selected Areas in Communications, vol. 28, no. 8, pp. 1332-1343, DOI 10.1109/JSAC.2010.101011, October 2010, <https://ieeexplore.ieee.org/document/5586446>.

[LISP-EMACS] Brim, S., Farinacci, D., Meyer, D., and J. Curran, “EID Mappings Multicast Across Cooperating Systems for LISP”, Work in Progress, Internet-Draft, draft-curran-lisp-emacs-00, 9 November 2007, <https://www.ietf.org/archive/id/draft-curran-lisp-emacs-00.txt>.

[LISP-SHDHT] Cheng, L. and M. Sun, “LISP Single-Hop DHT Mapping Overlay”, Work in Progress, Internet-Draft, draft-cheng-lisp-shdht-04, 15 July 2013, <https://www.ietf.org/archive/id/draft-cheng-lisp-shdht-04.txt>.

[Mathy] Mathy, L. and L. Iannone, “LISP-DHT: Towards a DHT to map identifiers onto locators”, CoNEXT ’08: Proceedings of the 2008 ACM CoNEXT Conference, ReArch ’08 — Re-Architecting the Internet, DOI 10.1145/1544012.1544073, December 2008, <https://dl.acm.org/doi/10.1145/1544012.1544073>.

[Quoitin] Quoitin, B., Iannone, L., de Launois, C., and O. Bonaventure, “Evaluating the Benefits of the Locator/Identifier Separation”, Proceedings of 2nd ACM/IEEE International Workshop on Mobility in the Evolving Internet Architecture, DOI 10.1145/1366919.1366926, August 2007, <https://dl.acm.org/doi/10.1145/1366919.1366926>.

Приложение A. История разделения идентификаторов и локаторов

Архитектура LISP для разделения местоположения и отождествления стала результатом дискуссий во время семинара IAB Routing and Addressing в Амстердаме в октябре 2006 г. [RFC4984].

Сразу после семинара спонтанно сформировалась небольшая группа единомышленников для работы над идеей, возникшей в неформальных дискуссиях на семинаре в различных почтовых конференциях. Первый документ Internet-Draft для LISP появился в январе 2007 г.

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

Протокол LISP перешёл из сферы IRTF в рабочую группу IETF в марте 2009 г. После многочисленных исправления базовые спецификации в начале 2013 г. были выпущены как RFC. Работа по расширению, совершенствованию и поиску новых применений продолжается (и несомненно будет длиться ещё долго). Рабочая группа LISP была в 2018 г. преобразована для продолжения работы над базовым протоколом LISP и создания документов Standards Track.

A.1. Старые модели LISP

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

LISP 1

Все EID появляются в обычных таблицах маршрутизации и пересылки в сети (т. е. являются «маршрутизируемыми»). Это свойство применяется для получения сопоставлений EID с RLOC в процессе начальной загрузки (bootstrapping). Пакеты передаются с EID в качестве адресата во внешнем заголовке и когда ETR видит такой пакет, он передаёт Map-Reply маршрутизатору ITR источника, давая полное сопоставление.

LISP 1.5

LISP 1.5 похож на LISP 1, но маршрутизация EID происходит в отдельной сети.

LISP 2

EID не маршрутизируются, сопоставления EID с RLOC доступны через DNS.

LISP 3

EID не маршрутизируются и их нужно искать в новой базе данных о сопоставлениях EID с RLOC (изачально это была система, использующая распределенные хэш-таблицы). Были возможны два варианта – push-системы, где все отображения распространялись всем ITR, и pull-системы, в которых ITR загружали сопоставления при необходимости.

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

Этот документ инициировал Noel Chiappa и большая часть идей представлена им. Авторы признательны за его важный вклад в работу и благодарны ему.

Спасибо также Dino Farinacci, Fabio Maino, Luigi Iannone, Sharon Barkai, Isidoros Kouvelas, Christian Cassar, Florin Coras, Marc Binderberger, Alberto Rodriguez-Natal, Ronald Bonica, Chad Hintz, Robert Raszuk, Joel M. Halpern, Darrel Lewis, David Black.

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

Albert Cabellos

Universitat Politecnica de Catalunya

c/ Jordi Girona s/n

08034 Barcelona

Spain

Email: acabello@ac.upc.edu

 

Damien Saucez (editor)

Inria

2004 route des Lucioles – BP 93

Sophia Antipolis

France

Email: damien.saucez@inria.fr

 

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

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

nmalykh@protokols.ru

---

Internet Engineering Task Force (IETF)                      D. Farinacci
Request for Comments: 9301                                   lispers.net
Obsoletes: 6830, 6833                                           F. Maino
Category: Standards Track                                  Cisco Systems
ISSN: 2070-1721                                                V. Fuller
                                             vaf.net Internet Consulting
                                                        A. Cabellos, Ed.
                                    Universitat Politecnica de Catalunya
                                                            October 2022

Locator/ID Separation Protocol (LISP) Control Plane

Плоскость управления протокола разделения идентификаторов и локаторов (LISP)

PDF

Аннотация

Этот документ описывает плоскость управления и службу сопоставления (Mapping Service) для протокола разделения идентификаторов и локаторов (Locator/ID Separation Protocol или LISP), реализованные двумя типами использующих LISP устройств – распознавателями LISP Map-Resolver и серверами LISP Map-Server, – которые обеспечивают упрощённый интерфейс (front end) для одного или нескольких идентификаторов конечных точек (Endpoint ID или EID) в базу сопоставления с локаторами маршрутизации (Routing Locator или RLOC).

Используя этот интерфейс службы плоскости управления и взаимодействуя с распознавателями Map-Resolver и серверами Map-Server, входные (LISP Ingress Tunnel Router или ITR) и выходные (Egress Tunnel Router или ETR) маршрутизаторы туннелей независимы от деталей базы данных системы сопоставления, что способствует модульности с разными вариантами баз данных. Поскольку эти устройства реализуются на «периметре» (edge) инфраструктуры плоскости управления LISP, соединяя узлы с адресами EID на сайте LISP, снижается сложность и стоимость реализации и эксплуатации развёртывания LISP.

Этот документ отменяет RFC 6830 и RFC 6833.

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

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG². Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

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

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

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

Протокол разделения локаторов и идентификаторов (Locator/ID Separation Protocol или LISP) [RFC9300] (см. также [RFC9299]) задаёт архитектуру и механизм для динамического туннелирования путём разделения адресов IP на два пространства имён – идентификаторы конечных точек (Endpoint ID или EID), используемые внутри сайтов, и локаторы маршрутизации (Routing Locator или RLOC), используемые в транзитных сетях, образующих инфраструктуру Internet. Для такого разделения LISP задаёт протокольные механизмы сопоставления EID с RLOC. Кроме того, в LISP предполагается наличие базы данных, хранящей и распространяющей такие отображения между узлами системы отображения (Mapping System). Предложено несколько таких баз, включая наложенную службу распространения содержимого (Content distribution Overlay Network Service) для LISP-NERD (старее, чем EID-to-RLOC Database) [RFC6837], дополнительную логическую топологию LISP (LISP Alternative Logical Topology или LISP-ALT) [RFC6836] и дерево делегированной базы данных LISP (LISP Delegated Database Tree или LISP-DDT) [RFC8111].

LISP Mapping Service определяет два типа понимающих LISP узлов – Map-Resolver, который воспринимает Map-Request от входных маршрутизаторов туннелей (Ingress Tunnel Router или ITR) и преобразует сопоставления EID-RLOC с помощью базы данных, и Map-Server, который узнаёт полномочные отображения EID-RLOC у выходных маршрутизаторов туннелей (Egress Tunnel Router или ETR) и публикует их в базе данных.

Плоскость управления LISP и службу сопоставления можно применять с множеством плоскостей данных на основе инкапсуляции или трансляции, включая заданные в LISP [RFC9300], расширении базового протокола LISP (LISP Generic Protocol Extension или LISP-GPE) [RFC9305], виртуальных расширяемых ЛВС (Virtual eXtensible Local Area Network или VXLAN) [RFC7348], VXLAN-GPE [NVO3-VXLAN-GPE], GRE³ [RFC2890], протоколе туннелирования GPRS (GPRS Tunneling Protocol или GTP) [GTP-3GPP], адресации ILA (Identifier-Locator Addressing) [INTAREA-ILA] и маршрутизации по сегментам (Segment Routing или SRv6) [RFC8402].

Концептуально серверы отображения LISP Map-Server имеют некоторые базовые свойства настройки и поддержки серверов системы доменных имён (Domain Name System или DNS) [RFC1035], а распознаватели Map-Resolver похожи на кэширующие распознаватели DNS. С учётом этого в данной спецификации применяются термины (распознаватель и сервер) из спецификаций DNS.

Отметим, что этот документ не предполагает какую-либо инфраструктуру баз отображения для иллюстрации некоторых аспектов операций Map-Server и Map-Resolver. Интерфейс службы отображения может и, скорей всего, будет) применяться ITR и ETR для доступа к другим системам баз данных по мере развития инфраструктуры LISP.

Протоколы LISP не предназначены для решения задач связности и расширяемости от имени произвольных взаимодействующих сторон. Соответствующие ситуации описаны в параграфе 1.1 [RFC9300].

Этот документ отменяет [RFC6830] и [RFC6833].

1.1. Сфера применимости

Изначально протокол LISP создавался для решения проблемы расширения маршрутизации в сети Internet [RFC4984]. Хотя имеется ряд подходов к решению этой задачи, по мере разработки и совершенствования LISP было найдено и реализовано много других применений LISP. В результате устройство и разработка LISP изменились с нацеленностью на эти варианты применения. Общим свойством таких вариантов является большой набор кооперирующихся объектов, стремящихся взаимодействовать через Internet или иную крупную инфраструктуру IP, сохраняя адресацию и топологию сотрудничающих элементов отдельно от топологии, маршрутизации и адресации базовой сети и Internet.

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

1. Должна быть реализована защита LISP (LISP Security или LISP-SEC) [RFC9303]. Это значит, что бит S должен быть установлен в сообщениях Map-Reply (параграф 5.4), Map-Register (параграф 5.6), Encapsulated Control (ECM) (параграф 5.8).

2. Разработчикам следует использовать HMAC-SHA256-128+HKDF-SHA256 как Algorithm ID (параграф 12.5) в сообщениях Map-Register (параграф 5.6) и недопустимо использовать None или HMAC-SHA-1-96-None как Algorithm ID (параграф 12.5) в сообщениях Map-Register (параграф 5.6).

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

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

3. Определения терминов

Map-Server – сервер отображений (сопоставлений)

Элемент инфраструктуры сети, изучающий записи отображений EID-Prefix от ETR через описанный ниже механизм регистрации или ото какого-либо иного полномочного источника, если он имеется. Map-Server публикует эти EID-Prefix в базе данных отображений.

Map-Request – запрос отображения

Сообщение плоскости управления, запрашивающее у системы отображения распознавание EID. LISP Map-Request может передаваться также по адресу RLOC для проверки доступности или обмена ключами защиты между инкапсулятором и декапсулятором. Этот тип Map-Request называют также RLOC-Probe Request.

Map-Reply – отклик с отображением

Сообщение плоскости управления, возвращаемое в ответ на сообщение Map-Request, переданное в Mapping System при распознавании EID. LISP Map-Reply может также возвращаться декапсулятором в ответ на Map-Request от инкапсулятора для проверки доступности. Этот тип Map-Reply называют также RLOC-Probe Reply.

Encapsulated Map-Request – инкапсулированный запрос отображения

Запрос LISP Map-Request, передаваемый с инкапсуляцией LISP (ECM). Этот Map-Request имеет в начале дополнительный заголовок LISP и передаётся в порт UDP 4342. Внешним адресом является маршрутизируемый адрес, называемый также RLOC. Применяется ITR при отправке Map-Resolver и сервером Map-Server при пересылке Map-Request в ETR.

Map-Resolver – распознаватель отображений

Элемент инфраструктуры сети, воспринимающий инкапсулированные в LISP (ECM) сообщения Map-Request (обычно от ITR) и определяющий, является ли IP-адрес получателя частью пространства EID. Если это не так, возвращается Negative Map-Reply, в ином случае Map-Resolver находит подходящее отображение EID-RLOC, запрашивая базу данных отображений.

Negative Map-Reply – негативный отклик для отображения

LISP Map-Reply с пустым набором Locator-Set, возвращаемый в ответ на Map-Request, если EID получателя не зарегистрирован в Mapping System, запрещён правилами или не прошла аутентификация.

Map-Register message – сообщение Map-Register

Сообщение LISP, передаваемое ETR серверу Map-Server для регистрации связанных с маршрутизатором EID-Prefix. В дополнение к отправке EID-Prefix для регистрации сообщение включает 1 или несколько RLOC, обеспечивающих доступ к ETR. Map-Server использует эти RLOC при пересылке Map-Request (переформатированных как Encapsulated Map-Request). ETR может запросить, чтобы Map-Server отвечал на Map-Request от своего имени, установив в сообщении флаг proxy Map-Reply (P).

Map-Notify message – сообщение Map-Notify

Сообщение LISP, передаваемое Map-Server маршрутизатору ETR для подтверждения приёма и обработки Map-Register. ETR запрашивает возврат Map-Notify установкой флага want-map-notify (M-bit) в сообщении Map-Register. В отличие от Map-Reply, сообщение Map-Notify использует порт UDP 4342 для источника и получателя. Сообщения Map-Notify передаются также маршрутизаторам ITR от Map-Server при изменении RLOC-Set.

Определения других терминов, в частности Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Re-encapsulating Tunnel Router (RTR), приведены в спецификации плоскости данных LISP [RFC9300].

4. Базовый обзор

Map-Server – это устройство, публикующее EID-Prefix в базе отображений LISP от имени набора ETR. При получении Map-Request (обычно от ITR) сервер обращается к базе данных для поиска ETR и может получить в ответ набор RLOC для EID-Prefix. Для публикации EID-Prefix маршрутизатор ETR переиодически отправляет сообщения Map-Register серверу Map-Server. Сообщение Map-Register содержит список EID-Prefix и набор RLOC, которые можно использовать для доступа к ETR.

При использовании LISP-ALT [RFC6836] в качестве базы данных отображений Map-Server соединяется с сетью ALT и действует как последний маршрутизатор (last-hop) ALT-Router. Промежуточные ALT-Router пересылают Map-Request серверу Map-Server, который анонсирует конкретный EID-Prefix, а тот пересылает их владеющему ETR, который отвечает сообщениями Map-Reply.

При использовании базы отображения LISP-DDT [RFC8111] Map-Server передаёт финальные сообщения Map-Referral от дерева делегированной базы данных (Delegated Database Tree или DDT).

Map-Resolver получает инкапсулированные Map-Request от своих ITR-клиентов и использует базу отображений в поиске подходящего ETR для ответа на эти запросы. В сети LISP-ALT Map-Resolver выступает как первый маршрутизатор (first-hop) ALT-Router. Он имеет туннели GRE к другим ALT-Router и использует BGP для изучения путей к ETR с разными префиксами в базе данных LISP-ALT. Map-Resolver использует сведения о путях для пересылки Map-Request через ALT корректным ETR. В сети LISP-DDT [RFC8111] Map-Resolver поддерживает кэш ссылок и выступает первым (first-hop) узлом DDT. Map-Resolver использует ссылочные данные для пересылки Map-Request.

Хотя Map-Resolver может кэшировать отклики для повышения производительности, нужно решать проблемы, связанные с управлением кэшем, чтобы это было надёжно и практично. В этой спецификации Map-Resolver работают без кэширования, декапсулируя и пересылая инкапсулированные Map-Request, полученные от ITR. Спецификация функций кэширования выходит за рамки этого документиа.

Отметим, что одно устройство может совмещать функции Map-Server и Map-Resolver и это будет применяться во многих случаях. При использовании LISP-ALT и LISP-DDT могут быть узлы, поддерживающие только ALT или только DDT, соответственно, соединяющие Map-Resolver и Map-Server для создания системы отображения Mapping System.

5. Форматы пакетов плоскости управления LISP IPv4 и IPv6

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

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Version|  IHL  |Type of Service|          Total Length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Identification        |Flags|      Fragment Offset    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Time to Live | Protocol = 17 |         Header Checksum       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Source Routing Locator                     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Destination Routing Locator                   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  / |           Source Port         |         Dest Port             |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  \ |           UDP Length          |        UDP Checksum           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                         LISP Message                          |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 1. Управляющее сообщение IPv4 UDP LISP.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |Version| Traffic Class |           Flow Label                  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Payload Length        | Next Header=17|   Hop Limit   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                     Source Routing Locator                    +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                  Destination Routing Locator                  +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  / |           Source Port         |         Dest Port             |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  \ |           UDP Length          |        UDP Checksum           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                         LISP Message                          |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 2. Управляющее сообщение IPv6 UDP LISP.

При отправке UDP Map-Request, Map-Register, Map-Notify (в качестве уведомления) порт источника UDP выбирается отправителем, а для порта получателя устанавливается значение 4342. При передаче UDP Map-Reply, Map-Notify (как подтверждения Map-Register), Map-Notify-Ack устанавливается порт отправителя UDP 4342, а номер порта получателя копируется из поля порта отправителя в Map-Request или вызвавшем сообщение пакете данных. реализации должны быть готовы воспринимать пакеты, в которых указан порт отправителя или получателя UDP 4342 в результате смены номера порта системой NAT.

Поле UDP Length отражает размер заголовка UDP и содержимого сообщения LISP. Предполагается, что LISP будет применяться сотрудничающими организациями, взаимодействующими через базовые сети. При внедрении предполагается установка MTU в соответствии с конкретными рекомендациями по развёртыванию для предотвращения фрагментации внутренних пакетов или внешних инкапсулированных пакетов. Для внедрений, где ограничения базовых сетей в части MTU на пути неизвестны, размер сообщения должен ограничиваться 576 байтами для IPv4 и 1280 – для IPv6 с учётом всего пакета IP, как описано в [RFC8085].

Контрольная сумма UDP рассчитывается и устанавливается (не 0) для всех сообщений, передаваемых в порт 4342 или из него. Это должно проверяться при получении и управляющие сообщения с ошибкой контрольной суммы должны отбрасываться [RFC1071].

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

5.1. Типы пакетов управления LISP

В этом параграфе описаны форматы управляющих сообщений LISP и дана сводка назначенных документом кодов LISP Type для IANA. Для полноты в сводку включено сообщение LISP Shared Extension, заданное в [RFC9304]. Определения типов сообщений перечислены в таблице 1.

Таблица 1.

 

Сообщение	Код	Двоичный код
Резерв	0	b’0000′
LISP Map-Request	1	b’0001′
LISP Map-Reply	2	b’0010′
LISP Map-Register	3	b’0011′
LISP Map-Notify	4	b’0100′
LISP Map-Notify-Ack	5	b’0101′
LISP DDT Map-Referral	6	b’0110′
Unassigned	7	b’0111′
LISP Encapsulated Control	8	b’1000′
Не выделены	9-14	b’1001′- b’1110′
LISP Shared Extension	15	b’1111′

 

Разработчикам протколв, экспериментирующим с новыми форматами сообщений, рекомендуется применять тип LISP Shared Extension, описанный в [RFC9304].

Сообщения плоскости управления LISP используют идентификаторы семейств адресов (Address Family Identifier или AFI) [AFN] или канонический формат адресов LISP (LISP Canonical Address Format или LCAF) [RFC8060] для представления адресов с фиксированным или переменным размером. Это включает явные поля в каждом управляющем сообщении или части EID-Record или RLOC-Record в сообщениях с базовым форматом. Сообщения плоскости управления LISP с нераспознанным AFI должны отбрасываться и в системных журнал должна вноситься запись об этом.

Плоскость управления LISP описывает, как другие плоскости данных могут кодировать сообщения для поддержки запросов Map-Request, а также процедур RLOC-Probing.

5.2. Формат сообщения Map-Request

        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=1 |A|M|P|S|p|s|R|R|  Rsvd   |L|D|   IRC   | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Source-EID-AFI        |   Source EID Address  ...     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         ITR-RLOC-AFI 1        |    ITR-RLOC Address 1  ...    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                              ...                              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         ITR-RLOC-AFI n        |    ITR-RLOC Address n  ...    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |   Reserved    | EID mask-len  |        EID-Prefix-AFI         |
   Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                       EID-Prefix  ...                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Map-Reply Record  ...                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

1 (Map-Request)

A

Бит полномочий (authoritative) устанавливаемый (1), когда ITR хочет, чтобы Map-Reply возвращал сайт получателя, а не база данных. В ином случае бит сбрасывается (0).

M

Бит map-data-present, установка (1) которого показывает, что в Map-Request включён сегмент Map-Reply Record.

P

Бит зондирования (probe-bit ), указывающий, что сообщение Map-Request должно считаться зондом доступности локатора. Получатель должен отвечать сообщением Map-Reply с установленным (1) битом probe-bit, указывающим, что Map-Reply является откликом на зонд доступности локатора, и копией nonce из Map-Request (см. параграф 7.1. Алгоритм зондирования RLOC). Такое сообщение RLOC-Probe Map-Request недопустимо передавать в Mapping System. Если Map-Resolver или Map-Server получает Map-Request с установленным битом probe-bit, он должен отбросить сообщение.

S

Флаг сообщения Solicit-Map-Request (SMR), см. параграф 6.1. Solicit-Map-Request (SMR).

p

Бит Proxy Ingress Tunnel Router (PITR), устанавливаемый (1) при передаче маршрутизатором PITR сообщения Map-Request. Использование этого бита зависит от развёртывания.

s

Бит вызова SMR, устанавливаемый (1) xTR при передаче Map-Request в ответ на Map-Request на основе SMR.

R

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

Rsvd

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

L

Бит local-xtr, используемый xTR на сайте LISP для указания другим xTR того же сайта, что он является частью RLOC-Set для сайта LISP. Бит L устанавливается (1), когда RLOC является IP-адресом отправителя.

D

Бит dont-map-reply, используемый в процедуре SMR, описанной в параграфе 6.1. Когда xTR передаёт сообщение SMR, ему не требуется возврат Map-Reply. При установленном (1) бите получатель Map-Request не передаёт Map-Reply.

IRC

Это 5-битовое поле служит счётчиком ITR-RLOC Count, который указывает число дополнительных полей (ITR-RLOC-AFI, ITR-RLOC Address) в данном сообщении. Должна кодироваться хотя бы 1 пара (ITR-RLOC-AFI, ITR-RLOC Address). Применяется несколько полей ITR-RLOC Address, поэтому передающая Map-Reply сторона может выбрать адрес получателя для указания в Map-Reply. Значение IRC может быть от 0 до 31, 0 указывает наличие одного адреса ITR-RLOC, 1 – 2 ITR-RLOC и т. д. до 31 для указания 32 адресов ITR-RLOC.

Record Count

Число записей в сообщении Map-Request. Запись состоит из части пакета, помеченной на рисунке выше как Rec, которая повторяется Record Count раз. В этой версии протокола получатель должен воспринимать и обрабатывать сообщения Map-Request с одной или несколькими записями, но отправитель должен передавать Map-Request лишь с одной записью.

Nonce

8-октетное случайное значение, создаваемое отправителем Map-Request, которое будет возвращаться в Map-Reply. Значение nonce служит для идентификации соответствующего Map-Request при получении Map-Reply. Значение должно генерироваться генератором псевдослучайных чисел с подобающей затравкой (seed), например, [RFC4086].

Source-EID-AFI

Семейство адресов для поля Source EID Address.

Source EID Address

EID хоста-источника, создавшего пакет, который вызвал Map-Request. При использовании Map-Request для обновления записи Map-Cache или зондирования RLOC-Probing применяется AFI = 0 и это поле имеет размер 0.

ITR-RLOC-AFI

Семейство адресов для поля ITR-RLOC Address, которое следует за этим полем.

ITR-RLOC Address

Служит для предоставления ETR возможности выбора адреса получателя сообщения Map-Reply из любого семейства. Этот адрес должен быть маршрутизируемым адресом RLOC отправителя сообщения Map-Request.

EID mask-len

Размер маски для EID-Prefix.

EID-Prefix-AFI

Семейство адресов EID-Prefix в соответствии с [AFN] и [RFC8060].

EID-Prefix

Префикс адреса размером 4 октета для IPv4 и 16 октетов для IPv6 при EID-Prefix-AFI со значением 1 или 2, соответственно. Для других AFI [AFN] размер адреса меняется и для LCAF AFI формат задан в [RFC8060]. Если Map-Request передаётся ITR в результате приёма пакета данных для адресата, с которым не связана запись отображения, в качестве EID-Prefix устанавливается IP-адрес получателя пакета данных, а в поле EID mask-len — значение 32 для IPv4 или 128 для IPv6. Когда xTR хочет запросить у сайта статус отображения, которое уже кэшировано, EID-Prefix в Map-Request имеет такой же размер маски, что и префикс EID-Prefix, возвращённый сайтом при отправке сообщения Map-Reply.

Map-Reply Record

При установленном (1) бите M это поле содержит размер одной записи (Record) в формате Map-Reply. Эта запись Map-Reply содержить отображение EID на RLOC, связанное с EID источника. Это позволяет ETR, получившему этот Map-Request, кэшировать данные по своему усмотрению. Важно отметить, что это отображение Mapping System не проверяет.

5.3. Сообщение EID-RLOC UDP Map-Request

ITR передаёт Map-Request, когда ему нужно отображение для EID, проверка доступности RLOC или обновление отображения до завершения срока действия (Time to Live или TTL). В первом случае IP-адресрм получателя Map-Request является адрес получателя пакета (EID получателя), который не удалось найти в кэше отображений. В двух других случаях IP-адресом получателя Map-Request является один из адресов RLOC из Locator-Set записи Map-Cache. Адресом отправителя является адрес IPv4 или IPv6 RLOC в зависимости использования в Map-Request заголовка IPv4 или IPv6. Во всех случаях номер порта UDP у источника для сообщения Map-Request является 16-битовым значением, выбранным ITR/PITR, а для порта отправителя UDP устанавливается общеизвестный номер 4342. Получение Map-Reply с nonce, соответствующим nonce в остающемся Map-Request, будет обновлять кэшированный набор RLOC, связанных с EID-Prefix.

ITR должен указать в Map-Request одно или несколько полей (ITR-RLOC-AFI, ITR-RLOC Address). Число полей за вычетом 1 должно указываться в поле IRC. ITR может включить в этот список все локально настроенные локаторы или указать 1 Routing Locator Address для каждого поддерживаемого семейства адресов. Если ITR по ошибке не указал адресов ITR-RLOC, передающая Map-Reply сторона должна отбросить Map-Request.

Сообщения Map-Request можно инкапсулировать в LISP с использованием порта получателя UDP 4342 и LISP Type Encapsulated Control Message при передаче от ITR к Map-Resolver. Точно так же сообщения Map-Request инкапсулируются в LISP при передаче от Map-Server в ETR. Подробности представлены в параграфе 5.8.

Частота передачи Map-Request должна ограничиваться 1 сообщением в секунду на EID-Prefix. После 10 повторов без получения Map-Reply, отправитель должен установить паузу в 30 секунд.

ITR, настроенный со сведениями из базы отображений (т. е., являющийся также ETR), может включать эти отображения в Map-Request. Когда ETR, настроенный на восприятие и проверку таких (piggybacked) данных отображения, получает такой Map-Request и не имеет отого отображения в Map-Cache, он должен инициировать проверочное сообщение Map-Request через базу данных отображений.

5.4. Формат сообщения Map-Reply

        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=2 |P|E|S|          Reserved               | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record TTL                           |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   | Rsvd  |  Map-Version Number   |       EID-Prefix-AFI          |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-Prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |        Unused Flags     |L|p|R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

2 (Map-Reply)

P

Бит зондирования (probe-bit ), указывающий, что сообщение Map-Reply является откликом на Map-Request зондирования доступности локатора должно считаться зондом доступности локатора. Поле Nonce должно отвечать сообщением Map-Reply с установленным (1) битом probe-bit, указывающим, что Map-Reply является содержать копию nonce из исходного Map-Request (см. параграф 7.1. Алгоритм зондирования RLOC). При установленном (1) флаге probe-bit в сообщении Map-Reply бит A в каждой записи EID-Record, включённой в сообщение, должен иметь значение 1, в противном случае сообщение должно просто отбрасываться.

E

Указывает, что ETR, передающий это сообщение Map-Reply, анонсирует поддержку на сайте алгоритма проверки доступности локаторов Echo-Nonce (см. параграф 10.1 в [RFC9300]).

S

Бит защиты (Security), при установке (1) которого добавляется показанные ниже сведения в конце Map-Reply (см. [RFC9303]).

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    AD Type    |       Authentication Data Content . . .       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Reserved

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

Record Count

Число записей в отклике. Запись состоит из части пакета, помеченной на рисунке выше как Record, которая повторяется Record Count раз. Отметим, что число записей в отклике может превышать число записей в запросе, например, при наличии более конкретных префиксов.

Nonce

64-битовое значение из Map-Request, копируемое в Map-Reply.

Record TTL

Число минут, в течение которых получатель Map-Reply может сохранять отображение. Значение 0xffffffff позволяет получателю самому определять срок хранения.

Locator Count

Число записей элементов Locator в данной записи Record. Элемент для локатора представляет собой часть, помеченную на рисунке выше как Loc. Счётчик может иметь значение 0, указывающее отсутствие локаторов для EID-Prefix.

EID mask-len

Размер маски для EID-Prefix.

ACT

3-битовое поле, описывающее действия Negative Map-Reply. В сообщениях иного типа устанавливается 0, а при получении роле игнорируется. Эти биты используются, когда поле Locator Count имеет значение 0. Биты действий указываются в сообщениях Map-Reply и говорят ITR или PITR причину возврата пустого Locator-Set системой отображения и влияние отклика на Map-Cache (см. 12.3. Коды LISP Map-Reply EID-Record Action).

0. No-Action – Map-Cache сохраняется, инкапсуляции пакета не происходит.
1. Natively-Forward – пакет не инкапсулируется и не отбрасывается, а пересылается обычным способом.
2. Send-Map-Request – создаётся запись Map-Cache и помечается так, чтобы любой пакет, который соответствует ей, вызывал отправку Map-Request.
3. Drop/No-Reason – пакет, соответствующий этой записи Map-Cache, отбрасывается, при этом следует передавать сообщение ICMP Destination Unreachable.
4. Drop/Policy-Denied – пакет, соответствующий этой записи Map-Cache, отбрасывается. Причина заключается в том, что Map-Request для целевого EID отвергнут правилами xTR или Mapping System.
5. Drop/Auth-Failure – пакет, соответствующий этой записи Map-Cache, отбрасывается. Причина заключается в том, что запрос Map-Request для целевого EID не прошёл проверку подлинности в xTR или Mapping System.

A

Бит полномочий (authoritative), который может устанавливать (1) только ETR. Серверу Map-Server, создающему сообщения Map-Reply как посреднику, недопустимо устанаваливать A = 1. Этот бит указывает запрашивающим ITR, исходит ли Map-Reply от узла LISP на сайте, владеющем EID-Prefix.

Map-Version Number

12-битовое поле номера версии отображения в EID-Record сообщения Map-Reply (см. [RFC9302]).

EID-Prefix-AFI

Семейство адресов EID-Prefix в соответствии с [AFN] и [RFC8060].

EID-Prefix

4-октетный префикс для семейства адресов IPv4 или 16-октетный для IPv6.

Priority

Для каждого RLOC устанавливается значение Priority, меньшее значение указывает более высокий приоритет. Когда у нескольких RLOC значения Priority совпадают, их можно применять для распределения нагрузки. Значение 255 указывает, что RLOC недопустимо использовать для пересылки индивидуальных пакетов.

Weight

При совпадении приоритета у нескольких RLOC значение Weight задаёт долю индивидуального трафика между ними. Вес кодируется как относительная доля unicast-пакетов, соответствующих записи отображения. Например, при наличии в Locator-Set 4 локаторов с Weight 30, 20, 20 и 10 первый локатор получит 37,5% трафика, второй и третий – по 25%, а четвёртый – 12,5%. Если все значения Weight для Locator-Set совпадают, получатель Map-Reply сам принимает решение о распределении трафика. В разделе 12 [RFC9300] предложен алгоритм хэширования для распределения трафика между локаторами с одинаковыми значениями Priority и Weight.

M Priority

Для каждого RLOC назначается групповой приоритет, используемый ETR на принимающем multicast-трафик сайте для выбора ITR на групповом сайте-источнике при построении деревьев распространения группового трафика. Значение 255 указывает, что RLOC недопустимо использовать для присоединения к multicast-дереву (см. [RFC6831]).

M Weight

При совпадении приоритета у нескольких RLOC значение Weight задаёт распределение трафика при построении multicast-дерева с несколькими ITR. Вес указывает относительную долю (как unicast Weight) от общего числа деревьев, строящихся к сайту-источнику, заданному EID-Prefix. Если все веса в Locator-Set совпадают, получатель Map-Reply будет сам распределять групповой трафик между ITR (см. [RFC6831]).

Unused Flags

Это поле устанавливается в 0 при передаче и игнорируется получателем.

L

Установка этого бита помечает локатор как локальный для ETR, передающего Map-Reply. Когда Map-Server служит посредником для Map-Reply сайта LISP, бит L сбрасывается (0) для всех локаторов этого Locator-Set.

p

Когда этот бит установлен, ETR информирует маршрутизатор ITR, передающий RLOC-Probe, о том, что адрес локатора маршрутизации, для которого этот бит установлен, является одним из проверяемый с помощью RLOC-Probe и может отличаться от адреса отправителя Map-Reply. ITR, использующий RLOC-Probe для конкретного локатора, должен использовать этот Locator для извлечения структуры данных, служащей для хранения факта достижимости этого локатора. Бит p устанавливается для одного локатора в одном Locator-Set. Если реализация по ошибке установит несколько флагов p, получатель Map-Reply должен выбирать первый локатор с установленным битом p. Флаг p недопустимо устанавливать для записей Locator-Set, передаваемых в сообщениях Map-Request и Map-Register.

R

Устанавливается, когда отправитель Map-Reply имеет маршрут к локатору в записи данных Locator. Этому получателю может быть полезно знать, активен (up) ли локатор, с точки зрения получателя (не обязательно достижим).

Locator

Адрес IPv4 или IPv6 (в соответствии с полем Loc-AFI), назначенный ETR и используемый ITR в качестве RLOC получателя во внешнем заголовке пакета с инкапсуляцией LISP. Отметим, что RLOC получателя в пакете с инкапсуляцией LISP может быть anycast-адресом, равно как RLOC отправителя пакета с инкапсуляцией LISP. В качестве RLOC отправителя или получателя недопустимо применять широковещательный адрес (255.255.255.255 или иной широковещательный адрес подсети, известный маршрутизатору) и ему недопустимо быть групповым адресом link-local. В качестве RLOC отправителя недопустим групповой адрес. Для RLOC получателя следует указывать групповой адрес, если он сопоставлен с групповым EID получателей.

Частота передачи сообщений Map-Reply должна ограничиваться и рекомендуется передавать Map-Reply с одним RLOC получателя не чаще 1 раза за три секунды.

Формат Record, указанный здесь, включая определения всех полей, применяется в сообщениях Map-Reply и Map-Register.

5.5. Сообщение EID-RLOC UDP Map-Reply

Map-Reply возвращает EID-Prefix с размером маски не более запрошенного EID из поля адреса получателя в заголовке IP пакета Data-Probe или EID записи Map-Request. RLOC в Map-Reply являются маршрутизируемыми адресами IP всех ETR для сайта LISP. Каждый RLOC сообщает статус своей доступности, но не сообщает статус доступности пути с точки зрения запрашивающего, поэтому для пути нужна отдельная проверка (см. 7.1. Алгоритм зондирования RLOC).

Отметим, что в Map-Reply может использоваться детализация EID-Prefix (префикс и размер маски), отличающаяся от указанной в вызвавшем отклик сообщении Map-Request. Это может быть обусловлено отправкой Map-Request для префикса, возвращённого в предшествующем Map-Reply. В таком случае запрашивающий обновляет свой кэш новыми сведениями для префикса. Например, запрашивающий с двумя кэшированными EID-Prefix, охватываемыми Map-Reply с менее конкретным префиксом, заменяет свою запись этим менее конкретным EID-Prefix. Отметим, что возможна и обратная ситуация с включением нескольких более конкретных префиксов без удаления менее конкретного, поскольку при поиске возвращается более конкретный префикс.

При переносе EID за пределы сайта LISP [EID-MOBILITY], в базе данных Mapping System могут возникать перекрывающиеся EID-Prefix. Аналогичная ситуация может возникать при настройке на сайте LISP нескольких наборов ETR, поддерживающих различные размеры масок EID-Prefix. При перекрытии EID-Prefix сообщение Map-Request для EID должно возвращать EID-Prefix с максимальным соответствием в сообщении Map-Reply. Например, если ETR имеет записи отображений для EID-Prefix

     2001:db8::/32
     2001:db8:1::/48
     2001:db8:1:1::/64
     2001:db8:1:2::/64

Map-Request для EID 2001:db8:1:1::1 будет приводить к получению Map-Reply с одной записью EID-Prefix 2001:db8:1:1::/64. Map-Request для EID 2001:db8:1:5::5 будет возвращать Map-Reply с 3 записями для EID-Prefix 2001:db8:1::/48, 2001:db8:1:1::/64, 2001:db8:1:2::/64, заполняя /48 более конкретными префиксами из Mapping System.

Отметим, что возвращать требуется не все перекрывающиеся EID-Prefix, а лишь более конкретные (во втором примере выше префикс 2001:db8::/32 не был возвращён для запроса EID 2001:db8:1:5::5) для EID-Prefix из запроса EID. При возврате более одного EID-Prefix для всех следует использовать одно значение TTL, чтобы срок их действия завершался одновременно. При получении позднее более конкретного EID-Prefix его значение TTL в записи Map-Reply может быть сохранено даже при наличии менее конкретных записей. При получении позднее менее конкретного EID-Prefix время завершения Map-Cache следует установить в соответствии с минимальным временем завершения более конкретного EID-Prefix в Map-Cache. Это делается для сохранения целостности набора EID-Prefix, чтобы из Map-Cache не удалялись более конкретные записи при сохранении менее конкретных.

Предполагается, что с точки зрения расширяемости агрегирование адресов EID в префиксы EID-Prefixes позволит одному сообщению Map-Reply соответствовать отображению адресов EID в диапазоне префиксов, снижая число сообщений Map-Request.

Записи Map-Reply могут включать пустой набор Locator-Set. Сообщение Negative Map-Reply – это Map-Reply с пустым Locator-Set. Такие сообщения Map-Reply передают специальные действия отправителя Map-Reply маршрутизаторам ITR и PITR, которые запросили Map-Reply. Имеется два основных применения Negative Map-Reply. Во-первых, Map-Resolver указывает ITR или PITR, когда адресат является сайтом LISP (в отличие от прочих), а во-вторых, для подавления источников Map-Request, передающих невыделенные EID.

Для каждой записи Map-Reply список локаторов в Locator-Set должен сортироваться в порядке роста адресов IP, при этом адреса IPv4 считаются численно меньшими по сравнению с адресами IPv6.

При передаче сообщения Map-Reply адрес получателя копируется из одного из полей ITR-RLOC в Map-Request. ETR может выбрать адрес локатора маршрутизации одного из семейств адресов, которые он поддерживает. Для Data-Probe адрес получателя Map-Reply копируется из поля отправителя сообщения Data-Probe, вызвавшего отклик. Адресом отправителя Map-Reply является один из локальных адресов IP, это позволяет применять индивидуальную проверку пересылки по обратному пути (Unicast Reverse Path Forwarding или uRPF) для восходящего поставщика услуг. Порт получателя Map-Reply копируется из поля порта отправителя сообщения Map-Request или Data-Probe, а для порта отправителя Map-Reply устанавливается стандартное значение UDP 4342.

5.6. Формат сообщения Map-Register

Ф этот параграфе задан формат кодирования сообщений Map-Register. Сообщения передаются в порт UDP 4342 из выбранного случайно порта UDP.

Показанные ниже поля применяются в нескольких типах сообщений и определены для Map-Register, Map-Notify, Map-Notify-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=3 |P|S|I|        Reserved       |E|T|a|R|M| Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Key ID     | Algorithm ID  |  Authentication Data Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                     Authentication Data                       ~
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record TTL                           |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   | Rsvd  |  Map-Version Number   |        EID-Prefix-AFI         |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-Prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |        Unused Flags     |L|p|R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

3 (Map-Register)

P

Флаг посредника для Map-Reply. Установка (1) флага показывает, что ETR, передавший Map-Register, запросил у Map-Server посредничество для Map-Reply. Map-Server передаёт неполномочные Map- Reply от имени ETR.

S

Бит поддержки защиты, установка (1) которого включает поддержку процедур [RFC9303].

I

Бит присутствия идентификатор, установка (1) которого показывает наличие 128-битового поля xTR-ID и 64-битового Site-ID в конце сообщения Map-Register. Если xTR настроен с xTR-ID и Site-ID, он должен устанавливать I=1 и включать свои xTR-ID и Site-ID в создаваемые сообщения Map-Register. Комбинация Site-ID и xTR-ID однозначно указывает xTR в домене LISP и служит для отслеживания его последнего nonce.

Reserved

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

E

Бит уведомления EID Map-Register, используемый первым (First-Hop) маршрутизатором, обнаружившим динамический адрес EID. Это сообщение Map-Register на основе EID-notify передаётся первым маршрутизатором xTR того же сайта, распространяющему Map-Register в Mapping System. Сайт xTR сохраняет состояние последнего Map-Notify первого маршрутизатора после удаления EID (см. подробности применения в [EID-MOBILITY]).

T

Флаг использования TTL для тайм-аута. Установка (1) флага указывает, что xTR хочет, чтобы Map-Server прерывал регистрацию на основе значения поля Record TTL в этом сообщении. В ином случае применяется заданный по умолчанию тайм-аут (8.2. Настройка EID-Prefix и регистрация ETR).

a

Бит слияния, установка (1) которого показывает, что xTR запрашивает слияние записей RLOC-Record от разных xTR, регистрирующих одну и ту же запись EID-Record (см. пример использования в [RFC8378]).

R

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

M

Бит want-map-notify, установка (1) которого показывает, что ETR запрашивает возврат сообщения Map-Notify в ответ на Map-Register. Сообщение Map-Notify от Map-Server служит подтверждением приёма Map-Register.

Record Count

Число записей в Map-Register. Запись состоит из части пакета, помеченной на рисунке выше как Record, которая повторяется Record Count раз.

Nonce

Это 8-октетное поле Nonce инкрементируется при каждой отправке сообщения Map-Register. При запросе подтверждения Map-Register значение nonce серверы Map-Server возвращают в сообщениях Map-Notify. Поскольку проверяется подлинность всего сообщения Map-Register, поле Nonce служит для защиты от атак с повторным использованием Map-Register (replay). ETR при регистрации в Mapping System следует сохранять последнее значение nonce в постоянном хранилище, чтобы при перезапуске можно было продолжать использование инкрементируемых nonce. Если ETR не может сохранять nonce, то при перезапуске он должен использовать новый ключ аутентификации для регистрации в Mapping System. Map-Server должен отслеживать и записывать в постоянное хранилище последнее значение nonce, принятое для каждой пары ETR xTR-ID и ключа. При получении Map-Register со значением nonce, которое не превышает сохранённое значение сервер должен отбрасывать сообщение Map-Register и следует записывать это в системный журнал, как возможную replay-атаку.

Key ID

Значение key-id, указывающее заранее распространённый секрет для ETR и Map-Server. Ключи для каждого сообщения выводятся из этого секрета для аутентификации источника и защиты целостности Map-Register. Key ID позволяет менять заранее распространённые секреты без нарушения работы. Секрет должен быть уникальным для каждого LISP Site-ID.

Algorithm ID

Указывает алгоритмы функции вывода ключа (Key Derivation Function и KDF) и кода аутентификации сообщений (Message Authentication Code или MAC), применяемые для создания ключа и расчёта данных аутентификации (Authentication Data) для Map-Register. Это 8-битовое поле указывает пару KDF и алгоритма MAC, возможные значения указаны в параграфе 12.5. Номера LISP Algorithm ID.

Authentication Data Length

Число октетов следующего поля Authentication Data. Размер Authentication Data зависит от применяемого алгоритма MAC. Это поле позволяет корректно анализировать пакет устройству, не знающему алгоритм MAC.

Authentication Data

Вывод алгоритма MAC, помещаемый после расчёта, описанного ниже.

1. Алгоритм KDF указывается полем Algorithm ID в соответствии с таблицей 5. Реализации этой спецификации должны поддерживать HMAC-SHA-256-128 [RFC4868] и следует поддерживать HMAC-SHA-256-128+HKDF-SHA256 [RFC5869].
2. Алгоритм MAC указывается полем Algorithm ID в соответствии с таблицей 5.
3. Выводится ключ для сообщения из заранее распространённого секрета, указанного PSK[Key ID].
4. Ключ для сообщения выводится как per-msg-key=KDF(nonce+PSK[Key ID],s), где nonce – значение поля Nonce из Map-Register, + означает конкатенацию, а s (salt) указывает строку, соответствующую типу аутентифицируемого сообщения. Для Map-Register это Map-Register Authentication, для Map-Notify и Map-Notify-Ack – Map-Notify Authentication и Map-Notify-Ack Authentication, соответственно. Для Algorithm ID, из таблицы 5, задающих для KDF значение none, ключ сообщения создается как per-msg-key = PSK[Key ID]. Это означает использование одного ключа для разных сообщений протокола.
5. Вывод MAC рассчитывается с применением алгоритма MAC и ключа для сообщения ко всему содержимому (payload) сообщения Map-Register (начиная с поля типа сообщения LISP до конца последней записи RLOC-Record). Для поля данных аутентификации при расчёте принимается значение 0.

Определения оставшихся полей Map-Register приведены в описании EID-Record (5.4. Формат сообщения Map-Reply). При установленном (1) бите I в конец сообщения Map-Register добавляются указанные ниже поля.

xTR-ID

128-битовое поле в конце сообщения Map-Register вслед за последним полем Record. xTR-ID служит для однозначного указания xTR и недопустимо применять 1 значение для разных xTR в области действия Site-ID.

Site-ID

64-битовое поле в конце сообщения Map-Register вслед за xTR-ID. Site-ID служит для однозначного указания сайта, к которому относится xTR, передающий сообщение. Этот документ не задаёт смысл поля Site-ID строго. Неформально оно указывает группу xTRs, как-то связанных между собой административно, топологически или иначе.

5.7. Формат сообщений Map-Notify и Map-Notify-Ack

This section specifies the encoding format for the Map-Notify and Map-Notify-Ack messages. The messages are sent inside a UDP packet with source and destination UDP ports equal to 4342.

The Map-Notify and Map-Notify-Ack message formats are:

        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=4/5|             Reserved                 | Record Count  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         Nonce . . .                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         . . . Nonce                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |    Key ID     | Algorithm ID  |  Authentication Data Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       ~                     Authentication Data                       ~
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                          Record TTL                           |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
   e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   c   | Rsvd  |  Map-Version Number   |         EID-Prefix-AFI        |
   o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   r   |                          EID-Prefix                           |
   d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
   | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | o |        Unused Flags     |L|p|R|           Loc-AFI             |
   | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  \|                             Locator                           |
   +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

4/5 (Map-Notify/Map-Notify-Ack)

Сообщения Map-Notify по составу содержимого совпадают с Map-Register. Описания полей приведены в параграфе 5.6. Формат сообщения Map-Register, а описания EID-Record и RLOC-Record – в 5.4. Формат сообщения Map-Reply.

Поля Map-Notify копируются из соответствующего сообщения Map-Register для подтверждения корректной обработки. В Map-Notify поле Authentication Data рассчитывается заново с использованием соответствующего ключа сообщения по процедуре, описанной в предыдущем параграфе. Сообщения Map-Notify могут передаваться без запроса, но это выходит за рамки документа (см. [LISP-PUBSUB]).

Если после отправки Map-Register сообщение Map-Notify не было получено в течение 1 секунды, передающая сторона должна повторять передачу исходного Map-Register с экспоненциально растущим интервалом повтора (с базой 2, т. е. удвоением интервала перед каждым повтором) вплоть до 1 минуты. Сообщения Map-Notify передаются лишь при получении Map-Register с установленным флагом M и не повторяются. Единственным исключением являются незапрошенные сообщения Map-Notify (см. ниже).

Map-Server передаёт незапрошенное сообщение Map-Notify (т. е. не являющееся подтверждением Map-Register) лишь в соответствии с параграфами 3.1 и 3.3 в [RFC8085]. Передача Map-Notify повторяется, пока Map-Server не получит Map-Notify-Ack с тем же nonce, что и в сообщении Map-Notify. Реализациям следует повторять передачу до 3 раз с интервалом 3 секунды, после чего интервал повтора следует экспоненциально увеличивать (вдвое при каждом следующем повторе) до 3 раз. Сообщения Map-Notify-Ack передаются лишь при получении незапрошенного Map-Notify и не повторяются.

Содержимое Map-Notify-Ack совпадает с содержимым Map-Notify. Сообщение служит подтверждением приёма незапрошенного Map-Notify и, поскольку Authentication Data проверяются, позволяет отправителю остановить повтор Map-Notify с теми же nonce и (проверенными) Authentication Data. Поля Map-Notify-Ack копируются из соответствующего Map-Notify для подтверждения корректной обработки. Поле Authentication Data рассчитывается заново с использованием соответствующего ключа сообщения по процедуре, описанной в предыдущем параграфе.

При получении Map-Register, Map-Notify или Map-Notify-Ack получатель проверяет Authentication Data и при отказе отбрасывает сообщение без дальнейшей обработки.

5.8. Формат инкапсулированного управляющего сообщения

Инкапсулированные управляющие сообщения (Encapsulated Control Message или ECM) применяются для инкапсуляции пакетов управления, передаваемых между xTR и системой отображения.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |                     Заголовок IPv4 или IPv6                   |
   OH  |                        (с адресами RLOC)                      |
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4342        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  LISP |Type=8 |S|D|R|R|            Reserved                           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |                     Заголовок IPv4 или IPv6                   |
   IH  |                    (с адресами RLOC или EID)                  |
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = yyyy        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   LCM |                      LISP Control Message                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

OH

Внешний заголовок IPv4 или IPv6 с адресами RLOC в полях отправителя и получателя.

UDP

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

LISP

Тип 8, определённый для инкапсулированных управляющих сообщений LISP, за которым (в зависимости от 4 битов перед полем Reserved) следует заголовок IPv4/IPv6 или поле Authentication Data [RFC9303], если установлен флаг S (см. ниже).

Type

8 (Encapsulated Control Message (ECM))

S

Бит защиты (Security), установка (1) которого указывает, что поле Reserved имеет показанный ниже формат Authentication Data и следует процедурам [RFC9303].

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    AD Type    |       Authentication Data Content . . .       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

D

Бит DDT, установка (1) которого указывает, что отправитель запрашивает возврат сообщения Map-Referral (см. [RFC8111]).

R

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

IH

Внутренний заголовок IPv4 или IPv6 с адресами RLOC или EID в полях отправителя и получателя. При инкапсуляции в этот формат сообщения Map-Request адресом получателя в этом заголовке является EID.

UDP

Внутренний заголовок UDP, в котором назначение портов зависит от инкапсулируемого пакета управления. Для пакетов Map-Request и Map-Register порт отправителя выбирает ITR/PITR, а порто получателя служит 4342. Для Map-Reply указывается порт отправителя 4342 а порт получателя берётся из вызвавшего сообщение пакета Map-Request. Значение 4341 недопустимо указывать для любого из портов. Поле контрольной суммы должно быть ненулевым.

LCM

Формат одного из управляющих сообщений, описанных в разделе 5. Сообщения Map-Request разрешено инкапсулировать в ECM. При передаче Map-Request как RLOC-Probe (probe-bit установлен) недопустимо помещать сообщение в ECM. Сообщения PIM Join/Prune [RFC6831] можно инкапсулировать в ECM.

6. Изменение содержимого отображений EID-RLOC

В архитектуре LISP маршрутизатор ITR и PITR применяют Map-Cache для хранения отображений EID-RLOC для пересылки. Когда ETR обновляет отображение, нужен механизм информирования ITR и PITR об изменении.

Плоскость данных LISP определяет несколько механизмов для обновления сопоставлений [RFC9300]. Этот документ задаёт механизм плоскости управления Solicit-Map-Request (SMR). Другие механизмы плоскости управления на основе подписки и выталкивания описаны в [LISP-PUBSUB].

6.1. Solicit-Map-Request (SMR)

Запрос сообщений Map-Request обеспечивает ETR селективный способ управлять на сайте скорстью получения запросов на сообщения Map-Reply. SMR также информируют все удалённые ITR для обновления кэшированных записей.

Поскольку ETR не обязаны отслеживать удалённые ITR, которые кэшируют их отображения, они не знают, каким ITR нужно обновлять отображение. Поэтому ETR запрашивает Map-Request у тех сайтов, которым он передавал инкапсулированные в LISP пакеты данных за последнюю минуту. При работе ETR и в качестве ITR он передаёт SMR маршрутизаторам ITR, которым он недавно передавал инкапсулированные данные.

Сообщение SMR является просто Map-Request с установленным флагом S (5.2. Формат сообщения Map-Request). ITR и PITR будут передавать Map-Request (вызванные SMR) при получении SMR. Хотя SMR передаются через плоскость данных, вызванные ими Map-Request должны передаваться через Mapping System (не напрямую).

Отправитель SMR и отвечающая сторона должны ограничивать скорость передачи сообщений. Отправителю SMR рекомендуется ограничивать частоту передачи для одного RLOC получателя 1 пакетом каждые 3 секунды. Отвечающему рекомендуется передавать не более 1 Map-Request за каждые 3 секунды для одного EID-Prefix.

Когда ITR получает сообщение SMR, для которого у него нет кэшированного отображения для EID из SMR, ему не следует передавать вызванное SMR сообщение Map-Request. Это может возникать в случае, когда ETR передаёт SMR всем локаторам из Locator-Set, сохранённого в его Map-Cache, а удалённые ITR, получающие SMR, могут не передавать данных на сайт. Нет смысла обновлять ITR, пока им не нужно ничего передавать, а перед передачей можно отправить Map-Request для получения записи.

7. Доступность локаторов маршрутизации

Этот документ задаёт несколько механизмов плоскости управления для проверки доступности RLOC. В [RFC9300] определены механизмы проверки доступности в плоскости данных.

1. ITR может получать сообщения ICMP Network Unreachable или Host Unreachable для используемых RLOC, указывающие недоступность адреса. Отметим, что сообщениям ICMP не всегда можно доверять, но игнорировать их полностью не следует. Реализациям рекомендуется следовать основанной на опыте трактовке таких сообщений, описанной в [OPSEC-ICMP-FILTER].

2. При участии ITR в протоколе маршрутизации базовой сети, он может определить недоступность RLOC по отсутствию в базе маршрутных сведений (Routing Information Base или RIB) записи для IP-адреса RLOC.

3. ITR может получить от целевого хоста сообщение ICMP Port Unreachable. Это может происходить при использовании ITR взаимодействия [RFC6832] с передачей пакетов LISP сайту, не поддерживающему LISP.

4. ITR может получить отклик Map-Reply от ETR в ответ на переданое сообщение Map-Request. RLOC источника Map-Reply вероятно будет активен (up), поскольку ETR удалось передать Map-Reply маршрутизатору ITR. Следует отметить, что в некоторых случаях значение RLOC из внешнего заголовка может быть подменено.

5. Пара ITR – ETR может использовать описанный ниже механизм зондирования RLOC-Probing.

Когда ITR получают сообщения ICMP Network Unreachable или Host Unreachable как метод определения недоступности, они будут воздерживаться от использования локаторов из списков сообщений Map-Reply. Однако такой подход ненадёжен, поскольку многие сетевын оператору отключают генерацию сообщений ICMP Destination Unreachable.

Если ITR получает сообщение ICMP Network Unreachable или Host Unreachable, он может создать своё сообщение ICMP Destination Unreachable для хоста, создавшего пакет данных, инкапсулированный ITR.

Это допущение создаёт зависимость – недоступность локатора обнаруживается получением сообщений ICMP Host Unreachable. Когда Locator считается недоступным, он не используется для активного трафика, как будто был указан в Map-Reply с Priority = 255.

ITR может проверить доступность локатора, периодически отправляя Map-Request. Частота отправки сообщений Map-Request и Map-Reply должна ограничиваться (см. 5.3. Сообщение EID-RLOC UDP Map-Request и 5.4. Формат сообщения Map-Reply). Тестирование доступности локаторов никогда не выполняется с пакетами данных, поскольку это повышает риск потерь для сквозных сессий.

7.1. Алгоритм зондирования RLOC

RLOC-Probing – это метод, который ITR и PITR могут применять для определения статуса доступности одного или нескольких локаторов в записи Map-Cache. Для этого служит флаг probe-bit в сообщениях Map-Request и Map-Reply.

RLOC-Probing выполняется в плоскости управления по таймеру, а ITR или PITR передаёт Map-Request для адреса локатора с одного из свойих адресов RLOC. Map-Request в качестве RLOC-Probe не инкапсулируется и не передаются Map-Server или базе данных отображений как при запросе отображения. EID-Record в Map-Request является EID-Prefix из записи Map-Cache на ITR или PITR. ITR может включить запись данных отображения из своих сведений о сопоставлениях, содержащую локальные EID-Prefix и RLOC для сайта. RLOC-Probe передаются периодически с внесением вариаций в интервал отправки.

Когда ETR получает Map-Request с установленным флагом probe-bit, он возвращает Map-Reply с таким же флагом. В качестве адреса отправителя Map-Reply указывается IP-адрес исходящего интерфейса, на который маршрутизируется адрес получателя Map-Reply. В Map-Reply следует включать данные отображения для EID-Prefix из Map-Request. Это позволяет ITR и PITR передавать RLOC-Probe для получения обновлений отображений, если они возникли с записях базы сопоставлений ETR.

Метод RLOC-Probing имеет преимуществ и недостатки. Основным преимуществом является возможность работы при разных отказах, что позволяет ITR определить, когда путь к конкретному локатороу достпен или стал недоступным, обеспечивая надёжный способ переключения на другой локатор. RLOC-Probing может также давать приблизительную оценку времени кругового обхода (Round-Trip Time или RTT) между парой локаторов, что может быть полезно для функций управления сетью, а также для выбора пути с меньшей задержкой. Основным недостатком RLOC-Probing является большое число управляющих сообщений и расход пропускной способности для получения упомянутых преимущест, особенно при жёстких требованиях в времени обнаружения отказов.

8. Взаимодействие с другими компонентами LISP

8.1. Распознавание отображения ITR EID-RLOC

На ITR настраивается 1 или несколько адресов Map-Resolver, которые служат локаторами (RLOC) и должны быть маршрутизируемыми в базовой сети ядра. Для этих адресов недопустимо требовать распознавания через отображения LISP EID-RLOC, поскольку это будет создавать циклические зависимости. При использовании Map-Resolver маршрутизатору ITR не требуется соединение с другими базами данных Mapping System.

ITR передаёт инкапсулированный Map-Request настроенному Map-Resolver, когда еиу нужно отображение EID-RLOC, отсутствующее в его локальном Map-Cache. Использование Map-Resolver силь сокращает сложности реализации ITR и издержки, связанные с его работой.

В ответ на инкапсулированное сообщение Map-Request маршрутизатор ITR может получить один из указанных ниже вариантов.

• Незамедлительный отклик Negative Map-Reply (с кодом действия Natively-Forward и 15-минутным TTL) от Map-Resolver, если тот может определить, что запрошенного EID не существует. ITR сохраняет EID-Prefix, возвращённый в Map-Reply в своём кэше, помечает его как не поддерживающий LISP и знает, что не нужно пытаться инкапсулировать в LISP пакеты для этого префикса.

• Negative Map-Reply (с кодом действия Natively-Forward) от Map-Server, полномочного (внутри развёртывания LISP, см. параграф 1.1. Сфера применимости) для EID-Prefix, соответствующего запрошенному EID, но не имеющего активно зарегистрированного более конкретного EID-Prefix. В этом случае говорят, что запрошенный EID соответствует «дыре» (hole) в полномочном префиксе. Если запрошенный EID соответствует более конкретному EID-Prefix, чем был делегирован серверу Map-Server, для которого не зарегистрировано ETR, возврашается 1-минутное значение TTL. Если запрошенный EID соответствует неделегированной части полномочного EID-Prefix, это не LISP EID и возвращается 15-минутное значение TTL. Подробное обсуждение делегирования EID-Prefix и детали сопоставления префиксов в Map-Server рассмотрены в параграфе 8.2. Настройка EID-Prefix и регистрация ETR.

• LISP Map-Reply от ETR, владеющего отображением EID-RLOC, или от Map-Server, отвечающего от имени ETR. Более подробно обработка сообщений в Map-Resolver описана в параграфе 8.4. Обработка в Map-Resolver.

Отметим, что ITR можно настроить как на использование Map-Resolver, так и на участие в логической сети LISP-ALT. В такой ситуации ITR следует передавать Map-Request через сеть ALT для любого EID-Prefix, полученного от ALT BGP. Такая конфигурация предполагается очень редкой, так как от применения Map-Resolver мало пользы, если ITR уже применяет LISP-ALT. Например, такому ITR не требуется передавать Map-Request для возможно несуществующего EID (и полагаться на Negative Map-Reply), если он может обратиться к базе данных ALT для проверки наличия EID-Prefix до отправки Map-Request.

8.2. Настройка EID-Prefix и регистрация ETR

ETR публикует свои EID-Prefix на Map-Server, передавая сообщения LISP Map-Register. Сообщения Map-Register включает данные аутентификации (AD), поэтому перед их отправкой ETR и Map-Server должны получить общий секрет, используемый для вывода ключей аутентификации Map-Register. В конфигурацию Map-Server следует также включать список EID-Prefix, для которых ETR имеет полномочия. После получения Map-Register от ETR сервер будет воспринимать лишь настроенные для этого ETR префиксы EID-Prefix. Отказ от реализации такой проверки сделает систему отображения уязвимой для тривиальных атак с захватом EID-Prefix.

В дополнение к набору EID-Prefix для каждого ETR, который может быть зарегистрирован, на Map-Server обычно настраивается один или несколько агрегированных префиксов, указывающих части выделенного ему пространства EID. При использовании базы данных LISP-ALT агрегированные префиксы реализуются как маршруты отбрасывания и анонсируются в ALT BGP. Наличие агрегированных EID-Prefix в базе данных Map-Server означает, что сервер может получать Map-Request для EID-Prefix, которые соответствуют агрегату, но не соответствуют зарегистрированному префиксу. Обработка таких ситуаций описана в параграфе 8.3. Обработка в Map-Server.

Сообщения Map-Register передаются периодически от ETR на Map-Server с рекомендуемым интервалом в 1 минуту. Серверу следует удалять регистрацию ETR по тайм-ауту, если он не получил от него действительного сообщения Map-Register в течение 3 минут. При первом контакте с Map-Server после перезапуска или смене отображений в своей базе данных EID-RLOC маршрутизатор ETR может сначала передавать сообщения Map-Register более часто, вплоть до 1 каждые 20 секунд. Продолжительность интервала «ускоренной регистрации» ограничена 5 минутами.

ETR может запросить у Map-Server явное подтверждение приёма и обработки сообщения Map-Register, установив (1) флаг want-map-notify (M). Map-Server, получивший Map-Register с установленным флагом, будет отвечать сообщением Map-Notify. Обычно ETR будет устанавливать этот флаг в сообщениях Map-Register, передаваемых при начальной ускоренной регистрации на Map-Server, а затем применять его лишь время от времени при наличии установившейся ассоциации с этим Map-Server. Отметим, что сообщение Map-Notify передаётся в порт UDP 4342, а не в порт, из которого передано исходное сообщение Map-Register.

Отметим, что 1-минутный минимальный интервал регистрации при наличии поддержимаемой ассоциации ETR-Map-Server задаёт нижнюю границу скорости и частоты возможных обновления базы отображений. Это может влиять на типы напрямую поддерживаемой системой отображений мобильности – в некоторых случаях могут потребоваться более короткие интервалы или иные механизмы регистрации. Обсуждение способов реализации ускорения мобильности для индивидуальных устройств можно найти в [LISP-MN].

ETR может, устанавливая флаг proxy Map-Reply (P) в сообщении Map-Register, запросить у Map-Server отклики на Map-Request вместо их пересылки ETR. В параграфе 7.1. Алгоритм зондирования RLOC описана установка сервером Map-Server некоторых флагов (таких, как указание полномочности сообщения и как следует трактовать возвращённые локаторы) при передаче Map-Reply от имени ETR. Когда ETR запрашивает услуги посредника для откликов, ему следует включать все RLOC для всех ETR регистрируемого EID-Prefix вместе с установкой флага маршрутизируемости (R) для каждого RLOC. Map-Server включает все эти сведения в сообщения Map-Reply, передаваемые от имени ETR. Это отличается от регистрации без посредника, поскольку та требует лишь предоставить 1 или несколько RLOC для Map-Server, применяемых при пересылке Map-Request, регистрационные сведения не используются в Map-Reply, поэтому неполнота информации не ведёт к ошибке.

ETR, использующему Map-Server для публикации своих отображений EID-RLOC, не требуется дальнейшее участие в протоколах баз данных отображений. При использовании базы отображений LISP-ALT это означает, например, что ETR не нужно реализовать GRE или BGP, что значительно упрощает настройку и эксплуатационные издержки.

Отметим, что использование Map-Server не препятствует подключению ETR к базе данных отображений (т. е. он может подключаться и к сети LISP-ALT), но это не представляется особо полезным, поскольку целью использования Map-Server является избавление от сложностей протоколов баз данных отображения.

8.3. Обработка в Map-Server

Когда Map-Server имеет EID-Prefix, зарегистрированные его клиентами ETR, он может воспринимать и обрабатывать сообщения Map-Request от них. При получении Map-Request сервер Map-Server сначала проверяет соответствие EID получателя настроенному EID-Prefix. Если совпадений не найдено, Map-Server возвращает Negative Map-Reply с кодом действия Natively-Forward и 15-минутным TTL. Это может происходить при получении a Map-Request для настроенного агрегированного EID-Prefix, не имеющего более конкретного EID-Prefix, и указывает наличие «дыры», не поддерживающей LISP в агрегате EID-Prefix. Затем Map-Server проверяет наличие зарегистрированных ETR для соответствующего EID-Prefix. Если ничего не найдено, Map-Server возвращает Negative Map-Reply с кодом действия Natively-Forward и 1-минутным TTL.

Независимо от регистрации EID-Prefix в Mapping System при наличии на Map-Server правила отбрасывания запрашивающим пакетов для соответствующего EID-Prefix возвращается код действия Drop/Policy-Denied. Если возникает отказ при аутентификации (независимо от регистрации EID-Prefix), возвращается код действия Drop/Auth-Failure. Если любое из этих действий создаёт временное состояние политики или аутентификации, может возвращаться код действия Send-Map-Request с 1-минутным TTL, чтобы запрашивающий мог повторить Map-Request.

Если любой из ETR, зарегистрированных для EID-Prefix, запросил посредничество при ответе, Map-Server отвечает на запрос вместо его пересылки. Он возвращает Map-Reply с EID-Prefix, адресами RLOC и другими сведениями, полученными в процессе регистрации.

Если ни один из ETR не запрашивал посреднических услуг, Map-Server заново инкапсулирует и пересылает инкапсулированное сообщение Map-Request одному из зарегистрированных ETR. В остальном Map-Request не меняется, поэтому сообщение Map-Reply, переданное ETR, возвращается по RLOC из Map-Request, а не на Map-Server. Если сервер действует и как Map-Resolver, ему не следует получать сообщения Map-Reply и любое такое сообщение следует просто отбрасывать, возможно указывая это в системном журнале, если частота получения Map-Reply указывает вредоносный трафик.

8.4. Обработка в Map-Resolver

При получении инкапсулированного Map-Request распознаватель Map-Resolver декапсулирует вложенное сообщение и ижет запрошенный EID в локальной базе отображений (статической или полученной от связанных ETR, если Map-Resolver служит также посредничающим Map-Server). При наличии записи распознаватель возвращает LISP Map-Reply с найденным отображением.

Если у Map-Resolver нет записи отображения и распознаватель может определить, что EID нет в базе данных отображений (например, при использовании LISP-ALT у Map-Resolver может быть таблица пересылки ALT, охватывающая все пространство EID), он сразу же возвращает Negative Map-Reply с кодом действия Natively-Forward и 15-минутным TTL. Для минимизации числа кэшированных негативных записей, необходимых для ITR, распознавателю следует возвращать наименее конкретный префикс, соответствующий исходному запросу, но не соответствующий ни одному из EID-Prefix, наличие которых известно поддерживающей LISP инфраструктуре.

Если Map-Resolver не может узнать, существует ли EID, ему нужно переслать Map-Request другому устройству, у которого может быть больше сведений о запрошенном EID. Для этого он пересылает неинкапсулированное сообщение Map-Request с RLOC отправителя исходного ITR в систему баз данных отображений. Используя LISP-ALT, Map-Resolver подключается к сети ALT и передаёт Map-Request следующему узлу (hop) ALT, найденному среди соседей ALT BGP. Map-Resolver не передаёт ITR никакого отклика, поэтому в RLOC источника указывается этот ITR, ETR или Map-Server, получающий Map-Request через ALT и отвечающий напрямую маршрутизатору ITR.

8.4.1. Операции Anycast

Для Map-Resolver можно настроить использование anycast, когда один адрес назначается нескольким Map-Resolver и распространяется через маршрутизацию IGP для упрощения работы каждого ITR с более близким Map-Resolver.

ETR могут иметь anycast-адреса RLOC, зарегистрированные как часть их RLOC-Set в Mapping System. Однако регистрация должна использовать их уникальные адреса RLOC, разные ключи аутентификации или xTR-ID, чтобы различать защищённые связи с Map-Server.

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

Анализ угроз для LISP приведён в [RFC7835]. Здесь рассматриваются вопросы безопасности, связанные с применением LISP в средах, подобных описанным в параграфе 1.1, где соблюдаются указанные ниже допущения.

1. Mapping System защищена и является доверенной в плане безопасности, поэтому считается доверенным элементом.

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

3. Должно быть реализовано расширение LISP-SEC [RFC9303]. Сетевым операторам следует внимательно оценить применимость модели угроз LISP-SEC к их варианту применения и развёртыванию. Если оператор решить игнорировать те или иные рекомендации, ему следует убедиться в осознании связанных с этим рисков.

Обмен сообщениями Map-Request/Map-Reply злоумышленник может использовать для организации атак с усилением (amplification) или DoS-атак. Злоумышленники могут передавать Map-Request с высокой скоростью, чтобы перегрузить узлы LISP и увеличить число поддерживаемых узлом состояний или повысить нагрузку на CPU. Такие угрозы можно смягчить применением фильтрой и ограничителей скорости.

Обмен сообщениями Map-Request/Map-Reply для внедрения фиктивных отображений непосредственно в ITR EID-RLOC Map-Cache, что может привести к перенаправлению трафика злоумышленнику (см. [RFC7835]). Кроме того, действительные ETR в системе могут выполнять атаки с перезаявлением (overclaiming). В этом случае злоумышленник может заявить свой EID-Prefix, который больше префикса, принадлежащего ETR. Эту проблему можно решить с помощью протокола LISP-SEC [RFC9303], определяющего механизм аутентификации источников, защиты целостности, а также предотвращение MITM⁴-атак и перезаявления префиксов при обмене Map-Request/Map-Reply. Кроме того, зотя это и выходит за рамки защиты отдельного Map-Server или Map-Resolver, следует отметить, что LISP-SEC можно дополнить механизмами защиты инфраструктуры Mapping System. Например, LISP-ALT [RFC6836] на основе BGP может применять стандартные средства BGP, а LISP-DDT [RFC8111] задаёт свои механизмы защиты.

Для публикации полномочного отображения EID-RLOC на Map-Server с помощью сообщения Map-Register маршрутизатор ETR включает данные аутентификации AD, которые представляют собой код MAC для всего сообщения с использованием ключа, выведенного из заранее распространённого секрета. Реализациям следует поддерживать алгоритм HMAC-SHA256-128+HKDF-SHA256 [RFC5869]. Сообщение Map-Register защищено от replay-атак с участием человека (MITM). Однако сохраняется возможность атак, в который скомпрометрированный ETR может перезаявить префикс, которым он владеет, и зарегистрировать его на соответствующем Map-Server. Для смягчения таких атак, как отмечено в параграфе 8.2. Настройка EID-Prefix и регистрация ETR, Map-Server должен убедиться, что все EID-Prefix, регистрируемые ETR, соответствуют конфигурации, сохранённой на Map-Server.

Развёртывания, связанные с манипулированием сообщениями Map-Request и Map-Reply, а также перезаявлением EID-Prefix вредоносными ETR, должны отбрасывать сообщения плоскости управления LISP, не включающие материала LISP-SEC (бит S, EID-AD, OTK-AD, PKT-AD, см. раздел 3 в [RFC9303]).

Следует развёртывать механизмы шифрования, защиты приватности и предотвращения перехвата и фальсификации сообщений между маршрутизаторами xTRs, xTRs и Mapping System, а также между узлами, образующими Mapping System. Примерами таких механизмов могут служить DTLS [RFC9147] и lisp-crypto [RFC8061].

10. Вопросы приватности

Как отмечено в [RFC6973], вопросы приватности достаточно сложны и зависят от конкретного варианта применения протокола и развёртывания. В параграфе 1.1 [RFC9300] сказано, что LISP фокусируется на взаимодействии элементов через общедоступную сеть Internet при сохранении независимой адресации и топологии. Здесь рассматриваются угрозы приватности, создаваемые плоскостью управления LISP, на основе рекомендаций приведённых в [RFC6973].

LISP может применять долгоживущие идентификаторы (EID), которые связаны с перемещаемыми узлами. Такие идентификаторы привязываются к RLOC узлов. Адреса RLOC представляют топологическое размещение относительно конкретных развёртываний LISP. Кроме того, сопоставления EID с RLOC обычно считаются общедоступными сведениями внутри развёртывания LISP, где сообщения плоскости управления не шифруются и могут быть перехвачены при отправке сообщений Map-Request соответствующим Map-Resolver или Map-Register соответствующим Map-Server.

В этом контексте злоумышленник может сопоставить EID с RLOC и отслеживать топологическое размещение и перемещения соответствующего пользователя. Это может быть реализовано злоумышленниками вне пути (off-path), если они аутентифицированы, через запросы к Mapping System. Развёртывания, для которых такая угроза значима, могут использовать списки контроля доступа или более строгие механизмы аутентификации [ECDSA-AUTH] в Mapping System, чтобы доступ к сведениям получали лишь уполномоченные пользователи (минимизация данных). Применение эфемерных EID [EID-ANONYMITY] для обеспечения анонимности является другим механизмом предотвращения отслеживания.

11. Отличия от RFC 6830 и RFC 6833

Из соображений реализации в [RFC6830] и [RFC6833] были внесены перечисленные ниже изменения.

• 16-битовое поле Key ID в сообщениях Map-Register и Map-Notify, определённое в [RFC6830], было разделено на два 8-битовых поля – Key ID и Algorithm ID. Это изменение относится и к сообщению Map-Notify-Ack, заданному в этом документе (5.6. Формат сообщения Map-Register, 5.7. Формат сообщений Map-Notify и Map-Notify-Ack).

• В этом документе определено сообщение Map-Notify-Ack для обеспечения надёжности доставки Map-Notify. Получатель Map-Notify должен передавать в ответ сообщение Map-Notify-Ack. Серверы Map-Server, являющиеся отправителями Map-Notify, должны держать содержимое Map-Notify в очереди, пока не будет получено сообщение Map-Notify-Ack со значением nonce из этого Map-Notify. Отметим, что реализации Map-Notify-Ack уже имелись до выхода этого документа.

• В этом документе применяется код для сообщений Map-Referral из спецификации LISP-DDT [RFC8111], указывающий, что Map-Server должен передавать финальное сообщение Map-Referral, когда он участвует в процедурах LISP-DDT Mapping System.

• Добавлены флаги L и D для сообщений Map-Request (5.3. Сообщение EID-RLOC UDP Map-Request).

• Добавлены флаги S, I, E, T, a, R, M для сообщений Map-Register (5.6. Формат сообщения Map-Register).

• Поля nonce и Authentication Data в сообщении Map-Register ведут себя по-разному (5.6. Формат сообщения Map-Register).

• Этот документ добавляет два кода действий в EID-Record сообщений Map-Reply, Map-Register, Map-Notify и Map-Notify-Ack – Drop/Policy-Denied и Drop/Auth-Failure (5.4. Формат сообщения Map-Reply).

12. Взаимодействие с IANA

В этом разделе приведены рекомендации для IANA по части регистрации значений, связанных с этой спецификацией плоскости управления LISP, в соответствии с BCP 26 [RFC8126].

• Значения из реестра LISP IANA не следует выделять для целей, не связанных с маршрутизацией и транспортными протоколами LISP.

• Далее используются заданные в BCP 26 [RFC8126] процедуры Specification Required, IETF Review, Experimental Use, First Come First Served.

В LISP имеется 3 пространства регистрируемых имён (см. ниже) in LISP (см. [RFC9299].

12.1. Номера портов LISP UDP

Агентство IANA выделило номер порта UDP 4342 для плоскости управления LISP и обновило описание этого порта, как показано в таблице 2

Таблица 2.

 

Имя службы	Номер порта	Транспортный протокол	Описание	Документ
lisp-control	4342	udp	Пакеты управления LISP	RFC 9301

 

12.2. Коды типа пакетов LISP

Агенство IANA теперь полномочно определять типы пакетов LISP, поэтому в реестре ссылки на [RFC6830] заменены указанием этого документа.

На основе опыта развёртывания, связанного с [RFC6830], в этом документе определено сообщение Map-Notify-Ack (тип 5), включённое в реестр, как показано в таблице 3.

Таблица 3.

 

Сообщение	Код	Документ
LISP Map-Notify-Ack	5	RFC 9301

 

12.3. Коды LISP Map-Reply EID-Record Action

Новые значения ACT могут выделяться по процедуре IETF Review или IESG Approval. Четыре значения уже были выделены в [RFC6830]. Агентство IANA заменило ссылки на [RFC6830] указанием этого документа. Данная спецификация изменила имя для действия с кодом 3 с Drop на Drop/No-Reason. Новые действия и значения ACT указаны в таблице 4.

Таблица 4. Значения LISP Map-Reply Action.

Значение	Действие	Описание	Документ
4	Drop/Policy-Denied	Пакет, соответствующий этой записи Map-Cache отброшен, поскольку целевой EID запрещён правилами xTR или Mapping System.	RFC 9301
5	Drop/Auth-Failure	Пакет, соответствующий этой записи Map-Cache отброшен, поскольку сообщение Map-Request для целевого EID не прошло проверку подлинности в xTR или Mapping System.	RFC 9301

В LISP имеется множество флагов и резервных полей, таких как поля и флаги заголовка LISP [RFC9300]. Новые флаги для этих полей могут быть реализованы по процедуре IETF Review или IESG Approval, но не обязательно будут управляться IANA.

12.4. Коды LISP Address Type

Канонический формат адресов LISP (LISP Canonical Address Format или LCAF) [RFC8060] имеет 8-битовое поле Type, указывающее кодирование LISP для семейства адресов AFI = 16387. Кодирование LCAF применяется в особых случаях, когда нужны разные типы адресов в EID-Record и RLOC-Record.

Для типов LCAF используется реестр LISP Canonical Address Format (LCAF) Types, для которого применяется процедура Specification Required [RFC8126]. Исходные значения и дополнительные сведения даны в [RFC8060].

Реестр LISP Address Type Codes, запрошенный [RFC6830], больше не требуется и этот документ закрывает его.

12.5. Номера LISP Algorithm ID

В [RFC6830] был представлен запрос на реестр LISP Key ID Numbers. В соответствии с этим документом агентство IANA переименовало этот реестр в LISP Algorithm ID Numbers и указало этот документ как ссылку на реестр.

Определённые этой спецификацией значения Algorithm ID, применяемые во всех типах пакетов с полем Algorithm ID, указаны в таблице 5.

Таблица 5.

 

Имя	Номер	MAC	KDF
Нет	0	Нет	none
HMAC-SHA-1-96-None	1	[RFC2404]	none
HMAC-SHA-256-128-None	2	[RFC4868]	none
HMAC-SHA256-128+HKDF-SHA256	3	[RFC4868]	[RFC4868]

 

Номера выделяются из диапазона от 0 до 255 в порядке поступления запросов (First Come First Served).

12.6. Битовые флаги LISP

Этот документ запрашивает у IANA создание реестра для выделения битов в нескольких заголовках сообщений плоскости управления LISP, а именно, Map-Request, Map-Reply, Map-Register, Encapsulated Control, а также записей EID-Record и RLOC-Record. Реестр следует назвать LISP Control Plane Header Bits и создать в нем субреестры для каждого сообщения и записи EID-Record. Имена этих субреестров указаны ниже вместе с форматом и выделенными этим документом битами. Для выделения дополнительных битов требуется спецификация в соответствии с правилами [RFC8126].

Субреестр Map-Request Header Bits (5.2. Формат сообщения Map-Request).

    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=1 |A|M|P|S|p|s|R|R|  Rsvd   |L|D|   IRC   | Record Count  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Таблица 6. Биты заголовка LISP Map-Request.

 

Имя	Имя IANA	Номер бита	Описание
A	Map-Request-A	4	Флаг полномочности
M	Map-Request-M	5	Флаг наличия данных отображения
P	Map-Request-P	6	Флаг запроса RLOC-Probe
S	Map-Request-S	7	Флаг запрошенного Map-Request (SMR)
p	Map-Request-p	8	Флаг Proxy-ITR
s	Map-Request-s	9	Флаг вызванного запрошенного Map-Request
L	Map-Request-L	17	Флаг локального xTR
D	Map-Request-D	18	Флаг отказа от Map-Reply

 

Субреестр Map-Reply Header Bits (5.4. Формат сообщения Map-Reply).

    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=2 |P|E|S|          Reserved               | Record Count  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Таблица 7. Биты заголовка LISP Map-Reply.

 

Имя	Имя IANA	Номер бита	Описание
P	Map-Reply-P	4	Флаг RLOC-Probe
E	Map-Reply-E	5	Флаг Echo-Nonce Capable
S	Map-Reply-S	6	Флаг Security

 

Субреестр Map-Register Header Bits (5.6. Формат сообщения Map-Register).

    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=3 |P|S|I|        Reserved       |E|T|a|R|M| Record Count  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Таблица 8. Биты заголовка LISP Map-Register.

 

Имя	Имя IANA	Номер бита	Описание
P	Map-Register-P	4	Флаг Proxy Map-Reply
S	Map-Register-S	5	Флаг поддержки LISP-SEC
I	Map-Register-I	6	Флаг наличия xTR-ID

 

Субреестр Encapsulated Control Message (ECM) Header Bits (5.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=8 |S|D|E|M|            Reserved                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Таблица 9. Биты заголовка LISP Encapsulated Control Message (ECM).

 

Имя	Имя IANA	Номер бита	Описание
S	ECM-S	4	Флаг Security
D	ECM-D	5	Флаг LISP-DDT
E	ECM-E	6	Флаг пересылки ETR
M	ECM-M	7	Флаг назначения Map-Server

 

Субреестр EID-Record Header Bits (5.4. Формат сообщения Map-Reply).

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Таблица 10. Биты заголовка LISP EID-Record.

 

Имя	Имя IANA	Номер бита	Описание
A	EID-Record-A	19	Флаг полномочности

 

Субреестр RLOC-Record Header Bits (5.4. Формат сообщения Map-Reply).

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Unused Flags     |L|p|R|           Loc-AFI             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Таблица 11. Биты заголовка LISP RLOC-Record.

 

Имя	Имя IANA	Номер бита	Описание
L	RLOC-Record-L	13	Флаг локального RLOC
p	RLOC-Record-p	14	Флаг RLOC-Probe Reply
R	RLOC-Record-R	15	Флаг RLOC Reachable

 

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

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

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://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, DOI 10.17487/RFC2404, November 1998, <https://www.rfc-editor.org/info/rfc2404>.

[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, “Randomness Requirements for Security”, BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.

[RFC4868] Kelly, S. and S. Frankel, “Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec”, RFC 4868, DOI 10.17487/RFC4868, May 2007, <https://www.rfc-editor.org/info/rfc4868>.

[RFC5869] Krawczyk, H. and P. Eronen, “HMAC-based Extract-and-Expand Key Derivation Function (HKDF)”, RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/info/rfc5869>.

[RFC6833] Fuller, V. and D. Farinacci, “Locator/ID Separation Protocol (LISP) Map-Server Interface”, RFC 6833, DOI 10.17487/RFC6833, January 2013, <https://www.rfc-editor.org/info/rfc6833>.

[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, “UDP Usage Guidelines”, BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos, Ed., “The Locator/ID Separation Protocol (LISP)”, RFC 9300, DOI 10.17487/RFC9300, October 2022, <https://www.rfc-editor.org/info/rfc9300>.

[RFC9302] Iannone, L., Saucez, D., and O. Bonaventure, “Locator/ID Separation Protocol (LISP) Map-Versioning”, RFC 9302, DOI 10.17487/RFC9302, October 2022, <https://www.rfc-editor.org/info/rfc9302>.

[RFC9303] Maino, F., Ermagan, V., Cabellos, A., and D. Saucez, “Locator/ID Separation Protocol Security (LISP-SEC)”, RFC 9303, DOI 10.17487/RFC9303, October 2022, <https://www.rfc-editor.org/info/rfc9303>.

[RFC9304] Boucadair, M. and C. Jacquenet, “Locator/ID Separation Protocol (LISP): Shared Extension Message and IANA Registry for Packet Type Allocations”, RFC 9304, DOI 10.17487/RFC9304, October 2022, <https://www.rfc-editor.org/info/rfc9304>.

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

[AFN] IANA, “Address Family Numbers”, <http://www.iana.org/assignments/address-family-numbers/>.

[ECDSA-AUTH] Farinacci, D. and E. Nordmark, “LISP Control-Plane ECDSA Authentication and Authorization”, Work in Progress, Internet-Draft, draft-ietf-lisp-ecdsa-auth-09, 11 September 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-ecdsa-auth-09>.

[EID-ANONYMITY] Farinacci, D., Pillay-Esnault, P., and W. Haddad, “LISP EID Anonymity”, Work in Progress, Internet-Draft, draft-ietf-lisp-eid-anonymity-13, 11 September 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-eid-anonymity-13>.

[EID-MOBILITY] Portoles, M., Ashtaputre, V., Maino, F., Moreno, V., and D. Farinacci, “LISP L2/L3 EID Mobility Using a Unified Control Plane”, Work in Progress, Internet-Draft, draft-ietf-lisp-eid-mobility-10, 10 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-eid-mobility-10>.

[GTP-3GPP] 3GPP, “General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U)”, TS.29.281, June 2022, <https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1699>.

[INTAREA-ILA] Herbert, T. and P. Lapukhov, “Identifier-locator addressing for IPv6”, Work in Progress, Internet-Draft, draft-herbert-intarea-ila-01, 5 March 2018, <https://datatracker.ietf.org/doc/html/draft-herbert-intarea-ila-01>.

[LISP-MN] Farinacci, D., Lewis, D., Meyer, D., and C. White, “LISP Mobile Node”, Work in Progress, Internet-Draft, draft-ietf-lisp-mn-12, 24 July 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-mn-12>.

[LISP-PUBSUB] Rodriguez-Natal, A., Ermagan, V., Cabellos-Aparicio, A., Barkai, S., and M. Boucadair, “Publish/Subscribe Functionality for LISP”, Work in Progress, Internet-Draft, draft-ietf-lisp-pubsub-09, 28 June 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-pubsub-09>.

[NVO3-VXLAN-GPE] Maino, F., Ed., Kreeger, L., Ed., and U. Elzur, Ed., “Generic Protocol Extension for VXLAN (VXLAN-GPE)”, Work in Progress, Internet-Draft, draft-ietf-nvo3-vxlan-gpe-12, 22 September 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-nvo3-vxlan-gpe-12>.

[OPSEC-ICMP-FILTER] Gont, F., Gont, G., and C. Pignataro, “Recommendations for filtering ICMP messages”, Work in Progress, Internet-Draft, draft-ietf-opsec-icmp-filtering-04, 3 July 2013, <https://datatracker.ietf.org/doc/html/draft-ietf-opsec-icmp-filtering-04>.

[RFC1035] Mockapetris, P., “Domain names – implementation and specification”, STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.

[RFC1071] Braden, R., Borman, D., and C. Partridge, “Computing the Internet checksum”, RFC 1071, DOI 10.17487/RFC1071, September 1988, <https://www.rfc-editor.org/info/rfc1071>.

[RFC2890] Dommety, G., “Key and Sequence Number Extensions to GRE”, RFC 2890, DOI 10.17487/RFC2890, September 2000, <https://www.rfc-editor.org/info/rfc2890>.

[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., “Report from the IAB Workshop on Routing and Addressing”, RFC 4984, DOI 10.17487/RFC4984, September 2007, <https://www.rfc-editor.org/info/rfc4984>.

[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, “The Locator/ID Separation Protocol (LISP)”, RFC 6830, DOI 10.17487/RFC6830, January 2013, <https://www.rfc-editor.org/info/rfc6830>.

[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, “The Locator/ID Separation Protocol (LISP) for Multicast Environments”, RFC 6831, DOI 10.17487/RFC6831, January 2013, <https://www.rfc-editor.org/info/rfc6831>.

[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, “Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites”, RFC 6832, DOI 10.17487/RFC6832, January 2013, <https://www.rfc-editor.org/info/rfc6832>.

[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, “Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)”, RFC 6836, DOI 10.17487/RFC6836, January 2013, <https://www.rfc-editor.org/info/rfc6836>.

[RFC6837] Lear, E., “NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database”, RFC 6837, DOI 10.17487/RFC6837, January 2013, <https://www.rfc-editor.org/info/rfc6837>.

[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, “Privacy Considerations for Internet Protocols”, RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.

[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, “Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks”, RFC 7348, DOI 10.17487/RFC7348, August 2014, <https://www.rfc-editor.org/info/rfc7348>.

[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, “Locator/ID Separation Protocol (LISP) Threat Analysis”, RFC 7835, DOI 10.17487/RFC7835, April 2016, <https://www.rfc-editor.org/info/rfc7835>.

[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, “LISP Canonical Address Format (LCAF)”, RFC 8060, DOI 10.17487/RFC8060, February 2017, <https://www.rfc-editor.org/info/rfc8060>.

[RFC8061] Farinacci, D. and B. Weis, “Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality”, RFC 8061, DOI 10.17487/RFC8061, February 2017, <https://www.rfc-editor.org/info/rfc8061>.

[RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. Smirnov, “Locator/ID Separation Protocol Delegated Database Tree (LISP-DDT)”, RFC 8111, DOI 10.17487/RFC8111, May 2017, <https://www.rfc-editor.org/info/rfc8111>.

[RFC8378] Moreno, V. and D. Farinacci, “Signal-Free Locator/ID Separation Protocol (LISP) Multicast”, RFC 8378, DOI 10.17487/RFC8378, May 2018, <https://www.rfc-editor.org/info/rfc8378>.

[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, “Segment Routing Architecture”, RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.

[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, “The Datagram Transport Layer Security (DTLS) Protocol Version 1.3”, RFC 9147, DOI 10.17487/RFC9147, April 2022, <https://www.rfc-editor.org/info/rfc9147>.

[RFC9299] Cabellos, A. and D. Saucez, Ed., “An Architectural Introduction to the Locator/ID Separation Protocol (LISP)”, RFC 9299, DOI 10.17487/RFC9299, October 2022, <https://www.rfc-editor.org/info/rfc9299>.

[RFC9305] Maino, F., Ed., Lemon, J., Agarwal, P., Lewis, D., and M. Smith, “Locator/ID Separation Protocol (LISP) Generic Protocol Extension”, RFC 9305, DOI 10.17487/RFC9305, October 2022, <https://www.rfc-editor.org/info/rfc9305>.

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

Авторы исходного документа благодарны Greg Schudel, Darrel Lewis, John Zwiebel, Andrew Partan, Dave Meyer, Isidor Kouvelas, Jesper Skriver и участникам почтовой конференции lisp@ietf.org за их отклики и полезные предложения.

Отдельная благодарность Noel Chiappa за обширную работу и размышления о кэшировании в Map-Resolver.

Нынешние авторы выражают свою искреннюю благодарность людам, которые помогли провести LISP через процедуры Standards Track в IETF. Это Joel Halpern, Luigi Iannone, Deborah Brungard, Fabio Maino, Scott Bradner, Kyle Rose, Takeshi Takahashi, Sarah Banks, Pete Resnick, Colin Perkins, Mirja Kühlewind, Francis Dupont, Benjamin Kaduk, Eric Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper, Suresh Krishnan, Alberto Rodriguez-Natal, Vina Ermagan, Mohamed Boucadair, Brian Trammell, Sabrina Tanamal, John Drake. Их влад существенно улучшил безопасность, расширяемость и отказоустойчивость архитектуры и протоколов LISP.

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

Dino Farinacci

lispers.net

San Jose, CA

United States of America

Email: farinacci@gmail.com

 

Fabio Maino

Cisco Systems

San Jose, CA

United States of America

Email: fmaino@cisco.com

 

Vince Fuller

vaf.net Internet Consulting

Email: vince.fuller@gmail.com

 

Albert Cabellos (editor)

Universitat Politecnica de Catalunya

c/ Jordi Girona s/n

08034 Barcelona

Spain

Email: acabello@ac.upc.edu

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

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

nmalykh@protokols.ru

---

Internet Engineering Task Force (IETF)                      M. Boucadair
Request for Comments: 9304                                  C. Jacquenet
Obsoletes: 8113                                                   Orange
Category: Standards Track                                   October 2022
ISSN: 2070-1721

Locator/ID Separation Protocol (LISP): Shared Extension Message and IANA Registry for Packet Type Allocations

LISP – общий тип сообщения для расширений и реестр IANA для типов пакетов

PDF

Аннотация

В этом документе определён общий (shared) тип сообщения протокола разделения локаторов и идентификаторов (Locator/ID Separation Protocol или LISP) для будущих расширений и проведения экспериментов без использования кодов типа пакетов LISP в каждом расширении.

Документ отменяет RFC 8113.

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

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG². Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

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

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

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

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

Реестр IANA LISP Packet Types (5. Взаимодействие с IANA) служит для упрощения отслеживания типов сообщений LISP.

Поскольку пространство типов [RFC9301] ограничено и требуется проводить эксперименты для оценки новых расширений LISP, в этом документе определяется общий тип сообщения для расширений LISP и описана процедура регистрации субтипов расширений LISP (3. Тип общего сообщения для расширений LISP). Для будущих расширений предназначен единственный код типа сообщений LISP, а для однозначной идентификации данного расширения применяется субтип. Идентификаторы субтипов выбирают авторы спецификаций LISP с новыми расширениями.

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

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

3. Тип общего сообщения для расширений LISP

На рисунке 1 показан базовый формат общего сообщения для расширений LISP. Поле типа должно иметь значение 15 (см. 5. Взаимодействие с IANA).

 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=15|        Sub-type       |   extension-specific          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
//                    extension-specific                       //
//                                                             //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 1. Общий тип сообщения для расширений.

В поле Sub-type указывается уникальный идентификатор, который должен регистрироваться в IANA (5.2. Субтипы).

Структуру extension-specific задаёт спецификация соответствующего расширения.

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

Этот документ не добавляет соображений безопасности к рассмотренным в [RFC9301].

5. Взаимодействие с IANA

5.1. Типы пакетов LISP

Агентство IANA создало реестр LISP Packet Types со значениями от 0 до 15.

Значения могут выделяться по процедуре Standards Action [RFC8126]. Документ с запросом нового LISP Packet Type может указывать предпочтительное значение в соответствующих разделах IANA.

Агентство IANA заменило ссылку на RFC 8113 указанием этого документа с обновлением таблицы, как показано ниже.

Таблица 1. Старая таблица.

 

Сообщение	Код	Документ
LISP Shared Extension Message	15	[RFC8113]

 

Таблица 2. Новая таблица.

 

Сообщение	Код	Документ
LISP Shared Extension Message	15	RFC 9304

 

5.2. Субтипы

Агентство IANA создало реестр LISP Shared Extension Message Type Sub-types. Реестр обновлён заменой ссылки на RFC 8113 указанием номера этого документа.

Значения субтипов из диапазона от 0 до 1023 выделяются по процедуре Standards Action. Эти значения предназначены на случай исчерпания реестра LISP Packet Types.

Значения от 1024 до 4095 выделяются в порядке запросов (First Come, First Served или FCFS). Процедура регистрации заключается в предоставлении IANA желаемого кода и контактных данных, краткого описания (вместе с сокращением, если оно нужно) предполагаемого применения сообщения.

6. Отличия от RFC 8113

• Статус Experimental заменён на Standards Track.

• Явно указано, что общее расширение применяется в двумя целями – расширение пространства типов и проведение экспериментов по оценке новых расширений LISP.

• Удалены указатели на некоторые примеры, иллюстрирующие применение общего сообщения расширений для расширения протокола LISP.

• Агентство IANA обновило реестры IANA LISP Packet Types и LISP Shared Extension Message Type Sub-types, указав ссылку на этот документ вместо RFC 8113.

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

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, Ed., “Locator/ID Separation Protocol (LISP) Control Plane”, RFC 9301, DOI 10.17487/RFC9301, October 2022, <https://www.rfc-editor.org/info/rfc9301>.

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

Эта работа частично финансировалась в рамках проекта ANR LISP-Lab #ANR-13-INFR-009-X.

Большое спавибо Luigi Iannone, Dino Farinacci, Alvaro Retana за рецензию.

Спасибо Geoff Huston, Brian Carpenter, Barry Leiba, Suresh Krishnan за рецензию.

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

Mohamed Boucadair

Orange

35000 Rennes

France

Email: mohamed.boucadair@orange.com

 

Christian Jacquenet

Orange

35000 Rennes

France

Email: christian.jacquenet@orange.com

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

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

nmalykh@protokols.ru

---

Internet Engineering Task Force (IETF)                        L. Iannone
Request for Comments: 9302                    Huawei Technologies France
Obsoletes: 6834                                                D. Saucez
Category: Standards Track                                          Inria
ISSN: 2070-1721                                           O. Bonaventure
                                        Universite catholique de Louvain
                                                            October 2022

Locator/ID Separation Protocol (LISP) Map-Versioning

Версии отображений протокола LISP

PDF

Аннотация

Этот документ описывает механизм версий отображений (Map-Versioning) протокола LISP¹, который позволяет указывать в пакетах отображения идентификаторов конечных точек на локаторы маршрутизации (Endpoint-ID-to-Routing-Locator или EID-RLOC), применяемые при инкапсуляции пакетов данных LISP. Этот подход основан на связывании номера версии с отображениями EID-RLOC и доставки этого номера в заголовке LISP пакетов, инкапсулированных в LISP. Версии отображений LISP особенно полезны для информирования входных (Ingress Tunnel Router или ITR) и выходных (Egress Tunnel Router или ETR) маршрутизаторов о смене версии отображения, применяемого при инкапсуляции пакетов. Механизм необязателен и не мешает не поддерживающим его реализациям, поскольку в заголовках LISP и записях отображений биты Map-Versioning можно без опаски игнорировать в маршрутизаторах ITR и ETR, не поддерживающих или не желающих использовать этот механизм.

Этот документ отменяет RFC 6834, где была задана исходная, экспериментальная спецификация механизмов.

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

Документ относится к категории Internet Standards Track.

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

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

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

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

Этот документ описывает механизм Map-Versioning, используемый для информирования об изменениях сопоставлений идентификаторов конечных точек с локаторами маршрутизаторов (EID-RLOC), применяемых в контексте протокола LISP [RFC9300] [RFC9301] для инкапсуляции пакетов. Механизм не препятствует работе входных (Ingress) и выходных (Egress) маршрутизаторов туннелей (xTRs), не поддерживающих или не использующих эту функциональность. Архитектура LISP описана [RFC9299] и предполагается знакомство читателя с этим вводным документом.

Этот документ отменяет [RFC6834], где была задана исходная, экспериментальная спецификация механизмов.

Базовым механизмом является связывание номера версии (Map-Version) с каждым отображением LISP EID-RLOC и доставка этого номера в связанном с LISP заголовке. При смене отображения ему назначается новый номер версии. Сменой сопоставления EID-RLOC может быть изменение набора RLOC, такое как добавление, удаление, изменение приоритета или веса одного или нескольких RLOC.

При использовании Map-Versioning пакеты данных с инкапсуляцией LISP содержат номера версий двух отображений, используемых для выбора RLOC во внешнем заголовке (RLOC источника и получателя). Эти сведения имеют два применения.

1. Map-Versioning позволяет выходному маршрутизатору туннеля (Egress Tunnel Router или ETR), принимающему пакет, знать, использует ли входной маршрутизатор туннеля (Ingress Tunnel Router или ITR) последнюю версию отображения для EID получателя. Если это не так, ETR может напрямую передать Map-Request с обновлённым отображением маршрутизатору ITR для информирования о последней версии. ETR может также запросить у ITR инициирование Map-Request для получения последнего отображения путём отправки сообщения SMR (Solicit Map-Request). Оба варианта определены в [RFC9301].

2. Map-Versioning позволяет ETR, принимающему пакет, знать, содержится ли в его EID-RLOC Map-Cache последнее отображение для EID источника. Если это не так, может быть передан Map-Request.

Вопросы развёртывания LISP Map-Versioning рассмотрены в разделе 9. Вопросы внедрения, а преимущества Map-Versioning в некоторых распространённых вариантах применения LISP описаны в Приложении A.

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

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

3. Определения терминов

В этом документе используются термины, определённые в основной спецификации LISP ([RFC9300] и [RFC9301]). Ниже определены термины, связанные с механизмом Map-Versioning. В документе применяется порядок битов big-endian (сначала старший).

Map-Version number – номер версии отображения

12-битовое целое число без знака, назначенное отображению EID-RLOC и указывающее номер версии (раздел 6).

Null Map-Version – нулевая (пустая) версия отображения

Номер Map-Version со значением 0x000, который применяется для информирования о том, что свойство Map-Version не используется и отображению EID-RLOC не назначается номер версии (параграф 6.1).

Dest Map-Version number – номер версии отображения у получателя

Map-Version для отображения в EID-RLOC Map-Cache, используемого ITR при выборе RLOC, помещаемого в поле Destination Routing Locator внешнего заголовка IP пакетов с инкапсуляцией LISP (параграф 7.1).

Source Map-Version number – номер версии отображения у отправителя

Map-Version для отображения в EID-to-RLOC Database, используемого ITR при выборе RLOC для включения в поле Source Routing Locator внешнего заголовка IP пакетов с инкапсуляцией LISP (параграф 7.2).

4. Заголовок LISP и номера Map-Version

Для работы с номерами версий заголовок LISP передаёт значения Source Map-Version и Dest Map-Version. Это делается путём установки бита V в заголовке LISP, как описано в [RFC9300] и показано на рисунке 1. Разрешённые комбинации флагов с установленным (1) битом V описаны в [RFC9300]. Номера версий не требуется передавать во всех пакетах с инкапсуляцией LISP. Формат заголовка LISP при установленном флаге V показан на рисунке 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|R|K|K|  Source Map-Version   |   Dest Map-Version    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Instance ID/Locator-Status-Bits               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 1. Пример заголовка LISP при использовании Map-Versioning.

Source Map-Version number (12 битов)

См. раздел 3. Определения терминов.

Dest Map-Version number (12 битов)

См. раздел 3. Определения терминов.

5. Запись отображения и Map-Version

Чтобы приспособиться к этому механизму, записи Map Record, доставляемые в сообщениях Map-Request, Map-Reply, Map-Register должны содержать номер Map-Version. Map Record (см. [RFC9301]) приводится здесь в качестве примера на рисунке 2. Этот документ не меняет назначение сообщений Map-Request, Map-Reply, Map-Register, они по-прежнему применяются в соответствии с [RFC9301].

     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
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   |                          Record TTL                           |
|   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R   | Locator Count | EID mask-len  | ACT |A|      Reserved         |
e   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c   | Rsvd  |  Map-Version Number   |       EID-Prefix-AFI          |
o   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r   |                          EID-Prefix                           |
d   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  /|    Priority   |    Weight     |  M Priority   |   M Weight    |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o |        Unused Flags     |L|p|R|           Loc-AFI             |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  \|                             Locator                           |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 2. Пример формата Map-Record.

Map-Version Number

Номер Map-Version для отображения, содержащегося в Record. Как указано в параграфе 6.1, это поле может иметь значение 0, указывающее, что с отображением не связано Map-Version.

Этот формат пакета совместим с xTR, не поддерживающими Map-Versioning, поскольку они могут просто игнорировать биты.

Map-Server, получивший неожиданный номер Map-Version (например, старый), должен отбросить сообщение без уведомления отправителя и следует внести соответствующую запись в журнал.

6. Номер EID-RLOC Map-Version

Номер EID-RLOC Map-Version представляется 12-битовым целым числом без знака. Номер версии назначается по отображениям, что означает разные номера у отображений, изменяемых независимо. Обновление версии (т. е. создание новой) должно увеличивать номер версии по сравнению с прежним (исключением является лишь Null Map-Version, как указано в конце параграфа 6.1. Null Map-Version).

Пространство номеров версий является кольцевым, при котором половина номеров будут меньше текущего номера Map-Version, а вторая половина – больше (новее). По сути, это порядковый номер, к которому применяется арифметика, описанная в [RFC1982]. Порядок позволяет по-разному реагировать на более старые и более новые номера Map-Version с отбрасыванием старых номеров и отправке Map-Request по новым (см. 7. Работа с номерами Map-Version). Предположим, что имеется два номера V1 и V2, отличных от Null Map-Version (6.1. Null Map-Version) и заданных 12 битами. Тогда для определения порядка этих номеров должны выполняться приведённые ниже процедуры (с соблюдением их порядка).

1. V1 = V2 - номера Map-Version совпадают.

2. V2 > V1, тогда и только тогда, когда 
   V2 > V1 И (V2 - V1) <= 2^(12-1)
   ИЛИ
   V1 > V2 И (V1 - V2) > 2^(12-1)

3. V1 > V2 в остальных случаях.

Для Map-Version = 69 номера Map-Version из диапазона [70; 69 + 2048] будут больше 69, а номера из диапазона [69 + 2049; (69 + 4095) mod 4096] – меньше чем 69.

Исходный номер Map-Version для нового отображения EID-RLOC следует задавать случайным, но недопустимо устанавливать значение Null Map-Version (0x000), поскольку этот номер имеет особое значение (см. параграф 6.1). Можно задавать начальный номер Map-Version в конфигурации.

При перезагрузке ETR будет использовать сопоставления, настроенные в его базе EID-RLOC. Если эти отображения имеют номер Map-Version, они будут применяться в соответствии с описанным в этом документе механизмом. ETR недопустимо автоматически создавать и назначать номера Map-Version для отображений в базе EID-RLOC.

6.1. Null Map-Version

Значение 0x000 (0) является особым номером Map-Version, указывающим, что на деле с отображением EID-RLOC не связано номера версии. Это значение применяется в особых случаях и называется Null Map-Version.

Запись отображений с номером Null Map-Version указывает, что с отображением не связано номера Map-Version. Это означает, что пакетам с инкапсуляцией LISP, адресованным в EID-Prefix, указанный отображением, недопустимо включать номер Map-Version (бит V сброшен – 0). Если ETR получает пакет с инкапсуляцией LISP и установленным битом V, когда исходное отображение в EID-RLOC Database имеет значение Null Map-Version, пакет должен отбрасываться без уведомления отправителя.

Null Map-Version может указываться в заголовке LISP как номер версии Source Map-Version (7.2. Обработка Map-Version источника), что указывает отсутствие сведений о версии отображения на сайте источника. Это означает, что при наличии отображения EID источника в EID-RLOC Map-Cache маршрутизатору ETR недопустимо сравнивать полученное значение Null Map-Version с содержимым EID-RLOC Map-Cache (параграф 7.2).

Особый смысл значения 0 для номера Map-Version означает, что при обновлении номера Map-Version в результате изменения содержимого отображения значение 0 должно пропускаться и взамен должно устанавливаться значение 1.

7. Работа с номерами Map-Version

Основная идея использования номеров Map-Version заключается в том, что при каждом изменении отображения (например, добавлении или удалении RLOC, смене веса в соответствии с правилами организации трафика, смене приоритета) или утрате на сайте LISP доступности одного или нескольких RLOC с локальной точки зрения (например, от IGP или при смене политики), сайт LISP назначает новый номер Map-Version. Действительным считается лишь последний номер Map-Version. Обновления отображений и соответствующих номеров Map-Version должны выполняться так, чтобы самая старая версия не могла быть спутана с последней (новой) по причине использования кольцевой нумерации. Для этого могут быть приняты простые меры, такие как обновление отображений лишь при условии использования для всего активного трафика последней версии или достаточно долгое ожидание, чтобы срок действия кэшированных записей LISP истёк (ожидание в течение времени не менее TTL, определённого в [RFC9301]).

ETR, получающий пакет LISP с номером Map-Version, выполняет указанные ниже проверки.

1. Проверяет, что ITR, передавший пакет, имеет актуальное отображение в своём EID-RLOC Map-Cache для EID получателя и корректно выполняет инкапсуляцию (см. 7.1. Обработка Map-Version получателя).

2. Для двухстороннего трафика проверяется, что отображение в EID-RLOC Map-Cache локального ETR для EID источника актуально (см. 7.2. Обработка Map-Version источника).

7.1. Обработка Map-Version получателя

Когда ETR получает пакет, номер Dest Map-Version отноится к отображению EID получателя, для которого ETR является RLOC. Это отображение является частью базы данных ETR EID-RLOC. Поскольку ETR уполномочен для отображения, он будет корректировать и обновлять номер Dest Map-Version. Номер версии должен проверяться, как указано ниже.

1. Пакет приходит с номером Dest Map-Version, сохраненным в EID-RLOC Database (обычный случай). Передавший пакет ITR имеет в своём кэше EID-RLOC Map-Cache актуальное отображение, поэтому иных действий не требуется.

2. Пакет приходит с номером Dest Map-Version новее (см. 6. Номер EID-RLOC Map-Version) сохранённого в EID-RLOC Database. Поскольку ETR уполномочен для сопоставлений, что означает корректность его номера отображения, номер версии в прибывшем пакете считается недействительным и пакет должен отбрасываться без уведомления отправителя. Следует также сделать запись об этом в системном журнале.

3. Пакет приходит с номером Dest Map-Version старее (см. 6. Номер EID-RLOC Map-Version) сохранённого в EID-RLOC Database. Это означает, что у передающего пакет ITR имеется устаревшее отображение в его EID-to-RLOC Map-Cache. ETR может обычным способом обработать инкапсулированную дейтаграмму в соответствии с [RFC9300], однако передающий пакет ITR должен быть проинформирован о доступности нового отображения с учётом правил ограничения скорости, заданных в [RFC9301]. Это осуществляется отправкой сообщения Map-Request маршрутизатору ITR, как описано в [RFC9301]. Одним из свойств, добавленных номерами Map-Version, является возможность блокировать трафик, не использующий последнюю версию отображения. Это возникает в случаях, когда ITR не обновил отображение, для которого ETR является полномочным, или в некоторых вариантах атак. В соответствии с правилами ограничения частоты передачи Map-Request из [RFC9301] после 10 повторов сообщения Map-Request передаются каждые 30 секунд. Если после первых 10 попыток номер Dest Map-Version в пакетах не обновился, маршрутизатору ETR следует отбрасывать пакеты со старым номером Map-Version. Операторы могут задать исключения для этого правила, но они выходят за рамки документа.

Правило для случая 3 может быть более строгим. Если время Record TTL для предыдущего отображения уже истекло, все пакеты со старым номером Map-Version должны отбрасываться без уведомления отправителя и отправки Map-Request. Такое действие разрешается, поскольку в случае, когда отображение с новым номером версии не менялось в течение Record TTL старого отображения, все записи в EID-RLOC Map-Cache маршрутизаторов ITR должны были уже устареть. Действительно, все ITR, передающие трафик, должны уже иметь обновлённые отображения в соответствии с [RFC9301].

Наличие в пакетах с инкапсуляцией LISP номера Dest Map-Version со значением Null Map-Version является нарушением протокола (см. 6.1. Null Map-Version).

7.2. Обработка Map-Version источника

Когда ETR принимает пакет, номер Source Map-Version относится к отображению для EID источника, для которого отправивший пакет ITR является полномочным. Если у ETR есть в EID-RLOC Map-Cache запись для EID источника, должна выполняться проверка с учётом указанных ниже обстоятельств.

1. Пакет приходит с номером Source Map-Version, сохраненным в EID-RLOC Database (обычный случай). ETR имеет в своём кэше EID-RLOC Map-Cache актуальное отображение, поэтому иных действий не требуется.

2. Пакет приходит с номером Source Map-Version новее (см. 6. Номер EID-RLOC Map-Version) сохранённого в локальном EID-RLOC Map-Cache. Это означает, что EID-RLOC Map-Cache у ETR устарел и его нужно обновить. Должно передаваться сообщение Map-Request, чтобы получить новое отображение для EID и сточника, с учётом правил ограничения скорости, описанных в [RFC9301].

3. Пакет приходит с номером Source Map-Version старее (см. 6. Номер EID-RLOC Map-Version) сохранённого в локальном EID-RLOC Map-Cache. Отметим, что при наличии отображения в EID-RLOC Map-Cache это означает, что было передано явное сообщение Map-Request и получено сообщение Map-Reply из полномочного источника. В такой ситуации пакет следует просто отбросить. Операторы могут задать исключения для этого правила, но они выходят за рамки документа.

Если у ETR нет записи в EID-RLOC Map-Cache для EID источника, номер Source Map-Version должен игнорироваться (см. Приложение A.1. Map-Versioning и односторонний трафик, где приведён пример такой ситуации).

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

Этот документ основан на спецификации и операциях плоскостей данных и управления LISP. Здесь применимо обсуждение вопросов безопасности из [RFC9300] и [RFC9301]. Номера Map-Version недопустимо применять в общедоступной сети Internet и они должны использоваться лишь в доверенных, изолированных средах. Тщательный анализ безопасности LISP приведён в [RFC7835].

Злоумышленники могут попытаться инициировать большое число Map-Request простой подделкой пакетов со случайными номерами Map-Version. Частота отправки Map-Request ограничена, как указано в [RFC9301]. При использовании Map-Version можно фильтровать пакеты с недействительными номерами до отправки Map-Request, что позволит снизить влияние DoS-атак, однако этого недостаточно для практической защиты от атак DDoS.

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

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

9. Вопросы внедрения

LISP требует от ETR одного сайта поддерживать идентичные отображения для данного EID-Prefix. Для Map-Versioning не требуется дополнительных механизмов синхронизации. Ясно, что все ETR должны возвращать одинаковые сопоставления, включая один номер Map-Version, поскольку в ином случае могут возникать несоответствия, создающие добавочный трафик управления, нестабильность и сбои.

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

Рассмотрим в качестве примера топологию, показанную на рисунке 3, где ITR A.1 в Domain A передаёт односторонний трафик в Domain B, а A.2 из Domain A обменивается в Domain B двухсторонним трафиком. В частности, ITR A.2 передаёт трафик ETR B, а ETR A.2 получает трафик от ITR B.

+-----------------+              +-----------------+
| Domain A        |              | Domain B        |
|       +---------+              |                 |
|       | ITR A.1 |---           |                 |
|       +---------+    \         +---------+       |
|                 |      ------->| ETR B   |       |
|                 |      ------->|         |       |
|       +---------+    /         |         |       |
|       | ITR A.2 |---      -----| ITR B   |       |
|       |         |       /      +---------+       |
|       | ETR A.2 |<-----        |                 |
|       +---------+              |                 |
|                 |              |                 |
+-----------------+              +-----------------+

Рисунок 3. Пример топологии.

Очевидно, что при использовании Map-Versioning оба маршрутизатора ITR A.1 и ITR A.2 из Domain A должны указывать одно значение, иначе ETR и Domain B начнёт передавать сообщения Map-Request.

Такая же проблемп может возникнуть и без Map-Versioning, например, если два ITR из Domain A будут передавать разные биты LSB. В этом случае трафик будет нарушаться, если ETR B не проверяет доступность, или ETR B начнёт передавать Map-Request для подтверждения каждого изменения доступности.

Пока LISP не предоставляет какого-либо конкретного механизма синхронизации, но предполагает, что синхронизация обеспечивается согласованной настройкой xTR. Это относится и к Map-Versioning. Если в будущем появится механизм синхронизации, Map-Versioning автоматически воспользуется им, поскольку это включено в формат Map Record, как описано в разделе 5. Запись отображения и Map-Version.

10. Взаимодействие с IANA

Этот документ не требует действий IANA.

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

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

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC9300] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos, Ed., “The Locator/ID Separation Protocol (LISP)”, RFC 9300, DOI 10.17487/RFC9300, October 2022, <https://www.rfc-editor.org/info/rfc9300>.

[RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, Ed., “Locator/ID Separation Protocol (LISP) Control Plane”, RFC 9301, DOI 10.17487/RFC9301, October 2022, <https://www.rfc-editor.org/info/rfc9301>.

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

[RFC1982] Elz, R. and R. Bush, “Serial Number Arithmetic”, RFC 1982, DOI 10.17487/RFC1982, August 1996, <https://www.rfc-editor.org/info/rfc1982>.

[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, “Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites”, RFC 6832, DOI 10.17487/RFC6832, January 2013, <https://www.rfc-editor.org/info/rfc6832>.

[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, “Locator/ID Separation Protocol (LISP) Map-Versioning”, RFC 6834, DOI 10.17487/RFC6834, January 2013, <https://www.rfc-editor.org/info/rfc6834>.

[RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, “Locator/ID Separation Protocol (LISP) Threat Analysis”, RFC 7835, DOI 10.17487/RFC7835, April 2016, <https://www.rfc-editor.org/info/rfc7835>.

[RFC9299] Cabellos, A. and D. Saucez, Ed., “An Architectural Introduction to the Locator/ID Separation Protocol (LISP)”, RFC 9299, DOI 10.17487/RFC9299, October 2022, <https://www.rfc-editor.org/info/rfc9299>.

Приложение A. Преимущества и применение Map-Versioning

В последующих параграфах обсуждаются различные аспекты и вариант применения Map-Versioning. Вопросы безопасности рассмотрены в разделе 8.

A.1. Map-Versioning и односторонний трафик

При использовании Map-Versioning заголвок LISP содержит номера Map-Version для отображений источника и получателя. Может возникнуть вопрос для случая одностороннего потока, например, как показано на рисунке 4, поскольку спецификация LISP не требует от ETR наличия отображения от EID источника.

+-----------------+            +-----------------+
| Domain A        |            | Domain B        |
|       +---------+            +---------+       |
|       | ITR A   |----------->| ETR B   |       |
|       +---------+            +---------+       |
|                 |            |                 |
+-----------------+            +-----------------+

Рисунок 4. Односторонний трафик между доменами LISP.

ITR способен включить номера версий источника и получателя в заголовок LISP, поскольку номер Source Map-Version имеется в его базе данных, а номер Dest Map-Version – в кэше.

ETR проверяет лишь номер Dest Map-Version, игнорируя номер Source Map-Version, как указано в заключительном предложении параграфа 7.2. Обработка Map-Version источника.

A.2. Map-Versioning и межсетевое взаимодействие Interworking

Версии отображений совместимы с межсетевым взаимодействием LISP между сайтами с поддержкой и без поддержки LISP, как описано в [RFC6832]. Межсетевое взаимодействие LISP определяет три метода взаимодействия между сайтами с поддержкой и без поддержки LISP – Proxy-ITR, LISP-NAT, Proxy-ETR, описанные ниже для Map-Versioning.

A.2.1. Map-Versioning и Proxy-ITR

+----------+                             +-------------+
| LISP     |                             | Без LISP    |
| Domain A |                             | Domain B    |
|  +-------+        +-----------+        |             |
|  | ETR A |<-------| Proxy-ITR |<-------|             |
|  +-------+        +-----------+        |             |
|          |                             |             |
+----------+                             +-------------+

Рисунок 5. Односторонний трафик из домена без LISP в домен LISP.

Назначением Proxy-ITR (PITR) является инкапсуляция трафика с сайта без поддержки LISP для доставки пакета одному из ETR сайта LISP (Рисунок 5). Этот случай очень похож на вариант с односторонним трафиком из Приложения A.1, поэтому к нему применимы те же правила.

Основное отличие состоит в том, что у Proxy-ITR нет никакого отображения, поскольку он просто инкапсулирует пакеты с сайта без LISP и не может поэтому предоставить Source Map-Version. В этом случае Proxy-ITR будет просто указывать Null Map-Version в качестве Source Map-Version, а принимающий ETR будет игнорировать это поле.

В этом примере LISP Domain A способен проверить, использует ли PITR последнее отображение. В поле Dest Map-Version Number заголовка LISP узел Proxy-ITR будет помещать номер версии отображения, используемого для инкапсуляции, а ETR A может использовать такое значение, как указано в параграфе 7. Работа с номерами Map-Version.

A.2.2. Map-Versioning и LISP-NAT

Механизм LISP-NAT основан на трансляции адресов немаршрутизируемых EID в маршрутизируемые EID без какой либо инкапсуляции, поэтому Map-Versioning в этом случае не применяется.

A.2.3. Map-Versioning и Proxy-ETR

Назначением Proxy-ETR (PETR) является декапсуляция трафика с сайта LISP для доставки пакетов на сайт без LISP (Рисунок 6). Одной из основных причин внедрения PETR является обход проверки индивидуальной пересылки по обратному пути (Unicast Reverse Path Forwarding).

+----------+                             +-------------+
| LISP     |                             | Без LISP    |
| Domain A |                             | Domain B    |
|  +-------+        +-----------+        |             |
|  | ITR A |------->| Proxy-ETR |------->|             |
|  +-------+        +-----------+        |             |
|          |                             |             |
+----------+                             +-------------+

Рисунок 6. Односторонний трафик между из домена LISP в домен без LISP.

У Proxy-ETR нет каких-либо отображений, поскольку он просто декапсулирует пакеты от сайта LISP. В этом случае ITR может указывать значение Map-Version или Null Map-Version в качестве номера Dest Map-Version, поскольку принимающий Proxy-ETR игнорирует это поле.

При такой настройке Proxy-ETR, просматривая номер Source Map-Version Number, может проверить наличие изменений отображения EID источника. Это полезно для проверки RLOC источника. В приведённом выше примере трафик из домена LISP инкапсулируется в LISP с использованием в качестве адреса отправителя RLOC домена. Proxy-ETR может извлечь отображение, связанное с доменом LISP и проверить поступление входящих пакетов с инкапсуляцией LISP от действительного RLOC. Изменение в RLOC-Set, который может применяться для адреса источника, может быть указано номером версии, при этом Proxy-ETR способен при необходимости запросить последнее отображение, как описано в параграфе 7.2. Обработка Map-Version источника.

A.3. Отключение и отзыв RLOC

Map-Versioning можно использовать для аккуратного завершения работы или отзыва конкретного RLOC. Это достигается путём создания нового отображения с обновлением номера Map-Version, где адрес RLOC, подлежащий исключению, будет анонсирован как недоступный (через флаг R в Map Record, см. [RFC9301]) без его фактического отключения.

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

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

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

Luigi Iannone

Huawei Technologies France

Email: luigi.iannone@huawei.com

 

Damien Saucez

Inria

2004 route des Lucioles – BP 93

Sophia Antipolis

France

Email: damien.saucez@inria.fr

 

Olivier Bonaventure

Universite catholique de Louvain

Email: olivier.bonaventure@uclouvain.be

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

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

nmalykh@protokols.ru

---

Internet Engineering Task Force (IETF)                      D. Farinacci
Request for Comments: 9300                                   lispers.net
Obsoletes: 6830                                                V. Fuller
Category: Standards Track                    vaf.net Internet Consulting
ISSN: 2070-1721                                                 D. Meyer
                                                               1-4-5.net
                                                                D. Lewis
                                                           Cisco Systems
                                                        A. Cabellos, Ed.
                                    Universitat Politecnica de Catalunya
                                                            October 2022

The Locator/ID Separation Protocol (LISP)

Протокол разделения локаторов и идентификаторов (LISP)

PDF

Аннотация

Этот документ описывает протокол плоскости данных для разделения локаторов и идентификаторов (Locator/ID Separation Protocol или LISP). LISP определяет два пространства имён – идентификаторы конечных точек (Endpoint Identifier или EID), указывающие конечные точки, и локаторы маршрутизации (Routing Locator или RLOC), которые указывают точки подключения к сети. При этом LISP эффективно разделяет управление и данные, что позволяет маршрутизаторам создавать наложенные сети. Маршрутизаторы с поддержкой LISP обмениваются инкапсулированными пакетами в соответствии с отображениями EID на RLOC, хранящимися в локальном кэше Map-Cache.

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

Этот документ отменяет RFC 6830.

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

Документ относится к категории Internet Standards Track.

Документ является результатом работы IETF¹ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG². Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.

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

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

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

Этот документ описывает LISP – протокол инкапсуляции, основанный на фундаментальной идее разделения топологического местоположения точки присоединения ксети и отождествления узла [CHIAPPA]. В результате LISP создаёт два пространства имён – идентификаторы конечных точек (EID), служащие для указания конечных хостов (например, узлов или виртуальных машин), и маршрутизируемых локаторов (RLOC), указывающих точки подключения к сети. LISP также задаёт функции для сопоставления между этими пространствами имён и инкапсуляции трафика от устройств, использующих немаршрутизируемые EID, для транспортировки через сетевую инфраструктуру, которая обеспечивает маршрутизацию и пересылку с использованием RLOC. Инкапсуляция LISP применяет динамическую форму туннелирования, где не требуется статическое обеспечение.

LISP является наложенным протоколом, отделяющим управление от данных и этот документ задаёт плоскость данных, а также способы обмена пакетами между маршрутизаторами с поддержкой LISP (туннельные маршрутизаторы) за счёт инкапсуляции. Туннельные маршрутизаторы включают кэш отображения (Map-Cache), который содержит сопоставления EID с RLOC. Map-Cache заполняется с помощью протокола плоскости управления LISP [RFC9301].

LISP не требует менять стек протоколов на хостах или базовых маршрутизаторах. Отделяя EID от RLOC, LISP поддерживает естественную организацию трафика (TE), многодомность, мобильность и иные возможности.

Разработка LISP была инициирована дискуссиями во время организованного IAB семинара Routing and Addressing в Амстердаме в октябре 2006 г. (см. [RFC4984]).

Этот документ задаёт инкапсуляцию плоскости данных LISP и другую функциональность пересылки на узлах LISP, а в [RFC9301] определена плоскость управления LISP. Рекомендации по развёртыванию LISP приведены в [RFC7215], а в [RFC6835] рассмотрены соображения по управлению сетями. В [RFC9299] описана архитектура LISP.

Этот документ отменяет RFC 6830.

1.1. Сфера применимости

Изначально протокол LISP создавался для решения проблемы расширения маршрутизации в сети Internet [RFC4984]. Хотя имеется ряд подходов к решению этой задачи, по мере разработки и совершенствования LISP было найдено и реализовано много других применений LISP. В результате устройство и разработка LISP изменились с нацеленностью на эти варианты применения. Общим свойством таких вариантов является большой набор кооперирующихся объектов, стремящихся взаимодействовать через Internet или иную крупную инфраструктуру IP, сохраняя адресацию и топологию сотрудничающих элементов отдельно от топологии, маршрутизации и адресации базовой сети и Internet.

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

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

3. Определения терминов

Address Family Identifier (AFI)

Термин AFI служит для описания кодирования адреса в пакете. Семейство адреса – это формат адреса, найденный в заголовках пакетов плоскости данных, например, адреса IPv4 или IPv6. Дополнительные подробности примедены в [AFN], [RFC2453], [RFC2677], [RFC4760]. AFI = 0 в этой спецификации указывает незаданное представление адреса, занимающего 0 октетов и имеющего 16-битовое поле AFI со значением 0.

Anycast Address

Anycast-адрес – это один адрес IPv4 или IPv6, настроенный и применяемый на нескольких системах одновременно. EID и RLOC могут быть anycast-адресами в своих пространствах адресов.

Client-side

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

Egress Tunnel Router (ETR) – выходной маршрутизатор туннеля

ETR – это маршрутизатор, воспринимающий пакеты IP, где адресом получателя во внешнем заголовке IP служит один из его RLOC. Маршрутизатор «вырезает» внешний заголовок и пересылает пакет по адресу IP из следующего заголовка. В общем случае ETR получает пакеты IP с инкапсуляцией LISP из Internet на одной стороне и передаёт декапсулированные пакеты IP конечным системам сайта на другой стороне. Функциональность ETR может реализоваться не только маршрутизаторами, но и серверными хостами, служащими точками завершения туннелей LISP.

EID-to-RLOC Database – база данных отображений

Распределенная база данных, содержащая все известные отображения EID-Prefix на RLOC. Каждый возможный ETR обычно содержит небольшую часть этой базы – отображения EID на RLOC для префиксов EID, находящихся за маршрутизатором. Эти префиксы сопоставляются с одним из IP-адресов маршрутизатора, маршрутизируемых в базовой сети. Отметим, что возможны временные условия, когда EID-Prefix для сайта LISP и Locator-Set для каждого EID-Prefix могут не совпадать на всех ETR. Это не оказывает негативного влияния, поскольку можно применять неполный набор локаторов.

EID-to-RLOC Map-Cache – кэш данных отображений

Обычно это краткосрочная таблица, создаваемая по запросу на входном маршрутизаторе туннеля (ITR), которая сохраняет, отслеживает, отвечает за синхронизацию и иные проверки отображения EID-RLOC. Этот кэш отличается от «полной» базы отображений EID на RLOC, он является динамическим, лакальным для ITR и относительно небольшим, тогда как база данных распределена, относительно статична и действует для большого числа узлов LISP.

EID-Prefix – префикс EID

EID-Prefix – это блок EID размером в степень числа 2, выделяемый сайту органом по распределению адресов. Префиксы EID-Prefix связываются с наборами адресов RLOC. EID-Prefix может делиться на более мелкие блоки, когда RLOC-Set связывается с более крупным блоком EID-Prefix.

End-System – конечная система

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

Endpoint ID (EID) – идентификатор конечной точки

EID – 32-битовое (IPv4) или 128-битовое (IPv6) значение, идентифицирующее хост. Значения EID обычно присутствуют лишь в полях адресов отправителя и получателя первого (внутреннего) заголовка LISP в пакете. Хост получает EID адресата от поиска в DNS³ [RFC1034] или обмена по протоколу инициирования сессии (Session Initiation Protocol или SIP) [RFC3261]. Их поведение не меняется при использовании LISP. EID отправителя получается с помощью имеющихся механизмов, применяемых для установки «локального» IP-адреса хоста. EID для использования в общедоступной сети Internet должен иметь такие же свойства, как другие адреса IP, используемые в таких случаях. Это означает, в том числе, что идентификатор должен быть уникальным. Значения EID выделяются хостам из блока EID-Prefix, связанного с сайтом, где размещён хост. EID может использоваться хостом для указания других хостов. Отметим, что блоки EID могут назначаться иерархически, независимо от топологии сети, для упрощения расширения база данных отображений. Кроме того, назначенный сайту блок EID может иметь локальную для сайта структуру (подсети) для маршрутизации внутри сайта, эта структура не будет видна базовой структуре маршрутизации. В теории битовая строка EID для одного устройства может представлять RLOC для другого устройства. При обсуждении других приложений по разделений Locator и ID все упоминания EID в этом документе относятся к LISP EID.

Ingress Tunnel Router (ITR) – входной маршрутизатор туннеля

ITR – это маршрутизатор, размещённый на сайте LISP. Пакеты с отправителями сайта LISP для внешних получателей являются кандидатами для инкапсуляции маршрутизатором ITR. ITR рассматривает IP-адрес получателя как EID и выполняет поиск отображения EID на RLOC. Маршрутизатор добавляет в начало пакета (prepend) «внешний» заголовок IP с одним из маршрутизируемых RLOC (в пространстве RLOC) в поле адреса отправителя и результатом поиска отображения в поле адреса получателя. Отметим, что RLOC получателя может быть промежуточным устройством-посредником (proxy), которому лучше известно отображение EID на RLOC ближе к EID адресата. В общем случае ITR получает пакеты IP от конечной системы сайта на одной стороне и передаёт пакет IP с инкапсуляцией LISP в направлении Internet на другой стороне.

LISP Header – заголовок LISP

Заголовком LISP в этом документе называется внешний заголовок IPv4 или IPv6, заголовок UDP и связанный с LISP 8-октетный заголовок, которые следуют после заголовка UDP. ITR помещает заголовок LISP перед пакетом, а ETR «вырезает» его.

LISP Router – маршрутизатор LISP

Маршрутизатором LISP называется маршрутизатор, выполняющий функции ITR, ETR, RTR, PITRs или PETR.

LISP Site – сайт LISP

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

Locator-Status-Bits (LSBs) – биты статуса локатора

Биты статуса локатора представляются в заголовке LISP и используются маршрутизаторами ITR для информирования ETR о состоянии up/down всех маршрутизаторов ETR на локальном сайте. Эти биты служат подсказками о состоянии маршрутизаторов, а не путей. LSB можно проверить с помощью одного из алгоритмов обнаружения доступности Locator, описанных в разделе 10. Доступность локатора маршрутизации. ETR должен ограничивать частоту применяемых действий при обнаружении смены битов статуса локаторов.

Proxy-ETR (PETR) – ETR-посредник

Определение и описание PETR приведено в [RFC6832]. PETR действует подобно ETR, но делает это от имени сайтов LISP, которые передают пакеты адресатам, не находящимся на сайтах LISP.

Proxy-ITR (PITR) – ITR-посредник

Определение и описание PITR приведено в [RFC6832]. PITR действует подобно ITR, но делает это от имени сайтов LISP, которые передают пакеты адресатам, находящимся на сайтах LISP.

Recursive Tunneling – рекурсивное туннелирование

Рекурсивное туннелирование возникает, когда пакет имеет более одного заголовка LISP IP. Дополнительные уровни туннелирования могут реализоваться для организации трафика (Traffic Engineering) или иных изменений маршрутизации (rerouting). При этом добавляется новый «внешний» заголовок LISP, а исходные RLOC сохраняются во «внутреннем» заголовке.

Re-encapsulating Tunneling Router (RTR) – туннельный маршрутизатор смены инкапсуляции

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

Route-Returnability – возвратность маршрута

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

Routing Locator (RLOC) – локатор маршрутизации

RLOC – это адрес IPv4 [RFC0791] или IPv6 [RFC8200] выходного маршрутизатора туннеля (ETR). Значение RLOC является результатом поиска отображения EID на RLOC. EID может (необязательно) сопоставляться с несколькими RLOC. Обычно значения RLOC берутся из блоков, назначенных сайту для каждой точки соединения с внешними базовыми сетями, где топология определяется связностью сетей провайдеров. Несколько RLOC можно назначить одному или нескольким маршрутизаторам ETR на сайте.

Server-side – серверная сторона

Серверной в этом документе называется сторона, воспринимающая попытку соединения с EID получателя.

xTR

xTR указывает ITR или ETR, когда направление потока данных не является частью описания контекста. xTR указывает маршрутизатор, являющийся конечной точкой туннеля, и применяется как синоним термина «туннельный маршрутизатор» (Tunnel Router). Например, фраза «xTR может размещаться на граничном маршрутизаторе клиента (Customer Edge или CE)» указывает, что маршрутизатор CE может быть ITR и ETR.

4. Базовый обзор

Одной из важных концепций LISP является независимость работы конечных точек от применения LISP. Адреса IP, применяемые хостами для отслеживания хостов и соединений, а также для передачи и приёма сообщений не меняются. В терминах LISP эти адреса называются идентификаторами конечных точек (EID).

Маршрутизаторы по-прежнему пересылают пакеты по IP-адресам получателей. Для пакетов с инкапсуляцией LISP эти адреса называются локаторами (RLOC). Большинство маршрутизаторов на пути между хостами также сохраняются и выполняют поиск для маршрутизации и пересылки по адресам получателей. Для маршрутизаторов между хостом-источником и ITR целевого хоста, а также между ETR целевого хоста и получателем адресом получателя служит EID. Для маршрутизаторов между ITR и ETR адресом получателя является RLOC.

Другой важной концепцией LISP является туннельный маршрутизатор (Tunnel Router). Этот маршрутизатор добавляет в начало (prepend) заголовки LISP созданных хостом пакетов и вырезает эти заголовки перед доставкой конечному получателю. Адресами IP в этих «внешних» заголовках являются локаторы RLOC. При сквозном обмене пакетами между хостами Internet маршрутизатор ITR добавляет заголовок LISP, а ETR удаляет его. ITR выполняет поиск отображения EID на RLOC для определения пути к ETR, имеющему RLOC в качестве одного из адресов IP.

Некоторые базовые правила LISP перечислены ниже.

• Конечные системы передают пакеты лишь по EID, которыми обычно служат адреса IP, назначенные хостам (другие типа EID, поддерживаемые LISP, описаны в [RFC8060]). Конечные системы не знают, что адреса являются EID, а не RLOC, и предполагают, что пакеты приходят к адресату. В системах с LISP маршрутизаторы LISP перехватывают пакеты с адресами EID и помогают доставлять их через ядро сети, где EID не маршрутизируются. Процедура отправки хостом пакетов IP не меняется.

• Маршрутизаторы LISP добавляют в начало пакета или вырезают внешние заголовки с адресами RLOC, как описано в параграфе 4.2. Порядок потока пакетов.

• RLOC всегда являются адресами IP, назначенными маршрутизаторам, которые предпочтительно привязывать к топологии провайдерских бесклассовых блоков (Classless Inter-Domain Routing или CIDR).

• Когда маршрутизатор создаёт пакеты, он может использовать в качестве адреса отправителя EID или RLOC. Выступая в качестве хоста (например, в транспортной сессии SSH, TELNET или SNMP), он может использовать EID, явно выделенный для этих целей. EID, указывающий маршрутизатор, недопустимо применять в качестве RLOC, поскольку EID маршрутизируется лишь внутри сайта. В типичной конфигурации BGP может встречаться такое «гибридное» использование EID/RLOC, где маршрутизатор может применять EID для внутренних сессий BGP (iBGP) с маршрутизаторами внутри сайта и RLOC для внешних сессий BGP (eBGP) с маршрутизаторами других сайтов.

• Предполагается, что пакеты с EID не будут доставляться «насквозь» при отсутствии отображения EID на RLOC. Ожидается, что они будут применяться для взаимодействий внутри сайта или инкапсулироваться для передачи на другие сайты.

• EID могут структурироваться (подсети) для маршрутизации внутри локальной автономной системы (Autonomous System или AS).

Дополнительный заголовок LISP могут добавлять в начало пакета маршрутизаторы TE-ITR для изменения пути доставки пакета. Возможным вариантом использования является маршрутизатор провайдера (ISP), которому нужно организовать трафик (Traffic Engineering) для пакетов, проходящих через сеть провайдера. В таких ситуациях, называемых рекурсивным туннелированием (Recursive Tunneling), транзитный ISP выступает дополнительным ITR, а применяемый им целевой RLOC для этого добавленного заголовка будет TE-ETR внутри ISP (на его внутреннем пути организации трафика) или TE-ETR у другого ISP (организация трафика между ISP при согласовании такого пути).

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

Туннельные маршрутизаторы можно достаточно свободно размещать в топологии с множеством AS. Например, ITR для определённого сквозного обмена пакетами может быть первым (first-hop) или принятым по умолчанию (default) маршрутизатором внутри сайта хоста-источника. ETR может быть последним (last-hop) маршрутизатором, напрямую соединенным с хостом-получателем. Другим примером может служить передача сайтом услуг VPN своему ISP, который будет применять в качестве ITR свой граничный маршрутизатор в точке присоединения. Для максимальной гибкости допускается смешивание туннельных маршрутизаторов на сайте, у ISP и в других местах.

4.1. Развёртывание в общедоступной сети Internet

Некоторые из описанных в документе механизмов предназначены для контролируемых, доверенных сред и небезопасны для использования в общей сети Internet. В частности, в Internet узлы xTRs

• должны сбрасывать (0) биты N, L, E, V в заголовке LISP (5.1. Формат заголовка LISP IPv4-in-IPv4);

• им недопустимо использовать LSB и Echo-Nonce (10. Доступность локатора маршрутизации) для доступности RLOC, а взамен они должны полагаться исключительно на методы плоскости управления;

• им недопустимо использовать сбор LSB и версий отображения (13. Изменение содержимого отображений EID на RLOC) для обновления отображений EID на RLOC и взамен они должны полагаться исключительно на методы плоскости управления.

4.2. Порядок потока пакетов

В этом параграфе приведён пример потока индивидуальных (unicast) пакетов, включая сведения плоскости управления, как указано в [RFC9301]. Ниже приведены условия, предполагающиеся в этом примере.

• Хост host1.abc.example.com передаёт пакеты хосту host2.xyz.example.com так же, как при отсутствии LISP.

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

• Маршрутизаторы ITR и ETR подключены напрямую к источнику и получателю, соответственно, но отправители и получатели могут размещаться в любом месте сайтов LISP.

• Передаётся Map-Request для внешнего адресата, когда получатель не найден в таблице пересылки и не соответствует заданному по умолчанию маршруту. Эти запросы передаются в базу данных отображений с помощью протокола плоскости управления LISP, описанного в [RFC9301].

• Отклики Map-Replies передаются в топологию базовой системы маршрутизации и помощью протокола плоскости управления [RFC9301].

Клиент host1.abc.example.com хочет взаимодействовать с сервером host2.xyz.example.com.

1. host1.abc.example.com хочет организовать соединение TCP с host2.xyz.example.com и выполняет поиск DNS для host2.xyz.example.com, который возвращает запись A/AAAA. Это будет EID получателя, а заданный локально адрес host1.abc.example.com служит EID отправителя. Пакеты IPv4 или IPv6 создаются и пересылаются через сайт LISP как обычные пакеты IP, пока они не почтупят на LISP ITR.

2. LISP ITR должен быть способен отобразить EID получателя на RLOC одного из ETR на сайте адресата. Это делается с помощью отправки LISP Map-Request, как описано в [RFC9301].

3. Система отображения (Mapping System) помогает переслать Map-Request соответствующему ETR. При поступлении Map-Request на один из ETR целевого сайта пакет обрабатывается как управляющее сообщение.

4. ETR просматривает EID получателя в Map-Request и сопоставляет его с префиксами в настроенной на ETR базы отображения EID-RLOC. Это список префиксов EID, которые ETR поддерживает для своего сайта. Если совпадения не найдено, Map-Request отбрасывается. В ином случае ITR возвращается LISP Map-Reply.

5. ITR принимает сообщение Map-Reply, анализирует его и сохраняет сведения об отображении из пакета в своём кэше отображений EID на RLOC (Map-Cache). Отметим, что это кэширование выполняется по запросам, а ITR поддерживает Map-Cache с учётом своих ограничений на ресурсы.

6. В последующие пакеты от host1.abc.example.com к host2.xyz.example.com маршрутизатор ITR включает заголовок LISP, используя подходящий локатор RLOC от ETR в качестве адреса получателя в заголовке LISP. Отметим, что пакет может передаваться разным ETR, которые могут быть указаны в Map-Reply, из-за политики хэширования сайта-источника или политики Locator-Set у получателя.

7. ETR получает пакеты напрямую (поскольку адресом получателя является один из его адресов IP), проверяет пригодность адреса, вырезает заголовок LISP и пересылает пакеты подключённому целевому хосту.

8. Чтобы отложить поиск сопоставления в обратном направлении ETR может создавать запись в кэше, отображающую EID источника (внутренний IP-адрес отправителя) на RLOC источника (IP-адрес отправителя из внешнего заголовка) из принятого пакета LISP. Такие записи называют отображениями сбора (glean mapping) и они включают лишь 1 RLOC для EID. Более полные сведения л дополнительных RLOC следует получать, передавая запрос LISP Map-Request для EID. Маршрутизаторы ITR и ETR могут влиять на решение, принимаемые другим при выборе RLOC.

5. Детали инкапсуляции LISP

Поскольку в начало пакета добавляются туннельные заголовки, пакет становится больше и его размер может превысить значение MTU на каком-либо канале между ITR и ETR. Для пакетов IPv4 рекомендуется не выполнять фрагментацию пакетов, поскольку они инкапсулированы ITR, а вместо этого отбрасывать такие пакеты и возвращать отправителю сообщение ICMPv4 Unreachable / Fragmentation Needed. Если требуется фрагментировать пакет, реализациям рекомендуется поддерживать одну из предложенных схем фрагментации и сборки. Две имеющихся схемы описаны в разделе 7. Обработка больших инкапсулированных пакетов.

Поскольку адреса IPv4 и IPv6 могут быть идентификаторами EID или локаторами RLOC, архитектура LISP поддерживает IPv4 EID с IPv6 RLOC (внутренний заголовок имеет формат IPv4, а внешний – IPv6) и IPv6 EID с IPv4 RLOC (внутренний заголовок IPv6 и внешний IPv4). В последующих параграфах показаны форматы пакетов для однородных вариантов (IPv4 в IPv4 и IPv6 в IPv6), но должны поддерживаться все 4 комбинации. Дополнительные типы EID определены в [RFC8060].

LISP использует инкапсуляцию UDP для передачи трафика между xTRs через Internet и разработчикам следует учитывать положения [RFC8085], особенно параграф 3.1.11, где описан контроль перегрузок для туннелей UDP. Разработчикам рекомендуется учитывать рекомендации параграфа 3.4 из [RFC8085] для контрольных сумм UDP, когда желательно защитить заголовки UDP и LISP от повреждений.

5.1. Формат заголовка LISP IPv4-in-IPv4

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version|  IHL  |    DSCP   |ECN|          Total Length         |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |         Identification        |Flags|      Fragment Offset    |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   OH  |  Time to Live | Protocol = 17 |         Header Checksum       |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                    Source Routing Locator                     |
    \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                 Destination Routing Locator                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4341        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L   |N|L|E|V|I|R|K|K|            Nonce/Map-Version                  |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                 Instance ID/Locator-Status-Bits               |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version|  IHL  |    DSCP   |ECN|          Total Length         |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |         Identification        |Flags|      Fragment Offset    |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   IH  |  Time to Live |    Protocol   |         Header Checksum       |
   |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |                           Source EID                          |
    \  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |                         Destination EID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IHL = IP-Header-Length

5.2. Формат заголовка LISP IPv6-in-IPv6

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version|    DSCP   |ECN|           Flow Label                  |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |         Payload Length        | Next Header=17|   Hop Limit   |
   v   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
   O   +                                                               +
   u   |                                                               |
   t   +                     Source Routing Locator                    +
   e   |                                                               |
   r   +                                                               +
       |                                                               |
   H   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   d   |                                                               |
   r   +                                                               +
       |                                                               |
   ^   +                  Destination Routing Locator                  +
   |   |                                                               |
    \  +                                                               +
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |       Source Port = xxxx      |       Dest Port = 4341        |
   UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     \ |           UDP Length          |        UDP Checksum           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   L   |N|L|E|V|I|R|K|K|            Nonce/Map-Version                  |
   I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   S / |                 Instance ID/Locator-Status-Bits               |
   P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     / |Version|    DSCP   |ECN|           Flow Label                  |
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   /   |         Payload Length        |  Next Header  |   Hop Limit   |
   v   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
   I   +                                                               +
   n   |                                                               |
   n   +                          Source EID                           +
   e   |                                                               |
   r   +                                                               +
       |                                                               |
   H   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   d   |                                                               |
   r   +                                                               +
       |                                                               |
   ^   +                        Destination EID                        +
   \   |                                                               |
    \  +                                                               +
     \ |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.3. Описание полей туннельного заголовка

Inner Header (IH)

Внутренним является заголовок дейтаграммы, полученной от хоста-источника [RFC0791] [RFC8200] [RFC2474]. IP-адреса отправителя и получателя являются EID.

Outer Header (OH)

Внешний заголовок добавляется в начало маршрутизатором ITR и адресные поля в нем являются RLOC, полученные из кэша EID-to-RLOC Map-Cache входного маршрутизатора. Номер протокола IP является UDP (17) из [RFC0768]. Бит запрета фрагментирования (Don’t Fragment или DF) в поле Flags устанавливается по правилам параграфов 7.1 и 7.2.

UDP Header

Заголовок UDP содержит выбранный ITR при инкапсуляции порт источника. В разделе 12 указаны детали алгоритма хэширования при выборе номера порта на основе квинтета (5-tuple) из внутреннего заголовка. В качестве порта получателя должен указываться выделенный IANA порт 4341.

UDP Checksum

В поле UDP Checksum маршрутизатору ITR следует помещать 0 для инкапсуляции IPv4 [RFC0768] или IPv6 [RFC6935] [RFC6936]. При получении пакета с нулевым значением UDP Checksum маршрутизатором ETR тот должен воспринимать пакет для декапсуляции. Когда ITR передаёт ненулевое значение UDP Checksum, он должен помещать в это поле корректно рассчитанную контрольную сумму. Когда ETR получает такой пакет, он может проверить значение контрольной суммы и при несовпадении должен отбросить пакет без уведомления отправителя. Если ETR не проверяет контрольную сумму, он должен воспринять пакет для декапсуляции. Обработка нулевой контрольной суммы UDP при использовании IPv6 для всех протоколов туннелирования, включая LISP, выполняется в соответствии с [RFC6936].

UDP Length

Поле UDP Length для инкапсулированного в IPv4 пакета содержит сумму значения поля IPv4 Total Length во внутреннем заголовки и размеров заголовков UDP и LISP. При инкапсуляции IPv6 в поле UDP Length указывается сумма значения поля IPv6 Payload во внутреннем заголовке, размера заголовка IPv6 (40 октетов), а также размера заголовков UDP и LISP.

N

Бит присутствия nonce. Установленный (1) бит указывает, что 24 младших бита из первого 32-битового слова в заголовке LISP содержат nonce (см. 10.1. Алгоритм Echo-Nonce). Биты N и V недопустимо устанавливать в одном пакете. При получении такого пакета ETR должен трактовать поле Nonce/Map-Version как значение nonce.

L

Флаг включения поля Locator-Status-Bits. При установленном бите второе 32-битовое слово заголовка LISP содержит Locator-Status-Bits.

    x 1 x x 0 x x x
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |N|L|E|V|I|R|K|K|            Nonce/Map-Version                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Locator-Status-Bits                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

E

Флаг запроса Echo-Nonce, который должен игнорироваться и не имеет значения при сброшенном (0) флаге N. При установленных (1) флагах N и E маршрутизатор ITR запрашивает возврат значения поля Nonce в пакетах с инкапсуляцией LISP, когда ITR выступает также и в качестве ETR (см. 10.1. Алгоритм Echo-Nonce).

V

Флаг присутствия поля Map-Version, при установке (1) которого бит N должен быть сброшен (0). Детали версий отображения описаны в [RFC9302]. Установка (1) этого бита показывает, что заголовок LISP имеет формат

    0 x 0 1 x x x x
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |N|L|E|V|I|R|K|K|  Source Map-Version   |   Dest Map-Version    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Instance ID/Locator-Status-Bits               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I

Флаг Instance ID (см. 8. Использование виртуализации и разделения с LISP). При установленном (1) бите поле Locator-Status-Bits сокращается до 8 битов, а 24 старших бита второго слова содержат Instance ID. При сброшенном (0) бите L младшие 8 битов передаются сброшенными (0) и игнорируются при получении. Формат заголовка LISP показан ниже.

    x x x x 1 x x x
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |N|L|E|V|I|R|K|K|            Nonce/Map-Version                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Instance ID                   |     LSBs      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

R

Резерв на будущее. При передаче бит должен сбрасываться (0), а при получении должен игнорироваться.

KK

Два бита KK указывают использование шифрования для инкапсулированных пакетов. Значение 00 указывает, что пакет не шифруется. Подробности описаны в [RFC8061].

LISP Nonce

Поле LISP Nonce представляет собой 24-битовое случайное значение, создаваемое ITR при установленном (1) бите N. Алгоритм создания Nonce определяется реализацией, но требуется генерировать разные значения при передаче по разным RLOC. Nonce применяется также при установленном (1) бите E для запроса возврата значения другой стороной в ответных пакетах. Если бит E сброшен (0), а N установлен (1), удалённый маршрутизатор ITR возвращает (эхо) запрошенное ранее значение Echo-Nonce или указывает случайное значение (см. 10.1. Алгоритм Echo-Nonce). Когда сброшены оба флага N и V (N=0, V=0), поля Nonce и Map-Version заполняются нулями, а при получении игнорируются.

LISP Locator-Status-Bits (LSBs)

При установленном (1) флаге L поле Locator-Status-Bits в заголовке LISP устанавливается ITR для указания маршрутизатору ETR состояния up/down для локаторов на сайте источника. Каждому RLOC в Map-Reply назначается номер от 0 до n-1 (n – число RLOC в записи отображения). Биты Locator-Status-Bits нумеруются от 0 до n-1, начиная с младшего бита поля. Поле имеет размер 32 бита при сброшенном (0) флаге I и 8 битов при I=1. Когда бит в Locator-Status-Bits установлен (1), ITR указывает маршрутизатору ETR, что локатор RLOC, связанный с этим битом, активен (up). В разделе 10 описано, как ITR может определить статус маршрутизаторов ETR на том же сайте. При наличии у сайта множества EID-Prefix, приводящего к множеству отображений (каждое может иметь свой набор Locator-Set), установка Locator-Status-Bits в инкапсулированном пакете должна соответствовать отображению для EID-Prefix, соответствующего адресу EID во внутреннем заголовке (по максимальному совпадению). Если LSB для индивидуального локатора имеет значение 1, существует хотя бы один RLOC с этим адресом и ETR считается работающим (up).

При инкапсуляции маршрутизаторы ITR и PITR выполняют указанные ниже правила.

• Поле TTL (Hop Limit для IPv6) следует копировать из поля TTL во внутреннем заголовке.

• В поле DSCP (Traffic Class для IPv6) следует копировать значение поля IPv4 DSCP (Traffic Class для IPv6) из внутреннего заголовка. Рекомендации для этого даны в [RFC2983].

• Биты явного уведомления о перегрузке IPv4 (Explicit Congestion Notification или ECN) и биты 6 – 7 поля IPv6 Traffic Class требуют особой обработки для предотвращения игнорирования индикации перегрузки, как указано в [RFC6040].

При декапсуляции маршрутизаторы ETR и PETR выполняют указанные ниже правила.

• В поле внутреннего заголовка IPv4 TTL (Hop Limit для IPv6) должно копироваться значение TTL (Hop Limit) из внешнего заголовка, если значение во внешнем заголовке меньше значения во внутреннем. Отказ от такой проверки может приводит к росту TTL (Hop Limit) во внутреннем заголовке в результате цикла инкапсуляции-декапсуляции. Проверка также выполняется при начальной инкапсуляции, когда пакет приходит в ITR или PITR для сайта LISP.

• Поле IPv4 DSCP (Traffic Class для IPv6) из внешнего заголовка следует копировать во внутренний заголовок. Рекомендации для этого даны в [RFC2983].

• Биты явного уведомления о перегрузке IPv4 (Explicit Congestion Notification или ECN) и биты 6 – 7 поля IPv6 Traffic Class требуют особой обработки для предотвращения игнорирования индикации перегрузки, как указано в [RFC6040]. Отметим, что имеются реализации, копирующие поле ECN из внешнего заголовка во внутренний, хотя [RFC6040] рекомендует не делать этого. Реализациям рекомендуется следовать поведению, описанному в [RFC6040].

Отметим, что в случаях, когда ETR/PETR является также ITR/PITR и заново инкапсулирует пакеты после декапсуляции, поле TTL во внешнем заголовке в результате будет уменьшаться на 1.

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

Некоторые xTR, PETR и PITR выполняют повторную инкапсуляцию и им нужна особая обработка полей ECN. Поскольку повторная инкапсуляция состоит из декапсуляции и последующей новой инкапсуляции, биты ECN должны обрабатывать в каждой из операций, как указано выше.

Протокол плоскости данных LISP не совместим с [RFC6830] и не имеет явной поддержки будущих изменений протокола (например, явного поля версии). Однако плоскость управления LISP [RFC9301] позволяет ETR регистрировать возможности плоскости данных с помощью новых типов канонического формата адресов (LISP Canonical Address Format или LCAF) [RFC8060]. За счёт этого ITR может узнать возможности плоскости данных ETR и применять соответствующую инкапсуляцию. Спецификация новых типов и механизмов LCAF, а также их применения выходит за рамки этого документа.

6. Кэш сопоставлений EID с RLOC в LISP

ITR и PITR поддерживают кэширование по запросам в LISP EID-to-RLOC Map-Cache, куда включаются отображения EID-Prefix на Locator-Set. Кэш применяется для инкапсуляции пакетов из пространства EID в RLOC точки присоединения к сети. Когда ITR или PITR получает пакет со своего сайта LISP для внешнего адресата, выполняется поиск по максимальному соответствию с EID в Map-Cache. При успешном поиске Locator-Set из Map-Cache применяется для передачи пакета в топологическое местоположение EID. Если поиск не даёт результата ITR/PITR требуется найти отображение с помощью протокола плоскости управления LISP [RFC9301]. Пока отображение отыскивается и извлекается, ITR/PITR может отбрасывать или буферизовать пакеты. Этот документ не даёт конкретных рекомендаций для таких случаев и разработчики должны решать этот вопрос самостоятельно, обеспечивая желаемое поведение реализации LISP. После распознавания отображения оно сохраняется в локальном Map-Cache для пересылки последующих пакетов в тот же EID-Prefix.

Map-Cache – это локальный кэш отображений, записи в котором сохраняются в течение заданного срока (Time to Live). Записи могут обновляться более свежими данными, как описано в разделе 13. Изменение содержимого отображений EID на RLOC. Кроме того, Map-Cache содержит сведения о доступности EID и RLOC, а также использует механизмы сведений о доступности LISP для проверки достижимости RLOC (см. 10. Доступность локатора маршрутизации).

7. Обработка больших инкапсулированных пакетов

В этом разделе предлагаются два механизма работы с пакетами, размер которых превышает Path MTU (PMTU) между ITR и ETR.

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

Оба механизма применимы к повторной инкапсуляции и рекурсивным туннелям, поскольку действия для ITR применимы и на TE-ITR.

7.1. Решение для обработки MTU без учёта состояний

Решение без учёта состояний при обработке ITR проблем с MTU описано ниже.

1. Определяется число октетов H, добавляемых ITR во внешний заголовок перед пакетом, с учётом размера заголовков UDP и LISP.

2. Определяется число октетов L для максимального размера пакетов, которые ITR может передавать ETR без необходимости их фрагментирования на ITR и промежуточных маршрутизаторах. Сетевой администратор сайта LISP должен выбрать значение L, позволяющее избежать проблем с MTU.

3. Определяется архитектурная константа S для максимального размера пакетов (в октетах), которые ITR должен воспринимать от источника с учётом эффективного значения MTU. L = S + H.

Когда ITR получает пакет от интерфейса в сторону сайта и добавка H октетов инкапсуляции ведёт к превышению L (размер пакета от источника больше S), он решает проблему MTU, деля исходный пакет на два фрагмента одинаковых размеров, а затем добавляет в начало каждого фрагмента заголовок LISP. Размер инкапсулированных фрагментов составит (S/2 + H), что меньше оценки ITR для PMTU между ITR и соответствующим ETR.

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

Это поведение должно быть реализовано в ITR лишь для исходных пакетов со сброшенным (0) битом запрета фрагментирования. Если бит DF установлен в заголовке IP или пакет относится к протоколу IPv6, ITR будет отбрасывать пакет, если его размер превышает L (после добавления заголовка инкапсуляции) и передавать источнику сообщение ICMPv4 Unreachable/Fragmentation Needed или ICMPv6 Packet Too Big (PTB) со значением S = (L – H).

При использовании для инкапсуляции внешнего заголовка IPv4 следует устанавливать (1) в нем флаг DF, чтобы избежать сборки на маршрутизаторе ETR. Реализация может сбрасывать (0) флаг DF в таких заголовках, если имеются веские основания предполагать наличие неразрешимых проблем с PMTU между ITR и принимающим ETR.

Рекомендуется устанавливать L = 1500.Дополнительные сведения о MTU в сети и вопросах фрагментации приведены в [RFC4459].

7.2. Решение для обработки MTU с учётом состояний

Решение с учётом состояний при обработке ITR проблем с MTU описано ниже.

1. ITR сохраняет эффективное состояние MTU для каждого локатора в записи Map-Cache. Эффективным значением MTU является размер пакета, который ядро сети может доставить по пути между ITR и ETR.

2. Когда инкапсулированный в IPv4 пакет с DF = 1 превышает размер, поддерживаемый ядром сети, один из промежуточных маршрутизаторов пути передаёт ITR сообщение ICMPv4 Unreachable/Fragmentation Needed. ITR анализирует сообщение ICMP для определения локатора, на который влияет смена эффективного MTU и записывает новое значение MTU в Map-Cache.

3. Когда ITR получает из внутренней сети сайта пакет с размером больше эффективного MTU в записи Map-Cache, связанной с EID получателя пакета, ITR передаёт источнику этого пакета сообщение ICMPv4 Unreachable/Fragmentation Needed. Размер пакета, анонсируемый ITR в сообщении ICMP, составляет эффективное значение MTU за вычетом заголовка инкапсуляции LISP.

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

Следует отметить, что применение пакетов ICMP для определения PMTU, как описано в [RFC1191] и [RFC8201], может приводить к неоптимальному поведению при потере пакетов ICMP или наличии за пределами пути злоумышленников, передающих обманные пакеты ICMP. Возможные меры снижения негативного влияния включают взаимодействие ITR и ETR с тестовыми пакетами [RFC4821] [RFC8899] или сохранение на ITR больших пакетов для проверки их соответствия пакетам, указанным в сообщениях ICMP Fragmentation Needed или PTB.

8. Использование виртуализации и разделения с LISP

В некоторых случаях требуется разделение на уровне EID. Например, это относится к развёртываниям с перекрывающимися адресами, правилами изоляции трафика или виртуализацией со множеством арендаторов. Для таких случаев применяются идентификаторы экземпляров – Instance ID.

Instance ID можно передавать в пакетах с инкапсуляцией LISP. ITR, добавляющий заголовок LISP будет копировать 24-битовое значение, используемое маршрутизатором LISP для однозначного указания пространства адресов. Значение копируется в поле Instance ID заголовка LISP а для флага I устанавливается значение 1.

Когда ETR декапсулирует пакет Instance ID из заголовка LISP используется в качестве идентификатора таблицы пересылки, применяемой для поиска EID получателя.

В качестве Instance ID может служить, например, тег 802.1Q VLAN или идентификатор VPN, помещаемый в 24-битовое поле Instance ID. Применение LISP в VPN подробно рассмотрено в [LISP-VPN]. Отметим, что поле Instance ID не защищено и находящийся на пути злоумышленник может менять его и, например, разрешать взаимодействие между изолированными VLAN.

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

Instance ID не следует применять с перекрывающимися адресами IPv6 EID.

9. Выбор локатора маршрутизации

Map-Cache содержит состояние, используемое ITR и PITR для инкапсуляции пакетов. Когда ITR или PITR принимает пакет с сайта LISP для внешнего адресата выполняется поиск по максимальному совпадению EID в Map-Cache (см. 6. Кэш сопоставлений EID с RLOC в LISP ). Поиск возвращает набор Locator-Set со списком RLOC, соответствующих топологическому расположению EID. С каждым RLOC в Locator-Set связан приоритет (Priority) и вес (Weight), используемые для выбора RLOC при инкапсуляции.

Выбирается RLOC с наименьшим значением Priority. RLOC с Priority=255 недопустимо использовать для пересылки. При наличии RLOC с одинаковым приоритетом значение Weight задаёт распределение трафика между ними. Значение Weight представляет относительный вес общего числа пакетов, соответствующих записи отображения.

Ниже рассмотрено несколько вариантов выбора RLOC и доступные элементы управления.

• Серверная сторона возвращает 1 локатор RLOC и клиентская сторона применяет лишь его. Выбор локатора полностью принадлежит серверной стороне.

• Серверная сторона возвращает список RLOC, часть которых имеет одинаковое (лучшее) значение Priority. Клиент может использовать эти локаторы с весовыми коэффициентами, заданными на стороне сервера. В этом случае сервер контролирует набор локаторов и распределение трафика между ними. Клиентская сторона может выбрать RLOC (с приоритетом, отличным от 255) не из подмножества списка, если она решает, что это подмножество недоступно. Здесь имеется некоторое распределение управления – сервер определяет список RLOC и распределение нагрузки между ними, а клиент может использовать другие локаторы, если RLOC из списка недоступны.

• Серверная сторона устанавливает Weight=0 для списка подмножества RLOC. В этос случае клиентская сторона выбирает способ распределения трафика между элементами подмножества. Механизмы распределения трафика рассмотрены в разделе 12. Хэширование локаторов маршрутизации. Управление распределено между серверной стороной, задающей список, и клиентской стороной, определяющей распределение нагрузки. Клиент и в этом случае может использовать другие локаторы, если RLOC из предоставленного сервером списка недоступны.

• Любая из сторон (наиболее вероятно, ETR на стороне сервера) решает «собрать» RLOC. Например, если ETR серверной стороны собирает RLOC, ITR на стороне клиента возлагает на этот ETR ответственность за двухстороннюю доступность и предпочтения RLOC. ETR на стороне сервера собирает RLOC клиентского ITR, кэшируя EID источника из внутренних заголовков и RLOC источника из внешних заголовков принятых пакетов. ITR на стороне клиента контролирует возврат трафика и может, как вариант, использовать RLOC источника из внешнего заголовка, который может затем добавляться в список, используемый ETR на серверной стороне для возврата трафика. Поскольку в этом случае Priority и Weights не предоставляются, ETR на стороне сервера должен предполагать, что RLOC, применяемые ITR на стороне клиента имеют наилучшее значение Priority с Weight = 0.

  Поскольку кодирование EID-Prefix не может передаваться в пакетах данных, EID-to-RLOC Map-Cache на туннельных маршрутизаторах может стать чрезмерно большим. Со сбором связано несколько важных соображений. «Собранная» запись Map-Cache сохраняется и применяется лишь в течение рекомендованного интервала в 3 секунды, ожидая проверки, которая должна выполняться путём отправки Map-Request по EID источника (IP-адрес отправителя во внутреннем заголовке) полученного инкапсулированного пакета. Отклик на проверочный Map-Request служит для заполнения записи Map-Cache для «собранного» EID с сохранением и использованием её в течение интервала, заданного полем Time to Live в полученном Map-Reply. При сохранении проверенной записи Map-Cache сбор данных больше не выполняется для последующих пакетов с EID источника, соответствующим EID-Prefix в проверенной записи. Этот механизм «сбора» недопустимо применять через общедоступную сеть Internet и следует использовать лишь в доверенных, изолированных развёртываниях. Безопасность механизма обсуждается в разделе 16.

RLOC из сообщений EID-to-RLOC предполагаются достижимыми, если бит R [RFC9301] для записи Locator имеет значение 1. При сброшенном (0) бите R маршрутизаторам ITR и PITR недопустимо инкапсулировать в этот RLOC. Ни сведения из Map-Reply, ни данные, сохранённые в базе отображений не обеспечивают информации о достижимости RLOC. Отметим, что достижимость не является частью системы отображения и определяется с использованием одного или нескольких алгоритмов проверки доступности RLOC, описанных в следующем разделе.

10. Доступность локатора маршрутизации

В настоящее время имеется несколько механизмов плоскости данных для определения доступности RLOC. Отметим, что в [RFC9301] описаны другие механизмы, основанные на плоскости управления.

1. ETR может проверить биты LSB в заголовке LISP инкапсулированного пакета данных, принятого от ITR. Если ETR выступает также в качестве ITR и имеет трафик для возврата сайту исходного ITR, он может использовать эти сведения при выборе RLOC.

2. Когда ETR получает инкапсулированный пакет от ITR, RLOC источника из внешнего заголовка, вероятно, будет доступен. Отметим, что в некоторых случаях RLOC во внешнем заголовке может быть обманным полем.

3. Пара ITR – ETR может использовать алгоритмы определения доступности, описанные в этом параграфе.

При определении статуса up/down для локатора путём проверки LSB из пакета данных с инкапсуляцией LISP маршрутизатор ETR будет получает от инкапсулирующего ITR актуальное состояние доступности всех ETR на сайте. Основанные на CE маршрутизаторы ITR на сайте источника могут определить достижимость друг друга, используя IGP, как указано ниже.

• При нормальных условиях каждый ITR будет анонсировать принятый по умолчанию маршрут в IGP сайта.

• При отказе ITR или восходящего канала к устройству PE для принятого по умолчанию маршрута будет возникать тайм-аут или он будет отзван.

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

Когда ITR сайта не развёрнуты на маршрутизаторах CE, IGP всё равно можно использовать для определения доступности локаторов при условии их внедрения в IGP. Обычно это делается с помощью адреса /32 (хост) на интерфейсе loopback.

RLOC, указанные в Map-Reply, имеют номера от 0 до n-1. Биты LSB в пакете с инкапсуляцией LISP нумеруются от 0 до n-1, начиная с младшего. Например, если RLOC в третьей позиции (порядковый номер 2) Map-Reply не активен, все ITR сайта будут сбрасывать этот бит (xxxx x0xx) в поле Locator-Status-Bits инкапсулируемых пакетов.

Когда xTR решает применять Locator-Status-Bits для воздействия на сведения о достижимости, он выполняет соответствующие действия. ETR, декапсулирующие пакеты, проверяют наличие изменений в поле Locator-Status-Bits. Если бит сбрасывается (переход от 1 к 0), ETR, выступающий также в качестве ITR, будет воздерживаться от инкапсуляции пакетов для RLOC, указанного как недоступный (down). Использование этого RLOC будет возобновлено лишь при возврате соответствующего бита LSB в состояние 1. Биты LSB связываются с Locator-Set по префиксам EID, поэтому когда локатор становится недоступным, бит LSB, соответствующий позиции этого локатора в списке из последнего Map-Reply, сбрасывается (0) для данного EID-Prefix.

Locator-Status-Bits недопустимо использовать через общую сеть Internet и следует применять лишь в доверенных, изолированных средах. Кроме того, Locator-Status-Bits следует сочетать с Map-Versioning [RFC9302] для предотвращения «состязания», когда биты LSB интерпретируются не для того локатора RLOC, которому они предназначены. Связанные с этим вопросы безопасности рассмотрены в разделе 16.

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

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

10.1. Алгоритм Echo-Nonce

Когда данные передаются в двух направлениях между локаторами разных сайтов, может применяться механизм плоскости данных «nonce-эхо» (nonce echoing) для определения достижимости между ITR и ETR. Если ITR хочет запросить nonce-эхо, он устанавливает флаги N и E, а также помещает 24-битовое значение [RFC4086] в заголовок LISP следующего инкапсулируемого пакета данных. Когда этот пакет приходит к ETR, инкапсулированный пакет пересылается обычным путём. Если ETR является xTR (совмещён с ITR), он затем передаёт пакет данных ITR (когда тот является xTR, совмещённым с ETR), включая в него полученное значение nonce, устанавливая бит N и сбрасывая бит E. ITR видит отражённое значение nonce и понимает, что путь между ним и ETR доступен.

ITR будет устанавливать биты E и N в каждом пакете, пока он находится в состоянии Echo-Nonce-request. Время, в течение которого ITR ожидает обработки отражённого nonce, определяющей доступность пути, является переменным и зависит от реализации.

Если ITR получает пакеты от ETR, но не видит в них отражённых nonce, находясь в состоянии Echo-Nonce-request, это говорит о недоступности пути к ETR. Это решение может быть отменено другим алгоритмом проверки доступности локаторов. После того, как ITR определит, что путь к ETR не работает, он может переключиться на другой Locator для этого EID-Prefix.

Отметим, что термины ITR и ETR здесь относительны и оба устройства должны реализовать функции ITR и ETR для работы механизма Echo-Nonce.

ITR и ETR могут одновременно оказаться в состоянии Echo-Nonce-request. Число передаваемых пакетов или время, в течение которого передаются пакеты Echo-Nonce, зависит от настроек реализации. Маршрутизатор xTR, получающий пакеты с запросом Echo-Nonce, выходит из состояния Echo-Nonce и устанавливает таймер Echo-Nonce-request-state, а по завершении его отсчёта возвращается в состояние Echo-Nonce.

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

Алгоритм Echo-Nonce является двухсторонним, т. е. если одна сторона устанавливает флаг E, а другая не включила Echo-Noncing, кодирование nonce не выполняется и запрашивающая сторона будет ошибочно считать, что локатор недоступен. ITR следует устанавливать бит E в инкапсулированных пакетах данных, когда ему известно, что на ETR включено Echo-Noncing. Это указывается флагом E в сообщении Map-Reply.

Многие реализации не анонсируют поддержку Echo-Nonce в сообщениях Map-Reply, поэтому для проверки доступности RLOC обычно применяется RLOC-Probing.

Механизм Echo-Nonce недопустимо применять в общедоступной сети Internet и он должен использоваться лишь в изолированных, доверенных средах (см. 16. Вопросы безопасности).

11. Доступность EID на сайте LISP

Сайт может быть многодомным и использовать два или более ETR. Хосты и инфраструктура сайта будут адресоваться с использованием одного или нескольких EID-Prefix, отображённых на RLOC соответствующих ETR в системе отображения. Одним из возможных вариантов отказа ETR является потеря связности с одним или несколькими EID-Prefix своего сайта. В таких случаях при отправке пакетов Map-Reply маршрутизатор ETR может сбрасывать (0) бит R, связанный с его локатором. Когда ETR служит также в качестве ITR, он может сбросить свой бит LSB в заголовке инкапсуляции данных.

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

12. Хэширование локаторов маршрутизации

Когда ETR представляет в сообщении Map-Reply отображение EID-RLOC, сохраняемое в Map-Cache запрашивающего ITR, Locator-Set для EID-Prefix может содержать разные значения Priority и Weight для каждого адреса локатора маршрутизации (Routing Locator Address). При наличии нескольких локаторов с лучшим приоритетом ITR может распределять трафик между соответствующими локаторами. Ниже приведён алгоритм, который ITR может использовать для пакета, адресованного EID, в отображении EID-RLOC.

1. Можно использовать хэш адреса отправителя и получателя или обычного квинтета (5-tuple). Обычно используемый хэш 5-tuple включает адреса отправителя и получателя, их номера портов TCP, UDP или SCTP⁴ и поле протокола IP или следующего протокола IPv6 из пакета, созданного хостом сайта LISP. Если пакет не относится к TCP, UDP, SCTP, для расчёта хэш-значения применяются лишь адреса отправителя и получателя.

2. Хэш-значение делится на число локаторов в Locator-Set для отображения EID-RLOC.

3. Остаток будет иметь значение от 0 до числа локаторов минус 1 и применяется для выбора локатора из Locator-Set.

Выбор конкретного алгоритма, применяемого ITR для распределения нагрузки, выходит за рамки этого документа и не препятствует совместимости. Порт источника следует сохранять одинаковым для всех пакетов одного потока. Отметим также, что при инкапсуляции пакетов в LISP нужно устанавливать номер порта во внешнем заголовке UDP. Выбор хэшированного значения позволяет маршрутизаторам ядра, соединенным с агрегатом каналов (Link Aggregation Group или LAG) распределять инкапсулированные пакеты между каналами LAG. В противном случае маршрутизаторы ядра будут лишь видеть один поток, поскольку в пакетах указан адрес ITR как отправителя для пакетов, исходящих от разных EID на сайте. Предлагается использовать в качестве порта источника, рассчитанное ITR хэш-значение 5-tuple из внутреннего заголовка, как указано выше. Порт отправителя следует сохранять для всех пакетов одного потока.

Многие реализации маршрутизаторов ядра применяют хэш 5-tuple для распределения нагрузки между каналами LAG. 5-tuple включает адреса и порты отправителя и получателя, когда номер протокола в пакете указывает TCP или UDP. Поэтому для инкапсуляции LISP применяется UDP. Когда внешним заголовком является IPv6, может устанавливаться также метка потока, как задано в [RFC6438]. Когда внутренним заголовком является IPv6 и метка потока отлична от 0, она может включаться в расчёт хэш-значения.

13. Изменение содержимого отображений EID на RLOC

Поскольку в архитектуре LISP для хранения и извлечения сопоставлений EID-RLOC применяется схема кэширования, ITR может получить более своевременное отображение только путём повторения запроса. ITR могут не знать о смене отображения, а ETR не отслеживают, какие ITR запрашивали отображения. Для расширяемости такой подход желательно сохранить, но разработчикам нужно предоставить ETR способ смены их отображений и информирования о такой смене сайты, взаимодействующие с сайтом ETR.

В этом разделе описаны два механизма плоскости данных для обновления отображений EID-RLOC. Кроме того, в [RFC9301] задан механизм запросов (Solicit-Map-Request или SMR).

13.1. Locator-Status-Bits

Биты состояния локаторов (LSB) могут служить для отслеживания статуса локаторов (up-down) при изменении отображений EID-RLOC. При использовании LSB в системе LISP все туннельные маршрутизаторы LISP должны реализовать возможности как ITR, так и ETR (т. е. фактически быть xTR). В этом параграфе термин xTR-источник указывает xTR, передающий LSB, а xTR-получатель – xTR, принимающий LSB. Процедура описана ниже.

1. При добавлении или удалении записи для локатора в Locator-Set xTR-источник будет сообщать об этом, передавая сообщение уровня управления SMR [RFC9301] xTR-получателю. В этот момент xTR-источнику недопустимо использовать поле LSB, если флаг L сброшен (0), поскольку сайт xTR-получателя имеет устаревшие сведения. Отправитель xTR устанавливает таймер use-LSB.

2. При получении сообщения SMR, как указано в [RFC9301], получатель xTR извлекает обновлённые отображения EID-RLOC путём отправки сообщений Map-Request.

3. По завершении отсчёта таймера use-LSB отправитель xTR снова может использовать LSB с xTR-получателем для информирования о статусе локаторов (up или down). Значение таймера use-LSB зависит от развёртывания LISP, но оно должно быть достаточно велико, чтобы xTR-получатель мог извлечь обновлённые отображения EID-RLOC. Рекомендуется устанавливать для таймера use-LSB значение 5 минут.

13.2. Версии базы данных отображений

Когда имеется односторонний поток данных между ITR и ETR, а отображения EID-RLOC на ETR меняются, нужно сообщить ITR, чтобы тот мог прекратить инкапсуляцию для удалённых локаторов и начать использовать добавленные в Locator-Set.

ETR может передать сообщения Map-Reply с номером Map-Version [RFC9302] в EID-Record. Этот номер называют Destination Map-Version Number. Маршрутизаторы ITR включают Destination Map-Version Number в пакеты, инкапсулируемые для сайта.

ITR при инкапсуляции пакетов для ETR может указать свой номер Map-Version – Source Map-Version Number.

При наличии в записях EID-Record сообщений Map-Register [RFC9301] номера Map-Version он является для Map-Server [RFC9301] хорошим способом обеспечить для всех зарегистрированных на нем ETR синхронизацию версий отображения.

Более подробно версии базы данных рассмотрены в [RFC9302].

14. Групповая передача

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

В контексте LISP групповой адрес является сразу EID и RLOC, поэтому для адреса получателя не требуется особой семантики, поскольку он указан в заголовке IP. Таким образом, групповой адрес IP, указанный во внутреннем заголовке хостом-источником, будет служить EID получателя. Внешний заголовок IP (RLOC получателя), добавляемый маршрутизатором LISP, может использовать в качестве RLOC получателя тот же групповой адрес, а также групповой или индивидуальный локатор RLOC, полученный при поиске в системе отображения или иным способом.

В качестве RLOC источника ITR использует свой адрес IP во внешнем заголовке IP, как при обмене с обычными EID. Этот адрес RLOC, как и все остальные RLOC, должен быть глобально маршрутизируемым.

Имеется два подхода к LISP-Multicast [RFC6831] – один на основе обычной multicast-маршрутизации в базовой сети без Mapping System, другой с использованием в базовой сети индивидуальной маршрутизации с поддержкой Mapping System (они описаны в [RFC6831] и [RFC8378], соответственно). Детали LISP-Multicast и взаимодействия с сайтами без поддержки LISP рассмотрены в [RFC6831] и [RFC6832], соответственно.

15. Работа маршрутизаторов

Протокол LISP разработан для аппаратной реализации, дружественной к пересылке (hardware based and forwarding friendly). Для поэтапного внедрения LISP имеется несколько методов.

• Когда ETR принимает инкапсулированный в туннель пакет, внешний адрес получателя может не быть адресом этого маршрутизатора. Это осложняет плоскости управления получение пакетов от оборудования. Проблему можно смягчить созданием специальных записей таблицы пересылки (Forwarding Information Base или FIB) для EID-Prefix адресов EID, обслуживаемых ETR (тех, для которых маршрутизатор транслирует RLOC). Эти записи FIB помечаются флагом, указывающим, что пакет следует обработать в плоскости пересылки. Логика пересылки для проверки конкретного номера протокола IP не требуется. Есть несколько подтверждённых вариантов, где не потребовалось менять имеющееся оборудование для поддержки плоскости данных LISP.

• На ITR добавление в начало нового заголовка IP состоит из добавления октетов в строку кода аутентификации сообщения (Message Authentication Code или MAC) и добавление этой строки в начало в процессе исходящей инкапсуляции. Маршрутизаторы с поддержкой туннелей GRE⁵ [RFC2784] или 6to4 [RFC3056] могут уже поддерживать это.

• Адрес источника пакета или интерфейс, на котором пакет был принят, могут служить для выбора экземпляра виртуальной маршрутизации и пересылки (Virtual Routing and Forwarding или VRF). Таблица маршрутизации VRF может служить для поиска отображений EID-RLOC.

Вопросы, связанные с управлением кэшем отображений, рассмотрены в разделе 16.

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

Далее рассматриваются соображения безопасности, применимые при внедрении LISP в средах, подробных описанным в параграфе 1.1. Сфера применимости.

Предложен необязательный механизм сбора (gleaning) для прямого получения сопоставлений из пакетов с инкапсуляцией LISP. В частности, xTR может изучать отображения EID-RLOC, просматривая RLOC и EID источника в инкапсулированных пакетах и помещая найденные сопоставления в свой Map-Cache. Атакующий извне пути может подменить EID источника, чтобы направить переданный трафик на EID жертвы. Если атакующий подменит RLOC, он сможет организовать DoS-атаку перенаправляя трафик на RLOC, возможно, перегружая её.

Плоскость данных LISP задаёт несколько механизмов отслеживания доступности RLOC. В этом контексте биты статуса локаторов (LSB), присутствия nonce и Echo-Nonce в заголовке инкапсуляции LISP атакующий может изменять для организации DoS-атаки. Атакующий извне пути может подменить RLOC и или nonce маршрутизатора xTR жертвы для анонсирования ложных сведений о статусе доступности RLOC.

Примером таких атак является случай, когда размещённый вне пути злоумышленник может использовать механизм Echo-Nonce, передавая маршрутизатору ITR пакеты данных со случайным значением nonce от фиктивного RLOC маршрутизатора ETR. Отметим, что у атакующего имеется лишь небольшой интервал времени, в течение которого ему нужно угадать значение nonce, отражение которого запросил маршрутизатор ITR. Цель заключается в том, чтобы убедить ITR, что RLOC маршрутизатора ETR доступен, даже если это не так. При успешной атаке ITR будет полагаться на ложный статус доступности RLOC маршрутизатора ETR, пока RLOC-Probing не обнаружит реальный статус. Этот интервал имеет порядок десятков секунд. Такие атаки можно смягчить предотвращая подмену RLOC в сети за счёт развёртывания uRPF⁶ в соответствии с BCP 84 [RFC8704]. Для использования этой уязвимости расположенный вне пути злоумышленник должен передавать пакеты Echo-Nonce с высокой скоростью. Если ITR не запрашивает nonce, он может защитить себя от ложных сведений о доступности.

Возможна проверка uRPF для LISP. При декапсуляции ETR может проверять корректность EID и RLOC по отображению EID-RLOC в Mapping System.

Map-Versioning – это механизм плоскости данных, используемый для сигнализации xTR-партнерам о смене локального отображения EID-RLOC, чтобы партнёры xTR использовали сигнальные сообщения плоскости управления LISP для извлечения свежего сопоставления. Злоумышленник может подменить поле Map-Version в заголовке инкапсуляции LISP и вызвать избыточную сигнализацию между xTR с целью их перегрузки. Вопросы безопасности использования Map-Versioning рассмотрены в [RFC9302].

Биты LSB, механизм Echo-Nonce и Map-Versioning недопустимо применять в общедоступной сети Internet и следует использовать лишь в изолированных, доверенных средах. Кроме того, LSB следует сочетать с Map-Versioning для предотвращения состязаний, когда биты LSB относятся не к тем RLOC, для которых предназначены.

Реализациям и внедрениям LISP, допускающим фрагменты внешних заголовков пакетов IPv6 с инкапсуляцией LISP в качестве средства решения вопросов MTU, следует использовать в ETR методы, предотвращающие использования этого для DoS-атак. Можно использовать ограничение числа фрагментов, ожидающих сборки в ETR, RTR, PETR, и скорости восприятия таких пакетов.

17. Вопросы управления сетью

Соображения по инструментам оперативного управления стеком протоколов LISP приведены в [RFC7052] и [RFC6835].

18. Отличия от RFC 6830

С учётом опыта реализации после публикации [RFC6830] в документ были внесены указанные ниже изменения.

• Больше не используется ограничение на число заголовков LISP, добавляемых в начало пакета. Если приложению нужно более 2 заголовков LISP, реализация может поддерживать это. Однако рекомендуется применять не более 2 заголовков LISP.

• Использованы резервные флаги в заголовке LISP для [RFC8061]. Два младших бита 3-битового поля (KK) служат идентификатором ключа, а оставшийся бит сохранён как резервный.

• Сбор в плоскости данных для создания записей Map-Cache сделана необязательной. Любым реализациям ITR, которые зависят от сборки или предполагают, что удалённый ETR выполняет сбор, следует отказаться от этого. Проблем функциональной совместимости не возникает, поскольку процедуры заполнения Map-Cache в плоскости управления являются односторонними и служат типовым методом заполнения Map-Cache.

• Большинство изменений в этом документе, которые сократили его размер, связаны с переносом сообщений и процедур плоскости управления LISP в [RFC9301].

19. Взаимодействие с IANA

В этом разделе приведены рекомендации для IANA по части регистрации значений, связанных с этой спецификацией плоскости данных LISP, в соответствии с BCP 26 [RFC8126].

19.1. Номера портов LISP UDP

Агентство IANA выделило номер порта UDP 4341 для плоскости данных LISP с показанным ниже обновлением описания этого порта в реестре.

Таблица 1.

 

Имя службы	Номер порта	Транспортный протокол	Описание	Документ
lisp-data	4341	udp	Пакеты данных LISP	RFC 9300

 

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

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

[RFC0768] Postel, J., “User Datagram Protocol”, STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <https://www.rfc-editor.org/info/rfc768>.

[RFC0791] Postel, J., “Internet Protocol”, STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>.

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers”, RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.

[RFC2983] Black, D., “Differentiated Services and Tunnels”, RFC 2983, DOI 10.17487/RFC2983, October 2000, <https://www.rfc-editor.org/info/rfc2983>.

[RFC6040] Briscoe, B., “Tunnelling of Explicit Congestion Notification”, RFC 6040, DOI 10.17487/RFC6040, November 2010, <https://www.rfc-editor.org/info/rfc6040>.

[RFC6438] Carpenter, B. and S. Amante, “Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels”, RFC 6438, DOI 10.17487/RFC6438, November 2011, <https://www.rfc-editor.org/info/rfc6438>.

[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, “The Locator/ID Separation Protocol (LISP)”, RFC 6830, DOI 10.17487/RFC6830, January 2013, <https://www.rfc-editor.org/info/rfc6830>.

[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, “The Locator/ID Separation Protocol (LISP) for Multicast Environments”, RFC 6831, DOI 10.17487/RFC6831, January 2013, <https://www.rfc-editor.org/info/rfc6831>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8200] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

[RFC8378] Moreno, V. and D. Farinacci, “Signal-Free Locator/ID Separation Protocol (LISP) Multicast”, RFC 8378, DOI 10.17487/RFC8378, May 2018, <https://www.rfc-editor.org/info/rfc8378>.

[RFC8704] Sriram, K., Montgomery, D., and J. Haas, “Enhanced Feasible-Path Unicast Reverse Path Forwarding”, BCP 84, RFC 8704, DOI 10.17487/RFC8704, February 2020, <https://www.rfc-editor.org/info/rfc8704>.

[RFC9301] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, Ed., “Locator/ID Separation Protocol (LISP) Control Plane”, RFC 9301, DOI 10.17487/RFC9301, October 2022, <https://www.rfc-editor.org/info/rfc9301>.

[RFC9302] Iannone, L., Saucez, D., and O. Bonaventure, “Locator/ID Separation Protocol (LISP) Map-Versioning”, RFC 9302, DOI 10.17487/RFC9302, October 2022, <https://www.rfc-editor.org/info/rfc9302>.

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

[AFN] IANA, “Address Family Numbers”, <http://www.iana.org/assignments/address-family-numbers>.

[CHIAPPA] Chiappa, J., “Endpoints and Endpoint Names: A Proposed Enhancement to the Internet Architecture”, 1999, <http://mercury.lcs.mit.edu/~jnc/tech/endpoints.txt>.

[LISP-VPN] Moreno, V. and D. Farinacci, “LISP Virtual Private Networks (VPNs)”, Work in Progress, Internet-Draft, draft-ietf-lisp-vpn-10, 3 October 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-lisp-vpn-10>.

[RFC1034] Mockapetris, P., “Domain names – concepts and facilities”, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.

[RFC1191] Mogul, J. and S. Deering, “Path MTU discovery”, RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/info/rfc1191>.

[RFC2453] Malkin, G., “RIP Version 2”, STD 56, RFC 2453, DOI 10.17487/RFC2453, November 1998, <https://www.rfc-editor.org/info/rfc2453>.

[RFC2677] Greene, M., Cucchiara, J., and J. Luciani, “Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP)”, RFC 2677, DOI 10.17487/RFC2677, August 1999, <https://www.rfc-editor.org/info/rfc2677>.

[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, “Generic Routing Encapsulation (GRE)”, RFC 2784, DOI 10.17487/RFC2784, March 2000, <https://www.rfc-editor.org/info/rfc2784>.

[RFC3056] Carpenter, B. and K. Moore, “Connection of IPv6 Domains via IPv4 Clouds”, RFC 3056, DOI 10.17487/RFC3056, February 2001, <https://www.rfc-editor.org/info/rfc3056>.

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol”, RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.

[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, “Randomness Requirements for Security”, BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>.

[RFC4459] Savola, P., “MTU and Fragmentation Issues with In-the-Network Tunneling”, RFC 4459, DOI 10.17487/RFC4459, April 2006, <https://www.rfc-editor.org/info/rfc4459>.

[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, “Multiprotocol Extensions for BGP-4”, RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.

[RFC4821] Mathis, M. and J. Heffner, “Packetization Layer Path MTU Discovery”, RFC 4821, DOI 10.17487/RFC4821, March 2007, <https://www.rfc-editor.org/info/rfc4821>.

[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., “Report from the IAB Workshop on Routing and Addressing”, RFC 4984, DOI 10.17487/RFC4984, September 2007, <https://www.rfc-editor.org/info/rfc4984>.

[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, “Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites”, RFC 6832, DOI 10.17487/RFC6832, January 2013, <https://www.rfc-editor.org/info/rfc6832>.

[RFC6835] Farinacci, D. and D. Meyer, “The Locator/ID Separation Protocol Internet Groper (LIG)”, RFC 6835, DOI 10.17487/RFC6835, January 2013, <https://www.rfc-editor.org/info/rfc6835>.

[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, “IPv6 and UDP Checksums for Tunneled Packets”, RFC 6935, DOI 10.17487/RFC6935, April 2013, <https://www.rfc-editor.org/info/rfc6935>.

[RFC6936] Fairhurst, G. and M. Westerlund, “Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums”, RFC 6936, DOI 10.17487/RFC6936, April 2013, <https://www.rfc-editor.org/info/rfc6936>.

[RFC7052] Schudel, G., Jain, A., and V. Moreno, “Locator/ID Separation Protocol (LISP) MIB”, RFC 7052, DOI 10.17487/RFC7052, October 2013, <https://www.rfc-editor.org/info/rfc7052>.

[RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-Pascual, J., and D. Lewis, “Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations”, RFC 7215, DOI 10.17487/RFC7215, April 2014, <https://www.rfc-editor.org/info/rfc7215>.

[RFC8060] Farinacci, D., Meyer, D., and J. Snijders, “LISP Canonical Address Format (LCAF)”, RFC 8060, DOI 10.17487/RFC8060, February 2017, <https://www.rfc-editor.org/info/rfc8060>.

[RFC8061] Farinacci, D. and B. Weis, “Locator/ID Separation Protocol (LISP) Data-Plane Confidentiality”, RFC 8061, DOI 10.17487/RFC8061, February 2017, <https://www.rfc-editor.org/info/rfc8061>.

[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, “UDP Usage Guidelines”, BCP 145, RFC 8085, DOI 10.17487/RFC8085, March 2017, <https://www.rfc-editor.org/info/rfc8085>.

[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., “Path MTU Discovery for IP version 6”, STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/info/rfc8201>.

[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. Völker, “Packetization Layer Path MTU Discovery for Datagram Transports”, RFC 8899, DOI 10.17487/RFC8899, September 2020, <https://www.rfc-editor.org/info/rfc8899>.

[RFC9299] Cabellos, A. and D. Saucez, Ed., “An Architectural Introduction to the Locator/ID Separation Protocol (LISP)”, RFC 9299, DOI 10.17487/RFC9299, October 2022, <https://www.rfc-editor.org/info/rfc9299>.

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

Первая благодарность Dave Oran за посеянные семена исходных идей LISP. Его консультации продолжают приносить пользу авторам LISP.

Особая признательность выражается Noel Chiappa за многолетнее подталкивание к архитектуре отделения местоположения от идентификации, а также за подробные обзоры архитектуры и документов LISP в сочетании с энтузиазмом, направленным на то, чтобы сделать LISP практичным для постепенного внедрения в Internet.

Первоначальные авторы благодарят множество людей, которые внесли свой вклад в обсуждение идей при подготовке этого предложения. Среди них Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller, Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston, David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Terry Manderson, Roger Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari Arkko, Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu, Dhirendra Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina Ermagan, Fabio Maino, Victor Moreno, Chris White, Clarence Filsfils, Alia Atlas, Florin Coras, Alberto Rodriguez.

Эта работа началась в исследовательской группе Routing (RRG) под эгидой IRTF. Индивидуальное представление превратилось в документ рабочей группы IETF LISP, который стал этим RFC.

Рабочая группа LISP хотела бы выразить особую благодарность Jari Arkko (Internet Area AD во время подготовки документов LISP к IESG Last Call) за его детальные обзоры и комментарии на 7 Working Group Last Call при подготовке документов в качестве Standards Track RFC.

Текущие авторы хотели бы выразить искреннюю признательность всем, кто помогал представить LISP в процессе IETF Standards Track. Среди них Joel Halpern, Luigi Iannone, Deborah Brungard, Fabio Maino, Scott Bradner, Kyle Rose, Takeshi Takahashi, Sarah Banks, Pete Resnick, Colin Perkins, Mirja Kühlewind, Francis Dupont, Benjamin Kaduk, Eric Rescorla, Alvaro Retana, Alexey Melnikov, Alissa Cooper, Suresh Krishnan, Alberto Rodriguez-Natal, Vina Ermagan, Mohamed Boucadair, Brian Trammell, Sabrina Tanamal, John Drake. Их влад существенно улучшил архитектуру и протоколы LISP в плане безопасности, расширяемости и отказоустойчивости.

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

Dino Farinacci

lispers.net

San Jose, CA

United States of America

Email: farinacci@gmail.com

 

Vince Fuller

vaf.net Internet Consulting

Email: vince.fuller@gmail.com

 

Dave Meyer

1-4-5.net

Email: dmm@1-4-5.net

 

Darrel Lewis

Cisco Systems

San Jose, CA

United States of America

Email: darlewis@cisco.com

 

Albert Cabellos (редактор)

Universitat Politecnica de Catalunya

c/ Jordi Girona s/n

08034 Barcelona

Spain

Email: acabello@ac.upc.edu

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

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

nmalykh@protokols.ru

---