sgnuni5

5. Обмен сообщениями в пределах Сигнализации UNI 4.0

Этот раздел описывает поддержку сигнализации для протоколов обмена сообщениями защиты в соединениях типа точка-точка и точка-много точек.

5.1. Соединения типа точка-точка

 

Рисунок 2. Поддержка Сигнализации при Соединениях типа точка-точка для Двухстороннего Обмена Сообщениями Защиты (SME).

Рисунок 2 показывает сигнализационную поддержку для двухстороннего протокола обмена сообщениями защиты в соединениях типа точка-точка. (Примечание: поддержка сигнализации для трехстороннего протокола обмена сообщениями защиты в этих Технических требованиях не обсуждается.)

При интерфейсе UNI, поток FLOW1-2WE переносится в УСТАНОВОЧНОМ (SETUP-сообщение) сообщении, а поток FLOW2-2WE идет в сообщении ПОДКЛЮЧЕНИЯ (CONNECT-сообщение).

В PNNI и B-ICI интерфейсах , поток FLOW1-2WE переносится в сетевом эквиваленте UNI SETUP-СООБЩЕНИЯ, а поток FLOW2-2WE идет соответственно в сетевом эквиваленте UNI CONNECT-СООБЩЕНИЯ.

з Назад

 

5.2. Соединения типа точка-много точек

Процедуры сигнализации для установления соединения радиально-узловой многоточечной связи

(соединения типа точка-много точек) описаны в спецификации АТМ Форум UNI 4.0 [3] сигнализация и ITU Q.2971 [22].

 

Рисунок 3. Сигнализационная Поддержка при соединениях типа точка-много точек для Двустороннего Обмена сообщениями Безопасности (SME) и последующей Установки Листьев (краевых узлов сети).

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

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

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

При интерфейсе UNI на звонящей стороне, FLOW1-2WE переносится в ADD PARTY-сообщении, а FLOW2-2WE соответственно идет в ADD PARTY ACK-сообщении (ACK = УВЕДОМЛЕНИЕ ОБ УСПЕШНОМ ПОЛУЧЕНИИ).

При интерфейсе UNI на вызываемой стороне, FLOW1-2WE переносится в SETUP-СООБЩЕНИИ, а FLOW2-2WE идет в CONNECT-СООБЩЕНИИ.

В PNNI и B-ICI интерфейсах , FLOW1-2WE переносится в сетевом эквиваленте UNI ADD PARTY-сообщения, а FLOW2-2WE идет соответственно в сетевом эквиваленте UNI CONNECT-СООБЩЕНИЯ.

з Назад

 

5.3. Инициализированная Листом Возможность Связи

Процедуры сигнализации для инициализированной листом возможности связи описаны в Разделе 6.0 Сигнализация UNI 4.0 Форума ATM .

Имеются два режима работы, связанные с инициализированной листом возможности связи: корень запрошенная связь и лист запрошенная связь без корневого уведомления. Первое SETUP-СООБЩЕНИЕ исходящее от корня укажет, является ли данный режим режимом корнем запрошенной связи или же режимом лист запрошенной связи без уведомления корня.

5.3.1. Корень Запрошенная Связь

В этом режиме работы, корень соединения обрабатывает запрос LIJ (Leaf Initiated Join Capability = Инициализированная Листом Возможность Связи). Корень прибавляет(подключает) листья или удаляет(отключает) их из нового или установленного соединения, используя процедуры соединения типа точка-много точек. Этот тип соединения упомянут как LIJ-корень соединение.

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

5.3.2. Лист Запрошенная Связь Без Уведомления Корня

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

Корень не уведомлен, когда лист добавлен к нему или удален (отключен). Этот тип подключения упомянут как LIJ-сеть соединение.

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

з Назад 

 

5.4. Процедуры Агента Безопасности для Основанного на сигнализации Обмена сообщениями

5.4.1. Общие Процедуры

Обратитесь к Разделу 1.3, где дается определение понятия "Агент Безопасности" ("Security Agent"="SA").

SAsme должен установить индикатор [5] Pass Along в один, так те узлы PNNI, что не реализуют SA по пути ВИРТУАЛЬНОГО КАНАЛА, пропустят SSIE к следующему узлу. Индикатор Действия Элемента Информации (IE Action Indicator) в Поле Команды Элемента Информации (IE Instruction Field) из SSIE будет установлен в 001 " Элемент Информации Брака и Продолжения работы ". Рекомендуется, чтобы Агенты Безопасности были способны к обработке отчета состояния, сгенерированного по значению 010 " Элемент Информации Брака, Продолжения работы и Отчета о состоянии. " Потеря SSIE будет отмечена в CONNECT-СООБЩЕНИИ так, чтобы могли быть вызваны соответствующие действия политики безопасности.

Секции Защищенного Соединения (SAS'ы) в пределах SSIE обрабатываются как "атомарные" объекты, и так они обрабатываются все до последнего, причем последовательно.

Агенты Безопасности, при изменении информационных элементов в сигнальном сообщении, должны соответствовать процедурам, которые управляют форматом и поведением объектных информационных элементов. В частности, тогда должны примениться соответствующие процедуры, описанные в UNI 4.0 [3], Q.2931 [21], и Q.2971 [22].

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

Следующие процедуры описывают действия, принятые агентами безопасности для получения сообщения, содержащего SSIE. Агенты Безопасности Версии 1 игнорируют SSIE'ы, встречающиеся в любом другом сообщении.

з Назад

 

5.4.2. Инициализизация Процедур Агента Безопасности

5.4.2.1. Запрос Вызова / Соединения

По получении SETUP-СООБЩЕНИЯ с помощью инициирующего агента безопасности ATM, все SSIE Секции Защищенного Соединения (SAS'ы), которые присутствуют в сигнальном сообщении, анализируются и самый большой Relative ID, Security Association ID отмечается. Если не имеется существующих SSIE SAS'ов, то самый большой Relative ID - нулевой по определению.

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

1. Номер версии для всех Служб безопасности Версии 1.0 Форума ATM нулевой.

2. Транспортный метод выбран и обозначен в поле Transport Indicator, используя рекомендации, точно установленные в Разделе 5.1.3.2.4 этого документа.

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

4. Если SAS предназначен только для одного агента безопасности, то бит Брака (Discard бит) установлен в 1. Обычно, службы управления доступом, основанные на метке, могут быть предназначены для больше чем одного целевого агента безопасности, тогда для этих служб бит Брака, может быть установлен в нуль.

5. Если агент безопасности намеревается использовать явный Целевой Идентификатор Агента Безопасности, чтобы опознавать предназначенный целевой агент безопасности (агент безопасности адресата), то устанавливается Явный (Explicit) бит Возможностей, и опционально Целевой Идентификатор Объекта Безопасности (Target Security Entity Identifier) включается в заголовок SAS.

Если Целевой Идентификатор Объекта Безопасности не используется, то выбирается соответствующее описание Возможностей (Scope ), чтобы опознавать Область (Region) и Назначение (Role) предназначенного целевого агента безопасности. Подробности относительно использования этого поля определены в Разделе 5.1.3.2.7.

6. Агент безопасности распределяет новое значение Security Association ID для служб безопасности SAS, как описано в Разделе 5.1.3.2.8. Security Association ID отмечен и используется, чтобы опознавать соответствующий SSIE SAS в ожидаемом CONNECT-СООБЩЕНИИ.

7. Каждой Секции Защищенного Соединения (SAS) дают Номер SAS (SAS Number), который определяет порядок старшинства для обработки SAS'ов в пределах того же самого Защищенного соединения. SAS'ы будут обработаны в порядке убывания номеров. Порядок обработки SAS'ов с одинаковыми SAS Номерами неопределен.

Если SSIE уже не существует в SETUP-СООБЩЕНИИ, заголовок SSIE - добавляется (?prepended) к SAS'ам, которые должны быть добавлены к сообщению. Новые SAS'ы тогда будут добавлены, соответственно, к сигнальному сообщению. Если любая ошибка происходит в обработке, агент безопасности должен возвратить условие отказа " Протокол Безопасности, обрабатывающий Ошибку " (см. Раздел 5.1.6), с соответствующей диагностикой для условия, которое генерировало

Ошибку. В этом случае, сообщение возвращается объекту сигнализации.

5.4.2.2. Запрос / Прием соединения

По получении CONNECT-СООБЩЕНИЯ инициирующим агентом безопасности ATM, все SSIE Секции Защищенного Соединения (SAS), которые присутствуют в сигнальном сообщении, анализируются и те SAS'ы, которые имеют Relative ID ИДЕНТИФИКАТОРЫ Защищенного соединения (Security Association ID), которые соответствуют поддерживаемым этим агентом безопасности будут обработаны. Если не имеется никаких существующих SSIE SAS'ов , которые соответствуют любым ожидаемым Relative ID ИДЕНТИФИКАТОРАМ Защищенного соединения (Security Association ID), то ошибка произошла, и агент безопасности возвратит условие отказа: " Отсутствие Заданного Информационного Элемента Безопасности " (см. Раздел 5.1.6). Если только частичный набор Relative ID ИДЕНТИФИКАТОРОВ Защищенного соединения (Security Association ID) присутствует в CONNECT-СООБЩЕНИИ, то инициирующий SA должен определить, является ли запрос ошибкой. Это решение основано на полученных SAS'ах и политике безопасности инициирующего SA.

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

Инициирующий агент безопасности обрабатывает все соответствующие SAS'ы, в убывающем порядке, основанном на Relative ID. Если ошибка происходит в течение обработки, агент безопасности возвратит условие отказа " Протокол Безопасности, обрабатывающий Отказ. "

Для каждой SAS, инициирующий агент безопасности обрабатывает содержание SAS до ее конца. Если обработка завершается успешно, то инициирующий агент безопасности может исполнять дополнительную обработку, в зависимости от значения поля Transport Indicator. Если Transport Indicator (Индикатор Переноса) - Основанная на сигнализации передача сообщений, то никакая дополнительная обработка не выполняется. Если Transport Indicator (Индикатор Переноса) - Внутриполосная Передача сообщений, то инициирующий агент безопасности исполняет Внутриполосный Обмен сообщениями Безопасности как выделено в Разделе 5.1.5. Если ошибка происходит в течение расширенной обработки SME, агент безопасности возвратит условие отказа: " Протокол Безопасности, обрабатывающий Отказ. " После успешного завершения расширенного SME, инициирующий агент безопасности обрабатывает следующую соответствующую SAS. В этом случае, сообщение возвращается объекту сигнализации.

з Назад

 

5.4.3. Ответ Процедурам Агента Безопасности

5.4.3.1. Запрос / Запрос соединения

По получении SETUP-СООБЩЕНИЯ отвечающим агентом безопасности (т.е. адресатом), если SSIE присутствует, все SSIE Секции Защищенного Соединения (SAS), которые присутствуют в сигнальном сообщении, анализируются и SAS'ы, которые предназначены для этого агента безопасности, собираются. Агент безопасности выбирает все соответствующие SSIE SAS'ы основываясь или на явно точно установленном Target Security Entity Identifier (Целевом [Адресном] Идентификаторе Объекта Безопасности) или основываясь на Region (Области) и битах Role (Роли) поля SAS Scope, используя процедуры, описанные в Разделе 5.1.3.2.7. Из этого набора SAS'ов, которые имеют Security Service Identifier (Идентификатор Службы безопасности), соответствующий службе безопасности, которая может обеспечиваться этим агентом безопасности, запоминаются. Все другие SAS'ы отвергаются без их модифицирования. Если SETUP-СООБЩЕНИЕ не содержит заданный SSIE или заданную SAS, агент безопасности, основываясь на политике, или возвращаясь к внутриполосному обмену сообщениями, чтобы установить службу безопасности или снимать запрос с условием отказа " Отсутствие Заданного Информационного Элемента " (см. Раздел 5.1.6).

Отвечаующий агент безопасности обрабатывает все соответствиющии SAS'ы, в порядке убывания, основанном на Relative ID SAS'ов. Если ошибка происходит в течение обработки, агент безопасности возвратит условие отказа " Протокол Безопасности, обрабатывающий Отказ".

Для каждого нового Security Association ID-номера, с которым сталкиваются в наборе соответствующих SAS'ов, формируется новое защищенное соединениеи и ассоциирутся с (ссылающимся на него) Security Association ID-номером. Все SAS'ы с тем же самым Security Association ID обрабатываются в пределах того же самого контекста защищенного соединения, и причем они обрабатываются в порядке убывания, основанном на SAS-номере. SAS'ы с идентичными восьмибитными Security Association ID номерами обрабатываются в неопределенном порядке.

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

Поддерживаются любые последовательные потоки или запросы к обработанным SAS'ам, ожидающим достижения соответствующего CONNECT-СООБЩЕНИЯ для этого ВИРТУАЛЬНОГО КАНАЛА.

Если бит Брака в поле Scope установлен (1), агент безопасности удаляет SAS из SSIE и корректирует длину SSIE. Если никаких других SAS'ов не остается, то SSIE удаляется из сигнального сообщения. Если Бит Брака нулевой (0), SAS запоминается и не модифицируется в сигнальном сообщении. В этом случае сообщение возвращается объекту сигнализации.

5.4.3.2. Запрос / Прием соединения

По получении CONNECT-СООБЩЕНИЯ отвечающим агентом безопасности, все SSIE Секции Защищенного Соединения (SAS), которые присутствуют в сигнальном сообщении, анализируются и самый большой Relative ID Security Association ID отмечается. Если не имеется никаких существующих SSIE SAS'ов, то самый большой Relative ID нулевой. Агент безопасности определяет, что Relative ID любого ожидающего решения второго (2 nd) потока или запросы SAS'ов - не меньше чем самый большой наблюдаемый Relative ID в текущем сообщении. Если только это выполнено, агент безопасности формирует одну или большее количество SAS'ов (с Flow Indicatorom'ом, установленным в 1, чтобы указать FLOW2 сообщение), и записывает или конкатенирует ожидаемые SAS'ы к SSIE. Если любые ошибки обработки происходят, агент безопасности возвратит соответствующую аварийную ситуацию, и объект сигнализации снимит запрос с условием отказа: " Протокол Безопасности, обрабатывающий Отказ " (см. Раздел 5.1.6). В этом случае, сообщение возвращается объекту сигнализации.

з Назад 

 

5.5. Запрос Оконечной точки о Службах безопасности

Оконечная точка или узел (host), который не обеспечивает службы безопасности, может (как опция) запросить службы безопасности из закачиваемого потока агента безопасности следующим образом:

1. Вставить Элемент Информации Служб безопасности в SETUP-СООБЩЕНИЕ на канале сигнализации.

2. Установить поле Security message exchange Protocol Type (октет 5.9) к "неопределенному" кодпоинту (" 0 0 ").

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

- Объявление Службы безопасности,

- Алгоритм конфиденциальности Данных,

- Алгоритм целостности Данных,

- Алгоритм Хэш-функции,

- Алгоритм Сигнатуры,

- Алгоритм Обмена ключами,

- Алгоритм модификации Сеансового ключа,

- Алгоритм Управления доступом.

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

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

з Назад 

 

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

Агент безопасности должен подтвердить запрос безопасности, полученный от оконечной точки следующим образом:

1. Вставить Элемент Информации Служб безопасности в CONNECT-СООБЩЕНИЕ на канале сигнализации.

2. Установить протокол обмена сообщениями безопасности к неопределенному кодпоинту ("00").

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

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


з Назад Вверхй Дальшеи