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

Network Working Group                                          A. Farrel
Request for Comments: 4655                            Old Dog Consulting
Category: Informational                                    J.-P. Vasseur
                                                     Cisco Systems, Inc.
                                                                  J. Ash
                                                                    AT&T
                                                             August 2006

A Path Computation Element (PCE)-Based Architecture

Архитектура на основе элементов расчёта пути

PDF

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

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

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

Copyright (C) The Internet Society (2006).

Аннотация

Расчёт пути на основе ограничений является фундаментальным компонентом систем организации трафика, таких как сети с многопротокольной коммутацией по меткам (Multiprotocol Label Switching или MPLS) и обобщённой MPLS (Generalized Multiprotocol Label Switching или GMPLS). Расчёт пути в больших, многодоменных, включающих множество регионов и уровней сетях является сложным и может потребовать специальных вычислительных компонентов и кооперации между разными доменами сети. Этот документ задаёт архитектуру для модели, основанной на элементах расчёта пути (Path Computation Element или PCE), для решения этой задачи. Документ не является попыткой подробного описания всех компонентов архитектуры, а описывает набор блоков архитектуры PCE, из которых можно построить решения.

1. Введение

Расчёт пути на основе ограничений является фундаментальным компонентом систем организации трафика в сетях MPLS [RFC3209] и GMPLS [RFC3473]. В [RFC2702] описаны требования к организации трафика в сетях MPLS, а в [RFC4105] и [RFC4216] для сред с обменом между областями и AS, соответственно.

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

Документ описывает набор блоков архитектуры PCE, из которых можно построить решения. Например, рассматриваются основанные на PCE реализации, включая составной, внешний и множественный расчёт пути PCE. Кроме того, рассматриваются архитектурные соображения, включая централизованный и распределенный расчёт, синхронизацию, обнаружение PCE и распределение нагрузки между ними, обнаружение живучести PCE, взаимодействие между клиентами расчёта пути (Path Computation Client или PCC) и PCE (коммуникации PCC-PCE) и между самими PCE, синхронизация баз данных организации трафика (Traffic Engineering Database или TED), PCE с учётом и без учёта состояния, мониторинга, правила и конфиденциальность, а также показатели оценки.

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

2. Термины

CSPF

Constraint-based Shortest Path First — кратчайший путь на основе ограничений.

LER

Label Edge Router — граничный маршрутизатор по меткам.

LSDB

Link State Database — база данных о состоянии каналов.

LSP

Label Switched Path — путь с коммутацией по меткам.

LSR

Label Switching Router — маршрутизатор с коммутацией по меткам.

PCC

Path Computation Client — клиент расчёта пути. Любое клиентское приложение, запрашивающее расчёт пути элементом PCE.

PCE

Path Computation Element — элемент расчёта пути. Любая сущность (компонент, приложение или узел сети), способная рассчитывать сетевой путь или маршрут на основе графа сети и применения расчётных ограничений (см. раздел 3).

TED

Traffic Engineering Database — база данных организации трафика, содержащая сведения о топологии и ресурсах домена. TED может получать сведения от расширений протоколов внутренней маршрутизации (Interior Gateway Protocol или IGP) и иных источников.

TE LSP

Traffic Engineering MPLS Label Switched Path — путь организации трафика с коммутацией по меткам MPLS.

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

Элемент расчёта пути (PCE) — это сущность, способная вычислять сетевой пути или маршрут по графу сети с применением расчётных ограничений в этом процессе. PCE — это приложение, которое может размещаться в узле сети, компоненте, сервере вне сети и т. п. Например, PCE может рассчитывать путь TE LSP, оперируя базой TED с учётом пропускной способности и иных ограничений, применимы к запросу услуг TE LSP.

Доменом считается любой набор элементов сети с единым управлением адресами и общей ответственностью за расчёт пути. Примера доменов включают области (area) IGP, автономные системы (Autonomous System или AS), множество AS внутри сети сервис-провайдера. Домен ответственности за расчёт пути может быть также субдоменом области или AS.

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

1. Расчёт пути может выполняться в контексте домена, между доменами и между уровнями.

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

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

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

2. Расчёт с одним или множеством PCE.

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

   2. При расчёте пути с множеством PCE применяется несколько элементов для расчёте пути в домене.

3. Централизованная и распределенная модель.

   1. Централизованной называют модель, где все пути в домене рассчитываются одним элементом PCE.

   2. Распределенной называют модель расчётов, где пути в домене вычисляются множеством PCE.

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

   Из этих определений следует, что централизованная модель использует расчёт пути с одним PCE. Однако в распределённой модели может применяться расчёт на одном или нескольких PCE. Централизованной модели, использующей расчёт на нескольких PCE.

4. PCE может (не обязательно) размещаться на головной стороне (head-end) пути. Например, традиционным внутридоменным решением является выполнение расчётов головным LSR из MPLS TE LSP, который в этом случае включает PCE. Имеются решения, где в расчёте пути должны участвовать другие узлы (например, нестрогие интервалы — hop), что делает их самостоятельными PCE. Возможен расчёт пути элементом PCE, физически не входящем в рассчитываемый путь.

5. Рассчитанный PCE путь может быть явным (полный путь от начала до получателя с включением строго списка узлов) или строгим/нестрогим (strict/loose), т. е. содержащим комбинацию строгих и нестрогих узлов (hop) хотя бы с одним нестрогим узлом, представляющим получателя, где узел может быть абстракцией (например, AS).

6. Модель расчёта путей на основе PCE не претендует на исключительность и может применяться в сочетании с другими моделями расчётов. Например путь TE LSP между AS может рассчитываться по модели PCE в некоторых AS и иными средствами (без PCE) — в других. Кроме того, для разных TE LSP могут применяться разные модели расчёта пути.

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

4. Мотивы разработки архитектуры на основе PCE

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

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

4.1. Требования к ресурсам CPU

Во многих ситуациях расчёт пути может требовать значительных ресурсов CPU, например для:

• размещения набора TE LSP в домене для оптимизации целевой функции (например, наибольшего снижения максимальной загрузки канала);

• расчёта пути по множеству критериев (например, задержка и загрузка канала, учёт возможностей коммутации, свойства адаптации и оптические ограничения в оптической сети GMPLS);

• расчёт деревьев «один со многими» (Point to Multipoint, дерево Steiner) с минимальной стоимостью.

В таких случаях для некоторых маршрутизаторов может оказаться невозможным или нежелательным выполнение расчёта путей из ограничений CPU, и желательно «выгрузить» (off-load) такие расчёты в другие PCE, которые могут быть маршрутизаторами или выделенными серверами PCE.

4.2. Частичная видимость

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

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

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

4.3. Отсутствие TED или использование IGP без TE

База данных организации трафика (TED) может сильно истощать ресурсы узла сети (например, граничного маршрутизатора или LER). Для поддержки TED может потребоваться много памяти и ощутимая загрузка CPU. В таких случаях имеет смысл использовать PCE на отдельном узле для организации и поддержки TED и сделать его доступным для расчёта путей.

Протоколов IGP, работающий в некоторых сетях, недостаточно для создания полной базы TED. Например, в сети может работать OSPF/IS-IS без расширений OSPF-TE/ISIS-TE или часть маршрутизаторов сети может не поддерживать расширения TE. В таких случаях для успешного расчёта путей через сеть база TED должна создаваться или дополняться с помощью действий по настройке и обновляться по мере резервирования или освобождения ресурсов сети. Такую базу TED можно распределить по маршрутизаторам, которым нужно рассчитывать пути, или поддерживать централизованно (на другом узле с поддержкой PCE) для централизованных расчётов.

4.4. Узел вне домена маршрутизации

LER может не входить в домен маршрутизации административным причинам, например, при подключении граничного маршрутизатора клиента (customer-edge или CE) к граничному маршрутизатору провайдера (provider-edge или PE) в контексте MPLS VPN [RFC4364], когда желательно обеспечить путь TE LSP от CE к CE. В таких случаях предполагается решение, не включающее расчёт на входном маршрутизаторе (головной TE LSP, CE) и не полагающееся на настройку статических нестрогих узлов. Оптимальный кратчайший путь при этом не гарантируется. Помочь может использование отдельного PCE, который в этом случае может обеспечивать путь с нестрогими узлами.

4.5. Элемент сети без плоскости управления и возможности маршрутизации

В унаследованных оптических сетях элементы сети зачастую не имеют плоскости управления и возможности маршрутизации, а имеют лишь плоскость данных и все кросс-соединения выполняются в плоскости администрирования (management). В таких случаях желательно запускать расчёт пути на PCE и передавать команды кросс-соединений каждому узлу на рассчитанном пути. Таким образом, PCC будет элементом плоскости администрирования, возможно входящим в систему управления сетью (Network Management System или NMS) или систему поддержки операций (Operations Support System или OSS). Этот сценарий важен для оптических сетей с поддержкой автоматической коммутации (Automatically Switched Optical Network или ASON) и может также применяться для взаимодействия между сетями с поддержкой GMPLS и без такой поддержки.

4.6. Расчёт резервного пути для защиты пропускной способности

PCE может служить для расчёта резервных путей в контексте защиты с с быстрой перемаршрутизацией TE LSP. В этой модели все резервные TE LSP, защищающие данный объект, рассчитываются координированно элементом PCE. Это позволяет полностью распределять пропускную способность между резервными туннелями, защищающими независимые элементы, избегая при этом каких-либо расширений сигнализации TE LSP. Здесь применимы централизованные и распределенные модели расчёта. В распределенном случае каждый LSR может быть PCE для расчёта путей резервных туннелей с целью защиты от отказов каналов или узлов соседней сети.

4.7. Многоуровневые сети

Сеть серверного уровня с одним средством коммутации может поддерживать несколько сетей с другим средством (более тонкой) коммутации. Например, сеть с мультиплексированием по времени (Time-Division Multiplexing или TDM) может предоставлять связность для сетей клиентского уровня, таких как IP, MPLS, L2 [MLN].

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

Разные сети клиентского и серверного уровня могут считаться различными областями расчёта путей в домене PCE, поэтому архитектура PCE полезна для обеспечения расчёта путей из одной сети клиентского уровня в другую через сеть серверного уровня. В этом случае PCE отвечают за решение проблемы адресных пространств, обработку различий в правилах и параметрах управления между сетями. Отметим, что из-за различий в гранулярности пропускной способности связность через сеть серверного уровня может обеспечиваться виртуальными каналами TE или смежностью при пересылке (Forwarding Adjacency) — PCE может предоставить точку управления, отвечающую за решение о предоставлении новых каналов TE или смежности при пересылке через сеть серверного уровня.

4.8. Правила выбора пути

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

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

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

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

4.9. Негативные аспекты

4.9.1. Internet в целом

PCE не рассматривается решением для всей сети Internet, т. е. применимость PCE ограничена набором доменов с известными взаимоотношениями. Это похоже на партнерское (пиринговое) взаимодействие сервис-провайдеров.

4.9.2. Гарантии организации TE LSP

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

Пакетная обработка запросов на расчёт, время отката (back-off), расчёт дополнительных путей и возвратный сигнал (crankback) могут помочь при решении таких проблем, а PCE может повысить шансы на успех при организации TE LSP. Однако один централизованный PCE не представляется решением, гарантирующим организацию TE LSP, поскольку сохраняются возможные отказы в сети или борьба за ресурсы, когда централизованная база TED не может полностью представить текущее (в реальном масштабе времени) состояние сети.

5. Обзор архитектуры на основе PCE

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

5.1. Композитный узел PCE

На рисунке 1 показаны компоненты типового композитного узла PCE (т. е. маршрутизатора, реализующего функции PCE), реализующего расчёт путей. Для обмена сведениями TE, на которых основана база TED, служит протокол маршрутизации. Запросы услуг предоставления TE LSP принимаются узлом и преобразуются в сигнальные запросы, но для преобразования может потребоваться расчёт пути, который запрашивается у PCE. PCE работает с базой TED в соответствии с локальной политикой для получения отклика с запрошенным путём.

          ---------------
         |   ---------   | Протокол  ----------
         |  |         |  |маршрутиз.|          |
         |  |   TED   |<-+----------+->        |
         |  |         |  |          |          |
         |   ---------   |          |          |
         |      |        |          |          |
         |      | Ввод   |          |          |
         |      v        |          |          |
         |   ---------   |          |          |
         |  |         |  |          | Смежный  |
         |  |   PCE   |  |          |   узел   |
         |  |         |  |          |          |
         |   ---------   |          |          |
         |      ^        |          |          |
         |      |Запрос- |          |          |
         |      |отклик  |          |          |
         |      v        |          |          |
         |   ---------   |          |          |
  Запрос |  |         |  | Протокол |          |
  услуги |  | Машина  |  | сигнализ.|          |
   ------+->| сигналов|<-+----------+->        |
         |  |         |  |          |          |
         |   ---------   |           ----------
          ---------------

Рисунок . Композитный узел PCE.

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

5.2. Внешний PCE

На рисунке 2 показан PCE, являющийся внешним для запрашивающего элемента сети. Запрос услуг получает головной узел, который перед возможностью инициировать сигнализацию делает запрос внешнему PCE на расчёт пути. PCE использует TED в соответствии с локальной политикой как входные данные для расчёта и возврата отклика.

         ----------
        |  -----   |
        | | TED |<-+----------->
        |  -----   |  Механизм синхронизации TED 
        |    |     |  (например, протокол маршрутизации)
        |    |     |
        |    v     |
        |  -----   |
        | | PCE |  |
        |  -----   |
         ----------
             ^
             | Запрос-
             | отклик
             v
Запрос   ----------  Сигнальный  ----------
услуги  | Головной |  протокол  | Смежный  |
   ---->|   узел   |<---------->|   узел   |
         ----------              ----------

Рисунок . Внешний узел PCE.

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

5.3. Расчёт пути с несколькими PCE

На рисунке 3 показано, как на пути сигнальной службы может выполняться несколько расчётов пути на PCE. Как и в предыдущем примере головной PCC подаёт запрос к внешнему PCE, но возвращается частичный путь и следующий элемент сети должен выполнить дополнительный расчёт. Это может происходить в тех случаях, когда возвращённый путь не достигает предусмотренного адресата или рассчитанный путь является нестрогим (loose). Нисходящий элемент сети обращается к другому PCE для определения последующих интервалов (hop) пути. В этом случае все решения политики принимаются независимо на каждом PCE на основе сведений от PCC.

Отметим, что любой или оба PCE в этом случае могут быть композитными как в параграфе 5.1.

         ----------           ----------
        |          |         |          |
        |   PCE    |         |   PCE    |
        |          |         |          |
        |   -----  |         |   -----  |
        |  | TED | |         |  | TED | |
        |   -----  |         |   -----  |
         ----------           ----------
             ^                     ^
             | Запрос-             | Запрос-
             | отклик              | отклик
             v                     v
Запрос   -------- Сигнальный  ------------ Сигнальный  ------------
услуги  |Головной| протокол  |Промежуточн.| протокол  |Промежуточн.|
   ---->|  узел  |<--------->|    узел    |<--------->|    узел    |
         --------             ------------             ------------

Рисунок . Расчёт пути с несколькими PCE.

5.4. Расчёт пути с несколькими взаимодействующими PCE

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

          ----------                                      ----------
         |          |     Запрос-отклик между PCE       |          |
         |   PCE    |<--------------------------------->|   PCE    |
         |          |                                   |          |
         |   -----  |                                   |   -----  |
         |  | TED | |                                   |  | TED | |
         |   -----  |                                   |   -----  |
          ----------                                     ----------
              ^
              | Запрос-
              | отклик 
              v
Запрос   ---------- Сигнальный   ---------- Сигнальный   ----------
услуги  | Головной | протокол   | Смежный  | протокол   | Смежный  |
   ---->|  узел    |<---------->|   узел   |<---------->|   узел   |
         ----------              ----------              ----------

Рисунок . Расчёт пути с множеством взаимодействующих PCE.

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

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

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

5.5. Основанное на системе управления использование PCE

Следует отметить, что PCC не обязательно является LSR. Например, на рисунке 5 система NMS предоставляет головному LSR полностью рассчитанный путь для TE LSP, который тот организует через сигнализацию. NMS использует механизм плоскости управления для отправки запроса и кодирует данные с представлением в форме модуля TE MIB [RFC3812]. NMS создаёт явный путь, которые предоставляется головному LSR, используя сведения от оператора и обращаясь к PCE, который возвращает путь для использования системой NMS. Хотя на рисунке 5 элемент PCE показан как удалённый от NMS, он может размещаться и вместе с NMS.

                          -----------
                         |   -----   |
     Запрос              |  | TED |<-+----------->
     услуг               |   -----   |  Механизм синхронизации 
        |                |     |     |  TED (например, протокол
        v                |     |     |  маршрутизации)
  -------------  Запрос- |     v     |
 |             | отклик  |   -----   |
 |     NMS     |<--------+> | PCE |  |
 |             |         |   -----   |
  -------------           -----------
 Запрос  |
 услуг   |
         v
     ----------  Сигнальный  ----------
    | Головной | протокол   | Смежный  |
    |  узел    |<---------->|   узел   |
     ----------              ----------

Рисунок . Управление на основе использования PCE.

5.6. Области стандартизации

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

• Взаимоействие между PCC и PCE, а также парой PCE, включая обмен сведениями о правилах.

• Требования к расширению имеющихся протоколов маршрутизации и сигнализации для поддержки обнаружения PCE и сигнализации о междоменных путях.

• Определение показателей для оченки качества, расширяемости, отзывчивости, отказоустойчивости и поддержки правил в моделях расчёта путей.

• Модули MIB, относящиеся к коммуникационным протоколам, расширениям маршрутизации и сигнализации, показателям и данным мониторинга PCE.

6. Архитектурные соображения для PCE

В этом разделе приведён список архитектурых компонентов PCE. Рассмотрение деталей конкретных реализаций PCE (конечных автоматов или алгоритмов) выходит за рамки этого документа. Отметим, что основанный на PCE расчёт путей никак не влияет на использование рассчитанных путей. Например, использование PCE не меняет способов сигнализации, поддержки и уничтожения TE LSP и относится лишь к аспектам расчёта таких TE LSP.

Этот раздел даёт архитектурное представление PCE, т. е. описывает имеющиеся компоненты и их взаимодействие. Отметим, что архитектурную модель (в частности, функциональную) разные компоненты системы PCE могут воспринимать по-разному. Например, PCC не знает, консультирует ли элемент PCE другие PCE (взгляд PCC на архитектуру PCE рассматривается в разделе 7).

6.1. Централизованный расчёт

В модели централизованного расчёта что все расчёты путей для данного домена выполняются одним централизованным PCE. Это может быть выделенный сервер (например, внешний узел PCE) или назначенный маршрутизатор (например, композитный узел PCE). В этой модели все PCC домена будут направлять свои запросы расчёта пути центральному PCE. Хотя доменом в этом контексте может быть область IGP или AS, им может быть группа узлов сети, определяемая их зависимостью от PCE.

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

6.2. Распределённый расчёт

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

Зачастую данный путь полностью рассчитывает один элемент PCE. Например, это обычно применяется в случае MPLS TE внутри одной области IGP, где выходной (LSR/композитный) узел PCE отвечает за расчёт пути или взаимодействие с внешним PCE. Расчёт пути на нескольких PCE предполагает участие в одном расчёте более одного PCE. Примером может служить преобразование нестрогих интервалов (loose hop), выполняемое транзитными узлами PCE (LSR/композитный) на пути MPLS TE LSP. Другим примером является использование нескольких взаимодействующих PCE для расчёта пути одного TE LSP черз несколько доменов.

6.3. Синхронизация

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

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

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

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

Желательно добавлять в протокол PCC-PCE параметр для запроса предоставления элементом PCE набора вариантов пути для использования PCC, если организация TE LSP по основному пути не удалась. Хотя дополнительные пути не всегда ведут к успеху при отказе основного, включение их в отклик PCE может сокращать издержки по сравнению с повторением узлом PCC отдельных запросов при возникновении необходимости. Это применяется в некоторых реализациях CSPF.

6.4. Обнаружение PCE и распределение нагрузки между ними

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

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

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

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

Некоторые возможности PCE, которые могут настраиваться или анонсироваться, включают:

• наборы ограничений, которые элемент может учитывать (разнообразие, SRLG¹, оптические нарушения, непрерывность длины волны и т. п.);

• расчётные возможности (например, объем вычислений за секунду);

• число уровней возможности коммутации с их конкретизацией;

• число критериев выбора пути с их конкретизацией;

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

• возможности расчёта деревьев P2MP с их конкретизацией;

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

Эти сведения помогут PCC выбрать элемент PCE для использования.

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

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

6.5. Обнаружение живучести PCE

Возможность определить живучесть PCE является обязательным элементом архитектуры и может быть достигнута разными способами. Если для обнаружения PCE применяется какая-то форма анонсов (например, через расширения IGP), предполагается, что живучесть PCE будет определяться из анонсов состояния (например, IGP LSA/LSP).

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

6.6. Расчёты PCC-PCE и PCE-PCE

При выборе узлом PCC элемента PCE, не являющегося локальным для PCC, нужен протокол запрос-отклик для передачи запросов PCC на расчёт пути элементу PCE и возврата от того откликов. Требования безопасности и последствия применения такого протокола рассматриваются в разделе 10.

Запрос расчёта пути может включать многочисленные требования, включая:

• источник и адресат для пути;

• желаемую пропускную способность и другие параметры качества обслуживания (Quality of Service или QoS);

• ресурсы, их связанность (affinitiy), SRLG для использования или исключения;

• требуемое число несвязанных (disjoint) путей и приемлемую близость путей;

• степень отказоустойчивости, надёжности и прочности ресурсов пути;

• связанные с правилами сведения.

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

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

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

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

В архитектуре не принимается каких-либо допущений об использовании общего протокола для взаимодействий PCC-PCE и PCE-PCE.

6.7. Синхронизация PCE TED

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

1. Участие IGP в распространении сведений TE. Стандартным способом распространения информации TE внутри области IGP является использование расширений IGP [RFC3630, RFC3784²]. Этот механизм позволяет участвующим узлам создать базу TED и служит стандартным методом, например, внутри одной области сети MPLS или GMPLS. Узел, где размещается PCE, может собирать сведения TE таким способом, поддерживая хотя бы одну маршрутную смежность с маршрутизатором в домене. Узел PCE может быть смежным или несмежным с маршрутизатором (через тот или иной метод туннелирования). Метод обеспечивает механизм, гарантирующий эффективную синхронизацию TED с состоянием сети и является обычным вариантом, например, при размещении PCE совместно с маршрутизаторами LSR в сети MPLS или GMPLS.

2. Синхронизация TED по отдельному каналу. Элементу PCE может быть неудобно или невозможно участвовать в IGP одного или нескольких доменов (например, доменов очень много, участие в IGP нежелательно или в некоторых доменах нет IGP с поддержкой TE). В этом случае может потребоваться определение некого механизма, позволяющего узлу PCE извлекать TED из каждого домена. Механизм может быть инкрементным (как IGP в п. 1) или использовать передачу полной базу TED. Второй вариант может сильно ограничивать возможность синхронизации TED, что может приводить к росту частоты отказов при расчёте путей или возврату неоптимальных путей. Следует также учитывать влияние распределения TED на сеть и узел в домене, которому поручено распространять базу данных. Это особенно важно при частых изменениях в сети.

3. База TED может включать сведения, полученные из других источников (не IGP). Например, данные о правилах использования каналов могут быть заданы оператором. При расчёте путём может использоваться более широкий набор сведений, включающий данные о TE LSP, предоставляемых в сети. Эти данные могут включать маршруты TE LSP, зарезервированную пропускную способность и измеренный объем трафика через TE LSP. Такие сведения о TE LSP могут улучшить (повторную) оптимизацию TE LSP для обеспечения (ре)оптимизации «всей сети» и учесть флуктуации трафика. Подробные сведения о TE LSP могут также облегчить реконфигурацию топологии виртуальной сети (Virtual Network Topology или VNT) [MLN], где TE LSP нижележащего уровня (например, оптические пути) обеспечивают каналы TE для использования вышележащим уровнем, поскольку такая реконфигурация является также проблемой «всей сети».

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

Отметим также, что PCE может иметь доступ лишь к части TED, например, в случае расчёта междоменного пути, где каждый домен может управляться своей сущностью. В таких случаях у каждого PCE может быть доступ к части TED, а между PCE могут применяться кооперативные методы для расчёта сквозного пути без требования обработки каким-либо PCE полной базы TED относящейся к набору доменов в рассматриваемом TE LSP.

6.8. PCE с учётом и без учёта состояния

PCE может учитывать или не учитывать состояния. В первом случае имеется строгая синхронизация PCE не только с набором состояний сети (топология и сведения о ресурсах), но и с набором рассчитанных путей и зарезервированных ресурсов, используемых в сети. Иными словами, PCE использует при обработке запросов сведения из базы TED, а также информацию о существующих в сети путях (например, TE LSP). Хотя это позволяет рассчитать оптимальный путь и повышает вероятность успешного расчёта, для PCE с учётом состояния требуются надёжные механизмы синхронизации, поддержка большого объёма данных/состояний (например, полная связность TE LSP) и могут возникать значительные издержки в плоскости управления. Например, при наличии в домене одного PCE все расчёты TE LSP будут выполняться этим PCE, который может отслеживать все имеющиеся TE LSP и оставаться синхронизированным (все изменения состояний TE LSP должны отслеживаться элементом PCE). Для этого могут потребоваться значительные ресурсы плоскости управления. При наличии в сети множества PCE расчёт TE LSP и сведения о них распределяются между PCE, что ведёт и к распределению требуемых для расчётов ресурсов. Однако задачи синхронизации, рассмотренные в параграфе 6.7 сохраняют свою актуальность.

Поддержка базы данных с состояниями является нетривиальной задачей. Тем не менее, в среде с одним централизованным PCE этому элементу сравнительно просто запомнить все рассчитанные TE LSP, факты фактической организации TE LSP (если это можно узнать) и их уничтожения. Синхронизация TED по отдельному каналу также может быть сложной при наличии множества PCE в распределенной модели расчётов, при этом могут возникать «гонки» между PCE, проблемы расширяемости и т. п. Даже при наличии у PCE подробных сведений обо всех путях, приоритетах и уровнях учёт этих данных при расчёте пути может быть очень сложным. PCE могут синхронизировать состояния, взаимодействуя между собой, но при создании TE LSP с помощью распределенных по множеству PCE вычислений проблемы синхронизации и предотвращение гонки всё более усложняются.

Знание наличия и маршрутизации TE LSP полезно для поддержки таких приложений, как размещение высокоприоритетного TE LSP в переполненной сети так, чтобы он вытеснял как можно меньше других TE LSP (проблема минимальных возмущений). Отметим, что вытеснение на основе минимального числа каналов может не обеспечивать минимального числа нарушаемых TE LSP. Ещё одно применение связано с созданием и поддержкой топологии виртуальной сети [MLN]. Полезно также понимать, какие ещё TE LSP имеются в сети, чтобы решить как управлять смежностями по пересылке, которые имеются или должны быть созданы. Оценка издержек и преимуществ расчётов PCE с учётом состояний будет полезна для сопоставления выгод при расчёте путей с дополнительной загрузкой сети и расчётных ресурсов.

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

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

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

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

Мониторинг PCE, несомненно, имеет важнейшее значение в любой архитектуре PCE и должен включать сбор переменных, связанных с состоянием и работой PCE. Например, требуется понимать, каким способом сохраняется синхронизация TED, с какой скоростью поступают новые запросы и какое время занимает расчёт, какие PCC используют PCE, а также знать операции протокола PCC-PCE.

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

Как указано в [RFC4216], при расчёте TE LSP между провайдерами требуется возможность рассчитать путь с сохранением конфиденциальности между ядрами сетей нескольких сервис-провайдеров. Провайдеру недопустимо раскрывать сведения о своих ресурсах и топологии для поддержки расчёта межпровайдерских путей TE LSP. Таким образом, любое решение архитектуры PCE должно поддерживать возможность возврата частичных путей с помощью нестрогих переходов (например, когда каждый такой переход будет указывать граничный LSR). Это требование не относится к вопросам безопасности и связано с политикой сервис-провайдера. Конфиденциальность, целостность и проверка подлинности сообщений PCC-PCE и PCE-PCE должны обеспечиваться и описаны в разделе 10.

Желательна также возможность расчёта пути по запросу головного PCC с предоставлением этого пути в форме сегментов пути к граничному PCC домена.

6.11. Политика

Политика влияет на многие аспекты архитектуры PCE. Рассматриваются два варианта применения правил:

• в элементах архитектуры (PCC или PCE);

• в связанных с PCE коммуникациях.

Поскольку политика напрямую применима к TE LSP, она является частью сигнального механизма организации TE LSP и не описана здесь. Предполагается, что правила будут применяться в основном локально в рамках каждого PCC и PCE. Однако в этом документе необходимо задать модели политики, которые могут поддерживаться в архитектуре PCE и связанных с PCE коммуникациях. Примеры политики включают:

• выбор элемента PCE клиентом PCC;

• отклонение запросов элементом PCE на основе идентификации запрашивающего PCC;

• выбор пути элементом PCE или применение дополнительных ограничений в расчётах в зависимости от PCC, цели расчёта, времени суток и т. п.

6.11.1. Архитектура политики PCE

Два примера применения компонентов политики в архитектуре PCE показаны на рисунках 6 и 7. Компоненты политики могут также применяться в других конфигурациях PCE, показанных в разделе 5. В каждой конфигурации правила могут рассматриваться до предоставления отклика элементом PCE с возможным обращением к PCC/PCE, получающему отклик. У PCE могут быть локальные правила, влияющие на пути, выбранные по конкретному запросу PCE. Правила могут применяться на основе любых сведений, полученных от PCC.

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

          ------------------------------
         |                  ---------   | Протокол  ----------
         |                 |         |  |маршрутиз.|          |
         |                 |   TED   |<-+----------+->        |
         |                 |         |  |          |          |
         |                  ---------   |          |          |
         |                     |        |          |          |
         |                     | Ввод   |          |          |
         |                     v        |          |          |
         |   ---------      ---------   |          |          |
         |  |Компонент|    |         |  |          | Смежный  |
         |  |политики |--->|   PCE   |  |          |   узел   |
         |  |         |    |         |  |          |          |
         |   ---------      ---------   |          |          |
         |                     ^        |          |          |
         |                     |Запрос- |          |          |
         |                     |отклик  |          |          |
         |                     v        |          |          |
         |                  ---------   |          |          |
 Запрос  |                 |         |  |Сигнальный|          |
 услуги  |                 | Машина  |  | протокол |          |
   ------+---------------->|сигнализ.|<-+----------+->        |
         |                 |         |  |          |          |
         |                  ---------   |           ----------
          ------------------------------

Рисунок . Компонент правил в композитном узле PCE.

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

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

   ------------------                             ------------------
  |                  |  Запрос-отклик между PCE  |                  |
  |       PCE        |<------------------------->|       PCE        |
  |                  |                           |                  |
  | -------   -----  |                           | -------   -----  |
  ||Правила| | TED | |                           ||Правила| | TED | |
  | -------   -----  |                           | -------   -----  |
   ------------------                             ------------------
             ^
             | Запрос-
             | отклик
             v
Запрос  ----------  Сигнальный  ----------  Сигнальный  ----------
услуги | Головной | протокол   | Смежный  | протокол   | Смежный  |
  ---->|  узел    |<---------->|   узел   |<---------->|   узел   |
        ----------              ----------              ----------

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

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

6.11.2. Реализация политики

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

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

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

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

6.11.3. Типы политики

В контексте PCE имеется несколько типов политики, указанных ниже.

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

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

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

6.11.4. Взаимодействие с сигнализацией

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

6.12. Незапрошенные взаимодействия

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

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

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

6.13. Взаимодействие с откликами

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

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

7. Взгляд клиента расчёта пути

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

• Выбор PCE, способного оперативно предоставить рассчитанный путь с учётом заданных ограничений.

• Сколько запросов на расчёт придётся отправить PCC? Будет ли нужный путь рассчитан первым элементом PCE (возможно во взаимодействии с другими PCE), которому отправлен запрос, или клиенту PCC придётся обращаться к другим PCE для заполнения пропусков в пути?

• Сколько ещё расчётов пути потребуется для организации в сети TE LSP?

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

Таким образом, с учётом ограниченного кругозора клиент PCC будет считать расчёт пути несколькими PCE (параграф 5.3) важным и выделит два случая. Первый случай показан на рисунке 3 с последующими запросами расчёта от других PCC на пути TE LSP. Во втором случае головной LSR подаёт несколько запросов на расчёт пути. С другой стороны, PCC не будет знать о расчёте пути несколькими PCE с взаимодействием между ними (параграф 5.4), который он не отличает от простого случая использования внешнего узла PCE (параграф 5.2). Поэтому PCC будет понимать, что модель централизованных расчётов (параграф 6.1) может по-прежнему требовать расчёта пути несколькими PCE, требуя от головного или последующих PCC передавать дополнительные запросы центральному PCE. PCC можно защитить от использования модели распределенных расчётов (параграф 6.2), поскольку первый элемент PCE, к которому клиент обращается, будет взаимодействовать с другими PCE для выполнения полного расчёта и другие запросы не потребуются.

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

8. Оценочные показатели

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

Оптимальность

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

Расширяемость

Влияние маршрутизации, сигнализации TE LSP и расчётных издержек PCE, включая число и размер сообщений (в том числе LSA, отклики (crankback), очереди, механизмы распространения и т. п.).

Распределение нагрузки

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

Расчёт нескольких путей

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

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

Способность повторно оптимизировать TE LSP, включая возможность межуровневого сопоставления при повторной оптимизации на конкретном уровне.

Время расчёта пути

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

Стабильность сети

Способность минимизировать любые нарушения существующего состояния TE при расчёте и организации новых путей TE.

Синхронность

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

Скорость синхронизации

Скорость, с которой обеспечивается синхронизация TED.

Влияние на сеть

Воздействие процесса синхронизации на потоки данных в сети.

Обработка отсутствия пути

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

Правила

Применение правил к взаимодействиям PCC-PCE и PCE-PCE, а также к расчёту путей в соответствии с политикой организации междоменных TE LSP.

Могут учитываться и другие показатели. Оценочные показатели следует применять при рассмотрении определённой архитектуры на основе PCE. Следует оценивать также возможные компромиссы при оптимизации показателей (например, повышение оптимальности пути может влиять на время расчёта).

9. Вопросы управляемости

Архитектура PCE включает несколько элементов, которыми нужно управлять. Управление требуется для самого PCE, а также к его взаимодействию с PCC и другими PCE. Механизмы обнаружения PCE и PCC друг друга также подлежат управлению. Многие из вопросов управляемости уже рассмотрены в других параграфах этого документа.

9.1. Управление работой и правилами

Должна обеспечиваться возможность включать и отключать функцию PCE на элементе PCE, что приведёт к тому, что PCE будет воспринимать или отклонять запросы PCC или даже не получать их. Следует также рассмотреть возможность аккуратного отключения (graceful shutdown) функции PCE, чтобы в контролируемых ситуациях (например, при обновлении программ) PCE не просто «исчезал», а предупреждал своих клиентов PCC, аккуратно обслужив все запросы из очереди (возможно, выполняя, передавая другому PCE или отклоняя их).

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

9.2. Модели данных и информационные модели

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

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

Новые модули MIB следует использовать также для уведомлений о достижении важных порогов или о важных событиях. Необходимо внимательно следить за тем, чтобы сеть не переполнялась уведомлениями простого протокола управления сетью (Simple Network Management Protocol или SNMP). Например, может быть нецелесообразно отправлять уведомление при получении элементом PCE каждого запроса на расчёт пути. В любом случае необходимо обеспечить полный контроль, чтобы уведомления можно было отключить с помощью, например, механизмов, заданных в модуле SNMP-NOTIFICATION-MIB [RFC3413].

9.3. Проверка живучести

В параграфе 6.5 обсуждалась важность способности PCC определять живучесть PCE. Методы взаимодействия PCE-PCC должны позволять PCC проверить живучесть PCE до отправки запроса а также в интервале между отправкой запроса и получением отклика.

Для PCE не так важно знать о живучести PCC и в рамках простой модели запрос-отклик это полезно лишь для:

• получения прогноза о вероятной загрузке PCE в будущем;

• возможности PCE отказаться от обработки полученного запроса.

9.4. Проверка корректности работы

Корректной работой архитектуры PCE можно считать наличие корректной связности «точка-точка» между PCC и PCE, а также достоверность рассчитанных путей. Первый вопрос относится к безопасности, которая может быть усилена путём аутентификации и регистрации событий в журнале с их отслеживанием, как описано в параграфе 9.1. Это может также относиться к маршрутизации для обеспечения связности PCC-PCE.

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

9.5. Требования к другим протоколам и функциональным компонентам

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

• Зависимость от базовых транспортных протоколов

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

• Использование имеющихся протоколов для обнаружения

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

• Влияние на LSR и сигнализацию TE LSP

  Основным примером PCC в этой архитектуре является LSR MPLS или GMPLS. Поэтому нужно уделить внимание управляемости LSR и добавочным ограничениям управляемости сигнальных протоколов TE LSP.

  В дополнение к описанной выше возможности управления PCC нужна настройка LSR, указывающая, будет ли маршрутизатор использовать удалённый PCE (вариантами являются поэтапная маршрутизация или предоставление функции PCE. Вероятно, будет важна способность LSR различать TE LSP, предоставленные сигнальным сообщением от другого LSR, оператором или PCE, а для указанного сигнальным сообщением пути способность увидеть улучшение или расширение пути элементом PCE.

• Использование имеющихся моделей и механизмов политики

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

9.6. Влияние на работу сети

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

Проблему возможных перегрузок в процессе восстановления после отказов можно смягчить за счёт применения рассчитанных заранее схем защиты, таких как быстрая перемаршрутизация (fast reroute).

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

9.7. Другие вопросы

Других вопросов управления не было отмечено.

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

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

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

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

Отметим, что использование нелокального PCE (не размещённого вместе с PCC) создаёт дополнительные проблемы безопасности, из которых наиболее важны:

• перехват запросов или откликов PCE;

• выдача атакующего за PCE или PCC;

• фальсификация сведений TE, правил или возможностей PCE;

• атаки на отказ в обслуживании для коммуникационных механизмов PCE или PCE.

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

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

Авторы выражают искреннюю признательность Arthi Ayyangar, Zafar Ali, Lou Berger, Mohamed Boucadair, Igor Bryskin, Dean Cheng, Vivek Dubey, Kireeti Kompella, Jean-Louis Le Roux, Stephen Morris, Eiji Oki, Dimitri Papadimitriou, Richard Rabbat, Payam Torab, Takao Shimizu, Raymond Zhang (перечислены в алфавитном порядке) за их рецензии и предложения. Lou Berger внёс полезный и детальный вклад в обсуждение правил в этом документе.

Спасибо также Pekka Savola, Russ Housley и Dave Kessens за рецензии и конструктивные дискуссии на финальных этапах публикации.

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

[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O’Dell, M., and J. McManus, «Requirements for Traffic Engineering Over MPLS», RFC 2702, September 1999.

[RFC4364] Rosen, E. and Y. Rekhter, «BGP/MPLS IP Virtual Private Networks (VPNs)», RFC 4364, February 2006.

[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, «RSVP-TE: Extensions to RSVP for LSP Tunnels», RFC 3209, December 2001.

[RFC3630] Katz, D., Kompella, K., and D. Yeung, «Traffic Engineering (TE) Extensions to OSPF Version 2», RFC 3630, September 2003.

[RFC3413] Levi, D., Meyer, P., and B. Stewart, «Simple Network Management Protocol (SNMP) Applications», STD 62, RFC 3413, December 2002.

[RFC3473] Berger, L., «Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions», RFC 3473, January 2003.

[RFC3784] Smit, H. and T. Li, «Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)», RFC 3784, June 2004.

[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, «Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)», RFC 3812, June 2004.

[RFC4105] Le Roux, J.-L., Vasseur, J.-P., and J. Boyle, «Requirements for Inter-Area MPLS Traffic Engineering», RFC 4105, June 2005.

[RFC4216] Zhang, R. and J.-P. Vasseur, «MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements», RFC 4216, November 2005.

[MLN] Shiomoto, K., Papdimitriou, D., Le Roux, J.-L., Vigoureux, M., and D. Brungard, «Requirements for GMPLS-based multi-region and multi-layer networks (MRN/MLN)», Work in Progress³, June 2006.

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

Adrian Farrel

Old Dog Consulting

EMail: adrian@olddog.co.uk

 

Jean-Philippe Vasseur

1414 Massachussetts Avenue

Boxborough, MA 01719

USA

EMail: jpv@cisco.com

 

Jerry Ash

AT&T

Room MT D5-2A01

200 Laurel Avenue

Middletown, NJ 07748,

USA

Phone: (732)-420-4578

Fax: (732)-368-8659

EMail: gash@att.com

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

Copyright (C) The Internet Society (2006).

К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.

Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

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

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.

IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.

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

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

---

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

nmalykh@protokols.ru

---

Заменен RFC 7159.

Network Working Group                                           E. Lewis
Request for Comments: 4592                                       NeuStar
Updates: 1034, 2672                                            July 2006
Category: Standards Track

The Role of Wildcards in the Domain Name System

Роль шаблонов в DNS

PDF

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

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

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

Copyright (C) The Internet Society (2006).

Аннотация

Этот документ обновляет определение шаблонов (wildcard) RFC 1034. Изменено взаимодействие CNAME с шаблонами, исключено условие ошибки, а также изменён текст некоторых определений, важных для шаблонов. Цель заключалась не в изменении шаблонов, а лишь в уточнении определения из RFC 1034.

1. Введение

В параграфах 4.3.2 и 4.3.3 RFC 1034 [RFC1034] описано создание ответов из специальных записей о ресурсах (resource record или RR), называемых шаблонами (wildcard). Определение в RFC 1034 неполно и оказалось путанным. В этом документе описывается создание шаблонов, дополняется их обсуждение и вносятся некоторые правки для устранения несоответствий, приводящих к проблемам функциональной совместимости. Описание не расширяет спектр услуг, предусмотренных исходным определением.

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

Документ посвящён концепции шаблонов, заданной в RFC 1034. Не принимается каких-либо допущений в части дополнительных средств синтеза RRSet и не обсуждаются альтернативы.

1.1. Мотивация

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

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

1.2. Исходное определение

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

Определение термина «шаблон» (wildcard) в параграфе 4.3.3 RFC 1034 приведено ниже.

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

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

Упоминание использования шаблонов при подготовке отклика содержится в п. 3.c параграфа 4.3.2 (Алгоритм) в RFC 1034. В описании алгоритма термин wildcard не применяется и вместо него используется термин «метка *». Часть алгоритма, относящаяся к шаблонам, подробно разбирается в разделе 3 этого документа, а ниже приведён соответствующий фрагмент из параграфа «Алгоритм» в RFC 1034.

3. Если для какой-либо метки сопоставление невозможно (т. е., соответствующей метки не существует), проверяется существование метки «*».

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

1.3. План документа

Документ решает 3 основных задачи:

• определение новых терминов;

• внесение незначительных изменений для исключения противоречивых понятий;

• описание действий при наличии шаблонов в некоторых записях о ресурсах.

1.3.1. Новые термины

Чтобы помочь разобраться, какие записи о ресурсах являются шаблонными, в параграфе 2.1.1 определяются два термина — «метка-звёздочка» (asterisk label) и «шаблонное доменное имя» (wildcard domain name). Для разъяснения роли шаблонов в работе алгоритма сервера имён из параграфа 4.3.2 в RFC 1034 в параграфе 3.3.1 определены термины «источник синтеза» (source of synthesis) и «ближайший включающий» (closest encloser). Совпадение меток (label match) определено в параграфе 3.2.

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

1.3.2. Изменённый текст

Внешне изменено определение существования (existence). Это изменение не будет важно для реализаций и внесено для уточнения описаний. Изменение представлено в параграфе 2.2.3.

Представляется, что параграф 4.3.3 в RFC 1034 запрещает использовать две метки * имени владельца шаблона. Данные документ полностью снимает это ограничение. Изменение и его результаты указаны в параграфе 2.1.3.

Действия в случае, когда источник синтеза владеет CNAME RR, изменены на зеркальные, если в точности совпадающее имя владеет CNAME RR. Это дополняет п.3.c в параграфе 4.3.2 RFC 1034 и приведено в параграфе 3.3.3.

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

1.3.3. Рассмотрение специальных типов

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

1.4. Терминология стандартов

В этом документе не применяются уровни требований из [RFC2119]. Цитаты из RFC 1034 выделены смещением текста вправо. Ссылки на параграф 4.3.2 указывают параграф 4.3.2 Алгоритм в RFC 1034.

2. Синтаксис шаблонов

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

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

2.1. Идентификация шаблонов

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

2.1.1. Шаблонные доменные имена и метка *

Шаблонное доменное имя определено как имеющее начальную (левую или наименее значимую) метку в формате

      0000 0001 0010 1010 (двоичный) = 0x01 0x2a (шестнадцатеричный)

Первый октет — это обычный тип и размер метки (1), а второй содержит код ASCII [RFC20] для символа *. Описательным именем такой метки служит asterisk label (метка-звёздочка).

В RFC 1034 шаблон определён как «запись о ресурсе, принадлежащая шаблонному доменному имени».

2.1.2. * и другие символы

Никакие значения меток, кроме указанного в параграфе 2.1.1, не применяются в качестве метки-звёздочки и имена меток, начинающиеся с другого символа, не могут быть именем шаблона. Такие метки, как the* и **, не являются метками-звёздочками и не могут служить началом шаблонных доменных имён.

2.1.3. Нетерминальные шаблонные доменные имена

В параграфе 4.3.3 сказано:

… Имя владельца шаблонной RR имеет форму *.<anydomain>, где <anydomain> может представлять собой любое доменное имя. В <anydomain> не следует включать другие метки «*» …

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

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

Шаблонные доменные имена могут иметь субдомены. Не требуется проверять субдомены на предмет наличия ещё одного символа * в каком-либо субдомене.

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

2.2. Правила существования

В определении шаблонов применяется понятие существования доменных имён. В параграфе 4.3.3 RFC 1034 сказано:

Шаблоны RR не применимы в тех случаях, когда:

• …

• имя в запросе или имя между шаблонным доменом и именем в запросе определённо существует …

Поэтому понятие существования важно для понимания шаблонов. К сожалению, определение существования в RFC 1034 нечетко, поэтому в параграфах 2.2.2 и 2.2.3 оно рассматривается ещё раз.

2.2.1. Пример

Для иллюстрации понятия существования рассмотрим приведённую ниже полную зону.

      $ORIGIN example.
      example.                 3600 IN  SOA   <SOA RDATA>
      example.                 3600     NS    ns.example.com.
      example.                 3600     NS    ns.example.net.
      *.example.               3600     TXT   "this is a wildcard"
      *.example.               3600     MX    10 host1.example.
      sub.*.example.           3600     TXT   "this is not a wildcard"
      host1.example.           3600     A     192.0.2.1
      _ssh._tcp.host1.example. 3600     SRV   <SRV RDATA>
      _ssh._tcp.host2.example. 3600     SRV   <SRV RDATA>
      subdel.example.          3600     NS    ns.example.com.
      subdel.example.          3600     NS    ns.example.net.

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

                     |
     -------------example------------
    /           /         \          \
   /           /           \          \
  /           /             \          \
 *          host1          host2      subdel
 |            |             |
 |            |             |
sub         _tcp          _tcp
              |             |
              |             |
            _ssh          _ssh

Приведённые ниже запросы синтезированы из одного из шаблонов в зоне.

      QNAME=host3.example. QTYPE=MX, QCLASS=IN

Ответом будет host3.example. IN MX …

      QNAME=host3.example. QTYPE=A, QCLASS=IN

Ответ будет указывать отсутствие ошибок и данных (no error, but no data), поскольку нет набора A RR в *.example.

      QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN

Ответом будет foo.bar.example. IN TXT …, поскольку bar.example. не существует, но шаблон имеется.

Приведённые ниже отклики¹ не будут синтезированы из одного из шаблонов в зоне.

      QNAME=host1.example., QTYPE=MX, QCLASS=IN

поскольку host1.example. существует.

      QNAME=sub.*.example., QTYPE=MX, QCLASS=IN

поскольку sub.*.example. существует.

      QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN

поскольку because _tcp.host1.example. существует (без данных).

      QNAME=host.subdel.example., QTYPE=A, QCLASS=IN

поскольку subdel.example. существует (и является срезом зоны).

      QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN

поскольку *.example. существует.

Последний пример демонстрирует распространённое заблуждение о шаблонах. Шаблон «блокирует себя» в том смысле, что он не соответствует своим субдоменам. Т. е. *.example. не соответствует именам в зоне example. и не соответствует именам ниже *.example. Для охвата имён ниже *.example. требуется другое шаблонное доменное имя *.*.example., которое охватывает все субдомены, кроме своих.

2.2.2. Пустые нетерминальные элементы

Пустые нетерминальные элементы [параграф 7.16 в RFC2136] — это доменные имена, в которых нет записей о ресурсах, но имеются субдомены. В параграфе 2.2.1 _tcp.host1.example. является примером пустого нетерминального имени. Эти имена введены в тексте параграфа 3.1 RFC 1034:

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

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

Педантичное прочтение приведённого выше абзаца может привести к допущению существования всех возможных доменов, вплоть до предложенного ограничения размера доменного имени 255 октетами [RFC1035]. Например, www.example. может иметь A RR и, насколько это возможно практически, быть листом дерева домена. Но это может означать, что существует также sub.www.example., хотя и без данных. Таким образом, существуют все возможные домены вниз от корня.

Поскольку RFC 1034 в параграфе 4.3.1 определяет также «ошибку authoritative name, указывающая на то, что имени не существует», это, очевидно, не является целью исходного определения, что оправдывает необходимость обновлённого определения в следующем параграфе.

2.2.3. Другое определение существования

Формулировка RFC 1034 заменяется приведёнными ниже абзацами.

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

Узел без потомков является листом. Пустых узлов-листьев не существует.

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

2.3. Когда шаблонное доменное имя не является специальным?

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

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

3. Влияние шаблонных доменных имён на отклик

В параграфе 4.3.2 RFC 1034 описано влияние шаблонов на генерацию откликов. Здесь описывается алгоритм, которому сервер следует при создании отклика. Пункт 3.c этого алгоритма задаёт поведение для шаблонов.

Алгоритм из параграфа 4.3.2 не является псевдокодом, т. е. его не обязательно выполнять строго по порядку. Это лишь предлагаемый способ реализации требований. Поэтому подпункты a, b и c пункта 3 не обязательно реализовать в указанном порядке, если результат реализации кода соответствует спецификации протокола.

3.1. Этап 2

В параграфе 4.3.2 сказано:

2. Поиск доступных зон для зоны, которая является ближайшим предком QNAME. При нахождении такой зоны переход к п. 3, иначе — п. 4.

На этом этапе выбирается зона, наиболее подходящая для отклика. Важность этого этапа определяется тем, что этап 3 целиком выполняется в рамках одной зоны. Это важно при рассмотрении вопроса о возможности использования SOA RR для синтеза.

3.2. Этап 3

Этап 3 разделен на 3 части — a, b и c. Начало этапа очень важно и требует разъяснения.

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

Слово «соответствие» здесь означает совпадение меток. В основе концепции лежит представление зоны в форме дерева существующих имён. Имя в запросе рассматривается как упорядоченная последовательность меток — путь от корня к владельцу желаемых данных (см. третий абзац в параграфе 3.1 RFC 1034).

Процесс сопоставления метки с именем в запросе завершается в точности одним из трёх вариантов (a, b, c) — имя найдено, находится ниже точки среза или не найдено. После выбора одного из вариантов остальные уже не рассматриваются (например, не следует выбирать п. c, а затем менять путь выполнения, чтобы закончить в п. b). Процесс сопоставления меток выполняется независимо от типа запроса (QTYPE).

Пункты a и b здесь не рассматриваются, поскольку они не связаны с синтезом записей. Пункт a относится к точному совпадению, приводящему к ответу, а пункт b’ is a referral.

3.3. Пункт c

Контекст п. c заключается в том, что процесс сопоставления меток из имени в запросе приводит к ситуации, когда в дереве нет соответствующей метки (как будто поиск «упал с дерева» — fallen off the tree).

3. Если для какой-либо метки сопоставление невозможно (т. е., соответствующей метки не существует), проверяется существование метки «*».

Чтобы помочь в описании процесса поиска «существования метки *» был введён термин, указывающий последний соответствующий домен (узел). Он называется «ближайшим включающим» (closest encloser).

3.3.1. Ближайший включающий узел и источник синтеза

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

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

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

      <asterisk label>.<closest encloser>.

Источник синтеза не гарантирует наличия RRSet для синтеза и может быть пустым нетерминальным узлом. Если источника синтеза не существует (нет в дереве домена), синтез по шаблону не выполняется и поиск альтернатив не производится.

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

3.3.2. Примеры ближайшего включающего узла и источника синтеза

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

 

QNAME	Ближайшее включающее имя	Источник синтеза
host3.example.	example.	*.example.
_telnet._tcp.host1.example.	_tcp.host1.example.	нет
_dns._udp.host2.example.	host2.example.	нет
_telnet._tcp.host3.example.	example.	*.example.
_chat._udp.host3.example.	example.	*.example.
foobar.*.example.	*.example.	нет

 

3.3.3. Сопоставление типа

В RFC 1034 п. c завершается приведённым ниже текстом.

Если метки «*» не существует, проверяется является ли искомое имя исходным QNAME в запросе или именем, полученным через CNAME. Если имя является исходным, в отклике указывается ошибка authoritative name и поиск завершается. В противном случае поиск заканчивается без констатации ошибки.

Если метка «*» существует, записи RR на данном узле сопоставляются с QTYPE. При обнаружении соответствий записи копируются в раздел ответа, но в качестве владельца RR указывается QNAME, а не узел с меткой «*». Переход к п. 6.

Во втором абзаце рассматривается роль QTYPE в процессе поиска. На основе отзывов на реализации и сходстве пп. a и c этот абзац изменён путём добавления приведённого ниже текста в п. c перед инструкцией перехода к п. 6.

Если данные в источнике синтеза являются CNAME, а QTYPE не соответствует CNAME, в раздел ответов копируется CNAME RR с заменой имени владельца на QNAME, заменой QNAME на каноническое имя в CNAME RR и возвратом к п. 1.

По сути, это тот же текст, что и в п. a для обработки CNAME RRSet.

4. Рассмотрение особых типов

В разделах 2 и 3 этого документа обсуждается синтез подстановок применительно именам в дереве домена и не учитывается влияние типов. В этом разделе рассматривается влияние шаблонов определённых типов с акцентом на более сложные для понимания типы, к каковым относятся SOA, NS, CNAME, DNAME, SRV, DS, NSEC, RRSIG, и none (пустые нетерминальные имена доменов с шаблоном).

4.1. SOA RRSet доменного имени с шаблоном

Шаблонное доменное имя, владеющее SOA RRSet, означает, что домен находится в корне зоны (вершина — apex). Домен не может быть источником синтеза, поскольку он, по определению, является узлом-потомком (ближайшего включающего узла) и вершина зоны размещается наверху зоны (zone apex is at the top of the zone).

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

      $ORIGIN *.example.
      @                 3600 IN  SOA   <SOA RDATA>
                        3600     NS    ns1.example.com.
                        3600     NS    ns1.example.net.
      www               3600     TXT   "the www txt record"

Запрос записи TXT для www.*.example. найдёт ответ the www txt record. Метка * становится значимой лишь при использовании п. 3.c из параграфа 4.3.2.

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

4.2. NS RRSet доменного имени с шаблоном

С появлением DNSSEC [RFC4033, RFC4034, RFC4035] семантика доменного имени с шаблоном, владеющего NS RRSet стала плохо определённой. Дилемма связана с конфликтом правил синтеза из п. с и тем фактом, что в результате синтезируется запись, для которой зона не имеет полномочий. В зоне, подписанной DNSSEC, механизмы управления подписями (создание и включение в сообщение) становятся неясными.

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

4.2.1. Отброшенные принципы

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

Прямой запрет использования шаблонов типа NS тоже несостоятелен, поскольку в протоколе DNS не определена обработка «недействительных» данных. Реализация может отказаться загружать зону, но протокол этого не задаёт. Отсутствие определения осложняется необходимостью поддержки динамических обновлений [RFC2136] и переноса зон, а также загрузки на первичном сервере. Нужно также учитывать случаи, когда клиент (распознаватель, кэширующий сервер) получает в отклике шаблон типа NS.

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

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

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

4.3. CNAME RRSet доменного имени с шаблоном

Проблема с CNAME RRSet, принадлежащим доменному имени с шаблоном, побудила внести изменение (см. параграф 3.3.3) в последний абзац п. 3c алгоритма из параграфа 4.3.2.

4.4. DNAME RRSet доменного имени с шаблоном

Принадлежность DNAME [RFC2672] RRSet доменному имени с шаблоном представляет угрозу согласованности DNS и таких ситуаций следует избегать или отвергнуть их совсем. Такой набор DNAME RRSet представляет недетерминированный синтез правил, передаваемых в различные кэши. По мере непредсказуемого поступления с кэши разных правил согласованность кэшей теряется (слова «по мере поступления» здесь относятся к хранению в кэше записей, полученных в откликах рекурсивных или итеративных серверов). Предположим, например, что один кэш, отвечающий на рекурсивный запрос, получит запись

         a.b.example. DNAME foo.bar.example.net.

а другой получит

         b.example.  DNAME foo.bar.example.net.

созданные полномочным сервером из записи

         *.example. DNAME foo.bar.example.net.

В спецификации DNAME нет чёткого указания о применении кэшированных записей DNAME для перезаписи запросов. В некоторых интерпретациях такая запись происходит, в других — нет. Если допустить возможность перезаписи, запросы для sub.a.b.example. A могут быть переписаны как sub.foo.bar.example.tld. A первым кэширующим сервером и как sub.a.foo.bar.example.tld. A — последующим. Согласованность теряется с кошмарным результатом.

Ещё одна рекомендация избегать применения шаблонных записей DNAME связана с наблюдением, что такая запись может создавать DNAME, принадлежащую sub.foo.bar.example. И foo.bar.example. В определении DNAME есть ограничение, в соответствии с которым не может существовать доменов ниже домена владельца DNAME, поэтому шаблонных записей DNAME следует избегать.

4.5. SRV RRSet доменного имени с шаблоном

Определение SRV RRset в RFC 2782 [RFC2782] содержит путаницу с термином Name (имя), как показано ниже.

Формат SRV RR

…

_Service._Proto.Name TTL Class SRV Priority Weight Port Target

…

Имя (Name)

Домен, на который указывает эта запись RR. Запись SRV RR уникальна в том, что искомое имя не является именем этой записи и пример в конце наглядно показывает это.

Не следует путать Name с именем владельца. Т. е. после удаления меток _Service и _Proto из имени владельца SRV RRSet оставшаяся часть может быть доменным именем с шаблоном, но это несущественно для SRV RRSet. Например, если запись SRV имеет вид

      _foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example.

*.example является доменным именем с шаблоном и хотя это Name для записи SRV RR, значение не будет владельцем (доменного имени). Владельцем будет _foo._udp.*.example. — доменное имя без шаблона.

Запрос SRV RRSet для _foo._udp.bar.example. (класс IN) приведёт к совпадению с именем *.example. (в предположении отсутствия bar.example.), а не с показанной записью SRV. Если в *.example. Нет SRV RRSet, раздел ответов будет отражать это (будет пустым или CNAME RRset).

Путаница, вероятно, связана со смешением спецификации SRV RR и описания «примера использования».

4.6. DS RRSet доменного имени с шаблоном

Набор DS RRSet, принадлежащий доменному имени с шаблоном не имеет смысла и не приносит вреда. Это утверждение сделано в контексте неопределённости NS RRSet доменного имени с шаблоном. В точке без делегирования DS RRSet не имеет значения (DNSKEY RRSet не будет использоваться для проверки DNSSEC). При наличии синтезированного DS RRSet он сам по себе не будет полезен, поскольку он существует в точке делегировани.

4.7. NSEC RRSet доменного имени с шаблоном

Шаблонные имена доменов в зоне с подписью DNSSEC будут иметь NSEC RRSet. Синтез таких записей будет выполняться лишь при точном соответствии запроса записи. Синтезированные NSEC RR не нанесут вреда, поскольку они не будут использоваться в негативном кэшировании или при генерации негативных откликов [RFC2308].

4.8. RRSIG доменного имени с шаблоном

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

4.9. Пустое нетерминальное доменное имя с шаблоном

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

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

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

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

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

[RFC20] Cerf, V., «ASCII format for network interchange», RFC 20, October 1969.

[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.

[RFC1995] Ohta, M., «Incremental Zone Transfer in DNS», RFC 1995, August 1996.

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

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

[RFC2672] Crawford, M., «Non-Terminal DNS Name Redirection», RFC 2672, August 1999.

[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, «A DNS RR for specifying the location of services (DNS SRV)», RFC 2782, February 2000.

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

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

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

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

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

7. Вклад в разработку документа

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

Комментарии к документу можно направлять редактору или в почтовую конференцию DNSEXT по адресу namedroppers@ops.ietf.org.

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

Edward Lewis

NeuStar

46000 Center Oak Plaza

Sterling, VA

20166, US

Phone: +1-571-434-5468

EMail: ed.lewis@neustar.biz

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

Copyright (C) The Internet Society (2006).

К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.

Этот документ и содержащаяся в нем информация представлены «как есть» и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

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

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.

IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.

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

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

---

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

nmalykh@protokols.ru

---

Network Working Group                                      E. Allman
Request for Comments: 4405                            Sendmail, Inc.
Category: Experimental                                       H. Katz
                                                     Microsoft Corp.
                                                          April 2006

Механизм Anonymous в SASL

Anonymous Simple Authentication and Security Layer (SASL) Mechanism

PDF

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

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

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

Copyright (C) The Internet Society (2006).

Аннотация

В сети Internet обычной практикой является предоставление анонимным пользователям доступа к различным сетевым службам. Обычно это организуется на основе механизма с открытыми паролями, использующего «anonymous» в качестве имени пользователя и, в некоторых случаях, — необязательную трассировочную информацию (типа адреса электронной почты) в качестве пароля. В новых протоколах IETF не допускаются команды регистрации в системе (login) в виде открытого текста, поэтому требуется новый метод предоставления доступа анонимным пользователям в контексте схемы SASL¹.

1. Введение

В этом документе определяется механизм анонимного доступа для схемы SASL [SASL]. Имя этого механизма «ANONYMOUS».

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

Данный механизм не обеспечивает уровня защиты.

Этот документ заменяет собой RFC 2245. Изменения по отношению к RFC 2245 отражены в Приложении A.

2. Механизм Anonymous

Механизм состоит из простого сообщения, передаваемого клиентом серверу. Клиент может включить в это сообщение трассировочную информацию в форме строки символов Unicode [Unicode] с кодировкой UTF-8 [UTF-8] в соответствии с [StringPrep] и «трассировать» профиль stringprep, определенный в главе 3 данного документа. Трассировочную информацию, которая не имеет семантического значения, следует задавать в одной из двух возможных форм – адрес электронной почты Internet или «темная» (opaque) строка, не содержащая символов @ (U+0040), которая может быть интерпретирована системным администратором домена на стороне клиента. По причинам сохранения приватности адрес электронной почты или иные сведения, идентифицирующие пользователя, могут использоваться только с его разрешения.

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

Ниже приведен формальный синтаксис клиентского сообщения в формате ABNF [ABNF], как иллюстрация к данной технической спецификации.

      message     = [ email / token ]    ;; готовится в соответствии с главой 3

      UTF1        = %x00-3F / %x41-7F ;; less '@' (U+0040)
      UTF2        = %xC2-DF UTF0
      UTF3        = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / %xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
      UTF4        = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / %xF4 %x80-8F 2(UTF0)
      UTF0        = %x80-BF

      TCHAR       = UTF1 / UTF2 / UTF3 / UTF4
                    ;; любые символы Unicode в кодировке UTF-8, за исключением @ (U+0040)

      email       = addr-spec        ;; в соответствии с [IMAIL]
      token       = 1*255TCHAR

Примечание для разработчиков:

Размер маркера <token> ограничен 255 символами в кодировке UTF-8. Поскольку данная кодировка использует от 1 до 4 октетов на символ, размер маркера может достигать 1020 октетов.

3. «Трассировка» профиля «Stringprep»

В этой главе определена «трассировка» профиля [StringPrep]. Этот профиль разработан для использования с механизмом SASL ANONYMOUS. В частности, клиент готовит <message> в соответствии с этим профилем.

Набором символов для этого профиля является Unicode 3.2 [Unicode].

Для профиля не требуется отображения.

Для профиля не требуется нормализации Unicode.

Список невыделенных кодов для этого профиля определен в Приложении A к документу [StringPrep]. Невыделенные коды не являются запрещенными.

Запрещено использование символов из следующих таблиц [StringPrep]:

• C.2.1 (управляющие символы ASCII)
• C.2.2 (управляющие символы, отличные от ASCII)
• C.3 (символы для приватного использования)
• C.4 (не имеющие символов коды)
• C.5 (суррогатные коды)
• C.6 (неприемлемо для текста)
• C.8 (изменение свойств дисплея запрещено)
• C.9 (символы для тегов)

Других запрещенных символов нет.

Данный профиль требует двунаправленной проверки символов в соответствии с главой 6 документа [StringPrep].

4. Пример

Здесь рассмотрен простой пример использования механизма ANONYMOUS между клиентом и сервером IMAP. В примере префиксы «C:» и «S:» указывают строки, передаваемые клиентом и сервером, соответственно. Если следующая строка не содержит префикса «C:» или «S:», она является просто переносом предыдущей строки, сделанным для удобства чтения.

Отметим, что в этом примере используется профиль IMAP [IMAP4] для SASL. Кодирование base64 для запросов и откликов, а также префиксы «+ » в откликах являются частью профиля IMAP4 и не относятся непосредственно к SASL. Кроме того, протоколы с профилями SASL, разрешающими клиенту включать в запрос на организацию аутентификационной сессии начальный отклик, позволяют сэкономить один период кругового обхода для аутентификационного обмена (избежать показанного ниже отклика «+ » с пустой строкой).

В данном примере трассировочной информацией является строка «sirhc».

      S: * OK IMAP4 server ready
      C: A001 CAPABILITY
      S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=DIGEST-MD5 AUTH=ANONYMOUS
      S: A001 OK done
      C: A002 AUTHENTICATE ANONYMOUS
      S: +
      C: c2lyaGM=
      S: A003 OK Welcome, trace information has been logged.

 

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

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

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

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

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

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

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

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

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

Анонимные соединения чувствительны к перехвату с участием человека (man-in-the-middle attack), при которых передаваемая информация может просматриваться и изменяться. Клиентам и серверам настоятельно рекомендуется использовать внешние средства защиты данных.

Протоколы, которые не могут обеспечить явную регистрацию в системе для анонимных пользователей, более уязвимы к вторжениям, связанным с некоторыми общепринятыми методами реализации. В частности, серверы Unix, которые предлагают пользователям регистрацию в системе, могут запускаться с правами пользователя root и переключаться на соответствующее значение user id после явной команды login. Обычно такие серверы отвергают все команды доступа к данным до явной регистрации в системе и могут создавать безопасную среду с ограниченными возможностями (например, с помощью chroot в Unix) для анонимных пользователей. Если анонимный доступ не запрашивается явно, вся система доступа к данным может подвергнуться внешним атакам без возможности явного использования защитных мер. Протоколам, предлагающим ограниченный доступ к данным для анонимных пользователей, не следует предоставлять такой доступ без этапа явной регистрации в системе.

Общие вопросы безопасности SASL [SASL] применимы и к данному механизму.

Вопросы безопасности StringPrep [StringPrep] и вопросы безопасности Unicode [Unicode], рассмотренные в [StringPrep], также применимы к этому механизму. Вопросы безопасности UTF-8 [UTF-8] также применимы к данному механизму.

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

Реестр SASL Mechanism [IANA-SASL] содержит запись для механизма ANONYMOUS, которая была обновлена IANA с учетом данного документа, обеспечивающего техническую спецификацию механизма.

      To: iana@iana.org
      Subject: Updated Registration of SASL mechanism ANONYMOUS

      SASL mechanism name: ANONYMOUS
      Security considerations: See RFC 4505.
      Published specification (optional, recommended): RFC 4505
      Person & email address to contact for further information:
           Kurt Zeilenga <Kurt@OpenLDAP.org>
           Chris Newman <Chris.Newman@sun.com>
      Intended usage: COMMON
      Author/Change controller: IESG <iesg@ietf.org>
      Note: Updates existing entry for ANONYMOUS

«Трассировка» профиля [StringPrep], определенная в данном RFC, была зарегистрирована:

      To: iana@iana.org
      Subject: Initial Registration of Stringprep "trace" profile

      Stringprep profile: trace
      Published specification: RFC 4505
      Person & email address to contact for further information:
          Kurt Zeilenga <kurt@openldap.org>

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

Этот документ является пересмотром документа RFC 2245, который подготовил Chris Newman. Фрагменты синтаксиса, определенного в главе 1, были заимствованы из RFC 3629, автором которого является Francois Yergeau.

Данный документ является результатом работы группы IETF SASL.

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

[ABNF] Crocker, D. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», RFC 4234, October 2005.

[IMAIL] Resnick, P., «Internet Message Format», RFC 2822³, April 2001.

[SASL] Melnikov, A., Ed. and K. Zeilenga, Ed., «Simple Authentication and Security Layer (SASL)», RFC 4422, June 2006.

[StringPrep] Hoffman, P. and M. Blanchet, «Preparation of Internationalized Strings (‘stringprep’)», RFC 3454, December 2002.

[Unicode] The Unicode Consortium, «The Unicode Standard, Version 3.2.0» is defined by «The Unicode Standard, Version 3.0» (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the «Unicode Standard Annex #27: Unicode 3.1» (http://www.unicode.org/reports/tr27/) and by the «Unicode Standard Annex #28: Unicode 3.2» (http://www.unicode.org/reports/tr28/).

[UTF-8] Yergeau, F., «UTF-8, a transformation format of ISO 10646», RFC 3629 (also STD 63), November 2003.

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

[IMAP4] Crispin, M., «INTERNET MESSAGE ACCESS PROTOCOL – VERSION 4rev1», RFC 3501, March 2003.

[IANA-SASL] IANA, «SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) MECHANISMS», <http://www.iana.org/assignments/sasl-mechanisms>.

Приложение A. Изменения по отношению к RFC 2245

Это приложение не является нормативным.

RFC 2245 позволяет клиенту включать необязательную трассировочную информацию в понятной человеку форме. RFC 2245 разрешает для этих строк только кодировку US-ASCII. В связи с интернационализацией сети Internet данный документ ограничивает такие строки набором символов Unicode в кодировке UTF-8. Определен профиль «stringprep» для точного указания символов Unicode, допустимых для включения в такие строки. Размер строки ограничен 255 символами, для кодирования каждого из которых может применяться от 1 до 4 октетов.

Кроме того, внесено множество редакторских правок.

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

Kurt D. Zeilenga

OpenLDAP Foundation

EMail: Kurt@OpenLDAP.org

---

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

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

nmalykh@protokols.ru

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

Copyright (C) The Internet Society (2006).

К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.

Этот документ и содержащаяся в нем информация представлены «как есть» и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

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

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.

IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.

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

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

Network Working Group                               A. Melnikov, Ed.
Request for Comments: 4422                             Isode Limited
Obsoletes: 2222                                     K. Zeilenga, Ed.
Category: Standards Track                        OpenLDAP Foundation
                                                           June 2006

Простой уровень аутентификации и защиты (SASL)

Simple Authentication and Security Layer (SASL)

PDF

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

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

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

Copyright (C) The Internet Society (2006).

Аннотация

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

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

Данный документ отменяет действие RFC 2222.

1. Введение

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

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

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

    SMTP    LDAP    XMPP   Другие протоколы ...
       \       |    |      /
        \      |    |     /
       Уровень абстракции SASL
        /      |    |     \
       /       |    |      \
EXTERNAL   GSSAPI  PLAIN   Другие протоколы ...

Благодаря интерфейсам этого уровня абстракции схема позволяет любому протоколу использовать любые механизмы. Хотя этот уровень в общем случае скрывает конкретные протоколы от механизмов (и наоборот), он не прячет в общем случае конкретные механизмы от реализации протокола. Например, для работы различных механизмов требуется разная информация – некоторые используют аутентификацию на основе пароля, другим нужна информация об областях (realm), третьи применяют ярлыки Kerberos, сертификаты и т. д. Кроме того, для проверки полномочий серверные реализации в общем случае применяют отображение между элементами² аутентификации, форма которых определяется механизмом, и элементами проверки полномочий, чья форма определяется прикладными протоколами. Концепции идентификации рассмотрены в главе 2.

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

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

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

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

В главе 6 обсуждаются вопросы безопасности, глава 7 содержит информацию о согласовании с IANA. В приложении A определен механизм SASL EXTERNAL.

1.1. Аудитория

Этот документ рассчитан на несколько категорий читателей:

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

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

1.2. Связь с другими документами

Данный документ прекращает действие RFC 2222. Он заменяет все части RFC 2222, за исключением параграфов 7.1 (механизм KERBEROS_IV), 7.2 (механизм GSSAPI) и 7.3 (механизм SKEY). Механизмы KERBEROS_IV и SKEY в настоящее время представляются устаревшими и их спецификации в RFC 2222 получают статус Historic. Спецификация механизма GSSAPI в настоящее время содержится в отдельном документе [SASL-GSSAPI].

В приложении B приводится список отличий от RFC 2222.

1.3. Использование терминов

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

Символы, используемые в данном документе для обозначения кодов (code point) и имен, соответствуют стандарту Unicode [Unicode]. Например, буква «a» может быть представлена как <U+0061> или <LATIN SMALL LETTER A>⁵.

В примерах префиксы «C:» и «S:» указывают строки, передаваемые клиентом и сервером, соответственно. Строки могут переноситься для удобства чтения документа.

2. Концепции идентификации

На практике аутентификация и проверка полномочий (authorization) может включать множество элементов проверки тождественности, возможно в разных формах (простые имена пользователей — username, Kerberos principal, X.500 Distinguished Name и т. п.) и с различным представлением (например строки ABNF в кодировке UTF-8, Distinguished Name в кодировке BER). Хотя технические спецификации часто описывают форму и представление элементов идентификации, используемых в сети, реализации могут использовать различные формы элементов и/или варианты их представления. Отношения между элементами идентификации различных форм в общем случае определяются локально. Используемые реализацией формы и варианты представления элементов также определяются локально самой реализацией.

Однако концептуально схема SASL включает два элемента идентификации:

1. идентификация, связанная с предъявленными при аутентификации полномочиями (authentication credentials), обозначаемая термином authentication identity (аутентификационная идентификация);
2. идентификация при проверке полномочий, обозначаемая термином authorization identity.

Спецификации механизмов SASL описывают форму полномочий (например, сертификаты X.509, ярлыки Kerberos, простые пары username/password), предъявляемых при аутентификации клиента, включая (когда это приемлемо) синтаксис и семантику элементов идентификации, передаваемых в свидетельствах полномочий (credentials). Спецификации протокола SASL описывают форму элементов идентификации, используемых при проверке полномочий (authorization) и, в частности, синтаксис и семантику строк элементов идентификации, передаваемых механизмами.

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

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

Однако конкретные формы authentication identity (используемые сервером для верификации) и authorization identity (используемые для проверки полномочий) не входят в спецификацию SASL. В некоторых случаях конкретные формы идентификации, используемые в том или ином контексте за пределами обмена SASL, могут диктоваться другими спецификациями. Например, спецификация правил identity assumption authorization (proxy authorization) может задавать представление идентификации при проверке полномочий и аутентификации в правилах политики.

3. Аутентификационный обмен

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

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

C: Запрос аутентификационного обмена
S: Первоначальный запрос (challenge) сервера
C: Первоначальный отклик
   <дополнительные сообщения challenge/response>
S: Результат аутентификационного обмена

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

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

C: Запрос аутентификационного обмена + Первоначальный отклик
   <дополнительные сообщения challenge/response>
S: Результат аутентификационного обмена

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

C: Запрос аутентификационного обмена
S: Пустой запрос (Challenge)
C: Первоначальный отклик
   <дополнительные сообщения challenge/response>
S: Результат аутентификационного обмена

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

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

C: Запрос аутентификационного обмена
S: Первоначальный запрос (challenge) сервера
C: Первоначальный отклик
   <дополнительные сообщения challenge/response>
S: Результат аутентификационного обмена с дополнительными данными об успехе

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

C: Запрос аутентификационного обмена
S: Первоначальный запрос (challenge) сервера
C: Первоначальный отклик
   <дополнительные сообщения challenge/response>
S: Дополнительный запрос (challenge)
C: Пустой отклик
S: Результат аутентификационного обмена

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

C: Запрос аутентификационного обмена + Первоначальный отклик
   <дополнительные сообщения challenge/response>
S: Результат аутентификационного обмена с дополнительными данными об успехе

вместо:

C: Запрос аутентификационного обмена
S: Пустой запрос (Challenge)
C: Первоначальный отклик
   <дополнительные сообщения challenge/response>
S: Дополнительный запрос (challenge)
C: Пустой отклик
S: Результат аутентификационного обмена

3.1. Именование механизмов

Механизмы SASL именуются символьными строками длиной от 1 до 20 знаков, содержащими буквы верхнего регистра кода ASCII [ASCII], цифры, знаки дефиса (-) и символы подчеркивания (_). В приведенной ниже форме ABNF⁶ [RFC4234] <sasl-mech> определяет синтаксис имен механизмов SASL.

sasl-mech   = 1*20mech-char
mech-char   = UPPER-ALPHA / DIGIT / HYPHEN / UNDERSCORE
; mech-char может содержать только буквы A-Z (заглавные), 0-9, -, и _ из набора ASCII. 

UPPER-ALPHA = %x41-5A ; A-Z (только заглавные)
DIGIT       = %x30-39 ; 0-9
HYPHEN      = %x2D ; hyphen (-)
UNDERSCORE  = %x5F ; underscore (_)

Регистрация имен механизмов SASL обсуждается в параграфе 7.1.

3.2. Согласование механизмов

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

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

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

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

3.3. Запрос аутентификационного обмена

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

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

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

3.4. Запросы и отклики

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

С помощью таких запросов и откликов механизм может:

• аутентифицировать клиента на сервере;
• аутентифицировать сервер на стороне клиента;
• передать строку идентификации для проверки полномочий (authorization identity);
• согласовать уровень защиты;
• обеспечить другие типы сервиса.

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

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

3.4.1. Строка идентификации для проверки полномочий

Строка идентификации для проверки полномочий (authorization identity string) представляет собой последовательность (возможно нулевой длины) символов Unicode [Unicode], за исключением символа NUL (U+0000).

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

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

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

3.5. Прерывание аутентификационного обмена

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

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

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

3.6. Результат аутентификации

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

Аутентификация завершается отказом, если

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

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

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

Передаваемое сервером сообщение о результате аутентификации может обеспечивать для клиента способ различать ошибки, при которых лучше всего повторно запросить у пользователя его свидетельства, от ошибок, при которых лучше всего рекомендовать клиенту обратиться к серверу позднее, или ошибок, при которых пользователю следует обратиться к системному администратору для решения проблем (см. коды откликов SYS и AUTH POP [RFC3206] в качестве примера). Такая возможность полезна, в частности, в периоды запланированного обслуживания сервера, поскольку она позволяет снизить расходы на поддержку. Важно также настроить сервер так, чтобы сообщения о результате аутентификации не позволяли отличить легитимного пользователя с некорректными свидетельствами от нелегитимного пользователя.

3.7. Уровни защиты

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

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

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

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

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

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

3.8. Множественная аутентификация

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

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

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

4. Требования к протоколам

Для того, чтобы протокол мог предлагать сервис SASL, его спецификация должна содержать следующую информацию:

1. Имя сервиса, которое может быть выбрано из реестра элементов service для связанного с хостом имени сервиса GSSAPI⁸, как описано в параграфе 4.1 документа [RFC2743]. Отметим, что этот регистр совместно используется всеми механизмами GSSAPI и SASL.
2. Детали всех аспектов согласования механизма, обеспечиваемых протоколом (см. параграф 3.2).Протоколу следует задавать средства, с помощью которых клиент может определить (как до начала обмена SASL, так и после установки уровня защиты в результате обмена) имена механизмов SASL, которые сервер делает доступными для клиента. Это важно для обеспечения клиенту возможности детектирования атак, направленных на снижение уровня защиты. Такие средства обычно обеспечиваются с помощью функций детектирования расширений протокола и согласования возможностей.
3. Определения сообщений, требуемых при аутентификационном обмене, включая следующие:

1. сообщения для запроса аутентификационного обмена (см. параграф 3.3).Такие сообщения должны содержать поле для передачи имени механизма, выбранного клиентом.В такие сообщения следует включать необязательное поле для передачи начального отклика. Если сообщение определено с таким полем, спецификация должна описывать, как сообщения с пустым начальным откликом отличаются от сообщений без такого отклика. Это поле должно обеспечивать возможность передачи произвольной последовательности октетов (включая последовательности нулевой длины и последовательности с нулевыми октетами).
2. Сообщения для передачи запросов сервера и откликов клиента (см. параграф 3.4).Каждое из таких сообщений должно обеспечивать возможность передачи произвольных последовательностей октетов (включая последовательности нулевой длины и последовательности с нулевыми октетами).
3. Сообщение для индикации результата аутентификационного обмена (см. параграф 3.6).В такие сообщения следует включать необязательное поле для передачи дополнительных данных при успешном завершении обмена. Если для сообщения определено такое поле, спецификация должна описывать способ различить сообщения с пустым полем дополнительной информации от сообщений без такого поля. Поле должно обеспечивать возможность передачи произвольной последовательности октетов (включая последовательности нулевой длины и последовательности с нулевыми октетами).

4. Описание синтаксиса и семантики непустых строк идентификации при проверке полномочий (см. параграф 3.4.1).Чтобы избавиться от проблем при взаимодействии в результате использования разной нормализации, спецификация протокола должна точно описывать, как и где (клиент или сервер) готовятся непустые строки идентификации при проверке полномочий (включая любую нормализацию), для операций сравнения и других функций, обеспечивающих корректную работу.Рекомендуется включать в спецификацию описание применения существующих форм идентификации при проверке полномочий, а также существующих вариантов представления строк таких, как обычные имена пользователей [RFC4013].Когда спецификация не описывает точно, как идентификация в SASL связана с идентификацией, используемой другими компонентами протокола (например, в правилах контроля доступа), для протокола может оказаться полезным поддержка для клиентов механизма обнаружения информации (например, представление идентификации, используемой при решении вопроса о предоставлении доступа) об имеющихся способах идентификации для таких целей.
5. Детали всех способов, которые позволяют клиенту и/или серверу прервать аутентификационный обмен (см. параграф 3.5).Протоколы, поддерживающие множественную аутентификацию, обычно позволяют клиенту прервать происходящий аутентификационный обмен путем инициирования нового обмена. Протоколы, которые не поддерживают множественную аутентификацию, могут требовать от клиента закрыть соединение для прерывания происходящего аутентификационного обмена и открыть новое для продолжения.Протоколы обычно позволяют серверу прерывать происходящий аутентификационный обмен путем возврата сообщения о неудачной аутентификации.
6. Точного указания момента, с которого начинает использоваться вновь согласованный уровень защиты для обоих направлений (см. параграф 3.7).Обычно спецификации требуют начинать использование уровня защиты с первого октета, передаваемого после результата аутентификации, для сообщений от сервера, и первого октета, передаваемого после приема сообщения о результате аутентификации, для клиента.
7. Если протокол поддерживает другие службы обеспечения уровня защиты (такие, как TLS⁹ [RFC4346], спецификация должна описывать, как эти уровни применяются к данным протокола.Например, когда протокол поддерживает уровни защиты TLS и SASL, спецификация может указать любой из перечисленных ниже вариантов:

1. уровень защиты SASL всегда применяется первым для передаваемых данных и последним для принимаемых;
2. уровень защиты SASL всегда применяется последним для передаваемых данных и первым для принимаемых;
3. уровни защиты применяются в порядке их установки;
4. уровни защиты применяются в порядке, обратном порядку их установки;
5. оба уровня TLS и SASL не могут быть установлены.

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

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

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

5. Требования к механизмам

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

1. Имя механизма (см. параграф 3.1). Это имя должно быть зарегистрировано, как описано в параграфе 7.1.
2. Определение запросов сервера (server-challenge) и откликов клиента (client-response) в процессе аутентификационного обмена, а также:

1. Индикацию того, начинает работу механизма клиент (client-first), сервер (server-first) или это может изменяться (variable). Если механизм SASL определен, как client-first, а клиент не передает начального отклика в запросе на аутентификацию, первый запрос сервера должен быть пустым (механизм EXTERNAL является примером такого случая). Если механизм SASL определен, как variable, спецификация должна указывать поведение сервера для тех случаев, когда начальный отклик в клиентском запросе на аутентификацию опущен (механизм DIGEST-MD5 [DIGEST-MD5] является примером для этого случая). Если механизм SASL определен, как server-first, для клиента недопустимо передавать начальный отклик в запросе на аутентификацию (примером для этого случая может служить механизм CRAM-MD5 [CRAM-MD5]).
2. Индикация того, предполагается ли со стороны сервера предоставление дополнительных данных при положительном результате аутентификации. Если такие данные ожидаются и сервер шлет их, как запрос (challenge), спецификация должна показывать, что в ответ на такой запрос передается пустой отклик.

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

3. Идентификация возможности поддержки механизмом передачи строк идентификации при проверке полномочий (см. параграф 3.4.1). Хотя некоторые унаследованные механизмы не способны передавать строки authorization identity (это означает, что для данного механизма authorization identity во всех случаях является пустой строкой), новым механизмам следует поддерживать передачу строк идентификации при проверке полномочий. Механизмам не следует поддерживать одновременно передачу отсутствия строк authorization identity и передачу пустых строк идентификации при проверке полномочий.

   Механизмы, способные передавать строки authorization identity, должны поддерживать возможность передачи произвольных непустых последовательностей символов Unicode, включая строки с символами NUL (U+0000). Механизмам следует использовать формат преобразования UTF-8 [RFC3629]. В спецификации должно быть указано, каким образом включаются в строки идентификации все последовательности символов, имеющие специальное значение для данного механизма, во избежание неоднозначности при декодировании строк authorization identity. Обычно механизмы, использующие специальные символы, требуют для таких символов добавки специального escape-символа или представления таких символов в виде последовательности (после преобразования в заданный формат Unicode) с использованием схем кодирования данных типа Base64 [RFC3548].

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

Механизмам SASL следует быть нейтральными по отношению к протоколам.

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

Механизмам SASL следует использовать формат преобразования UTF-8 [RFC3629] для представления передаваемых кодов в кодировке Unicode [Unicode].

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

Для простых имен пользователей и паролей в аутентификационных свидетельствах в качестве алгоритма подготовки следует указывать SASLprep [RFC4013] (профиль алгоритма подготовки StringPrep [RFC3454]).

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

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

Вопросы безопасности обсуждаются на протяжении всего документа.

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

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

6.1. Активные атаки

6.1.1. Перехват

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

6.1.2. Атаки, направленные на снижение уровня защиты

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

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

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

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

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

6.1.3. Атаки с воспроизведением данных

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

6.1.4. Атаки с отсечением

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

6.1.5. Другие активные атаки

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

6.2. Пассивные атаки

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

6.3. Замена ключей

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

Административные ограничения на продолжительность существования защитного уровня могут задаваться в форме сертификатов X.509, ярлыков Kerberos V или каталогов. Такие ограничения часто весьма желательны. На практике же очевидным результатом административного ограничения срока жизни является то, что приложение может столкнуться с прекращением работы уровня защиты во время операции прикладного уровня (например, при передаче большого объема данных). В результате соединение будет закрыто (см. параграф 3.7), что приведет к негативной реакции пользователей.

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

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

6.4. Прочие вопросы

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

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

Вопросы безопасности Unicode [UTR36] имеют отношение к строкам authorization identity, а при использовании UTF-8 становятся актуальными и вопросы безопасности UTF-8 [RFC3629]. Следует принимать во внимание также вопросы безопасности SASLprep [RFC4013] и StringPrep [RFC3454] в тех случаях, когда эти алгоритмы применяются.

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

7.1. Реестр механизмов SASL

Реестр механизмов SASL поддерживается агентством IANA. В настоящее время реестр доступен по адресу http://www.iana.org/assignments/sasl-mechanisms.

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

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

Для регистрации имени отдельного механизма используется процедура, описанная в параграфе 7.1.1.

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

Вопросы включения комментариев в реестр рассмотрены в параграфе 7.1.3, а вопросы изменения имеющихся комментариев – в параграфе 7.1.4.

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

7.1.1. Процедура регистрации имен механизмов

IANA будет регистрировать новые имена механизмов SASL в порядке подачи заявок (процедура First Come First Served), как описано в BCP 26 [RFC2434]. IANA имеет право отвергать явно фиктивные запросы на регистрацию, но не будет рассматривать заявления прав, сделанные в регистрационной форме.

Регистрация имен механизмов SASL осуществляется путем заполнения приведенной ниже формы

Тема: регистрация механизма SASL с именем X

Имя механизма SASL (или префикс для семейства имен):

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

Опубликованная спецификация (рекомендуется):

Контактное лицо и адрес электронной почты для обмена информацией:

Предполагаемое использование: (Один из вариантов COMMON — общего назначения, LIMITED USE — ограниченное применение, OBSOLETE — не использовать)

Владелец/контролер изменений:

Примечания: (Здесь может быть добавлена любая информация, которую автор сочтет нужной).

и ее отправки по электронной почте в IANA по адресу iana@iana.org.

Хотя эта процедура не требует экспертного обзора, авторам механизмов SASL настоятельно рекомендуется получить отклики и комментарии сетевого сообщества в тех случаях, когда это возможно. Авторы могут получить отклики сетевого сообщества, опубликовав спецификацию предлагаемого механизма в качестве Internet-Draft. Механизмы SASL, рассчитанные на общее применение, следует стандартизировать с использованием нормального процесса IETF в тех случаях, когда это возможно.

7.1.2. Процедура регистрации имен семейств

Как было отмечено выше, для механизмов SASL не существует общего соглашения об именовании. Однако спецификация может резервировать часть пространства имен механизмов SASL для набора связанных между собой механизмов SASL (семейства механизмов SASL). Каждое семейство механизмов SASL обозначается уникальным префиксом типа X-. Регистрация нового семейства имен механизмов SASL требует экспертизы в соответствии с BCP 26 [RFC2434].

Регистрация имен семейств механизмов SASL осуществляется путем заполнения приведенной ниже формы

Тема: регистрация семейства механизмов SASL с именем X

Имя семейства SASL (или префикс для семейства имен):

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

Опубликованная спецификация (рекомендуется):

Контактное лицо и адрес электронной почты для обмена информацией:

Предполагаемое использование: (Один из вариантов COMMON — общего назначения, LIMITED USE — ограниченное применение, OBSOLETE — не использовать)

Владелец/контролер изменений:

Примечания: (Здесь может быть добавлена любая информация, которую автор сочтет нужной).

И ее отправки по электронной почте в конференцию IETF SASL по адресу ietf-sasl@imc.org с копией по адресу iana@iana.org.

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

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

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

7.1.3. Комментарии к регистрации механизмов SASL

Комментарии к зарегистрированным механизмам и семействам SASL следует сначала направить «владельцу» имени или семейства и/или в почтовую конференцию по адресу ietf-sasl@imc.org.

Автор комментариев может, после разумного числа попыток контакта с владельцем, запросить в IANA включение своих комментариев в регистрацию этого механизма SASL, направив письмо по адресу iana@iana.org. По своему разумению IANA может включить комментарии в регистрацию механизма SASL.

7.1.4. Контроль изменений

После того, как регистрация механизма SASL опубликована IANA, автор может запросить изменение зарегистрированного определения. Запрос на изменение осуществляется в соответствии с такой же процедурой, какая использовалась при регистрации.

Владелец механизма SASL может передать ответственность за этот механизм другому лицу или организации, уведомив об этом IANA; такая передача не требует обсуждения или обзора.

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

Регистрация механизмов SASL не может быть отменена; механизмы, которые перестали быть приемлемыми для использования, помечаются как OBSOLETE в поле «intended usage»; такие механизмы SASL явно маркируются в списках, публикуемых IANA.

IESG рассматривается как владелец механизмов SASL, имеющих статус IETF.

7.2. Изменение регистрации

Агентство IANA внесло в реестр механизмов SASL следующие изменения:

1. Изменено поле Intended usage для механизмов KERBEROS_V4 и SKEY на OBSOLETE.
2. Изменено поле Published specification для механизма EXTERNAL с указанием данной спецификации, как показано ниже:

Subject: Updated Registration of SASL mechanism EXTERNAL

Family of SASL mechanisms: NO

SASL mechanism name: EXTERNAL

Security considerations: See A.3 of RFC 4422

Published specification (optional, recommended): RFC 4422

Person & email address to contact for further information:

Alexey Melnikov <Alexey.Melnikov@isode.com>

Intended usage: COMMON

Owner/Change controller: IESG <iesg@ietf.org>

Note: Updates existing entry for EXTERNAL

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

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

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

[RFC2244] Newman, C. and J. G. Myers, «ACAP – Application Configuration Access Protocol», RFC 2244, November 1997.

[RFC2434] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 2434, October 1998.

[RFC2743] Linn, J., «Generic Security Service Application Program Interface Version 2, Update 1», RFC 2743, January 2000.

[RFC3454] Hoffman, P. and M. Blanchet, «Preparation of Internationalized Strings («stringprep»)», RFC 3454, December 2002.

[RFC3629] Yergeau, F., «UTF-8, a transformation format of ISO 10646», STD 63, RFC 3629, November 2003.

[RFC4013] Zeilenga, K., «SASLprep: Stringprep Profile for User Names and Passwords», RFC 4013, February 2005.

[RFC4234] Crocker, D. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», RFC 4234, October 2005.

[ASCII] Coded Character Set—7-bit American Standard Code for Information Interchange, ANSI X3.4-1986.

[Unicode] The Unicode Consortium, «The Unicode Standard, Version 3.2.0» is defined by «The Unicode Standard, Version 3.0» (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended by the «Unicode Standard Annex #27: Unicode 3.1» (http://www.unicode.org/reports/tr27/) and by the «Unicode Standard Annex #28: Unicode 3.2» (http://www.unicode.org/reports/tr28/).

[CharModel] Whistler, K. and M. Davis, «Unicode Technical Report #17, Character Encoding Model», UTR17, <http://www.unicode.org/unicode/reports/tr17/>, August 2000.

[Glossary] The Unicode Consortium, «Unicode Glossary», <http://www.unicode.org/glossary/>.

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

[RFC3206] Gellens, R., «The SYS and AUTH POP Response Codes», RFC 3206, February 2002.

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

[RFC4301] Kent, S. and K. Seo, «Security Architecture for the Internet Protocol», RFC 4301, December 2005.

[RFC4346] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.1», RFC 4346¹³, April 2006.

[SASL-GSSAPI] Melnikov, A. (Editor), «The Kerberos V5 («GSSAPI») SASL Mechanism», Work in Progress¹⁴, May 2006.

[UTR36] Davis, M., «(Draft) Unicode Technical Report #36, Character Encoding Model», UTR17, <http://www.unicode.org/unicode/reports/tr36/>, February 2005.

[CRAM-MD5] Nerenberg, L., «The CRAM-MD5 SASL Mechanism», Work in Progress.

[DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, «Using Digest Authentication as a SASL Mechanism», Work in Progress, March 2006.

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

Этот документ является пересмотром RFC 2222, автором которого является John Myers.

Документ является результатом работы группы IETF Simple Authentication and Security Layer (SASL).

Перечисленные здесь люди внесли значительный вклад в подготовку документа: Abhijit Menon-Sen, Hallvard Furuseth, Jeffrey Hutzelman, John Myers, Luke Howard, Magnus Nystrom, Nicolas Williams, Peter Saint-Andre, RL ‘Bob’ Morgan, Rob Siemborski, Sam Hartman, Simon Josefsson, Tim Alsop, Tony Hansen.

Приложение A. Механизм SASL EXTERNAL

Данное приложение является нормативным.

Механизм EXTERNAL позволяет клиенту запросить у сервера использования свидетельств (credentials), созданных с применением внешних по отношению к механизму средств, для аутентификации клиента. Внешними средствами могут быть, например, службы IP Security [RFC4301] или TLS [RFC4346]. В отсутствие некой предварительной договоренности между клиентом и сервером клиент не может делать каких-либо предположений об использовании сервером внешних средств для получения клиентских свидетельств или о форме этих свидетельств. Например, клиент не может предполагать, что сервер будет использовать свидетельства, созданные клиентом с помощью TLS.

A.1. Техническая спецификация механизма EXTERNAL

Название механизма — «EXTERNAL».

Механизм не обеспечивает защитного уровня.

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

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

Клиент передает начальный отклик, содержащий строку идентификации для проверки полномочий в кодировке UTF-8 [RFC3629]. Этот отклик будет непустым, когда клиент запрашивает у сервера аутентификацию с использованием представленной (непустой) строки. Пустой отклик будет передаваться в тех случаях, когда клиент запрашивает у сервера аутентификацию с использованием аутентификационных свидетельств (authentication credentials).

Синтаксис начального отклика задается как значение <extern-initial-resp> описанное ниже в формате ABNF [RFC4234].

    external-initial-resp = authz-id-string
    authz-id-string       = *( UTF8-char-no-nul )
    UTF8-char-no-nul      = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4
    UTF8-1-no-nul         = %x01-7F

<UTF8-2>, <UTF8-3> и <UTF8-4> определены в [RFC3629].

Механизм не использует дополнительных запросов (challenge) и откликов.

Следовательно, сервер возвращает результат аутентификационного обмена.

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

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

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

A.2. Примеры SASL EXTERNAL

В этом параграфе рассматриваются примеры аутентификационного обмена с использованием механизма EXTERNAL. Эти примеры рассчитаны на то, чтобы помочь читателям понять приведенный выше текст. Примеры не являются определяющими. В примерах используется протокол ACAP¹⁵ [RFC2244].

Первый пример показывает использование механизма EXTERNAL с пустой строкой authorization identity. В этом примере начальный отклик не включается в запрос клиента на организацию аутентификационного обмена.

  S: * ACAP (SASL "DIGEST-MD5")
  C: a001 STARTTLS
  S: a001 OK "Begin TLS negotiation now"
     <согласование TLS, остальные команды выполняются на уровне TLS>
  S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL")
  C: a002 AUTHENTICATE "EXTERNAL"
  S: + ""
  C: + ""
  S: a002 OK "Authenticated"

Второй пример показывает использование механизма EXTERNAL со строкой authorization identity «fred@example.com». В этом примере клиентский запрос на организацию аутентификационного обмена содержит начальный отклик, Такой подход экономит время на один период кругового обхода.

 S: * ACAP (SASL "DIGEST-MD5")
 C: a001 STARTTLS
 S: a001 OK "Begin TLS negotiation now"
    <согласование TLS, остальные команды выполняются на уровне TLS >
 S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL")
 C: a002 AUTHENTICATE "EXTERNAL" {16+}
 C: fred@example.com
 S: a002 NO "Cannot assume requested authorization identity"

 

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

Механизм EXTERNAL не обеспечивает защиты; он уязвим по отношению к подменам (spoofing) со стороны клиента или сервера, активным атакам и подслушиванию. Этот механизм следует использовать лишь в тех случаях, когда имеется надежная защита.

Приложение B. Изменения по отношению к RFC 2222

Это приложение не является нормативным.

Текст RFC 2222 при создании этого документа был в значительной степени переработан.

RFC 2222 не указывал, что текст строк authorization identity использует символы Unicode, позволяя лишь символьные данные, подразумевающие, что authorization identity представляет собой строку октетов.

• Строки authorization identity сейчас определены как строки символов Unicode. Использование символа NUL (U+0000) не допускается. Хотя за определение формы строк authorization identity, синтаксис строк Unicode и связанную с ними семантику отвечает спецификация протокола, спецификация механизма несет ответственность за определение способа передачи строк Unicode в сеансе аутентификационного обмена.
• Удалена фраза «If so, when the client does not send data first, the initial challenge MUST be specified as being an empty challenge.¹⁶»

В механизм EXTERNAL были внесены следующие технические изменения:

• Строки authorization identity используют кодировку UTF-8.

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

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

Alexey Melnikov

Isode Limited

5 Castle Business Village

36 Station Road

Hampton, Middlesex,

TW12 2BX, United Kingdom

EMail: Alexey.Melnikov@isode.com

URI: http://www.melnikov.ca/

Kurt D. Zeilenga

OpenLDAP Foundation

EMail: Kurt@OpenLDAP.org

---

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

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

nmalykh@protokols.ru

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

Copyright (C) The Internet Society (2006).

К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.

Этот документ и содержащаяся в нем информация представлены «как есть» и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

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

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.

IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.

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

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

Network Working Group                                 M. Eisler, Ed.
Request for Comments: 4506                   Network Appliance, Inc.
STD: 67                                                     May 2006
Obsoletes: 1832
Category: Standards Track

XDR – стандарт внешнего представления данных

XDR: External Data Representation Standard

PDF

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

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

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

Copyright (C) The Internet Society (2006).

Аннотация

В этом описан стандартный протокол XDR¹ в его современном состоянии. Документ служит заменой RFC 1832.

1. Введение

XDR является стандартом для описания и представления данных. Он полезен при обмене данными между компьютерами с разной архитектурой и применяется при взаимодействии таких систем, как SUN WORKSTATION, VAX, IBM-PC, Cray. XDR работает на уровне представления ISO и является аналогом X.409, ISO ASN². Основное различие между ними заключается в том, что XDR использует неявную типизацию, а X.409 — явную.

XDR использует язык описания формата данных. Этот язык служит лишь для этой цели и не может применяться для программирования. Этот язык обеспечивает компактное описание сложных форматов данных. Графическое представление форматов (неформальный язык) с ростом сложности формата становится непонятным. Язык XDR похож на язык программирования C [KERN], как Courier [COUR] похож на Mesa. Протоколы типа ONC RPC³ и NFS⁴ используются в XDR для описания формата данных.

Стандарт XDR использует допущение о переносимости байтов (или октетов), которые определяются, как 8 битов данных. Конкретное устройство кодирует байты в различных средах так, чтобы другие устройства могли их декодировать без потери информации. Например, стандарт Ethernet использует формат представления little-endian [COHE], когда младший бит указывается первым.

2. Отличия от RFC 1832

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

3. Размер базового блока

Для представления всех объектов требуется блок из 4 байтов (или 32 битов) данных. Байты нумеруются от 0 до n-1. Байты считываются или записываются в некий байтовый поток так, что байт m всегда предшествует байту m+1. Если для хранения данных нужно n байтов и n не кратно 4, после n байтов данных будет размещено (r) (от 1 до 3 байтов⁵) с нулевыми значениями для того, чтобы общее число байтов было кратно 4.

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

        +--------+--------+...+--------+--------+...+--------+
        | байт 0 | байт 1 |...|байт n-1|    0   |...|    0   |   BLOCK
        +--------+--------+...+--------+--------+...+--------+
        |<-----------n байтов--------->|<------r байтов----->|
        |<------------n+r (где (n+r) mod 4 = 0)>------------>|

4. Типы данных XDR

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

Для каждого типа данных в языке показана общая декларация парадигмы. Отметим, что угловые скобки (< и >) означают последовательность данных переменного размера, а квадратные скобки ([ и ]) указывают последовательность данных фиксированного размера. Буквы n, m и r обозначают целые числа (integer). Полная спецификация языка и более формальные определения терминов (таких, как «идентификатор» и «декларация») приведены в разделе 6. Спецификация языка XDR.

Для некоторых типов данных приведены более конкретные примеры. Расширенные примеры описания данных даны в разделе 7. Пример описания данных XDR.

4.1. Integer — целое число

Целое число со знаком в XDR представляет собой 32 бита данных, с помощью которых можно представить значения в диапазоне [-2147483648, 2147483647]. Целое число представляется в форме дополнения до двух. Старший байт имеет номер 0, младший — 3. Представление целых чисел показано ниже:

         int identifier;

           (MSB)                   (LSB)
         +-------+-------+-------+-------+
         |байт 0 |байт 1 |байт 2 |байт 3 |                      INTEGER
         +-------+-------+-------+-------+
         <------------32 бита------------>

4.2. Unsigned Integer — целое число без знака

Целое число без знака в XDR представляет собой 32 бита, с помощью которых можно представить значения из диапазона [0, 4294967295]. Старший байт числа имеет номер 0, младший — 3. Представление показано ниже.

            unsigned int identifier;
              (MSB)                   (LSB)
            +-------+-------+-------+-------+
            |байт 0 |байт 1 |байт 2 |байт 3 |           UNSIGNED INTEGER
            +-------+-------+-------+-------+
            <------------32 бита------------>

4.3. Enumeration — перечисление

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

enum { name-identifier = constant, ... } identifier;

Например, три цвета red, yellow, blue можно описать, как перечисляемый тип:

enum { RED = 2, YELLOW = 3, BLUE = 5 } colors;

Будет ошибкой представление в качестве перечисляемого любого целого числа, не указанного при объявлении типа.

4.4. Boolean — логическое значение

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

bool identifier;

Это эквивалентно:

enum { FALSE = 0, TRUE = 1 } identifier;

4.5. Hyper Integer и Unsigned Hyper Integer

Стандарт также определяет 64-битовые (8 батов) целые числа, называемые hyper integer и unsigned hyper integer. Эти форматы являются простым расширением описанных выше форматов integer и unsigned integer. Числа представляются в форме дополнения до двух. Старший и младший байты имеют номера 0 и 7, соответственно.

   hyper identifier; unsigned hyper identifier;

        (MSB)                                                   (LSB)
      +-------+-------+-------+-------+-------+-------+-------+-------+
      |байт 0 |байт 1 |байт 2 |байт 3 |байт 4 |байт 5 |байт 6 |байт 7 |
      +-------+-------+-------+-------+-------+-------+-------+-------+
      <----------------------------64 бита---------------------------->
                                                 HYPER INTEGER
                                                 UNSIGNED HYPER INTEGER

4.6. Floating-Point — число с плавающей запятой

Стандарт определяет тип данных с плавающей запятой — float (32 бита или 4 байта). Для этого типа используется представление IEEE для нормализованных чисел одинарной точности с плавающей запятой [IEEE]. Приведенные ниже три поля определяют число с плавающей запятой.

S — знак (0 для положительных чисел, 1 для отрицательных). 1 бит.

E — показатель степени (основание 2). 8 битов. Степени 0 соответствует значение 127 (Bias).

F — дробная часть мантиссы (основание 2). 23 бита.

Следовательно, число с плавающей запятой можно выразить формулой:

(-1)S * 2(E-Bias) * 1,F

Числа этого типа декларируются следующим образом:

         float identifier;

         +-------+-------+-------+-------+
         |байт 0 |байт 1 |байт 2 |байт 3 |              SINGLE-PRECISION
         S|   E   |           F          |         FLOATING-POINT NUMBER
         +-------+-------+-------+-------+
         1|<- 8 ->|<-------23 бита------>|
         <------------32 бита------------>

Как старший и младший байты целого числа имеют номера 0 и 3, старший и младший биты числа одинарной точности с плавающей запятой имеют номера 0 и 31. Первый (старший) бит полей S, E и F имеет смещение 0, 1 и 9, соответственно. Отметим, что эти смещения указывают математические позиции битов, а не их реальное расположение, которое зависит от среды.

Представление 0 со знаком, бесконечности со знаком (переполнение) и денормализованных чисел (опустошение⁶) описаны в стандарте [IEEE]. В соответствии со спецификацией IEEE, значение NaN⁷ зависит от системы и не должно интерпретироваться в XDR, как нечто, отличное от NaN.

4.7. Double-Precision Floating-Point (двойная точность)

Стандарт определяет представления чисел с плавающей запятой двойной точности — double (64 бита или 8 байтов). Представление использует стандарт IEEE для нормализованных чисел с плавающей запятой двойной точности [IEEE]. Для представления чисел используется три поля:

S — знак (0 для положительных чисел, 1 для отрицательных). 1 бит.

E — показатель степени (основание 2). 11 битов. Степени 0 соответствует значение 1023 (Bias).

F — дробная часть мантиссы (основание 2). 52 бита.

Следовательно, число с плавающей запятой можно выразить формулой:

(-1)S * 2(E-Bias) * 1,F

Числа этого типа декларируются следующим образом:

         double identifier;

         +------+------+------+------+------+------+------+------+
         |байт 0|байт 1|байт 2|байт 3|байт 4|байт 5|байт 6|байт 7|
         S|    E   |                    F                        |
         +------+------+------+------+------+------+------+------+
         1|<--11-->|<-----------------52 бита------------------->|
         <-----------------------64 бита------------------------->
                                        DOUBLE-PRECISION FLOATING-POINT

Как старший и младший байты целого числа имеют номера 0 и 3, старший и младший биты числа двойной точности с плавающей запятой имеют номера 0 и 63. Первый (старший) бит полей S, E и F имеет смещение 0, 1 и 12, соответственно. Отметим, что эти смещения указывают математические позиции битов, а не их реальное расположение, которое зависит от среды.

Представление 0 со знаком, бесконечности со знаком (переполнение) и денормализованных чисел (опустошение⁸) описаны в стандарте [IEEE]. В соответствии со спецификацией IEEE, значение NaN⁹ зависит от системы и не должно интерпретироваться в XDR, как нечто, отличное от NaN.

4.8. Quadruple-Precision Floating-Point (4-кратная точность)

Стандарт определяет представления чисел с плавающей запятой 4-кратной точности — quadruple (128 битов или 16 байтов). Представление чисел аналогично представлению чисел с плавающей запятой одинарной или двойной точности с использованием формата IEEE. Для представления чисел используется три поля:

S — знак (0 для положительных чисел, 1 для отрицательных). 1 бит.

E — показатель степени (основание 2). 15 битов. Степени 0 соответствует значение 16383 (Bias).

F — дробная часть мантиссы (основание 2). 112 битов.

Следовательно, число с плавающей запятой можно выразить формулой:

(-1)S * 2(E-Bias) * 1,F

Числа этого типа декларируются следующим образом:

         quadruple identifier;

         +------+------+------+------+------+------+-...--+------+
         |байт 0|байт 1|байт 2|байт 3|байт 4|байт 5| ...  |байт15|
         S|    E       |                  F                      |
         +------+------+------+------+------+------+-...--+------+
         1|<----15---->|<-------------112 битов----------------->|
         <-----------------------128 битов----------------------->
                                      QUADRUPLE-PRECISION FLOATING-POINT

Как старший и младший байты целого числа имеют номера 0 и 3, старший и младший биты числа 4-кратной точности с плавающей запятой имеют номера 0 и 127. Первый (старший) бит полей S, E и F имеет смещение 0, 1 и 16, соответственно. Отметим, что эти смещения указывают математические позиции битов, а не их реальное расположение, которое зависит от среды.

Представление 0 со знаком, бесконечности со знаком (переполнение) и денормализованных чисел аналогичны числам с плавающий запятой одинарной и двойной точности [SPAR], [HPRE]. В соответствии со спецификацией IEEE, значение NaN для чисел 4-кратной точности зависит от системы и не должно интерпретироваться в XDR, как нечто, отличное от NaN.

4.9. Неинтерпретируемые данные фиксированного размера

Иногда между машинами требуются передавать не интерпретируемые данные фиксированного размера. Такие «непрозрачные» (opaque) данные декларируются следующим образом:

opaque identifier[n];

где постоянная n задает (фиксированное) число байтов, которые должны содержаться в непрозрачных данных. Если n не кратно 4, после n следует r (от 1¹⁰ до 3) байтов с нулевыми значениями, служащих для выравнивания размера до значения, кратного 4.

          0        1     ...
      +--------+--------+...+--------+--------+...+--------+
      | байт 0 | байт 1 |...|байт n-1|    0   |...|    0   |
      +--------+--------+...+--------+--------+...+--------+
      |<-----------n байтов--------->|<------r байтов----->|
      |<------------n+r (где (n+r) mod 4 = 0)------------->|
                                                   FIXED-LENGTH OPAQUE

4.10. Неинтерпретируемые данные переменного размера

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

Байт m в последовательности всегда предшествует байту m+1, а байт 0 всегда следует за полем размера (счетчик). Если значение n не кратно 4, к последовательности добавляется r (от 1¹¹ до 3) байтов со значением 0 для выравнивания размера по границе 4-байтового слова. Непрозрачные данные переменного размера декларируются следующим образом:

opaque identifier<m>;

или

opaque identifier<>;

Постоянная m обозначает верхнюю границу числа байтов, которые могут содержаться в последовательности. Если m не задано (второй вариант декларации), предполагается максимальный размер 2³² — 1.

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

         opaque filedata<8192>;

            0     1     2     3     4     5   ...
         +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
         |        размер n       |байт0|байт1|...| n-1 |  0  |...|  0  |
         +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
         |<-------4 байта------->|<------n байтов----->|<---r байтов-->|
                                 |<-----n+r (где (n+r) mod 4 = 0)----->|
                                                  VARIABLE-LENGTH OPAQUE

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

4.11. String — строка

Стандарт определяет строку из n (с номерами от 0 до n-1) символов ASCII, где размер строки задается целым числом без знака n (см. выше), а за ним следует n байтов самой строки. Байт m всегда предшествует в строке байту m+1, а байт 0 всегда следует за полем размера строки. Если значение n не кратно 4, после n байтов к строке добавляется r (от 1¹ до 3) байтов заполнения для выравнивания до размера, кратного 4. Строка байтов декларируется, как:

string object<m>;

или

string object<>;

Постоянная m обозначает верхнюю границу числа байтов, которые могут содержаться в последовательности. Если m не задано (второй вариант декларации), предполагается максимальный размер 2³² — 1. Постоянную m обычно можно найти в спецификации протокола. Например, протокол подачи может декларировать максимальный размер имени файла 255 байтов, как показано ниже:

         string filename<255>;

            0     1     2     3     4     5   ...
         +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
         |        размер n       |байт0|байт1|...| n-1 |  0  |...|  0  |
         +-----+-----+-----+-----+-----+-----+...+-----+-----+...+-----+
         |<-------4 байта------->|<------n байтов----->|<---r байтов-->|
                                 |<-----n+r (где (n+r) mod 4 = 0)----->|
                                                                  STRING

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

4.12. Массив фиксированного размера

Декларация массива фиксированного размера из однородных элементов имеет вид:

type-name identifier[n];

Массивы фиксированного размера с элементами, имеющими номера от 0 до n-1 представляются путем кодирования (представления) отдельных элементов в порядке роста порядковых номеров от 0 до n-1. Размер каждого элемента в байтах кратен 4. Все элементы массива являются однотипными, но их размеры могут различаться. Например, в массиве строк все элементы имеют тип string, но могут различаться по размерам.

         +---+---+---+---+---+---+---+---+...+---+---+---+---+
         |   элемент 0   |   элемент 1   |...|  элемент n-1  |
         +---+---+---+---+---+---+---+---+...+---+---+---+---+
         |<--------------------n элементов------------------>|

                                               FIXED-LENGTH ARRAY

 

4.13. Массив переменного размера

Counted-массивы обеспечивают возможность создания массивов с переменным числом однотипных элементов. Массив представляется числом элементов n (целое число без знака), за которым следуют элементы массива с номерами от 0 до n-1. Декларация массива переменного размера имеет вид:

type-name identifier<m>;

или

type-name identifier<>;

Постоянная m задает максимально допустимое число элементов массива. Если значение m не задано (второй вариант) предполагается максимальное число элементов 2³² — 1.

           0  1  2  3
         +--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+
         |     n     | элемент 0 | элемент 1 |...|элемент n-1|
         +--+--+--+--+--+--+--+--+--+--+--+--+...+--+--+--+--+
         |<-4 байта->|<--------------n элементов------------>|
                                                         COUNTED ARRAY

Если значение n превышает максимальное число элементов массива, возникает ошибка.

4.14. Structure — структура

Структуры декларируются следующим образом:

         struct {
            component-declaration-A;
            component-declaration-B;
            ...
         } identifier;

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

         +-------------+-------------+...
         | компонент A | компонент B |...                      STRUCTURE
         +-------------+-------------+...

4.15. Discriminated Union — объединение с дискриминантом

Объединение этого типа состоит из дискриминанта, за которым следует тип, выбранный из множества предопределенных типов в соответствии со значением дискриминанта. Дискриминант может относиться к типу int, unsigned int или перечисляемому типу (например, bool). Типам компонент объединения (их называют arm — ветвь) предшествуют значения дискриминанта, определяющие их представление. Объединение с дискриминантом декларируется следующим образом:

         union switch (discriminant-declaration) {
         case discriminant-value-A:
            arm-declaration-A;
         case discriminant-value-B:
            arm-declaration-B;
         ...
         default: default-declaration;
         } identifier;

За каждым ключевым словом case следует корректное значение дискриминанта. Принятая по умолчанию ветвь (arm) является необязательной. Если она не задана, корректное представление объединения не может принимать неуказанных значений дискриминанта. Размер принимаемой ветви всегда кратен 4 байтам.

Объединение с дискриминантом представляется дискриминантом, за которым следует представление принимаемой ветви.

           0   1   2   3
         +---+---+---+---+---+---+---+---+
         |  discriminant |  implied arm  |          DISCRIMINATED UNION
         +---+---+---+---+---+---+---+---+
         |<---4 байта--->|

 

4.16. Void — пустой тип

В XDR пустой (void) тип имеет размер 0 байтов. Пустой тип полезен для описания операций, которые не принимают данных на входе и/или не возвращают их на выходе. Этот тип также полезен в объединениях, где некоторые ветви включают данные, а другие не включают. Декларация пустого типа имеет вид:

void;

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

           ++
           ||                                                     VOID
           ++
         --><-- 0 байтов

 

4.17. Constant — константа

Декларация константы имеет вид:

const name-identifier = n;

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

const DOZEN = 12;

4.18. Typedef — определение типа

Определение типа (typedef) не служит для декларирования каких-либо данных, но позволяет определять новые идентификаторы для декларирования данных. Синтаксис определения типа имеет вид:

typedef declaration;

Имя нового типа реально является именем переменной в декларативной части typedef. Например, можно определить новое имя типа eggbox на основе существующего типа egg:

typedef egg eggbox[DOZEN];

Переменные, декларируемые с использованием нового имени типа, имеют тот же тип, который указан для нового имени типа в typedef, если рассматривать его, как переменную. Например, две приведенных ниже декларации являются эквивалентными объявлениями переменной fresheggs:

eggbox fresheggs; egg fresheggs[DOZEN];

Для случаев, когда typedef включает определение struct, enum или union, существует другой (предпочтительный) синтаксис. В общем случае typedef вида:

typedef <<struct, union, or enum definition>> identifier;

можно преобразовать в другую форму, удалив часть typedef и поместив идентификатор после ключевого слова struct, union или enum вместо указания идентификатора в конце декларации. Ниже показаны два варианта определения типа bool:

         typedef enum {    /* использование typedef */
            FALSE = 0,
            TRUE = 1
         } bool;

         enum bool {       /* предпочтительный вариант */
            FALSE = 0,
            TRUE = 1
         };

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

4.19. Optional-Data

Optional-data представляет собой один из вариантов объединения, который используется достаточно часто и по этой причине для него имеется специальный синтаксис декларирования. Декларация вида:

type-name *identifier;

эквивалентна декларации объединения:

         union switch (bool opted) {
         case TRUE:
            type-name element;
         case FALSE:
            void;
         } identifier;

Она также эквивалентна приведенной ниже декларации массива переменного размера, поскольку логическую переменную opted можно рассматривать, как размер массива:

type-name identifier<1>;

Тип Optional-data не интересен сам по себе, но он часто применяется для описания рекурсивных структур данных типа связанных списков или деревьев. Например, ниже определен тип stringlist, представляющий собой список (возможно пустой) строк произвольной длины:

        struct stringentry {
           string item<>;
           stringentry *next;
        };

        typedef stringentry *stringlist;

Эту декларацию можно заменить эквивалентной декларацией объединения:

         union stringlist switch (bool opted) {
         case TRUE:
            struct {
               string item<>;
               stringlist next;
            } element;
         case FALSE:
            void;
         };

 

или массива переменного размера:

struct stringentry {
string item<>;
stringentry next<1>;
};
typedef stringentry stringlist<1>;

Оба эти варианта «скрывают» тип stringlist, поэтому явная декларация optional-data является более предпочтительной. Тип optional-data также коррелирует с представлением рекурсивных структур данных в языках программирования высокого уровня (типа Pascal или C) с помощью указателей. Фактически синтаксис совпадает с синтаксисом языка C для указателей.

4.20. Направления дальнейшего развития

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

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

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

5. Обсуждение

(1) Зачем нужен язык описания данных? Чем плохи диаграммы?

Существует множество преимуществ использования языков описания данных типа XDR по сравнению с использованием диаграмм. Языки являются более формальными, чем диаграммы и позволяют снизить число неоднозначностей в описаниях. Язык проще для понимания и позволяет меньше думать о мелких деталях битового представления данных. Кроме того, существуют близкие аналогии между типами XDR и типами данных в языках высокого уровня таких, как C или Pascal. Это существенно упрощает реализацию модулей кодирования и декодирования данных XDR. Наконец, спецификация языка, как таковая, представляет собой строку ASCII, которая может предаваться между машинами для интерпретации «на лету».

(2) Почему в XDR применяется только один порядок байтов?

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

(3) Почему XDR использует порядок байтов big-endian, а не little-endian?

Разве это «справедливо» по отношению с машинам типа VAX(r), которые вынуждены преобразовывать порядок байтов?

Выбор любого из двух порядков будет «несправедливым» по отношению к части машин. Многие архитектуры, включая Motorola 68000 и IBM 370, поддерживают порядок байтов big-endian.

(4) Почему XDR использует 4-байтовые блоки?

Выбор размера блока XDR является компромиссом. Выбор меньшего размера (скажем, 2) позволил бы представлять более экономно, но вызвал бы проблемы на машинах, которые не выравнивают данные по такой границе. Выбор большего размера (скажем, 8) обеспечил бы соответствие с выравниванием данных практически на всех машинах, но привел бы к неоправданному росту заполнения. Поэтому было выбрано компромиссное значение. 4-байтовые блоки обеспечивают достаточно экономное представление данный и выравнивание по 4-байтовой границе поддерживается большинством машин за исключением такой «экзотики», как 8-байтовые Cray.

(5) Зачем данные переменного размера дополняются нулями?

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

(6) Почему не используется явной типизации данных?

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

6. Спецификация языка XDR

6.1. Соглашения о нотации

В данной спецификации для описания языка XDR применяется расширенная нотация BNF¹². Ниже приведено краткое описание нотации:

1. Символы |, (, ), [, ], » и * имеют специальные значения.

2. Терминальными символами являются строки любых символов, заключенные в двойные кавычки («).

3. Нетерминальными символами являются строки символов, не имеющих специального значения.

4. Варианты разделяются символом |.

5. Необязательные элементы заключаются в квадратные скобки.

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

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

В качестве примера расмотрим запись:

"a " "very" (", " "very")* [" cold " "and "] " rainy " ("day" | "night")

которой соответствует бесконечное множество строк. Варианты таких строк включают:

"a very rainy day"
"a very, very rainy day"
"a very cold and rainy day"
"a very, very, very cold and rainy night"

6.2. Лексические замечания

1. Комментарии начинаются символами /* и завершаются символами */.

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

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

4. Десятичная константа выражает число по основанию 10 и представляет собой последовательность цифр. Первая цифра последовательности должна быть отлична от 0, последовательности может предшествовать знак минус (-).

5. Шестнадцатеричная константа выражает число по основанию 16 и должна начинаться с последовательности 0x, за которой следует одна или множество шестнадцатеричных «цифр» (A, B, C, D, E, F, a, b, c, d, e, f, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9).

6. Восьмеричная константа выражает число по основанию 8 и всегда начинается с символа 0, за которым следует одна или множество восьмеричных цифр (0, 1, 2, 3, 4, 5, 6, 7).

6.3. Синтаксическая информация

Декларация:

type-specifier identifier
| type-specifier identifier "[" value "]"
| type-specifier identifier "<" [ value ] ">"
| "opaque" identifier "[" value "]"
| "opaque" identifier "<" [ value ] ">"
| "string" identifier "<" [ value ] ">"
| type-specifier "*" identifier
| "void"

Значение:

constant
| identifier

Константа:

decimal-constant | hexadecimal-constant | octal-constant

Спецификатор типа:

[ "unsigned" ] "int"
| [ "unsigned" ] "hyper"
| "float"
| "double"
| "quadruple"
| "bool"
| enum-type-spec
| struct-type-spec
| union-type-spec
| identifier

Спецификация перечисляемого типа:

"enum" enum-body

Перечисление:

"{"
( identifier "=" value )
( "," identifier "=" value )*
"}"

Спецификация структуры:

"struct" struct-body

Структура:

"{"
( declaration ";" )
( declaration ";" )*
"}"

Спецификация объединения:

"union" union-body

Объединение:

"switch" "(" declaration ")" "{"
case-spec
case-spec *
[ "default" ":" declaration ";" ]
"}"

Спецификация вариантов:

( "case" value ":")
( "case" value ":") *
declaration ";"

Определение постоянной:

"const" identifier "=" constant ";"

Определение типа:

"typedef" declaration ";"
| "enum" identifier enum-body ";"
| "struct" identifier struct-body ";"
| "union" identifier union-body ";"

Определение:

type-def
| constant-def

Спецификация:

definition *

6.4. Замечания по синтаксису

1. Следующие слова являются ключевыми и не могут использоваться в качестве идентификаторов: bool, case, const, default, double, quadruple, enum, float, hyper, int, opaque, string, struct, switch, typedef, union, unsigned и void.

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

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

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

5. Дискриминант объединения должен иметь тип, приводимый к целому числу. Т. е. он может относиться к типам int, unsigned int, bool, перечисляемым или typedef. Такое же требованием применяется к вариантам. Кроме того, каждое значение варианта может использоваться в декларации объединения не более одного раза.

7. Пример описания данных XDR

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

         const MAXUSERNAME = 32;     /* максимальный размер имени пользователя */
         const MAXFILELEN = 65535;   /* максимальный размер файла              */
         const MAXNAMELEN = 255;     /* максимальный размер имени файла        */

         /*
          * Типы файлов:
          */
         enum filekind {
            TEXT = 0,       /* ascii-данные */
            DATA = 1,       /* raw-данные   */
            EXEC = 2        /* исполняемый  */
         };

         /*
          * Информация о файлах по их типам
          */
         union filetype switch (filekind kind) {
         case TEXT:
            void;                           /* нет дополнительной информации */
         case DATA:
            string creator<MAXNAMELEN>;     /* создатель данных              */
         case EXEC:
            string interpretor<MAXNAMELEN>; /* программный интерпретатор     */
         };

         /*
          * Полный файл:
          */
         struct file {
            string filename<MAXNAMELEN>; /* имя файла          */
            filetype type;               /* информация о файле */
            string owner<MAXUSERNAME>;   /* владелец файла     */
            opaque data<MAXFILELEN>;     /* дата файла         */

 

Предположим, что пользователь с именем john хочет сохранить свою программу sillyprog на языке lisp, содержащую просто строку данных (quit). Ниже показано представление файла:

Смещение	HEX-байты	ASCII	Комментарии
0	00 00 00 09	….	Размер имени файла (9)
4	73 69 6c 6c	sill	Символы имени файла
8	79 70 72 6f	ypro	… дополнительные символы …
12	67 00 00 00	g…	… и 3 байта заполнения (0)
16	00 00 00 02	….	Тип файла (EXEC = 2)
20	00 00 00 04	….	Размер имени интерпретатора (4)
24	6c 69 73 70	lisp	Имя интерпретатора
28	00 00 00 04	….	Размер имени владельца (4)
32	6a 6f 68 6e	john	Имя владельца
36	00 00 00 06	….	Число байтов данных в файле
40	28 71 75 69	(qui	Байты данных файла …
44	74 29 00 00	t)..	… и 2 байта заполнения (0)

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

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

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

• Атаки на переполнение буфера. По возможности протоколы следует определять с явными пределами (путем использования нотации <[ значение ]> вместо < >) для элементов с типами данных переменного размера. Независимо от возможности явного ограничения переменных размеров элемента данного протокола, декодеры должны проверять размеры данных на входе в части предотвращения выхода за размеры приемных буферов.

• Нулевые октеты в значении типа string. Если естественным для декодера форматом являются строки, завершающиеся nul-символом, видимый размер декодированного объекта будет меньше объема памяти, выделенного для строки. Некоторые интерфейсы возвращения (deallocation) памяти поддерживают параметр размера. При обращении к такому интерфейсу вызывающая сторона будет скорей всего передавать размер строки до первого nul-символа, добавляя к нему 1. Это несоответствие может приводить к «утечке» памяти (поскольку возвращаться памяти будет меньше, чем было выделено), которая может приводить к системным отказам и атакам с целью отказа в обслуживании.

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

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

              struct m {
                int x;
                struct m *next;
              };

Программа кодирования или декодирования может рекурсивно вызывать сама себя каждый арз при обнаружении другого элемента struct m. Атакующий может создать длинный связный список элементов struct m в запросе или отклике и такой список может привести к переполнению стека для кодера или декодера. Программы кодирования-декодирования следует создавать без использования рекурсии или ограничивать длину списков¹³.

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

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

10. Торговые знаки и их владельцы

SUN WORKSTATION Sun Microsystems, Inc.

VAX Hewlett-Packard Company

IBM-PC International Business Machines Corporation

Cray Cray Inc.

NFS Sun Microsystems, Inc.

Ethernet Xerox Corporation.

Motorola 68000 Motorola, Inc.

IBM 370 International Business Machines Corporation

11. Стандарт ANSI/IEEE 754-1985

Определения NaN, нулей со знаком, бесконечности и денормализованных чисел для удобства заимствованы из [IEEE]. Определения чисел с плавающей запятой 4-кратной точности аналогичны определениям чисел обычной и двойной точности в [IEEE].

Ниже S обозначает бит знака, E — показатель степени, а F — дробную часть числа. Символ u указывает бит с неопределенным значения (0 или 1).

Для чисел с плавающей запятой:

Тип	S (1бит)	E (8 битов)	F (23 бита)
signalling NaN	u	255 (макс) (не менее 1 бита)	.0uuuuu—u
quiet NaN	u	255 (макс)	.1uuuuu—u
Отрицательная бесконечность	1	255 (макс)	.000000—0
Положительная бесконечность	0	255 (макс)	.000000—0
Отрицательный 0	1	0	.000000—0
Положительный 0	0	0	.000000—0

Для чисел с плавающей запятой двойной точности:

Тип	S (1бит)	E (11 битов)	F (52 бита)
signalling NaN	u	2047 (макс) (не менее 1 бита)	.0uuuuu—u
quiet NaN	u	2047 (макс)	.1uuuuu—u
Отрицательная бесконечность	1	2047 (макс)	.000000—0
Положительная бесконечность	0	2047 (макс)	.000000—0
Отрицательный 0	1	0	.000000—0
Положительный 0	0	0	.000000—0

Для чисел с плавающей запятой 4-кратной точности:

Тип	S (1бит)	E (15 битов)	F (112 битов)
signalling NaN	u	32767 (макс) (не менее 1 бита)	.0uuuuu—u
quiet NaN	u	32767 (макс)	.1uuuuu—u
Отрицательная бесконечность	1	32767 (макс)	.000000—0
Положительная бесконечность	0	32767 (макс)	.000000—0
Отрицательный 0	1	0	.000000—0
Положительный 0	0	0	.000000—0

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

Точность	Показатель	Значение
Одинарная	0	(-1)S * 2-126 * 0,F
Двойная	0	(-1)S * 2-1022 * 0,F
Четырехкратная	0	(-1)S * 2-16382 * 0,F

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

[IEEE] «IEEE Standard for Binary Floating-Point Arithmetic», ANSI/IEEE Standard 754-1985, Institute of Electrical and Electronics Engineers, August 1985.

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

[KERN] Brian W. Kernighan & Dennis M. Ritchie, «The C Programming Language», Bell Laboratories, Murray Hill, New Jersey, 1978.

[COHE] Danny Cohen, «On Holy Wars and a Plea for Peace», IEEE Computer, October 1981.

[COUR] «Courier: The Remote Procedure Call Protocol», XEROX Corporation, XSIS 038112, December 1981.

[SPAR] «The SPARC Architecture Manual: Version 8», Prentice Hall, ISBN 0-13-825001-4.

[HPRE] «HP Precision Architecture Handbook», June 1987, 5954-9906.

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

Bob Lyon представлял Sun в рабочей группе ONC RPC в 1980-х. Компания Sun Microsystems, Inc. значится разработчиком RFC 1014. Raj Srinivasan и другие участники рабочей группы ONC RPC редактировали RFC 1014 в RFC 1832, который послужил основой для данного документа. Mike Eisler и Bill Janssen представили обзоры по реализациям данного стандарта. Kevin Coffman, Benny Halevy и Jon Peterson рассмотрели документ и дали свои замечания. Peter Astrand и Bryan Olson отметили несколько ошибок в RFC 1832, которые были исправлены в этом документе.

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

Mike Eisler

5765 Chase Point Circle

Colorado Springs, CO 80919

USA

Phone: 719-599-9026

EMail: email2mre-rfc4506@yahoo.com

Отправляйте комментарии по адресу: nfsv4@ietf.org

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

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

nmalykh@protokols.ru

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

Copyright (C) The Internet Society (2006).

К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.

Этот документ и содержащаяся в нем информация представлены «как есть» и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

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

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.

IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.

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

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

---

Network Working Group                                   S. Leontiev, Ed.
Request for Comments: 4491                                    CRYPTO-PRO
Updates: 3279                                        D. Shefanovski, Ed.
Category: Standards Track                        Mobile TeleSystems OJSC
                                                                May 2006


           Using the GOST R 34.10-94, GOST R 34.10-2001, and
                  GOST R 34.11-94 Algorithms with the
               Internet X.509 Public Key Infrastructure
                      Certificate and CRL Profile

PDF

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

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

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

Copyright (C) The Internet Society (2006).

Аннотация

Этот документ дополняет RFC 3279, описывая форматы представления, идентификаторы и форматы параметров для алгоритмов GOST R 34.10-94, GOST R 34.10-2001 и GOST R 34.11-94 для их применения в инфраструктуре открытых ключей Internet X.509 (PKI¹).

1. Введение

Этот документ дополняет RFC 3279 [PKALGS] и описывает соглашения по использованию алгоритмов подписи GOST R 34.10-94 [GOST3431095, GOSTR341094] и GOST R 34.10-2001 [GOST3431004, GOSTR341001], алгоритмов создания производных ключей VKO GOST R 34.10-94 и VKO GOST R 34.10-2001, а также необратимых хэш-функций GOST R 34.11-94 [GOST3431195, GOSTR341194] в инфраструктуре открытых ключей Internet X.509 PKI [PROFILE].

Данный документ обеспечивает дополнительную информацию и спецификации, требуемые российским «Соглашением о совместимости СКЗИ».

Указаны идентификаторы алгоритмов и связанные параметры для субъектов открытых ключей, которые используют алгоритмы GOST R 34.10-94 [GOSTR341094]/VKO GOST R 34.10-94 [CPALGS] и GOST R 34.10-2001 [GOSTR341001]/VKO GOST R 34.10-2001 [CPALGS], а также формат представления для подписей, создаваемых этими алгоритмами. Указаны также идентификаторы алгоритмов для использования необратимой хэш-функции GOST R 34.11-94 с алгоритмами подписи GOST R 34.10-94 и GOST R 34.10-2001.

Данная спецификация определяет содержимое полей signatureAlgorithm, signatureValue, signature и subjectPublicKeyInfo в сертификатах и списках отзыва (CRL) X.509. Для каждого алгоритма представлены подходящие варианты расширения сертификата keyUsage.

Модули ASN.1, включающие все использованные в этом документе определения, можно найти в [CPALGS].

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

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

2. Поддержка алгоритмов

В этом разделе приведен обзор криптографических алгоритмов, которые могут использоваться с сертификатами Internet X.509 и профилями CRL [PROFILE]. Описаны необратимые хэш-функции и алгоритмы цифровой подписи, которые могут применяться для подписывания сертификатов и CRL, а также приведены идентификаторы объектов (OID) и представления ASN.1 для открытых ключей, содержащихся в сертификатах.

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

2.1. Необратимая хэш-функция

В этом разделе описано использование необратимой и не имеющей коллизий хэш-функции GOST R 34.11-94, единственной, которая может применяться с алгоритмами цифровой подписи GOST R 34.10-94/2001. Данные, которые хэшируются для подписания сертификатов и CRL, полностью описаны в RFC 3280 [PROFILE].

2.1.1. Необратимая хэш-функция GOST R 34.11-94

Хэш-функция GOST R 34.11-94 разработана Главным управлением безопасности связи Федерального агентства правительственной связи и информации, а также Всероссийским НИИ Стандартизации. Алгоритм GOST R 34.11-94 дает на выходе 256-битовое хэш-значение для произвольного конечного размера входных данных. Данный документ не включает полной спецификации GOST R 34.11-94, которую можно найти в [GOSTR341194] на русском языке. В работе [Schneier95], параграф 18.11, стр. 454 приведено краткое техническое описание алгоритма на английском языке.

Данная функция должна всегда применяться с набором параметров, идентифицируемым id-GostR3411-94-CryptoProParamSet (см. параграф 8.2 [CPALGS]).

2.2. Алгоритмы подписи

Соответствующие данной спецификации УЦ могут использовать алгоритмы подписи GOST R 34.10-94 и GOST R 34.10-2001 для подписывания сертификатов и CRL.

Эти алгоритмы подписи во всех случаях должны применяться с необратимой хэш-функцией GOST R 34.11-94 как указано в [GOSTR341094] b [GOSTR341001].

В этом разделе определены идентификаторы и параметры алгоритмов для использования в поле signatureAlgorithm структур Certificate и CertificateList.

2.2.1. Алгоритм подписи GOST R 34.10-94

Алгоритм GOST R 34.10-94 разработан Главным управлением безопасности связи Федерального агентства правительственной связи и информации, а также Всероссийским НИИ Стандартизации. В данном документе не приводится полной спецификации алгоритма GOST R 34.10-94, которая дана в [GOSTR341094] на русском языке, а краткое описание на английском языке содержится в работе [Schneier95] (глава 20.3, стр. 495).

Идентификатор объекта ASN.1 для этого алгоритма цифровой подписи приведен ниже.

   id-GostR3411-94-with-GostR3410-94 OBJECT IDENTIFIER ::=
      { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) gostR3411-94-with-gostR3410-94(4) }

Если идентификатор алгоритма id-GostR3411-94-with-GostR3410-94 указан в поле algorithm структуры AlgorithmIdentifier, поле parameters нужно опускать. Т. е., в качестве AlgorithmIdentifier нужно указывать последовательность (SEQUENCE) из одной компоненты OBJECT IDENTIFIER id-GostR3411-94-with-GostR3410-94.

Алгоритм электронной подписи GOST R 34.10-94 создает цифровую подпись в форме двух 256-битовых значений r’ и s. Их представление строками октетов будет занимать 64 октета, из которых первые 32 содержат значение s в представлении big-endian, а вторые 32 октета содержат значение r’ в том же представлении.

Это определение значения подписи напрямую применимо для CMS [CMS], где такие значения представляются в виде строк октетов. Однако значения подписей в сертификатах и CRL [PROFILE] представляются в форме битовых строк и представление в виде строк октетов должно конвертироваться.

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

2.2.2. Алгоритм подписи GOST R 34.10-2001

Алгоритм GOST R 34.10-2001 разработан Главным управлением безопасности связи Федерального агентства правительственной связи и информации, а также Всероссийским НИИ Стандартизации. Данный документ не содержит полной спецификации GOST R 34.10-2001, она приведена в [GOSTR341001] (на русском языке).

Идентификатор объекта ASN.1 для этого алгоритма цифровой подписи приведен ниже.

   id-GostR3411-94-with-GostR3410-2001 OBJECT IDENTIFIER ::=
    { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) gostR3411-94-with-gostR3410-2001(3) }

Если идентификатор алгоритма id-GostR3411-94-with-GostR3410-2001 указан в поле algorithm структуры AlgorithmIdentifier, поле parameters нужно опускать. Т. е., в качестве AlgorithmIdentifier нужно указывать последовательность (SEQUENCE) из одной компоненты OBJECT IDENTIFIER id-GostR3411-94-with-GostR3410-2001.

Алгоритм электронной подписи GOST R 34.10-2001 создает цифровую подпись в форме двух 256-битовых значений r и s. Их представление строками октетов будет занимать 64 октета, из которых первые 32 содержат значение s в представлении big-endian, а вторые 32 октета содержат значение r в том же представлении.

Для преобразования строки октетов в битовую строку при использовании в сертификатах и CRL должен использоваться процесс, описанный выше (параграф 2.2.1).

2.3. Алгоритмы открытых ключей субъектов

В этом разделе определены идентификаторы OID и параметры открытых ключей для ключей, использующих алгоритмы GOST R 34.10-94 [GOSTR341094]/VKO GOST R 34.10-94 [CPALGS] и GOST R 34.10-2001 [GOSTR341001]/VKO GOST R 34.10-2001 [CPALGS].

Использование одного ключа для подписи и производного ключа не рекомендуется. Предусмотренное применение ключа может быть указано расширением сертификата keyUsage (см. [PROFILE], параграф 4.2.1.3).

2.3.1. Ключи GOST R 34.10-94

Открытые ключи GOST R 34.10-94 могут применяться с алгоритмом подписи GOST R 34.10-94 [GOSTR341094] и при создании производных ключей с помощью алгоритма VKO GOST R 34.10-94 [CPALGS].

Открытые ключи GOST R 34.10-94 указываются идентификатором OID, приведенным ниже.

   id-GostR3410-94 OBJECT IDENTIFIER ::=
       { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) gostR3410-94(20) }

Поле SubjectPublicKeyInfo.algorithm.algorithm (см. RFC 3280 [PROFILE]) для ключей GOST R 34.10-94 должно иметь значение id-GostR3410-94.

Когда идентификатор алгоритма id-GostR3410-94 указан в поле algorithm структуры AlgorithmIdentifier, поле parameters может быть опущено или иметь значение NULL. В остальных случаях это поле должно иметь приведенную ниже структуру.

    GostR3410-94-PublicKeyParameters ::=
        SEQUENCE {
            publicKeyParamSet
                OBJECT IDENTIFIER,
            digestParamSet
                OBJECT IDENTIFIER,
            encryptionParamSet
                OBJECT IDENTIFIER DEFAULT
                    id-Gost28147-89-CryptoPro-A-ParamSet
        }

где:

• publicKeyParamSet — идентификатор параметров открытого ключа для GOST R 34.10-94 (см. параграф 8.3 в [CPALGS]);

• digestParamSet — идентификатор параметров для GOST R 34.11-94 (см. параграф 8.2 в [CPALGS]);

• encryptionParamSet — идентификатор параметров для GOST 28147-89 [GOST28147] (см. параграф 8.1 в [CPALGS])

Отсутствие параметров нужно обрабатывать в соответствии с параграфом 6.1 RFC 3280 [PROFILE], т. е., параметры наследуются из сертификата эмитента. Когда переменная working_public_key_parameters имеет значение null, сертификат и все подтверждаемые им подписи нужно отвергать.

Открытые ключи GOST R 34.10-94 должны кодироваться в формате ASN.1 DER как OCTET STRING, это представление нужно использовать в качестве содержимого (т. е., значения) компоненты subjectPublicKey (BIT STRING) элемента данных SubjectPublicKeyInfo.

   GostR3410-94-PublicKey ::= OCTET STRING — открытый ключ, Y

Поле GostR3410-94-PublicKey должно содержать 128 октетов (в представлении little-endian) открытого ключа Y = a^x (mod p), где a и p являются параметрами открытого ключа, а x — секретный ключ.

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

При наличии в сертификате конечного элемента с открытым ключом GOST R 34.10-94 расширения keyUsage могут присутствовать следующие значения:

digitalSignature;

nonRepudiation;

keyEncipherment;

keyAgreement.

Если в сертификате открытого ключа GOST R 34.10-94 имеется расширение keyAgreement или keyEnchiperment, могут присутствовать также следующие значения:

encipherOnly;

decipherOnly.

В расширении keyUsage недопустимо заявлять одновременно encipherOnly и decipherOnly.

При наличии расширения keyUsage в сертификате подписавшего CA или CRL, содержащем открытый ключ GOST R 34.10-94, могут присутствовать также значения:

digitalSignature;

nonRepudiation;

keyCertSign;

cRLSign.

2.3.2. Ключи GOST R 34.10-2001

Открытые ключи GOST R 34.10-2001 могут использоваться с алгоритмом подписи GOST R 34.10-2001 [GOSTR341001] и алгоритмом создания производных ключей VKO GOST R 34.10-2001 [CPALGS].

Открытый ключ GOST R 34.10-2001 идентифицируется значением OID, показанным ниже.

   id-GostR3410-2001 OBJECT IDENTIFIER ::=
       { iso(1) member-body(2) ru(643) rans(2) cryptopro(2) gostR3410-2001(19) }

Поле SubjectPublicKeyInfo.algorithm.algorithm (см. RFC 3280 [PROFILE]) для ключей GOST R 34.10-2001 должно иметь значение id-GostR3410-2001.

Если в поле algorithm структуры AlgorithmIdentifier указан идентификатор алгоритма id-GostR3410-2001, при кодировании поле parameters может быть опущено или установлено в NULL. В остальных случаях это поле должно иметь приведенную ниже структуру.

    GostR3410-2001-PublicKeyParameters ::=
        SEQUENCE {
            publicKeyParamSet
                OBJECT IDENTIFIER,
            digestParamSet
                OBJECT IDENTIFIER,
            encryptionParamSet
                OBJECT IDENTIFIER DEFAULT
                    id-Gost28147-89-CryptoPro-A-ParamSet
        }

где:

• publicKeyParamSet — идентификатор параметров открытого ключа для GOST R 34.10-2001 (см. параграф 8.4 в [CPALGS])

• digestParamSet — идентификатор параметров для GOST R 34.11-94 (см. параграф 8.2 в [CPALGS])

• encryptionParamSet — идентификатор параметров для GOST 28147-89 [GOST28147] (см. параграф 8.1 в [CPALGS])

Отсутствие параметров нужно обрабатывать в соответствии с параграфом 6.1 RFC 3280 [PROFILE], т. е., параметры наследуются из сертификата эмитента. Когда переменная working_public_key_parameters имеет значение null, сертификат и все подтверждаемые им подписи нужно отвергать.

Открытые ключи GOST R 34. 10-2001 должны кодироваться в формате ASN.1 DER как OCTET STRING, это представление нужно использовать в качестве содержимого (т. е., значения) компоненты subjectPublicKey (BIT STRING) элемента данных SubjectPublicKeyInfo.

   GostR3410-2001-PublicKey ::= OCTET STRING — вектор открытого ключа, Q

Согласно [GOSTR341001], открытый ключ является точкой эллиптической кривой Q = (x,y).

Строка GostR3410-2001-PublicKey должна содержать 64 октета, из которых первые 32 являются представлением little-endian для значения x, а оставшиеся 32 октета — представлением little-endian для y. Это соответствует двоичному представлению (<y>256||<x>256) из [GOSTR341001] (параграф 5.3).

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

Ограничения на keyUsage для ключей GOST R 34.10-2001 совпадают с ограничениями, описанными в параграфе 2.3.1 для ключей GOST R 34.10-94.

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

Приложениям рекомендуется проверять значения подписей и открытых ключей на предмет соответствия стандартам [GOSTR341001, GOSTR341094] до использования этих значений.

При использовании сертификатов для поддержки цифровых подписей в качестве эквивалента рукописных подписей в контексте российского Федерального закона «Об электронной цифровой подписи» [RFEDSL] сертификат должен включать расширение keyUsage, это должно быть критичным и в keyUsage недопустимо включать keyEncipherment и keyAgreement.

Удостоверяющим центрам (CA) и приложениям рекомендуется обеспечивать уверенность в том, что секретный ключ для создания подписей не используется в течение периода, превосходящего разрешенный (обычно 15 месяцев для алгоритмов GOST R 34.10-94 и GOST R 34.10-2001).

Обсуждение вопросов безопасности, связанных с использованием параметров алгоритма, приведено в разделе «Вопросы безопасности» [CPALGS].

4. Примеры

4.1. Сертификат GOST R 34.10-94

 -----BEGIN CERTIFICATE-----
 MIICCzCCAboCECMO42BGlSTOxwvklBgufuswCAYGKoUDAgIEMGkxHTAbBgNVBAMM
 FEdvc3RSMzQxMC05NCBleGFtcGxlMRIwEAYDVQQKDAlDcnlwdG9Qcm8xCzAJBgNV
 BAYTAlJVMScwJQYJKoZIhvcNAQkBFhhHb3N0UjM0MTAtOTRAZXhhbXBsZS5jb20w
 HhcNMDUwODE2MTIzMjUwWhcNMTUwODE2MTIzMjUwWjBpMR0wGwYDVQQDDBRHb3N0
 UjM0MTAtOTQgZXhhbXBsZTESMBAGA1UECgwJQ3J5cHRvUHJvMQswCQYDVQQGEwJS
 VTEnMCUGCSqGSIb3DQEJARYYR29zdFIzNDEwLTk0QGV4YW1wbGUuY29tMIGlMBwG
 BiqFAwICFDASBgcqhQMCAiACBgcqhQMCAh4BA4GEAASBgLuEZuF5nls02CyAfxOo
 GWZxV/6MVCUhR28wCyd3RpjG+0dVvrey85NsObVCNyaE4g0QiiQOHwxCTSs7ESuo
 v2Y5MlyUi8Go/htjEvYJJYfMdRv05YmKCYJo01x3pg+2kBATjeM+fJyR1qwNCCw+
 eMG1wra3Gqgqi0WBkzIydvp7MAgGBiqFAwICBANBABHHCH4S3ALxAiMpR3aPRyqB
 g1DjB8zy5DEjiULIc+HeIveF81W9lOxGkZxnrFjXBSqnjLeFKgF1hffXOAP7zUM=
 -----END CERTIFICATE-----

   0 30  523: SEQUENCE {
   4 30  442:  SEQUENCE {
   8 02   16:   INTEGER
            :    23 0E E3 60 46 95 24 CE C7 0B E4 94 18 2E 7E EB
  26 30    8:   SEQUENCE {
  28 06    6:    OBJECT IDENTIFIER
            :     id-GostR3411-94-with-GostR3410-94 (1 2 643 2 2 4)
            :    }
  36 30  105:   SEQUENCE {
  38 31   29:    SET {
  40 30   27:     SEQUENCE {
  42 06    3:      OBJECT IDENTIFIER commonName (2 5 4 3)
  47 0C   20:      UTF8String 'GostR3410-94 example'
            :      }
            :     }
  69 31   18:    SET {
  71 30   16:     SEQUENCE {
  73 06    3:      OBJECT IDENTIFIER organizationName (2 5 4 10)
  78 0C    9:      UTF8String 'CryptoPro'
            :      }
            :     }
  89 31   11:    SET {
  91 30    9:     SEQUENCE {
  93 06    3:      OBJECT IDENTIFIER countryName (2 5 4 6)
  98 13    2:      PrintableString 'RU'
            :      }
            :     }
 102 31   39:    SET {
 104 30   37:     SEQUENCE {
 106 06    9:      OBJECT IDENTIFIER emailAddress (1 2 840 113549 1 9 1)
 117 16   24:      IA5String 'GostR3410-94@example.com'
            :      }
            :     }
            :    }
 143 30   30:   SEQUENCE {
 145 17   13:    UTCTime '050816123250Z'
 160 17   13:    UTCTime '150816123250Z'
            :    }
 175 30  105:   SEQUENCE {
 177 31   29:    SET {
 179 30   27:     SEQUENCE {
 181 06    3:      OBJECT IDENTIFIER commonName (2 5 4 3)
 186 0C   20:      UTF8String 'GostR3410-94 example'
            :      }
            :     }
 208 31   18:    SET {
 210 30   16:     SEQUENCE {
 212 06    3:      OBJECT IDENTIFIER organizationName (2 5 4 10)
 217 0C    9:      UTF8String 'CryptoPro'
            :      }
            :     }
 228 31   11:    SET {
 230 30    9:     SEQUENCE {
 232 06    3:      OBJECT IDENTIFIER countryName (2 5 4 6)
 237 13    2:      PrintableString 'RU'
            :      }
            :     }
 241 31   39:    SET {
 243 30   37:     SEQUENCE {
 245 06    9:      OBJECT IDENTIFIER emailAddress (1 2 840 113549 1 9 1)
 256 16   24:      IA5String 'GostR3410-94@example.com'
            :      }
            :     }
            :    }
 282 30  165:   SEQUENCE {
 285 30   28:    SEQUENCE {
 287 06    6:     OBJECT IDENTIFIER id-GostR3410-94 (1 2 643 2 2 20)
 295 30   18:     SEQUENCE {
 297 06    7:      OBJECT IDENTIFIER
            :       id-GostR3410-94-CryptoPro-A-ParamSet
            :        (1 2 643 2 2 32 2)
 306 06    7:      OBJECT IDENTIFIER
            :       id-GostR3411-94-CryptoProParamSet
            :        (1 2 643 2 2 30 1)
            :      }
            :     }
 315 03  132:    BIT STRING 0 unused bits, encapsulates {
 319 04  128:     OCTET STRING
            :      BB 84 66 E1 79 9E 5B 34 D8 2C 80 7F 13 A8 19 66
            :      71 57 FE 8C 54 25 21 47 6F 30 0B 27 77 46 98 C6
            :      FB 47 55 BE B7 B2 F3 93 6C 39 B5 42 37 26 84 E2
            :      0D 10 8A 24 0E 1F 0C 42 4D 2B 3B 11 2B A8 BF 66
            :      39 32 5C 94 8B C1 A8 FE 1B 63 12 F6 09 25 87 CC
            :      75 1B F4 E5 89 8A 09 82 68 D3 5C 77 A6 0F B6 90
            :      10 13 8D E3 3E 7C 9C 91 D6 AC 0D 08 2C 3E 78 C1
            :      B5 C2 B6 B7 1A A8 2A 8B 45 81 93 32 32 76 FA 7B
            :     }
            :    }
            :   }
 450 30    8:  SEQUENCE {
 452 06    6:   OBJECT IDENTIFIER
            :    id-GostR3411-94-with-GostR3410-94 (1 2 643 2 2 4)
            :   }
 460 03   65:  BIT STRING 0 unused bits
            :   11 C7 08 7E 12 DC 02 F1 02 23 29 47 76 8F 47 2A
            :   81 83 50 E3 07 CC F2 E4 31 23 89 42 C8 73 E1 DE
            :   22 F7 85 F3 55 BD 94 EC 46 91 9C 67 AC 58 D7 05
            :   2A A7 8C B7 85 2A 01 75 85 F7 D7 38 03 FB CD 43
            :  }

В подписи приведенного выше сертификата r’ имеет значение

 0x22F785F355BD94EC46919C67AC58D7052AA78CB7852A017585F7D73803FBCD43

s имеет значение

 0x11C7087E12DC02F102232947768F472A818350E307CCF2E431238942C873E1DE

4.2. Сертификат GOST R 34.10-2001

 -----BEGIN CERTIFICATE-----
 MIIB0DCCAX8CECv1xh7CEb0Xx9zUYma0LiEwCAYGKoUDAgIDMG0xHzAdBgNVBAMM
 Fkdvc3RSMzQxMC0yMDAxIGV4YW1wbGUxEjAQBgNVBAoMCUNyeXB0b1BybzELMAkG
 A1UEBhMCUlUxKTAnBgkqhkiG9w0BCQEWGkdvc3RSMzQxMC0yMDAxQGV4YW1wbGUu
 Y29tMB4XDTA1MDgxNjE0MTgyMFoXDTE1MDgxNjE0MTgyMFowbTEfMB0GA1UEAwwW
 R29zdFIzNDEwLTIwMDEgZXhhbXBsZTESMBAGA1UECgwJQ3J5cHRvUHJvMQswCQYD
 VQQGEwJSVTEpMCcGCSqGSIb3DQEJARYaR29zdFIzNDEwLTIwMDFAZXhhbXBsZS5j
 b20wYzAcBgYqhQMCAhMwEgYHKoUDAgIkAAYHKoUDAgIeAQNDAARAhJVodWACGkB1
 CM0TjDGJLP3lBQN6Q1z0bSsP508yfleP68wWuZWIA9CafIWuD+SN6qa7flbHy7Df
 D2a8yuoaYDAIBgYqhQMCAgMDQQA8L8kJRLcnqeyn1en7U23Sw6pkfEQu3u0xFkVP
 vFQ/3cHeF26NG+xxtZPz3TaTVXdoiYkXYiD02rEx1bUcM97i
 -----END CERTIFICATE-----

   0 30  464: SEQUENCE {
   4 30  383:  SEQUENCE {
   8 02   16:   INTEGER
            :    2B F5 C6 1E C2 11 BD 17 C7 DC D4 62 66 B4 2E 21
  26 30    8:   SEQUENCE {
  28 06    6:    OBJECT IDENTIFIER
            :     id-GostR3411-94-with-GostR3410-2001 (1 2 643 2 2 3)
            :    }
  36 30  109:   SEQUENCE {
  38 31   31:    SET {
  40 30   29:     SEQUENCE {
  42 06    3:      OBJECT IDENTIFIER commonName (2 5 4 3)
  47 0C   22:      UTF8String 'GostR3410-2001 example'
            :      }
            :     }
  71 31   18:    SET {
  73 30   16:     SEQUENCE {
  75 06    3:      OBJECT IDENTIFIER organizationName (2 5 4 10)
  80 0C    9:      UTF8String 'CryptoPro'
            :      }
            :     }
  91 31   11:    SET {
  93 30    9:     SEQUENCE {
  95 06    3:      OBJECT IDENTIFIER countryName (2 5 4 6)
 100 13    2:      PrintableString 'RU'
            :      }
            :     }
 104 31   41:    SET {
 106 30   39:     SEQUENCE {
 108 06    9:      OBJECT IDENTIFIER emailAddress (1 2 840 113549 1 9 1)
 119 16   26:      IA5String 'GostR3410-2001@example.com'
            :      }
            :     }
            :    }
 147 30   30:   SEQUENCE {
 149 17   13:    UTCTime '050816141820Z'
 164 17   13:    UTCTime '150816141820Z'
            :    }
 179 30  109:   SEQUENCE {
 181 31   31:    SET {
 183 30   29:     SEQUENCE {
 185 06    3:      OBJECT IDENTIFIER commonName (2 5 4 3)
 190 0C   22:      UTF8String 'GostR3410-2001 example'
            :      }
            :     }
 214 31   18:    SET {
 216 30   16:     SEQUENCE {
 218 06    3:      OBJECT IDENTIFIER organizationName (2 5 4 10)
 223 0C    9:      UTF8String 'CryptoPro'
            :      }
            :     }
 234 31   11:    SET {
 236 30    9:     SEQUENCE {
 238 06    3:      OBJECT IDENTIFIER countryName (2 5 4 6)
 243 13    2:      PrintableString 'RU'
            :      }
            :     }
 247 31   41:    SET {
 249 30   39:     SEQUENCE {
 251 06    9:      OBJECT IDENTIFIER emailAddress (1 2 840 113549 1 9 1)
 262 16   26:      IA5String 'GostR3410-2001@example.com'
            :      }
            :     }
            :    }
 290 30   99:   SEQUENCE {
 292 30   28:    SEQUENCE {
 294 06    6:     OBJECT IDENTIFIER id-GostR3410-2001 (1 2 643 2 2 19)
 302 30   18:     SEQUENCE {
 304 06    7:      OBJECT IDENTIFIER
            :       id-GostR3410-2001-CryptoPro-XchA-ParamSet
            :        (1 2 643 2 2 36 0)
 313 06    7:      OBJECT IDENTIFIER
            :       id-GostR3411-94-CryptoProParamSet
            :        (1 2 643 2 2 30 1)
            :      }
            :     }
 322 03   67:    BIT STRING 0 unused bits, encapsulates {
 325 04   64:     OCTET STRING
            :      84 95 68 75 60 02 1A 40 75 08 CD 13 8C 31 89 2C
            :      FD E5 05 03 7A 43 5C F4 6D 2B 0F E7 4F 32 7E 57
            :      8F EB CC 16 B9 95 88 03 D0 9A 7C 85 AE 0F E4 8D
            :      EA A6 BB 7E 56 C7 CB B0 DF 0F 66 BC CA EA 1A 60
            :     }
            :    }
            :   }
 391 30    8:  SEQUENCE {
 393 06    6:   OBJECT IDENTIFIER
            :    id-GostR3411-94-with-GostR3410-2001 (1 2 643 2 2 3)
            :   }
 401 03   65:  BIT STRING 0 unused bits
            :   3C 2F C9 09 44 B7 27 A9 EC A7 D5 E9 FB 53 6D D2
            :   C3 AA 64 7C 44 2E DE ED 31 16 45 4F BC 54 3F DD
            :   C1 DE 17 6E 8D 1B EC 71 B5 93 F3 DD 36 93 55 77
            :   68 89 89 17 62 20 F4 DA B1 31 D5 B5 1C 33 DE E2
            :  }

В открытом ключе приведенного выше сертификата x имеет значение

 0x577E324FE70F2B6DF45C437A0305E5FD2C89318C13CD0875401A026075689584

y имеет значение

 0x601AEACABC660FDFB0CBC7567EBBA6EA8DE40FAE857C9AD0038895B916CCEB8F

Соответствующий секретный ключ имеет значение d

 0x0B293BE050D0082BDAE785631A6BAB68F35B42786D6DDA56AFAF169891040F77

В приведенном выше сертификате r имеет значение

 0xC1DE176E8D1BEC71B593F3DD36935577688989176220F4DAB131D5B51C33DEE2

s имеет значение

 0x3C2FC90944B727A9ECA7D5E9FB536DD2C3AA647C442EDEED3116454FBC543FDD

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

Этот документ был подготовлен в соответствии с «Соглашением о совместимости СКЗИ», подписанным ФГУП НТЦ «Атлас», ООО «КРИПТО-ПРО», ООО «Фактор-ТС», ЗАО «МО ПНИЭИ», ООО «Инфотекс», ЗАО «СПбРЦЗИ», ООО «Криптоком», ООО «Р-Альфа». Целью этого соглашения является обеспечение взаимной совместимости продукции и решений.

Авторы выражают свою признательность

представительству компании Microsoft в России за предоставление информации о продукции и решениях компании, а также технические консультации в части PKI;

представительству RSA Security в России и компании «Демос» за активное сотрудничество и неоценимую помощь в создании этого документа;

RSA Security Inc за тестирование совместимости предложенных форматов данных при встраивании в продукцию RSA Keon;

Baltimore Technology plc за тестирование совместимости предложенных форматов данных при встраивании в их продукцию UniCERT;

Peter Gutmann за полезную программу dumpasn1;

Russ Housley (Vigil Security, LLC, housley@vigilsec.com) и Василию Сахарову (DEMOS Co Ltd, svp@dol.ru) за поощрение авторов к созданию этого документа;

Григорию Чудову за помощь в прохождении процесса IETF для этого документа;

Дмитрию Приходько (VSTU, PrikhodkoDV@volgablob.ru) за неоценимую помощь в корректуре этого документа и проверку формы и содержания структур ASN.1 упомянутых и использованных в документе.

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

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

[GOST28147] «Системы обработки информации. Защита криптографическая. Алгоритм криптографического преобразования. ГОСТ 28147-89″, Государственный стандарт СССР, Государственный комитет СССР по стандартизации, 1989. (на русском языке)

[GOST3431195] «Информационная технология. Криптографическая защита информации. Функция хэширования.», ГОСТ 34.311-95, Межгосударственный совет по стандартизации, метрологии и сертификации (МГС), Минск, 1995. (на русском языке)

[GOST3431095] «Информационная технология. Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма.», ГОСТ 34.310-95, Межгосударственный совет по стандартизации, метрологии и сертификации (МГС), Минск, 1995. (на русском языке)

[GOST3431004] «Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи.»³, ГОСТ 34.310-2004, Межгосударственный совет по стандартизации, метрологии и сертификации (МГС), Минск, 2004. (на русском языке)

[GOSTR341094] «Информационная технология. Криптографическая защита информации. Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма.», ГОСТ Р 34.10-94, Государственный стандарт Российской Федерации, Госстандарт России, 1994. (на русском языке)

[GOSTR341001] «Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи.», ГОСТ Р 34.10-2001, Государственный стандарт Российской Федерации, Госстандарт России, 2001. (на русском языке)

[GOSTR341194] «Информационная технология. Криптографическая защита информации. Функция хэширования.», ГОСТ Р 34.11-94⁴, Государственный стандарт Российской Федерации, Госстандарт России, 1994. (на русском языке)

[CPALGS] Popov, V., Kurepkin, I., and S. Leontiev, «Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms», RFC 4357, January 2006.

[PKALGS] Bassham, L., Polk, W., and R. Housley, «Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 3279, April 2002.

[PROFILE] Housley, R., Polk, W., Ford, W., and D. Solo, «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile», RFC 3280, April 2002.

[X.660] ITU-T Recommendation X.660 Information Technology — ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER), 1997.

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

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

[Schneier95] B. Schneier, Applied Cryptography, Second Edition, John Wiley & Sons, Inc., 1995.

[RFEDSL] Федеральный закон «Об электронной цифровой подписи» от 10.01.2002 N 1-ФЗ⁵

[CMS] Housley, R., «Cryptographic Message Syntax (CMS)», RFC 3852, July 2004.

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

Сергей Леонтьев, редактор

CRYPTO-PRO

38, Obraztsova,

Moscow, 127018, Russian Federation

EMail: lse@cryptopro.ru

Денис Стефановский, редактор

Mobile TeleSystems OJSC

4, Marksistskaya Str.,

Moscow, 109147, Russian Federation

EMail: dbs@mts.ru

Григорий Чудов

CRYPTO-PRO

38, Obraztsova,

Moscow, 127018, Russian Federation

EMail: chudov@cryptopro.ru

Александр Афанасьев

Factor-TS

office 711, 14, Presnenskij val,

Moscow, 123557, Russian Federation

EMail: afa1@factor-ts.ru

Николай Никишин

Infotecs GmbH

p/b 35, 80-5, Leningradskij prospekt,

Moscow, 125315, Russian Federation

EMail: nikishin@infotecs.ru

Болеслав Изотов

FGUE STC «Atlas»

38, Obraztsova,

Moscow, 127018, Russian Federation

EMail: izotov@nii.voskhod.ru

Елена Минаева

MD PREI

build 3, 6A, Vtoroj Troitskij per.,

Moscow, Russian Federation

EMail: evminaeva@mail.ru

Игорь Остапенко

MD PREI

Office 600, 14, B.Novodmitrovskaya,

Moscow, Russian Federation

EMail: igori@mo.msk.ru

Сергей Муругов

R-Alpha

4/1, Raspletina,

Moscow, 123060, Russian Federation

EMail: msm@top-cross.ru

Игорь Устинов

Cryptocom

office 239, 51, Leninskij prospekt,

Moscow, 119991, Russian Federation

EMail: igus@cryptocom.ru

Анатолий Еркин

SPRCIS (SPbRCZI)

1, Obrucheva,

St.Petersburg, 195220, Russian Federation

EMail: erkin@nevsky.net

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

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

nmalykh@gmail.com

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

Copyright (C) The Internet Society (2006).

К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.

Этот документ и содержащаяся в нем информация представлены «как есть» и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

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

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.

IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.

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

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

---

Заменен RFC 9063.

Отменено RFC 5077.