Label Distribution Protocol

Label Distribution Protocol

17.12.2020

LDP (эл-ди-пи, англ. Label Distribution Protocol — протокол распределения меток) — протокол, с помощью которого два LER (англ. Label Edge Router — граничный маршрутизатор меток) в сети MPLS обмениваются информацией об отображении меток. Два LER называются LDP пирами. Обмен информацией между LER двунаправленный.

Общие сведения

Протокол распределения меток (LDP) предоставляет LSR (англ. Label Switching Router — коммутирующий метки маршрутизатор) средства для запроса, распространения и выпуска информации о привязке префикса метки для одноранговых маршрутизаторов в сети. LDP позволяет LSR обнаруживать потенциальные одноранговые узлы и устанавливать сеансы LDP с этими одноранговыми узлами с целью обмена информацией о привязке меток.

Другими словами, LDP используется для установления транспортных LSP (англ. Label Switch Path — пути коммутации меток) MPLS, когда управление трафиком не требуется. Он устанавливает LSP, которые следуют существующей таблице IP-маршрутизации, и особенно хорошо подходит для создания полной сети LSP между всеми маршрутизаторами в сети.

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

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

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

Основным преимуществом LDP над RSVP является простота настройки полной сети туннелей с использованием незапрашиваемого режима, поэтому он чаще всего используется в этом режиме для настройки базовой сети туннелей, необходимой для VPN уровня 2 и уровня 3.

Установка соседских отношений

Установление соседских отношений между маршрутизаторами осуществляется в две фазы:

  • обмен сообщениями Hello;
  • установление сессии LDP.
  • Фаза N2 исполняется только при успешном выполнении фазы N1.

    Обмен сообщениями Hello

    Сообщения Hello посылаются маршрутизатором через все интерфейсы, на которых включен LDP, каждые 15 секунд на адрес 224.0.0.2 (all-routers), порт 646, транспортный протокол UDP. Возможен обмен сообщений Hello и между LSR-ами не соединенными непосредственно. В этом случае сообщение посылается на уникастовый адрес.

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

    Holddown timer - промежуток времени, в течение которого, соседи должны послать хотя бы одно сообщение Hello. Если соседи предлагают разное значение, то принять они должны минимальное. Так как протокол UDP не обеспечивают гарантии доставки, то рекомендуется посылать сообщения Hello с периодом в три раза меньшим, чем Holddown timer. Если Holddown timer равен 0, то принимаются следующие значения по умолчанию:

    • 15 сек. - для обыкновенных hello сообщений на адрес all-routers;
    • 45 сек. - для сообщений посылаемых на конкретный адрес (Targeted Hello).

    Значение Holddown timer равное 0xFFFF означает бесконечность, но зачем оно - RFC умалчивает.

    T bit - (Targeted Hello) если данный бит 1, то это означает, что сообщение послано на конкретный (unicast) адрес, иначе сообщение послано на 224.0.0.2.

    R bit - (Request Send Targeted Hellos) если данный бит 1, то это означает, что получатель должен ответить на это сообщение (Hello), иначе не должен. Данный бит может быть установлен в 1, только в случае если T-bit=1.

    Примечание: Targeted Hello используются при реализации дополнительного функционала на базе MPLS.

    Transport Address - данное поле в Hello пакете не обязательно. Если оно присутствует, то адрес, указанный в нем, используется в дальнейшем для установления LDP сессии между устройствами. Если данное поле отсутствует, то для установления сессии должен использоваться адрес источника Hello пакета. Адрес, используемый для установки LDP сессии, мы будем называть "транспортный адрес".

    Configuration Sequence Number - Поле содержит номер конфигурации. При изменении настроек на LSR, соответственно меняется этот номер. Изменение номера может вызывать переустановку LDP сессии (а может и не вызывать - RFC тут не однозначно).

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

    • LSR-у административно запрещено принимать сообщения hello определенного типа (например, TargetHello) или с определенного адреса;
    • Не совпадения типов транспортных адресов (например, IPv4 и IPv6).

    Установление LDP сессии

    LDP сессия функционирует поверх TCP/IP (порт 646).

    LSR1 и LSR2 при обмене сообщениями hello узнают транспортные адреса друг друга. Если транспортный адрес LSR1 больше чем транспортный адрес LSR2, то LSR1 становиться "активным" соседом, а LSR2 "пассивным", иначе, наоборот. Далее, LDP сессия устанавливается по следующему сценарию.

  • "Активный" сосед устанавливает TCP/IP сессию на порт 646.
  • "Активный" сосед посылает сообщение Init, включающее в себя свои параметры LDP сессии (формат см.далее).
  • "Пассивный" сосед проверяет параметры LDP сессии в сообщении Init на предмет совместимости с локальными настройками LDP.
  • "Пассивный" сосед отвечает сообщением Init , включающее в себя свои параметры LDP сессии.
  • "Активный сосед проверяет параметры LDP сессии в сообщении Init на предмет совместимости с локальными настройками LDP
  • Сессия установлена.
  • Если на каком-то этапе происходит что-то не предвиденное (приходит не тот тип пакета, ожидаемое сообщение не приходит вообще, или не совпадают параметры LDP сессии в сообщении Init и т.п.), то сессия считается не установленной. LSR, обнаруживший ошибку посылает сообщение Shutdown или Reject своему соседу.

    Сообщение Init

    Сообщение Init содержит следующую информацию:

    Protocol Version - версия протокола.

    KeepAlive Time - максимальное время между служебными сообщениями KeepAlive. Обе стороны могут предлагать различные значения - использоваться должно минимальное.

    A-bit, Label Advertisement Discipline - режим обмена информацией о метках. Возможно использование двух режимов обмена информацией о метках:

    • 1 - Downstream On Demand;
    • 0 - Downstream Unsolicited.

    D-but, Loop Detection - механизм предотвращения циклов LSP. 0 - выключен, 1 - включен.

    PVLim, Path Vector Limit - Переменная используется для работы механизма предотвращения циклов.

    Max PDU Length - LDP сообщения группируются в PDU (Protocol Data Units) и передаются в одном пакете TCP/IP. Max PDU Length - означает максимально возможную длину совмещенных сообщений LDP в байтах. Соседи могут предлагать различные значения, но оба должны выбрать минимальное. Заметим, что даже одно сообщение упаковывается внутрь PDU.

    Receiver LDP Identifier - Идентификатор пространства меток (или Label Space Identifier). Формат поля следующий: LSR_ID:Label_Space_ID. LSR_ID это идентификатор LSR. Данный идентификатор должен быть уникален в рамках домена MPLS и един для каждого LSR-а. Label_Space_ID - это идентификатор множества меток. Label Space Identifier указывается в заголовке PDU, идентифицируя тем самым соседа и интерфейс по которому установлено соседство. Например, два LSR-а могут быть соединены двумя каналами, и для каждого канала должен быть выделен разные Label Space Identifier, отличаться которые будут только значением Label_Space_ID.

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

    LDP сессия устанавливается при выполнении следующих условий:

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

    Несовпадение PVLim, в соответствии с RFC не должно приводить к закрытию сессии, но может вызывать предупреждение на LSR.

    Сообщения KeepAlive

    За каждой сессией LDP LSR должен закреплять таймер. После получения любого сообщения LDP, LSR устанавливает таймер в 00:00 и снова запускает его. До достижения таймером значения "KeepAlive Time" соседний LSR должен прислать любое LDP сообщение. Если у соседа нет информативных сообщений для пересылки, то он должен послать сообщение KeepAlive.

    Примечание: При конкретной реализации таймер может работать как от 00:00 до "KeepAlive Time", так и в обратную сторону.

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

    Параметры функционирования LDP

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

    • режим обмена информацией о метках (Label Distribution Mode)
    • режим контроля над распространением меток (Label Distribution Control)
    • механизм сохранения меток (Label Retention Mode)

    Режим обмена информацией о метках

    Между соседями возможно использования двух режимов обмена информацией о метках:

    • Downstream On Demand - с запросом;
    • Downstream Unsolicited - без запроса.

    При режиме Downstream On Demand LSR должен запрашивать метку для создания LSP (для FEC) от соседнего LSR, который является next-hop-ом для этого FEC. При режиме Downstream Unsolicited LSR для каждого FEC находящегося у него в таблице IP-маршрутизации назначает метку и рассылает ее всем своим соседям. Если для соседнего LSR исходный LSR является next-hop-ом, то метка устанавливается в таблицу коммутации.

    Механизм контроля над распространением меток

    Также существует несколько механизмов контроля над распространением меток (Label Distribution Control Mode):

    • Independent Label Distribution Control - независимый контроль;
    • Ordered Label Distribution Control - упорядоченный контроль.

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

    Режим сохранения меток

    Режим сохранения меток (Label Retention Mode)

    • Conservative Label Retention Mode (сдержанный режим сохранения меток);
    • Liberal Label Retention Mode (свободный режим сохранения меток).

    При использовании сдержанного режима сохранения меток при уничтожении маршрута на FEC метка удаляется. Для восстановления LSP необходимо, что бы метка была заново выделена соседним NH-LSR-ом. Если используется свободный режим сохранения меток, то при уничтожении маршрута на FEC метка не удаляется, а лишь помечается как неактивная. И в случае, если маршрут на FEC восстанавливается через тот же NH-LSR, то метка не запрашивается, а используется старая, статус которой меняется на активный.

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

    Протокол LDP должен реагировать на следующие события:

    • появления новой записи FEC в таблице маршрутизации;
    • исчезновение записи FEC из таблицы маршрутизации;
    • смена next-hop для записи FEC.

    Возможные комбинации режимов работы протокола LDP, а так же примеры функционирования приведены в табл. 1.

    При исчезновении записи FEC из таблиц маршрутизации все LSR должны в обязательном порядке отозвать назначенные метки для коммутации FEC у своих соседей. Делается это посредством посылки сообщения Label Withdraw.

    Механизм предотвращения циклов

    Протокол LDP имеет в своем составе механизм предотвращения циклов. Назначение этого механизма не допускать зацикливания запросов и маршрутов. Данный эффект достигается включением во все сообщения Label Mapping и Label Mapping Request информации об LSR через которые данные запросы прошли. В случае если LSR-ы функционируют в режиме Ordered Control данный эффект достигается легко. Если LSR-ы используют Independed Control, то в этом случае LSR-ы должны заново отсылать запросы и ответы на них, так как информация о LSR-ах, через которые прошли запросы, будет обновляться.

    Механизм предотвращения циклов может и не использоваться, так как по идее отсутствие циклов должен гарантировать протокол IP-маршрутизации, информацию от которого использует LDP.

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

    Типы сообщений

    В таблице приведены типы LDP сообщений:

    Безопасность

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

    Спуфинг

    Существует два типа LDP-коммуникации, которые могут стать целью атаки спуфинга.

    1. Открытие обменов, проводимых по UDP.

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

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

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

    2. Сессионная связь по TCP.

    LDP определяет использование опции подписи TCP MD5 для обеспечения подлинности и целостности сообщений сеанса.

    [RFC2385] утверждает, что проверка подлинности MD5 теперь рассматривается некоторыми как слишком слабая для этого приложения. Он также указывает, что аналогичный вариант TCP с более сильным алгоритмом хеширования (в качестве примера он цитирует SHA-1) может быть развернут. Насколько нам известно, такая опция TCP не была определена и развернута. Тем не менее, мы отмечаем, что LDP может использовать любые доступные методы дайджеста сообщений TCP, и когда определен и реализован один, более сильный, чем MD5, обновление LDP для его использования будет относительно простым.

    Конфиденциальность

    LDP не обеспечивает механизма защиты конфиденциальности распространения меток. Требования безопасности протоколов распространения меток по существу идентичны требованиям безопасности протоколов маршрутизации.

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

    DoS-атака

    LDP предоставляет две потенциальные цели для атак типа «отказ в обслуживании» (DoS-атак):

    1. Хорошо известный порт UDP для обнаружения LDP.

    Администратор LSR может устранить угрозу DoS-атак с помощью Basic Hello, убедившись, что LSR напрямую подключен только к одноранговым узлам, которым можно доверять, чтобы они не инициировали такую ​​атаку.

    Интерфейсы с одноранговыми узлами внутри домена администратора не должны представлять угрозы, поскольку внутренние узлы находятся под контролем администратора. Интерфейсы с одноранговыми узлами, внешними по отношению к домену, представляют потенциальную угрозу, в отличие от внешних одноранговых узлов. Администратор может уменьшить эту угрозу, подключив LSR только к внешним партнерам, которым можно доверять, чтобы они не инициировали атаку Basic Hello. DoS-атаки через Extended Hello сообщения потенциально представляют собой более серьезную угрозу. Эта угроза может быть устранена путем фильтрации расширенных приветствий с использованием списков доступа, определяющих адреса, с которыми разрешено расширенное обнаружение. Однако для выполнения фильтрации требуется ресурс LSR. В среде, где можно идентифицировать надежное облако MPLS, LSR на край облака может быть использован для защиты внутренних LSR от DoS-атак с помощью расширенных приветствий путем фильтрации расширенных приветствий, исходящих за пределами доверенного облака MPLS, принимая только те, которые исходят с адресов, разрешенных списками доступа. Эта фильтрация защищает LSR внутри облака, но потребляет ресурсы на границах.

    2. Хорошо известный порт TCP для установления сеанса LDP.

    Как и другие протоколы уровня управления, использующие TCP, LDP может быть целью DoS-атак, таких как SYN-атаки. LDP не более или менее уязвим для таких атак, чем другие протоколы уровня управления, использующие TCP.

    Угрозу таких атак можно несколько снизить за счет следующего:

    • LSR должен избегать беспорядочного прослушивания TCP для установления сеанса LDP. Он должен использовать только прослушивания, специфичные для обнаруженных одноранговых узлов. Это позволяет отбрасывать атакующие пакеты на раннем этапе их обработки, поскольку они с меньшей вероятностью будут соответствовать существующим или выполняющимся соединениям.
    • Использование опции MD5 в некоторой степени помогает, поскольку предотвращает принятие SYN, если контрольная сумма сегмента MD5 не является действительной. Однако получатель должен вычислить контрольную сумму, прежде чем он сможет принять решение об отказе от приемлемого в других отношениях сегмента SYN.
    • Использование механизмов списка доступа, применяемых на границе облака MPLS способом, аналогичным предложенному выше для Extended Hello, может защитить внутреннюю часть от атак, исходящих из-за пределов облака.