Протоколы Internet
Протокол COPS (Common Open Policy Service)
4.4.9.7 Протокол COPS (Common Open Policy Service)
Семенов Ю.А. (ГНЦ ИТЭФ)
1. Базовая модель
Рис. .1. Схема взаимодействия различных частей COPS.
На рисунке .1 показано взаимодействие различных компонентов политики (взято из [WRK]). Здесь, COPS используется для обмена описаниями политики между узлами реализации политики PEP (Policy Enforcement Point) и удаленными пунктами принятия политических решений PDP (Policy Decision Point) в пределах контекста конкретного типа клиента. Может использоваться опционный пункт принятия локального политического решения LPDP (Local Policy Decision Point) в отсутствии PDP.
Предполагается, что каждый конкретный клиент политики функционально совместим с PEP [WRK]. PEP может обмениваться информацией с сервером политики.
PEP ответственен за инициализацию постоянного TCP-соединения с PDP. Узел PEP использует это соединение для посылки запросов и получения откликов-решений от удаленного PDP. Коммуникация между PEP и удаленным PDP происходит в основном в форме обменов запрос-решение, хотя удаленный PDP может по своей инициативе послать PEP и не запрошенное решение, чтобы вызвать изменение одобренных ранее состояний запросов. PEP имеет также возможность сообщать удаленному >PDP, что решение PDP успешно исполнено локально. Узел PEP ответственен за уведомление PDP об изменении состояния запроса в PEP. Наконец, в функции PEP входит аннулирование любого состояния, которое не может быть использовано из-за событий, имевших место у клиента, или в силу решений, принятых сервером.
После этого PEP посылает конфигурационный запрос, и ожидает присылки от PDP именованных блоков конфигурационных данных (в виде сообщений-решений). Когда именованные конфигурационные данные успешно доставлены PEP, он должен послать PDP сообщение-отчет, подтверждающее получение конфигурационных данных. Сервер с помощью сообщения-решения может после этого обновить или удалить конфигурационную информацию. Когда PDP посылает решение об удалении именованной конфигурационной информации на PEP, PEP стирает специфицированные данные и посылает PDP в качестве подтверждения сообщение-отчет.
Протокол политики предполагает коммуникацию с само идентифицируемыми объектами, которые содержат данные, необходимые для идентификации состояний запроса, устанавливающие контекст запроса, его тип, содержащие ссылки на поступившие ранее запросы, принятые политические решения, поступившие сообщения об ошибках и прочие данные специфичные для клиента.
Чтобы идентифицировать разные виды клиентов, в каждом сообщении приводится тип клиента. Разные типы клиентов могут иметь различные специфические данные и могут требовать различных политических решений. Ожидается, что каждый новый тип клиента имеет соответствующее описание, характеризующее специфику его взаимодействия с данным протоколом описания политики.
Контекст каждого запроса соответствует типу события, его вызвавшего. Объект контекста COPS идентифицирует тип запроса и сообщения, которые вызвали данное политическое событие, посредством своих полей типа сообщения и запроса. COPS идентифицирует три типа событий: (1) приход сообщения (2) выделение локальных ресурсов, и (3) переадресацию исходящего сообщения. Каждое из этих сообщений может потребовать различных решений. Содержимое сообщений COPS-запросов/решений зависит от контекста. Четвертый тип запроса полезен для типов клиентов, которые хотят получить конфигурационную информацию от PDP. Это позволяет >PEP послать конфигурационный запрос специфическому именованному устройству или модулю, который требует инсталляции конфигурационной информации. PEP может также иметь возможность принимать локальные политические решения с помощью LPDP (Local Policy Decision Point) [WRK], однако, PDP всегда остается точкой принятия решений. Это означает, что соответствующая информация о локальных решениях должна передаваться PDP. То есть, PDP должен быть предоставлен доступ к информации, чтобы принять окончательное политическое решение. Чтобы обеспечить такую возможность, PEP должен послать информацию о локальном решении удаленному PDP посредством объекта решения LPDP. PEP должен затем следовать решению PDP, так как оно является окончательным.
Наконец, допустимость ошибки ( fault tolerance) является обязательной особенностью данного протокола, в частности из-за того, что он ассоциируется с управлением услугами и безопасностью в распределенных сетях. Допустимость ошибки может быть достигнута за счет того, что PEP и удаленный PDP постоянно проверяют свое соединение путем посылки тестовых сообщений keep-alive (“еще жив?”). Когда обнаружен отказ, PEP должен попытаться восстановить контакт с удаленным PDP или соединиться с альтернативным (backup) PDP. Пока PEP не имеет связи, он должен ограничиться принятием локальных решений. Как только соединение восстановлено, PEP должен уведомить PDP о любом ликвидированном состоянии или о событиях, которые произошли с момента потери соединения. Кроме того, удаленный PDP может потребовать, чтобы все внутренние состояния PEP были заново синхронизованы (все ранее поступившие запросы должны быть продублированы). После отказа и до того как новое соединение будет восстановлено в полном объеме, ущерб в обслуживании может быть минимизирован, если PEP кэширует переданные ранее решения и продолжает их использовать в течение некоторого ограниченного времени. В разделах 2.3 и 2.5 детально рассмотрены механизмы COPS для обеспечения надежности.
2. Протокол
2.1. Общий заголовок
Далее рассматриваются форматы сообщений и объекты, которыми обмениваются PEP и удаленный PDP. Каждое сообщение COPS состоит из заголовка, за которым следует некоторое число типизованных объектов.
//// далее обозначает зарезервированное поле и должно содержать 0.
В заголовке имеются поля:
| Версия: 4 бита | Номер версии COPS. Текущее значение версии 1. |
| Флаги: 4 бита | Определенные значения флага (все другие флаги должны быть установлены в нулевое состояние): 0x1 Solicited Message Flag Bit. Этот флаг устанавливается, когда поступает запрос COPS. Этот флаг не должен устанавливаться (значение=0), если только не специфицировано обратное в разделе 3 |
/p> Ниже в таблице представлены значения поля код операции.
операции (8 бит)
Поле Тип клиента: 16 бит
Тип клиента идентифицирует клиента политики. Интерпретация всех инкапсулированных объектов Типы клиента, которые устанавливают старший бит в поле тип клиента, зависят от производителя (enterprise specific; это типы клиентов 0x8000 - 0xFFFF). Для сообщений KA тип клиента в заголовке должен быть установлен равным 0, так как KA используется для проверки связи.
Длина сообщения: 32 бит
Размер сообщения в октетах, который включает в себя стандартный заголовок COPS и все инкапсулированные объекты. Сообщения должны иметь длину кратную 4 октетам.
2.2. Форматы специфических объектов COPS
Все объекты имеют один и тот же формат; каждый объект состоит из одного или более 32-битных слов с 4-октетным заголовком. Формат показан на рисунке:
Длина характеризуется двухоктетной величиной, которая описывает число октетов (включая заголовок), которые образуют объект. Если длина в октетах не попадает на границу слова, кратную 32-бит, должно использоваться заполнение вплоть до конца объекта, так чтобы обеспечивать выравнивание, прежде чем объект будет послан. На принимающей стороне соответствующая граница объекта определяется округлением объявленной ранее длины объекта до значения кратного ближайшим 32-бит.
Обычно, C-Num идентифицирует класс информации в объекте, а C-тип идентифицирует субтип или версию информации, содержащейся в объекте.
C-num: 8 бит
| 1 | Дескриптор (Handle) |
| 2 | Контекст |
| 3 | Входной интерфейс |
| 4 | Выходной интерфейс |
| 5 | Код причины |
| 6 | Решение |
| 7 | LPDP решение |
| 8 | Ошибка |
| 9 | Специфические данные клиента |
| 10 | Таймер Keep-Alive |
| 11 | Идентификация PEP |
| 12 | Тип отчета |
| 13 | Адрес переадресации PDP |
| 14 | Последний PDP-адрес |
| 15 | Таймер аккоунтинга |
| 16 | Целостность сообщения |
/p> C-type: 8 бит. Значения, определенные для C-num.
2.2.1. Объект дескриптор (Handle)
Объект Handle (дескриптор) содержит уникальную величину, которая идентифицирует инсталлированное состояние. Эта идентификация используется большинством операций COPS. Состояние, соответствующее дескриптору, должно быть непосредственно удалено, когда оно более не применимо.
C-Num = 1
C-Type = 1, дескриптор клиента.
Поле дескриптора имеет переменную длину, дескриптор должен отличаться от других дескрипторов клиента того же самого PEP (соединение COPS TCP)для определенного типа клиента. Он всегда выбирается PEP в исходный момент и ликвидируется, когда он более не нужен. Дескриптор клиента используется, чтобы осуществить ссылку на состояние запроса инициализированного некоторым PEP и инсталлированным для типа клиента PDP. PEP специфицирует дескриптор клиента в своих сообщениях запроса (Request), отклика (Report) и ликвидации (Delete), посланных к PDP. Во всех случаях, дескриптор клиента служит для однозначной идентификации конкретного запроса PEP для данного типа клиента.
Значение дескриптора клиента устанавливается PEP и является непрозрачным для PDP. PDP просто выполняет побайтовое сравнение со значением этого объекта с учетом значений дескрипторов объектов других поступивших запросов.
2.2.2. Объект Context
Специфицирует тип события(ий), которое вызвало запрос. Этот объект необходим для сообщений-запросов. Запросы управления доступом, выделения ресурсов, и переадресации зависят от типов клиентов. Для допустимых типов клиента PEP может также послать запрос PDP с целью получения именованной конфигурационной информации. Эта именованная конфигурационная информация может иметь форму, полезную для установления системных атрибутов в PEP, или она может иметь форму правил политики, которые могут быть непосредственно проверены PEP.
В одном запросе может присутствовать несколько флагов. Это, однако, допустимо, только если набор специфической информации клиента в комбинированном запросе идентичен набору, который был бы специфицирован в случае посылки отдельного запроса для каждого из флагов.
C-num = 2, C-тип = 1
R-тип (флаг типа запроса)
M-Type ( Тип сообщения специфичные для клиента (Client Specific) 16-битовые значения типов протокольного сообщения.
2.2.3. Объект In-Interface (IN-Int)
Объект In-Interface используется для идентификации входного интерфейса, к которому относится запрос, и PEP, используется обратный адрес и ifindex.
Объект Interface используется также для идентификации принимающего интерфейса через его ifindex. Поле ifindex может быть использовано, чтобы отличать субинтерфейсы от ненумерованных интерфейсов (смотри, например RSVP LIH). Когда PEP поддерживает SNMP, целое число ifindex должно соответствовать тому же целому числу для интерфейса в индексной интерфейсной таблице MIB-II.
Поле ifindex специфицированное в In-Interface обычно имеет отношение к ниже лежащему потоку протокольных сообщений. Поле ifindex является интерфейсом, через который получаются протокольные сообщения.
C-Num = 3
C-Type = 1, IPv4-адрес + Интерфейс
Для этого типа объекта интерфейса, IPv4-адрес специфицирует адрес, откуда пришло сообщение.
C-Type = 2, IPv6-адрес + Интерфейс
Для данного типа объекта интерфейса, IPv6-адрес специфицируетIP-адрес, откуда пришло входное сообщение. Поле ifindex используется для спецификации местного интерфейса MIB-II PEP, как это описано выше.
2.2.4. Объект Out-Interface (OUT-Int)
Объект Out-Interface используется для идентификации выходного интерфейса, которому адресован запрос, и адреса, куда должен быть переправлено сообщение. Для потоков или сообщений, направляемых локальной ЭВМ PEP, используется обратный адрес и ifindex. Out-Interface >имеет те же форматы, что и объект In-Interface. Этот интерфейсный объект используется также для идентификации выходного интерфейса через его ifindex. Поле ifindex может быть использовано для отличия субинтерфейсов от ненумерованных интерфейсов (смотри, например, RSVP LIH). Когда PEP поддерживает SNMP, целое число ifindex должно соответствовать тому же целому числу для интерфейса в индексной интерфейсной таблице MIB-II.
Поле ifindex специфицированное в Out-Interface обычно связано с потоком протокольных сообщений. Поле ifindex определяет один из адресов, куда протокольное сообщение может быть переадресовано.
C-Num = 4
C-Type = 1, IPv4-адрес + интерфейс
Некоторые форматы C-типа выступают в качестве объекта In-Interface. IPv4-адрес специфицирует адрес, куда направлено исходящее сообщение. Поле ifindex используется для спецификации местного интерфейса MIB-II для PEP.
C-Type = 2, IPv6-адрес + интерфейс
Тот же формат C-типа, что и в случае объекта In-Interface. Для этого типа объекта интерфейса, адрес IPv6 специфицирует IP-адрес, которому адресовано исходящее сообщение. Поле ifindex используется для спецификации местного интерфейса MIB-II для PEP.
2.2.5. Объект Reason
Этот объект специфицирует причину, почему состояние запроса было стерто. Объект появляется в запросах стирания (DRQ). Поле субкода причины зарезервировано для более подробного описания причины, специфической для клиента и описанной в соответствующих документах.
C-Num = 5, C-тип = 1
Субкод (октет 2) содержит неизвестный C-Num объекта (октет 3) содержит неизвестный C-тип объекта
2.2.6. Объект Decision
Решение, принятое PDP. Присутствует в откликах. Специфические необязательные объекты решения необходимы в решениях для определенных запросов в зависимости от типа клиента.
C-Num = 6
C-тип = 1, флаги решения (обязательные)
Команды:
0 = Решение NULL (Конфигурационные данные недоступны)
1 = Инсталлировать (Admit request/Install configuration)
2 = Удалить (запрос/конфигурацию)
Флаги:
0x01 = Trigger Error ( сообщение об ошибке срабатывания, если установлена)
Trigger Error применима для типов клиентов, которые могут посылать уведомления об ошибках для сигнальных сообщений.
Значения поля флаги не применимые для данного контекста R-типа или типа клиента должны игнорироваться PEP.
C-тип = 2, Stateless Data
Этот тип объекта решения несет в себе дополнительную информацию (stateless), которая может быть использована PEP локально. Этот объект имеет переменную длину и его внутренний формат должен специфицироваться для данного типа клиента в соответствующем расширительном документе COPS. Этот объект для сообщений-решений является опционным и интерпретируется согласно текущему контексту.
Ожидается, что даже посторонние PEP могут принимать некоторые простые политические решения в рамках их LPDP
Так как этот набор хорошо известен и используется повсеместно, PDP обслуживает и его (обычным образом, через конфигурацию, или используя сообщение Client-Open). PDP может также включать эту информацию в свои решения, а PEP должен использовать ее в случае запросов выделения ресурсов.
C-тип = 3, Данные замещения
Этот тип объекта решения несет в себе информацию замещения, которая призвана заменить существующие данные в указанном сообщении. Этот объект имеет переменную длину и его внутренний формат должен быть специфицирован для данного типа клиента в соответствующем документе-расширении COPS. Он является опционным в сообщениях решениях и интерпретируется согласно текущему контексту.
C-тип = 4, Данные решения, специфические для клиента
Дополнительные типы решений могут быть введены с помощью информационного объекта специфического решения клиента (Client Specific Decision Data Object). Он имеет переменную длину и его внутренний формат должен быть специфицирован для данного типа клиента в соответствующем документе расширения COPS. Он является опционным в сообщениях-решениях и интерпретируется в соответствии с данным контекстом.
C-тип = 5, именованные данные решения
Информация об именованной конфигурации инкапсулируется в поле версии объекта решения, это делается в ответ на запрос конфигурации. Этот объект имеет переменную длину и его внутренний формат должен быть специфицирован в соответствующих документах расширения COPS для данного типа клиента. Для сообщений решения этот объект является опционным и интерпретируется в зависимости от контекста и флагов решения.
2.2.7. Объект LPDP-решение (LPDPDecision)
Решение принятое LPDP PEP (Local Policy Decision Point) может присутствовать в запросах. Эти объекты имеют формат, идентичный формату объектов специфических решений клиента, описанному выше.
C-Num = 7
C-тип = (тот же C-Type что и для объектов решения)
2.2.8. Объект Error
Этот объект используется для идентификации конкретных протокольных ошибок COPS. Поле субкода ошибки содержит дополнительную спецификацию ошибки, характерную для данного клиента. Субкоды ошибки для конкретного типа клиента должны специфицироваться в соответствующем документе расширения.
C-Num = 8, C-тип = 1
Субкод (октет 2) содержит C-Num и C-Type (октет 3) неизвестного объекта.
2.2.9. Объект специфической информации клиента (ClientSI)
Для запросов необходимы различные типы этого объекта, он используется в откликах и, когда необходимо, в процедурах open. Объект содержит специфическую информацию для клиента данного типа.
C-Num = 9,
C-Type = 1, Signaled ClientSI.
Поле переменной длины. Все объекты/атрибуты, специфичные для сигнального протокола клиента или внутреннего состояния, инкапсулируются в один или более информационных объектов, специфических для клиента. Формат данных, инкапсулированных в объект ClientSI, определяется типом клиента.
C-Type = 2, Именованный ClientSI.
Поле переменной длины. Содержит именованную конфигурационную информацию, полезную для передачи специфических данных о PEP, запросе, или сконфигурированном состоянии серверу PDP.
2.2.10. Объект Keep-Alive-таймер (KATimer)
Значение времени кодируются в виде 2-октетных целых чисел и измеряются в секундах. Время выдержки таймера рассматривается как приращение.
C-Num = 10,
C-Type = 1, значение таймера Keep-alive
Объект таймер используется для спецификации максимального временного интервала, в течение которого сообщение COPS должно быть послано или получено. Диапазон значений таймаутов лежит в пределах 1 - 65535 секунд. Значение нуль соответствует бесконечности.
2.2.11. Объект идентификации PEP (PEPID)
Объект идентификации PEP используется, для того чтобы идентифицировать PEP-клиента удаленному PDP. Это необходимо для сообщений Client-Open.
C-Num = 11, C-Type = 1
Поле переменной длины. Это ASCII-строка, завершающаяся нулем, которая дополняется нулями до границы, кратной 32 бит. Идентификатор PEPID должен содержать ASCII-строку, однозначно идентифицирующую PEP в пределах политической области PEP. Например, он может быть статически приписанным IP-адресом PEP или DNS-именем. Этот идентификатор может использоваться PDP в качестве дескриптора для идентификации PEP в его политических правилах.
2.2.12. Объект тип отчета (Report-Type)
Тип отчета, соответствующий запросу состояния для данного дескриптора:
C-Num = 12, C-Type = 1
Report-Type:
1 = Success : Решение было успешным для PEP
2 = Failure : Решение не могло быть реализовано PEP
3 = Accounting: Актуализация аккоунтинга для инсталлированного состояния.
2.2.13. Адрес пересылки PDP (PDPRedirAddr)
PDP при закрытии PEP- сессии для конкретного типа клиента может опционно использовать этот объект для того чтобы переадресовать PEP на специфицированный адрес сервера и заданный порт TCP:
C-Num = 13,
C-Type = 1, IPv4-адрес+ TCP порт
C-Type = 2, IPv6-адрес + TCP порт
2.2.14. Последний адрес PDP (LastPDPAddr)
Когда PEP имеет определенный тип клиента, он должен специфицировать последний PDP, который он успешно открыл (им получено сообщение Client-Accept) со времени, когда PEP последний раз перезагружался. Если со времени последней загрузки не использовалось никакого PDP, PEP просто не включит этот объект в сообщение Client-Open.
C-Num = 14,
C-Type = 1, IPv4-адрес (тот же формат, что и для PDPRedirAddr)
C-Type = 2, IPv6-адрес (имеет тот же формат, что и PDPRedirAddr)
2.2.15. Объект Accounting-таймер (AcctTimer)
Время кодируется в виде двухоктетых целых чисел и измеряется в секундах. Значение таймера рассматривается как временной интервал между двумя событиями.
C-Num = 15,
C-Type = 1, Значение таймера аккоунтинга
Значение опционного таймера используется для определения минимального интервала между периодическими отчетами о типах аккоунтинга. Оно используется PDP для того чтобы охарактеризовать PEP приемлемое значение интервала между не запрошенными аккоунтинг-актуализациями через сообщения-отчеты, когда это применимо. Он обеспечивает для PDP метод управления объемом аккоунтинг-трафика в сети. Диапазон конечных значений времени лежит в пределах 1 - 65535 секунд (два октета). Значение нуль означает, что не должно быть не запрошенных аккоунтинг-актуализаций.
2.2.16. Объект целостность сообщения (Message Integrity)
Объект целостности (integrity) включает в себя порядковый номер и дайджест сообщения, полезный для аутентификации и проверки целостности сообщения COPS. Когда используется этот объект, он размещается в самом конце сообщения COPS. Дайджест вычисляется для всего сообщения COPS за исключением самого дайджеста. Отправитель сообщения COPS вычисляет и заполняет дайджест-секцию объекта Integrity. Получатель сообщения вычисляет дайджест для этого сообщения и сравнивает его с тем, что хранится в объекте Integrity.
C-Num = 16,
C-Type = 1, HMAC дайджест
Объект HMAC- целостности для вычисления дайджеста сообщения привлекает HMAC (ключевое хэширование для аутентификации сообщения) [HMAC], при этом используется ключ, общий для PEP и PDP.
Объект Integrity специфицирует 32-битовый ID ключа, который определяет специфический ключ, используемый конкретным PEP и его PDP, а также используемый криптографический алгоритм. Для заданного PEPID ID ключа допускает существование одновременно нескольких ключей для PEP и оответствующих ключей PDP. Ключ, идентифицированный ID ключа, используется для вычисления дайджеста сообщения в объекте Integrity. Все программные реализации, как минимум должны поддерживать HMAC-MD5-96, который реализует алгоритм MD5 [MD5] вычисляющий дайджест сообщения длиной 96-бит.
Этот объект включает в себя также порядковый номер, который представляет собой 32-битовое целое число без знака, которое служит для предотвращения атак откликов. Порядковый номер инициируется на фазе обмена сообщениями Client-Open, Client-Accept и инкрементируется каждый раз при посылке очередного сообщения тому же получателю через существующее TCP-соединение. Если порядковый номер достигает значения 0xFFFFFFFF, следующим номер будет равен нулю и процесс продолжится.
Дайджест сообщения COPS вычисляется для области, начиная с заголовка, и вплоть до объекта Integrity (который должен быть последним объектом в сообщении COPS). В эту область попадают заголовок объекта Integrity, ID ключа и порядковый номер (Sequence Number). В случае HMAC-MD5-96, HMAC-MD5 выдает 128-битовый дайджест, который далее укорачивается до 96 бит.
2.3. Коммуникация
Протокол COPS использует одно устойчивое TCP соединение между PEP и удаленным PDP. Реализация PDP на сервере должна прослушивать стандартный номер TCP-порта (COPS=3288 [IANA]). PEP ответственен за инициативу TCP-соединения с PDP. Положение удаленного PDP может быть сконфигурировано или получено с помощью механизма локации услуг [SRVLOC].
Если один PEP может поддерживать несколько типов клиентов, он может посылать соответствующее число сообщений Client-Open, адресованных PDP, через одно или более TCP-соединений. Аналогично, PDP с заданным адресом и номером порта может поддерживать один или более типов клиента. Для заданного набора поддерживаемых типов клиентов PDP может в каждом конкретном случае независимо воспринять или отвергнуть любой тип клиента. Если тип клиента отвергнут, PDP может перенаправить PEP на альтернативный PDP-адрес и TCP-порт для данного типа клиента через COPS. Различные TCP-порты могут использоваться для перенаправления PEP на другие программные реализации PDP, работающие на том же сервере.
Один PEP может сформировать соединения с несколькими PDP. Это может происходить, когда физически различные PDP поддерживают разные типы клиентов (как это показано на рис.).
Рис. .2. Пример с несколькими PDP.
Когда TCP-соединение разорвано, PDP ожидает, что необработанное состояние запроса, соответствующее обмену запрос/решение, будет удалено. Когда PEP регистрирует потерю соединения из-за таймаута, он должен послать сообщение Client-Close каждому открытому типу клиенту, содержащему объект <Error>, который указывает на код ошибки "Communication Failure". Кроме того, PEP должен постоянно пытаться контактировать с первичным PDP или, если не удается, с любым известным запасным PDP. В частности PEP должен проверить все доступные PDP, с которыми он был сконфигурирован до того, как он сможет установить соединение. Если PEP соединен с запасным PDP, а первичный PDP становится доступным, запасной PDP является ответственным за переадресацию PEP на первичный PDP (через сообщение <Client-Close>, содержащее объект <PDPRedirAddr>, идентифицирующий первичный PDP для каждого из типов клиента). В разделе 2.5 рассмотрены детали синхронизации PEP и PDP.
2.4. Использование дескриптора клиента (Client Handle)
Дескриптор клиента служит для идентификации уникального состояния запроса для каждого из типов клиента для одного PEP. Дескрипторы клиента выбираются PEP и являются недоступными для PDP. PDP просто использует дескриптор запроса, чтобы однозначно идентифицировать состояние запроса для конкретного типа клиента, для конкретного TCP-соединения, и тем самым связать его решения с соответствующим запросом. Дескрипторы клиента инициализируются в сообщениях запроса и используются в последующих сообщениях запроса, решения и отчета для ссылки на то же состояние запроса. Когда PEP готов удалить состояние локального запроса, он посылает сообщение удаления (delete) PDP для соответствующего дескриптора клиента. Дескрипторы, относящиеся к различным состояниям запроса, должны быть уникальны в рамках контекста конкретного TCP-соединения и типа клиента.
2.5. Синхронизация
При отсоединении от PDP, PEP должен перейти к принятию локальных решений. При восстановлении соединения PEP информирует PDP обо всех событиях, которые произошли под локальным управлением. Кроме того, удаленный PDP может потребовать, чтобы внутренние состояния всех PEP были заново синхронизованы (все ранее поступившие запросы были заново посланы) путем передачи сообщения синхронизации состояний (Synchronize State).
После неудачи и до полного установления нового соединения, ухудшение сервиса может быть минимизировано, если PEP кэширует переданные ранее решения и продолжает использовать их в течение некоторого времени.
PEP, который кэширует состояние предыдущего обмена PDP, должен сообщить о факте разрыва соединения любому PDP, с которым он может восстановить соединение. Это выполняется путем включения адреса и номера TCP-порта последнего PDP, для которого PEP кэширует состояние в сообщении Client-Open. Объект <LastPDPAddr> будет включен для последнего PDP, с которым PEP был полностью синхронизован. Если прерывание обслуживания было временным и PDP все еще содержит полное состояние для PEP, PDP может выбрать вариант, когда не все состояния синхронизованы. PEP ответственен за актуализацию всех состояний PDP, которые изменились за время прерывания обслуживания. Если PEP выходит из строя и теряет все кэшированные состояния для некоторого типа клиента, он просто не включает <LastPDPAddr> в свое сообщение Client-Open.
3. Содержимое сообщения
Объект Integrity, если он включен, должен всегда быть последним объектом сообщения. Если необходимо обеспечить безопасность, а полученное сообщение не содержит корректного объекта Integrity, получатель должен послать сообщение Client-Close для Client-Type=0, определяющее соответствующий код ошибки.
3.1. Запрос (REQ) PEP -> PDP
PEP устанавливает дескриптор состояния запроса клиента, для которого PDP может обеспечить нужное состояние. Удаленный PDP затем использует дескриптор, для ссылки на информацию и решения, переданные по TCP-каналу конкретному PEP для данного типа клиента.
Раз для нового запроса определен дескриптор, любые последующие модификации запроса могут производиться с помощью сообщения REQ, специфицирующего инсталлированный дескриптор. PEP ответственен за уведомление PDP всякий раз, когда изменения его локального состояния отслеживает состояния PEP. Формат сообщения-запроса имеет вид:
<Request Message> ::= <Common Header>
<Client Handle>
<Context>
[<IN-Int>]
[<OUT-Int>]
[<ClientSI(s)>]
[<LPDPDecision(s)>]
[<Integrity>]
<ClientSI(s)> ::= <ClientSI> | <ClientSI(s)> <ClientSI>
<LPDPDecision(s)> ::= <LPDPDecision> | <LPDPDecision(s)> <LPDPDecision>
<LPDPDecision> ::= [<Context>]
<LPDPDecision: Flags>
[<LPDPDecision: Stateless Data>]
[<LPDPDecision: Replacement Data>]
[<LPDPDecision: ClientSI Data>]
[<LPDPDecision: Named Data>]
Объект context используется для определения контекста, в рамках которого следует интерпретировать все другие объекты. Он также служит для определения вида решения, которое должен послать сервер, определяющий политику. Это решение может относиться к управлению доступом, размещению ресурсов, переадресации или замене объектов, а также в конфигурации.
Объекты interface используются, чтобы определить соответствующий интерфейс, через который было получено или предполагается послать протокольное сообщение. Они обычно используются, если клиент запрашивает конфигурационные данные для какого-то конкретного интерфейса.
ClientSI является информационным объектом клиента и содержит в себе специфическую информацию, для которой должно быть принято политическое решение. В случае конфигурации именованное ClientSI может включать в себя именованные данные о модуле, интерфейсе или функции, которые следует конфигурировать. Порядок следования для кратных ClientSI не существенен.
Наконец, объект LPDPDecision содержит информацию согласно локальному решению, принятому LPDP.
Сообщения Request с неверным форматом должны вызывать сообщения Decision PDP с соответствующим кодом ошибки.
3.2. Решение (DEC) PDP -> PEP
PDP реагирует посредством REQ с сообщением DEC, которое включает в себя ассоциированный дескриптор клиента и один или более объектов решения, сгруппированные относительно пар типов объектов Context и флагов решения (Decision Flags). Если имела место протокольная ошибка, вместо этого присылается объект ошибки.
Требуется, чтобы первое сообщение решения для нового или актуализованного запроса имело флаг требования в заголовке COPS равный 1. Это исключает отслеживание того, какому модифицированному запросу соответствует конкретное решение (т.е., запрос посылается повторно для того же самого дескриптора). Важно, чтобы для данного дескриптора существовало одно предпочтительное решение, соответствующее определенному запросу. Это по существу означает, что PEP не должен посылать более одного REQ (для данного дескриптора), прежде чем он получит соответствующий DEC с заданным набором флагов сообщения. PDP должен всегда посылать решения для запросов в порядке их получения и каждому запросу должно соответствовать решение.
Чтобы избежать тупиков, PEP может делать выдержку после посылки запроса, пока не будет получено решение. Он должен аннулировать дескриптор, для которого время выдержки истекло, а решение не получено, новая попытка может быть осуществлена с новым дескриптором.
Формат сообщения Decision представлен ниже:
<Decision Message> ::= <Common Header>
<Client Handle>
<Decision(s)> | <Error>
[<Integrity>]
<Decision(s)> ::= <Decision> | <Decision(s)> <Decision>
<Decision> ::= <Context>
<Decision: Flags>
[<Decision: Stateless Data>]
[<Decision: Replacement Data>]
[<Decision: ClientSI Data>]
Сообщение Decision может включать либо объект Error, либо один или более объекта context и соответствующего объекта decision. О проблемах протокола COPS сообщается в объекте Error. Объект Decision зависит от контекста и типа клиента.
3.3. Состояние отчета (RPT) PEP -> PDP
Сообщение RPT используется PEP, чтобы сообщить PDP об успехе или неудаче реализации решения PDP, или уведомить об изменении состояния. Report-Type специфицирует вид отчета и опционный ClientSI и может содержать дополнительную информацию для типа клиента.
Для каждого сообщения DEC, содержащего контекст конфигурации, которое получено PEP, он должен сформировать соответствующее сообщение-отчет о состоянии с флагом запрошенного сообщения (Solicited Message flag), который указывает на то успешно или нет реализовано конфигурационное решение. RPT-сообщения, запрошенные решением для данного дескриптора клиента, должны устанавливать флаг запрошенного сообщения и должны быть посланы в том же порядке, к каком получены соответствующие сообщения решения. Не должно быть более одного сообщения отчета о состоянии, соответствующему флагу-требованию, установленному для заданного решения.
Состояние отчета может также использоваться для реализации периодических модификаций специфической информации клиента для целей мониторирования состояния, зависящего от типа клиента. В таких случаях тип аккоунтинг-отчета должен специфицироваться с помощью соответствующего информационного объекта клиента.
<Report State> ::== <Common Header>
<Client Handle>
<Report-Type>
[<ClientSI>]
[<Integrity>]
3.4. Состояние аннулирования запроса DRQ (Delete Request State) PEP -> PDP
При посылке это сообщение PEP указывает, что удаленный PDP, чье состояние идентифицируется дескриптором клиента, более недоступно или неверно. Эта информация будет затем использоваться удаленным PDP для инициации соответствующих служебных операций. Объект кода причины интерпретируется с учетом типа клиента и определяет причину аннулирования. Формат сообщения Delete Request State представлен ниже:
<Delete Request> ::= <Common Header>
<Client Handle>
<Reason>
[<Integrity>]
Важно, что когда состояние запроса окончательно удаляется из PEP, сообщение DRQ для состояния запроса посылается PDP, так что соответствующее состояние может быть также удалено в PDP. Состояния запроса, не удаленные явно PEP, будут поддерживаться PDP, пока не будет закрыта сессия или пока не будет разорвано соединение.
Сообщения Decision с неверным форматом должны запустить DRQ, специфицирующее соответствующий код ошибки (Bad Message Format) и любое ассоциированное состояние PEP должно быть либо удалено, либо повторно запрошено. Если Decision содержится в неизвестном объекте COPS Decision, PEP должен аннулировать его запрос, специфицирующий код причины объекта COPS Unknown, так как PEP будет неспособен работать с информацией, содержащейся в неизвестном объекте. В любом случае, после отправки DRQ, PEP может попытаться послать соответствующий запрос повторно.
3.5. Запрос состояния синхронизации (SSQ) PDP -> PEP
Сообщение запроса состояния синхронизации имеет следующий формат:
<Synchronize State> ::= <Common Header>
[<Client Handle>]
[<Integrity>]
Это сообщение указывает, что удаленный PDP хочет, чтобы клиент повторно прислал свое состояние. Если имеется опционный дескриптор клиента, только состояние, ассоциированное с этим дескриптором, синхронизуется. Если PEP не распознает запрошенный дескриптор, он должен немедленно послать сообщение DRQ PDP для дескриптора, специфицированного в SSQ-сообщении. Если в SSQ-сообщении не специфицировано никакого дескриптора, все активные состояния клиента должны быть синхронизованы с PDP.
Клиент выполняет синхронизацию состояний путем повторной посылки запросов специфицированного типа клиента для существующего состояния PEP. Когда синхронизация завершена, PEP должен направить завершающее сообщение синхронизованного состояния в PDP.
3.6. Client-Open (OPN) PEP -> PDP
Сообщение Client-Open может использоваться PEP, для того чтобы специфицировать PDP типы клиента, которые PEP может поддерживать, и последний PDP, с которым PEP устанавливал соединение при данном типе клиента. Сообщение Client-Open может быть послано PDP в любое время, допускаются множественные сообщения Client-Open для одного и того же типа клиента (в случае общих изменений состояния).
<Client-Open> ::= <Common Header>
<PEPID>
[<ClientSI>]
[<LastPDPAddr>]
[<Integrity>]
PEPID является символическим именем с переменной длиной, которое однозначно идентифицирует клиента для PDP (смотри раздел 2.2.11).
Именованный объект ClientSI может быть включен для передачи дополнительной глобальной информации о PEP к PDP, когда необходимо (как это специфицировано в соответствующем расширении документа для заданного типа клиента).
PEP может также предоставить объект Last PDP Address в его сообщении Client-Open, специфицирующий последний PDP (для заданного типа клиента), для которого он кэширует решения с момента последней перезагрузки (reboot). PDP может использовать эту информацию, чтобы определить подходящий режим синхронизации (смотри раздел 2.5).
Если PDP получает сообщение Client-Open с неверным форматом, он должен сформировать сообщение Client-Close, специфицирующее соответствующий код ошибки.
3.7. Client-Accept (CAT) PDP -> PEP
Сообщение Client-Accept используется для позитивного отклика на сообщение Client-Open. Это сообщение пришлет PEP объект таймера, заключающий в себе максимальный временной интервал между сообщениями keep-alive. Опционно, если нужно, может быть добавлен таймер, специфицирующий минимально допустимый интервал между аккоунтинг-сообщениями-отчетами.
<Client-Accept> ::= <Common Header>
<KA Timer>
[<ACCT Timer>]
[<Integrity>]
Если PDP отказывает клиенту, он пошлет сообщение Client-Close.
Таймер KA соответствует максимальному приемлемому времени между сообщениями, посылаемыми от PDP к PEP. Время выдержки таймера определяется PDP и измеряется в секундах. Значение времени выдержки 0 означает, что не требуется верификации вторичного соединения.
Опционный таймер ACCT позволяет PDP проинформировать PEP о том, что периодические аккоунтинг-отчеты не должны превышать специфицированный временной интервал для каждого дескриптора клиента. Это позволяет PDP контролировать частоту, с которой PEP посылает аккоунтинг-отчеты. Вообще, сообщения Report типа аккоунтинг посылаются PDP, когда определен соответствующий PEP. Аккоунтинг-таймер по большей части используется PDP, чтобы поддерживать частоту актуализаций на приемлемом уровне (т.e. предотвращать перегрузку PEP под действием аккоунтинг-отчетов от PDP). Не включение этого объекта в сообщение означает, что не существует для PDP каких-либо ограничений на частоту аккоунтинг-актуализации.
Если PEP получает сообщение Client-Accept с неверным форматом, он должен сгенерировать сообщение Client-Close, где специфицирован соответствующий код ошибки.
3.8. Client-Close (CC) PEP -> PDP, PDP -> PEP
Сообщение Client-Close может быть послано как PDP, так и PEP с тем, чтобы обратить внимание противоположной стороны на то, что указанный тип клиента более не поддерживается.
<Client-Close> ::= <Common Header>
<Error>
[<PDPRedirAddr>]
[<Integrity>]
Объект Error включен, чтобы описать причину закрытия (например, запрошенный тип клиента не поддерживается удаленным PDP или отказ в работе клиента).
PDP может опционно включать PDP-объект адреса перенаправления, для того чтобы проинформировать PEP об альтернативном PDP, который он должен использовать для типа клиента, специфицированного в общем заголовке.
3.9. Keep-Alive (KA) PEP -> PDP, PDP -> PEP
Сообщение keep-alive должно передаваться PEP в пределах периода, определенного минимальным значением выдержки KA-таймера, которая определяется в сообщениях CAT для данного соединения. Сообщение KA должно генерироваться случайным образом в пределах между 1/4 и 3/4 этого минимального интервала KA-таймера. Когда PDP получает сообщение keep-alive от PEP, он должен откликнуться таким же сообщением, адресованным PEP. Это сообщение обеспечивает подтверждение для каждой из сторон того, что соединение функционирует даже в случае, когда нет никаких других сообщений.
Тип клиента в заголовке должен всегда быть установлен равным 0, так как KA используется для верификации соединения (а не для верификации сессии клиента).
<Keep-Alive> ::= <Common Header>
[<Integrity>]
Как клиент, так и сервер могут предполагать, что TCP-соединение недостаточно для типа клиента с минимальным значением времени (специфицировано в сообщении CAT), если не зарегистрировано никакой телекоммуникационной активности в течение периода времени, превосходящего выдержку таймера. При этом PEP предполагает, что удаленный PDP или соединение не работает и PEP должен пытаться использовать альтернативный/запасной PDP.
3.10. Завершение состояния синхронизации (SSC) PEP -> PDP
Сообщение завершения состояния синхронизации ( Synchronize State Complete) посылается от PEP к PDP, после того как PDP пошлет запрос синхронизации состояния PEP и PEP завершит синхронизацию. Полезно, чтобы PDP знал, когда все старые состояния клиента успешно повторно запрошены и, таким образом, PEP и PDP полностью синхронизованы. Объект дескриптора клиента (Client Handle) следует включать только тогда, когда соответствующее сообщение синхронизации состояний (Synchronize State Message) непосредственно ссылается на определенный дескриптор (handle).
<Synchronize State Complete> ::= <Common Header>
[<Client Handle>]
[<Integrity>]
4. Общие операции
4.1. Согласование уровня безопасности и номера по порядку
Безопасность сообщения COPS согласуется один раз на соединение и работает для всего последующего обмена через это соединение. Если требуется определенный уровень безопасности COPS, он должен быть согласован во время начального обмена сообщениями Client-Open/Client-Accept, специфицирующего тип клиента равный нулю (который зарезервирован для согласования уровня соединения и верификации соединения).
Если PEP не конфигурировался для использования средств безопасности COPS, он просто пошлет PDP сообщения Client-Open для поддерживаемых типов клиента, как это задано в разделе 4.3 и не будет включать объект Integrity в какие-либо сообщения COPS.
В противном случае, средства безопасности могут быть инициализированы PEP, если он посылает PDP сообщение Client-Open с Client-Type=0 до открытия любого другого типа клиента (Client-Type). Если PDP получает Client-Open с Client-Type=0, после того как другой тип клиента уже успешно открыт, он должен прислать сообщение Client-Close (для Client-Type=0) к PEP. Это первое сообщение Client-Open должно специфицировать Client-Type=0 и должно предоставить объекты PEPID и COPS Integrity. Этот объект Integrity будет содержать начальный порядковый номер, который PDP должен инкрементировать в дальнейшем, после исходного обмена Client-Open/Client-Accept и Key ID, идентифицирующего алгоритм и ключ, которые используются для вычисления дайджеста.
Аналогично, если PDP принимает ключ безопасности PEP и алгоритм путем проверки дайджеста сообщения с использованием идентифицированного ключа, PDP должен послать PEP сообщение Client-Accept с Client-Type =0, содержащего объект Integrity. Этот объект Integrity будет включать исходный порядковый номер, идентификатор ключа (Key ID), задающий ключ и алгоритм, использованные для вычисления дайджеста.
Если PEP, от перспективного PDP, который требует безопасности, потерпит неудачу или вообще не выполнит согласование требований безопасности, не послав исходное сообщение Client-Open с Client-Type=0, содержащее корректный объект Integrity, PDP должен послать PEP сообщение Client-Close с Client-Type=0, специфицирующее соответствующий код ошибки. Аналогично, если PDP, в процессе диалога с PEP, который требует безопасности, не выполнил согласования параметров, не послав сообщение Client-Accept со значением Client-Type=0 и корректным объектом Integrity, PEP должен послать PDP сообщение Client-Close со значением Client-Type=0, специфицируя соответствующий код ошибки. Такое сообщение Client-Close не должно нести в себе объект integrity (так как согласование безопасности еще не завершено).
Инициализация безопасности может потерпеть неудачу по одной из следующих причин:
| 1. | Партнер, получающий сообщение требует обеспечения уровня безопасности COPS, но объект Integrity не прислан. |
| 2. | Объект Integrity COPS был прислан, но с неизвестным или неприемлемым C-Type (код ошибки Unknown COPS Object, специфицирующий неподдерживаемые C-Num и C-Type). |
| 3. | Дайджест сообщения или идентификатор ключа в присланном объекте Integrity был некорректен и, следовательно, сообщение не может быть аутентифицировано с помощью ключа (код ошибки - Authentication Failure). |
4.2. Работа с ключами
Процедура работы с ключами находится за пределами данного документа, но реализации COPS должны, по крайней мере, предоставить возможность ручной конфигурации ключей и задания их параметров. Ключ, используемый для формирования дайджеста сообщения с объектом Integrity, идентифицируется с помощью поля Key ID. Таким образом, параметр Key ID используется для идентификации одного из множества ключей, используемых совместно PEP и PDP. Key ID имеет отношение к определенному PEPID для PDP, или к определенному PDP для PEP. Для каждого ключа должны быть также определены параметры времени действия и параметры, задающие криптографический алгоритм. Как минимум, все реализации COPS должны поддерживать криптографический алгоритм HMAC-MD5-96 [HMAC][MD5] для вычисления дайджеста сообщения, который включается в объект Integrity (Keyed Message Digest), присоединяемый к сообщению.
Регулярное изменение ключей является хорошей практикой. Ключи должны быть конфигурируемы так, чтобы их время действия перекрывались, обеспечивая плавный переход с одного набора на другой. В середине периода действия ключа отправитель должен запустить процедуру перехода на следующий ключ. Тем временем, получатели просто воспринимают любой идентифицированный ключ, полученный в пределах его периода существования (lifetime) и отклоняют любые другие ключи.
4.3. Инициализация PEP
Спустя некоторое время после установления соединения между PEP и удаленным PDP, после согласования условий обеспечения безопасности (если это требуется), PEP пошлет удаленному PDP одно или более сообщение Client-Open, по одному для каждого поддерживаемого PEP типов клиента. Сообщение Client-Open должно содержать адрес последнего PDP, с которым PEP хранит полный набор решений. Если не поступило ни одного решения от предыдущего PDP, объект LastPDPAddr не должен быть включен в сообщение Client-Open (смотри раздел 2.5). Каждое сообщение Client-Open должно, по крайней мере, содержать общий заголовок, указывающий на один тип клиента, который поддерживает PEP. Удаленный PDP откликнется сообщениями Client-Accept для каждого типа клиента, запрошенного PEP и поддерживаемого PDP.
Если какой- то конкретный тип клиента не поддерживается PDP, PDP будет реагировать с помощью Client-Close, специфицируя неподдерживаемый тип клиента, и возможно предлагая альтернативный PDP-адрес и номер порта. В противном случае, PDP пошлет Client-Accept, специфицируя временную выдержку между сообщениями keep-alive, а PEP может начать посылку запросов PDP.
4.4. Нестандартные операции
Когда PEP сталкивается с ситуацией, которая требует нового политического решения, он посылает удаленному PDP сообщение-запрос. То, что квалифицируется как случай определенного типа клиента, должно быть специфицировано в соответствующем документе, посвященном этому client-type. Удаленный PDP принимает решение и посылает сообщение-решение PEP. Так как запрос определяет состояние, запрос будет запомнен или инсталлирован на удаленном PDP. Уникальный дескриптор (уникальный для TCP-соединения и типа клиента), специфицированный в запросе и соответствующем ему решении идентифицирует состояние запроса. PEP отвечает за удаление этого состояния запроса, если запрос уже более не применим.
PEP может актуализовать ранее инсталлированное состояние запроса путем повторной посылки запроса для соответствующего дескриптора. Удаленный PDP примет новые решения и пошлет сообщения-решения к PEP. Аналогично, сервер может изменить принятое ранее решение на любое инсталлированное состояние запроса в любое время путем посылки не запрошенного сообщения-решения. В любое время модуль PEP ожидает решения PDP и уведомляет PDP о любых изменениях.
4.5. Операции конфигурирования
В конфигурационном сценарии PEP выполнит запрос PDP для определенного интерфейса, модуля, или функциональности, которые могут быть специфицированы в информационном объекте именованного клиента. PDP пошлет потенциально несколько решений, содержащих именованные блоки конфигурационных данных PEP. Предполагается, что PEP инсталлирует и использует конфигурацию локально. Конкретная именованная конфигурация может быть актуализована путем отправки дополнительных сообщений-решений для данной конфигурации. Когда PDP более не хочет, чтобы PEP использовал часть конфигурационной информации, он пошлет сообщение-решение, специфицирующее именованную конфигурацию и объект флагов решения (decision flags) с командой удаления конфигурации. PEP должен удалить соответствующую конфигурацию и послать сообщение-отчет PDP, об этом удалении.
В любом случае, PEP может уведомить удаленный PDP о локальном статусе инсталлированного состояния, используя сообщение-отклик. Это сообщение, если нужно, может содержать специфическую информацию клиента.
4.6. Операции Keep-Alive
Сообщение Keep-Alive используется для проверки соединения между клиентом и сервером, чтобы проверить функциональность соединения даже в отсутствие обмена сообщениями между PEP и PDP. PEP должен формировать COPS KA-сообщение случайным образом в диапазоне от одной четвертой до 3/4 минимальной величины выдержки KA таймера, заданной PDP в сообщении Client-Accept. При получении сообщения Keep-Alive от PEP, PDP должен реагировать на это сообщение Keep-Alive посылкой отклика Keep-Alive к PEP. Если любая из сторон не получит сообщение Keep-Alive или любого другого сообщения COPS за время выдержки KA-таймера, соединение должно считаться разорванным.
4.7. Закрытие PEP/PDP
Наконец, сообщения Client-Close используются для аннулирования влияния соответствующих сообщений Client-Open, оповещающих партнера о том, что специфицированный тип клиента не поддерживается или не является активным. Когда PEP регистрирует потерю связи, связанную с таймаутом keep-alive он должен послать сообщение Client-Close для каждого открытого типа клиента, специфицирующего код ошибки разрыва соединения. Затем PEP может разорвать соединение с PDP, попытаться восстановить связь или использовать альтернативный PDP. Когда PDP завершает работу, он должен послать сообщения Client-Close всем PEP для всех типов клиента, при этом может специфицироваться альтернативный PDP, который может заменить прежний.
5. Соображения безопасности
Протокол COPS предоставляет объект Integrity, который может обеспечить аутентификацию, целостность сообщения, и предотвратить подмену с использованием записи предыдущих сообщений. Все реализации COPS должны поддерживать работу с объектом COPS Integrity. Чтобы гарантировать, что клиент (PEP) обменивается с корректным сервером политики (PDP), необходима аутентификация PEP и PDP, с использованием общего ключа (secret), и согласованная проверка того, что соединение является корректным. Ключ используется в сочетании с содержимым сообщения COPS, чтобы вычислить дайджест сообщения, который является частью объекта Integrity. Объект Integrity затем используется для проверки всех сообщений COPS, посланных через TCP-соединение между PEP и PDP.
Объект COPS Integrity предоставляет также порядковый номер, чтобы исключить атаки откликов. PDP выбирает начальный порядковый номер для PEP, а PEP выбирает начальный порядковый номер для PDP. Эти начальные номера затем инкрементируются каждым последующим сообщением, пересланным через данное соединение в соответствующем направлении. Исходный порядковый номер должен быть выбран так, чтобы для заданного ключа в процессе монотонного приращения не получалось идентичных номеров.
Безопасность обмена между клиентом (PEP) и сервером (PDP) может быть обеспечена за счет IP Security [IPSEC]. В этом случае, заголовок аутентификации IPSEC (AH) должен использоваться для проверки правильности соединения; кроме того, безопасное поле данных IPSEC ESP (Encapsulation Security Payload) может использоваться для реализации, как безопасности, так и конфиденциальности.
TLS [Transport Layer Security] может использоваться, как для обеспечения соединения, так и для гарантии конфиденциальности.
Тип клиента идентифицирует Client-type приложения, к которому относится сообщение. Значения типа клиента в диапазоне 0x0001-0x3FFF зарезервированы для статуса необходимой спецификации (Specification Required), как это определено [IANA-CONSIDERATIONS]. Эти значения должны быть зарегистрированы IANA и их поведение и применимость должны быть описана в документе расширения COPS.
Значения типа клиента (Client-type) в диапазоне 0x4000 - 0x7FFF зарезервированы для частного использования, как это определено в [IANA-CONSIDERATIONS].
Значения типа клиента в диапазоне 0x8000 - 0xFFFF относятся к типу “первым пришел – первым обслужен”, как это определено в [IANA-CONSIDERATIONS].
6. Ссылки
| [RSVP] | Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) Version 1 - Functional Specification", RFC-2205, September 1997. |
| [WRK] | Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-Based Admission Control", RFC-2753, January 2000. |
| [SRVLOC] | Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC-2608, June 1999. |
| [IPSEC] | Atkinson, R., "Security Architecture for the Internet Protocol", RFC-2401, August 1995. |
| [HMAC] | Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC-2104, February 1997. |
| [MD5] | Rivest, R., "The MD5 Message-Digest Algorithm", RFC-1321, April 1992. |
| [RSVPPR] | Braden, R. and L. Zhang, "Resource ReSerVation Protocol (RSVP) - Version 1 Message Processing Rules", RFC-2209, September 1997. |
| [TLS] | Dierks T. and C. Allen, "The TLS Protocol Version 1.0", RFC-2246, January 1999. |
| [IANA] | http://www.isi.edu/in-notes/iana/assignments/port-numbers |
| [IANA-CONSIDERATIONS] | Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC-2434, October 1998 |
