Интегрированные сети ISDN
Общие операции
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). |
Следующее сообщение, которое посылает PEP в направлении PDP, будет иметь порядковый номер 12 и т.д. Если любое последующее сообщение содержит неверный порядковый номер, неопределенный Key ID, некорректный дайджест сообщения, или не имеет объекта Integrity при условии, что параметры безопасности согласованы, то для Client-Type=0 должно быть сгенерировано сообщение Client-Close, содержащее корректный объект Integrity, где специфицируется соответствующий код ошибки. После этого соединение должно быть разорвано.
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, который может заменить прежний.
