RFC 2753 A Framework for Policy-based Admission Control

Network Working Group                                         R. Yavatkar
Request for Comments: 2753                                          Intel
Category: Informational                                     D. Pendarakis
                                                                      IBM
                                                                R. Guerin
                                                       U. Of Pennsylvania
                                                             January 2000

Модель контроля доступа на основе правил

A Framework for Policy-based Admission Control

PDF

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

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

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

Copyright (C) The Internet Society (2000). All Rights Reserved.

1. Введение

Рабочие группы IETF, такие как Integrated Services1 (int-serv) и RSVP [1] подготовили расширения архитектуры IP и модели обслуживания «по возможности» (best-effort), позволяющие приложениям и конечным пользователям запрашивать определенное качество (уровень) обслуживания от сети в дополнение к современным услугам IP best-effort. Недавние результаты рабочей группы Differentiated Services2 также направлены на определение механизмов поддержки агрегатов услуг QoS3. Модель int-serv для этих новых услуг требует явной сигнализации требований QoS от конечных точек и обеспечения восприятия и управления трафиком на маршрутизаторах с интегрированным обслуживанием. Предложенные стандарты для RSVP [RFC 2205] и интегрированных услуг [RFC 2211, RFC 2212] являются примерами нового протокола организации резервирования и новых определений сервиса, соответственно. В модели int-serv некоторые потоки данных получают предпочтительное обслуживание по сравнению с другими потоками — компоненты управления восприятием (admission control) принимают во внимание лишь запросы ресурсов со стороны резервирующего и доступные возможности, но не принимают запросы QoS. Однако механизмы int-serv не включают важных аспектов управления восприятием — сетевые администраторы и сервис-провайдеры должны быть способны отслеживать, контролировать и форсировать использование ресурсов и услуг на основе правил, выводимых из таких критериев, как отождествление пользователей и приложений, потребности в пропускной способности, день недели, время суток. Механизмы diff-serv тоже должны принимать во внимание правила, включающие такие критерии, как отождествление пользователей, точки входа и т. д.

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

В разделе 2 приведены определения основных терминов. В разделе 3 указан список требований и целей механизмов, применяемых для контроля доступа и обеспечения лучшего QoS. Затем очерчены элементы архитектуры модели (раздел 4) и описана функциональность каждой компоненты. В разделе 5 приведены примеры правил, возможные варианты и поддержка политики для этих вариантов. В разделе 6 заданы требования к протоколу «клиент-сервер» для коммуникаций между сервером правил (PDP) и клиентом (PEP), а также оценена пригодность имеющихся протоколов.

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

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

Administrative Domain — административный домен

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

Network Element или Node — элемент сети или узел

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

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

QoS Signaling Protocol — сигнальный протокол QoS

Протокол сигнализации, передающий запросы контроля доступа к ресурсу, например, RSVP.

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

Набор правил и услуг, где правила определяют критерии доступа и использования ресурса.

Policy control — проверка политики

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

Policy Object — объект политки

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

Policy Element — элемент политики

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

Policy Decision Point (PDP) — точка принятия решений в политике

Место, где принимается решение в политике доступа.

Policy Enforcement Point (PEP) — точка исполнения решений политики

Место, где реально испольняется решение политики доступа.

Policy Ignorant Node (PIN) — игнорирующий политику узел

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

Resource — ресурс

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

Service Provider — сервис-провайдер

Контролирует сетевую инфраструктуру и может отвечать за учет и оплату услуг.

Soft State Model — модель “мягких” состояний

Soft state представляет собой вариант модели с учетом состояний, которые истекают через некоторое время после установки в PEP или PDP. Это способ автоматического удаления состояний при наличии отказов коммуникаций или сетевых элементов. Например, RSVP применяет такую модель для установки состояний резерва на сетевых элементах в пути потока данных через сеть.

Installed State — установленное состояние

Новый и уникальный запрос от PEP к PDP, который должен удаляться явно.

Trusted Node — доверенный узел

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

3. Контроль восприятия на основе правил — цели и требования

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

Политика и механизмы

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

RSVP

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

Поддержка вытеснения

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

Поддержка разных стилей политики

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

Предоставление информации для мониторинга и учета

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

Устойчивость к отказам и восстановление

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

Поддержка узлов PIN

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

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

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

Вопросы безопасности и атак на службы

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

4. Элементы архитектуры

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

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

 ________________         Сервер политики
|                |        ______
|    Узел сети   |        |     |------------->
|    _____       |        |     |  Может применять LDAP,SNMP,.. для
|   |     |      |        |     |  доступа к базе правил, аутентификации и пр.
|   | PEP |<-----|------->| PDP |------------->
|   |_____|      |        |_____|
|                |
|________________|

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


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

Особое значение имеет «язык» определения правил, реализованный в PDP. Число правил, применимых к узлу сети, может быть достаточно большим. В то же время эти правила могут быть очень сложными с точки зрения числа полей, используемых для принятия решения, а спектр решений может быть широким. Кроме того, вполне возможно применение нескольких правил к одному профилю запроса. Например, политика может предписывать определенную обработку запросов от общей группы пользователей (например, сотрудники компании), а также иную обработку запросов другой группы (например, управляющих). В этом примере профиль managers соответствует двум правилам, одно из которых является общим, другое — более конкретным.

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

 ________________                        ____________________
|                |                      |                    |
|    Узел сети   |  Сервер политики     |     Узел сети      |
|    _____       |      _____           |  _____      _____  |
|   |     |      |     |     |          | |     |    |     | |
|   | PEP |<-----|---->| PDP |          | | PEP |<-->| PDP | |
|   |_____|      |     |_____|          | |_____|    |_____| |
|    ^           |                      |                    |
|    |    _____  |                      |____________________|
|    \-->|     | |
|        | LPDP| |
|        |_____| |
|                |
|________________|

Рисунок 2. Два других варианта конфигурации компонент политки управления доступом. Слева показана локальная точка принятия решений на узле сети, а справа — PEP и PDP на одном узле.


В некоторых случаях простой конфигурации, показанной на рисунке 1, может оказаться недостаточно, поскольку нужно применять локальные правила (например, списки доступа) в дополнение к правилам удаленной точки PDP. Кроме того, PDP может размещаться на одном узле с PEP. Эти варианты показаны на рисунке 2.

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

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

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

В этой модели управления политикой модуль PEP на узле сети должен для принятия решения использовать указанные ниже действия.

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

  2. PEP может обратиться к локальной базе конфигурации для идентификации набора элементов политики (назовем его A), которые могут быть проверены локально. Локальная конфигурация задает типы элементов политики для локальной оценки. PEP передает запрос с набором A локальной точке принятия решений LPDP и принимает результат LPDP («частичное решение», обозначенное D(A)).

  3. Затем PEP передает запрос со всеми элементами политики и D(A) точке PDP, которая применяет правила ко всем элементам политики и запроса, принимая решение (обозначено D(Q)). Затем это решение объединяется с частичным решением D(A) для получения окончательного решения.

  4. PDP возвращает окончательное решение (полученное при объединении) точке PEP.

Отметим, что в приведенной выше модели точка PEP должна контактировать с PDP даже при отсутствии (или NULL) объектов политики, полученных в запросе контроля доступа. Это требование помогает гарантировать для каждого запроса невозможность обойти управление политикой путем пропуска элементов политики в запросе на резервирование. Однако разрешено «короткое замыкание» при обработке, т. е. при отрицательном результате D(A) не требуется выполнять дополнительную проверку в PDP. Тем не менее, нужно информировать PDP об отказе при локальной обработке политики. То же самое относится к случаю, когда обработка политики прошла, но контроль доступа (на уровне управления ресурсом в результате нехватки емкости) дал отрицательный результат. PDP в этом случае также нужно информировать об отказе.

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

4.1. Пример маршрутизатора RSVP

Для маршрутизатора RSVP на рисунке 3 показано взаимодействие между PEP и другими компонентами int-serv в маршрутизаторе. Для обсуждения все компоненты, относящиеся к связанной с RSVP обработке, показаны в виде одного модуля RSVP, а более подробное обсуждение взаимодействия и интерфейсов между RSVP и PEP дано в [3].

   ______________________________
  |                              |
  |       Маршрутизатор          |
  |  ________           _____    |            _____
  | |        |         |     |   |           |     |
  | |  RSVP  |<------->| PEP |<--|---------->| PDP |
  | |________|         |_____|   |           |_____|
  |      ^                       |
  |      |      Контроль трафика |
  |      |      _____________    |
  |      \---->|  _________  |   |PC - классификатор
  |            | | емкость | |   |     пакетов
  |            | | ADM CTL | |   |PS - планировщик
  |            | |_________| |   |     пакетов
--|----------->|  ____ ____  |   |
  |   Данные   | | PC | PS | |   |
  |            | |____|____| |   |
  |            |_____________|   |
  |                              |
  |______________________________|

Рисунок 3. Связь между PEP и другими компонентами int-serv в маршрутизаторе RSVP


Когда сообщение RSVP приходит маршрутизатору (или связанное с RSVP событие требует решения политики), предполагается, что модуль RSVP передаст запрос (соответствующий событию или сообщению) модулю PEP, который будет использовать PDP (и LPDP) для принятия решения и возврата его модулю RSVP.

4.2. Дополнительная функциональность PDP

Обычно PDP возвращает окончательное решение на основе запроса управления доступом и связанных элементов политики. Однако у PDP должна быть возможность запросить PEP (или модуль контроля доступа в элементе сети, где размещается PEP) генерацию связанных с политикой сообщений об ошибках. Например, в случае RSVP точка PDP может воспринять запрос и разрешить организацию и пересылку резервирования предыдущему интервалу (hop), но в то же время сгенерировать сообщение об ошибке (предупреждение) нисходящему узлу (NHOP) для информирования о том, что «запрос может быть отменен по истечении 10 минут и т. п.». По сути нужна возможность создавать связанные с политикой сообщения об ошибках и/или предупреждения и распространять их с использованием естественного протокола сигнализации QoS (такого как RSVP). Такие ошибки, возвращаемые PDP, должны также обеспечивать возможность указать, следует ли по-прежнему воспринимать, устанавливать и пересылать запросы резервирования для продолжения обычной обработки RSVP. В частности, возвращенная PDP ошибка указывает, что

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

  2. или указывает, что была возвращена ошибка, но сообщение RSVP не следует пересылать как обычно.

4.3. Взаимодействие PEP, LPDP и PDP на маршрутизаторе RSVP

Все детали обработки сообщений RSVP и связанных с ними взаимодействий между разными элементами в маршрутизаторе RSVP (PEP, LPDP) и PDP описаны в отдельных документах [3,8]. Ниже приведены несколько аспектов, связанных с рассматриваемой моделью.

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

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

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

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

4.4. Размещение элементов политики в сети

Обеспечивая разделение задач между LPDP и PDP, архитектура управления политикой позволяет поэтапное развертывание путем включения маршрутизаторов различной степени сложности в части управления политикой взаимодействовать с серверами политики. На рисунке 4 приведен пример набора узлов в трех административных доменах (AD), каждый из которых относится к своему сервис-провайдеру. Узлы A, B, C относятся к AD-1, обслуживаемому PDP PS-1, а D и E относятся к AD-2 и AD-3, соответственно. Узел E взаимодействует с PDP PS-2. В общем случае предполагается наличие хотя бы одной точки PDP в каждом административном домене.

                        AD-1                    AD-2         AD-3
      ________________/\_______________     __/\___      __/\___
     {                                 }   {       }    {       }
             A           B            C            D            E
        +-------+  +-----+    +-------+    +-------+    +-------+
        | RSVP  |  | RSVP|    | RSVP  |    | RSVP  |    | RSVP  |
+----+  |-------|  |-----|    |-------|    |-------|    |-------|
| S1 |--| P | L |--|     |----| P | L |----| P | P |----|   P   | +----+
+----+  | E | D |  +-----+    | E | D |    | E | D |    |   E   |-| R1 |
        | P | P |             | P | P |    | P | P |    |   P   | +----+
        +-------+             +-------+    +-------+    +-------+
           ^                        ^                           ^
           |                        |                           |
           |                        |                           |
           |                        |                       +-------+
           |                        |                       | PDP   |
           |         +------+       |                       |-------|
           +-------->| PDP  |<------+                       |       |
                     |------|                               +-------+
                     |      |                                  PS-2
                     +------+
                       PS-1

Рисунок 4. Размещение элементов политики в сети.


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

5. Примеры политики, сценариев и поддержки политики

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

5.1. Правила восприятия на основе времени, отождествления и свидетельств

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

5.2. Двухсторонние соглашения между сервис-провайдерами

До недавнего времени соглашения между сервис-провайдерами для трафика через границу доменов были достаточно простыми. Наример, два ISP могли согласовать восприятие любого трафика друг от друга без учета и оплаты пропускания «чужого» трафика. Однако доступность механизмов QoS, основанных на интеграции и дифференциации услуг, дифференциация трафика и гарантий качества обслуживания, привела к их постепенному внедрению в Internet. По мере того, как ISP начинают продавать своим пользователям различные уровни обслуживания и могут различать разные виды трафика, они будут искать механизмы оплаты друг другу трафика (и резервирования) через свои сети. Еще одним стимулом для создания таких механизмов является асимметрия трафика в терминах клиентской базы разных провайдеров. ISP, ориентированные на корпоративных заказчиков, скорей всего будут иметь более высокий спрос на резервирование по сравнению с провайдерами, обслуживающими индивидуальных пользователей. Отсутствие изощренных схем учета трафика между ISP может привести к неэффективному распределению затрат между разными сервис-провайдерами.

Двухсторонние соглашения можно разделить на две большие категории — локальные и глобальные. Сложность проблемы вынуждает предположить, что сначала будут применяться лишь первые. В них провайдеры, управляющие сетевым облаком или административным доменом, будут заключать договор со своим ближайшим соседом для задания основных правил и механизмов контроля доступа и учета. Эти договоры будут в основном локальными и не будут опираться на глобальные соглашения, поэтому узлы политики будут поддерживать лишь информацию о соседях. Применительно к рисунку 4, это подразумевает, что провайдер AD-1 будет иметь соглашение об использовании сети с AD-2, но не с AD-3. Провайдер AD-2 будет иметь соглашение с AD-3 и т. д. Таким образом, при пересылке запроса на резервирование в AD-2 провайдер AD-2 будет взимать плату с AD-1 за использование ресурсов вне сети AD-1. Эта информация получается путем рекурсивного применения двухсторонних соглашений на каждой границе между доменами (соседями), пока не дойдет до конечного получателя резервирования. Для реализации такой схемы в архитектуре управления политикой граничные узлы должны добавлять соответствующий объект политики в сообщение RSVP перед его пересылкой в сеть соседнего провайдера. Этот объект будет включать информацию о создавшем его провайдере и эквивалент учетного номера, по которому будут собираться данные для оплаты услуг. Поскольку соглашения существуют лишь между соседями, объекты политики должны заменяться в сообщениях RSVP при пересечении границы административного домена или сети провайдера.

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

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

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

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

Из трех означенных выше требований слияние данных о приоритете является наиболее сложной задачей и заслуживает дополнительного обсуждения. Сложность слияния данных о приоритете обусловлена тем, что это объединение выполняется в дополнение к слиянию информации о резервировании. Когда данные о резервировании (FLOWSPEC) идентичны (резервирование однородно), при слиянии достаточно рассмотреть информацию о приоритете и простое правило сохранения высшего приоритета дает адекватный ответ. Однако при неоднородном резервировании, «двумерная природа» пар (FLOWSPEC, priority) усложняет их упорядочение и слияние. Описание обработки различных объектов RSVP с приоритетами представлено в работе [7].

5.4. Карты предоплаты и маркеры

В телефонных сетях набирает популярность модель на основе карт с предоплатой. Эта концепция применима и в Internet — пользователи покупают «маркеры», которые могут применяться для доступа к сетевым услугам. Когда пользователь запрашивает резервирование, передавая, например, сообщение RSVP RESV, он представляет уникальный идентификационных маркер, встроенный в объект политики. Обработка такого маркера на поддерживающем политику маршрутизаторе приводит к снижению числа «единиц обслуживания» для этого маркера.

Возвращаясь к рисунку 4, предположим, что получатель R1 в административном домене AD3 хочет зарезервировать услугу из AD1. R1 генерирует объект данных политики типа PD(prc, CID), где prc означает карту предоплаты, а CID указывает номер карты. Вместе с другими объектами политики в сообщении RESV этот объект приходит на узел E, который пересылает его своей точке PEP (PEP_E), а так обращается к PDP PS-3. Точка PS-3 обращается к локальной или удаленной карт предоплаты. Если кредит карты с номером CID не исчерпан, PDP разрешает резервирование и объект политики возвращается PEP_E. Здесь нужно решить два вопроса:

  • какова область действия оплаты?

  • когда оплата происходит в первый раз (в форме снижения остатка)?

Ответ на первый вопрос связан с действующими двухсторонними соглашениями. Если провайдер AD-3 имеет соглашения с AD-2 и AD-1, он будет оплачивать стоимость полного резервирования вплоть до отправителя S1. В этом случае PS-2 удалит объект PD(prc,CID) из отправляемого сообщения RESV.

Если же у AD-3 нет двухсторонних соглашений, он просто будет снимать с CID плату за резервирование внутри AD-3 и пересылать PD(prc,CID) в исходящем сообщении RESV. Следующие PDP в других административных доменах также снимут с CID плату за свое резервирование. Поскольку множество объектов считывает (оставшиеся средства) и записывает (снятие оплаты) информацию в одну базу данных, требуется тот или иной контроль доступа к базе и блокировка записи. Вопросы, связанные с размещением, поддержкой и координацией платежных баз данных выходят за рамки этого документа.

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

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

5.5. Заданные отправителем ограничения на резервирование

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

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

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

6. Взаимодействие между PEP и PDP

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

6.1. Требования к протоколу между PEP и PDP

В этом разделе приведены общие требования к протоколу взаимодействия между PEP и внешней точкой PDP.

Надежность

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

Малые задержки

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

Способность передавать неразобранные объекты

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

Поддержка инициируемых PEP двухсторонних транзакций

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

Поддержка асинхронных уведомлений

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

Обслуживание multicast-групп

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

Спецификация QoS

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

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

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

В случае сигнализации RSVP может применяться аутентификация сообщений RSVP MD5 [2] для защиты коммуникаций между элементами сети.

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

[1] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, «Resource ReSerVation Protocol (RSVP) — Version 1 Functional Specification», RFC 2205, September 1997.

[2] Baker, F., Lindell, B. and M. Talwar, «RSVP Cryptographic Authentication», RFC 2747, January 2000.

[3] Herzog, S., «RSVP Extensions for Policy Control», RFC 2750, January 2000.

[4] Atkinson, R., «Security Architecture for the Internet Protocol», RFC 18257, August 1995.

[5] Rigney, C., Rubens, A., Simpson, W. and S. Willens, «Remote Authentication Dial In User Service (RADIUS)», RFC 21388, April 1997.

[6] Rajan, R., et al., «Schema for Differentiated Services and Integrated Services in Networks», Work in Progress.

[7] Herzog, S., «RSVP Preemption Priority Policy», Work in Progress.

[8] Herzog, S., «COPS Usage for RSVP», RFC 2749, January 2000.

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

Эта работа является результатом обсуждений среди членов группы RAP, включая Jim Boyle, Ron Cohen, Laura Cunningham, Dave Durham, Shai Herzog, Tim O’Malley, Raju Rajan и Arun Sastry.

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

Raj Yavatkar

Intel Corporation

2111 N.E. 25th Avenue,

Hillsboro, OR 97124

USA

Phone: +1 503-264-9077

EMail: raj.yavatkar@intel.com

Dimitrios Pendarakis

IBM T.J. Watson Research Center

P.O. Box 704

Yorktown Heights

NY 10598

Phone: +1 914-784-7536

EMail: dimitris@watson.ibm.com

Roch Guerin

University of Pennsylvania

Dept. of Electrical Engineering

200 South 33rd Street

Philadelphia, PA 19104

Phone: +1 215 898-9351

EMail: guerin@ee.upenn.edu


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

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

nmalykh@protocols.ru

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

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

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


1Интегрированные услуги.

2Дифференцированные услуги.

3Quality of Service — качество обслуживания.

4Access control list — список управления доступом.

5Authentication Header — заголовок аутентификации.

6Encapsulating Security Payload — инкапсуляция защищенных данных.

7Заменен RFC 2401. Прим. перев.

8Заменен RFC 2865. Прим. перев.




RFC 2747 RSVP Cryptographic Authentication

Network Working Group                                F. Baker
Request for Comments: 2747                              Cisco
Category: Standards Track                          B. Lindell
                                                      USC/ISI
                                                    M. Talwar
                                                    Microsoft
                                                 January 2000

Криптографическая аутентификация RSVP

RSVP Cryptographic Authentication

PDF

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

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

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

Copyright (C) The Internet Society (2000). All Rights Reserved.

Тезисы

В этом документе описан формат и применение объекта RSVP INTEGRITY для поэтапного обеспечения целостности и аутентификации сообщений RSVP.

1. Введение

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

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

Примечание. В этом документе смысл терминов «отправитель» (sender) и «получатель» (receiver) отличается от принятого в [1]. Термины относятся к системам, расположенным по разные стороны одного интервала (hop) RSVP, при этом отправителем считается система, генерирующая сообщения RSVP.

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

Предложенный механизм не зависит от какого-либо криптографического алгоритма, но в документе описывается применение хеширования с ключами для аутентификации сообщений2 с использованием HMAC-MD5 [7]. Как отмечено в работе [7], существуют более строгие алгоритмы хэширования (типа HMAC-SHA1); с тех случаях, где это целесообразно, реализациям следует делать такие алгоритмы доступными. Однако для общего случая в документе [7] показана адекватность HMAC-MD5 для заявленной цели, а также отмечено преимущество этого алгоритма в части производительности. В работе [7] также приведен исходный код и тестовые векторы для данного алгоритма, позволяющие проверить интероперабельность. HMAC-MD5 требуется в качестве базового механизма RSVP для обеспечения криптографической аутентификации, но опционально могут быть предложены и другие алгоритмы (см. раздел 6).

Контрольные суммы RSVP могут быть отключены (0) wпри включении в сообщение объекта INTEGRITY, поскольку цифровая подпись обеспечивает более строгую проверку целостности, нежели контрольная сумма.

1.1. Используемые соглашения

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

1.2. Почему не применяется стандартный заголовок IPSEC AH?

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

Защищенные связи в IPSEC базируются на адресах получателей. Не очевидно, что сообщения могут быть надежно определены для любого отправителя или получателя на базе защищенных связей, поскольку маршрутизаторы должны пересылать сообщения PATH и PATH TEAR с использованием того же адреса отправителя, который отправитель указал в SENDER TEMPLATE. Иначе служебный трафик RSVP может пойти по пути, отличному от пути доставки данных. Использование связей на основе адреса получателя или отправителя будет требовать создания новых защищенных связей между маршрутизаторами, через которые организуется резервирование.

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

2. Структуры данных

2.1. Формат объекта INTEGRITY

Сообщение RSVP состоит из последовательности «объектов» представляющих собой структуры вида TLV3. Информация, требуемая для поэтапной (hop-by-hop) проверки целостности, передается в объектах INTEGRITY. Одинаковые объекты INTEGRITY применимы как для IPv4, так и для IPv6.

Формат объекта INTEGRITY показан ниже.

       INTEGRITY: Class = 4, C-Type = 1

       +-------------+-------------+-------------+-------------+
       |    Flags    | 0 (резерв)  |                           |
       +-------------+-------------+                           +
       |                    Key Identifier                     |
       +-------------+-------------+-------------+-------------+
       |                    Sequence Number                    |
       |                                                       |
       +-------------+-------------+-------------+-------------+
       |                                                       |
       +                                                       +
       |                                                       |
       +                  Keyed Message Digest                 |
       |                                                       |
       +                                                       +
       |                                                       |
       +-------------+-------------+-------------+-------------+
Flags - 8-битовое поле, формат которого показан ниже.
                                      Flags

                          0   1   2   3   4   5   6   7
                        +---+---+---+---+---+---+---+---+
                        | H |                           |
                        | F |             0             |
                        +---+---+---+---+---+---+---+---+

В настоящее время определен лишь флаг HF, а оставшиеся биты являются резервными и должны иметь значение 0.

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

  • Key Identifier — 48-битовое целое число без знака, которое должно быть уникальным для данного отправителя. Уникальные в локальном масштабе значения Key Identifier можно создавать на основе адресов (IP, MAC или LIH) передающего интерфейса и номера ключа. Комбинация Key Identifier с IP-адресом системы является уникальным идентификатором защищенной связи (параграф 2.2).

  • Sequence Number — 64-битовый, монотонно возрастающий порядковый номер (целое число без знака).

    В качестве значений Sequence Number могут служить монотонно возрастающие последовательности из объектов INTEGRITY [каждого сообщения RSVP] с тегом, обеспечивающим уникальную связь с временем жизни ключа. Генерация порядковых номеров подробно рассматривается в разделе 3.

  • Keyed Message Digest — подпись должна иметь размер, кратный 4 октетам. Для HMAC-MD5 размер подписи составляет 16 байтов.

2.2. Защищенная связь

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

  • алгоритм аутентификации и используемый режим этого алгоритма;

  • ключ, применяемый с алгоритмом аутентификации;

  • время жизни ключа;

  • привязанный передающий интерфейс и другие критерии выбора защищенной связи [требуется на передающей системе];

  • адрес отправителя на передающей системе [требуется на приемной системе];

  • последний переданный порядковый номер, использованный с этим идентификатором ключа [требуется на приемной системе];

  • список из последних N порядковых номеров, принятых с этим идентификатором ключа [требуется на приемной системе].

3. Генерация порядковых номеров

В этом параграфе описаны методы, которые могут быть выбраны для генерации порядковых номеров, используемых в объектах INTEGRITY сообщений RSVP. Как было отмечено выше, имеются два важных свойства, которые должны быть обеспечены в процедуре генерации. Первым свойством является уникальность (однократное применение) порядковых номеров в течение всего срока жизни текущего используемого ключа защиты целостности. Получатель может использовать это свойство для того, чтобы однозначно различать новые и повторные сообщения. Вторым свойством является монотонный рост номеров с использованием модуля 264. Это требуется для существенного снижения сохраняемого объема состояний, поскольку получателю достаточно сохранить значение с наибольшим порядковым номером для предотвращения атак с повторным использованием пакетов (replay). Поскольку начальный порядковый номер может быть произвольно большим, требуется применение операций с модулем для обеспечения возможности начала отсчета с нуля в течение жизни одного ключа. Это решение основано на нумерации в TCP [9].

Поле порядкового номера трактуется, как 64-битовое целое число без знака. Размер поля достаточно велик для того, чтобы нумерации хватило на весь срок жизни ключа. Например, если для ключа выбран срок жизни в 1 год, нумерации будет достаточно для передачи сообщений RSVP со средней скоростью около 585 Гига-сообщений в секунду. Использование 32-битовых порядковых номеров снизило бы этот предел до 136 сообщений в секунду.

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

3.1. Простые порядковые номера

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

3.2. Порядковые номера на основе системного времени

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

В этой модели можно использовать основанную на NTP временную метку в качестве порядкового номера. Цикл полного отсчета для временных меток NTP составляет около 136 лет, что значительно превышает разумный срок жизни любого ключа. Кроме того, дискретность меток NTP достаточно хороша для того, чтобы можно было генерировать сообщение RSVP для данного ключа каждые 200 пикосекунд. Однако многие часы не поддерживают уровня дискретности меток NTP. В таких случаях младшие биты временной метки можно создавать с использованием счетчика сообщений, который сбрасывается при каждом «тике» системных часов. Например, если часы обеспечивают дискретность в 1 секунду, 32 младших бита порядкового номера можно задавать с использованием счетчика сообщений. В оставшиеся 32 бита порядкового номера следует помещать 32 старших5 бита временной метки. Если предположить, что время восстановления после отказа занимает более одного «тика» системных часов, значение счетчика для младших битов порядкового номера можно смело сбрасывать после перезапуска системы.

3.3. Порядковые номера на основе сетевого времени

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

4. Обработка сообщений

Реализациям следует разрешать спецификацию интерфейсов, которые будут защищены для отправки сообщений, их приема или в обоих случаях. Отправитель должен обеспечить во всех сообщениях RSVP, передаваемых через защищенные интерфейсы, наличие объекта INTEGRITY, созданного с использованием подходящего ключа Key. Получатели проверяют сообщения RSVP (за исключением типа Integrity Challenge, см. параграф 4.3), прибывающие на защищенный приемный интерфейс, на предмет наличия в них объекта INTEGRITY. Если объект INTEGRITY отсутствует, получатель отбрасывает сообщение.

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

Каждому отправителю следует иметь разные защищенные связи (и ключи) на защищенных передающих интерфейсах (или LIH). Хотя администраторы могут настроить все маршрутизаторы и хосты своей подсети (или сети) на использование одной защищенной связи, реализации должны предполагать, что каждый отправитель может передавать, используя отдельную защищенную связь на каждом защищенном интерфейсе. На стороне отправителя выбор защищенной связи происходит по интерфейсам, через которые передается сообщение. Этот выбор может учитывать дополнительные критерии типа адреса получателя (при передаче unicast-сообщения через широковещательную ЛВС с большим числом хостов) или идентификации пользователя на стороне отправителя или получателя [2]. Кроме того, все предполагаемые получатели сообщения должны участвовать в этой защищенной связи. Переключения (flap) маршрутов в сети без поддержки RSVP могут приводить к передаче сообщений для одного получателя через разные интерфейсы в разное время. В таких случаях получателю следует участвовать во всех защищенных связях, которые могут быть выбраны для возможных выходных интерфейсов.

Получатели выбирают ключи на основе Key Identifier и IP-адреса передающей стороны. Значение Key Identifier включается в объект INTEGRITY. Адрес передающей стороны может быть получен из объекта RSVP_HOP или (при отсутствии такого объекта, как в случае сообщений PathErr и ResvConf) из IP-адреса отправителя. Поскольку значение Key Identifier уникально для отправителя, этот метод обеспечивает уникальную идентификацию ключа.

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

4.1. Генерация сообщений

Сообщения RSVP, передаваемые через защищенный выходной интерфейс, создаются, как описано в [1], за исключением перечисленного ниже.

  1. Поле контрольной суммы RSVP устанавливается в 0. При необходимости контрольная сумма RSVP может быть рассчитана по завершении обработки объекта INTEGRITY.

  2. Объект INTEGRITY помещается в подходящее место и его позиция в сообщении запоминается для последующего использования.

  3. Передающий интерфейс и другие подходящие критерии (как указано выше) используются для определения ключа аутентификации Authentication Key и применяемого алгоритма хэширования.

  4. Неиспользуемые флаги и резервные поля объекта INTEGRITY должны быть установлены в 0. Флаг согласования HF6 следует устанавливать в соответствии с правилами, описанными в параграфе 2.1.

  5. Номер передающего интерфейса должен обновляться для обеспечения уникальных, монотонно возрастающих порядковых номеров. Этот номер помещается в поле Sequence Number объекта INTEGRITY.

  6. В поле Keyed Message Digest помещается значение 0.

  7. Идентификатор ключа (Key Identifier) включается в объект INTEGRITY.

  8. Рассчитывается аутентификационная подпись сообщения с использованием Authentication Key в комбинации с алгоритмом хеширования. Для случая алгоритма HMAC-MD5 вычисление хэш-значения описано в [7].

  9. Полученная подпись записывается в поле Cryptographic Digest объекта INTEGRITY.

4.2. Прием сообщений

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

  1. Значение поля контрольной суммы RSVP сохраняется, а в поле помещается 0.

  2. Значение поля Cryptographic Digest объекта INTEGRITY сохраняется, а в поле помещается 0.

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

  4. Рассчитывается новая подпись с использованием указанного алгоритма и ключа Authentication Key.

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

  6. Если сообщение относится к типу Integrity Response, проверяется соответствие объекта CHALLENGE запросу. При наличии соответствия порядковый номер сохраняется в объекте INTEGRITY, как наибольший принятый номер.

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

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

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

При получении на защищенном интерфейсе сообщения Integrity Challenge оно обрабатывается следующим образом:

  1. Формируется сообщение Integrity Response с использованием объекта Challenge, полученного в сообщении-вызове.

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

4.3. Согласование защиты целостности при перезапуске и инициализации получателя

Чтобы получить стартовый порядковый номер для Authentication Key, получатель может инициировать согласование защиты целостности с отправителем. Это согласование включает вызов получателя Challenge и отклик отправителя Response, согласование может быть инициировано в процессе перезапуска или отложено до момента приема сообщения, подписанного ключом.

Когда получатель решил инициировать согласование защиты целостности для конкретного ключа Authentication Key, он идентифицирует отправителя с использованием адреса передающей системы, настроенного для соответствующей защищенной связи. Получатель передает сообщение RSVP Integrity Challenge отправителю. Это сообщение содержит Key Identifier для идентификации ключа отправителя и должно иметь уникальной значение cookie отправителя, основанное на локальном секрете для предотвращения его подбора (см. параграф 2.5.3 работы [4]). Предполагается, что значение cookie будет представлять собой хэш MD5 для локального секрета и временной метки с целью обеспечения уникальности (см. раздел 9).

Сообщение RSVP Integrity Challenge относится к типу 11 и имеет формат:

<Integrity Challenge> ::= <Common Header> <CHALLENGE>

Объект CHALLENGE имеет формат:

       CHALLENGE: Class = 64, C-Type = 1

       +-------------+-------------+-------------+-------------+
       |         0 (резерв)        |                           |
       +-------------+-------------+                           +
       |                    Key Identifier                     |
       +-------------+-------------+-------------+-------------+
       |                    Challenge Cookie                   |
       |                                                       |
       +-------------+-------------+-------------+-------------+

Отправитель воспринимает Integrity Challenge без проверки целостности. Он возвращает сообщение RSVP Integrity Response, содержащее исходный объект CHALLENGE. Сообщение также включает объект INTEGRITY, подписанный с помощью ключа, заданного Key Identifier из Integrity Challenge.

Сообщение RSVP Integrity Response относится к типу 12 и имеет формат:

<Integrity Response> ::= <Common Header> <INTEGRITY> <CHALLENGE>

Сообщение Integrity Response воспринимается получателем (challenger) только в том случае, когда оно возвращает объект CHALLENGE, соответствующий переданному в сообщении Integrity Challenge. Это предотвращает повторное использование старых сообщений Integrity Response. Если объекты соответствуют, получатель сохраняет номер Sequence Number из объекта INTEGRITY в качестве последнего номера, полученного с идентификатором ключа, включенным в объект CHALLENGE.

Если отклик не приходит в течение заданного периода, запрос (challenge) повторяется. После успешного завершения процедуры согласования защиты целостности получатель начинает воспринимать обычные сигнальные сообщения RSVP от данного отправителя и игнорирует другие сообщения Integrity Response.

Флаг согласования HF (Handshake Flag) используется для того, чтобы обеспечить реализациям гибкость без использования механизма согласования защиты целостности. Путем установки этого флага (1) отправители сообщений, реализующие согласование защиты целостности, отличают себя от остальных. Получателям не следует пытаться согласовывать защиту целостности с отправителями, чьи объекты INTEGRITY имеют HF = 0.

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

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

5. Управление ключами

Вполне вероятно, что IETF будет определять стандартный протокол управления ключами. Весьма желательно использовать этот протокол для распространения ключей RSVP Authentication Key между взаимодействующими реализациями RSVP. Такой протокол обеспечит масштабируемость и существенное снижение нагрузки на администраторов. Идентификаторы ключей (Key Identifier) могут послужить связкой между RSVP и будущим протоколом управления ключами. Протоколы управления ключами имеют долгую историю недостатков, которые зачастую обнаруживались значительно позже публикации соответствующего протокола. Чтобы избежать необходимости изменения всех реализаций RSVP в результате обнаружения таких недостатков, встроенные средства управления ключами были преднамеренно исключены из данной спецификации.

5.1. Процедуры управления ключами

Каждый ключ имеет связанное с ним время жизни, которое записывается во всех системах (отправители и получатели), настроенных на работу с этим ключом. Концепция «времени жизни» ключа требует лишь понятного для систем представления значения начала (KeyStartValid) и завершения (KeyEndValid) срока действия ключа. Некоторые механизмы генерации ключей типа Kerberos и некоторых схем с открытыми ключами, могут напрямую создавать эфемерные ключи. В таких случаях время жизни ключа неявно определяется самим ключом.

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

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

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

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

5.2. Требования к управлению ключами

Требования к реализациям перечислены ниже.

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

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

  • Реализации должны связывать конкретное время жизни (KeyStartValid и KeyEndValid) с каждым ключом и соответствующим идентификатором Key Identifier.

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

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

  • Устаревшие ключи могут автоматически удаляться реализацией.

  • Должно также поддерживаться удаление активных ключей вручную.

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

5.3. Патологический случай

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

6. Требования по соответствию

Для соответствия данной спецификации реализация должна поддерживать все аспекты спецификации. Во всех соответствующих этому документу реализациях должен поддерживаться алгоритм аутентификации HMAC-MD5, определенный в [7]. В соответствии со спецификацией реализации могут также поддерживать другие алгоритмы аутентификации типа NIST Secure Hash Algorithm (SHA). Все реализации должны поддерживать описанное выше распространение ключей вручную. Все реализации должны поддерживать продление срока жизни ключей, как описано в параграфе «5.1. Процедуры управления ключами».

Реализациям следует поддерживать стандартный протокол управления ключами для защищенного распространения ключей RSVP Authentication Key после того, как такой протокол будет стандартизован IETF.

7. Генерация Authentication Key с помощью Kerberos

Алгоритм Kerberos[10] может использоваться для генерации ключей RSVP Authentication, применяемых для генерации подписи в объектах Integrity, которые передаются отправителем RSVP получателям. Генерация ключей Kerberos избавляет от необходимости применения ключей, разделяемых отправителями и получателями RSVP (хосты и маршрутизаторы). Kerberos позволяет использовать связь между защищаемыми сторонами (отправитель и получатели RSVP) через доверенную третью сторону, когда центр распространения ключей Kerberos (KDC) организует эфемерные сеансовые ключи впоследствии разделяемые между отправителем и получателями RSVP. Для группового случая все получатели группового сообщения RSVP должны разделять общий ключ с KDC (т. е., получатели эффективно являются защищаемой стороной относительно Kerberos).

Информация о ключе (Key information), определенная отправителем, может задавать использование Kerberos вместо заданных в конфигурации разделяемых ключей в качестве механизма обмена ключами между отправителем и получателем. Kerberos-идентификация получателя организуется в процессе настройки конфигурации интерфейса отправителя или с помощью иного механизма. При генерации первого сообщения RSVP для конкретного идентификатора ключа отправитель запрашивает «квитанцию» от сервиса Kerberos и получет эфемерный сеансовый ключ и квитанцию Kerberos от KDC. Отправитель инкапсулирует квитанцию и свою идентификацию в объект Identity Policy [2]. Объект Policy Object отправитель включает в сообщение RSVP. Сеансовый ключ используется отправителем в качестве ключа RSVP Authentication на этапе (3) (параграф 4.1) и сохраняется как информация о ключе, связанная в идентификатором ключа.

При получении сообщения RSVP приемная сторона извлекает Kerberos Ticket из объекта Identity Policy, дешифрует квитанцию и извлекает из нее сеансовый ключ. Этот ключ совпадает с применяемым отправителем ключом и используется на этапе (3) (параграф 4.2). Получатель сохраняет ключ для использования при обработке последующих сообщений RSVP.

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

7.1. Оптимизация при использовании аутентификации на базе Kerberos

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

У получателя может не оказаться кэшированного ключа с его Key Identifier по причине перезагрузки или изменения маршрута. Если политика получателя задает использование ключей Kerberos для проверки целостности, получатель может передать отправителю сообщение Integrity Challenge. При получении такого сообщения отправитель должен передать объект Identity, включающий квитанцию Kerberos, в сообщении Integrity Response, что позволит получателю получить и сохранить сеансовый ключ из квитанции Kerberos для последующих проверок целостности.

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

Этот документ непосредственно базируется на похожей работе, выполненной для протоколов OSPF и RIP Version II совместно Ran Atkinson и Fred Baker. Существенная работа по редактированию была выполнена Bob Braden, что улучшило ясность изложения. Были получены важные комментарии от Steve Bellovin, хорошо знающего эту тему. Matt Crawford и Dan Harkins помогли в пересмотре документа.

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

[1] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, «Resource ReSerVation Protocol (RSVP) — Version 1 Functional Specification», RFC 2205, September 1997.

[2] Yadav, S., et al., «Identity Representation for RSVP», RFC 27528, January 2000.

[3] Atkinson, R. and S. Kent, «Security Architecture for the Internet Protocol», RFC 24019, November 1998.

[4] Maughan, D., Schertler, M., Schneider, M. and J. Turner, «Internet Security Association and Key Management Protocol (ISAKMP)», RFC 240810, November 1998.

[5] Kent, S. and R. Atkinson, «IP Authentication Header», RFC 240211, November 1998.

[6] Kent, S. and R. Atkinson, «IP Encapsulating Security Payload (ESP)», RFC 240612, November 1998.

[7] Krawczyk, H., Bellare, M. and R. Canetti, «HMAC: Keyed-Hashing for Message Authentication», RFC 2104, March 1996.

[8] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997. (перевод)

[9] Postel, J., «Transmission Control Protocol», STD 7, RFC 793, September 1981. (перевод)

[10] Kohl, J. and C. Neuman, «The Kerberos Network Authentication Service (V5)», RFC 151013, September 1993.

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

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

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

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

Однако это позволяет атакующему генерировать обманные запросы на согласование с неким challenge cookie. Атакующий может сохранить полученные отклики и попытаться использовать их для атаки на восстанавливаемого получателя. При определенном везении атакующий может угадать значение challenge cookie, используемые получателем в процессе восстановления. Тогда переданный атакующим обманный отклик будет воспринят, поскольку он имеет корректную подпись и меньший, чем у отправителя порядковый номер (поскольку сообщение будет более старым). Таким образом открывается возможность атаки на получателя с повторным использованием пакетов. Однако использование такой возможности представляется весьма проблематичным. Требуется не только заранее угадать значение challenge cookie (основано на локальном секрете), но и иметь возможность замаскироваться под получателя для генерации Integrity Challenge с корректным адресом IP и не оказаться пойманным.

Данный механизм не обеспечивает защиты конфиденциальности. Если такая защита нужна, эффективным решением может быть IPSEC ESP [6], хотя ему полностью присущи недостатки IPSEC Authentication и, следовательно, применение возможно только в специфических средах. Не обеспечивается и защиты от анализа трафика. Для обеспечения такой защиты могут применяться механизмы шифрования данных на уровне канала.

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

Fred Baker

Cisco Systems

519 Lado Drive

Santa Barbara, CA 93111

Phone: (408) 526-4257

EMail: fred@cisco.com

Bob Lindell

USC Information Sciences Institute

4676 Admiralty Way

Marina del Rey, CA 90292

Phone: (310) 822-1511

EMail: lindell@ISI.EDU

Mohit Talwar

Microsoft Corporation

One Microsoft Way

Redmond, WA 98052

Phone: +1 425 705 3131

EMail: mohitt@microsoft.com

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

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

nmalykh@protocols.ru

12. Приложение 1 — Интерфейс управления ключами

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

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

12.1. Структура данных

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

     KeyInfo {
             Тип ключа (Send или Receive)
             KeyIdentifier
             Ключ
             Тип и режим алгоритма аутентификации
             KeyStartValid
             KeyEndValid
             Статус (Active или Deleted)
             Выходной интерфейс (только для Send)
             Другие критерии выбора исходящей защищенной связи 
                     (только для Send, не обязательно)
             Адрес передающей системы (только для Receive)
     }

12.2. Таблица используемых по умолчанию ключей

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

KM_DefaultKeyTable() -> KeyInfoList

12.3. Запрос неизвестных ключей приема

При получении сообщения с неизвестной парой (Key Identifier, Sending System Address) RSVP может использовать эту функцию для запроса подходящего ключа у системы управления ключами (Key Management System). Функция возвращает статус элемента (если он найден), который должен иметь значение Active.

KM_GetRecvKey( INTEGRITY Object, SrcAddress ) -> KeyInfo

12.4. Опрос на предмет обновлений

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

KM_KeyTablePoll() -> KeyInfoList

12.5. Интерфейс асинхронных Upcall-вызовов

Вместо повторяющихся вызовов KM_KeyTablePoll() реализация может воспользоваться асинхронной моделью на основе событий. Эта функция регистрирует интерес к смене ключа для заданного Key Identifier или для всех ключей при отсутствии Key Identifier. Функция будет вызываться при каждой смене ключей.

KM_KeyUpdate( Function [, KeyIdentifier ] )

где upcall-функция параметризуется следующим образом:

Function( KeyInfo )

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

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an «AS IS» basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

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

1Resource ReSerVation Protocol.

2Keyed-Hashing for Message Authentication.

3Type-length-value – тип-размер-значение.

4Handshake Flag.

5В оригинале ошибочно сказано «32 least significant bits». См. http://www.rfc-editor.org/errata_search.php?eid=4313. Прим. перев.

6Handshake Flag.

7Network Time Protocol.

8Этот документ заменен RFC 3182. Прим. перев.

9Этот документ заменен RFC 4301 (перевод). Прим. перев.

10Этот документ заменен RFC 4306 (перевод). Прим. перев.

11Этот документ заменен RFC 4302 (перевод) и RFC 4305 (перевод). Прим. перев.

12Этот документ заменен RFC 4303 (перевод) и RFC 4305 (перевод). Прим. перев.

13Этот документ заменен RFC 4120 и RFC 6649. Прим. перев.




Методы цифрового кодирования

Методы цифрового кодирования

PDF

Цифровое кодирование (Digital Encoding), иногда не совсем корректно называемое модуляцией, определяет способ представления битов в физическом канале передачи данных. В этом документе рассмотрены различные варианты цифрового кодирования от простого метода NRZ (Non Return to Zero – без возврата к нулю) до существенно более сложного кодирования HDB3 (High Density Bipolar 3 – биполярное кодирование с высокой плотностью, вариант 3). Документ содержит список требований, предъявляемых к алгоритмам цифрового кодирования, и краткие описания наиболее распространенных методов кодирования цифровых сигналов.

Требования к алгоритмам цифрового кодирования

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

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

  2. Невысокий уровень постоянного напряжения в линии.

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

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

Обзор методов цифрового кодирования

NRZ — Non Return to Zero (без возврата к нулю)

В этом варианте кодирования используется следующее представление битов:

  • биты 0 представляются нулевым напряжением (0 В);

  • биты 1 представляются напряжением +V.

Рисунок 1. Кодирование NRZ.

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

  • высокий уровень постоянного напряжения (среднее значение 1/2V для последовательности, содержащей равное число 1 и 0);

  • широкая полоса сигнала (от 0 Гц для последовательности, содержащей только 1 или только 0, до половины скорости передачи данных при чередовании 10101010…);

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

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

RZ — Return to Zero (возврат к нулю)

Цифровые данные представляются следующим образом:

  • биты 0 представляются нулевым напряжением (0 В);

  • биты 1 представляются значением +V в первой половине и нулевым напряжением – во второй, т.е. единице соответствует импульс напряжения продолжительностью в половину длительности передачи одного бита данных.

Рисунок 2. Кодирование RZ.

Этот метод имеет два преимущества по сравнению с кодированием NRZ:

  • средний уровень напряжения в линии составляет ¼ V (вместо ½ V);

  • при передаче непрерывной последовательности 1 сигнал в линии не остается постоянным.

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

NRZI — Non Return to Zero Invertive (инверсное кодирование без возврата к 0)

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

  • биты 0 представляются нулевым напряжением (0 В);

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

Рисунок 3. Кодирование NRZI.

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

AMI — Alternate Mark Inversion (поочередная инверсия единиц)

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

  • биты 0 представляются нулевым напряжением (0 В);

  • биты 1 представляются поочередно значениями +V и -V.

Рисунок 4. Кодирование AMI.

Этот метод подобен алгоритму RZ, но обеспечивает в линии нулевой уровень постоянного напряжения. Недостатком метода AMI является ограничение на «плотность» нулей в потоке данных, поскольку длинные последовательности 0 ведут к потере синхронизации.

HDB3 — High Density Bipolar 3 (биполярное кодирование с высокой плотностью)

Представление битов в методе HDB3 лишь незначительно отличается от представления, используемого алгоритмом AMI. При наличии в потоке данных 4 последовательных битов 0 последовательность изменяется на 000V, где полярность бита V такая же, как для предшествующего ненулевого импульса (в отличие от кодирования битов 1, для которых знак сигнала V изменяется поочередно для каждой единицы в потоке данных).

Рисунок 5. Кодирование HDB3.

Этот алгоритм снимает ограничения на плотность 0, присущие кодированию AMI, но порождает взамен новую проблему – в линии появляется отличный от нуля уровень постоянного напряжения за счет того, что полярность отличных от нуля импульсов совпадает. Для решения этой проблемы полярность бита V изменяется по сравнению с полярностью предшествующего бита V. Когда это происходит, битовый поток изменяется на B00V, где полярность бита B совпадает с полярностью бита V. Когда приемник получает бит B, он думает, что этот сигнал соответствует значению 1, но после получения бита V (с такой же полярностью) приемник может корректно трактовать биты B и V как 0.

Метод HDB3 удовлетворяет всем требованиям, предъявляемым к алгоритмам цифрового кодирования, но при использовании этого метода могут возникать некоторые проблемы.

PE — Phase Encode (Manchester, фазовое кодирование, манчестерское кодирование)

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

  • биты 0 представляются напряжением +V в первой половине бита и напряжением -V – во второй половине;

  • биты 1 представляются напряжением -V в первой половине бита и напряжением +V – во второй половине.

Рисунок 6. Манчестерское кодирование.

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

CDP — Conditional Diphase

Этот метод является комбинацией алгоритмов NRZI и PE и использует следующие представления битов цифрового потока:

  • биты 0 представляются переходом напряжения в том же направлении, что и для предшествующего бита (от +V к -V или от -V к +V);

  • биты 1 представляются переходом напряжения в направлении, противоположном предшествующему биту (от +V к -V или от -V к +V).

Рисунок 7. Кодирование CDP.

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

Заключение

Как вы увидели из приведенных описаний, существует достаточно много алгоритмов кодирования цифровых сигналов. Простейший метод NRZ используется в протоколах на базе интерфейса RS232, в сетях Ethernet применяется кодирование PE, а в телефонии используется алгоритм HDB3 (этот метод служит для кодирования сигналов в потоках E1 и E2). Выбор метода кодирования зависит от полосы канала связи, используемой кабельной системы, скорости передачи данных и других параметров.

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

nmalykh@protocols.ru