RFC 4026 Provider Provisioned Virtual Private Network (VPN) Terminology

Network Working Group                                       L. Andersson
Request for Comments: 4026                                     T. Madsen
Category: Informational                                         Acreo AB
                                                              March 2005

Provider Provisioned Virtual Private Network (VPN) Terminology

Терминология для предоставляемых провайдером VPN

PDF

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

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

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

Copyright (C) The Internet Society (2005).

Тезисы

Широкий интерес к предоставляемым провайдерами решениям для виртуальных частных сетей (VPN1) привел к появлению документов, предлагающих различные и перекрывающиеся решения. Рабочие группы IETF (сначала PPVPN2, затем L2VPN3 и L3VPN4) обсудили эти предложения и документированные спецификации. Это привело к разработке отчасти нового набора концепций, используемых для описания множества услуг VPN.

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

Оглавление

Исключено в версии HTML.

1. Введение

В бывшую рабочую группу PPVPN, а затем в группы L2VPN, L3VPN и PWE3 было представлено довольно большое число документов, решающих задачи из одной области — предоставления провайдерами виртуальных частных сетей для своих абонентов. Документы были связаны с широким спектром услуг, но среди предложенных решений было много общего.

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

Этот документ предлагает основу для унифицированной терминологии рабочим группам L2VPN и L3VPN. В некоторых случаях близкие концепции рабочей группы PWE3 использованы как ссылки.

2. Терминология PPVPN

Концепции и термины в рассмотренном ниже списке собраны из документов Internet Draft, присланных в почтовые конференции L2VPN и L3VPN (ранее в PPVPN), и RFC, относящихся к рабочим группам L2VPN и L3VPN. Основное внимание уделяется терминам и понятиям, относящимся к PPVPN, но это не соблюдается строго. Например, некоторые понятия и термины в областях PWE3 и (G)MPLS тесно связаны с рассматриваемой темой. Авторы пытались найти истоки терминов и понятий.

Документ рассчитан на полный охват концепций основных документов рабочих групп L2VPN и L3VPN, т. е. [L3VPN-REQ], [L2VPN-REQ], [L3VPN-FRAME], [L2VPN] и [RFC3809]. Цель заключается в создании полного и унифицированного набора понятий для этих документов и, как следствие, всей области PPVPN. Для этого нужно рассмотреть аспекты разработки концепций.

Документ разбит на 4 основных раздела. В разделе 4 рассмотрены различные услуги, которые описаны или будут опсаны, в разделе 5 описаны компоненты, используемые для спецификации этих услуг, а в разделе 6 перечислены требуемые для услуг функции. В разделе 7 рассмотрены некоторые типовые устройства, используемые в сетях абонентов и провайдеров.

3. Предоставляемые провайдером услуги VPN

В этом разделе определяется терминология, связанная с набором услуг, заданным рабочими группами L2VPN и L3VPN. Понятие «псевдопровода» относится к рабочей группе PWE3 и включено для справки. Требования к предоставляемым провайдерами VPN заданы в [L3VPN-REQ].

Все приведенные термины и сокращения снабжены кратким описанием сервиса. Список структурирован и сначала представлена наиболее общая информация. Имена служб, над которыми работает IETF помещены в начало списка, а более старые термины — в конец.

3.1. L3VPN

L3VPN5 соединяет множество хостов и маршрутизаторов на основе адресов L3, как описано в [L3VPN-FRAME].

3.2. L2VPN

В этом документе описаны три типа L2VPN6 — виртуальные частные провода — VPWS7 (параграф 3.4), виртуальные частные ЛВС — VPLS8 (параграф 3.3) и услуги ЛВС для протокола IP — IPLS9 (параграф 3.5).

3.3. VPLS

VPLS представляет собой услугу провайдера, эмулирующую полную функциональность традиционной ЛВС. VPLS позволяет соединить несколько сегментов ЛВС через сеть с коммутацией пакетов (PSN10) и позволяет удаленным сегментам вести себя как часть единой ЛВС. Первыми работами, определившими решени и протокол для VPLS были [L2VPN-REQ], [VPLS-LDP] и [VPLS].

В VPLS сеть провайдера эмулирует обучающийся мост и решения о пересылке принимаются на основе MAC-адреса или MAC-адреса и тега VLAN.

3.4. VPWS

VPWS представляет собой устройство (канал) «точка-точка», соединяющее два граничных устройства клиента (CE11). Канал является логическим и организуется через сеть с коммутацией пакетов. CE в сети абонента соединяется с PE12 в сети провайдера через устройство присоединения — AC13 (параграф 6.1), которое может быть логическим или физическим.

Устройства PE в ядре сети соединяются псевдопроводом — PW14.

Устройствами CE могут быть маршрутизаторы, мосты, коммутаторы или хосты. В некоторых реализациях набор VPWS служит для создания многосайтовой сети L2VPN. Пример решения VPWS представлен в [PPVPN-L2VPN].

VPWS отличается от VPLS (параграф 3.3) в том, что VPLS имет многоточечную структуру (point to multipoint), а VPWS — структуру «точка-точка» (см. [L2VPN]).

3.5. IPLS

Сервис IPLS очень похож на VPLS (параграф 3.3), за исключением перечисленных ниже отличий.

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

  • Предполагается, что сервис будет применяться только для пакетов IP и протоколов поддержки, таких как ICMP и ARP (кадры L2, содержащие другие протоколы, не поддерживаются).

  • К пакетам IP относятся пакеты IPv4 и IPv6.

Хотя этот сервис является функциональным подмножеством VPLS, он рассматривается отдельно, поскольку может поддерживаться на основе других механизмов, что позволяет реализовать сервис на некоторых аппаратных платформах не поддерживающих полную функциональность VPLS [L2VPN].

3.6. PW

Рабочая группа IETF PWE3 создала спецификации псевдопроводов, которые представляют собой эмулируемые соединения «точка-точка» через сеть с коммутацией пакетов и позволяют соединить пару узлов с любой технологией L2. PW используют некоторые общие компоненты и архитектурные конструкции с решениями «точка-множество точек», например, PE (параграф 5.2) и CE (параграф 5.1). Первое решение для PW предложено в [TRANS-MPLS]. Форматы инкапсуляции используемые в VPWS, VPLS и PW, описаны в [ENCAP-MPLS]. Требования к PW представлены в [RFC3916], а в работе [PWE3-ARCH] описана архитектурная модель PW.

3.7. TLS

Обозначение TLS15 изначально применялось для сервиса VPLS, но сейчас от него отказались.

3.8. VLAN

Термин VLAN16 был введен стандартом IEEE 802.1Q и обозначает метод разделения трафика ЛВС путем размещения специальных метог (тегов) в кадрах Ethernet. В расширенном смысле термин VLAN используется для обозначения трафика, разделяемого с помощью тегов Ethernet или похожих механизмов.

3.9. VLLS

Термин VLLS17 был заменен термином VPWS. Обозначение VLLS использовалось в устаревшем документе по созданию метрик, позволяющих сравнивать различные решения L2VPN, работа над которым была прервана.

3.10. VPN

Термин VPN является базовым обозначением публичных и частных виртуальных сетей для групп пользователей, отделенных от других пользователей сети, которые могут взаимодействовать между собой как будто в частной сети. Уровень разделения пользователей можно повысить (например, с помощью сквозного шифрования), но это выходит за рамки задач рабочей группы IETF VPN. Определение VPN заимствовано из [RFC2764].

В работе [L3VPN-FRAME] термин VPN обозначает конкретный набор сайтов как сеть intranet или extranet, которая может быть настроена для взаимодействия. Отметим, что сайт входит по крайней мере в одну сеть VPN и может участвовать во множестве сетей.

В этом документе термин VPN служит также базовым обозначением всех типов сервиса, перечисленных в разделе 3.

3.11. VPSN

Термин VPSN18 заменен термином VPLS. Требования к сервису были собраны из требований к L3VPN [L3VPN-REQ] и L2VPN [L2VPN-REQ].

4. Классификация VPN

Терминология в [RFC3809] определена на основе рисунка 1.

                         PPVPN
           ________________|__________________
          |                                   |
         L2                                  L3
    ______|_____                        ______|______
   |            |                      |             |
  P2P          P2M                 На базе PE    На базе CE
(VPWS)     _____|____            ______|____         |
          |          |          |           |        |
         VPLS      IPLS     BGP/MPLS  Виртуальный  IPsec
                             IP VPN  маршрутизатор

Рисунок 1.


На рисунке 1 представлена систематика технологий PPVPN, а ниже приведены некоторые определения.

CE-based VPN — VPN на основе CE

Подход к организации VPN, при котором сеть провайдера не знает об абонентских VPN, которые известны лишь устройствам CE. Все связанные с VPN процедуры выполняются на устройствах CE, а PE ничего не знают о принадлежности трафика к VPN (см. также [L3VPN-FRAME]).

PE-Based VPNs — сети VPN на основе PE

Модель L3 VPN, в которой сеть сервис-провайдера служит для соединения сайтов абонента с использованием общих ресурсов. В частности, устройства PE поддерживают состояние VPN и изолируют пользователей одной сети VPN от пользователей других сетей. Поскольку все требуемые для VPN состояния поддерживаются в PE, устройства CE могут вести себя как при подключении к частной сети. В частности, на устройствах CE в сети VPN на основе PE не требуется вносить каких-либо изменений или расширять функциональность при подключении к PPVPN вместо частной сети.

Устройства PE знают, что часть трафика относится к VPN и пересылают трафик (через туннели) по IP-адресам получателей и могут учитывать при пересылке другую информацию из заголовка IP в пакете. Конечными точками туннелей являются устройства PE. Для туннелей может применяться разная инкапсуляция при пересылке через сеть SP (например, туннели GRE, IP-in-IP, IPsec, MPLS) [L3VPN-FRAME].

Virtual Router (VR) style — виртуальные маршрутизаторы

Основанная на PE модель VPN, где маршрутизатор PE поддерживает полнофункциональный логический маршрутизатор для каждой обслуживаемой им сети VPN. Каждый логический маршрутизатор поддерживает уникальную таблицу пересылки и свои экземпляры протоколов маршрутизации. Этот тип VPN описан в [L3VPN-VR].

BGP/MPLS IP VPNs — сети IP VPN на основе BGP/MPLS

Основанная на PE модель VPN, где маршрутизатор PE поддерживает отдельную среду пересылки и таблицу пересылки для каждой сети VPN. Для поддержки множества экземпляров таблиц пересылки при использовании единственного экземпляра BGP анонсы маршрутов в BGP/MPLS IP VPN помечаются атрибутами, указывающими контекст VPN. Это решение VPN основано на подходе, описанном в [RFC2547bis].

RFC 2547 Style — стиль RFC 2547

Этот термин применялся в L3VPN для описания расширений для VPN, определенных в информационном RFC 2547 [RFC2547]. Сейчас взамен применяется термин BGP/MPLS IP VPN.

5. Компоненты сервиса

Начиная со спецификаций L3VPN (например, [RFC2547] и [RFC2547bis], а также [L3VPN-VR]), был разработан способ описания компонентов и распределения функций в решениях VPN. В повседневных разговорах о компонентах говорят, как будто они являются физическими устройствами, общими для всех типов сервиса.

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

5.1. Абонентские краевые устройства (CE)

Абонентское граничное устройство CE представляет собой устройство, функциональность которого нужна на площадке абонента для доступа к услугам, заданным бывшей рабочей группой PPVPN, применительно к L3VPN [L3VPN-FRAME]. Концепция была изменена при определении L2VPN и VPN на основе CE. Об этом подробней сказано ниже.

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

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

5.1.1. Именование CE по типу устройства

5.1.1.1. Граничный маршрутизатор абонента (CE-R)

CE-R19 является маршрутизатором в сети абонента, взаимодействующим с сетью провайдера. Имеется много причин применения маршрутизатора в сети клиента, например при использовании приватных адресов IP для L3VPN этот маршрутизатор сможет обеспечить пересылку на основе приватных адресов IP. Другой причиной может служить желание ограничить число MAC-адресов, которые нужно знать в сети провайдера.

Устройства CE-R могут применяться для сервиса L2 и L3.

5.1.1.2. Граничный коммутатор абонента (CE-S)

CE-S20 — это осведомленный о сервисе VPN коммутатор L2 в сети абонента, взаимодействующий с сетью провайдера. В службах VPWS и VPLS не обязательно применять в сети абонента граничный маршрутизатор, поскольку с задачами может справиться коммутатор L2.

5.1.2. Именование CE по услугам

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

5.1.2.1. L3VPN-CE

L3VPN-CE — это устройство или набор устройств на площадке абонента, которые служат для подключения к предоставляемому провайдером сервису L3VPN, например, реализация RFC 2547bis.

5.1.2.2. VPLS-CE

VPLS-CE — это устройство или набор устройств на площадке абонента, которые служат для подключения к предоставляемому провайдером сервису VPLS.

5.1.2.3. VPWS-CE

VPWS-CE — это устройство или набор устройств на площадке абонента, которые служат для подключения к предоставляемому провайдером сервису VPWS.

5.2. Граничные устройства провайдера (PE)

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

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

5.2.1. Именование PE по типу устройства

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

5.2.1.1. Граничный маршрутизатор провайдера (PE-R)

PE-R21 представляет собой устройство сетевого уровня (L3), участвующее в маршрутизации и пересылке пакетов PSN (раздел 8) на основе маршрутных данных.

5.2.1.2. Граничный коммутатор провайдера (PE-S)

PE-S22 представляет собой устройство канального уровня (L2), которое участвует, например, в коммутации Ethernet, принимая решение о пересылке на основе адресов L2.

5.2.2. Именование PE по услугам

5.2.2.1. L3VPN-PE

L3VPN-PE — устройство или набор устройств с функциональностью L3VPN на краю сети провайдера для взаимодействия с сетью абонента.

5.2.2.2. VPWS-PE

VPWS-PE — устройство или набор устройств с функциональностью VPWS на краю сети провайдера для взаимодействия с сетью абонента.

5.2.2.3. VPLS-PE

VPLS-PE — устройство или набор устройств с функциональностью VPLS на краю сети провайдера для взаимодействия с сетью абонента.

5.2.3. Именование PE по месту размещения

Для обеспечения расширяемости в случаях VPLS/VPWS иногда бывает желательно распределить функции PE между несколькими устройствами. Например, можно назначить функции изучения MAC-адресов сравнительно небольшому и недорогому устройству, расположенному близко к сайту абонента, а участие в сигнализации PSN и организацию туннелей PE — PE выполнять на маршрутизаторах, расположенных ближе к ядру сети.

При распределении функций между устройствами нужен протокол обмена информацией между обращенными в сторону сети — N-PE23 (параграф 5.2.3.1) и в сторону пользователя — U-PE24 (параграф 5.2.3.2) устройствами PE.

5.2.3.1. Обращенное к сети устройство (N-PE)

N-PE является устройством, которому назначаются функции сигнализации и управления в распределенном VPLS-PE.

5.2.3.2. Общащенное к клиенту устройство PE (U-PE)

U-PE представляет собой устройство, выполняющее функции пересылки и принятия решений о коммутации на входе в сеть провайдера.

5.3. Ядро сети

5.3.1. Маршрутизатор провайдера (P)

Маршрутизатор провайдера P25 определяется как маршрутизатор в ядре сети, который не имеет интерфейсов непосредственно к абонентам. Следовательно P не хранит состояний VPN и не знает о VPN.

5.4. Именование в отдельных документах Internet Draft

5.4.1. PE канального уровня (L2PE)

L2PE — общее имя устройств в сети провайдера, реализующих функции L2, требуемые для VPLS или VPWS.

5.4.2. Логическое устройство PE (LPE)

Термин LPE26 берет свое начало в просроченном документе Internet Draft «VPLS/LPE L2VPNs: Virtual Private LAN Services using Logical PE Architecture» и служил для описания набора устройств, используемых в сети провайдера для реализации VPLS. В LPE функции VPLS распределены между небольшими устройствами U-PE (PE-edge) и устройствами в ядре сети N-PE (PE-Core). В решениях LPE устройства PE-edge и PE-Core могут быть соединены через коммутируемый транспорт Ethernet или восходящие каналы (uplink). LPE может также присутствовать в ядре сети в форме одного устройства PE. В этом документе устройства, составляющие LPE, называются N-PE и U-PE.

5.4.3. PE-CLE

Другое название U-PE, предложенное в просроченном документе Internet Draft «VPLS architectures».

5.4.4. PE-Core

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

5.4.5. PE-Edge

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

5.4.6. PE-POP

Другое название U-PE, предложенное в просроченном документе Internet Draft «VPLS architectures».

5.4.7. Краевое устройство VPLS (VE)

Термин VE27 берет свое начало в просроченном документе Internet Draft по распределенным «прозрачным» услугам ЛВС и служил для описания устройств, используемых в сети провайдера для передачи VPLS абоненту. В этом документе VE называются VPLS-PE. Термин считается устаревшим.

6. Функции

В этом разделе собраны термины и понятия, связанные с работой сервиса VPN.

6.1. Устройство присоединения (AC)

В L2 VPN устройство CE подключается к PE с помощью устройства присоединения (AC). AC может быть физическим или логическим каналом.

6.2. Backdoor Link

Backdoor Links — это «закулисный» канал между устройствами CE, организованный конечным пользователем, а не SP. Такие каналы могут служить для соединения устройств CE в многодомных конфигурациях [L3VPN-FRAME].

6.3. Обнаружение конечных точек

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

Требования к обнаружению конечных точек и сигнализации рассмотрены в [L3VPN-REQ]. Они также являются темой уже просроченного документа Internet Draft от команды разработчиков по обнаружению VPN.

6.4. Лавинная рассылка

Функция лавинной рассылки относится к службам L2 — когда PE принимает кадр с неизвестным MAC-адресом получателя, этот кадр требуется переслать во все интерфейсы.

6.5. Изучение MAC-адресов

Функция изучения MAC-адресов относится к службам L2 — когда PE принимает кадр с неизвестным MAC-адресом отправителя, привязка MAC-адреса к порту фиксируется для использования при пересылке в будущем. В решении для VPN канального уровня от рабочей группы L2VPN WG эта функция назначается устройствам VPLS-PE.

6.5.1. Квалифицированное обучение

В квалифицированном обучении на уровне U-PE выполняется изучение в абонентских кадрах Ethernet адресов MAC и тегов VLAN (при наличии тега). Если тегов в кадре нет, предполагается принятая по умолчанию VLAN.

6.5.2. Невалифицированное обучение

При неквалифицированном обучении изучаются только MAC-адреса в абонентских кадрах Ethernet.

6.6. Сигнализация

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

7. Физические устройства

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

7.1. Устройство агрегирования

Устройствами агрегирования обычно служат коммутаторы L2, которые не знают о VPN и лишь агрегируют трафик к узлам сети с большей функциональностью.

7.2. Абонентское оборудование (CPE)

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

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

7.3. MTU

MTU29 — обычно коммутатор L2, размещаемый сервис-провайдером в здании, где размещается несколько абонентов данного провайдера. Термин введен документом Internet Draft, задающим решение VPLS с распределением функций между MTU и PE в контексте [VPLS].

Термин MTU обычно используется в описании работы сети и в контексте развертывания и его не следует применять в спецификациях протоколов, поскольку такая же аббревиатура служит для обозначения максимального размера передаваемого блока (Maximum Transmit Unit).

8. Сети с коммутацией пакетов (PSN)

PSN30 — это сеть, через которую организуются туннели для поддержки сервиса VPN.

8.1. Отличие маршрута (RD)

RD31 [RFC2547bis] — 8-байтовое значение, которое вместе с 4 байтами адреса IPv4 указывает адрес семейства VPN-IPv4. Если в двух VPN используется общий префикс IPv4, устройства PE будут транслировать его в уникальные префиксы VPN-IPv4. Это позволяет использовать одни и те же адреса в разных VPN, поскольку можно в каждой VPN организовать уникальный маршрут к данному префиксу.

8.2. Рефлектор маршрутов

Рефлектором маршрутов называют элемент сети SP, используемый для распространения маршрутов BGP среди поддерживающих протокол BGP маршрутизаторов SP [L3VPN-FRAME].

8.3. Цель маршрута (RT)

Атрибут RT32 [RFC2547bis] можно рассматривать как идентификатор набора сайтов или, более точно, набора таблиц VRF (параграф 8.9).

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

Атрибут RT относится также BGP extended community, используемым в [RFC2547] и [BGP-VPN]. Группа RT служит для ограничения распространения информации VPN заданным набором таблиц VRF. Цель маршрута можно рассматривать как указание набора сайтов или, более точно, набора таблиц VRF.

8.4. Туннель

Туннель является соединением через сеть PSN, которое применяется для передачи трафика через сеть от одного PE к другому. Теннель обеспечивает способы транспортировки пакетов между устройствами PE. Разделение трафика абонентов в туннели обеспечивается с помощью туннельных мультиплексоров (параграф 8.5). Организация туннеля зависит от механизмов туннелирования, предоставляемых PSN, например, туннели могут создаваться на основе заголовков IP, меток MPLS, идентификаторов сессий L2TP или полей GRE Key.

8.5. Туннельный мультиплексор

Туннельный мультиплексор — это просто элемент, передаваемый с пакетом, проходящим через туннель, и позволяющий отличить пакеты разных экземпляров сервиса и отправителей на приемной стороне. В [PPVPN-L2VPN] туннельный мультиплексор имеет формат метки MPLS.

8.6. Виртуальный канал (VC)

VC34 существует внутри туннеля и указывается туннельным мультиплексором. Виртуальный канал идентифицируется VCI (Virtual Channel Identifier). В контексте PPVPN идентификатором VCI служит метка VC или туннельный мультиплексор, а в случае Martini это VCID.

8.7. Метка VC

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

8.8. Внутренняя метка

Термин Inner label служит другим названием метки VC (параграф 8.6).

8.9. Маршрутизация и пересылка VPN (VRF)

В сетях VPN на основе [RFC2547] маршрутизаторы PE поддерживают таблицы VRF, определяющие маршрутизацию и пересылку на уровне сайта. Каждый сайт, к которому подключен маршрутизатор PE, связа с одной из таких таблиц. Поиск адреса IP для получателя конкретного пакета выполняется в данной таблице VRF лишь в том случае, когда пакет принят непосредственно с сайта, связанного с этой таблицей.

8.10. Экземпляр пересылки VPN (VFI)

VFI (VPN Forwarding Instance) — это логический элемент в PE, включающий базу маршрутной информации и данных пересылки для экземпляра VPN [L3VPN-FRAME].

8.11. Экземпляр виртуального коммутатора (VSI)

В контексте канального уровня VSI35 представляет собой экземпляр виртуального коммутатора, который обслуживает один сервис VPLS [L2VPN]. VSI выполняет функции стандартного моста ЛВС (т. е. Ethernet). Пересылку VSI выполняет на основе MAC-адресов и тегов VLAN, возможно с учетом другой информации, относязейся к экземпляру VPLS. Экземпляры VSI выделяются устройством VPLS-PE или (в распределенном варианте) U-PE.

8.12. Виртуальный маршрутизатор (VR)

Виртуальный маршрутизатор (VR36) — это программный или аппаратный модуль для эмуляции физического маршрутизатора. Виртуальные маршрутизаторы имеют независимые таблицы маршрутизации и пересылки IP и изолированы один от другого (см. [L3VPN-VR]).

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

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

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

Большая часть этого документа основана на обсуждениях в командах разработчиков PPVPN auto discovery и l2vpn.

Dave McDysan, Adrian Farrel и Thomas Narten рецензировали документ и внесли много ценных предложений.

Thomas Narten преобразовал близкий к финальному вариант этого документа в формат XML, после того как извлечение приемлемого варианта из Word стало слишком тяжелым. Avri Doria сильно помогла в использовании XML.

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

[L2VPN] Andersson, L. and E. Rosen, «Framework for Layer 2 Virtual Private Networks (L2VPNs)», Work in Progress37, June 2004.

[L2VPN-REQ] Augustyn, W. and Y. Serbest, «Service Requirements for Layer 2 Provider Provisioned Virtual Private Networks», Work in Progress38, October 2004.

[VPLS] Kompella, K., «Virtual Private LAN Service», Work in Progress39, January 2005.

[VPLS-LDP] Lasserre, M. and V. Kompella, «Virtual Private LAN Services over MPLS», Work in Progress40, September 2004.

[BGP-VPN] Ould-Brahim, H., Rosen, E., and Y. Rekhter, «Using BGP as an Auto-Discovery Mechanism for Layer-3 and Layer-2 VPNs», Work in Progress, May 2004.

[L3VPN-FRAME] Callon, R. and M. Suzuki, «A Framework for Layer 3 Provider Provisioned Virtual Private Networks», Work in Progress41, July 2003.

[RFC3809] Nagarajan, A., «Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)», RFC 3809, June 2004.

[L3VPN-REQ] Carugi, M. and D. McDysan, «Service requirements for Layer 3 Virtual Private Networks», Work in Progress42, July 2004.

[RFC2547bis] Rosen, E., «BGP/MPLS IP VPNs», Work in Progress43, October 2004.

[L3VPN-VR] Knight, P., Ould-Brahim, H. and B. Gleeson, «Network based IP VPN Architecture using Virtual Routers», Work in Progress, April 2004.

[PWE3-ARCH] Bryant, S. and P. Pate, «PWE3 Architecture», Work in Progress44, March 2004.

[RFC3916] Xiao, X., McPherson, D., and P. Pate, «Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)», RFC 3916, September 2004.

[PPVPN-L2VPN] Kompella, K., «Layer 2 VPNs Over Tunnels», Work in Progress, June 2002.

[ENCAP-MPLS] Martini, L., «Encapsulation Methods for Transport of Layer 2 Frames Over IP and MPLS Networks», Work in Progress, September 2004.

[TRANS-MPLS] Martini, L. and N. El-Aawar, «Transport of Layer 2 Frames Over MPLS», Work in Progress45, June 2004.

[RFC2547] Rosen, E. and Y. Rekhter, «BGP/MPLS VPNs», RFC 254746, March 1999.

[RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. Malis, «A Framework for IP Based Virtual Private Networks», RFC 2764, February 2000.

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

Loa Anderson

Acreo AB

EMail: loa@pi.se

Tove Madsen

Acreo AB

EMail: tove.madsen@acreo.se


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

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

nmalykh@protocols.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).


1Virtual Private Network.

2Provider Provisioned VPNs — предоставляемые провайдерами VPN.

3Layer 2 VPNs — VPN канального уровня.

4Layer 3 VPNs — VPN сетевого уровня.

5Layer 3 VPN — услуги VPN на сетевом уровне.

6Layer 2 VPN — услуги VPN на канальном уровне.

7Virtual Private Wire Service.

8Virtual Private LAN Service.

9IP-only LAN-like Service.

10Packet switched network.

11Customer Edge.

12Provider Edge.

13Attachment Circuit.

14Pseudowire.

15Transparent LAN Service — «прозрачные» услуги ЛВС.

16Virtual LAN — виртуальная ЛВС.

17Virtual Leased Line Service — услуги виртуальной арендованной линии.

18Virtual Private Switched Network — виртуальная частная коммутируемая сеть.

19Customer Edge Router.

20Customer Edge Switch.

21Provider Edge Router.

22Provider Edge Switch

23Network Facing PE.

24User Facing PE.

25Provider Router.

26Logical PE.

27VPLS Edge.

28Customer Premises Equipment.

29Multi-Tenant Unit — устройство с множеством арендаторов.

30Packet Switched Network

31Route Distinguisher.

32Route Target.

33 VPN Routing and Forwarding — маршрутизация и пересылка VPN.

34Virtual Channel

35Virtual Switch Instance.

36Virtual Router.

37Работа опубликована в RFC 4664. Прим. перев.

38Работа опубликована в RFC 4665. Прим. перев.

39Работа опубликована в RFC 4761. Прим. перев.

40Работа опубликована в RFC 4762. Прим. перев.

41Работа опубликована в RFC 4110. Прим. перев.

42Работа опубликована в RFC 4031. Прим. перев.

43Работа опубликована в RFC 4364. Прим. перев.

44Работа опубликована в RFC 3985. Прим. перев.

45Работа опубликована в RFC 4906. Прим. перев.

46Заменен RFC 4364. Прим. перев.




RFC 4034 Resource Records for the DNS Security Extensions

Network Working Group                                          R. Arends
Request for Comments: 4034                          Telematica Instituut
Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658,                R. Austein
           3755, 3757, 3845                                          ISC
Updates1: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
         3597, 3226                                             VeriSign
Category: Standards Track                                      D. Massey
                                               Colorado State University
                                                                 S. Rose
                                                                    NIST
                                                              March 2005

 

Записи RR для защитных расширений DNS

Resource Records for the DNS Security Extensions

PDF

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

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

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

Copyright (C) The Internet Society (2005).

Тезисы

Этот документ является одним из группы документов, описывающих расширения DNSSEC2. Защитные расширения DNS представляют собой множество записей о ресурсах и изменений в протоколах для обеспечения аутентификации источника данных в системе DNS. В данном документе определены записи для открытых ключей (DNSKEY), подписавшего передачу полномочий (DS), цифровой подписи (RRSIG) и аутентифицированного указания отсутствия (NSEC). Назначение и формат каждой записи подробно описаны в документе с примерами использования записей.

Этот документ отменяет действие RFC 2535 и включает в себя все обновления, предложенные для RFC 2535.

Оглавление

Исключено в версии HTML.

1. Введение

В защитных расширениях DNSSEC добавлены четыре новых типа записей о ресурсах DNS — открытый ключ DNS (DNSKEY3), подпись записи о ресурсе (RRSIG4), Next Secure (NSEC) и подписавший передачу полномочий (DS5). Этот документ определяет назначение каждой RR6, формат RDATA и формат представления записи (ASCII-представление).

1.1. Связанные документы

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

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

В [RFC4035] определены протокольные операции DNSSEC.

Предполагается знакомство читателя с базовыми концепциями DNS, описанными в [RFC1034], [RFC1035], а также последующих документах с обновлениями (в частности, [RFC2181] и [RFC2308]).

В этот документе определены записи DNSSEC о ресурсах. Все числовые коды типов DNS в этом документе указаны в десятичном представлении.

1.2. Зарезервированные слова

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

2. Запись DNSKEY RR

DNSSEC использует криптографию с открытыми ключами для подписания и аутентификации наборов записей о ресурсах DNS (RRset). Открытые ключи хранятся в записях DNSKEY и применяются в процессе аутентификации DNSSEC, описанном в [RFC4035] — зона подписывает свои полномочные RRset, используя секретный ключ и сохраняя соответствующий открытый ключ в DNSKEY RR. Преобразователь может использовать открытый ключ для проверки подписей, покрывающий наборы RRset в зоне, и, таким образом, аутентифицировать их.

DNSKEY RR не предназначены для хранения произвольных открытых ключей и их недопустимо использовать для хранения сертификатов или открытых ключей, не относящихся напрямую к инфраструктуре DNS.

Поле Type для записей DNSKEY RR имеет значение 48.

Записи DNSKEY RR не зависят от класса.

К DNSKEY RR не предъявляется специальных требований в части времени жизни (TTL).

2.1. Формат передачи DNSKEY RDATA

                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Flags            |    Protocol   |   Algorithm   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                                                               /
/                            Public Key                         /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

RDATA для записей DNSKEY RR включает 2-октетное поле Flags, 1-октетные поля Protocol и Algorithm, а также поле Public Key.

2.1.1. Поле Flags

Бит 7 поля Flags является флагом ключа зоны (Zone Key). Если этот бит установлен (1), запись DNSKEY включает ключ зоны DNS и имя владельца DNSKEY RR должно быть именем зоны. Если бит 7 имеет значение 0, запись DNSKEY содержит какой-либо другой открытый ключ DNS и ее недопустимо использовать для проверки подписей RRSIG, которые покрывают наборы RRset.

Бит 15 поля Flags является флагом защищенной точки входа (Secure Entry Point), описанным в [RFC3757]. Если этот бит имеет значение 1, запись DNSKEY содержит ключ, предназначенный для использования в качестве защищенной точки входа. Этот флаг служит лишь подсказкой для программ отладки и подписывания зон о возможности использования данной записи DNSKEY, для валидаторов недопустимо менять свое поведение в процессе проверки подписи на основе значения этого флага. Это также означает, что DNSKEY RR с установленным битом SEP будет требовать установленного флага Zone Key для обеспечения возможности легального создания подписей. Записи DNSKEY RR с установленным битом SEP и сброшенным флагом Zone Key недопустимо использовать для проверки подписей RRSIG, покрывающих RRset.

Биты 0 — 6 и 8 — 14 являются резервными, они должны сбрасываться при создании DNSKEY RR и игнорироваться при получении.

2.1.2. Поле Protocol

Поле Protocol должно иметь значение 3, а DNSKEY RR должна трактоваться, как непригодная в процессе проверки подписи, если это поле имеет другое значение.

2.1.3. Поле Algorithm

Поле Algorithm указывает криптографический алгоритм с открытым ключом и определяет формат поля Public Key. Список типов алгоритма DNSSEC приведен в Приложении A.1

2.1.4. Поле Public Key

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

2.1.5. Замечания по устройству DNSKEY RDATA

Хотя поле Protocol всегда имеет значение 3, оно сохраняется для обеспечения совместимости с ранними версиями записи KEY.

2.2. Формат представления DNSKEY RR

Часть RDATA представляется следующим образом:

поле Flags должно представляться, как десятичное целое число без знака; с учетом определенных в настоящее время флагов возможны значения поля 0, 256 и 257;

поле Protocol должно представляться десятичным целым числом без знака, имеющим значение 3;

поле Algorithm должно представляться десятичным целым числом без знака или с использованием мнемоники, описанной в Приложении A.1;

поле Public Key должно содержать представление ключа Public Key в формате Base64; в тексте Base64 могут использоваться пробелы, определение Base64 дано в работе [RFC3548].

2.3. Пример DNSKEY RR

Приведенная ниже запись DNSKEY RR хранит ключ зоны DNS для домена example.com.

   example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
                                          Cbl+BBZH4b/0PY1kxkmvHjcZc8no
                                          kfzj31GajIQKY+5CptLr3buXA10h
                                          WqTkF7H6RfoRqXQeogmMHfpftf6z
                                          Mv1LyBUgia7za6ZEzOJBOztyvhjL
                                          742iU/TpPSEDhm2SNKLijfUppn1U
                                          aNvv4w==  )

 

Первые четыре тестовых поля указывают имя владельца, TTL, класс и тип RR (DNSKEY). Значение 256 показывает, что флаг Zone Key (бит 7) в поле Flags имеет значение 1. Значение 3 в поле Protocol указывается всегда. Значение 5 указывает алгоритм с открытым ключом. В Приложении A.1 указано, что тип 5 используется для алгоритма RSA/SHA1, следовательно это значение говорит об использовании открытых ключей RSA/SHA1 в соответствии с [RFC3110]. Оставшаяся часть записи содержит представление Base64 для открытого ключа.

3. Запись RRSIG RR

DNSSEC использует криптографию с открытым ключом для подписания и аутентификации наборов записей о ресурсах DNS (RRset). Цифровые подписи хранятся в записях RRSIG и используются в процессе аутентификации DNSSEC, описанном в [RFC4035]. Проверяющий может использовать эти записи RRSIG для аутентификации RRset зоны. Записи RRSIG RR должны применяться только для передачи верификационного материала (цифровых подписей), используемого при защищенных операциях DNS.

Запись RRSIG содержит подпись для RRset с конкретным именем, классом и типом. RRSIG RR указывает интервал достоверности для подписи и использует поля Algorithm, Signer’s Name и Key Tag для идентификации DNSKEY RR, содержащей открытый ключ, который проверяющий может использовать для проверки подписи.

Поскольку все полномочные RRset в зоне должны защищаться цифровой подписью, записи RRSIG RR должны присутствовать для имен, содержащих CNAME RR. Это меняет стандартную спецификацию DNS [RFC1034], в которой указано, что при наличии CNAME для имени, это будет единственный разрешенный для данного имени тип. В подписанной зоне для того же имени, что и CNAME, должны существовать записи RRSIG и NSEC (см. раздел 4).

Поле Type для RRSIG RR имеет значение 46.

Записи RRSIG RR не зависят от класса.

Запись RRSIG RR должна относиться к тому же классу, что и подписываемый ею набор RRset.

Значение TTL для RRSIG RR должно совпадать с TTL подписываемого Rrset. Имеется исключение из правил [RFC2181] для TTL отдельных записей RR внутри RRset – отдельные RRSIG RR с общим именем владельца будут иметь разные значения TTL, если покрываемые ими наборы RRset имеют разные значения TTL.

3.1. Формат передачи RRSIG RDATA

                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 Covered           |  Algorithm    |     Labels    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Original TTL                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Signature Expiration                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Signature Inception                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Key Tag            |                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         Signer's Name         /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                                                               /
/                            Signature                          /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

RDATA для записей RRSIG RR включает двухоктетное поле Type Covered, однооктетные поля Algorithm и Labels, четырехоктетные поля Original TTL, Signature Expiration и Signature Inception, двухоктетное поле Key tag, а также поля Signer’s Name и Signature.

3.1.1. Type Covered

Поле Type Covered указывает тип RRset, покрываемого этой записью RRSIG.

3.1.2. Algorithm Number

Поле Algorithm Number указывает криптографический алгоритм, использованный для создания подписи. Список алгоритмов DNSSEC приведен в Приложении A.1

3.1.3. Labels

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

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

В значении поля Labels недопустимо учитывать пустую (корневую) метку, завершающую имя владельца или метку-шаблон (при ее наличии). Значение поля Labels должно быть не больше числа меток в имени владельца RRSIG. Например, для www.example.com. поле Labels имеет значение 3, а для *.example.com. — 2. Для корня (.) поле Labels имеет значение 0.

Хотя шаблонные метки не учитываются в поле Labels записей RRSIG RR, такие метки являются частью имени владельца RRset при генерации и проверке подписи.

3.1.4. Original TTL

Поле Original TTL указывает значение TTL для покрываемого подписью RRset, как оно появляется в полномочной зоне.

Поле Original TTL требуется по причине того, что кэширующие преобразователи декрементируют значения TTL для кэшируемых RRset. Для проверки подписи проверяющему требуется знать исходное значение TTL. В [RFC4035] описано использование значения поля Original TTL для восстановления исходного значения TTL.

3.1.5. Signature Expiration и Signature Inception

Поля Signature Expiration и Signature Inception указывают период действия подписи. Запись RRSIG недопустимо использовать для аутентификации до момента создания и после завершения срока ее действия.

Поля Signature Expiration и Signature Inception задают дату и время в форме 32-битового целого числа без знака с сетевым порядком байтов, указывающего количество секунд с 00:00:00 часов UTC 1 января 1970 г, без учета високосных секунд. Максимальный интервал, который может быть задан в таком формате, составляет приблизительно 136 лет. Запись RRSIG RR может иметь поле Expiration, значение которого численно меньше значения поля Inception, если значение первого находится вблизи границы 32-битового диапазона или подпись имеет очень большой срок действия. По этой причине все операции сравнения для этих полей должны использовать арифметику порядковых номеров, описанную в [RFC1982]. Прямым следствием этого является то, что значения полей не могут указывать даты, отличающиеся от текущей более, чем на 68 лет в ту или иную сторону.

3.1.6. Key Tag

Поле Key Tag содержит значение тега ключа DNSKEY RR, который «заверяет» эту подпись, с сетевым порядком байтов. Расчет значений Key Tag описан в Приложении B.

3.1.7. Signer’s Name

Значение поля Signer’s Name указывает имя владельца записи DNSKEY RR, которое проверяющий предложил использовать для проверки этой подписи. Поле Signer’s Name должно содержать имя зоны, покрываемой набором RRset. Отправителю недопустимо использовать сжатие имени DNS для поля Signer’s Name при передаче RRSIG RR.

3.1.8. Signature

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

3.1.8.1. Расчет подписи

Подпись учитывает RRSIG RDATA (за исключением поля Signature) и набор RRset, указанный именем владельца RRSIG, а также поля класса RRSIG и RRSIG Type Covered. RRset имеет каноническую форму (см. раздел 6) и набор RR(1),…RR(n) подписывается следующим образом:

signature = sign(RRSIG_RDATA | RR(1) | RR(2)... )

где | означает конкатенацию (слияние);

RRSIG_RDATA представляет формат передачи полей RRSIG RDATA с канонической формой Signer’s Name и исключенным полем Signature.

RR(i) = owner | type | class | TTL | RDATA length | RDATA

owner — полное (fully qualified) имя владельца RRset в канонической форме (для записей RR с шаблонами имен владельца символ шаблона включается в имя);

все RR должны иметь то же имя владельца, которое указано в RRSIG RR;

все RR должны иметь тот же класс, который указан в RRSIG RR;

все RR в RRset должны иметь тип RR, указанный в поле Type Covered записи RRSIG RR;

все RR в RRset должны иметь значение TTL, указанное в поле Original TTL записи RRSIG;

все имена DNS в полях RDATA каждой записи RR должны иметь каноническую форму;

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

Подробная информация о канонической форме и упорядочении RRset приведена в параграфах 6.2 и 6.3.

3.2. Формат представления RRSIG RR

Ниже показан формат представления части RDATA.

Поле Type Covered представляется мнемоникой типа RR. Если мнемоническое значение не известно, должно применяться представление TYPE, описанное в разделе 5 [RFC3597].

Значение поля Algorithm должно быть представлено десятичным целым числом без знака или мнемоническим значением, как указано в Приложении A.1.

Значение поля Labels должно представляться десятичным целым числом без знака.

Значение поля Original TTL должно представляться десятичным целым числом без знака.

Значения полей Signature Expiration Time и Signature Inception Time должны представляться десятичным целым числом без знака, указывающим число секунд с начала суток 1 января 1970 года, или указывать время часового пояса UTC в формате YYYYMMDDHHmmSS, где

YYYY — год (0001-9999, см. параграф 3.1.5);

MM — месяц (01-12);

DD — число месяца (01-31);

HH — число часов в 24-часовом формате (00-23);

mm — число минут (00-59);

SS — число секунд (00-59).

Отметим, что форматы представления времени всегда можно различить, поскольку формат YYYYMMDDHHmmSS всегда использует 14 цифр, а 32-битовое целое число без знака не может иметь более 10 цифр.

Значение поля Key Tag должно представляться десятичным целым числом без знака.

Значение поля Signer’s Name должно представляться в виде доменного имени.

Поле Signature указывает подпись в представлении Base64, где разрешено использовать пробельные символы (см. параграф 2.2).

3.3. Пример RRSIG RR

Приведенная ниже запись RRSIG RR содержит набор A RRset для хоста host.example.com.

   host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
                                  20030220173103 2642 example.com.
                                  oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
                                  PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
                                  B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
                                  GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
                                  J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )

 

Первые 4 поля указывают имя владельца, TTL, класс, и тип RR (RRSIG). Значение A представляет поле Type Covered. Значение 5 указывает использованный для создания подписи алгоритм (RSA/SHA1). Значение 3 указывает число меток в исходном имени владельца. Значение 86400 в RRSIG RDATA представляет собой Original TTL для покрываемого подписью набора A RRset. Значения 20030322173103 и 20030220173103 указывают даты окончания и создания подписи, соответственно. 2642 указывает Key Tag, а example.com. — имя подписавшего (Signer’s Name). Остальная часть записи — представление Base64 для подписи.

Отметим, что комбинация имени владельца, класса и покрываемого типа в RRSIG RR указывает, что эта запись RRSIG покрывает набор A RRset для host.example.com. Значение Label = 3 показывает, что шаблонное расширение не используется. Поля Algorithm, Signer’s Name и Key Tag показывают, что эта подпись может быть аутентифицирована с помощью DNSKEY RR зоны example.com, где используется алгоритм 5 и тег ключа 2642.

4. Запись NSEC RR

Запись NSEC содержит два отдельных элемента — имя следующего владельца (в каноническом порядке для зоны), содержащего полномочные данные, или точка передачи полномочий (делегирования) NS RRset и множество типов RR, присутствующих в имени владельца NSEC RR [RFC3845]. Полный набор записей NSEC RR в зоне показывает, какие из полномочных RRset имеются в зоне, а также формирует цепочку имен полномочных владельцев в зоне. Эта информация служит для предоставления аутентифицированных сведений об отсутствии данных в DNS, как описано в [RFC4035].

Поскольку каждое полномочное имя в зоне должно быть частью цепочки NSEC, для имен, содержащих CNAME RR, должны присутствовать записи NSEC RR. Это является отличием от традиционной спецификации DNS [RFC1034], где сказано, что CNAME представляется для имени и является единственным типом, дозволенным для этого имени. Записи RRSIG (см. раздел 3) и NSEC должны существовать для имен, имеющих запись CNAME в подписанной зоне.

В документе [RFC4035] описано, как подписывающий зону точно определяет включаемые в зону записи NSEC RR.

Тип NSEC RR имеет значение 47.

NSEC RR не зависит от класса.

В записи NSEC RR следует указывать такое же значение TTL, которое приведено в поле минимального TTL записи SOA. Такое поведение следует духу негативного кэширования ([RFC2308]).

4.1. Формат передачи NSEC RDATA

                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                      Next Domain Name                         /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                       Type Bit Maps                           /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

Формат RDATA записи NSEC RR показан на рисунке.

4.1.1. Поле Next Domain Name

Поле Next Domain содержит имя следующего владельца (в каноническом порядке зоны, см. параграф 6.1), который имеет полномочные данные или содержит точку передачи полномочий (делегирования) NS RRset. Значением поля Next Domain Name в последней записи NSEC данной зоны является имя на вершине зоны (имя владельца записи SOA RR для зоны). Это показывает, что имя владельца NSEC RR является последним при каноническом упорядочении имен в зоне.

Отправителю недопустимо использовать сжатие имен DNS для полей Next Domain Name при передаче NSEC RR.

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

4.1.2. Поле Type Bit Maps

Поле Type Bit Maps указывает типы RRset, существующие с именем владельца NSEC RR.

Пространство типов RR разделено на 256 окон (блоков), каждое из которых представляет 8 младших битов 16-битового пространства типов RR. Каждый блок, имеющий хотя бы один активный тип RR, кодируется с помощью 1-октетного номера окна (0 — 255), 1-октетного размера битового отображения (1 — 32), указывающего число октетов, используемых для битового отображения (bitmap) блока, и до 32 октетов (256 битов) самого битового отображения.

Блоки представляются в NSEC RR RDATA по порядку возрастания числовых значений.

Type Bit Maps = ( Window Block # | Bitmap Length | Bitmap )+

где | обозначает конкатенацию.

Каждое битовое отображение представляет 8 младших битов типов RR в блоке с использованием сетевого порядка битов. Первый бит имеет номер 0. Для оконного блока 0 бит 1 соответствует RR типа 1 (A), бит 2 — RR типа 2 (NS) и т. д. Для блока 1, бит 1 соответствует RR типа 257, в бит 2 — RR типа 258. Установленный бит показывает, что набор RRset данного типа присутствует для имени владельца NSEC RR, сброшенный бит говорит об отсутствии RRset данного типа для имени владельца NSEC RR.

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

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

Битовое отображение для NSEC RR в точке передачи полномочий требует отдельного внимания. Биты, соответствующие делегирования NS RRset и типы RR, для которых родительская зона имеет полномочные данные, должны быть установлены, биты, соответствующие всем отличным от NS RRset, для которых родительская зона не является полномочной, должны быть сброшены.

В зону недопустимо включать NSEC RR для каких-либо доменных имен, которые имеют лишь склеивающие записи.

4.1.3. Включение шаблонных имен в NSEC RDATA

При наличии в зоне шаблонного имени владельца символ шаблона (*) трактуется буквально и одинаково для всех проичх имен владельцев при генерации записей NSEC RR. Шаблонные имена указываются в поле Next Domain Name без расширения шаблона. Влияние шаблонов на аутентифицированные данные от отсутствии (denial of existence) рассмотрено в [RFC4035].

4.2. Формат представления NSEC RR

Представление части RDATA использует следующий формат:

поле Next Domain Name представляется, как доменное имя;

поле Type Bit Maps представляется в форме последовательности мнемонических обозначений типов RR, а при отсутствии мнемоники должно использоваться представление TYPE, описанное в разделе 5 [RFC3597].

4.3. Пример NSEC RR

Приведенная ниже запись NSEC RR идентифицирует наборы RRset, связанные с alfa.example.com. И указывает следующее после alfa.example.com. полномочное имя.

alfa.example.com. 86400 IN NSEC host.example.com. ( A MX RRSIG NSEC TYPE1234 )

Первые четыре текстовых поля задают имя, TTL, класс и тип RR (NSEC). Поле host.example.com. указывает следующее в каноническом порядке после alfa.example.com. полномочное имя. Мнемонические обозначения A, MX, RRSIG, NSEC и TYPE1234 показывают наличие наборов (RRset) A, MX, RRSIG, NSEC и TYPE1234, связанных с именем alfa.example.com.

Часть RDATA записи NSEC RR будет представлена в виде

            0x04 'h'  'o'  's'  't'
            0x07 'e'  'x'  'a'  'm'  'p'  'l'  'e'
            0x03 'c'  'o'  'm'  0x00
            0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
            0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
            0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
            0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
            0x00 0x00 0x00 0x00 0x20

 

В предположении, что проверяющий может аутентифицировать эту запись NSEC, она может быть использована для подтверждения отсутствия beta.example.com или подтверждения отсутствия записи AAAA, связанной с именем alfa.example.com. Аутентификация данных об отсутствии рассматривается в [RFC4035].

5. Запись DS RR

Запись DS RR указывает на DNSKEY RR и используется в процессе аутентификации DNS с помощью ключа DNSKEY. Запись DS RR указывает DNSKEY RR путем сохранения тега ключа, номера алгоритма и отпечатка (digest) DNSKEY RR. Отметим, что, несмотря на достаточность отпечатка для идентификации открытого ключа, сохранение тега ключа и алгоритма помогает повысить эффективность процесса идентификации. Путем аутентификации записи DS распознаватель может аутентифицировать запись DNSKEY RR, на которую указывает данная DS. Процесс аутентификации ключей описан в [RFC4035].

Запись DS RR и соответствующая ей DNSKEY RR имеют общее имя владельца, но хранятся в разных местах. Запись DS RR появляется только на верхней (родительской) стороне делегирования и относится к полномочным данным родительской зоны. Например, DS RR для example.com хранится в зоне com (родительская), а не example.com (дочерняя). Соответствующая запись DNSKEY RR сохраняется в зоне example.com (дочерняя). Это упрощает управление зонами DNS и их подписание, но требует специальной обработки откликов для DS RR (см. [RFC4035]).

Номер типа для записи DS равен 43.

Записи DS не зависят от класса.

Для записей DS RR нет особых требований к TTL.

5.1. Формат передачи DS RDATA

                     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Key Tag             |  Algorithm    |  Digest Type  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                                                               /
/                            Digest                             /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 

RDATA для DS RR состоит из 2-октетного поля Key Tag, 1-октетных полей Algorithm и Digest Type, а также поля Digest.

5.1.1. Поле Key Tag

Поле Key Tag содержит тег ключа для записи DNSKEY RR, указанной в записи DS, с использованием сетевого порядка байтов.

Поле Key Tag в записях DS RR идентично одноименному поля в RRSIG RR. Расчет тегов описан в Приложении B.

5.1.2. Поле Algorithm

Поле Algorithm содержит номер алгоритма для записи DNSKEY RR, указанной в записи DS.

Номер алгоритма в DS RR идентичен номерам алгоритмов, используемым в записях RRSIG и DNSKEY. Номера типов алгоритмов приведены в Приложении A.1.

5.1.3. Поле Digest Type

DS RR указывает на DNSKEY RR путем включения отпечатка (digest) данной DNSKEY RR. Поле Digest Type указывает алгоритм, использованный для создания отпечатка. Алгоритма создания отпечатков перечислены в Приложении A.2.

5.1.4. Поле Digest

Запись DS указывает на DNSKEY RR путем включения отпечатка (digest) данной DNSKEY RR .

Отпечаток рассчитывается путем использования алгоритма создания отпечатка к конкатенации канонической формы полного имени владельца DNSKEY RR и DNSKEY RDATA.

digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);

«|» указывает конкатенацию (слияние)

DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.

Размер отпечатка может меняться в зависимости от применяемого алгоритма и размера DNSKEY RR. На момент подготовки этого документа единственным алгоритмом создания отпечатков был SHA-1, обеспечивающий на выходе 20 октетов.

5.2. Обработка DS RR при проверке откликов

Записи DS RR связывают аутентификационные цепочки через границы зон, поэтому для DS RR требуется дополнительная обработка. DNSKEY RR, указанная в DS RR, должна быть ключом зоны DNSSEC. В поле флагов DNSKEY RR Flags должен быть установлен бит 7. Если флаги DNSKEY не указывают ключ зоны DNSSEC, записи DS RR (и указываемые ими DNSKEY RR) недопустимо использовать в процессе проверки.

5.3. Формат представления DS RR

Формат представления части RDATA показан ниже.

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

Поле Algorithm должно быть представлено десятичным целым числом без знака или мнемоническим обозначением алгоритма из числа приведенных в Приложении A.1.

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

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

5.4. Пример DS RR

Ниже приведен пример записи DNSKEY RR и соответствующей ей DS RR.

   dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
                                             fwJr1AYtsmx3TGkJaNXVbfi/
                                             2pHm822aJ5iI9BMzNXxeYCmZ
                                             DRD99WYwYqUSdjMmmAphXdvx
                                             egXd/M5+X7OrzKBaMbCVdFLU
                                             Uh6DhweJBjEVv5f2wwjM9Xzc
                                             nOf+EPbtG9DMBmADjFDc2w/r
                                             ljwvFw==
                                             ) ;  key id = 60485
   dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
                                              98631FAD1A292118 )

 

Первые 4 поля указывают имя, TTL, класс и тип RR (DS). Значение 60485 является тегом ключа, соответствующего dskey.example.com. DNSKEY RR и значение 5 указывают алгоритм, используемый этой записью dskey.example.com. DNSKEY RR. Значение 1 указывает алгоритм создания отпечатка, а остальная часть RDATA содержит отпечаток в 16-ричном формате.

6. Каноническая форма и порядок RR

В этом разделе определяется каноническая форма записей о ресурсах, канонический порядок имен DNS и канонический порядок записей о ресурсах в наборах RRset. Канонический порядок имен требуется при создании цепочек имен NSEC. Каноническая форма RR и канонический их порядок в RRset требуются для создания и проверки записей RRSIG RR.

6.1. Канонический порядок имен DNS

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

Для определения канонического порядка множества имен DNS сначала выполняется сортировка имен по старшим (правым) меткам. Для имен с одинаковой правой меткой выполняется сортировка по значению следующей по старшинству метки и т. д.

Ниже приведен набор имен DNS, отсортированных в каноническом порядке. Старшей меткой в данном случае является example. Поэтому первым в списке появляется имя, содержащее лишь старшую метку, за ним следует имя a.example, а заканчивается список именами z.example. В каждом уровне осуществляется внутренняя сортировка меток.

             example
             a.example
             yljkjljk.a.example
             Z.a.example
             zABC.a.EXAMPLE
             z.example
             \001.z.example
             *.z.example
             \200.z.example

 

6.2. Каноническая форма RR

Для использования в целях защиты DNS в качестве канонической формы RR используется формат передачи RR, где:

  1. каждое доменное имя в RR является несжатым (нет компрессии DNS) и полным (fully qualified);

  2. все символы верхнего регистра US-ASCII в имени владельца RR заменяются соответствующими символами нижнего регистра US-ASCII;

  3. 7

  4. если имя владельца RR является шаблонным, оно сохраняется без преобразования (с сохранением символа *);

  5. для поля TTL в записи RR устанавливается исходное значение, которое указано в полномочной зоне-источнике или в поле Original TTL покрывающей записи RRSIG RR.

6.3. Канонический порядок RR в наборе RRset

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

В [RFC2181] указано, что в RRset не допускается наличие дубликатов записей (множество RR с одинаковым именем владельца, классом, типом и RDATA). Следовательно, если реализация обнаруживает дубликат RRs при преобразовании RRset в каноническую форму, это должно трактоваться, как протокольная ошибка. Если реализация считает нужным самостоятельно обрабатывать такие ошибки в целях повышения отказоустойчивости (либеральное отношение к входным данным), она должна удалить все дубликаты RR до приведения RRset в каноническую форму.

7. Согласование с IANA

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

Дополнительное рассмотрение связанных с IANA вопросов приведено в [RFC4035].

Типы записей о ресурсах DNS. В [RFC2535] выделены типы 24, 25 и 30 для записей типа SIG, KEY и NXT, соответственно. В [RFC3658] выделен тип 43 для записей DS. В [RFC3755] выделены типы 46, 47 и 48 для RRSIG, NSEC и DNSKEY, соответственно. В [RFC3755] тип 30 (NXT) указан, как устаревший (Obsolete) и ограничено применение типов 24 (SIG) и 25 (KEY) до SIG(0) в протоколе защиты транзакций, описанном в [RFC2931], и KEY RR [RFC2930].

Номера алгоритмов защиты DNS. В [RFC2535] создан реестр IANA для значений поля DNSSEC Resource Record Algorithm и выделены значения 1 — 4 и 252 — 255. В [RFC3110] выделено значение 5. В [RFC3755] были внесены изменения в реестр с включением флагов для каждого элемента, связанных с использованием защитных расширений DNS. Каждый элемент может указывать алгоритм, который может применяться для подписания зоны и/или защиты транзакций (см. [RFC2931]). Значения 6 — 251 доступны для выделения в процессах стандартизации IETF ([RFC3755]). Полный список номеров алгоритмов защиты и статус их применения в DNSSEC на момент подготовки документа приведены в Приложении A.

В [RFC3658] создан реестр IANA для значений DNSSEC DS Digest Type и выделены значение 0 в качестве резервного и 1 для SHA-1.

Значения протоколов ключей. В [RFC2535] создан реестр IANA для значений KEY Protocol, но в [RFC3445] переопределены все значения этого реестра, за исключением резервного номера 3 и реестр был закрыт. Реестр остается закрытым и во всех записях KEY и DNSKEY октет Protocol должен иметь значение 3.

Биты флагов в записях KEY и DNSKEY. В [RFC3755] создан реестр IANA для битов флагов в записях DNSSEC KEY и DNSKEY. Изначально были выделены значения лишь для битов 7 (флаг ZONE) и 15 (флаг SEP8, см. [RFC3757]). Как указано в [RFC3755], биты 0 — 6 и 8 — 14 доступны для выделения в процессах стандартизации IETF.

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

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

Запись DS указывает на DNSKEY RR путем использования криптографического отпечатка, типа алгоритма и тега ключа. Записи DS предназначены для идентификации имеющихся DNSKEY RR, но теоретически возможно их использование атакующими для генерации DNSKEY, соответствующих всем полям записи DS. Возможность создания соответствующих DNSKEY зависит от типа применяемого алгоритма создания отпечатков. В настоящее время определен только алгоритм SHA-1 и рабочая группа предполагает, что создание открытого ключа, который будет соответствовать алгоритму, тегу ключа и отпечатку SHA-1, представленным в записи DS, является достаточно сложной проблемой и такие атаки в настоящее время не представляют угрозы.

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

Таблица алгоритмов в Приложении A и алгоритмы расчета тегов ключей в Приложении B включают для полноты алгоритм RSA/MD5, но его применение не рекомендуется (см. [RFC3110]).

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

Этот документ был создан на основе идей и результатов работы группы DNS Extensions, а также обсуждений в списке рассылки этой группы. Редакторы рады выразить свою признательность за комментарии и предложения, полученные в процессе пересмотра этих защитных расширений. Хотя указать всех, кто принял участие в десятилетней разработке DNSSEC, просто невозможно, в [RFC4033] приведен список некоторых активных участников обсуждения документов.

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

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

[RFC1034] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, November 1987.

[RFC1035] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, November 1987.

[RFC1982] Elz, R. and R. Bush, «Serial Number Arithmetic», RFC 1982, August 1996.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC2181] Elz, R. and R. Bush, «Clarifications to the DNS Specification», RFC 2181, July 1997.

[RFC2308] Andrews, M., «Negative Caching of DNS Queries (DNS NCACHE)», RFC 2308, March 1998.

[RFC2536] Eastlake 3rd, D., «DSA KEYs and SIGs in the Domain Name System (DNS)», RFC 2536, March 1999.

[RFC2931] Eastlake 3rd, D., «DNS Request and Transaction Signatures ( SIG(0)s )», RFC 2931, September 2000.

[RFC3110] Eastlake 3rd, D., «RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)», RFC 3110, May 2001.

[RFC3445] Massey, D. and S. Rose, «Limiting the Scope of the KEY Resource Record (RR)», RFC 3445, December 2002.

[RFC3548] Josefsson, S., «The Base16, Base32, and Base64 Data Encodings», RFC 35489, July 2003.

[RFC3597] Gustafsson, A., «Handling of Unknown DNS Resource Record (RR) Types», RFC 3597, September 2003.

[RFC3658] Gudmundsson, O., «Delegation Signer (DS) Resource Record (RR)», RFC 3658, December 2003.

[RFC3755] Weiler, S., «Legacy Resolver Compatibility for Delegation Signer (DS)», RFC 3755, May 2004.

[RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, «Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag», RFC 3757, April 2004.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «DNS Security Introduction and Requirements», RFC 4033, March 2005.

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Protocol Modifications for the DNS Security Extensions», RFC 4035, March 2005.

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

[RFC2535] Eastlake 3rd, D., «Domain Name System Security Extensions», RFC 2535, March 1999.

[RFC2537] Eastlake 3rd, D., «RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)», RFC 2537, March 1999.

[RFC2539] Eastlake 3rd, D., «Storage of Diffie-Hellman Keys in the Domain Name System (DNS)», RFC 2539, March 1999.

[RFC2930] Eastlake 3rd, D., «Secret Key Establishment for DNS (TKEY RR)», RFC 2930, September 2000.

[RFC3845] Schlyter, J., «DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format», RFC 3845, August 2004.

Приложение A. Типы алгоритмов и отпечатков DNSSEC

Защитные приложения DNS разрабатываются так, чтобы они не зависели от используемого криптографического алгоритма. Записи DNSKEY, RRSIG и DS используют DNSSEC Algorithm Number для идентификации используемого записью криптографического алгоритма. Записи DS также указывают Digest Algorithm Number для идентификации алгоритма цифровой подписи, использованного для создания записи DS. Определенные в настоящее время алгоритмы (Algorithm) и типы отпечатков (Digest Type) перечислены ниже. По мере развития криптографии могут добавляться новые алгоритмы и типы отпечатков.

Осведомленные о DNSSEC преобразователи и серверы имен должны реализовать все обязательные (MANDATORY) алгоритмы.

A.1. Типы алгоритмов DNSSEC

Записи DNSKEY, RRSIG и DS используют 8-битовые целые числа для идентификации используемого алгоритма защиты. Эти значения хранятся в поле Algorithm number элемента RDATA данной записи.

Некоторые алгоритмы подходят только для подписывания зон (DNSSEC), другие — только для механизмов защиты транзакций (SIG(0) и TSIG), а некоторые — для обоих случаев. Пригодные для подписывания зон алгоритмы могут присутствовать в записях DNSKEY, RRSIG и DS RR, пригодные для защиты транзакций — в записях SIG(0) и KEY, как описано в [RFC2931].

Значение

Алгоритм

Обозначение

Подпись зоны

Документ

Статус

0

резерв

1

RSA/MD5

RSAMD5

нет

RFC2537

Не рекомендуется

2

Diffie-Hellman

DH

нет

RFC2539

3

DSA/SHA-1

DSA

есть

RFC2536

Опционально

4

Elliptic Curve

ECC

В работе

5

RSA/SHA-1

RSASHA1

есть

RFC3110

Обязательно

252

Indirect

INDIRECT

нет

253

Private

PRIVATEDNS

есть

см. ниже

Опционально

254

Private

PRIVATEOID

есть

см. ниже

Опционально

255

резерв

6 — 251

Резерв для стандартизации IETF

A.1.1. Частные типы алгоритмов

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

Номер 254 зарезервирован для частных применений и никогда не будет выделен для конкретного алгоритма. Область открытого ключа в DNSKEY RR и область подписи в RRSIG RR начинаются с (беззнакового) байта размера, за которым следует BER-представление идентификатора объекта (ISO OID10) указанного размера. OID указывает используемый приватный алгоритм и остальная часть области определяется этим алгоритмом. Объектам следует использовать только те идентификаторы OID, для которых они контролируют применение частных алгоритмов.

A.2. Типы отпечатков DNSSEC

Поле Digest Type в записях DS идентифицирует криптографический алгоритм создания отпечатка (digest), использованный для этой записи. Определенные в настоящее время алгоритмы указаны в таблице.

Значение

Алгоритм

Статус

0

резерв

1

SHA-1

Обязательно

2 — 255

Не распределены

Приложение B. Расчет Key Tag

Поле Key Tag в записях типов RRSIG и DS обеспечивает механизм эффективного выбора открытого ключа. В большинстве случаев комбинация имени владельца, алгоритма и тега ключа могут эффективно идентифицировать запись DNSKEY. Записи обоих типов RRSIG и DS имеют соответствующие записи DNSKEY. Поля Key Tag в записях RRSIG и DS могут помочь в эффективном выборе соответствующей DNSKEY RR из множества таких записей.

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

Теги ключа определяются одинаково для всех алгоритмов DNSKEY, за исключением алгоритма 1 (для этого алгоритма определение тега ключа приведено в Приложении B.1). Тег ключа получается путем суммирования 2-октетных блоков DNSKEY RDATA в формате передачи. Сначала RDATA (в формате передачи) трактуется, как последовательность 2-октетных групп. Эти группы складываются с использованием по крайней мере 32-битового формата суммы с сохранением всех битов переноса. После этого биты переноса добавляются к результату из которого в качестве тега ключа используется только 16 младших битов. Следует отметить, что переносы, возникающие при добавлении при добавлении битов переноса, игнорируются. Это, в свою очередь, означает, что расчет ключа зачастую (но не всегда) совпадает с сокращением по модулю 6553511.

Ниже приведен образец реализации алгоритма создания тега ключа на языке ANSI C с использованием компоненты RDATA записи DNSKEY RR в качестве входных данных. Не требуется использовать именно приведенный код, но численное значение Key Tag должно быть идентично значению, которое для тех же входных данных будет возвращать приведенный образец кода.

Отметим, что алгоритм расчета Key Tag почти (но не полностью) идентичен алгоритму расчета контрольных сумм с дополнением до 1, используемому во многих протоколах Internet. Значения Key Tags должны рассчитываться с использованием приведенного здесь алгоритма, а не контрольной суммы с дополнением до 1.

Приведенный ниже код ANSI C служит для расчета Key Tag. Этот образец реализации применим ко всем типа алгоритмов за исключением алгоритма 1 (см. Приложение B.1). Входными данными является компонента RDATA (в формате передачи) записи DNSKEY RR. Код оптимизирован в части ясности, а не эффективности.

   /*
    * Предполагается, что размер int не менее 16 битов.
    * Первый октет тега ключа содержит 8 старших битов возвращаемого значения;
    * Второй октет тега ключа содержит 8 младших битов возвращаемого значения.
    */

   unsigned int
   keytag (
           unsigned char key[],  /* компонента RDATA записи DNSKEY RR */
           unsigned int keysize  /* RDLENGTH */
          )
   {
           unsigned long ac;     /* предполагается размер не менее 32 битов */
           int i;                /* переменная цикла */

           for ( ac = 0, i = 0; i < keysize; ++i )
                   ac += (i & 1) ? key[i] : key[i] << 8;
           ac += (ac >> 16) & 0xFFFF;
           return ac & 0xFFFF;
   }

 

B.1. Key Tag для алгоритма 1 (RSA/MD5)

Теги ключей для алгоритма 1 (RSA/MD5) определяются не так, как для всех остальных алгоритмов в силу исторических причин. Для записи DNSKEY RR с алгоритмом 1 тег ключа определяется, как 16 старших из 24 младших битов в модуле открытого ключа (иными словами, 3-й и 2-й12 с конца октеты модуля открытого ключа).

Следует отметить, что использование алгоритма 1 не рекомендуется.

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

Roy Arends

Telematica Instituut

Brouwerijstraat 1

7523 XC Enschede

NL

EMail: roy.arends@telin.nl

Rob Austein

Internet Systems Consortium

950 Charter Street

Redwood City, CA 94063

USA

EMail: sra@isc.org

Matt Larson

VeriSign, Inc.

21345 Ridgetop Circle

Dulles, VA 20166-6503

USA

EMail: mlarson@verisign.com

Dan Massey

Colorado State University

Department of Computer Science

Fort Collins, CO 80523-1873

EMail: massey@cs.colostate.edu

Scott Rose

National Institute for Standards and Technology

100 Bureau Drive

Gaithersburg, MD 20899-8920

USA

EMail: scott.rose@nist.gov

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

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

nmalykh@protocols.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1В оригинале ошибочно указано также обновление RFC 3007. См. https://www.rfc-editor.org/errata_search.php?eid=3045. Прим. перев.

2DNS Security Extensions — защитные расширения DNS.

3DNS Public Key.

4Resource Record Signature.

5Delegation Signer.

6Resource record.

7Текст этого пункта в исходном документе «если типом RR указан NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV, DNAME, A6, RRSIG или NSEC, все заглавные буквы US-ASCII в именах DNS, содержащихся в RDATA, заменяются соответствующими строчными буквами US-ASCII;» является ошибочным. См. https://www.rfc-editor.org/errata_search.php?eid=1062. Прим. перев.

8Secure Entry Point — защищенная точка входа.

9Этот документ признан устаревшим и заменен RFC 4648. Прим. перев.

10Object Identifier.

11Текст этого абзаца был переведен с учетом обнаруженной в нем ошибки. См. https://www.rfc-editor.org/errata_search.php?eid=4552 и https://www.rfc-editor.org/errata_search.php?eid=2681. Прим. перев.

12В оригинале ошибочно указаны 4-й и 3-й. См. https://www.rfc-editor.org/errata_search.php?eid=193. Прим. перев.




RFC 4033 DNS Security Introduction and Requirements

Network Working Group                                      R. Arends
Request for Comments: 4033                      Telematica Instituut
Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658,            R. Austein
3755, 3757, 3845                                                 ISC
Updates: 1034, 1035, 2136, 2181, 2308, 3225,               M. Larson
3007, 3597, 3226                                            VeriSign
Category: Standards Track                                  D. Massey
                                           Colorado State University
                                                             S. Rose
                                                                NIST
                                                          March 2005

Защита DNS — введение и требования

DNS Security Introduction and Requirements

PDF

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

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

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

Copyright (C) The Internet Society (2005).

Тезисы

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

Оглавление

Исключено из версии HTML

1. Введение

Этот документ является введением для серии RFC, описывающих расширение DNSSEC для системы доменных имен. Документ вместе с [RFC4034] и [RFC4035] служит обновлением и совершенствованием расширений в целях безопасности, описанных в [RFC2535] и предшествующих документах. Расширения включают набор новых типов записей RR2 и изменение существующего протокола DNS ([RFC1035]). Новые записи и обновление протокола не описываются в данном документе полностью, но они подробно описаны в документах, перечисленных в главе 10. В главах 3 и 4 описываются более детально возможности и ограничения предложенного расширения. В главе 5 обсуждается сфера действия описывающего расширение набора документов. В глава 6 — 9 обсуждается воздействие этого документа на серверы распознавания (resolver), оконечные серверы распознавания (stub resolver), зоны и серверы имен.

Данный документ в комбинации в двумя другими документами серии отменяет действие документов [RFC2535], [RFC3008], [RFC3090], [RFC3445], [RFC3655], [RFC3658], [RFC3755], [RFC3757] и [RFC3845]. Кроме того, этот набор документов служит обновлением (но не отменяет) для документов [RFC1034], [RFC1035], [RFC2136], [RFC2181], [RFC2308], [RFC3225], [RFC3007], [RFC3597] и части [RFC3226], относящейся к DNSSEC.

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

2. Определения важнейших терминов DNSSEC

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

Authentication Chain – цепочка аутентификации.

Чередующаяся последовательность наборов открытых ключей DNS (DNSKEY) и Delegation Signer (DS), формирующая подписанные данные – каждая связь в цепочке служит поручительством для следующей. Запись DNSKEY RR используется для верификации сигнатуры, покрывающей DS RR, и позволяет проверить запись DS RR. Запись DS RR содержит хэш другой записи DNSKEY RR и эта новая запись DNSKEY RR проверяется по соответствию хэшу в записи DS RR. Эта новая запись DNSKEY RR, в свою очередь, аутентифицирует другой набор DNSKEY RR и, в свою очередь, некая запись DNSKEY RR из этого набора может использоваться для аутентификации другой DS RR и т. д., пока цепочка не завершится записью DNSKEY RR, которая соответствует приватному ключу, подписывающему желаемые данные DNS. Например, корневой набор DNSKEY RR может использоваться при аутентификации набора DS RR для «example.». Набор DS RR «example.» содержит хэш для некой записи из «example.». DNSKEY и соответствующий приватный ключ подписывают DNSKEY RR для «example.». Дополнение приватного ключа «example.» DNSKEY RR подписывает данные (такие, как («www.example.») и DS RR для делегирования «subzone.example.»

Authentication Key – ключ аутентификации.

Открытый ключ, который защищенный распознаватель3 проверяет и может, следовательно, использовать для аутентификации данных. Защищенный распознаватель может получить ключи аутентификации тремя способами. Во-первых, распознаватель обычно настроен так, что ему известен по крайней мере один открытый ключ — в конфигурационных параметрах указывается сам ключ или его хэш, который находится в DS RR (см. «trust anchor»). Во-вторых, распознаватель может использовать аутентифицированный открытый ключ для верификации записей DS RR и DNSKEY RR, на которые указывает DS RR. В-третьих, распознаватель может определить, что новый открытый ключ был подписан секретным ключом, соответствующим другому публичному ключу, который был уже верифицирован распознавателем. Отметим, что распознаватель всегда должен следовать локальной политике при определении необходимости аутентификации нового открытого ключа, даже если локальная политика состоит состоит лишь из аутентификации любого нового открытого ключа, для которого распознаватель способен проверить подпись.

Authoritative RRset – аутентичный набор RRset.

В контексте отдельной зоны RRset является аутентичным тогда и только тогда, когда имя владельца RRset входит в подмножество пространства имен, которое находится на уровне вершины (апекса) зоны или ниже его и на уровне или выше границы, отделяющей зону от ее потомков, если таковые имеются. Все наборы RRset на уровне вершины зоны являются аутентичными, за исключением отдельных RRset на уровне доменного имени, которое (если оно имеется), относится к родителю данной зоны. Этот набор RRset может включать DS RRset, набор NSEC RRset, указывающий на данный набор DS RRset (“родительский NSEC”) и записи RRSIG RR, связанные с этими RRset, каждый из которых является аутентичным в родительской зоне. Аналогично, если эта зона содержит любые точки делегирования, только родительский набор NSEC RRset, наборы DS RRset и все записи RRSIG RR, связанные с этими наборами RRset, являются аутентичными для этой зоны.

Delegation Point – точка делегирования4.

Этот термин используется для обозначения имени на родительской стороне среза зоны. Т. е., точкой делегирования для «foo.example» в зоне «example» будет узел foo.example (апекс зоны для «foo.example»). См. также zone apex.

Island of Security – островок безопасности

Этот термин используется для обозначения подписанной, делегированной зоны, которая не имеет цепочки аутентификации от делегировавшего эту зону родителя. Т. е., здесь нет записи DS RR, содержащей хэш DNSKEY RR для островка в делегирующей родительской зоне (см. [RFC4034]). Островки безопасности обслуживаются защищенными5 серверами имен и могут обеспечивать цепочки аутентификации для любых делегированных дочерних зон. Ответы от островка безопасности или его наследников могут быть аутентифицированы только в тех случаях, когда аутентификационные ключи могут быть аутентифицированы тем или иным доверенным способом за пределами протокола DNS.

Key Signing Key (KSK) – ключ подписывания ключа

Аутентификационный ключ, который соответствует закрытому (private) ключу, использованному для подписания одного или множества других аутентификационных ключей, которые, в свою очередь, имеют соответствующие закрытые ключи для подписывания других данных зоны. Локальная политика может требовать частой смены ключа, подписывающего зону, тогда как ключ подписывания ключа может использоваться в течение большего срока для обеспечения более стабильной защищенной точки входа в зону. Обозначение аутентификационного ключа в качестве ключа подписывания других ключей является рабочим вопросом – проверка корректности DNSSEC не делает различий между ключами подписывания ключей и другими аутентификационными ключами DNSSEC и можно использовать один ключ для подписывания зоны и других ключей. Более детальное обсуждение ключей для подписывания других ключей приведено в документе [RFC3757]. См. также zone signing key.

Non-Validating Security-Aware Stub Resolver – не проверяющий корректность защищенный оконечный распознаватель

Защищенный оконечный распознаватель, который доверяет одному или более защищенному рекурсивному серверу имен для выполнения от его имени большинства задач, обсуждающихся в данном наборе документов. В частности, такой распознаватель является объектом, передающим запросы DNS, получающим отклики DNS и способным создавать подобающим образом защищенный канал к защищенному серверу имен, который будет выполнять эти задачи от имени оконечного защищенного распознавателя. См. также security-aware stub resolver, validating security-aware stub resolver.

Non-Validating Stub Resolver – не проверяющий оконечный распознаватель

Менее утомительный термин для обозначения non-validating security-aware stub resolver.

Security-Aware Name Server – защищенный сервер имен

Объект, действующий в роли сервера имен (определен в параграфе 2.4 документа [RFC1034]), который понимает защитные расширения DNS, определенные в данном наборе документов. В частности, защищенный сервер имен представляет собой объект, получающий запросы DNS, передающий отклики DNS, поддерживающий расширение размера сообщения EDNS0 ([RFC2671]) и бит DO ([RFC3225]), а также типы RR и биты заголовка сообщения, определенные в данном наборе документов.

Security-Aware Recursive Name Server– защищенный рекурсивный сервер имен

Объект, выступающий одновременно в качестве security-aware name server и security-aware resolver. Более громоздким, но эквивалентным термином является a security-aware name server that offers recursive service6.

Security-Aware Resolver – защищенный распознаватель

Объект, играющий роль распознавателя (см. определение в параграфе 2.4 документа [RFC1034]) и понимающий защитные расширения DNS, определенные в данном наборе документов. В частности, защищенный распознаватель представляет собой объект, передающий запросы DNS, получающий отклики DNS, поддерживающий расширения размера сообщений EDNS0 ([RFC2671]) и бит DO ([RFC3225]), а также способный использовать типы RR и биты заголовка сообщения, определенные в настоящем наборе документов, для предоставления сервиса DNSSEC.

Security-Aware Stub Resolver – защищенный оконечный распознаватель

Объект, действующий в качестве оконечного распознавателя (см. определение в параграфе 5.3.1 документа [RFC1034]), который в достаточной степени понимает защитные расширения DNS, определенные в данном наборе документов, для предоставления дополнительных услуг, которые невозможно получить от обычного (не защищенного) оконечного распознавателя. Защищенные распознаватели могут быть проверяющими (validating) и не проверяющими (non-validating) корректность в зависимости от того, проверяет ли распознаватель подписи DNSSEC сам или доверяет такую проверку дружественному защищенному серверу имен. См. также validating stub resolver, non-validating stub resolver.

Security-Oblivious <anything> — обычное <нечто>

Нечто, не относящееся к числу понимающего защищенного (security-aware).

Signed Zone – подписанная зона

Зона с подписанными наборами RRset, содержащая корректно созданный ключ DNSKEY, подпись RRSIG7, записи NSEC8 и (необязательно) DS.

Trust Anchor – доверенная привязка

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

Unsigned Zone – неподписанная зона

Зона, не имеющая подписи.

Validating Security-Aware Stub Resolver – проверяющий корректность оконечный распознаватель

Защищенный распознаватель, который передает запросы в рекурсивном режиме, но выполняет проверку сигнатур самостоятельно, не полагаясь на доверие к вышестоящему защищенному рекурсивному серверу имен. См. также security-aware stub resolver, non-validating security-aware stub resolver.

Validating Stub Resolver – проверяющий оконечный распознаватель

Менее утомительный термин для validating security-aware stub resolver.

Zone Apex – апекс (вершина) зоны

Этот термин используется для имени на дочерней стороне среза зоны. См. также delegation point.

Zone Signing Key (ZSK) – ключ для подписывания зоны

Аутентификационный ключ, который соответствует закрытому ключу, используемому для подписывания зоны. Обычно такой ключ является частью того же набора DNSKEY RRset, к которому относится ключ для подписывания ключей, чей закрытый ключ подписывает данного набора DNSKEY RRset, но ключ подписывания зоны используется для иных задач и может отличаться от ключа подписывания ключей (например, временем жизни). Назначение аутентификационного ключа для подписывания зоны является локальным рабочим вопросом; проверка корректности DNSSEC не делает различий между ключами для подписывания зоны и другими аутентификационными ключами DNSSEC и можно использовать один ключ в качестве ключа для подписывания зоны и подписывания других ключей. См. также key signing key.

3. Службы, обеспечиваемые DNS Security

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

Эти механизмы требуют изменения протокола DNS. DNSSEC добавляет 4 новых типа записей о ресурсах — RRSIG9, DNSKEY10, DS11 и NSEC12. Добавлены также два новых бита заголовков — CD13 и AD14. Для поддержки сообщений DNS большего размера в связи с добавлением записей DNSSEC RR это расширение также требует поддержки EDNS0 ([RFC2671]). И, наконец, DNSSEC требует поддержки битов заголовка DNSSEC OK (DO) EDNS ([RFC3225]), чтобы защищенный распознаватель мог указать в своих запросах, желает ли он получать записи DNSSEC RR в откликах.

Перечисленные меры обеспечивают защиту от большинства угроз системе DNS, описанных в [RFC3833]. В главе 12 обсуждаются ограничения, присущие этим расширениям.

3.1. Аутентификация источника данных и проверка целостности

DNSSEC обеспечивает аутентификацию путем связывания криптографических цифровых подписей с наборами данных DNS RRset. Эти цифровые подписи хранятся в новых записях RRSIG. Обычно имеется один закрытый (ключ для подписывания данных зоны, но можно использовать и множество ключей. Например, могут использоваться отдельные ключи для каждого из различных алгоритмов создания цифровой подписи. Если защищенный распознаватель надежным путем получает открытый ключ зоны, он может аутентифицировать подписанные данные зоны. Важной концепцией DNSSEC является то, что ключ, подписывающий данные зоны, связывается с самой зоной, а не с уполномоченными серверами этой зоны. Открытые ключи для механизмов аутентификации транзакций DNS также могут появляться в зонах, как описано в [RFC2931], но расширения DNSSEC сами по себе не имеют дела с защитой объектов данных DNS и каналов для выполнения транзакций DNS. Ключи, связанные с защитой транзакций, могут храниться в различных типах RR. Дополнительную информацию можно найти в [RFC3755].

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

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

Записи типа DS RR упрощают решение некоторых административных задач, связанных с подписыванием делегирования через организационные границы. Набор DS RRset находится в точке делегирования родительской зоны и показывает открытый ключ (ключи), используемый для самоподписывания DNSKEY RRset на вершине делегированной дочерней зоны. Администратор дочерней зоны, в свою очередь, использует закрытый ключ (ключи), соответствующий одному или нескольким открытым ключам в данном наборе DNSKEY RRset, для подписывания данных дочерней зоны. Типовая цепочка аутентификации, следовательно, будет иметь вид DNSKEY->[DS->DNSKEY]*->RRset, где символ * обозначает субцепочки DS->DNSKEY (0 или более). DNSSEC разрешает и более сложные цепочки аутентификации (такие, как дополнительные уровни DNSKEY RR, подписывающие другие DNSKEY RR внутри зоны).

Защищенный распознаватель обычно создает цепочку аутентификации от корня иерархии DNS вниз к ветвям зон, на основе заданных в конфигурации данных о корневом открытом ключе. Локальная политика может также позволять защищенному распознавателю использовать один или множество открытых ключей (или их хешей), отличных от корневого открытого ключа, не обеспечивать данных о корневом открытом ключе или запрещать распознавателю использовать открытые ключи по любым причинам, даже если эти ключи корректно подписаны и подписи проверены. DNSSEC обеспечивает механизмы, посредством которых защищенный распознаватель может определить, является ли подпись RRset корректной с точки зрения DNSSEC. Однако последнее слово при анализе аутентификации для ключей и данных DNS остается за локальной политикой, которая может расширить или переназначить расширения протокола, определенные в этом наборе документов (см. также главу 5).

3.2. Аутентификация в случаях отсутствия имени или типа

Механизм защиты, описанный в параграфе 3.1, обеспечивает лишь способ подписывания существующих в зоне наборов RRset. Проблема возврата негативных откликов с таким же уровнем аутентификации и целостности требует использования еще одного нового типа записи — NSEC. Запись NSEC позволяет защищенному распознавателю аутентифицировать негативный отклик в случаях отсутствия имени или типа с использованием того же механизма, который применяется при аутентификации других откликов DNS. Использование NSEC требует канонического представления и упорядочения имен в зонах. Цепочки записей NSEC явно описывают пропуски или «пустое пространство» между доменными именами в зоне, а для существующих имен присутствует список типов RRset. Каждая запись NSEC подписывается и аутентифицируется, как описано в параграфе 3.1.

4. Сервис, не поддерживаемый DNS Security

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

DNSSEC не обеспечивает защиты от DoS-атак. Защищенные распознаватели и серверы имен уязвимы также для DoS-атак на основе криптографических механизмов. Более детальное обсуждение этого вопроса содержится в главе 12.

Расширения DNS обеспечивают аутентификацию данных и источника для операций DNS. Описанный выше механизм не предназначен для защиты таких операций, как перенос зон или динамическое обновление ([RFC2136], [RFC3007]). Для таких транзакций защиту можно организовать с помощью схем, описанных в [RFC2845] и [RFC2931].

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

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

Проверяющий распознаватель может определять 4 перечисленных ниже состояния:

Secure — защищенное

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

Insecure — незащищенное

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

Bogus — подделка

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

Indeterminate — неопределенное

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

Эта спецификация определяет лишь, как защищенные серверы имен могут сигнализировать не проверяющим корректность оконечным распознавателям, что данные были квалифицированы как подставные (с помощью RCODE=2, «Server Failure»; см. [RFC4035]).

Существует механизм, с помощью которого защищенный сервер имен может сообщить защищенному оконечному распознавателю о том, что данные были сочтены защищенными (с помощью бита AD; см. [RFC4035]).

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

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

6. Распознаватели

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

Если защищенный распознаватель отделен от уполномоченного сервера имен любым промежуточным устройством, играющим роль посредника для DNS, если рекурсивный сервер имен или промежуточное устройство не являются защищенными, распознаватель может оказаться неспособным работать в защищенном режиме. Например, если пакеты защищенного распознавателя маршрутизируются через систему трансляции адресов и устройство, включающее DNS-прокси, не является защищенным, для защищенного распознавателя может оказаться сложным или невозможным получение или проверка подписанных данных DNS. Особые сложности могут возникать у защищенного распознавателя при получении DS RR в таких ситуациях, поскольку DS RR не следуют обычным правилам DNS для принадлежности RR на срезе зоны. Отметим, что такие проблемы не являются спецификой NAT – не понимающие защиты программы DNS любого типа между защищенным распознавателем и уполномоченным сервером имен будут вызывать проблемы с DNSSEC.

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

Защищенному распознавателю следует принимать во внимание период проверки подписи при рассмотрении времени жизни (TTL) данных в своем кэше, чтобы избежать кэширования подписанных данных на период, превышающий срок действия подписи. Однако ему следует также допускать возможность некорректности показаний своих часов. Таким образом, защищенный распознаватель, который является часть защищенного рекурсивного сервера имен, должен аккуратно принимать во внимание бит DNSSEC CD ([RFC4034]). Это нужно для того, чтобы предотвратить блокирование корректных подписей, передаваемых другим защищенным распознавателям, которые являются клиентами данного рекурсивного сервера имен. Обработка защищенным рекурсивным сервером запросов с битом CD описана в [RFC4035].

7. Оконечные распознаватели

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

Хотя обычные оконечные распознаватели могут получить некоторые преимущества DNSSEC, если используемые ими рекурсивные серверы имен являются защищенными, для реального доверия к службам DNSSEC оконечный распознаватель должен доверять как используемым серверам имен, так и коммуникационным каналам, связывающим его с этими серверами. Первый вопрос определяется локальной политикой – обычный распознаватель, по сути, не имеет выбора кроме как положиться на используемый рекурсивный сервер, поскольку распознаватель не может выполнять операций DNSSEC по проверке корректности. Второй вопрос требует того или иного механизма защиты канала – надлежащего использования механизмов аутентификации транзакций DNS (таких, как SIG(0) ([RFC2931]) или TSIG ([RFC2845]) будет вполне достаточно, подойдет и использование IPsec. Конкретные реализации могут выбирать и другие доступные варианты (например, поддерживаемые операционной системой механизмы обмена данными между процессами). Конфиденциальность для канала не требуется, но нужна аутентификация и обеспечение целостности данных.

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

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

8. Зоны

Существуют некоторые различия между подписанными и неподписанными зонами. Подписанная зона будет содержать дополнительные записи, связанные с защитой (RRSIG, DNSKEY, DS, NSEC). Записи RRSIG и NSEC могут генерироваться подписывающим процессом до обслуживания зоны. Записи RRSIG, сопровождающие данные зоны, имеют время начала и завершения действия, определяющие период корректности подписей и данных зоны.

8.1. Значения TTL и срок действия RRSIG

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

Поля начала и завершения срока действия в RRSIG RR ([RFC4034]), с другой стороны, задают временной интервал, в течение которого подписи могут применяться для проверки соответствующего набора RRset. Сигнатуры, связанные с подписанными данными зоны, корректны лишь в течение периода, заданного полями записи RRSIG RR. Значения TTL не могут расширять период корректности подписанных наборов RRset в кэше распознавателя, но распознаватель может использовать время, остающееся до истечения срока действия сигнатуры подписанного набора RRset, в качестве верхней границы для значения TTL подписанного набора RRset и связанной с ним записи RRSIG RR в кэше распознавателя.

8.2. Новые временные зависимости для зон

Информация в подписанной зоне имеет зависимость от времени, которой не существовало в исходном протоколе DNS. Подписанная зона требует регулярного обслуживания для обеспечения корректности текущего значения RRSIG RR для каждого набора в зоне. Период корректности подписи RRSIG RR представляет собой интервал, в течение которого сигнатура для одного подписанного набора RRset может считаться корректной. Срок действия подписей разных наборов RRset в зоне может различаться. При подписывании заново одного или нескольких наборов RRset в зоне будут изменяться соответствующеи записи RRSIG RR, что, в свою очередь, потребует увеличения порядкового номера в записи SOA, которое показывает, что в зоне произошли изменения, и создания новой подписи для самого набора SOA RRset. Таким образом, создание новой подписи для любого набора RRset в зоне может также инициировать сообщение DNS NOTIFY и операции по переносу зоны.

9. Серверы имен

Защищенным серверам имен следует включать соответствующие записи DNSSEC (RRSIG, DNSKEY, DS и NSEC) во все отклики на запросы от распознавателей, которые указали свое желание получать такие записи путем установки бита DO в заголовке EDNS, с учетом ограничений на размер сообщений. Поскольку включение записей DNSSEC RR может привести к усечению сообщений UDP и переходу на использование протокола TCP, защищенные серверы имен должны также поддерживать механизм EDNS «sender’s UDP payload».

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

Расширений DNSSEC, как таковых, еще недостаточно для обеспечения целостности всей зоны при операциях переноса, поскольку даже подписанная зона содержит некоторые не подписанные и не полномочнные (nonauthoritative) данные, если эта зона имеет какие-либо дочерние зоны. Следовательно, операции по поддержке зоны будут требовать дополнительных механизмов (обычно это средства защиты каналов типа TSIG, SIG(0) или IPsec).

10. Серия документов DNS Security

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

Словами «Набор документов DNSSEC» обозначаются три документа, описывающих расширение DNS security:

  1. DNS Security Introduction and Requirements (данный документ)

  2. Resource Records for DNS Security Extensions [RFC4034]

  3. Protocol Modifications for the DNS Security Extensions [RFC4035]

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

Словами «Спецификация алгоритма цифровой подписи» обозначается группа документов, описывающих работу конкретных алгоритмов цифровой подписи, которые следует реализовать для заполнения формата записей о ресурсах DNSSEC. Каждый документ этой группы связан с определенным алгоритмом создания цифровой подписи. Список таких алгоритмов на момент создания настоящей спецификации приведен в приложении «DNSSEC Algorithm and Digest Types» документа [RFC4034].

Словами «Протокол аутентификации транзакций» обозначается группа документов, описывающих аутентификацию сообщений DNS, включая создание и верификацию секретных ключей. Не будучи существенной частью спецификации DNSSEC, эта группа, тем не менее, указана в списке, благодаря ее тесной связи с DNSSEC.

И, наконец, словами «Новые защищенные приложения» будут обозначаться документы, в которых рассматривается использование предложенного расширения DNS Security для иных приложений, связанных с безопасностью. DNSSEC не обеспечивает прямых механизмов защиты для таких новых приложений, но может использоваться для их поддержки. К этой категории относятся документы, описывающие использование DNS в системах хранения и распространения сертификатов ([RFC2538]).

11. Согласование с IANA

Этот обзорный документ не требует согласования с IANA. Полный обзор требующих согласования с IANA вопросов, связанных с DNSSEC, приведен в [RFC4034].

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

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

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

В этом документе кратко обсуждаются другие методы защиты запросов DNS (такие, как использование защищенных каналов IPsec или применение механизмов защиты транзакций DNS типа TSIG [RFC2845] или SIG(0) [RFC2931]), но защита транзакций не входит в задачи DNSSEC.

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

DNSSEC не защищает от DoS-атак. DNSSEC делает протокол DNS уязвимым к новому классу атак на службы, основанных на использовании криптографических механизмов, против защищенных распознавателей и серверов имен – в таких атаках могут предприниматься попытки использования механизмов DNSSEC для потребления значительных ресурсов атакуемой системы. Этот класс атак принимает как минимум две формы. Атакующий может поглотить значительные ресурсы на проверку подписей в защищенном распознавателе путем подмены записей RRSIG RR в откликах или путем создания чрезмерно сложных цепочек сигнатур. Атакующий может также потребить ресурсы защищенных серверов имен, поддерживающих динамические обновления, передавая им поток обновлений, заставляющих сервер заново подписывать некоторые наборы RRset с более высокой частотой, нежели это нужно при нормальной работе.

В результате обдуманного выбора разработчиков DNSSEC не обеспечивает защиты конфиденциальности.

DNSSEC позволяет недружественной стороне найти все имена в зоне, следуя по цепочке NSEC. Записи NSEC RR обеспечивают связь существующего в зоне имени со следующим существующим именем в каноническом порядке. Таким образом, атакующий может последовательно запросить записи NSEC RR для получения всех имен в зоне. Хотя это не будет атакой на DNS, атакующий получает возможность узнать имена хостов и других ресурсов, имеющихся в зоне.

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

DNSSEC не защищает от подмены данных неподписанных зон. Неуполномоченные данные на срезах зон (склеивающие записи и NS RR в родительской зоне) не подписываются. Это не создает проблем при проверке корректности аутентификационной цепочки, но означает, что неуполномоченные данные сами по себе уязвимы для подмены при операциях переноса зон. Таким образом, хотя DNSSEC может обеспечить аутентификацию источника данных и целостность данных в RRset, такие функции не обеспечиваются для зон и требуется использовать другие механизмы (такие, как TSIG, SIG(0) IPsec) для защиты операций переноса зон.

Дополнительная информация по вопросам безопасности приведена в [RFC4034] и [RFC4035].

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

Этот документ был создан на основе идей и результатов работы членов группы DNS Extensions. Указать полный список всех, кто внес свой вклад за десятилетие разработки DNSSEC, не представляется возможным. Редакторы хотят поблагодарить и отметить вклад в подготовку документа таких людей, как Jaap Akkerhuis, Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein, David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson, Gilles Guette, Andreas Gustafsson, Jun-ichiro Itojun Hagino, Phillip Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson, Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters, Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis, Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ Mundy, Thomas Narten, Mans Nilsson, Masataka Ohta, Mike Patton, Rob Payne, Jim Reid, Michael Richardson, Erik Rozendaal, Marcos Sanz, Pekka Savola, Jakob Schlyter, Mike StJohns, Paul Vixie, Sam Weiler, Brian Wellington и Suzanne Woolf.

Приведенный список, вне всяких сомнений, неполон и мы извиняемся перед всеми, кто оказался за его пределами.

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

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

[RFC1034] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, November 1987.

[RFC1035] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, November 1987.

[RFC2535] Eastlake 3rd, D., «Domain Name System Security Extensions», RFC 2535, March 1999.

[RFC2671] Vixie, P., «Extension Mechanisms for DNS (EDNS0)», RFC 2671, August 1999.

[RFC3225] Conrad, D., «Indicating Resolver Support of DNSSEC», RFC 3225, December 2001.

[RFC3226] Gudmundsson, O., «DNSSEC and IPv6 A6 aware server/resolver message size requirements», RFC 3226, December 2001.

[RFC3445] Massey, D. and S. Rose, «Limiting the Scope of the KEY Resource Record (RR)», RFC 3445, December 2002.

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Resource Records for DNS Security Extensions», RFC 4034, March 2005.

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Protocol Modifications for the DNS Security Extensions», RFC 4035, March 2005.

14.2. Информационные документы

[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, «Dynamic Updates in the Domain Name System (DNS UPDATE)», RFC 2136, April 1997.

[RFC2181] Elz, R. and R. Bush, «Clarifications to the DNS Specification», RFC 2181, July 1997.

[RFC2308] Andrews, M., «Negative Caching of DNS Queries (DNS NCACHE)», RFC 2308, March 1998.

[RFC2538] Eastlake 3rd, D. and O. Gudmundsson, «Storing Certificates in the Domain Name System (DNS)», RFC 2538, March 1999.

[RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, «Secret Key Transaction Authentication for DNS (TSIG)», RFC 2845, May 2000.

[RFC2931] Eastlake 3rd, D., «DNS Request and Transaction Signatures ( SIG(0)s )», RFC 2931, September 2000.

[RFC3007] Wellington, B., «Secure Domain Name System (DNS) Dynamic Update», RFC 3007, November 2000.

[RFC3008] Wellington, B., «Domain Name System Security (DNSSEC) Signing Authority», RFC 3008, November 2000.

[RFC3090] Lewis, E., «DNS Security Extension Clarification on Zone Status», RFC 3090, March 2001.

[RFC3597] Gustafsson, A., «Handling of Unknown DNS Resource Record (RR) Types», RFC 3597, September 2003.

[RFC3655] Wellington, B. and O. Gudmundsson, «Redefinition of DNS Authenticated Data (AD) bit», RFC 3655, November 2003.

[RFC3658] Gudmundsson, O., «Delegation Signer (DS) Resource Record (RR)», RFC 3658, December 2003.

[RFC3755] Weiler, S., «Legacy Resolver Compatibility for Delegation Signer (DS)», RFC 3755, May 2004.

[RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, «Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag», RFC 3757, April 2004.

[RFC3833] Atkins, D. and R. Austein, «Threat Analysis of the Domain Name System (DNS)», RFC 3833, August 2004.

[RFC3845] Schlyter, J., «DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format», RFC 3845, August 2004.

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

Roy Arends

Telematica Instituut

Brouwerijstraat 1

7523 XC Enschede

NL

EMail: roy.arends@telin.nl

Rob Austein

Internet Systems Consortium

950 Charter Street

Redwood City, CA 94063

USA

EMail: sra@isc.org

Matt Larson

VeriSign, Inc.

21345 Ridgetop Circle

Dulles, VA 20166-6503

USA

EMail: mlarson@verisign.com

Dan Massey

Colorado State University

Department of Computer Science

Fort Collins, CO 80523-1873

EMail: massey@cs.colostate.edu

Scott Rose

National Institute for Standards and Technology

100 Bureau Drive

Gaithersburg, MD 20899-8920

USA

EMail: scott.rose@nist.gov

Полное заявление авторских прав

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.


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

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

nmalykh@protocols.ru

1Domain Name System Security Extensions – расширение системы доменных имен в целях безопасности.

2Resource record – запись для ресурса.

3В оригинале — security-aware resolver.

4Передачи полномочий

5В оригинале — security-aware. Использованный здесь перевод не совсем точен, но суть отражает достаточно верно. Корректным и точным переводом будет “понимающий методы защиты, описанные в настоящем наборе документов”. Прим. перев.

6Защищенный сервер имен, предоставляющий рекурсивный сервис.

7Resource Record Signature

8Next Secure

9Resource Record Signature – подпись RR

10DNS Public Key – открытый ключ DNS.

11Delegation Signer

12Next Secure

13Checking Disabled – проверка запрещена.

14Authenticated Data – аутентифицированные данные.




RFC 3985 Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture

Network Working Group                                 S. Bryant, Ed.
Request for Comments: 3985                             Cisco Systems
Category: Informational                                 P. Pate, Ed.
                                             Overture Networks, Inc.
                                                          March 2005

Архитектура сквозной эмуляции псевдопровода (PWE3)

Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture

PDF

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

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

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

Copyright (C) The Internet Society (2005).

Тезисы

Этот документ описывает архитектуру сквозной эмуляции псевдопровода (PWE31). Обсуждается эмуляция таких служб, как Frame Relay, ATM, Ethernet, TDM, SONET/SDH в сетях с коммутацией пакетов (PSN), использующих IP или MPLS. Документ представляет архитектурную схему псевдопроводов (PW), определяет терминологию, задает различные протокольные элементы и их функции.

Оглавление

Исключено из версии HTML

1. Введение

В этом документе описана архитектура сквозной эмуляции псевдопровода (PWE32) в соответствии с [RFC3916]. В документе рассматривается эмуляция таких служб, как Frame Relay, ATM, Ethernet, TDM и SONET/SDH в сетях с коммутацией пакетов (PSN3), использующих IP или MPLS. Документ представляет архитектурную схему псевдопроводов (PW4), определяет используемые термины, а также описывает различные протокольные элементы и их функции.

1.1. Определение псевдопровода

PWE3 представляет собой механизм, который эмулирует существенные атрибуты телекоммуникационного сервиса (такого, как выделенные линии T1 или Frame Relay) в сетях PSN. Задачей PWE3 является лишь обеспечение минимальной требуемой функциональности для эмуляции провода с требуемой степенью достоверности для данного типа сервиса. За реализацию всех функций коммутации отвечает механизм пересылки (FWRD). Все преобразования и другие операции, требующие знания семантики передаваемой информации, осуществляются элементами естественного сервиса (NSP5). Функциональные определения каких-либо элементов FWRD или NSP выходят за пределы PWE3.

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

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

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

1.2. Функциональность PW

Для обеспечение эмуляции поведения и характеристик естественного сервиса PW обеспечивают следующие функции:

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

1.3. Что не рассматривается в этом документе и не относится к PW

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

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

Перечисленные ниже аспекты лежат за пределами PWE3:

  • любые службы с групповой адресацией, не являющиеся естественными для эмулируемого сервиса; таким образом, передача кадров Ethernet по групповому адресу IEEE-48 относится к PWE3, а службы с групповой адресацией типа MARS [RFC2022] не относятся;
  • методы сигнализации и контроля для сети PSN, в которой используется инкапсуляция.

1.4. Терминология

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

Attachment Circuit (AC) – устройство подключения

Физическое или виртуальное устройство, обеспечивающее подключение CE к PE. В качестве AC может выступать Frame Relay DLCI, ATM VPI/VCI, порт Ethernet, VLAN, канал HDLC, соединение PPP на физическом интерфейсе, сессия PPP через туннель L2TP, MPLS LSP и т. п. Если физические или виртуальные AC используют одну и ту же технологию (например, оба устройства ATM, Ethernet или Frame Relay), говорят, что PW обеспечивает «однородный транспорт»; в противном случае транспорт является разнородным (гетерогенным).

CE-bound – к абоненту

Направление трафика, при котором PW-PDU принимаются на PW через сеть PSN, обрабатываются и передаются устройству CE (адресату).

CE Signaling — сигнализация CE

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

Control Word (CW) – управляющее слово

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

Customer Edge (CE) – пользовательский край

Устройство, один край которого является источником или завершением сервиса. Устройство CE не знает какой сервис используется – естественный или эмулируемый.

Forwarder (FWRD) – система пересылки

Подсистема PE, которая выбирает PW для передачи информации, полученной в AC.

Fragmentation — фрагментация

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

Maximum Transmission unit (MTU) – максимальный передаваемый блок

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

Native Service Processing (NSP)

Обработка данных, полученных PE от устройства CE до их представления PW для передачи в сеть, или обработка данных, полученных от PW устройством PE до их передачи устройству AC. Функционально NSP определяется не IETF, а комитетами по стандартизации (такими, как ITU-T, ANSI, ATMF)

Packet Switched Network (PSN) – сеть с коммутацией пакетов

В контексте PWE3 это сеть, использующая IP или MPLS в качестве механизма пересылки пакетов.

PE-Bound – в сторону сети

Направление трафика, при котором информация от CE адаптируется для PW и блоки PW-PDU передаются в сеть PSN.

PE/PW Maintenance – обслуживание PE/PW

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

Protocol Data Unit (PDU) – модуль данных протокола

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

Provider Edge (PE) – провайдерский край

Устройство, обеспечивающее PWE3 для CE.

Pseudo Wire (PW) – псевдопровод

Механизм, обеспечивающий передачу существенных элементов эмулируемого сервиса из устройства PE в одно или множество других устройств PE через сеть PSN.

Pseudo Wire Emulation Edge to Edge (PWE3) – сквозная эмуляция псевдопровода

Механизм, эмулирующий существенные атрибуты сервиса (такого, как выделенная линия T1 или Frame Relay) через сеть PSN.

Pseudo Wire PDU (PW-PDU) – PDU псевдопровода

Блок PDU, передаваемый в PW и содержащий все данные и управляющую информацию, требуемые для эмуляции нужного сервиса.

PSN Tunnel – туннель PSN

Туннель через сеть PSN, внутри которого могут передаваться один или множество PW.

PSN Tunnel Signaling – сигнализация туннеля PSN

Используется организации, поддержки и разрыва туннелей PSN.

PW Demultiplexer – демультиплексор PW

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

Time Domain Multiplexing (TDM) – мультиплексирование с разделением по времени

Мультиплексирование TDM. Этот термин часто используется для обозначения синхронных битовых потоков со скоростями, определенными в стандарте G.702.

Tunnel — туннель

Метод прозрачной передачи информации через сеть.

2. Применимость PWE3

В сети PSN используемой для PW может происходить потеря пакетов, их задержка, которая может варьироваться в широких пределах, и нарушение порядка доставки пакетов. В периоды неустойчивости сети могут возникать достаточно продолжительные интервалы существенного снижения качества сервиса и даже его полной неработоспособности. Применимость PWE3 для того или иного сервиса зависит от чувствительности данного сервиса (или реализации CE) к перечисленным воздействиям, а также от возможностей уровня адаптации по маскированию вредных воздействий. Некоторые службы (например, IP over FR over PWE3) могут быть достаточно устойчивы к характеристикам сетей IP и MPLS. Другие типы сервиса (например, соединение PBX через PWE3) будут требовать более осторожного подхода к характеристикам PSN и уровня адаптации. В некоторых случаях требуется использование средств организации трафика PSN, а иногда ограничения будут делать невозможными требуемые для сервиса гарантии.

3. Многоуровневая модель

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

+------------------------+
| Payload |
+------------------------+
| Encapsulation          | <==== м. б. пустой
+------------------------+
| PW Demultiplexer       |
+------------------------+
| PSN Convergence        | <==== м. б. пустой
+------------------------+
| PSN                    |
+------------------------+
| Data-Link              |
+------------------------+
| Physical               |
+------------------------+

Рисунок 1: Модель логических уровней протокола

3.1. Протокольные уровни

Логическая структура многоуровневой модели для поддержки PW показана на рисунке 1.

Информация (payload) транспортируется через уровень инкапсуляции (Encapsulation Layer). Этот уровень передает всю информацию (не только собственно данные — payload), которая требуется интерфейсу PW CE-bound PE для передачи данных устройству CE через физический интерфейс. Если кроме данных не передается никакой информации, этот уровень остается пустым.

Уровень инкапсуляции обеспечивает также поддержку обработки в реальном масштабе времени, если это требуется для упорядочения.

Уровень демультиплексирования (PW Demultiplexer) обеспечивает возможность доставки множества PW через один туннель PSN. Значение PW Demultiplexer, используемое для идентификации PW в плоскости данных, может быть уникальным для каждого PE, но это требование не является обязательным для PWE3. Однако идентификаторы должны быть уникальными в масштабах конечной точки туннеля. Если требуется обеспечить идентификацию отдельных туннелей, ответственность за это ложится на уровень PSN.

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

Определения заголовков PSN, канального (MAC/Data-Link) и физического уровня выходят за пределы настоящего документа. PSN может быть IPv4, IPv6 или MPLS.

3.2. Сфера действия PWE3

PWE3 определяет уровень инкапсуляции – метод передачи различных типов информации (payload) и интерфейс с уровнем PW Demultiplexer. Предполагается, что другие уровни будут обеспечиваться с помощью методов туннелирования типа L2TP или MPLS через PSN.

3.3. Типы информационных полей

Данные классифицируются на несколько типов блоков данных естественного сервиса:

  • пакет;
  • ячейка;
  • битовый поток;
  • структурированный битовый поток.

В рамках этих базовых типов имеются связанные с сервисом подтипы:

Базовый тип Сервис PW
пакет Ethernet (все типы), кадрирование HDLC, Frame Relay, ATM AAL5 PDU
ячейка ATM
битовый поток Неструктурированные потоки E1, T1, E3, T3
структурированный битовый поток SONET/SDH (например, SPE, VT, NxDS0)

3.3.1. Пакетные данные

Пакеты (packet payload) представляют собой блоки данных переменной длины, доставляемые PE через AC. Размер пакетов может превышать PSN MTU. Границы пакетов определяются типом инкапсуляции. Примерами пакетных данных могут служить HDLC или Ethernet. Обычно из пакетов удаляется избыточная служебная информация (типа флагов HDLC и битов заполнения) перед тем, как пакеты будет переданы через PW.

Пакетные данные обычно передаются через PW в виде одного блока. Однако возможны случаи, когда размер пакетных данных в сумме с заголовками PWE3 и PSN будет превышать значение MTU на пути через PSN MTU. В таких случаях используется тот или иной механизм фрагментации. Это может быть, например, в случаях, когда пользователь обеспечивает сервис и соединяется с провайдером через Ethernet или когда используются “вложенные” псевдопровода. Фрагментация более подробно рассматривается в параграфе 5.3.

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

В некоторых случаях пакетные данные могут выбираться из присутствующих в эмулируемом проводе пакетов на основе того или иного метода субмультиплексирования. Например, один или несколько блоков Frame Relay PDU могут быть выбраны для транспортировки через определенный псевдопровод на основе Frame Relay DLCI7 или, для случая Ethernet, может использоваться подходящий фильтр MAC-уровня. Эта функция относится к системе пересылки и выбор, следовательно, будет происходить до того, как пакет будет представлен уровню инкапсуляции (PW Encapsulation).

3.3.2. Данные в ячейках

Данные в ячейках (cell payload) создаются путем сбора, доставки и восстановления (replaying) групп октетов, представленных в проводе в формате с фиксированным размером. Границы группы битов, составляющих ячейку, определяются типом инкапсуляции. Двумя наиболее распространенными примерами могут служить ячейки ATM размером 53 октета и пакеты MPEG Transport Stream [DVB] размером 188 октетов.

Для снижения объема служебной информации, передаваемой через PSN, множество ячеек может объединяться в один блок данных (payload). Уровень инкапсуляции может завершать формирование такого блока по таймеру, количеству ячеек или при получении специальной ячейки (например, ATM OAM). Преимущества объединения множества ячеек следует оценивать с учетом возможного роста вариации задержек и более серьезных потерь в случаях потери пакетов. В некоторых ситуациях на уровне инкапсуляции целесообразно использовать ту или иную компрессию (например, подавление пауз — silence suppression или сжатие голосовых данных).

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

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

В некоторых случаях ячейки, помещаемые в поле данных (payload), могут выбираться путем фильтрации потока ячеек, присутствующих в проводе. Например, сервис ATM PWE3 может фильтровать ячейки по значениям полей VCI или VPI. Эта функция реализуется системой пересылки и, следовательно, выбор происходит до представления пакета уровню инкапсуляции.

3.3.3. Битовый поток

Данные в форме битовых потоков (bit stream payload) создаются путем захвата, доставки и воспроизведения битовых потоков в проводе без учета структуры потока, которая на поверку может быть видна в транслируемом трафике (к примеру, внутренняя структура не оказывает влияния на фрагментацию пакетов).

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

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

3.3.4. Структурированный битовый поток

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

Между структурированными и неструктурированными битовыми потоками существует два важных отличия:

  • Некоторые части исходного битового потока могут вырезаться при передаче в направлении PSN-bound в блоке NSP. Например, раздел Structured SONET и служебная строка (возможно и более) могут фильтроваться. Для обеспечения возможности такого вырезания требуется формирователь кадров (framer). Требуется также выравнивание кадров/данных для дробных потоков T1/E1.
  • От PW требуется сохранение структуры при передаче через PSN, поэтому блок CE-bound NSP может вставлять информацию в восстановленный неструктурированный поток битов. Вырезанная информация (например, выравнивание указателей SONET) может появляться на уровне инкапсуляции для упрощения этой реконструкции.

В качестве опции уровень инкапсуляции может также использовать подавление пауз (silence/idle suppression) или аналогичные механизмы компрессии по отношению к структурированному потоку.

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

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

3.3.5. Принцип минимального вмешательства

Для минимизации просмотра данных и повышения эффективности потока данных через уровень инкапсуляции данные следует транспортировать в том виде, как они получены с минимальными изменениями [RFC1958].

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

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

4. Архитектура псевдопроводов

В этой главе описана архитектурная модель PWE3.

4.1. Эталонная модель

На рисунке 2 показана эталонная модель PW типа “точка-точка”.

      |<------------- Эмулируемый сервис --------------->|
      |                                                  |
      |          |<------ псевдопровод ------>|          |
      |          |                            |          |
      |          |    |<-- Туннель PSN ->|    |          |
      |          V    V                  V    V          |
      V    AC    +----+                  +----+    AC    V
+-----+    |     | PE1|==================| PE2|    |     +-----+
|     |----------|............PW1.............|----------|     |
| CE1 |    |     |    |                  |    |    |     | CE2 |
|     |----------|............PW2.............|----------|     |
+-----+  ^ |     |    |==================|    |    | ^   +-----+
      ^  | |     +----+                  +----+    | |   ^
      |  |        PE 1                    PE 2       |   |
      |  |                                           |   |
    CE 1 |                                           |  CE 2
         |                                           |
         |                                           |
Естественный сервис                         Естественный сервис

Рисунок 2: Эталонная модель PWE3

Два устройства PE (PE1 и PE2) обеспечивают один или более PW от имени клиентских устройств CE (CE1 и CE2) чтобы обеспечить взаимодействие клиентских CE через сеть PSN. Чтобы обеспечить путь передачи данных для PW создается туннель PSN. Трафик PW остается невидимым для промежуточной сети, которая прозрачна для CE. Естественные блоки данных (биты, ячейки или пакеты), поступающие через AC, инкапсулируются в PW-PDU и передаются через сеть с использованием туннеля PSN. Устройства PE выполняют необходимую инкапсуляцию и декапсуляцию PW-PDU, а также выполняют другие функции, требуемые сервисом PW (такие, как упорядочение или синхронизация).

4.2. Предварительная обработка PWE3

 Некоторые приложения выполняют те или иные операции по отношению к естественным блокам данных, полученным от CE (включая информацию и сигнальный трафик), до передачи через PW. Примерами могут служить мосты Ethernet, кросс-соединения SONET, трансляция идентификаторов локальной значимости (таких, как VCI/VPI) или преобразование к другому типу сервиса. Эти операции могут выполняться внешним оборудованием с передачей обработанных данных устройству PE через один или множество физических интерфейсов. Во многих случаях выполнение таких операций в PE обеспечивает экономические и эксплуатационные преимущества. Обработанные данные в таких случаях передаются в PW через виртуальный интерфейс внутри PE. Такие операции предварительной обработки включены в эталонную модель PWE3 для обеспечения единой контрольной точки (reference point), но детальное описание этих операций выходит за пределы рассматриваемых здесь определений PW.

           Завершение PW
                 |
                 |<------ псевдопровод ----->|
                 |                            |
                 |    |<-- Туннель PSN ->|    |
                 V    V                  V    V     
           +-----+----+                  +----+ Завершение PW
+-----+    |PREP | PE1|==================| PE2|     |    +-----+
|     |    |     |............PW1.............|----------|     |
| CE1 |----|     |    |                  |    |     |    | CE2 |
|     | ^  |     |............PW2.............|----------|     |
+-----+ |  |     |    |==================|    |     | ^  +-----+
        |  +-----+----+                  +----+     | |
        |        ^                                  | |
        |        |                                  | |
        |        |<------ Эмулируемый сервис ------>| |
        |        |                                    |
        | Виртуальное физическое                      |
        | завершение                                  |
        |        ^                                    |
Естественный     |                                Естественный
сервис CE1       |                                сервис CE2
                 |
      Естественный сервис CE2

Рисунок 3: Предварительная обработка в эталонной модели PWE3

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

Работа систем, в которых оба устройства PE включают PREP, также поддерживается.

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

  • пересылка (FWRD);
  • естественная для сервиса обработка (NSP).

4.2.1. Системы пересылки

Некоторые приложения селективно пересылают блоки данных от одного или множества AC одному или многим PW. В таких случаях требуется также выполнять обратные операции для PWE3-PDU, полученных PE из сети PSN. Это относится к функциям системы пересылки.

Система пересылки (forwarder) выбирает PW на основе AC-отправителя, содержимого поля данных или неких статически или динамически задаваемых параметров.

        +---------------------------------------+
        |               Устройство PE           |
        +---------------------------------------+
 Одно   |                |                      |
 AC     |                |        Один          | Экземпляр PW
<------>o   Forwarder    +      экземпляр PW    X<===========>
        |                |                      |
        +---------------------------------------+

Рисунок 4a: Простой сервис “точка-точка”

        +---------------------------------------+
        |               Устройство PE           |
        +---------------------------------------+
Много   |                |        Один          | Экземпляр PW
AC      |                +      экземпляр PW    X<===========>
<------>o                |                      |
        |                |----------------------|
<------>o                |        Один          | Экземпляр PW
        |    Forwarder   +      экземпляр PW    X<===========>
<------>o                |                      |
        |                |----------------------|
<------>o                |        Один          | Экземпляр PW
        |                +      экземпляр PW    X<===========>
<------>o                |                      |
        +---------------------------------------+

Рисунок 4b: Пересылка от множества AC во множество PW

На рисунке 4a показана простая система пересылки, выполняющая некоторые операции по фильтрации. Поскольку система пересылки имеет один входной интерфейс и один выходной, фильтрация является единственным типом операций, выполняемых при пересылке. На рисунке 4b показана более распространенная ситуация, когда данные от одного или множества AC направляются одному или множеству PW. В таких случаях к данным могут применяться операции пересылки, фильтрации или их комбинация. Например, если AC использует Frame Relay, система пересылки может выполнять коммутацию Frame Relay, а экземпляры PW могут быть соединениями между коммутаторами.

4.2.2. Естественная обработка

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

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

На рисунке 5 показаны связи между NSP, системой пересылки и PW внутри PE. Функции NSP могут выполнять любые преобразования (изменение, вставку и т. п.) по отношению к данным, проходящим через физический интерфейс к CE и через виртуальный интерфейс к системе пересылки. Эти преобразования будут, естественно, ограничены теми операциями, которые могут быть выполнены на пути передачи данных и разрешены конфигурацией PE. Устройство PE может включать более одной системы пересылки.

        +---------------------------------------+
        |               Устройство PE           |
Много   +---------------------------------------+
AC      |   |            |        Один          | Экземпляр PW
<------>oNSP#            +      экземпляр PW    X<===========>
        |   |            |                      |
        |---|            |----------------------|
        |   |            |        Один          | Экземпляр PW
<------>oNSP# Forwarder  +      экземпляр PW    X<===========>
        |   |            |                      |
        |---|            |----------------------|
        |   |            |        Один          | Экземпляр PW
<------>oNSP#            +      экземпляр PW    X<===========>
        |   |            |                      |
        +---------------------------------------+

Рисунок 5: Пересылка от множества AC во множество PW

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

4.3. Эталонная модель поддержки

На рисунке 6 показана эталонная модель поддержки для PW.

      |<------- Сигнализация CE (сквозная) ----->|
      |     |<----- Поддержка PW/PE ------>|     |
      |     |     |<- Сигнализация ->|     |     |
      |     |     |   туннеля PSN    |     |     |
      |     V     V  (не рассматр.)  V     V     |
      v     +-----+                  +-----+     v
+-----+     | PE1 |==================| PE2 |     +-----+
|     |-----|.............PW1..............|-----|     |
| CE1 |     |     |                  |     |     | CE2 |
|     |-----|.............PW2..............|-----|     |
+-----+     |     |==================|     |     +-----+
            +-----+                  +-----+
CE 1        PE 1                     PE 2         CE 2

Рисунок 6: Эталонная модель поддержки PWE3

Требуются перечисленные ниже сигнальные механизмы:

  • Сквозная сигнализация между устройствами CE, в качестве которой может использоваться Frame Relay PVC status, ATM SVC, TDM CAS и т. п.
  • Поддержка PW/PE используется между устройствами PE (или NSP) для организации, поддержки и разрыва PW, включая всю требуемую координацию параметров.
  • Сигнализация туннеля PSN управляет мультиплексированием PW и некоторыми элементами PSN. Примерами могут служить протокол управления L2TP, MPLS LDP и RSVP-TE. Определение информации, которую нужно передавать в качестве сигналов PWE3 входит в задачи PWE3, но сами сигнальные протоколы не входят сюда.

4.4. Эталонная модель стека протоколов

На рисунке 7 показана эталонная модель стека протоколов для PW.

+-----------------+                           +-----------------+
| Эмулир.  сервис |                           | Эмулир.  сервис |
|(напр., TDM, ATM)|<== Эмулируемый сервис ===>|(напр., TDM, ATM)|
+-----------------+                           +-----------------+
|  Инкапсуляция   |                           |  Инкапсуляция   |
|     данных      |<===== псевдопровод ======>|     данных      |
+-----------------+                           +-----------------+
|     Уровни      |                           |     Уровни      |
|PW Demultiplexer |                           |PW Demultiplexer |
|   PSN Tunnel,   |<====== Туннель PSN ======>|   PSN Tunnel,   |
| PSN и Physical  |                           | PSN и Physical  |
+-------+---------+        ___________        +---------+-------+
        |                /             \                |
        +===============/     PSN       \===============+
                        \               /
                         \_____________/

Рисунок 7: Эталонная модель стека протоколов PWE3

PW обеспечивает CE эмулируемым физическим или виртуальным соединением с удаленным партнером. PDU естественного сервиса от CE проходят через уровень инкапсуляции на передающем устройстве PE и пересылаются после этого через сеть PSN. Принимающее устройство PE выполняет декапсуляцию и восстанавливает информацию в ее естественном формате для передачи CE-адресату.

4.5. Предварительная обработка для эталонной модели стека протоколов

На рисунке 8 показано как эталонная модель стека протоколов расширяется для выполнения предварительной обработки (пересылка и NSP). Приведенная схема показывает расположение физического интерфейса относительно CE.

/======================================\
H      Система пересылки               H<----Предварительная
H----------------======================/     обработка
H Естественная   H   |                 |
H обработка серв.H   |                 |
\================/   |                 |
|                |   | Эмулируемый     |
| Интерфейс      |   | сервис          |
| сервиса        |   | (TDM, ATM,      |
| (TDM, ATM,     |   | Ethernet,       |<== Эмулируемый ==
| Ethernet,      |   | Frame Relay,    |    сервис
| Frame Relay,   |   | и т. п.)        |
| и т. п.)       |   +-----------------+
|                |   | Инкапсуляция    |
|                |   | данных          |<=== псевдопровод ==
|                |   +-----------------+
|                |   |Заголовки PW-    |
|                |   |демультиплексора |
|                |   |туннеля PSN, PSN |<=== туннель PSN ====
|                |   |и физич. уровня  |
+----------------+   +-----------------+
|Физичес. уровень|   |Физичес. уровень |
+-------+--------+   +-------+---------+
        |                    |
        |                    |
        |                    |
        |                    |
        |                    |
        |                    |
К CE <--+                    +--> В PSN

Рисунок 8: Эталонная модель стека протоколов с предварительной обработкой

5. Инкапсуляция PW

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

Уровень инкапсуляции PW включает три подуровня:

  • Payload Convergence – конвергенция данных;
  • Timing — синхронизация;
  • Sequencing — упорядочение.

Подуровни уровня инкапсуляции PW в контексте стека протоколов показаны на рисунке 9.

+---------------------------+
|         Payload           |
/===========================\ <------ Уровень      
H    Payload Convergence    H    инкапсуляции
H---------------------------H
H          Timing           H
H---------------------------H
H        Sequencing         H
\===========================/
|     PW Demultiplexer      |
+---------------------------+
|     PSN Convergence       |
+---------------------------+
|           PSN             |
+---------------------------+
|         Data-Link         |
+---------------------------+
|          Physical         |
+---------------------------+

Рисунок 9: Уровень инкапсуляции PWE3

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

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

5.1. Подуровень конвергенции данных

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

Основной задачей подуровня конвергенции является инкапсуляция данных в PW-PDU. Инкапсулируемые естественные блоки данных могут содержать служебную информацию в канального (L2) и физического (L1) уровня. Эта информация зависит от типа сервиса. Заголовок подуровня конвергенции содержит дополнительную информацию, требуемую для восстановления естественных блоков данных на физическом интерфейсе в направлении CE-bound (к абоненту). Заголовок уровня демультиплексирования не рассматривается как часть заголовка PW.

Не вся дополнительная информация, требуемая для восстановления естественных блоков данных, передается в PW-заголовке PW PDU. Часть информации (например, тип сервиса для PW) может сохраняться на приемной стороне (destination PE) во время организации PW.

5.1.2. Типы каналов PWE3

Уровень инкапсуляции PW и связанная с ним сигнализация требуют одного или нескольких каналов (канал типа 1 + один или несколько каналов типа 2 — 4) из числа перечисленных ниже от нижележащих уровней демультиплексирования PW и PSN:

  1. Канал управления с гарантированной доставкой для сигнализации, индикации состояний и, в исключительных случаях, событий CE-CE, которые должны транслироваться и гарантированно передаваться между PE. PWE3 может потребоваться этот тип канала для обеспечения достоверной эмуляции сложных протоколов канального уровня.
  2. Канал с высоким приоритетом и соблюдением порядка доставки, но без гарантии доставки пакетов. Такие каналы обычно используются для сигнализации между устройствами CE. “Высокий приоритет” может просто задаваться битами DSCP для протокола IP или EXP для MPLS, обеспечивая пакетам приоритетную доставку. Этот тип каналов может также использовать бит в заголовке самого туннеля для индикации того, что полученные PE пакеты следует обрабатывать с более высоким приоритетом [RFC2474].
  3. Канал с упорядоченной доставкой для передачи данных, чувствительных к нарушению порядка следования пакетов (одним из вариантов такого трафика могут быть данные протоколов, отличных от IP).
  4. Канал с неупорядоченной доставкой для данных, не чувствительных к нарушению порядка пакетов.

Каналы данных (2, 3, 4) следует передавать в одной полосе (in band) с другими для эффективного использования возможностей PSN.

Там, где сквозная связность может нарушаться системами трансляции адресов [RFC3022], списками контроля доступа, межсетевыми экранами и т. п., могут возникать ситуации, когда канал управления сможет передавать трафик и создавать PW, а трафик данных PW будет блокироваться одним или несколькими упомянутыми механизмами. В этих случаях, если канал управления не передается в той же полосе (in band), сигнализация при организации PW не будет подтверждать существование сквозного пути передачи данных. В некоторых случаях требуется синхронизация событий CE с данными, передаваемыми через PW. В частности, такая ситуация возникает при использовании устройств TDM (например, информация о поднятии/опускании телефонной трубки в коммутаторах PSTN может передаваться через сигнальный канал с гарантированной доставкой, тогда как связанные с телефонным разговором данные будут передаваться через упорядоченный канал данных).

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

5.1.3. Качество обслуживания

По возможности следует реализовать для PW поддержку механизма QoS9 через PSN.

5.2. Независимые от типа данных подуровни инкапсуляции PW

Подуровни упорядочения (Sequencing) и синхронизации (Timing) уровня инкапсуляции PWE3 обеспечивают общий сервис для всех типов данных. Этот сервис является необязательным и используется только в случае необходимости для конкретного экземпляра PW. Если сервер не нужен, соответствующий заголовок может быть опущен в целях экономии ресурсов при обработке и передаче через сеть.

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

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

5.2.1. Упорядоченная доставка

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

Размер пространства порядковых номеров зависит от скорости эмулируемого сервиса и максимального времени нахождения пакета в сети PSN. Следовательно, требуются порядковые номера более 2^16, чтобы избавиться от проблем, связанных с переходом через максимум в течение срока передачи пакета через сеть.

5.2.1.1. Упорядочение кадров

Когда пакеты, содержащие PW-PDU, проходят через PSN, они могут поменять порядок следования и прийти в PE с нарушением порядка. Для некоторых случаев кадры (управление, данные или оба типа) должны доставляться с сохранением порядка. Для таких типов сервиса должен поддерживаться тот или иной механизм, гарантирующий соблюдение порядка доставки. Задание порядковых номеров на подуровне упорядочения является одним из вариантов решения задачи. Отметим, что упорядоченная доставка является частным случаем задачи синхронизированной доставки и задача доставки с соблюдением порядка может быть решена вместе с задачей синхронизированной доставки с помощью одного комбинированного механизма (например, [RFC3550]).

Существует два варианта стратегии сохранения порядка доставки:

  • отбрасывание PW PDU, доставленных с нарушением порядка;
  • попытка сортировки PW PDU с целью восстановления порядка.

Выбор одного из этих вариантов будет зависеть от перечисленных ниже условий:

  • критичность потери пакетов для работы PW (например, допустимое число битовых ошибок в единицу времени);
  • скорость работы PW и PSN;
  • допустимая задержка (при попытке восстановления порядка);
  • предполагаемая частота нарушения порядка доставки.
5.2.1.2. Детектирование дубликатов

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

5.2.1.3. Детектирование потери кадров

PE-адресат может обнаружить потерю кадра, контролируя порядковые номера полученных PW PDU.

В некоторых системах, если PW PDU не поступает в течение некоторого времени, PE-адресат будет предполагать потерю пакета. Если такой PW-PDU впоследствии прибывает целевое устройство PE должно отбросить его.

5.2.2. Синхронизация

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

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

Следовательно, подуровень синхронизации должен поддерживать две функции: восстановление синхросигналов и синхронизированную доставку данных10. Те или иные типы сервиса могут использовать одну из этих функций или обе.

5.2.2.1. Восстановление синхросигналов

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

5.2.2.2. Синхронизированная доставка

Синхронизированная доставка (Timed delivery) представляет собой доставку дискретных PW PDU в выходной интерфейс PW с постоянным фазовым сдвигом относительно входного интерфейса. Синхронизация доставки может осуществляться по сигналам, восстановленным из потока пакетов, полученных через PSN, или по сигналам от внешнего источника.

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

В идеальном случае данные будут транслироваться через PW в виде одного блока. Однако возникают ситуации, когда суммарный размер данных и связанных с ними заголовков PWE3 и PSN будет превышать значение MTU для пути через PSN. Когда размер пакета превышает MTU данной сети, в процессе доставки пакетов используются операции фрагментации и сборки. Поскольку фрагментация и сборка пакетов требуют больших ресурсов, нежели простая передача пакетов, уровень фрагментации (и связанной с ней последующей сборки) следует снижать, насколько это возможно. Фрагментация и сборка пакетов могут стать существенной проблемой для узлов, в которых обрабатывается множество PW (например, в точках PE).

В идеальном оборудование, создающее трафик, который передается через PW, будет использовать механизмы адаптации (например, [RFC1191], [RFC1981]), которые обеспечат передачу пакетов, не требующих фрагментации. Когда фрагментации избежать не удается, точке, ближайшей к передающему хосту и поддерживающей возможность фрагментации и сборки, следует предпринять попытку снижения размера пакетов до требуемой величины (PSN MTU). Таким образом, в эталонной модели PWE3 (рисунок 3), фрагментацию следует пытаться выполнить в устройстве CE. Если CE не может обеспечить соответствующий MTU размер пакетов, PW следует предпринимать свои методы фрагментации.

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

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

Если размер кадра L2/L1, восстановленного из PW PDU, превышает значение MTU для AC-адресата, такой кадр должен быть отброшен. В этом случае система управления целевого PE может получить уведомление.

5.4. Конкретизация уровней протокола

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

5.4.1. PWE3 в сетях IP PSN

Определению протокола работы PWE3 через IP PSN следует использовать существующие протоколы IETF там, где это возможно.

На рисунке 10 показаны уровни протокола для работы PWE3 через IP PSN. Как правило данные следует передавать в том виде, в котором они были получены от NSP с использованием при необходимости подуровня конвергенции данных. Однако в некоторых ситуациях может оказаться предпочтительной передача данных в трансформированном виде. Причина преобразования должна быть документирована в определении уровня инкапсуляции для этого типа данных.

+---------------------+              +-------------------------+
|      Данные         |------------->|Необраб. данные, по-возм.|
/=====================\              +-------------------------+
H Конвергенция данных H-----------+->|     Flags, seq # и т. п.|
H---------------------H          /   +-------------------------+
H    Синхронизация    H---------/--->|            RTP          |
H---------------------H        /     +-------------+           |
H    Упорядочение     H----один из   |             |
\=====================/        \     |             +-----------+
| Демультиплексор PW  |---------+--->|     L2TP, MPLS и т. п.  |
+---------------------+              +-------------------------+
| Конвергенция PSN    |------------->|      Не требуется       |
+---------------------+              +-------------------------+
|        PSN          |------------->|            IP           |
+---------------------+              +-------------------------+
|      Канальный      |------------->|         Канальный       |
+---------------------+              +-------------------------+
|      Физический     |------------->|         Физический      |
+---------------------+              +-------------------------+

Рисунок 10: PWE3 через IP PSN

В тех случаях, когда это применимо, синхронизация обеспечивается с помощью протокола RTP [RFC3550], который (при его использовании) обеспечивает также сервис упорядочения. Когда сеть PSN работает на базе UDP/IP, заголовок RTP следует за заголовком UDP и предшествует полю управления PW. Во всех остальных случаях заголовок RTP следует за управляющим заголовком PW.

Уровень инкапсуляции может также передавать порядковый номер. Упорядочение обеспечивается RTP или уровнем инкапсуляции PW (но не обоими).

Демультиплексирование PW обеспечивается метками PW, которые могут иметь форму, заданную для множества протоколов IETF – например, метка MPLS [MPLSIP], идентификатор сессии L2TP [RFC3931] или номер порта UDP [RFC768]. Когда PW передаются через IP, уровень конвергенции PSN не требуется.

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

5.4.2. PWE3 в сетях MPLS PSN

Специфика MPLS весьма хороша для обеспечения эффективности “проводов”. За счет использования управляющего слова некоторые компоненты протоколов PWE3 могут быть сжаты для дополнительного повышения эффективности.

На рисунке 11 показана многоуровневая модель работы PWE3 через MPLS PSN. Метки MPLS служат для демультиплексирования PW. Управляющее слово служит для передачи большей части информации, требуемой уровню инкапсуляции PWE3 и конвергенции PSN, в компактном формате. Флаги в управляющем слове обеспечивают требуемую конвергенцию данных. Поле порядкового номера позволяет поддерживать как упорядоченную доставку, так и сервис фрагментации PSN на уровне конвергенции PSN (поддерживается с помощью метода управления фрагментацией). Ethernet дополняет все кадры до минимального размера 64 байта. Заголовок MPLS не включает поле размера. Следовательно, при передаче PWE3 через MPLS для корректного прохождения через каналы Ethernet требуется поле коррекции размера в управляющем слове. Как и для случаях IP PSN, синхронизацию (по возможности) следует обеспечивать с помощью RTP [RFC3550].

+---------------------+
|       Данные        |
/=====================\
H Конвергенция данных H--+
H---------------------H  |       +--------------------------------+
H    Синхронизация    H--------->|              RTP               |
H---------------------H  |       +--------------------------------+
H    Упорядочение     H--+------>| Flags, Frag, Len, Seq # и т. п.|
\=====================/  |       +--------------------------------+
| Демультиплексор PW  |--------->|           PW Label             |
+---------------------+  |       +--------------------------------+
| Конвергенция PSN    |--+  +--->| Outer Label или MPLS-in-IP инк.|
+---------------------+     |    +--------------------------------+
|        PSN          |-----+
+---------------------+
|      Канальный      |
+---------------------+
|      Физический     |
+---------------------+

Рисунок 11: PWE3 через MPLS PSN – использование Control Word

В некоторых сетях может потребоваться передача PWE3 через MPLS, который, в свою очередь, передается через IP. В таких случаях PW инкапсулируются для передачи через MPLS, как описано выше, а после этого к полученным PW-PDU применяются методы доставки MPLS через IP PSN (такие, как GRE [RFC2784], [RFC2890]).

5.4.3. Дискриминация пакетов PW-IP

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

6. Уровень демультиплексирования PW и требования к PSN

PWE3 предъявляет три требования к протокольным уровням, используемым для передачи через PSN:

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

6.1. Мультиплексирование

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

Некоторые типы естественного сервиса способны группировать множество устройств в транк (например, множество ATM VC в одном VP, множество Ethernet VLAN в одном физическом канале, множество DS0 в T1 или E1). PW может использоваться для соединения пары таких транков. Транк в таких случаях будет иметь один идентификатор мультиплексирования.

При использовании меток MPLS для мультиплексирования установка значения TTL [RFC3032] в поле PW определяется приложением.

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

Если PSN обеспечивает достаточную производительность фрагментации и сборки пакетов, эти функции можно использовать для разбиения крупных PW PDU в соответствии с MTU. Более подробное описание вопросов фрагментации и сборки пакетов приведено в параграфе 5.3.

6.3. Размер и доставка

Доставка PDU на принимающее устройство PE является функцией уровня PSN.

Если нижележащая PSN не предоставляет информации, достаточной для определения размера PW-PDU, этот размер должен задаваться уровнем инкапсуляции (Encapsulation Layer).

6.4. Проверка PW-PDU

Общепринятым является использование механизмов детектирования ошибок (например, CRC) для контроля целостности доставляемых кадров. Для конкретных типов сервиса должны задаваться механизмы, которые будут определять, следует ли передавать контрольную сумму через PW или ее нужно удалять из PDU, передаваемых в направлении PE-bound и заново рассчитывать для вставки в пакеты, передаваемые в направлении CE-bound.

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

Для таких протоколов, как ATM и FR, сфера действия контрольной суммы ограничена одним соединением. Это связано с тем, что идентификаторы (например, FR DLCI или ATM VPI/VCI) имеют лишь локальную значимость и изменяются на каждом отрезке пути. Если идентификатор устройства (и, следовательно, контрольная сумма) изменяются в процессе эмуляции PW, разумно будет исключить и заново рассчитать контрольную сумму.

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

6.5. Перегрузки

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

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

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

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

Сравнение с TCP не может быть выполнено в точности, но оно предназначено лишь для оценки и сравнения порядка величин. Период времени, в течение которого измеряется пропускная способность TCP составляет время кругового обхода для соединения. По сути, это требование говорит о недопустимости развертывания приложений (использующих PWE3 или другой транспортный протокол) в сети Internet без гарантий (best-effort), которые потребляют произвольную полосу и отличаются по порядку значений от TCP. Один из методов определения допустимой полосы PW описан в [RFC3448].

7. Управление

В этой главе рассматриваются службы управления PWE3.

7.1. Организация и разрыв псевдопроводов

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

Организация и разрыв PW могут выполняться по команде оператора через систему управления (management plane) PE, с помощью сигналов организации и разрыва от AC (например, ATM SVC) или с помощью механизма автоматического детектирования.

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

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

7.2. Мониторинг состояния

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

7.3. Уведомления о смене состояния псевдопровода

7.3.1. Уведомления об организации и разрыве PW

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

Поскольку два устройства CE эмулируемого сервиса не являются смежными, могут возникать отказы, при которых одно или оба физических соединения между CE и PE сохранят работоспособность. Например, если на рисунке 2 физическое соединение между CE1 и PE1 будет разорвано, это не окажет влияния физическое соединение между CE2 и PE2, которое продолжит работать. Если устройству CE2 не сообщить об удаленной аварии, оно будет продолжать передачу трафика через эмулируемый сервис устройству CE1 и этот трафик будет отбрасываться PE1. Некоторые типы естественного сервиса поддерживают индикацию сбоев, поэтому при отказе сервиса оба CE получат уведомление. Для такого естественного сервиса соответствующий сервис PWE3 должен обеспечивать механизм уведомления об отказах.

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

Такие механизмы могут уже быть встроены в протокол туннелирования. Например, протокол управления L2TP [RFC2661] [RFC3931] поддерживает такую возможность, а LDP имеет возможность отзывать соответствующие метки MPLS.

7.3.2. Ошибочные соединения и несоответствие типов данных

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

Для предотвращения проблем могут использоваться службы нижележащего механизма туннелирования и связанного с ним протокола управления. В процессе организации PW происходит обмен идентификаторами PW-TYPE, которые впоследствии используются системой пересылки и NSP для проверки совместимости AC.

7.3.3. Потеря и повреждение пакетов, доставка с нарушением порядка

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

7.3.4. Другие уведомления о состояниях

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

7.3.5. Коллективные уведомления о состоянии

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

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

7.4. Механизм Keep-Alive

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

7.5. Обслуживание управляющих сообщений естественного сервиса

Некоторые типы естественного сервиса используют управляющие сообщение для обслуживания устройств. Такие сообщения могут передаваться в основной полосе (например, управление потоком данных в Ethernet, управление производительностью ATM, тональная сигнализация TDM) или по отдельному каналу (например, VC-сигнализация в ATM VP, или сигнализация TDM CCS).

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

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

8. Управление и мониторинг

В этой главе описана архитектура управления и мониторинга для PWE3.

8.1. Состояния и статистика

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

  • принятые и переданные PW-PDU с учетом ошибок или без такового;
  • число потерянных один за другим PW-PDU;
  • число сервисных PDU, принятых и переданных через PSN с учетом ошибок или без него (кроме TDM);
  • связанные с сервисом счетчики для интерфейсов;
  • задержка в одном направлении и ее вариации.

Значения этих счетчиков содержатся в связанных с PW базах MIB и в них не следует дублировать существующие в MIB счетчики.

8.2. Архитектура PW SNMP MIB

В этом параграфе описана общая архитектура SNMP MIB, используемых для управления PW и нижележащей PSN. Задача состоит в создании четкой картины объединения всех имеющих отношение к делу MIB в одну согласованную схему управления для развертывания служб PWE3. Отметим, что приведенные ниже имена MIB являются лишь предложенным вариантом и реальные модули, используемые для реализации компонент, совсем не обязаны иметь именно такие имена.

8.2.1. Уровни MIB

Базам SNMP MIB, создаваемым для PWE3, следует соответствовать архитектуре, показанной на рисунке 12. Эта архитектура обеспечивает многоуровневую модульную схему, в которой любой поддерживаемый эмулируемый сервис может быть соединен с любым поддерживаемым типом PSN. Эта модель способствует максимальному использованию уже существующей функциональности. Например, модули MIB уровня эмулируемого сервиса не переопределяют заново существующие модули сервисного уровня для эмулируемого сервиса. Эти модули просто связываются с псевдопроводами, используемыми для доставки эмулируемого сервиса через заданный тип PSN. В результате архитектура PWE3 MIB соответствует общей архитектуре PWE3.

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

 MIB естественного
 сервиса         ...           ...               ...
                  |             |                 |
            +-----------+ +-----------+     +-----------+
 Сервисный  |    CEP    | | Ethernet  |     |    ATM    |
  уровень   |Service MIB| |Service MIB| ... |Service MIB|
            +-----------+ +-----------+     +-----------+
                    \           |             /
                      \         |           /
- - - - - - - - - - - - \ - - - | - - - - / - - - - - - -
                          \     |       /
            +-------------------------------------------+
 Базовый    |            Базовые PW MIB                 |
 уровень PW +-------------------------------------------+
                         /             \
- - - - - - - - - - - - / - - - - - - - - \ - - - - - - -
                      /                     \
                    /                         \
            +--------------+             +--------------+
 Уровень    |L2TP VC MIB   |             | MPLS VC MIB  |
 PSN VC     +--------------+             +--------------+
                   |                              |
 Естественные+-----------+                  +-----------+
 MIB PSN     |L2TP MIB   |                  |MPLS MIB   |
             +-----------+                  +-----------+

Рисунок 12: Уровни модулей MIB

На рисунке 13 показан пример для SONET PW при передаче через MPLS Traffic Engineering Tunnel и LSP с сигнализацией LDP.

                 +-----------------+
                 |    SONET MIB    |  RFC3592
                 +-----------------+
                          |
            +------------------------------+
 Сервисный  | Circuit Emulation Service MIB|
  уровень   +------------------------------+
- - - - - - - - - - - - - | - - - - - - - - - - - - -
                 +-----------------+
 Базовый         | Базовые PW MIB  |
 уровень PW      +-----------------+
           - - - - - - - - - - - - - | - - - - - - - 
                 +-----------------+
  Уровень        |   MPLS VC MIB   |
  PSN VC         +-----------------+
                    |           |
       +-----------------+  +------------------+
       | MPLS-TE-STD-MIB |  | MPLS-LSR-STD-MIB |
       +-----------------+  +------------------+

Рисунок 13: Пример для SONET PW через MPLS PSN

8.2.2. Модули сервисного уровня

Этот концептуальный уровень модели содержит модули MIB, используемые для представления отношений между эмулируемыми PWE3 службами (такими, как Ethernet, ATM или Frame Relay) и псевдопроводом, используемым для доставки сервиса через PSN. Данный уровень содержит соответствующие модули MIB, используемые для адаптации эмулируемых служб к базовому представлению псевдопровода, которое показано блоком «Базовые PW MIB» на рисунке 13. Рабочей группе PWE3 не следует создавать какие-либо модули MIB для управления базовым сервисом, а следует создать модули, которые обеспечат интерфейс или адаптацию в систему управления PWE3, как показано выше. Например, стандартная база SONET-MIB [RFC3592] разработана и поддерживается другой группой. База SONET-MIB создана для управления естественным сервисом без эмуляции PW. Задачей рабочей группы PWE3 является подготовка стандартов, которые показывают, как эмулировать существующие технологии (такие, как SONET/SDH) через псевдопроводные соединения, а не повторная разработка модулей.

8.2.3. Базовые модули PW MIB

Средний уровень архитектуры носит название “Базовый уровень PW” (Generic PW Layer). MIB этого уровня отвечают за представление связанных с псевдопроводом счетчиков и сервисные модели, используемые для мониторинга и настройки сервиса PWE3 через любую поддерживаемую сеть PSN. Т. е., данный уровень обеспечивает общую модель абстракции PWE3 для решения задач управления. Эта база MIB используется для соединения модулей MIB сервисного уровня с базами PSN VC Layer MIB (см. параграф 8.2.4).

8.2.4. MIB-модули уровня PSN VC

Третий уровень архитектуры управления PWE3 называется уровнем PSN VC. Этот уровень включает базы MIB, которые специально разработаны для связывания псевдопроводов с транспортными технологиями нижележащей PSN, которые передают данные из псевдопровода через сеть PSN. В общем случае это означает, что модуль MIB обеспечивает отображение эмулируемого сервиса, который связан с псевдопроводом через сервисный уровень и базовый уровень PW MIB, на естественный сервис PSN. Например, для случая MPLS требуется, чтобы общий сервис VC отображался на MPLS LSP через MPLS-LSR-STD-MIB [RFC3813] или на туннели TE13 через MPLS-TE-STD-MIB [RFC3812]. В дополнение к этому может использоваться MPLS-LDP-STD-MIB [RFC3815] для выявления меток MPLS, которые распространяются через MPLS PSN для поддержки сервиса PW. Как сказано выше модули MIB естественного сервиса, используемые для управления естественным сервисом PSN, разрабатываются другими группами, которые разрабатывают естественный сервис PSN. В эти модули MIB следует включать соответствующие механизмы для мониторинга и настройки сервиса PSN, чтобы эмулируемый сервис PWE3 работал корректно.

8.3. Проверка и трассировка соединений

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

В целях поиска неисправностей зачастую желательно иметь точную информацию о функциональном пути PW между устройствами PE. Эта информация обеспечивается средствами трассировки (traceroute) нижележащей сети PSN. Закрытая природа PW означает, что трассировочная информация доступна только в сети провайдера (например, на устройствах PE).

9. Согласование с IANA

Согласование с IANA потребуется для документов PWE3, которые определяют протоколы инкапсуляции, управления и контроля PWE3.

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

PWE3 не обеспечивает средств защиты целостности и конфиденциальности, а также не гарантирует доставку блоков данных естественного сервиса. Использование PWE3 может, следовательно, подвергать конкретную среду риску угроз безопасности. Допущения, сделанные для случаев, когда все взаимодействующие системы соединены каналами «точка-точка» или через сеть с коммутацией каналов, не могут применяться при соединении устройств эмулируемыми псевдопроводами через некоторые типы PSN. Полный анализ и обзор рисков, связанных с использованием PWE3, выходит за рамки этого документа, особенно в тех аспектах, которые зависят от PSN. Для большей ясности приведем пример. Многие стандарты IETF обеспечивают сравнительно слабые механизмы защиты в предположении, что взаимодействующие узлы соединены между собой через одну локальную сеть. Одним из примеров может служить протокол VRRP14 [RFC3768]. Сравнительно слабые механизмы защиты представляют более серьезные уязвимости в эмулируемой среде Ethernet, использующей PW-соединения.

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

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

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

Базируясь на типе передаваемых данных, PW может указывать уровню демультиплексирования PW требуемые функции защиты. Уровень демультиплексирования PW может определить множество профилей защиты на основе требования эмулируемого сервиса. Сигнализация между устройствами CE и управляющие события, эмулируемые PW, а также некоторые типы данных могут потребовать дополнительной защиты. В дополнение к сказанному уровень демультиплексирования PW может использовать аутентификацию партнера для каждого пакета PSN, чтобы предотвратить подмену естественных блоков данных, передаваемых CE-адресату.

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

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

Мы благодарим Sasha Vainshtein за работу над NSP и советы в части передачи битовых потоков через PW и Thomas K. Johnson за работу по основам и мотивации PW.

Мы также благодарим Ron Bonica, Stephen Casner, Durai Chinnaiah, Jayakumar Jayakumar, Ghassem Koleyni, Danny McPherson, Eric Rosen, John Rutemiller, Scott Wainner и David Zelig за их комментарии и вклад в работу.

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

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

[RFC3931] Lau, J., Townsley, M., and I. Goyret, «Layer Two Tunneling Protocol — Version 3 (L2TPv3), RFC 393115, March 2005.

[RFC768] Postel, J., «User Datagram Protocol», STD 6, RFC 768, August 1980.

[RFC2401] Kent, S. and R. Atkinson, «Security Architecture for the Internet Protocol», RFC 240117, November 1998.

[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, December 1998.

[RFC3592] Tesink, K., «Definitions of Managed Objects for the Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Type», RFC 3592, September 2003.

[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, «Layer Two Tunneling Protocol «L2TP»», RFC 2661, August 1999.

[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, «Generic Routing Encapsulation (GRE)», RFC 2784, March 2000.

[RFC2890] Dommety, G., «Key and Sequence Number Extensions to GRE», RFC 2890, September 2000.

[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, «MPLS Label Stack Encoding», RFC 3032, January 2001.

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, «RTP: A Transport Protocol for Real-Time Applications», STD 64, RFC 355019, July 2003.

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

[DVB] EN 300 744 Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation for digital terrestrial television (DVB-T), European Telecommunications Standards Institute (ETSI).

[RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, «Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)», RFC 3815, June 2004.

[RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, «Multiprotocol Label Switching (MPLS) Label Switching Router (LSR) Management Information Base (MIB)», RFC 3813, June 2004.

[MPLSIP] Rosen et al, «Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)», Work in Progress20, March 2004.

[RFC1191] Mogul, J. and S. Deering, «Path MTU discovery», RFC 1191, November 1990.

[RFC1958] Carpenter, B., «Architectural Principles of the Internet», RFC 195822, June 1996.

[RFC1981] McCann, J., Deering, S., and J. Mogul, «Path MTU Discovery for IP version 6», RFC 1981, August 1996.

[RFC2022] Armitage, G., «Support for Multicast over UNI 3.0/3.1 based ATM Networks», RFC 2022, November 1996.

[RFC3768] Hinden, R., «Virtual Router Redundancy Protocol (VRRP)», RFC 376823, April 2004.

[RFC3022] Srisuresh, P. and K. Egevang, «Traditional IP Network Address Translator (Traditional NAT)», RFC 3022, January 2001.

[RFC3448] Handley, M., Floyd, S., Padhye, J., and J. Widmer, «TCP Friendly Rate Control (TFRC): Protocol Specification», RFC 3448, January 2003.

[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, «Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)», RFC 3812, June 2004.

[RFC3916] Xiao, X., McPherson, D., and P. Pate, Eds, «Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)», RFC 39162, September 2004.

13. Соавторы

Ниже перечислены соавторы этого документа.

Thomas K. Johnson

Litchfield Communications

Kireeti Kompella

Juniper Networks, Inc.

Andrew G. Malis

Tellabs

Thomas D. Nadeau

Cisco Systems

Tricci So

Caspian Networks

W. Mark Townsley

Cisco Systems

Craig White

Level 3 Communications, LLC.

Lloyd Wood

Cisco Systems

14. Адреса редакторов

Stewart Bryant

Cisco Systems

250, Longwater

Green Park

Reading, RG2 6GB,

United Kingdom

EMail: stbryant@cisco.com

Prayson Pate

Overture Networks, Inc.

507 Airport Boulevard

Morrisville, NC, USA 27560

EMail: prayson.pate@overturenetworks.com


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

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

nmalykh@gmail.com

Полное заявление авторских прав

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1Pseudo Wire Emulation Edge-to-Edge.

2Pseudo Wire Emulation Edge-to-Edge.

3Packet Switched Network.

4Pseudo Wire.

5Native Service Processing

6Customer Edge Equipment

7Data-Link Connection Identifier – идентификатор соединения на канальном уровне.

8Native Service Processor.

9Quality of Service – качество обслуживания.

10В оригинале — timed payload delivery. Прим. перев.

11Номер версии протокола IP. Прим. перев.

12Service-level greements – соглашение об уровне обслуживания.

13Traffic-Engineered.

14Virtual Router Redundancy Protocol — протокол резервирования виртуальных маршрутизаторов.

15Этот документ частично обновлен в RFC 5641. Прим. перев.

17Этот документ заменен RFC 4301. Прим. перев.

18Этот документ частично обновлен в RFC 3260. Прим. перев.

19Этот документ частично обновлен в RFC 5506. Прим. перев.

20К настоящему времени эта работа завершена и опубликована в RFC 4023, который обновлен в RFC 5332. Прим. перев.

22Этот документ частично обновлен в RFC 3439. Прим. перев.

23Этот документ заменен RFC 5798. Прим. перев.

24Этот документ заменен RFC 5348. Прим. перев.




RFC 4035 Protocol Modifications for the DNS Security Extensions

Network Working Group                                          R. Arends
Request for Comments: 4035                          Telematica Instituut
Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658,                R. Austein
           3755, 3757, 3845                                          ISC
Updates1: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
         3597, 3226                                             VeriSign
Category: Standards Track                                      D. Massey
                                               Colorado State University
                                                                 S. Rose
                                                                    NIST
                                                              March 2005

 

Изменение протокола для защитных расширений DNS

Protocol Modifications for the DNS Security Extensions

PDF

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

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

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

Copyright (C) The Internet Society (2005).

Тезисы

Этот документ является частью набора документов, описывающих расширения DNS Security (DNSSEC). Эти расширения представляют собой набор новых записей RR и изменений протокола, обеспечивающих совместно аутентификацию источника данных и целостность данных DNS. В данном документе описаны изменения протокола, вносимые DNSSEC. Документ определяет концепцию подписанной зоны и требования к использованию DNSSEC. Описываемые здесь методы позволяют защищенному распознавателю2 аутентифицировать как записи DNS RR, так и уполномоченную индикацию ошибок DNS.

Данный документ отменяет действие RFC 2535 и включает в себя все обновления к RFC 2535.

Оглавление

Исключено в версии HTML.

1. Введение

Защитные расширения DNS (DNSSEC) представляют собой набор новых записей и изменений в протоколе, которые добавляют аутентификацию источника данных и поддержку целостности данных DNS. В этом документе рассматриваются изменения протокола, вносимые DNSSEC. Глава 2 определяет концепцию подписанной зоны и список требований для этого. В главе 3 описываются изменения в поведении уполномоченных серверов имен, требуемые для работы с подписанными зонами. В главе 4 описано поведение объектов, включающих функции защищенного распознавателя. В главе 5 определено использование записей DNSSEC RR для аутентификации откликов.

1.1. Связанные документы

Этот документ является частью семейства документов, определяющих расширения DNSSEC. Документы следует читать как единое целое.

[RFC4033] содержит введение в DNSSEC и определения основных терминов; предполагается, что читатель внимательно ознакомился с этим документом. [RFC4033] также включает список документов, обновленных или отмененных данным набором документов.

[RFC4034] определяет записи DNSSEC RR.

Предполагается, что читатель знаком с основными концепциями DNS, описанными в [RFC1034], [RFC1035] и последующих документах, обновляющих два указанных документа (в частности, [RFC2181] и [RFC2308]).

Данный документ определяет работу протокола DNSSEC.

1.2. Зарезервированные слова

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

2. Подписывание зоны

DNSSEC вводит концепцию подписанной зоны. Подписанная зона включает открытый ключ DNS (DNSKEY), сигнатуру RR (RRSIG3), записи NSEC4 и (не обязательно) DS5, как указывают правила в параграфах 2.1, 2.2, 2.3 и 2.4, соответственно. Зона, не включающая записи в соответствии с указанными правилами, является не подписанной.

DNSSEC требует замены определения записи CNAME ([RFC1035]). Параграф 2.5 меняет CNAME RR, чтобы записи RRSIG и NSEC появлялись с тем же именем владельца, которое указано в CNAME RR.

DNSSEC задает положение двух новых типов RR — NSEC и DS, — которые могут размещаться на родительской стороне среза зоны (т. е., в точке передачи полномочий). Это является исключением из общего правила, запрещающего включение данных в родительскую зону на срезе зоны. Это изменение описано в параграфе 2.6.

2.1. Включение в зону записей DNSKEY RR

Для подписывания зоны ее администратор генерирует по крайней мере одну пару ключей (закрытый и открытый) и использует закрытый ключ или ключи для подписывания полномочных наборов RRset в зоне. Для каждого закрытого ключа, использованного при создании записи RRSIG RR в зоне, в эту зону следует включать запись DNSKEY RR, содержащую соответствующий открытый ключ. Запись DNSKEY RR для ключа зоны должна иметь установленный бит Zone Key в поле флагов RDATA (см. параграф 2.1.1 документа [RFC4034]). Открытые ключи, связанные с другими операциями DNS, могут сохраняться в записях DNSKEY RR, которые не помечаются как ключи зоны, но такие записи недопустимо использовать для проверки RRSIG.

Если администратор зоны разрешает использование подписанной зоны, отличающееся от островка безопасности, вершина зоны должна содержать по крайней мере одну запись DNSKEY RR, используемую в качестве защищенной точки входа в зону. Эта защищенная точка входа используется как назначение защищенной передачи полномочий через соответствующую запись DS RR в родительской зоне (см. [RFC4034]).

2.2. Включение в зону записей RRSIG RR

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

  • Имя владельца RRSIG совпадает с именем владельца.

  • Класс RRSIG совпадает с классом RRset.

  • Поле RRSIG Type Covered совпадает с типом RRset.

  • Поле RRSIG Original TTL совпадает со значением TTL для RRset.

  • Значение TTL для RRSIG RR совпадает со значением TTL для RRset.

  • Поле RRSIG Labels совпадает с числом меток в имени владельца RRset, без учета пустой (null) корневой метки и без учета самой левой метки, если та является шаблоном.

  • Поле RRSIG Signer’s Name совпадает с именем зоны, содержащей RRset.

  • Поля RRSIG Algorithm, Signer’s Name и Key Tag идентичны записи DNSKEY для ключа зоны на срезе последней.

Процесс создания RRSIG RR для данного набора RRset описан в [RFC4034]. Набор RRset может включать множество связанных с ним записей RRSIG. Отметим, что по причине тесной связи записей RRSIG RR с наборами RRset, чьи сигнатуры эти записи содержат, записи RRSIG RR, в отличие от других типов DNS RR, не формируют наборов RRset. В частности, значения TTL для записей RRSIG RR с общим именем владельца, не следуют правилам для RRset, описанным в [RFC2181].

Сами записи RRSIG RR недопустимо подписывать, поскольку подписывание RRSIG RR не имеет смысла, но создает бесконечный цикл в процессе подписывания.

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

Должна присутствовать запись RRSIG для каждого набора RRset, использующая по крайней мере один ключ DNSKEY для каждого алгоритма из набора DNSKEY RRset на вершине зоны. Сам набор DNSKEY на вершине зоны должен быть подписан с использованием каждого алгоритма, включенного в набор DS RRset, расположенный у передающего полномочия родителя (если таковой имеется).

2.3. Включение в зону записей NSEC RR

Каждое имя владельца в зоне, содержащей полномочные данные или набор NS RRset точки передачи полномочий, должно иметь запись NSEC. Формат NSEC RR и процесс создания таких записей для данного имени описан в [RFC4034].

Значение TTL для любой записи NSEC RR следует устанавливать таким же, как указано в поле минимального значения TTL записи SOA RR для зоны.

Записи NSEC (и связанному с ней набору RRSIG RRset) недопустимо быть единственным набором RRset для любого конкретного имени владельца. Т. е., в процессе подписывания недопустимо создавать NSEC или RRSIG RR для узлов имени владельца, которые не являются именами владельца какого-либо набора RRset до подписания зоны. Основная причина этого заключается в обеспечении согласованности пространства имен между подписанной и не подписанной версиями одной зоны и снижения риска несогласованности откликов в обычных (не защищенных) рекурсивных серверах имен.

Битовая последовательность типа каждой записи NSEC в подписанной зоне должна показывать наличие самой записи NSEC и соответствующей записи RRSIG.

Различие между наборами имен владельцев, требующими записи RRSIG, и наборами имен владельцев, требующими записи NSEC, трудно уловимо и слабо разъяснено. Записи RRSIG используются с именами владельцев всех полномочных наборов RRset. Записи NSEC используются с именами владельцев всех имен, для которых полномочна подписанная зона, а также с именами владельцев при передаче полномочий из подписанной зоны в дочерние зоны. Ни одна из записей NSEC и RRSIG не используется (в родительской зоне) для имен владельцев наборов RRset склеивающего адреса. Отметим, однако, что упомянутое различие для большинства случаев видимо только в процессе подписывания зоны, поскольку наборы NSEC RRset являются полномочными данными и должны подписываться. Таким образом, любое имя владельца, имеющее набор NSEC RRset в подписанной зоне, будет иметь записи RRSIG RR.

Битовая последовательность для NSEC RR в точке передачи полномочий требует особого внимания. Биты, соответствующие делегируемому набору NS RRset и любым наборам RRset, для которых родительская зона имеет полномочные данные, должны быть установлены; биты, соответствующие любым наборам, не относящимся к числу NS RRset должны быть сброшены, если родительская зона не содержит для этих наборов полномочные данные.

2.4. Включение в зону записей DS RR

Запись DS создает цепочку аутентификации между зонами DNS. Набор DS RRset следует включать в точке передачи полномочий, если дочерняя зона подписывается. Набор DS RRset может включать множество записей, каждой из которых соответствует открытый ключ в дочерней зоне, используемый для проверки записей RRSIG в этой зоне. Все наборы DS RRset в зоне должны быть подписаны и недопустимо включать наборы DS RRset на вершине зоны.

Записи DS RR следует указывать на запись DNSKEY RR, присутствующую в наборе DNSKEY RRset на вершине дочерней зоны, а набор DNSKEY RRset на вершине дочерней зоны следует подписывать с использованием соответствующего закрытого ключа. Записи DS RR, которые не соответствуют этим условиям, бесполезны при проверке корректности, но, поскольку записи DS RR и соответствующие им записи DNSKEY RR находятся в разных зонах, а согласованность DNS достаточно свободна, может возникать временное рассогласование.

Значению TTL в наборах DS RRset следует соответствовать значению TTL в делегирующем наборе NS RR (т. е., в наборе NS RRset из той же зоны, где содержится DS RRset).

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

2.5. Изменения в CNAME RR

Если для имени в подписанной зоне имеется набор CNAME RRset, для этого имени требуются соответствующие наборы RRSIG и NSEC RRset. В целях обеспечения защиты динамических обновлений для этого имени может также использоваться набор KEY RRset ([RFC3007]). Другие типы записей для этого имени недопустимы.

Сказанное выше отличается от исходного определения CNAME в [RFC1034], которое не позволяет другим типам существовать вместе с CNAME RR, но подписанная зона требует наличия записей NSEC и RRSIG RR для каждого полномочного имени. Для разрешения этого конфликта данная спецификация меняет определение записи CNAME, разрешая сосуществование записей CNAME с записями NSEC и RRSIG.

2.6. Типы DNSSEC RR, появляющиеся на срезах зон

DNSSEC вводит два новых типа RR, которые являются не совсем обычными в том, что они могут присутствовать на родительской стороне среза зоны. На родительской стороне среза зоны (т. е., в точке передачи полномочий) для имени владельца требуется включать записи RR. На срезе может также присутствовать запись DS RR, если делегируемая зона подписывается и имеет цепочку аутентификации в родительскую зону. Это отличается от исходной спецификации DNS ([RFC1034]), в которой сказано, что на родительской стороне среза зоны могут присутствовать лишь наборы NS RRset.

Данная спецификация обновляет исходную спецификацию DNS, разрешая включать записи типов NSEC и DS на родительской стороне среза зон. Эти наборы являются полномочными для родительской зоны при их включении на родительской стороне среза.

2.7. Пример защищенной зоны

Полный пример небольшой подписанной зоны содержится в Приложении A.

3. Работа сервера

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

Термины SNAME, SCLASS и STYPE при обсуждении используются так же, как в [RFC1034].

Защищенный сервер имен должен поддерживать расширение размера сообщений EDNS0 ([RFC2671]), должен поддерживать сообщения размером по крайней мере 1220 октетов (следует также поддерживать сообщения размером 4000 октетов). Поскольку пакеты IPv6 могут фрагментироваться только исходным отправителем, защищенному серверу имен следует принять меры, чтобы дейтаграммы UDP, передаваемые по протоколу IPv6, были при необходимости фрагментированы до минимального значения IPv6 MTU, если не известно значение MTU для пути. Вопросы фрагментирования и размера пакетов подробно обсуждаются в документах [RFC1122], [RFC2460] и [RFC3226].

Защищенный сервер имен при получении запроса DNS, не включающего псевдозапись EDNS OPT, или имеющего сброшенный бит DO, должен трактовать записи RRSIG, DNSKEY и NSEC, как обычные наборы RRset и недопустимо выполнять для этих записей какие-либо дополнительные операции, описанные ниже. Поскольку тип DS RR имеет особое свойство быть единственным в точке делегирования в родительской зоне, записи DS RR всегда требуют специальной обработки, описанной в параграфе 3.1.4.1.

Защищенному серверу имен при получении явных запросов на связанные с защитой типы RR, которые соответствуют содержимому нескольких обслуживаемых сервером зон (например, записи NSEC и RRSIG ниже и выше точки делегирования, когда сервер является полномочным для обеих зон), следует обеспечивать самосогласованность. Поскольку отклик для каждого запроса всегда согласован, сервер имен может возвратить один из перечисленных вариантов отклика:

  • наборы RRset выше точки делегирования;

  • наборы RRset ниже точки делегирования;

  • наборы RRset выше и ниже точки делегирования;

  • пустой раздел answer (нет записей);

  • какой-либо иной отклик;

  • сообщение об ошибке.

DNSSEC выделяет два новых бита в заголовке сообщений DNS — CD6 (проверка отключена) и AD7 (аутентичные данные). Бит CD контролируется распознавателями – защищенный сервер имен должен копировать этот бит из запроса в соответствующий отклик. Бит AD контролируется серверами имен – защищенный сервер должен игнорировать значение этого бита в полученных запросах. Более детальное описание использования этих битов приведено в параграфах 3.1.6, 3.2.2, 3.2.3, 4 и 4.9.

Защищенным серверам имен, которые создают записи CNAME RR из DNAME RR, как описано в [RFC2672], не следует генерировать подписи для синтезированных CNAME RR.

3.1. Полномочные серверы имен

При получении имеющего отношение к делу запроса с установленным битом DO псевдозаписи EDNS ([RFC2671]), защищенный полномочный сервер имен для подписанной зоны должен включить дополнительные записи RRSIG, NSEC и DS, в соответствии с приведенными ниже правилами:

  • запись RRSIG RR, которая может использоваться для аутентификации отклика, должна включаться в отклик в соответствии с правилами параграфа 3.1.1;

  • запись NSEC RR, которая может использоваться для аутентифицированного отказа, должна включаться в отклик в соответствии с правилами параграфа 3.1.3;

  • набор DS RRset или запись NSEC RR, говорящая об отсутствии DS RR, должна включаться автоматически в соответствии с правилами параграфа 3.1.4.

Эти правила применимы только к откликам, семантика которых передает информацию о наличии или отсутствии записей RR. Т. е., эти правила не используются при генерации откликов типа RCODE 4 (Not Implemented8) или RCODE 5 (Refused9).

DNSSEC не меняет протокол переноса зон DNS. В параграфе 3.1.5 обсуждаются требования к переносу зон.

3.1.1. Включение записей RRSIG RR в отклик

При ответе на запрос, содержащий бит DO, защищенному полномочному серверу имен следует пытаться передать записи RRSIG RR, которые защищенный распознаватель может использовать для аутентификации наборов RRset в отклике. Серверу имен следует каждый раз пытаться сохранить в отклике RRset и связанные с ним записи RRSIG вместе. Включение в отклик записей RRSIG RR выполняется по приведенным ниже правилам:

  • При включении подписанного набора RRset в раздел Answer сервер имен должен также включить соответствующие записи RRSIG RR в раздел Answer. Записи RRSIG RR имеют при включении более высокий приоритет, нежели прочие наборы RRset, которые также могут включаться в отклик. Если свободное пространство не позволяет включить записи RRSIG RR, сервер имен должен установить бит TC.

  • При включении подписанного набора RRset в раздел Authority сервер имен должен также включить соответствующие записи RRSIG RR в раздел Authority. Записи RRSIG RR имеют при включении более высокий приоритет, нежели прочие наборы RRset, которые также могут включаться в отклик. Если свободное пространство не позволяет включить записи RRSIG RR, сервер имен должен установить бит TC.

  • При включении подписанного набора RRset в раздел Additional сервер имен должен также включить соответствующие записи RRSIG RR в раздел Additional. Если свободное пространство не позволяет включить RRset и связанные с ним записи RRSIG RR, сервер имен может сохранить RRset, отбрасывая записи RRSIG RR. В таких случаях для сервера недопустимо устанавливать бит TC на основании лишь того, что записи RRSIG RR не поместились в отклик.

3.1.2. Включение записей DNSKEY RR в отклик

При отклики на запросы с установленным битом DO, запрашивающие записи SOA или NS на вершине подписанной зоны, защищенный полномочный сервер имен для этой зоны может возвращать расположенный на вершине зоны набор DNSKEY RRset в разделе Additional. В такой ситуации DNSKEY RRset и связанные с ним записи RRSIG RR имеют более низкий приоритет, нежели прочие данные, которые могут быть включены в раздел Additional. Серверу имен не следует включать набор DNSKEY RRset, если в сообщении недостаточно места для одновременного включения связанных с набором записей RRSIG RR. Если свободного пространства недостаточно для включения DNSKEY и записей RRSIG RR, сервер должен опустить их; недопустимо устанавливать бит TC лишь на том основании, что записи не помещаются в сообщение (см. параграф 3.1.1).

3.1.3. Включение записей NSEC RR в отклик

При ответе на запрос с установленным битом DO защищенный полномочный сервер имен для подписанной зоны должен включать записи NSEC RR в каждом из перечисленных случаев:

No Data — зона содержит наборы RRset, которые точно соответствуют <SNAME, SCLASS>, но не содержит ни одного набора, в точности соответствующего <SNAME, SCLASS, STYPE>.

Name Error — зона не содержит наборов, соответствующих <SNAME, SCLASS> в точности или с использованием шаблона.

Wildcard Answer — зона не содержит ни одного RRset, в точности соответствующего <SNAME, SCLASS>, но содержит RRset, соответствующий <SNAME, SCLASS, STYPE> с использованием шаблона.

Wildcard No Data — зона не содержит ни одного набора RRset, который точно соответствует <SNAME, SCLASS> и содержит один или несколько наборов RRset, соответствующих <SNAME, SCLASS> с использованием шаблона, но не содержит ни одного набора RRset, соответствующего <SNAME, SCLASS, STYPE> с использованием шаблона.

В каждом из этих случаев сервер имен включает в отклик записи NSEC RR, чтобы показать отсутствие в зоне точного соответствия для <SNAME, SCLASS, STYPE> и указать, что сервер имен возвращает корректные данные для зоны.

3.1.3.1. Включение записей NSEC RR отклик No Data

Если зона содержит наборы RRset, соответствующие <SNAME, SCLASS>, но не содержит RRset, соответствующих <SNAME, SCLASS, STYPE>, сервер имен должен включить NSEC RR для <SNAME, SCLASS> вместе со связанными записями RRSIG RR в раздел отклика Authority (см. параграф 3.1.1). Если свободное пространство не позволяет включить запись NSEC RR или связанные с ней записи RRSIG RR, сервер имен должен установить бит TC (см. параграф 3.1.1).

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

3.1.3.2. Включение записей NSEC RR отклик Name Error

Если зона не содержит наборов RRset, соответствующих <SNAME, SCLASS> в точности или с использованием шаблона, сервер имен должен включить в раздел Authority перечисленные ниже записи NSEC RR вместе с соответствующими RRSIG RR:

  • запись NSEC RR, показывающая отсутствие точного соответствия <SNAME, SCLASS>;

  • запись NSEC RR, показывающая отсутствие в зоне наборов RRset, соответствующих <SNAME, SCLASS> с использованием шаблона.

В некоторых случаях достаточно бывает одной записи NSEC RR для обоих вариантов отсутствия. Тогда серверу имен следует включать в раздел Authority одну запись RR и связанные с ней RRSIG RR.

Если свободное пространство не позволяет включить записи NSEC и RRSIG, сервер имен должен установить бит TC (см. параграф 3.1.1).

Для имен владельцев в записях NSEC и RRSIG не используются шаблоны при включении таких RR в раздел Authority.

Отметим, что эта форма отклика включает ситуации, когда SNAME соответствует пустому нетерминальному имени в зоне (имя, которое не является именем владельца какого-либо набора RRset, но является родительским именем для одного или нескольких наборов RRset).

3.1.3.3. Включение записей NSEC RR отклик Wildcard Answer

Если зона не содержит наборов RRset, в точности соответствующих <SNAME, SCLASS>, но содержит RRset, соответствующий <SNAME, SCLASS, STYPE> с использованием шаблона, сервер имен должен включить полученный с использованием шаблона ответ и соответствующие записи RRSIG RR в раздел Answer, а также должен включить в раздел Authority запись NSEC RR и связанные с ней записи RRSIG RR, показывающие, что зона не содержит более точного соответствия <SNAME, SCLASS>. Если свободное пространство не позволяет включить записи NSEC и RRSIG RR, сервер имен должен установить бит TC (см. параграф 3.1.1).

3.1.3.4. Включение записей NSEC RR отклик Wildcard No Data

Этот случай представляет собой комбинацию предыдущих. Зона не содержит имени, в точности соответствующего <SNAME, SCLASS>, и, хотя зона содержит наборы RRset, которые соответствуют <SNAME, SCLASS> с использованием шаблона, ни один из этих наборов не соответствует STYPE. Сервер имен должен включить в раздел Authority перечисленные ниже записи NSEC RR с соответствующими записями RRSIG RR:

  • Запись NSEC RR, показывающую отсутствие наборов RRset, соответствующих STYPE с шаблоном имени владельца, которое соответствует <SNAME, SCLASS> при использовании шаблона.

  • Запись NSEC RR, показывающую отсутствие в зоне наборов RRset, более точно соответствующих <SNAME, SCLASS>.

В некоторых случаях достаточно бывает одной записи NSEC RR для обоих вариантов отсутствия. Тогда серверу имен следует включать в раздел Authority одну запись RR и связанные с ней RRSIG RR.

К именам владельцев в записях NSEC и RRSIG не применяются шаблоны, когда эти записи включены в раздел отклика Authority.

Если свободное пространство не позволяет включить записи NSEC и RRSIG, сервер имен должен установить бит TC (см. параграф 3.1.1).

3.1.3.5. Поиск правильных записей NSEC RR

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

Чтобы найти запись NSEC, говорящую об отсутствии наборов RRset, соответствующих имени N в зоне Z, создается последовательность S, содержащая имена владельцев каждого набора RRset в Z, отсортированные в каноническом порядке ([RFC4034]) без дубликатов. Далее в списке находится имя M, которое непосредственно предшествовало бы N, если бы это имя содержалось в S. M будет именем владельца записи NSEC RR, которая подтверждает отсутствие наборов RRset с именем владельца N.

Алгоритм поиска записи NSEC RR, показывающей отсутствие соответствия заданному имени при использовании шаблона, похож на описанный, но требует выполнения дополнительного шага. Более точно, алгоритм поиска NSEC, обеспечивающий информацию об отсутствии RRset с совпадающим в точности именем шаблона, совпадает с алгоритмом поиска NSEC RR, который говорит об отсутствии RRset с любым другим именем владельца. Сообщающая об отсутствии часть представляет собой метод определения имени применимого несуществующего шаблона. На практике это просто, поскольку полномочный сервер имен уже проверен на предмет наличия в точности такого имени шаблона на этапе (1)(c) обычного алгоритма поиска, описанного в параграфе 4.3.2 документа [RFC1034].

3.1.4. Включение в отклик записей DS RR

При откликах на запросы с установленным битом DO защищенный полномочный сервер имен, возвращающий информацию, включает данные DNSSEC вместе с набором NS RRset.

Если в точке передачи полномочий присутствует DS RRset, сервер имен должен должен возвратить как DS RRset, так и связанные с ним записи (запись) RRSIG RR в разделе Authority вместе с NS RRset.

Если в точке делегирования нет DS RRset, сервер имен должен возвратить запись NSEC RR, говорящую об отсутствии DS RRset, и связанные с NSEC RR записи (запись) RR вместе с NS RRset. Сервер имен должен разместить NS RRset до NSEC RRset и связанных с этим набором записей (записи) RRSIG RR.

Включение записей DS, NSEC и RRSIG увеличивает размер referral-сообщений и может приводит к опусканию некоторых или всех склеивающих записей. Если свободное пространство не позволяет включить DS или NSEC RRset и связанные записи RRSIG RR, сервер имен должен установить бит TC (см. параграф 3.1.1).

3.1.4.1. Отклики на запросы записей DS RR

Записи DS необычны в том смысле, что они появляются только на родительской стороне среза зон. Например, DS RRset для делегирования foo.example сохраняется в зоне example, а не в зоне foo.example. Это требует использования специальных правил обработки как на серверах, так и на распознавателях, поскольку сервер имен для дочерней зоны является полномочным для имени на срезе зоны в соответствии с обычными правилами DNS, но дочерняя зона не содержит DS RRset.

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

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

  • сервер имен получил запрос для DS RRset на срезе зоны;

  • сервер имен является полномочным для дочерней зоны;

  • сервер имен не является полномочным для родительской зоны;

  • сервер имен не предлагает рекурсии.

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

Если все указанные выше условия выполняются, однако сервер имен уполномочен для SNAME, но не поддерживает запрошенный RRset, этот сервер имен должен возвращать полномочный отклик no data, показывающий, что DS RRset не существует на вершине дочерней зоны. Пример такого отклика представлен в Приложении B.8.

3.1.5. Отклики на запросы типа AXFR или IXFR

DNSSEC не меняет процесс переноса зон DNS. Подписанная зона будет включать записи RRSIG, DNSKEY, NSEC и DS, но эти записи не имеют какого-либо специального значения в контексте операций переноса зон.

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

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

Записи NSEC RR присутствуют на срезе зон как в родительской, так и в дочерней зоне и являются полномочными для обеих. Записи NSEC RR в родительской и дочерней зонах никогда не являются идентичными, поскольку NSEC RR на вершине дочерней зоны всегда указывает присутствие SOA RR дочерней зоны, тогда как родительская NSEC RR на срезе зоны никогда не указывает наличия SOA RR. Как и все прочие полномочные RR, записи NSEC RR должны включаться в перенос зон, для которых они служат полномочными данными. Родительская NSEC RR на срезе зоны должна включаться в перенос родительской зоны, а NSEC на вершине дочерней зоны должна включаться в перенос дочерней зоны.

Записи RRSIG RR присутствуют на срезе зон как в родительской, так и в дочерней зоне и являются полномочными для зон, содержащих полномочные RRset, для которых RRSIG RR обеспечивают подписи. Т. е., RRSIG RR для DS RRset или родительской NSEC RR на срезе зоны будет полномочной в родительской зоне, а RRSIG для любых RRset на вершине дочерней зоны будут полномочными для дочерней зоны. Родительские и дочерние записи RRSIG RR на срезе зоны никогда не являются идентичными, поскольку поле Signer’s Name в RRSIG RR на вершине дочерней зоны будет указывать DNSKEY RR на вершине дочерней зоны, тогда как аналогичное поле родительской RRSIG RR на срезе зоны будет указывать DNSKEY RR на вершине родительской зоны. Как и все прочие полномочные RR, записи RRSIG RR должны включаться в перенос зоны, для которой они являются полномочными.

3.1.6. Биты AD и CD в полномочных откликах

Флаги CD и AD предназначены для использования при взаимодействии защищенных распознавателей и рекурсивных серверов имен. Эти биты по большей части не имеют отношения к обработке запросов защищенными полномочными серверами имен.

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

Защищенному серверу имен недопустимо устанавливать бит AD в откликах, пока сервер не рассмотрит все RRset в разделах Answer и Authority на предмет аутентичности. Локальная политика таких серверов может считать данные из полномочной зоны аутентичными без дополнительной проверки. Однако серверам имен недопустимо такое поведение, если полномочная зона не была получена с использованием мер защиты (таких, как защищенный механизм переноса зон), а также недопустимо делать это без явного указания такого поведения в конфигурации.

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

3.2. Рекурсивные серверы имен

Как разъяснено в [RFC4033], защищенный сервер имен имеет элемент, действующий в ролях защищенного сервера имен и защищенного распознавателя. В этом параграфе термины «на стороне сервера имен» (name server side) и «на стороне распознавателя» (resolver side) относятся к коду защищенного сервера имен, который исполняет роль защищенного сервера и распознавателя, соответственно.

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

3.2.1. Бит DO

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

3.2.2. Бит CD

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

Сервер имен должен копировать бит CD из запроса в соответствующий отклик.

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

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

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

3.2.3. Бит AD

На стороне сервера имен защищенного рекурсивного сервера имен недопустимо устанавливать бит AD в отклике, пока сервер имен не считает все наборы RRset в разделах Answer и Authority подлинными. На серверной стороне следует устанавливать бит AD тогда и только тогда, когда на стороне распознавателя все RRset в разделе Answer и все имеющиеся RR с негативными откликами в разделе Authority признаны подлинными. На стороне распознавателя должна выполняться описанная в разделе 5 процедура для решения вопроса о подлинности рассматриваемых записей RR. Однако для совместимости со старыми версиями рекурсивный сервер имен может устанавливать бит AD, когда отклик включает неподписанные записи CNAME RR, если эти CNAME RR явно могут быть синтезированы из подлинной записи DNAME RR, которая также включена в отклик в соответствии с правилами синтеза, описанными в [RFC2672].

3.3. Примеры откликов DNSSEC

Примеры пакетов откликов приведены в Приложении B.

4. Преобразование имен

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

4.1. Поддержка EDNS

Защищенный распознаватель должен включать EDNS ([RFC2671]) OPT псевдо-RR с установленным при отправке отправке запросов битом DO ([RFC3225]).

Защищенный распознаватель должен поддерживать сообщения размером не менее 1220 октетов, следует также поддерживать сообщения размером до 4000 октетов, а также распознаватель должен использовать поле sender’s UDP payload size в EDNS OPT псевдо-RR для анонсирования размера сообщений, которые он будет принимать. Уровень IP защщенных распознавателей должен корректно обрабатывать фрагментированные пакеты UDP независимо от того, были такие фрагментированные пакеты получены по IPv4 или IPv6. Эти требования были рассмотрены в [RFC1122], [RFC2460] и [RFC3226].

4.2. Поддержка верификации подписей

Защищенный распознаватель должен поддерживать механизмы проверки подписей, описанные в разделе 5 и эти механизмы следует применять к каждому полученному отклику, за исключением перечисленных случаев:

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

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

  • проверка для данного запроса отключена в соответствии с локальной политикой.

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

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

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

При попытке отыскать отсутствующие записи DS защищенный итеративный распознаватель должен запрашивать серверы имен для родительской, а не дочерней зоны. Как разъяснено в параграфе 3.1.4.1, защищенные серверы имен должны применять специальные правила обработки DS RR и в некоторых ситуациях распознаватель также должен применять специальные правила, чтобы найти серверы имен для родительской зоны, если у распознавателя еще нет родительского NS RRset. Для нахождения родительского NS RRset распознаватель может начать с имени делегирования (delegation name), исключить из него левую метку и отправить запрос для NS RRset по этому имени. Если для этого имени не будет возвращен набор NS RRset, распознаватель вырезает еще одну метку слева и повторяет запрос. Описанная процедура повторяется до тех пор, пока не будет найден NS RRset или закончатся метки.

4.3. Определение статуса защиты данных

Защищенный распознаватель должен быть способен определить, следует ли ожидать наличия подписи для конкретного набора RRset. Точнее говоря, такой распознаватель должен различать перечисленные ниже случаи:

Защишенный (Secure) — RRset, для которого распознаватель способен построить цепочку подписанных записей DNSKEY и DS RR от даверенной защитной привязки (security anchor) до RRset. В этом случае набору RRset следует быть подписанным и для него выполняется проверка подписи, описанная выше.

Незащищенный (Insecure) — RRset, для которого распознаватель знает об отсутствии цепочки подписанных записей DNSKEY и DS RR от любой доверенной стартовой точки до RRset. Это может наблюдаться в тех случаях, когда целевой набор RRset находится в неподписанной зоне или потомке такой зоны. В этом случае набор RRset может быть как подписанным, так и неподписанным и распознаватель не сможет проверить подпись.

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

Неопределенность (Indeterminate) — RRset, для которого распознаватель не может определить необходимость наличия подписи по причине невозможности получить требуемые записи DNSSEC RR. Это может происходить в тех случаях, когда распознаватель не может контактировать с осведомленными о защите серверами имен для соответствующих зон.

4.4. Заданные в конфигурации доверенные привязки

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

Отметим, что доверенные привязки покрывают также ключевой материал, обновляемый защищенным путем, который может включать ту или иную физическую среду, протокол обмена ключами или иные способы обмена по отдельному каналу (out-of-band).

4.5. Кэширование откликов

Защищенному распознавателю следует кэшировать каждый отклик, как неделимый элемент, содержащий целиком ответ, включая именованный набор RRset и все связанные с ним записи DNSSEC RR. По истечении срока действия записи распознавателю следует отбрасывать ее целиком. В большинстве случаев подходящим индексом для таких записей в кэше будет служить тройка <QNAME, QTYPE, QCLASS>, но для откликов, описанных в параграфе 3.1.3.2, подходящим индексом будет служить пара <QNAME,QCLASS>.

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

Описанное выше имеет отношение к двум ситуациям.

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

  2. Записи NSEC RR с подтверждением отсутствия имени, могут повторно использоваться защищенным распознавателем для подтверждения отсутствия любого имени в охватываемом записью диапазоне.

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

4.6. Обработка битов CD и AD

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

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

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

4.7. Кэширование неприемлемых данных

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

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

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

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

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

  • для предотвращения кэширования временных отказов при проверке (они могут быть результатом атаки) распознавателям следует отслеживать запросы, приводящие к отказам при проверке и отклики из BAD-кэша следует возвращать только при достижении определенного числа откликов на запросы, не прошедших проверку, для конкретного набора <QNAME, QTYPE, QCLASS>.

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

4.8. Синтезированные записи CNAME

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

4.9. Оконечные распознаватели

Защищенный оконечный распознаватель должен поддерживать типы DNSSEC RR, по крайней мере не отвергая отклики лишь на основании наличия записей DNSSEC RR.

4.9.1. Обработка бита DO

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

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

4.9.2. Обработка бита CD

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

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

4.9.3. Обработка бита AD

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

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

5. Аутентификация откликов DNS

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

Исходную запись DNSKEY RR можно использовать для аутентификации набора DNSKEY RRset на вершине зоны. Для идентификации DNSKEY RRset на вершине зоны с использованием начального ключа распознаватель должен:

  1. убедиться в том, что исходная запись DNSKEY RR присутствует на вершине appears DNSKEY RRset и для этой записи DNSKEY RR установлен флаг Zone Key (бит 7 в DNSKEY RDATA bit 7);

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

После того, как распознаватель подтвердил подлинность набора DNSKEY RRset на вершине зоны, используя начальную запись DNSKEY RR, делегирования из этой зоны можно аутентифицировать с использованием записей DS RR. Это позволяет распознавателю начать со стартового ключа и использовать наборы DS RRset для рекурсивного перемещения по дереву DNS вниз, получая наборы DNSKEY RRset на других вершинах. Если в конфигурации распознавателя задана корневая запись DNSKEY RR и каждое делегирование имеет связанную с ним запись DS RR, этот распознаватель может получить и проверить набор DNSKEY RRset на любой вершине. Процесс использования записей DS RR для аутентификации отсылок описан в параграфе 5.2.

В параграфе 5.3 показано, как распознаватель может использовать записи DNSKEY RR на вершине DNSKEY RRset и записи RRSIG RR из зоны для аутентификации любых других наборов RRset в зоне, если он имеет аутентифицированный набор DNSKEY RRset для вершины зоны. В параграфе 5.4 показан, как распознаватель может использовать аутентифицированные наборы NSEC RRset из зоны для подтверждения отсутствия RRset в зоне.

Когда распознаватель указывает поддержку DNSSEC (устанавливая флаг DO), защищенному серверу имен следует предпринять попытку обеспечить в отклике требуемые DNSKEY, RRSIG, NSEC и DS RRset (см. раздел 3). Однако защищенный распознаватель может продолжать получать отклики без соответствующих DNSSEC RR в результате конфигурационных проблем типа восходящего рекурсивного сервера имен, игнорирующего защиту, который непреднамеренно конфликтует с записями DNSSEC RR, или в результате преднамеренной атаки, когда злоумышленники будут вырезать записи DNSSEC RR из откликов или менять запрос таким образом, чтобы записи DNSSEC RR представлялись не запрошенными. Отсутствие данных DNSSEC в отклике, само по себе, недопустимо трактовать, как индикацию отсутствия аутентификационной информации.

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

5.1. Островки безопасности

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

К островкам безопасности применимы все обычные процессы проверки откликов. Единственным отличием является способ получения проверяющим доверенной привязки для цепочки аутентификации.

5.2. Аутентификация отсылок

После аутентификации вершины DNSKEY RRset для подписанной родительской зоны наборы DS RRset могут применяться для аутентификации делегирования подписанной дочерней зоны. Запись DS RR идентифицирует DNSKEY RR в наборе DNSKEY RRset на вершине дочерней зоны и содержит криптографический отпечаток записи DNSKEY RR дочерней зоны. Использование строгого криптографического алгоритма для создания отпечатков гарантирует невозможность расчетным путем создать злоумышленнику запись DNSKEY RR, соответствующую отпечатку. Таким образом, аутентификационный отпечаток позволяет распознавателю проверит подлинность DNSKEY RR. После этого распознаватель может применять эту дочернюю DNSKEY RR для аутентификации всего набора DNSKEY RRset вершины дочерней зоны.

На основе DS RR для делегирования набор DNSKEY RRset на вершине дочерней зоны может считаться подлинным, если выполняются все перечисленные ниже условия.

  • Запись DS RR была аутентифицирована с использованием той или иной записи DNSKEY RR из набора DNSKEY RRset на вершине родительской зоны (см. параграф 5.3).

  • Поля Algorithm и Key Tag в записи DS RR соответствуют аналогичным полям в записи DNSKEY RR из набора DNSKEY RRset на вершине дочерней зоны и при хэшировании имени владельца DNSKEY RR и RDATA с использованием алгоритма, указанного в поле Digest Type записи DS RR, результирующий отпечаток соответствует полю Digest в записи DS RR.

  • Соответствующая запись DNSKEY RR в дочерней зоне имеет установленный бит Zone, соответствующий секретный ключ имеет подписанный набор DNSKEY RRset вершины дочерней зоны и результирующая запись RRSIG RR аутентифицирует набор DNSKEY RRset на вершине дочерней зоны.

Если отсылка из родительской зоны не содержит DS RRset, отклику следует включать подписанный набор NSEC RRset, подтверждающий наличие DS RRset для делегированного имени (см. параграф 3.1.4).Защищенный распознаватель должен запрашивать серверы имен для родительской зоны набора DS RRset, если отсылка не включает ни DS RRset, ни NSEC RRset, подтверждающий существование DS RRset (см. раздел 4).

Если проверяющий аутентифицирует набор NSEC RRset, который подтверждает отсутствие DS RRset для этой зоны, это говорит об отсутствии пути аутентификации от родителя к потомку. Если у распознавателя имеется начальная запись DNSKEY или DS RR, относящаяся к дочерней зоне или любой точке делегирования ниже дочерней зоны, такая запись DNSKEY или DS RR может быть использована для организации аутентификационного пути. Если такой записи нет, проверяющий не сможет аутентифицировать наборы RRset в дочерней зоне и ниже ее.

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

Отметим, что для подписанного делегирования имеются две записи NSEC RR, связанные с именем делегирования. Одна NSEC RR размещается в родительской зоне и может использоваться для проверки наличия набора DS RRset для делегированного имени. Вторая запись NSEC RR размещается в дочерней зоне и указывает какие наборы RRset присутствуют на вершине этой зоны. Родительская и дочерняя записи NSEC RR в любом случае могут различаться, поскольку бит SOA будет установлен для дочерней NSEC RR и сброшен для родительской. Защищенный распознаватель должен использовать родительскую запись NSEC RR при попытке проверки отсутствия набора DS RRset.

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

5.3. Аутентификация RRset с помощью RRSIG RR

Проверяющий может использовать запись RRSIG RR и соответствующую ей DNSKEY RR для попытки аутентифицировать наборы RRset. Валидатор сначала проверяет RRSIG RR,чтобы убедиться в том, что эта запись покрывает RRset, срок ее действия не истек и она идентифицирует приемлемую запись DNSKEY RR. Затем проверяющий создает каноническую форму подписанных данных, добавляя в конце RRSIG RDATA (за исключением поля Signature) с канонической формой охватываемого набора RRset. В заключение проверяющий использует открытый ключ и подпись для аутентификации подписанных данных. Подробные описания всех этапов приведены в параграфах 5.3.1, 5.3.2 и 5.3.3.

5.3.1. Проверка корректности RRSIG RR

Защищенный распознаватель может использовать запись RRSIG RR для аутентификации RRset, если выполняются все перечисленные ниже условия:

  • RRSIG RR и RRset должны иметь одиноковые имя владельца и класс;

  • поле Signer’s Name записи RRSIG RR должно совпадать с именем зоны, содержащей RRset;

  • поле Type Covered записи RRSIG RR должно совпадать с полем типа в наборе RRset;

  • число меток в имени владельца RRset должно быть не меньше значения поля Labels в RRSIG RR;

  • Текущее время у проверяющего должно быть не больше значения поля Expiration в RRSIG RR;

  • Текущее время у проверяющего должно быть не меньше значения поля Inception в RRSIG RR;

  • поля Signer’s Name, Algorithm и Key Tag в записи RRSIG RR должны совпадать с именем владельца, алгоритмом и тегом ключа для той или иной DNSKEY RR в наборе DNSKEY RRset на вершине зоны;

  • соответствующая запись DNSKEY RR должна присутствовать в наборе DNSKEY RRset на вершине зоны и должна иметь установленный флаг Zone (бит 7 в DNSKEY RDATA Flag).

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

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

  • набор DNSKEY RRset на вершине зоны, содержащий DNSKEY RR считается подлинным;

  • набор RRset, охватываемый записью RRSIG RR, является вершиной самого DNSKEY RRset, а DNSKEY RR соответствует аутентифицированной DS RR из родительской зоны или доверенной привязке.

5.3.2. Реконструкция подписанных данных

После того, как проверено соответствие RRSIG RR требованиям, описанным в параграфе 5.3.1, проверяющий восстанавливает исходные подписанные данные. Эти данные включают RRSIG RDATA (без поля Signature) и каноническую форму RRset. Помимо изменения порядка, каноническая форма RRset может отличаться от полученного набора RRset за счет сжатия имен DNS, декрементирования значений TTL, преобразования шаблонов. Проверяющему следует использовать при восстановлении исходных подписанных данных форму

signed_data = RRSIG_RDATA | RR(1) | RR(2)...

где | обозначает конкатенацию, RRSIG_RDATA — поля RRSIG RDATA в формате передачи, за исключением поля Signature и канонического представления Signer’s Name.

RR(i) = name | type | class | OrigTTL | RDATA length | RDATA

Значение name в соответствии с приведенной ниже функцией

class — класс RRset;

type — тип RRset и всех RR в классе;

OrigTTL — значение поля Original TTL из RRSIG;

все имена в поле RDATA имеют каноническую форму;

Все RR(i) сортируются в каноническом порядке.

Для расчета значение name выполняются перечисленные ниже действия:

rrsig_labels = значение поля Labels из записи RRSIG;
fqdn = каноническая форма полного доменного имени RRset;
fqdn_labels = счетчик меток в значении fqdn;
если rrsig_labels = fqdn_labels,
name = fqdn
если rrsig_labels < fqdn_labels,
name = "*." | the rightmost rrsig_label labels of the fqdn
если rrsig_labels > fqdn_labels
RRSIG RR не проходит требуемых проверок приемлемости и эту запись НЕДОПУСТИМО использовать для аутентификации данного набора RRset.

Канонические формы для имен и наборов RRset определены в [RFC4034].

Наборы NSEC RRset на границах делегирования требуют специальной обработки. Есть два разных набора NSEC RRset, связанных с подписанным делегированным именем. Один из NSEC RRset размещается в родительской зоне и указывает, какие наборы RRset присутствуют в родительской зоне. Второй набор NSEC RRset размещается в дочерней зоне и указывает, какие RRset присутствуют на вершине дочерней зоны. Родительский и дочерний наборы NSEC RRset всегда различаются, поскольку только дочерняя NSEC RR будет указывать наличие для имени набора SOA RRset. При восстановлении исходного NSEC RRset для точки делегирования из родительской зоны записи NSEC RR недопустимо комбинировать с записями NSEC RR из дочерней зоны. При восстановлении исходного набора NSEC RRset для вершины дочерней зоны записи NSEC RR недопустимо объединять с записями NSEC RR из родительской зоны.

Отметим, что каждый из двух наборов NSEC RRset у точки делегирования имеет соответствующую запись RRSIG RR с именем владельца, соответствующим делегированному имени, и каждая из этих RRSIG RR является полномочными данными, связанными с той же самой зоной, которая содержит соответствующий набор NSEC RRset. При необходимости распознаватель может различать эти записи RRSIG RR по значению поля Signer’s Name.

5.3.3. Проверка подписи

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

Поле Algorithm в записи RRSIG RR указывает криптографический алгоритм, использованный для создания подписи. Сама подпись содержится в поле Signature записи RRSIG RDATA, а открытый ключ, используемый для проверки подписи, — в поле Public Key соответствующей записи (записей) DNSKEY RR (найденных, как описано в 5.3.1). В [RFC4034] приведен список типов алгоритмов и ссылки на документы, в которых определено применение каждого из этих алгоритмов.

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

Если значение поля Labels в RRSIG RR не совпадает с числом меток в полном доменном имени врадельца RRset, это говорит о некорректности набора RRset или преобразовании шаблонного имени. Распознаватель должен проверить корректность преобразования шаблона до того, как признать набор RRset подлинным. Процедура проверки корректности преобразования шаблонного имени описана в параграфе 5.3.4.

Если другие записи RRSIG RR также охватывают этот набор RRset, локальная политика безопасности распознавателя определяет, следует ли распознавателю проверять эти RRSIG RR, а также задает способ разрешения конфликтов в тех случаях, когда разные записи RRSIG RR дают различные результаты.

Если распознаватель признает набор RRset подлинным, он должен установить для TTL в RRSIG RR и каждой записи RR в аутентифицированном наборе RRset значение, не привышающее минимального из перечисленных ниже:

  • значение TTL из RRset, указанное в полученном отклике;

  • значение TTL из RRSIG RR, указанное в полученном отклике;

  • значение Original TTL в RRSIG RR;

  • разница между значением Signature Expiration в RRSIG RR и текущим временем.

5.3.4. Проверка RRset из позитивного отклика с преобразованием шаблона

Если число меток в имени владельца RRset превышает значение поля Labels в охватывающей этот набор записи RRSIG RR, это говорит о том, что RRset и покрывающая его запись RRSIG RR были созданы в результате преобразования шаблонного имени. После того, как валидатор проверит подпись, как описано в параграфе 5.3, он должен выполнить дополнительные действия для проверки отсутствия точного или более близкого соответствия шаблону для запроса, описанные в параграфе 5.4.

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

5.4. Аутентифицированный ответ об отсутствии

Распознаватель может использовать аутентифицированные записи NSEC RR для подтверждения отсутствия RRset в подписанной зоне. Защищенным серверам имен следует автоматически включать все требуемые записи NSEC RR для подписанных зон в свои отклики защищенным распознавателям.

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

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

  • Если имя запрашиваемой RR появляется после имени владельца аутентифицированной записи NSEC RR и до имени, указанного в поле Next Domain Name этой NSEC RR в соответствии с каноническим порядком имен DNS, определенном в [RFC4034], это говорит об отсутствии в зоне наборов RRset с запрошенным именем. Однако возможны ситуации с использованием шаблона для определения соответствия запрашиваемой RR имени владельца и типу, поэтому для подтверждения отсутствия запрошенного RRset требуется также подтвердить отсутствие каких-либо RRset, соответствующих шаблону.

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

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

Поскольку проверенная запись NSEC RR подтверждает существование самой себя и соответствующей записи RRSIG RR, проверяющая сторона должна игнорировать установки битов NSEC и RRSIG в записи NSEC RR.

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

Если по той или иной причине ни одна из записей RRSIG не может быть подтверждена, отклик следует рассматривать, как неприемлемый (BAD). Если проверка выполняется для обработки рекурсивного запроса, сервер имен должен возвращать клиенту, инициировавшему запрос, результат RCODE 2. Однако он должен возвращать полный отклик тогда и только тогда, когда в исходном запросе установлен бит CD. См. также параграф 4.7 по части кэшированных откликов, которые не проверяются.

5.6. Пример аутентификации

В Приложении C приведен пример процесса аутентификации.

6. Согласование с IANA

[RFC4034] включает обзор связанных с агентством IANA вопросов, относящихся к DNSSEC. Этот документ добавляет два связанных с IANA вопроса.

[RFC2535] резервирует биты CD и AD в заголовках сообщений. Значение бита AD было переопределено в [RFC3655], а данный документ заново определяет смысл битов CD и AD. Новых битов в заголовках сообщений DNS данный документ не определяет.

[RFC2671] вводит EDNS, а [RFC3225] резервирует бит DNSSEC OK и определяет его использование. Данный документ повторно определяет использование бита без внесения каких-либо изменений.

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

Этот документ описывает, как защитные расширения DNS используют криптографию с открытыми ключами для подписания и аутентификации наборов записей о ресурсах DNS. Терминология и общее описание вопросов безопасности, связанных с DNSSEC, приведены в [RFC4033], а в [RFC4034] описаны специфические для DNSSEC типы записей о ресурсах.

Активный атакующий, способный установить бит CD в запросном сообщении DNS или бит AD в отклике DNS, может воспользоваться этими битами для преодоления защиты, которую DNSSEC пытается организовать для незащищенных рекурсивных распознавателей. По этой причине для использования этих битов защищенными рекурсивными распознавателями требуется организация защищенного канала. Этот вопрос подробно рассмотрен в параграфах 3.2.2 и 4.9.

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

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

Этот документ был создан на основе предложений и идей членов рабочей группы DNS Extensions, а также подписчиков списка рассылок этой группы. Авторы рады выразить свою признательность за комментарии и предложения, полученные в процессе пересмотра этой спецификации защитных расширений. Хотя явно перечислить всех, кто внес свои предложения в течение десятилетия разработки DNSSEC просто не возможно, в [RFC4033] приведен список некоторых активных участников обсуждения этих документов.

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

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

[RFC1034] Mockapetris, P., «Domain names — concepts and facilities», STD 13, RFC 1034, November 1987.

[RFC1035] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, November 1987.

[RFC1122] Braden, R., «Requirements for Internet Hosts — Communication Layers», STD 3, RFC 1122, October 1989.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC2181] Elz, R. and R. Bush, «Clarifications to the DNS Specification», RFC 2181, July 1997.

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

[RFC2671] Vixie, P., «Extension Mechanisms for DNS (EDNS0)», RFC 2671, August 1999.

[RFC2672] Crawford, M., «Non-Terminal DNS Name Redirection», RFC 2672, August 1999.

[RFC3225] Conrad, D., «Indicating Resolver Support of DNSSEC», RFC 3225, December 2001.

[RFC3226] Gudmundsson, O., «DNSSEC and IPv6 A6 aware server/resolver message size requirements», RFC 3226, December 2001.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «DNS Security Introduction and Requirements», RFC 4033, March 2005.

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, «Resource Records for DNS Security Extensions», RFC 4034, March 2005.

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

[RFC2308] Andrews, M., «Negative Caching of DNS Queries (DNS NCACHE)», RFC 2308, March 1998.

[RFC2535] Eastlake 3rd, D., «Domain Name System Security Extensions», RFC 2535, March 1999.

[RFC3007] Wellington, B., «Secure Domain Name System (DNS) Dynamic Update», RFC 3007, November 2000.

[RFC3655] Wellington, B. and O. Gudmundsson, «Redefinition of DNS Authenticated Data (AD) bit», RFC 3655, November 2003.

Приложение A. Пример подписанной зоны

Ниже приведен пример (небольшой) полной подписанной зоны.

   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
                              1081539377
                              3600
                              300
                              3600000
                              3600
                              )
                  3600 RRSIG  SOA 5 1 3600 20040509183619 (
                              20040409183619 38519 example.
                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
                              jV7j86HyQgM5e7+miRAz8V01b0I= )
                  3600 NS     ns1.example.
                  3600 NS     ns2.example.
                  3600 RRSIG  NS 5 1 3600 20040509183619 (
                              20040409183619 38519 example.
                              gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
                              EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
                              4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
                              RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
                              0HjMeRaZB/FRPGfJPajngcq6Kwg= )
                  3600 MX     1 xx.example.
                  3600 RRSIG  MX 5 1 3600 20040509183619 (
                              20040409183619 38519 example.
                              HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB
                              2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE
                              VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO
                              6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM
                              W6OISukd1EQt7a0kygkg+PEDxdI= )
                  3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
                  3600 RRSIG  NSEC 5 1 3600 20040509183619 (
                              20040409183619 38519 example.
                              O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
                              FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
                              Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
                              SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
                              jfFJ5arXf4nPxp/kEowGgBRzY/U= )
                  3600 DNSKEY 256 3 5 (
                              AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV
                              rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e
                              k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo
                              vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI
                              ySFNsgEYvh0z2542lzMKR4Dh8uZffQ==
                              )
                  3600 DNSKEY 257 3 5 (
                              AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl
                              LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ
                              syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP
                              RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT
                              Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q==
                              )
                  3600 RRSIG  DNSKEY 5 1 3600 20040509183619 (
                              20040409183619 9465 example.
                              ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ
                              xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ
                              XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9
                              hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY
                              NC3AHfvCV1Tp4VKDqxqG7R5tTVM= )
                  3600 RRSIG  DNSKEY 5 1 3600 20040509183619 (
                              20040409183619 38519 example.
                              eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z
                              DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri
                              bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp
                              eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk
                              7z5OXogYVaFzHKillDt3HRxHIZM= )
   a.example.     3600 IN NS  ns1.a.example.
                  3600 IN NS  ns2.a.example.
                  3600 DS     57855 5 1 (
                              B6DCD485719ADCA18E5F3D48A2331627FDD3
                              636B )
                  3600 RRSIG  DS 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
                              oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
                              kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
                              EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
                              Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
                  3600 NSEC   ai.example. NS DS RRSIG NSEC
                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba
                              U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2
                              039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I
                              BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g
                              sdkOW6Zyqtz3Zos8N0BBkEx+2G4= )
   ns1.a.example. 3600 IN A   192.0.2.5
   ns2.a.example. 3600 IN A   192.0.2.6
   ai.example.    3600 IN A   192.0.2.9
                  3600 RRSIG  A 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
                              ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
                              hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
                              ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
                              6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
                  3600 HINFO  "KLH-10" "ITS"
                  3600 RRSIG  HINFO 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l
                              e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh
                              ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7
                              AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw
                              FvL8sqlS5QS6FY/ijFEDnI4RkZA= )
                  3600 AAAA   2001:db8::f00:baa9
                  3600 RRSIG  AAAA 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
                              kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
                              1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
                              cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
                              sZM6QjBBLmukH30+w1z3h8PUP2o= )
                  3600 NSEC   b.example. A HINFO AAAA RRSIG NSEC
                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG
                              CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p
                              P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN
                              3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL
                              AhS+JOVfDI/79QtyTI0SaDWcg8U= )
   b.example.     3600 IN NS  ns1.b.example.
                  3600 IN NS  ns2.b.example.
                  3600 NSEC   ns1.example. NS RRSIG NSEC
                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
                              9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
                              xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
                              0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
                              vhRXgWT7OuFXldoCG6TfVFMs9xE= )
   ns1.b.example. 3600 IN A   192.0.2.7
   ns2.b.example. 3600 IN A   192.0.2.8
   ns1.example.   3600 IN A   192.0.2.1
                  3600 RRSIG  A 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
                              5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
                              im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
                              +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
                              v/iVXSYC0b7mPSU+EOlknFpVECs= )
                  3600 NSEC   ns2.example. A RRSIG NSEC
                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
                              1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
                              jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
                              ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
                              IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
   ns2.example.   3600 IN A   192.0.2.2
                  3600 RRSIG  A 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
                              Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
                              yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
                              6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
                              rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
                  3600 NSEC   *.w.example. A RRSIG NSEC
                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE
                              VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb
                              3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH
                              l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw
                              Ymx28EtgIpo9A0qmP08rMBqs1Jw= )
   *.w.example.   3600 IN MX  1 ai.example.
                  3600 RRSIG  MX 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
                              f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
                              tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
                              TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
                              4kX18MMR34i8lC36SR5xBni8vHI= )
                  3600 NSEC   x.w.example. MX RRSIG NSEC
                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
                              HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
                              5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
                              91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
                              s1InQ2UoIv6tJEaaKkP701j8OLA= )
   x.w.example.   3600 IN MX  1 xx.example.
                  3600 RRSIG  MX 5 3 3600 20040509183619 (
                              20040409183619 38519 example.
                              Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
                              XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
                              H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
                              kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
                              jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
                  3600 NSEC   x.y.w.example. MX RRSIG NSEC
                  3600 RRSIG  NSEC 5 3 3600 20040509183619 (
                              20040409183619 38519 example.
                              aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK
                              vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E
                              mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI
                              NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e
                              IjgiM8PXkBQtxPq37wDKALkyn7Q= )
   x.y.w.example. 3600 IN MX  1 xx.example.
                  3600 RRSIG  MX 5 4 3600 20040509183619 (
                              20040409183619 38519 example.
                              k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia
                              t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj
                              q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq
                              GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb
                              +gLcMZBnHJ326nb/TOOmrqNmQQE= )
                  3600 NSEC   xx.example. MX RRSIG NSEC
                  3600 RRSIG  NSEC 5 4 3600 20040509183619 (
                              20040409183619 38519 example.
                              OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
                              ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
                              xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
                              a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
                              QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
   xx.example.    3600 IN A   192.0.2.10
                  3600 RRSIG  A 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
                              7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
                              0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
                              VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
                              kbIDV6GPPSZVusnZU6OMgdgzHV4= )
                  3600 HINFO  "KLH-10" "TOPS-20"
                  3600 RRSIG  HINFO 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0
                              t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq
                              BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8
                              3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+
                              RgNvuwbioFSEuv2pNlkq0goYxNY= )
                  3600 AAAA   2001:db8::f00:baaa
                  3600 RRSIG  AAAA 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
                              aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
                              ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
                              U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
                              xS9cL2QgW7FChw16mzlkH6/vsfs= )
                  3600 NSEC   example. A HINFO AAAA RRSIG NSEC
                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY
                              9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k
                              mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi
                              asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W
                              GghLahumFIpg4MO3LS/prgzVVWo= )

 

Вершина набора DNSKEY включает две записи DNSKEY RR и поле DNSKEY RDATA Flags показывает, что каждая из этих DNSKEY RR является ключом зоны. Одна из этих записей DNSKEY RR имеет также установленный флаг SEP и служит подписью вершины DNSKEY RRset; этот ключ следует хэшировать для генерации записи DS, которая будет помещаться в родительскую зону. Другая запись DNSKEY используется в качестве подписи для всех остальных RRset в зоне.

Зона включает шаблонную запись *.w.example. Отметим, что имя *.w.example используется при создании цепочек NSEC и подпись RRSIG, покрывающая набор *.w.example MX RRset имеет значение счетчика меток 2.

Зона также включает два делегирования. Делегирование для b.example включает NS RRset, склеивающие записи и NSEC RR, причем подписывается только NSEC RRset. Делегирование для a.example обеспечивает DS RR и подписываются только NSEC и наборы DS RRset.

Приложение B. Примеры откликов

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

B.1. Ответ

Успешный запрос к полномочному серверу.

   ;; Header: QR AA DO RCODE=0
   ;;
   ;; Question
   x.w.example.        IN MX

   ;; Answer
   x.w.example.   3600 IN MX  1 xx.example.
   x.w.example.   3600 RRSIG  MX 5 3 3600 20040509183619 (
                              20040409183619 38519 example.
                              Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
                              XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
                              H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
                              kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
                              jNSlwZ2mSWKHfxFQxPtLj8s32+k= )

   ;; Authority
   example.       3600 NS     ns1.example.
   example.       3600 NS     ns2.example.
   example.       3600 RRSIG  NS 5 1 3600 20040509183619 (
                              20040409183619 38519 example.
                              gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
                              EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
                              4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
                              RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
                              0HjMeRaZB/FRPGfJPajngcq6Kwg= )

   ;; Additional
   xx.example.    3600 IN A   192.0.2.10
   xx.example.    3600 RRSIG  A 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
                              7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
                              0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
                              VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
                              kbIDV6GPPSZVusnZU6OMgdgzHV4= )
   xx.example.    3600 AAAA   2001:db8::f00:baaa
   xx.example.    3600 RRSIG  AAAA 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
                              aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
                              ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
                              U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
                              xS9cL2QgW7FChw16mzlkH6/vsfs= )
   ns1.example.   3600 IN A   192.0.2.1
   ns1.example.   3600 RRSIG  A 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
                              5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
                              im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
                              +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
                              v/iVXSYC0b7mPSU+EOlknFpVECs= )
   ns2.example.   3600 IN A   192.0.2.2
   ns2.example.   3600 RRSIG  A 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
                              Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
                              yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
                              6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
                              rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )

 

B.2. Ошибка имени

Ответ полномочного сервера об ошибке в имени. Записи NSEC RR говорят об отсутствии имени и покрывающего его шаблонного имени.

   ;; Header: QR AA DO RCODE=3
   ;;
   ;; Question
   ml.example.         IN A

   ;; Answer
   ;; (пусто)

   ;; Authority
   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
                              1081539377
                              3600
                              300
                              3600000
                              3600
                              )
   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
                              20040409183619 38519 example.
                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
                              jV7j86HyQgM5e7+miRAz8V01b0I= )
   b.example.     3600 NSEC   ns1.example. NS RRSIG NSEC
   b.example.     3600 RRSIG  NSEC 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
                              9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
                              xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
                              0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
                              vhRXgWT7OuFXldoCG6TfVFMs9xE= )
   example.       3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
   example.       3600 RRSIG  NSEC 5 1 3600 20040509183619 (
                              20040409183619 38519 example.
                              O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
                              FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
                              Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
                              SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
                              jfFJ5arXf4nPxp/kEowGgBRzY/U= )

   ;; Additional
   ;; (пусто)

 

B.3. Нет данных

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

   ;; Header: QR AA DO RCODE=0
   ;;
   ;; Question
   ns1.example.        IN MX

   ;; Answer
   ;; (пусто)

   ;; Authority
   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
                              1081539377
                              3600
                              300
                              3600000
                              3600
                              )
   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
                              20040409183619 38519 example.
                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
                              jV7j86HyQgM5e7+miRAz8V01b0I= )
   ns1.example.   3600 NSEC   ns2.example. A RRSIG NSEC
   ns1.example.   3600 RRSIG  NSEC 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
                              1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
                              jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
                              ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
                              IZaIGBLryQWGLw6Y6X8dqhlnxJM= )

   ;; Additional
   ;; (пусто)

 

B.4. Отсылка к подписанной зоне

Запись DS RR содержит данные, которые будут нужны распознавателю для проверки соответствующей DNSKEY RR на вершине дочерней зоны.

   ;; Header: QR DO RCODE=0
   ;;
   ;; Question
   mc.a.example.       IN MX

   ;; Answer
   ;; (пусто)

   ;; Authority
   a.example.     3600 IN NS  ns1.a.example.
   a.example.     3600 IN NS  ns2.a.example.
   a.example.     3600 DS     57855 5 1 (
                              B6DCD485719ADCA18E5F3D48A2331627FDD3
                              636B )
   a.example.     3600 RRSIG  DS 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
                              oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
                              kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
                              EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
                              Fm+v6ccF2EGNLRiY08kdkz+XHHo= )

   ;; Additional
   ns1.a.example. 3600 IN A   192.0.2.5
   ns2.a.example. 3600 IN A   192.0.2.6

 

B.5. Отсылка к неподписанной зоне

Запись NSEC RR говорит об отсутствии в родительской зоне записи DS RR для этого делегирования.

   ;; Header: QR DO RCODE=0
   ;;
   ;; Question
   mc.b.example.       IN MX

   ;; Answer
   ;; (пусто)

   ;; Authority
   b.example.     3600 IN NS  ns1.b.example.
   b.example.     3600 IN NS  ns2.b.example.
   b.example.     3600 NSEC   ns1.example. NS RRSIG NSEC
   b.example.     3600 RRSIG  NSEC 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
                              9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
                              xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
                              0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
                              vhRXgWT7OuFXldoCG6TfVFMs9xE= )
   ;; Additional
   ns1.b.example. 3600 IN A   192.0.2.7
   ns2.b.example. 3600 IN A   192.0.2.8

 

B.6. Преобразование шаблона

Успешный запрос, для ответа на который выполнялось преобразование шаблонного имени. Счетчик меток в записи RRSIG RR отклика показывает, что шаблонный набор RRset был преобразован для создания этого отклика с заменой шаблона реальной меткой, NSEC RR подтверждает, что более точного соответствия шаблону в зоне не существует.

   ;; Header: QR AA DO RCODE=0
   ;;
   ;; Question
   a.z.w.example.      IN MX

   ;; Answer
   a.z.w.example. 3600 IN MX  1 ai.example.
   a.z.w.example. 3600 RRSIG  MX 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
                              f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
                              tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
                              TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
                              4kX18MMR34i8lC36SR5xBni8vHI= )

   ;; Authority
   example.       3600 NS     ns1.example.
   example.       3600 NS     ns2.example.
   example.       3600 RRSIG  NS 5 1 3600 20040509183619 (
                              20040409183619 38519 example.
                              gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
                              EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
                              4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
                              RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
                              0HjMeRaZB/FRPGfJPajngcq6Kwg= )
   x.y.w.example. 3600 NSEC   xx.example. MX RRSIG NSEC
   x.y.w.example. 3600 RRSIG  NSEC 5 4 3600 20040509183619 (
                              20040409183619 38519 example.
                              OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
                              ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
                              xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
                              a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
                              QoKqJDCLnoAlcPOPKAm/jJkn3jk= )

   ;; Additional
   ai.example.    3600 IN A   192.0.2.9
   ai.example.    3600 RRSIG  A 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
                              ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
                              hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
                              ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
                              6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
   ai.example.    3600 AAAA   2001:db8::f00:baa9
   ai.example.    3600 RRSIG  AAAA 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
                              kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
                              1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
                              cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
                              sZM6QjBBLmukH30+w1z3h8PUP2o= )

 

B.7. Отсутствие заданных шаблоном данных

Отклик no data (нет данных) для имени, покрываемого шаблоном. Записи NSEC RR подтверждают, что для соответствующего шаблону имени нет каких-либо записей RR запрошенного типа и в зоне нет более точного соответствия шаблону имени.

   ;; Header: QR AA DO RCODE=0
   ;;
   ;; Question
   a.z.w.example.      IN AAAA

   ;; Answer
   ;; (пусто)

   ;; Authority
   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
                              1081539377
                              3600
                              300
                              3600000
                              3600
                              )
   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
                              20040409183619 38519 example.
                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
                              jV7j86HyQgM5e7+miRAz8V01b0I= )
   x.y.w.example. 3600 NSEC   xx.example. MX RRSIG NSEC
   x.y.w.example. 3600 RRSIG  NSEC 5 4 3600 20040509183619 (
                              20040409183619 38519 example.
                              OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
                              ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
                              xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
                              a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
                              QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
   *.w.example.   3600 NSEC   x.w.example. MX RRSIG NSEC
   *.w.example.   3600 RRSIG  NSEC 5 2 3600 20040509183619 (
                              20040409183619 38519 example.
                              r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
                              HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
                              5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
                              91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
                              s1InQ2UoIv6tJEaaKkP701j8OLA= )

   ;; Additional
   ;; (пусто)

 

B.8. Отсутствие данных DS для дочерней зоны

Отклик об отсутствии данных (no data) для запроса QTYPE=DS, ошибочно направленного серверу имен для дочерней зоны.

   ;; Header: QR AA DO RCODE=0
   ;;
   ;; Question
   example.            IN DS

   ;; Answer
   ;; (пусто)

   ;; Authority
   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
                              1081539377
                              3600
                              300
                              3600000
                              3600
                              )
   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
                              20040409183619 38519 example.
                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
                              jV7j86HyQgM5e7+miRAz8V01b0I= )
   example.       3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
   example.       3600 RRSIG  NSEC 5 1 3600 20040509183619 (
                              20040409183619 38519 example.
                              O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
                              FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
                              Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
                              SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
                              jfFJ5arXf4nPxp/kEowGgBRzY/U= )

   ;; Additional
   ;; (пусто)

 

Приложение C. Примеры аутентификации

Примеры в этом приложении показывают, как выполняется аутентификация откликов, приведенных в Приложении B.

C.1. Аутентификация ответа

Запрос из Приложения B.1 возвращает набор MX RRset для x.w.example.com. Соответствующая запись RRSIG показывает, что набор MX RRset был подписан ключом DNSKEY для example с использованием алгоритма 5 и тега ключа 38519. Распознавателю нужна соответствующая запись DNSKEY RR для проверки подлинности этого ответа. Ниже описано, как распознаватель может получить эту запись DNSKEY RR.

Запись RRSIG показывает, что исходное значение TTL для MX RRset было 3600, и для целей аутентификации текущее значение TTL меняется на 3600. Значение 3 в поле Labels записи RRSIG говорит о том, что ответ не является результатом преобразования шаблона. Набор x.w.example.com MX RRset помещается в канонической форме и, в предположении того, что текущее время попадает в интервал между вводом и завершением срока действия подписи, эта подпись считается подлинной.

C.1.1. Пример аутентификации DNSKEY RR

Этот пример показывает логический процесс аутентификации, который начинается с заданного в конфигурации корня DNSKEY (или DS RR) и перемещается вниз по дереву для аутентификации нужной записи example DNSKEY RR. Отметим, что логический порядок представлен для лучшего понимания. Реализации могут выбрать проведение аутентификации по мере получения отсылок (referral) или путем создания аутентификационной цепочки только после получения всех наборов RRset, а также с использованием любой другой комбинации. Приведенный пример демонстрирует лишь логику, не задавая правил реализации.

Предполагается, что распознаватель начинает с заданной в конфигурации записи DNSKEY RR для корневой зоны (или с записи DS RR для корневой зоны). Распознаватель проверяет наличие заданной в конфигурации записи DNSKEY RR в корневом наборе DNSKEY RRset (или проверяет соответствие DS RR тому или иному ключу DNSKEY в корневом наборе DNSKEY RRset), факт подписания DNSKEY RR корневым набором DNSKEY RRset, а также корректность срока действия подписи. При выполнении всех перечисленных условий все ключи в DNSKEY RRset считаются подлинными. После этого распознаватель использует одну или несколько корневых записей DNSKEY RR для проверки подлинности example DS RRset. Отметим, что распознаватель может запросить у корневой зоны набор DNSKEY RRset или example DS RRset.

После подтверждения подлинности DS RRset с использованием корневой записи DNSKEY распознаватель проверяет example DNSKEY RRset на предмет наличия записи example DNSKEY RR, соответствующей аутентифицированным записям example DS RR. Если такая запись example DNSKEY найдена, распознаватель проверяет, что данная запись DNSKEY RR подписана example DNSKEY RRset и срок действия подписи не истек. При выполнении всех этих условий все ключи в наборе example DNSKEY RRset считаются аутентифицированными.

В заключение распознаватель проверяет, что та или иная запись DNSKEY RR в наборе example DNSKEY RRset использует алгоритм 5 и имеет тег ключа 38519. Эта запись DNSKEY служит для проверки подлинности записи RRSIG, включенной в отклик. Если номеру алгоритма и тегу ключа соответствует множество записей example DNSKEY RR, проверяется каждая запись DNSKEY RR и ответ считается подлинным, если любая из соответствующих записей DNSKEY RR подтверждает подпись, как было описано выше.

C.2. Ошибка имени

Запрос, приведенный в Приложении B.2, возвращает записи NSEC RR, подтверждающие отсутствие запрошенных данных и подходящих шаблонов. Негативные отклики аутентифицируются путем проверки обеих записей NSEC RR. Эти записи аутентифицируются, подобно описанному выше набору MX RRset.

C.3. Нет данных

Запрос, приведенный в Приложении B.3, возвращает запись NSEC RR, подтверждающую наличие запрошенного имени и отсутствие запрошенного типа RR. Негативный отклик аутентифицируется путем проверки записи NSEC RR. Эта запись аутентифицируется, подобно описанному выше набору MX RRset.

C.4. Отсылка к подписанной зоне

Запрос, приведенный в Приложении B.4, возвращает отсылку к подписанной зоне a.example. Запись DS RR аутентифицируется, подобно описанному выше набору MX RRset. Эта DS RR служит для проверки подлинности набора a.example DNSKEY RRset.

После того, как набор a.example DS RRset будет аутентифицирован с использованием записи example DNSKEY, распознаватель проверяет набор a.example DNSKEY RRset на предмет наличия записи a.example DNSKEY RR, соответствующей DS RR. При обнаружении такой записи a.example DNSKEY распознаватель проверяет, подписана ли эта DNSKEY RR с помощью a.example DNSKEY RRset и приемлема ли по сроку действия. Если все эти условия выполнены, набор a.example DNSKEY RRset считается подлинным.

C.5. Отсылка к неподписанной зоне

Запрос, приведенный в Приложении B.5, возвращает отсылку к неподписанной зоне b.example.. Запись NSEC подтверждает отсутствие аутентификации со стороны example для зоны b.example и запись NSEC RR аутентифицируется аналогично описанному выше набору MX RRset.

C.6. Преобразование шаблона

Запрос, приведенный в Приложении B.6, возвращает отклик, созданный в результате преобразования шаблона. Раздел answer содержит шаблонный набор RRset, полученный как в традиционном отклике DNS, и соответствующая запись RRSIG показывает, что шаблонный набор MX RRset был подписан example DNSKEY с использованием алгоритма 5 и тега ключа 38519. запись RRSIG показывает, что исходное значение TTL для набора MX RRset было 3600 и для целей аутентификации текущее значение TTL заменено на 3600. Поле Labels записи RRSIG со значением 2 показывает, что отклик является результатом преобразования шаблона, поскольку имя a.z.w.example включает 4 метки. Имя a.z.w.w.example заменяется на *.w.example, набор MX RRset помещается в канонической форме и, в предположении того, что текущее время попадает в срок действия подписи, последняя считается подлинной.

Запись NSEC подтверждает отсутствие более точного соответствия (включая полное совпадение) для отклика на этот запрос, а запись NSEC RR должна быть аутентифицирована до того, как ответ будет признан подлинным.

C.7. Отсутствие данных для шаблона

Запрос, приведенный в Приложении B.7, возвращает записи NSEC RR, которые подтверждают отсутствие запрошенных данных и подходящего шаблона. Негативный отклик аутентифицируется путем проверки обеих записей NSEC RR.

C.8. Отсутствие данных DS для дочерней зоны

Запрос, приведенный в Приложении B.8, возвращает записи NSEC RR, которые показывают, что ответ на запрос был получен от дочернего сервера (сервер example). Запись NSEC RR показывает наличие записи SOA RR, говорящей о получении ответа от потомка. Запросы для example DS RRset следует направлять родительским (корневым) серверам.

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

Roy Arends

Telematica Instituut

Brouwerijstraat 1

7523 XC Enschede

NL

EMail: roy.arends@telin.nl

Rob Austein

Internet Systems Consortium

950 Charter Street

Redwood City, CA 94063

USA

EMail: sra@isc.org

Matt Larson

VeriSign, Inc.

21345 Ridgetop Circle

Dulles, VA 20166-6503

USA

EMail: mlarson@verisign.com

Dan Massey

Colorado State University

Department of Computer Science

Fort Collins, CO 80523-1873

EMail: massey@cs.colostate.edu

Scott Rose

National Institute for Standards and Technology

100 Bureau Drive

Gaithersburg, MD 20899-8920

USA

EMail: scott.rose@nist.gov

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

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

nmalykh@protoclos.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor в настоящее время обеспечивается Internet Society.

1В оригинале ошибочно указано также обновление RFC 3007. См. https://www.rfc-editor.org/errata_search.php?rfc=4035. Прим. перев.

2Security-aware resolver.

3Resource Record Signature.

4Next Secure – следующий защищенный владелец.

5Delegation Signer – подписавший передачу полномочий.

6Checking Disabled.

7Authentic Data.

8Не реализовано.

9Отказ.




RFC 4023 Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)

Network Working Group                                         T. Worster
Request for Comments: 4023                                Motorola, Inc.
Category: Standards Track                                     Y. Rekhter
                                                  Juniper Networks, Inc.
                                                           E. Rosen, Ed.
                                                     Cisco Systems, Inc.
                                                              March 2005

Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)

Инкапсуляция MPLS в IP или GRE

PDF

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

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

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

Copyright (C) The Internet Society (2005).

Тезисы

Различные приложения MPLS используют стеки меток со множеством элементов. В некоторых случаях можно заменить верхнюю метку стека инкапсуляцией на базе IP, что позволяет приложению работать в сетях без поддержки MPLS на маршрутизаторах ядра. Этот документ определяет два варианта инкапсуляции на базе IP — MPLS-in-IP и MPLS-in-GRE1. Каждый из этих вариантов применим в определенных ситуациях.

Оглавление

Исключено в версии HTML.

1. Предпосылки

Во многих приложениях MPLS пакеты, проходящие через магистраль MPLS, содержат стек со множеством меток. Как указано в параграфе 3.15 [RFC3031], каждая метка представляет путь LSP2. Для каждого LSP имеются маршрутизаторы LSR3, являющиеся входным (LSP Ingress) и выходным (LSP Egress). Если маршрутизаторы A и B являются входным и выходным (соответственно) для LSP, соответствующего верхней метке в пакете, A и B являются смежными LSR на пути LSP, соответствующем второй метке (метке, непосредственно под верхней).

Назначение (или одна из целей) верхней метки состоит в точ, чтобы при доставке пакета от A к B маршрутизатор B мог продолжить обработку на основе второй метки. В этом смысле верхняя метка служит заголовком инкапсуляции для остального пакета. Иногда вместо верхней метки могут применяться другие заголовки инкапсуляции без потери функциональности. Например, вместо верхней метки может присутствовать заголовок IP или GRE. Поскольку инкапсулированный пакет остается пакетом MPLS, результататом будет инкапсуляция MPLS-in-IP или MPLS-in-GRE.

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

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

  • IP-адрес декапсулирующего LSR;

  • реальность поддержки конкретной инкапсуляции на декапсулирующем LSR.

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

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

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

3. Инкапсуляция в IP

Формат сообщений MPLS, инкапсулированных в IP, показан ниже.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                     |
|             IP Header               |
|                                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                     |
|          MPLS Label Stack           |
|                                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                     |
|            Message Body             |
|                                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

IP Header

Это поле содержит заголовок дейтаграммы IPv4 или IPv6 в соответствии с [RFC791] или [RFC2460]. В качестве адресов отправителя и получателя указываются адреса инкапсулирующего и декапсулирующего LSR, соответственно.

MPLS Label Stack

Это поле содержит стек меток MPLS в соответствии с определением [RFC3032].

Message Body

Это поле содержит тело одного сообщения MPLS.

В поле IPv4 Protocol Number или IPv6 Next Header помещается значение 137, указывающее индивидуальный (unicast) пакет MPLS. Применение инкапсуляции MPLS в IP для групповых пакетов MPLS эта спецификация не поддерживает.

После заголовка IP помещается пакет MPLS, как указано в [RFC3032]. Эта инкапсуляция вызывает передачу пакетов MPLS через «туннели IP». Когда конечная точка туннеля принимает пакет, она декапсулирует пакет MPLS, удаляя заголовок IP. Затем пакет обрабатывается как пакет MPLS, в котором «входной меткой» [RFC3031] является верхняя метка декапсулированного пакета.

4. Инкапсуляция в GRE

Инкапсуляция MPLS в GRE помещает пакеты MPLS в пакеты GRE [RFC2784]. Пакет состоит из заголовка IP (IPv4 или IPv6), за которым следует заголовок GRE, а затем стек меток MPLS в соответствии с [RFC3032]. В поле типа протокола заголовка GRE должно указываться значение Ethertype для MPLS Unicast (0x8847) или Multicast (0x8848).

Эта инкапсуляция ведет к передаче пакетов MPLS через «туннели GRE». Когда конечная точка туннеля принимает пакет, она декапсулирует пакет MPLS, удаляя заголовки IP и GRE. После этого принятый пакет MPLS обрабатывается с использованием в качестве «входной» [RFC3031] верхней метки декапсулированного пакета.

[RFC2784] задает необязательную контрольную сумму GRE, а [RFC2890] — необязательные поля ключа GRE и порядкового номера. Эти поля не очень полезны для инкапсяляции MPLS в GRE. Поля порядкового номера и контрольной суммы не нужны по причине отсутствия соответствующих полей в туннелируемых пакетах MPLS. Поле GRE key не требуется для демультиплексирования, поскольку для этого служит верхняя метка MPLS инкапсулированного пакета. Иногда поле ключа GRE рассматривают как средство защиты, позволяющее передавать в открытом виде 32-битовый пароль, однако такая защиты очень слаба. Для (a) упрощения высокоскоростных реализаций и (b) обеспечения интероперабельности мы требуем от всех реализаций способность корректно работать без этих необязательных полей.

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

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

5. Общие процедуры

Некоторые процедуры являются общими для инкапсуляции MPLS-in-IP и MPLS-in-GRE. Далее инкапсулятор, чей адрес IP появляется в поле отправителя в заголовке IP, называется «началом туннеля» (tunnel head). Декапсулятор, чей адрес указан в поле получателя в декапсулируемом заголовке IP, называется «концом туннеля» (tunnel tail).

При использовании IPv6 (для MPLS-in-IPv6 или MPLS-in-GRE-in-IPv6) процедуры [RFC2473] остаются применимыми.

5.1. Предотвращение фрагментации и сборки

Если пакет MPLS-in-IP или MPLS-in-GRE фрагментируется («обычная» фрагментация IP), конечная точка туннеля должна собрать его до того, как станет возможной декапсуляция MPLS. Когда туннель заканчивается на маршрутизаторе, сборка явно не желательна, поскольку у маршрутизатора может не быть ресурсов для сборки с требуемой производительностью.

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

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

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

При использовании IPv4 для туннеля должен быть установлен бит DF. Это будет препятствовать фрагментированию пакетов на промежуточных узлах туннеля (при использовании IPv6 промежуточные узлы никогда не будут фрагментировать пакеты).

В начальной точке следует выполнить процедуру Path MTU Discovery ([RFC1191] для IPv4 или [RFC1981] для IPv6).

В начале туннеля должно поддерживаться значение Tunnel MTU для каждого имеющегося туннеля. Это меньшее из двух значений — (a) заданное административно и (b) Path MTU за вычетом издержек инкапсуляции.

Если начальная точка туннеля получает для инкапсуляции пакет MPLS, размер которого превосходит Tunnel MTU, такой пакет должен отбрасываться. Однако отбрасывание таких пакетов без уведомления отправителей может создать существенные проблемы в работе, поскольку создатель пакета заметит, что пакет не прошел, но может не понять, что причиной этого послужил избыточный размер пакета. В результате он может продолжить передачу пакетов, которые будут отбрасываться. Механизм определения Path MTU может помочь (если туннель будет возвращать ошибки ICMP), но зачастую в начальной точке туннеля нет достаточной информации для определения исходного отправителя. Чтобы свести проблемы к минимуму, предлагается делать MTU достаточно большими, предотвращая фрагментацию на практике.

В некоторых случаях начальная точка туннеля будет получать для инкапсуляции пакеты IP, которые были сначала инкапсулированы в MPLS, а затем в MPLS-in-IP или MPLS-in-GRE. Если отправитель пакета IP доступен из начальной точки туннеля и в результате пакета в MPLS его размер превышает Tunnel MTU, значением, которое этой точке следует применять для фрагментации и определения PMTU за пределами туннеля, будет значением Tunnel MTU за вычетом размера инкапсуляции MPLS (т. е. Tunnel MTU минус размер инкапсуляции MPLS будет определять значение MTU, передаваемое в сообщениях). Пакет будет отбрасываться, но начальной точке туннеля следует указать IP-адрес его источника в подходящем сообщении ICMP, как указано в [RFC1191] или [RFC1981].

5.2. TTL или Hop Limit

Начальная точка туннеля может помещать значение TTL из стека меток MPLS в поле TTL заголовка инкапсуляции IPv4 или поле Hop Limit инкапсулирующего заголовка IPv6. В конце туннеля можно помещать значение TTL из инкапсулирующего заголовка IPv4 или Hop Limit из заголовка IPv6 в поле TTL заголовка MPLS, если это не бует увеличивать значение TTL в заголовке MPLS.

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

5.3. Дифференцированные услуги

Описанные в документе процедуры позволяют организовать LSP через туннель IP или GRE. В [RFC2983] подробно рассмотрены многочисленные вопросы и процедуры, связанные с поддержкой архитектуры дифференцированных услуг при наличии туннелей IP-in-IP. Эти соображения и процедуры применимы к туннелям MPLS-in-IP и MPLS-in-GRE.

Соответственно, при сборке пакета MPLS в MPLS-in-IP или MPLS-in-GRE начальной точкой туннеля установка поля DS в инкапсулирующем заголовке IPv4 или IPv6 может определяться (по крайней мере частично) «агрегатом поведения» пакета MPLS. Процедуры определения Behavior Aggregate для пакетов MPLS заданы в [RFC3270].

Аналогично, в конечной точке туннеля поле DS в заголовке инкапсуляции IPv4 или IPv6 может определять Behavior Aggregate для инкапсулированного пакета MPLS. В [RFC3270] указаны связи между агрегатом поведения и последующим размещением пакета.

6. Применимость

Инкапсуляция MPLS-in-IP более эффективна и при прочих равных условиях обычно считается предпочтительной. Однако в некоторых ситуациях может применяться инкапсуляция MPLS-in-GRE, как указано ниже.

  • Два маршрутизатора являются «смежными» через туннель GRE, организованный по не связанным с этим документом причинам, и эти маршрутизаторы передают пакеты MPLS через такой туннель. Для всех отправляемых в туннель пакетов применяется инкапсуляция GRE и вариант MPLS-in-GRE будет более предпочтительным, поскольку инкапсуляция MPLS-in-IP все равно будет инкапсулироваться в GRE.

  • Особенности реализации могут требовать применения MPLS-in-GRE. Например, то или иное устройство может оказаться способным обрабатывать лишь инкапсуляцию GRE на своем «быстром пути» (fastpath).

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

Агентство IANA выделило значение 137 в качестве IP Protocol Number для инкапсуляции MPLS-in-IP, как указано в разделе 3. Других действий от IANA не требуется. Для инкапсуляции MPLS-in-GRE не требуется действий IANA.

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

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

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

8.1. Защита туннелей с помощью IPsec

Всех упомянутых проблем безопасности можно избежать, если туннель MPLS-in-IP или MPLS-in-GRE будет защищен с помощью IPsec. Приведенные ниже требования к реализации применимы для случев использования IPsec.

При использовании IPsec начало и конец туннеля следует считать конечными точками защищенной связи SA4. Для этого один адрес IP начальной точки туннеля будет служить IP-адресом отправителя, а один адрес IP конечной точки туннеля — IP-адресом получателя. Способы, используемые для получения информации об используемом другой сторонй туннеля адресе выходят за рамки этого документа. Если для организации туннелей используется протокол управления (например, для информирования оконечной точки туннеля о IP-адресе другой стороны), этот протокол должен иметь механизм проверки подлинности и этот механизм должен применяться при организации туннеля. Если туннель организован автоматически, например, с помощью распространяемой по протоколу BGP информации, использования механизма аутентификации BGP на основе MD5 будет достаточно.

Пакеты с инкапсуляцией MPLS-in-IP или MPLS-in-GRE следует считать исходящими из начальной точки туннеля и адресованными конечной точке. Следует применять транспортный режим IPsec.

Заголовок IP пакета MPLS-in-IP становится внешним заголовком IP результирующего пакета, когда начальная точка туннеля использует транспортный режим IPsec для защиты пакетов MPLS-in-IP. За ним следует заголовок IPsec, а затем — стек меток MPLS. В заголовке IPsec устанавливается тип данных MPLS путем указания номера протокола IP, заданного в разделе 3. Если транспортный режим IPsec применяется для пакетов MPLS-in-GRE, заголовок GRE следует после заголовка IPsec.

В конечной точке туннеля выходная обработка IPsec восстанавливает инкапсулированный пакет MPLS-in-IP/GRE. Затем конечная точка вырезает заголовок IP/GRE для восстановления пакета MPLS, который пересылается в соответствии со стеком меток.

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

Защищенные с помощью IPsec туннели MPLS-in-IP и MPLS-in-GRE должны обеспечивать аутентификацию и целостность (отметим, что проверка подлинности и защита целостности применяются ко всему пакету MPLS, включая стек меток). Поэтому реализация должна поддерживать ESP с null (пустым) шифрованием. Может поддерживаться ESP с реальным шифрованием, если требуется защита конфиденциальности. При использовании ESP конечная точка туннеля должна проверять принадлежность IP-адреса всех пакетов, принятых через SA, к числу ожидаемых.

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

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

При использовании инкапсуляции MPLS-in-IP селекторами, связанными с SA, будут адреса отправителя и получателя, упомянутые выше, а также номер протокола IP, заданный в разделе 3. Если нужно защитить множество туннелей MPLS-in-IP между данной парой узлов по-отдельности, для каждого туннеля должна применяться уникальная пара адресов.

При использовании инкапсуляции MPLS-in-GRE селекторами, связанными с SA, будут адреса отправителя и получателя, упомянутые выше, а также номер протокола IP, заданный для GRE (47). Если нужно защитить множество туннелей MPLS-in-GRE между данной парой узлов по-отдельности, для каждого туннеля должна применяться уникальная пара адресов.

8.2. Отсутствие IPsec

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

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

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

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

Эта спецификация оъединяет раннюю работу по инкапсуляции MPLS в IP, выполненную Tom Worster, Paul Doolan, Yasuhiro Katsube, Tom K. Johnson, Andrew G. Malis и Rick Wilder, с ранней работой по инкапсуляции MPLS в GRE, выполненной Yakov Rekhter, Daniel Tappan и Eric Rosen. Авторы благодарят своих предшественников за их вклад.

Множество людей, включая Rahul Aggarwal, Scott Bradner, Alex Conta, Mark Duffy, Francois Le Feucheur, Allison Mankin, Thomas Narten, Pekka Savola, Alex Zinin, представило полезные замечания и поправки к работе.

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

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

[RFC792] Postel, J., «Internet Control Message Protocol», STD 5, RFC 792, September 1981.

[RFC1191] Mogul, J. and S. Deering, «Path MTU discovery», RFC 1191, November 1990.

[RFC1981] McCann, J., Deering, S., and J. Mogul, «Path MTU Discovery for IP version 6», RFC 1981, August 1996.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

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

[RFC2463] Conta, A. and S. Deering, «Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification», RFC 2463, December 1998.

[RFC2473] Conta, A. and S. Deering, «Generic Packet Tunneling in IPv6 Specification», RFC 2473, December 1998.

[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, «Generic Routing Encapsulation (GRE)», RFC 2784, March 2000.

[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, «Multiprotocol Label Switching Architecture», RFC 3031, January 2001.

[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, «MPLS Label Stack Encoding», RFC 3032, January 2001.

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

[RFC2401] Kent, S. and R. Atkinson, «Security Architecture for the Internet Protocol», RFC 24016, November 1998.

[RFC2402] Kent, S. and R. Atkinson, «IP Authentication Header», RFC 24027, November 1998.

[RFC2406] Kent, S. and R. Atkinson, «IP Encapsulating Security Payload (ESP)», RFC 24068, November 1998.

[RFC2409] Harkins, D. and D. Carrel, «The Internet Key Exchange (IKE)», RFC 24099, November 1998.

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, «An Architecture for Differentiated Service», RFC 2475, December 1998.

[RFC2890] Dommety, G., «Key and Sequence Number Extensions to GRE», RFC 2890, September 2000.

[RFC2983] Black, D., «Differentiated Services and Tunnels», RFC 2983, October 2000.

[RFC3260] Grossman, D., «New Terminology and Clarifications for Diffserv», RFC 3260, April 2002.

[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, «Multi-Protocol Label Switching (MPLS) Support of Differentiated Services», RFC 3270, May 2002.

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

Tom Worster

Motorola, Inc.

120 Turnpike Road

Southborough, MA 01772

EMail: tom.worster@motorola.com

Yakov Rekhter

Juniper Networks, Inc.

1194 N. Mathilda Ave.

Sunnyvale, CA 94089

EMail: yakov@juniper.net

Eric Rosen

Cisco Systems, Inc.

1414 Massachusetts Avenue

Boxborough, MA 01719

EMail: erosen@cisco.com

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

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

nmalykh@protocols.ru

Полное заявление авторских прав

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.


1Generic Routing Encapsulation — базовая инкапсуляция маршрутных данных.

2Label Switched Path — путь с коммутацией по меткам.

3Label Switching Router — маршрутизатор с коммутацией по меткам.

4Security Association.

5Заменен RFC 8200. Прим. перев.

6Заменен RFC 4301. Прим. перев.

7Заменен RFC 4302 и RFC 4305. Прим. перев.

8Заменен RFC 4302 и RFC 4305. Прим. перев.

9Заменен RFC 4301. Прим. перев.




RFC 4012 Routing Policy Specification Language next generation (RPSLng)

Network Working Group                                           L. Blunk
Request for Comments: 4012                                 Merit Network
Updates: 2725, 2622                                             J. Damas
Category: Standards Track                    Internet Systems Consortium
                                                               F. Parent
                                                                  Hexago
                                                          A. Robachevsky
                                                                RIPE NCC
                                                              March 2005

 

Язык описания правил маршрутизации следующего поколения (RPSLng)

Routing Policy Specification Language next generation (RPSLng)

PDF

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

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

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

Copyright (C) The Internet Society (2005).

Тезисы

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

Оглавление

Исключено в версии HTML.

1. Введение

В RFC 2622 [1] определен язык RPSL для протоколов индивидуальной (unicast) маршрутизации IPv4 и дано руководство по расширению языка. Кроме того, в RFC 2725 [2] описаны расширения безопасности для RPSL.

В этом документе описаны расширения языка RPSL, преследующие несколько целей:

  • обеспечить расширение RPSL для новых семейств адресов (в частности, для документирования маршрутизации IPv6 и multicast);

  • обеспечить совместимость с прежними версиями и минимизировать влияние на существующие инструменты и процессы в соответствии с рекомендациями раздела 10 в RFC 2622 [1] для расширения RPSL;

  • обеспечить ясность и однозначность — информация RPSL используется как людьми, так и программами;

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

Добавление поддержки IPv6 и групповой адресации в RPSL ведет к появлению четырех разных политик маршрутизации, которые требуется различать в данном документе — IPv4 {unicast|multicast}, Ipv6 {unicast|multicast}).

2. Задание политики маршрутизации для разных семейств адресов

Политика маршрутизации в настоящее время специфицирована в классе aut-num с использованием атрибутов «import:», «export:» и «default:». Иногда важно различать правила для разных семейств адресов, а также правила для индивидуальной и групповой (multicast) маршрутизации.

Хотя синтаксис существующих атрибутов import, export и default можно расширить, это создаст проблемы совместимости с ранними версиями и сделает выражения менее понятными.

С учетом того, что атрибуты import:, export: и default: явно заданы для правил маршрутизации индивидуальных адресов IPv4 и определены в RPSL, здесь вводятся новые мультипротокольные атрибуты (с префиксом mp-), которые описаны ниже.

2.1. Устранение неоднозначностей

К одним и те же партнерским отношениям могут быть привязано более одного атрибута мультипротокольной политики или комбинация мультипротокольных атрибутов (при задании политики для индивидуальной адресации IPv4) и ранее определенных атрибутов политики для индивидуальной адресации IPv4. В таких случаях реализациям следует пользоваться правилом specification-order, определенным в параграфе 6.4 RFC 2622 [1]. Для устранения неоднозначности используется действие, соответствующее первой партнерской спецификации.

2.2. Атрибут словаря afi

В этом параграфе вводится новый атрибут словаря:

Идентификатор семейства адресов <afi>2 представляет собой RPSL-список семейств адресов, для которого следует вычислять данное ввыражение политики маршрутизации. Атрибут <afi> является опциональным в составе мультипротокольных атрибутов, вводимых для класса aut-num. Определен псевдоидентификатор any для более компактного выражения политики.

Возможные значения <afi> перечислены ниже:

ipv4.unicast
ipv4.multicast
ipv4 (эквивалент ipv4.unicast, ipv4.multicast)
ipv6.unicast
ipv6.multicast
ipv6 (эквивалент ipv6.unicast, ipv6.multicast)
any (эквивалент to ipv4, ipv6)
any.unicast (эквивалент ipv4.unicast, ipv6.unicast)
any.multicast (эквивалент ipv4.multicast, ipv6.multicast)

При включении этих значений в атрибуты им должно предшествовать ключевое слово afi.

Список <afi-list> определяется, как одно или множество значений afi, разделенных запятыми.

2.3. Расширения словаря RPSL

Для поддержки адресов IPv6 в атрибуте next-hop rp-attribute, в RPSL добавлен новый тип предопределенного словаря ipv6_address. Определение этого типа дано в параграфе 2.2 RFC 3513 [3].

Атрибут next-hop rp-attribute расширен в словаре следующим образом:

rp-attribute: # следующий маршрутизатор в статическом маршруте
next-hop
operator=(union ipv4_address, ipv6_address, enum[self])

В спецификацию словаря <protocol> добавлено новое значение:

MPBGP

MPBGP трактуется, как BGP4 с мультипротокольными расширениями (его часто называют BGP4+). Обозначение BGP4+ не используется в имени словаря, поскольку спецификация RPSL не допускает использования символа + в именах протоколов.

2.4. Типы IPv6 RPSL

В этом документе упоминаются три новых типа IPv6 RPSL, а именно <ipv6-address>, <ipv6-address-prefix> и <ipv6-address-prefix-range>. Типы <ipv6-address> и <ipv6-address-prefix> определены в параграфах 2.2 и 2.3 RFC 3513 [3]. Тип <ipv6-address-prefix-range> добавляет оператор диапазона к типу <ipv6-address-prefix>. Оператор диапазона определен в разделе 2 RFC 2622 [1].

2.5. mp-import, mp-export, mp-default

В класс aut-num добавлены три новых атрибута:

mp-import:
mp-export:
mp-default:

Эти атрибуты включают спецификацию afi (семейство адресов). Отметим, что спецификация afi не является обязательной. Если afi не задано, предполагается, что правило применимо для всех семейств протоколов — ipv4.unicast, ipv4.multicast, ipv6.unicast и ipv6.multicast. Это является эквивалентом спецификации семейства адресов afi any. Атрибуты mp-import и mp-export имеют базовую спецификацию правил, дополненную более мощной структурированной спецификацией.

Синтаксис для атрибута mp-default и базовой спецификации для атрибутов mp-import и mp-export показан ниже.

Атрибут

Значение

Тип

mp-import

[protocol <protocol-1>] [into <protocol-2>]

[afi <afi-list>]

from <mp-peering-1> [action <action-1>; … <action-N>;]

. . .

from <mp-peering-M> [action <action-1>; … <action-N>;]

accept <mp-filter> [;]

Необязательный, многозначный

mp-export

[protocol <protocol-1>] [into <protocol-2>]

[afi <afi-list>]

to <mp-peering-1> [action <action-1>; … <action-N>;]

. . .

to <mp-peering-M> [action <action-1>; … <action-N>;]

announce <mp-filter> [;]

Необязательный, многозначный

mp-default

[afi <afi-list>] to <mp-peering>

[action <action-1>; … <action-N>;]

[networks <mp-filter>]

Необязательный, многозначный

Правила mp-import и mp-export могут быть структурированными. В соответствии с RFC 2622 [1] структурирование правил рекомендуется только опытным пользователям RPSL. Синтаксис структурированного правила mp-import определен ниже. Отметим, что точка с запятой (;) в конце <import-factor> является обязательным символом, хотя в бесструктурных записях правил этот символ не обязателен. Синтаксис структурированного правила mp-export аналогичен синтаксису атрибута mp-import. Структурированный синтаксис позволяет вносить в правила исключения и уточнения с помощью ключевых слов except (исключить) и refine (улучшить). Более того, исключения и уточнения могут задавать необязательный список afi для ограничения воздействия правила определенным семейством адресов.

Отметим, что определение разрешает последовательность или «каскадирование» уточнений и исключений. В RFC 2622 [1] это некорректно названо «вложенностью» выражений (nested expressions). Синтаксис не разрешает действительно вложенных выражений.

   <import-factor> ::=
        from <mp-peering-1> [action <action-1>; ... <action-M>;]
        . . .
        from <mp-peering-N> [action <action-1>; ... <action-K>;]
        accept <mp-filter>;

   <import-term> :: = import-factor |
        {
        <import-factor-1>
        . . .
        <import-factor-N>
        }

   <import-expression> ::= <import-term> |
        <import-term> EXCEPT <afi-import-expression> |
        <import-term> REFINE <afi-import-expression>

   <afi-import-expression> ::= [afi <afi-list>] <import-expression>

   mp-import: [protocol <protocol-1>] [into <protocol-2>]
        <afi-import-expression>

 

2.5.1. <mp-peering>

<mp-peering> указывает AS (и маршрутизатор, если присутствует) и определяется следующим образом:

<mp-peering> ::= <as-expression> [<mp-router-expression-1>]
   [at <mp-router-expression-2>] | <peering-set-name>

где <as-expression> — выражение из номеров и наборов AS с использованием операторов AND, OR и EXCEPT, а <mp-router-expression> — выражение из адресов маршрутизаторов ipv4-addresses или ipv6-addresses, имен inet-rtr и rtr-set с использованием операторов AND, OR, EXCEPT. Двоичный оператор EXCEPT является оператором исключения (вычитания) множества и имеет такой же приоритет исполнения, как оператор AND. Семантически оператор EXCEPT эквивалентен комбинации AND NOT, т. е. (AS65001 OR AS65002) EXCEPT AS65002 равно AS65001.

2.5.2. <mp-filter>

Выражение фильтра <mp-filter> произведено на основе выражения RPSL <filter>, определенного в параграфе 5.4 RFC 2622 [1]. Фильтр <mp-filter> расширяет выражение <filter>, позволяя указывать префиксы и диапазоны префиксов IPv6. В частности, выражение Address-Prefix Set в <mp-filter> может включать префиксы и диапазоны префиксов IPv4 и IPv6. В остальном <mp-filter> идентично выражению RPSL <filter>. Множества Address-Prefix Set указываются в фигурных скобках {}. Фильтру соответствует множество маршрутов, для которых адресные префиксы получателей входят в указанное множество. Например,

{ 192.0.2.0/24, 2001:0DB8::/32 }
{ 2001:0DB8:0100::/48^+, 2001:0DB8:0200::/48^64 }

2.5.3. Примеры правил

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

В примере

aut-num: AS65534
mp-import: afi any.unicast from AS65001 accept as-foo;
except afi any.unicast {
   from AS65002 accept AS65226;
   } except afi ipv6.unicast {
   from AS65003 accept {2001:0DB8::/32};
}

последний оператор except используется только для индивидуальных адресов IPv6, тогда как остальные выражения для импорта рассчитываются для индивидуальных адресов IPv6 и IPv4.

Проверка выражения правила выполняется путем проверки каждой из его компонент. Проверка peering-sets и filter-sets ограничивается семейством адресов. Такие ограничения могут приводить к NOT ANY <mp-filter> или недействительному <mp-peering> в зависимости от явного или неявного указания семейства адресов. Конфликты с явным или неявным указанием семейства разрешаются в процессе проверки выражения правила. Реализация проверки RPSL может выдавать предупреждения при обнаружении NOT ANY <mp-filter>. Приведенный ниже пример mp-import содержит фильтр <mp-filter>, который при проверке дает NOT ANY.

aut-num: AS65002
mp-import: afi ipv6.unicast from AS65001 accept {192.0.2.0/24}

3. Класс route6

Класс route6 является эквивалентом класса route для IPv6. Как и для класса route, ключ класса route6 задается парой атрибутов route6 и origin. Кроме атрибута route6 класс route6 включает те же атрибуты, которые используются для класса route. Хотя имена атрибутов совпадают, атрибуты inject, components, exports-comps, holes и mnt-routes должны задавать адреса и префиксы IPv6, а не IPv4. Это требование выражается указанием <ipv6-router-expression>, <ipv6-filter> и <ipv6-address-prefix>, как показано ниже. Определение <ipv6-address-prefix> приведено выше. Фильтр <ipv6-filter> связан с <mp-filter>, как описано в параграфе 2.5.2, но может включать только тип <ipv6-address-prefix>. Аналогично, выражение <ipv6-router-expression> связано с <mp-router-expression>, как определено выше в параграфе 2.5.1, но может включать только тип <ipv6-address>.

Атрибут

Значение

Тип

route6

<ipv6-address-prefix>

Обязательный, ключ класса, однозначный

origin

<as-number>

Обязательный, ключ класса, однозначный

member-of

список <route-set-name>

Необязательный, многозначный

inject

[at <ipv6-router-expression>] …

[action <action>]

[upon <condition>]

Необязательный, многозначный

components

[ATOMIC] [[<ipv6-filter>]

[protocol <protocol> <ipv6-filter> …]]

Необязательный, однозначный

aggr-bndry

<as-expression>

Необязательный, однозначный

aggr-mtd

inbound или outbound

[<as-expression>]

Необязательный, однозначный

export-comps

<ipv6-filter>

Необязательный, однозначный

holes

список <ipv6-address-prefix>

Необязательный, многозначный

mnt-lower

список <mntner-name>

Необязательный, многозначный

mnt-routes

список <mntner-name>

[{список <ipv6-address-prefix-range>} или ANY]

Необязательный, многозначный

Пример

route6: 2001:0DB8::/32
origin: AS65001

4. Обновление имеющихся классов для поддержки расширений

4.1. Класс as-set

Класс as-set определяет множество автономных систем (AS), задаваемое путем прямого перечисления, с помощью ссылки на другое множество as-set или с помощью mbrs-by-ref. Важно отметить, что «В контексте, который предполагает множество маршрутов (например, атрибут members в классе route-set), […] множество (as-set) AS-X определяет набор маршрутов, исходящих из автономных систем в составе AS-X.» (параграф 5.3 RFC 2622 [1]).

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

В существующий класс as-set не требуется вносить какие-либо изменения. Значения класса могут фильтроваться по семействам адресов с использованием обычных механизмов фильтрации с целью использования в современных системах маршрутных реестров IRR3.

4.2. Класс route-set

Этот класс служит для задания множества маршрутных префиксов.

Для этого класса определен новый атрибут mp-members, позволяющий задавать диапазоны адресных префиксов IPv4 и IPv6.

Атрибут

Значение

Тип

mp-members

список (<ipv4-address-prefix-range>

или <ipv6-address-prefix-range>

или <route-set-name>

или <route-set-name><range-operator>)

Необязательный, многозначный

Пример

route-set: rs-foo
mp-members: rs-bar
mp-members: 2001:0DB8::/32 # префикс v6
mp-members: 192.0.2.0/24 # префикс v4

4.3. Класс filter-set

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

Атрибут

Значение

Тип

filter-set

<object-name>

Обязательный, ключ класса, однозначный

filter

<filter>

Необязательный, однозначный

mp-filter

<mp-filter>

Необязательный, однозначный

Определение <mp-filter> приведено выше в параграфе 2.5.2. Хотя атрибуты filter: и mp-filter: не являются обязательными (тип optional), выражение filter-set должно включать один из этих двух атрибутов. Реализациям следует отвергать экземпляры, содержащие в одном объекте оба атрибута, поскольку интерпретация таких filter-set становится неопределенной.

4.4. Класс peering-set

Для класса peering-set (множество партнеров) добавлен атрибут mp-peering:.

Атрибут

Значение

Тип

peering-set

<object-name>

Обязательный, ключ класса, однозначный

peering

<peering>

Необязательный, многозначный

mp-peering

<mp-peering>

Необязательный, многозначный

Пример

peering-set: prng-ebgp-peers
mp-peering: AS65002 2001:0DB8::1 at 2001:0DB8::2

Определение <mp-peering> приведено выше в параграфе 2.5.1. Хотя атрибуты peering: и mp-peering: не являются обязательными (тип optional), в peering-set должен присутствовать хотя бы один из этих атрибутов.

4.5. Класс inet-rtr

Для класса inet-rtr добавлены два новых атрибута — interface:, позволяющий определить интерфейсы, включая информацию, ранее содержавшуюся в атрибуте ifaddr:, а тажке поддержку определения туннелей и mp-peer:, который включает и расширяет функциональность существующего атрибута peer:. Синтаксис определения interface: приведен ниже.

Атрибут

Значение

Тип

interface

<ipv4-address> или <ipv6-address>

masklen <mask>

[action <action>]

[tunnel <remote-endpoint-address>,<encapsulation>]

Необязательный, многозначный

Синтаксис позволяет определять естественные интерфейсы IPv4 и IPv6, а также туннели в качестве виртуальных интерфейсов. Без учета поддержки определений туннельных интерфейсов функциональность этого атрибута совпадает с функциональностью атрибута ifaddr:, расширенной поддержкой адресов IPv6.

Синтаксис определения туннельных интерфейсов описан ниже.

<remote-endpoint-address> показывает адрес IPv4 или IPv6 на удаленной стороне туннеля. Семейство адресов должно соответствовать адресу локальной стороны туннеля. <encapsulation> указывает применяемый в туннеле метод инкапсуляции и может принимать одно из двух значений {GRE, IPinIP} (отметим, что версии протокола IP для внутреннего и внешнего заголовков можно определить по контексту интерфейса — например, инкапсуляция IPv6-in-IPv4 будет просто IPinIP). Правила маршрутизации для таких маршрутизаторов следует описывать в подходящих классах (например, aut-num).

Атрибут mp-peer: описан ниже. Он отличается от атрибута peer: лишь поддержкой адресов IPv6.

Атрибут

Значение

Тип

mp-peer

<protocol> <ipv4-address> <options> или

<protocol> <ipv6-address> <options> или

<protocol> <inet-rtr-name> <options> или

<protocol> <rtr-set-name> <options> или

<protocol> <peering-set-name> <options>

Необязательный, многозначный

<protocol> указывает имя протокола, <options> представляет собой список разделенных запятыми опций партнерства для <protocol>, как указано в словаре RPSL.

4.6. Класс rtr-set

Класс rtr-set расширен новым атрибутом mp-members:, который добавляет в прототип members: поддержку адресов IPv6. Атрибут показан ниже.

Атрибут

Значение

Тип

mp-members

список(<inet-rtr-name> или

<rtr-set-name> или

<ipv4-address> или

<ipv6-address>)

Необязательный, многозначный

5. Расширения RFC 2725

В RFC 2725 [2] предложена модель проверки полномочий (authorization) для контроля целостности правил в маршрутных реестрах. Для поддержки этой модели были определены два новых атрибута mnt-routes и mnt-lower.

В RPSLng эти атрибуты расширены для классов route6 и inet6num (см. ниже). Кроме того, синтаксис имеющегося атрибута mnt-routes был изменен для поддержки необязательных списков дапазонов адресных префиксов IPv6 в объектах классов inet6num, route6 и aut-num. Эти списки содержат разделенные запятыми диапазоны префиксов и весь список заключается в фигурные скобки. Для класса aut-num диапазоны префиксов IPv6 могут смешиваться с диапазонами префиксов IPv4. Вместо указания диапазона может также использоваться ключевое слово ANY (любые). Для объектов inet6num и route6 слово ANY указывает все более специфические префиксы по сравнению с префиксом в поле ключа класса. Для класса aut-num слово ANY указывает все префиксы. По умолчанию при отсутствии дополнительных элементов принимается значение ANY. Сокращенное определение класса aut-num с обновленным синтаксисом для атрибута mnt-routes представлено ниже.

Атрибут

Значение

Тип

aut-num

<as-number>

Обязательный, однозначный, ключ класса

mnt-routes

список<mntner-name>

[{список (<ipv6-address-prefix-range> или

<ipv4-address-prefix-range>)} или ANY]

Необязательный, многозначный

Ниже приведен пример использования mnt-routes. Это пример предоставляет MAINT-65001 полномочия создания объектов route6 с исходной AS 65002 для адресных префиксов IPv6 из диапазона 2001:0DB8::/32^+ и объектов route с исходной AS 65002 для префиксов IPv4 из диапазона 192.0.2.0/24^+.

aut-num: AS65002
mnt-routes: MAINT-AS65001 {2001:0DB8::/32^+, 192.0.2.0/24^+}

Отметим, что включение диапазонов префиксов IPv6 в атрибут mnt-routes объектов aut-num может приводить к конфликтам с имеющимися реализациями RPSL, которые поддерживают только диапазоны префиксов IPv4. Однако с учетом малой распространенности таких необязательных списков префиксов было принято решение о целесообразности расширения имеющегося атрибута mnt-routes в классе aut-num, а не создания нового типа атрибута.

Атрибут

Значение

Тип

inet6num

<ipv6-address-prefix>

Обязательный, однозначный, ключ класса

netname

<netname>

Обязательный, однозначный

descr

<free-form>

Обязательный, многозначный

country

<country-code>

Обязательный, многозначный

admin-c

<nic-handle>

Обязательный, многозначный

tech-c

<nic-handle>

Обязательный, многозначный

remarks

<free-form>

Необязательный, многозначный

notify

<email-address>

Необязательный, многозначный

mnt-lower

список <mntner-name>

Необязательный, многозначный

mnt-routes

список <mntner-name>

[{список <ipv6-address-prefix-range>} или ANY]

Необязательный, многозначный

mnt-by

список <mntner-name>

Обязательный, многозначный

changed

<email-address> <date>

Обязательный, многозначный

source

<registry-name>

Обязательный, однозначный

Значение <country-code> должно быть корректным двухсимвольным идентификатором страны ISO 3166. <netname> указывает символьное имя для заданного адресного блока IPv6. Ограничений на резервные прификсы не накладывается. Определения взяты из RIPE Database Reference Manual [4].

5.1. Модель проверки полномочий для объектов route6

Удаление и обновление объектов route6 не отличается от аналогичных операций, описанных в RFC 2725 [2]. Правила создания объектов route6 реплицированы из соответствующих правил для route с RFC 2725 [2] (параграф 9.9).

При добавлении объектов route6 долдны быть выполнены два аутентификационных требования. Аутентификация должна выполняться по методу, указанному в объекте aut-num в соответствии со спецификацией объекта route6 или, при отсутствии подходящего объекта route6, в соответствии с объектом inet6num.

Добавляемый объект представляется с номером AS и префиксом IPv6 в качестве ключа. Если для добавляемого объекта route6 не существует объекта aut-num, добавление будет отвергнуто. Если объект aut-num имеется, представление проверяется на предмет применимости поддерживающих (maintainer). Выполняется поиск для префикса сначала на предмет точного соответствия, а при отсутствии совпадения ищется наиболее длинный префикс, соответствующий указанному. Если поиск дал результат, будет возвращен один или множество объектов route6. Подача должна соответствовать применимому поддерживающему по крайней мере для одного из возвращенных объектов route6. Если при поиске не было возвращено объектов route6, выполняется поиск объекта inet6num, точно соответствующего префиксу, или наиболее специфичного inet6num, который менее специфичен, нежели подаваемый объект route6.

После того, как найден объект aut-num и список объектов route6 или объект inet6num, для этих объектов должна быть выполнена проверка полномочий. Подходящим объектом maintainer будет любой из указанных в атрибутах mnt-routes. Если в объекте присутствует один или несколько атрибутов mnt-routes, атрибуты mnt-by и mnt-lower не принимаются во внимание. При отсутствии а данном объекте атрибутов mnt-routes используется первый из атрибутов mnt-lower (только в случаях, когда данный объект является inet6num и менее специфичен, чем добавляемый объект route6). Если подходящего атрибута mnt-lower не найдено, используется атрибут mnt-by для этого объекта. Аутентификация должна соответствовать одной из проверок полномочий в каждом из двух объектов.

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

Этот документ описывает расширения RFC 2622 [1] и RFC 2725 [2], предназначенные для снятия ограничений, связанных с IPv6 и групповой адресацией. Расширения не создают новых угроз и связанной с безопасностью функциональности.

Хотя предложенные расширения не создают новых угроз, следует отметить, что исходный стандарт RPSL RFC 2622 [1] включал несколько слабых и/или уязвимых механизмов. Во-первых, это схема MAIL-FROM, которую легко обмануть путем подмены адреса отправителя в сообщении электронной почты, во-вторых, схема CRYPT-PW, которая может быть атакована с использованием словарей или перехвата паролей, если объекты RPSL отправляются через незашифрованный канал типа электронной почты, а в-третьих, механизм NONE, который не обеспечивает защиты объектов.

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

Авторы благодарят всех участников связанных с этим документом обсуждения и, в частности, Ekaterina Petrusha за ценные замечания и предложения. Shane Kerr, Engin Gunduz, Marc Blanchet и David Kessens внесли множество конструктивных предложений, а с Cengiz Alaettinoglu связано все, что относится к RPSL.

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

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

[1] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, «Routing Policy Specification Language (RPSL)», RFC 2622, June 1999.

[2] Villamizar, C., Alaettinoglu, C., Meyer, D., and S. Murphy, «Routing Policy System Security», RFC 2725, December 1999.

[3] Hinden, R. and S. Deering, «Internet Protocol Version 6 (IPv6) Addressing Architecture», RFC 35134, April 2003.

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

[4] Damas, J. and A. Robachevsky, «RIPE Database Reference Manual», August 2002.

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

Larry Blunk

Merit Network

EMail: ljb@merit.edu

Joao Damas

Internet Systems Consortium

EMail: Joao_Damas@isc.org

Florent Parent

Hexago

EMail: Florent.Parent@hexago.com

Andrei Robachevsky

RIPE NCC

EMail: andrei@ripe.net

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

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

nmalykh@gmail.com


Полное заявление авторских прав

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF’s procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1Routing Policy Specification Language — язык описания правил маршрутизации.

2Address Family Identifier.

3Internet Routing Registry.

4Документ признан устаревшим и заменен RFC 4291. Прим. перев.