есть, применение IPSEC для аутентификации и/или шифрования транспортируемой информации управления и сигнализации. В этом случае IPSEC следует применять к каждому потоку UDP, тогда как при передаче сообщений SCTP через IP требуется применение IPSEC к SCTP как к типу протокола.

4.12.5.5. Информационная безопасность при разрешении адресов

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

4.12.5.6. Информационная безопасность при перспективных расширениях

Собственно механизм прохождения порции достоверной информации не требует добавления каких-либо аспектов информационной безопасности, кроме тех, которые связаны с протоколом SCTP базовых уровней. Однако, каждое новое расширение может иметь результатом появление новых требований к безопасности; для каждого расширения должны быть выработаны новые аспекты безопасности.

Добавление/удаление (ADD/DELETE) адреса IP существующему соединению обеспечивает дополнительный механизм, посредством которого существующие соединения могут подвергаться попыткам перехвата. Если посягнувший на информацию имеет возможность перехвата переданных и принятых пакетов, использование этого свойства может упростить перехват информации. Такая угроза должна учитываться при развертывании использующей данное свойство версии SCTP. Должен применяться заголовок аутентификации IP (IP Authentication Header), когда среда передачи, которая может подвергнуться перехвату, требует усиления защиты целостности, но не требует конфиденциальности.

Список литературы к главе 4

1. Bradner, S., The Internet Standards Process - Revision 3 , RFC 2026.

2. Clark, D.D., Names, addresses, ports and routes , RFC 0814.

3. Gulbrandsen, Vixie and Esibov, A DNS RR for specifying the location of services (DNS SRV) RFC 2782.

4. Heinanen, J., Baker, F., Weiss, W. and Wroclawski, J., Assured Forwarding PHB Group , RFC2597.

5. Hinden, R. and Deering, S., Internet Protocol, Version 6 (IPv6) Specification , RFC 2460.

6. Hinden, R. and Deering, S., IP Version 6 Addressing Architecture , RFC 2373.

7. Huitema, C, Routing in the Internet , Prentice-Hall, 1995.

8. ISDN Q.921-User Adaptation Layer, RFC 3057.

9. ITU-T Recommendation Q.1400, Architecture framework for the development of signaling and OA&M protocols using OSI concepts .

10. ITU-T Recommendations Q.761 to Q.767, Signalling System No.7 (SS7) - ISDN User Part (ISUP).

11. Jacobson, V., Nichols, K. and Poduri, K., An Expedited Forwarding PHB , RFC2598.

12. Kent, S., and Atkinson, R., Security Architecture for the Internet Protocol , RFC 2401.

13. Mankin, A. Ed., Baker, F., Braden, В., Bradner, S., ODell, M., Romanow, A., Weinrib, A. and Zhang, L., Resource ReSerVationProtocol (RSVP) - Version 1 Applicability Statement Some Guidelines on Deployment , RFC 2208.

14. Mathis, M., Mahdavi, J., Floyd, S., Romanow, A., TCP Selective Acknowledgement Options , RFC2018.

15. McCann, J., Deering, S., and Mogul, J., Path MTU Discovery for IP version 6 , RFC 1981.

16. Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., Lin, H., Juhasz, I., Holdrege, M., Sharp, C, Framework Architecture for Signaling Transport , RFC 2719.

17. R. R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. J. Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and, V. Paxson, Stream Control Transmission Protocol, RFC 2960.

18. Savage, S., Cardwell, N., Wetherall, D., and Anderson, Т., TCP Congestion Control with a Misbehaving Receiver , ACM Computer Communication Review, 29(5), October 1999. http: www.cs.washington.edu/homes/savage/papers/CCR99.pdf.

19. Security Considerations for SIGTRAN Protocols, Draft IETF <draft-ietf-sigtran-security-OO.txt>.

20. Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation Layer (M2UA), RFC 3331.

21. Signaling System 7 (SS7) Message Transfer Part 3 (МТРЗ) - User Adaptation Layer (M3UA), RFC 3332.

22. Signalling Connection Control Part User Adaptation Layer (SUA), Draft IETF <draft-ietf-sigtran-sua-14.txt>.

23. Stevens, W., TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms , RFC2001.

ПРИНЦИПЫ ПОСТРОЕНИЯ ПРОТОКОЛА OSP

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

Общий случай архитектуры взаимодействия доменов показан следующим рисунком на примере трех административных доменов, предоставляющих услуги 1Р-телефонии.

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

ствами, когда административные домены IT имеют какие-либо соглашения относительно обмена информацией о шлюзах. На рисунке LS ITAD1 соединен с LS ITAD2, который, в свою очередь, соединяется с LS ITAD3. При посредстве протокола TRIP LS ITAD2 имеет сведения о двух шлюзах, находящихся в ITAD1. К этой информации при посредстве протокола front-end могут получить доступ оконечные пользователи (EU) ITAD2. Протокол front-end представляет собой не TRIP, а механизм доступа к базам данных LS. В состав ITAD3 входят как EU, так и шлюзы. LS ITAD3 получает сведения о шлюзах ITAD1 посредством приема агрегатированной информации от LS ITAD2.

ITAD3

Рис. 78. Общий случай архитектуры взаимодействия доменов

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

Административный домен IT может не являться автономной системой (AS). В то время, как AS представляет собой совокупность физически связанных сетей, Административный домен IT может состоять

из элементов полностью различных сетей и даже различных автономных систем.

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

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

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

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

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

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

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

Сервер местонахождения имеет доступ к базе данных о шлюзах, называемой информационной базой шлюзов (Gateway Information Base - GIB). Такая база данных составляется комбинированием информации о локально доступных и удаленных шлюзах в соответствии с проводимой политикой. LS также поставляет сведения о шлюзах другим LS, находящимся в других ITAD.

Информация GIB доступна разнообразным объектам в пределах данного ITAD. Способ организации доступа к такой информации называется front end и представляет собой видимые средства эксплуатации услуг протокола маршрутизации вызовов.

К числу протоколов front-end можно отнести:

Протокол определения местонахождения услуги (Service Location Protocol - SLP). Разработан специально для выполнения функций такого типа и идеален для определения местонахождения серверов, описываемых набором атрибутов. В данном случае сервером является шлюз (или следующее по направлению к шлюзу устройство), а атрибутами является политика оконечного пользователя. Оконечный пользователь будет представлять UA SLP, a LS - DA SLP. Для запроса шлюза с конкретным набором атрибутов используется процедура запроса услуги (Service Query).

Протокол открытого урегулирования (Open Settlements Protocol - OSP). Является протоколом типа клиент - сервер . Позволяет клиенту запросить сервер по телефонному номеру и получить ответ с адресом следующего устройства на маршруте при авторизации маркеров эстафетной передачи (token), используемых для вызова. В этом случае сервер может быть сервером местонахождения. Для ответа на запросы OSP он использует таблицу маршрутизации, построенную с помощью TRIP.

Протокол упрощенного доступа к директориям (Lightweight Directory Access Protocol - LDAP). Используется для доступа к распределенным базам данных. Так как сервер LS имеет базу данных, для запроса может применяться LDAP.

Web-страница. На LS должна обеспечиваться поддержка front end типа web. Пользователи могут вводить запрос в определенной форме,

получая ответ с информацией о соответствующем шлюзе. Механизм более удобен для использования при запросе доступа человеком. Сервер сигнализации вряд ли будет использовать доступ к front end посредством web page.

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

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

Ниже в качестве средства реализации front end рассматривается протокол OSP.

Имеется несколько объектов, которые для доступа к GIB могут использовать front end. Ниже приведен их перечень, не являющийся исчерпывающим.

Серверы сигнализации. Серверами сигнализации принимаются сигнальные сообщения, например, сообщения Н.323 или SIP, задачей которых является инициирование вызовов IP-телефонии. Адресом пункта назначения этих вызовов может быть телефонный номер, соответствующий терминалу ТфОП. Для маршрутизации таких вызовов к соответствующему шлюзу серверу сигнализации необходим доступ к базе данных, организованной на LS.

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

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

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

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

Hypertext Transfer Protocol (HTTP)

Secure Sockets Layer (SSL) / Transport Layer Security (TLS)

Transmission Control Protocol (TCP)

Internet Protocol (P)

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

Дальнейшее развитие структуры протоколов с участием OSP представлено на рис. 80.

OSP XML HTTP TCP

Рис. 80. Архитектурная концепция применения протокола OSP

Формат сообщений OSP предполагает, что содержимое сообщений протокола HTTP соответствует стандарту Multipurpose Internet Mail Extensions (MIME). Этот стандарт определяет механизм комбинирования индивидуальных компонентов произвольного формата (например,

текст, графика, звук, двоичные данные) в пределах одного сообщения. Изначально разработанный для приложений электронной почты, стандарт в настоящее время адаптирован к различным приложениям, включая web browsing. Конкретные компоненты сообщения являются документами, удовлетворяющими требованиям спецификаций Extensible Markup Language (XML) и цифровой подписи Secure MIME (S/MIME) формата application/pkcs7-signature. Формат MIME поддерживается существующими системами firewall и proxy server. Для цифровой подписи спецификациями протокола OSP определены методы ее создания и канонизации, а также алгоритмистика и кодировка.

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

Client

Server Client

Server

Capabilitieslndication

CapabilitiesConfirmation

Capabilities Exchange

Pricinglndication

PricingConfirmation Pricing Exchange

Client Server

SubscriberAuthentication Request

SubscriberAuthentication Response

Subscriber Authentication

Client Server

Author isationRequest

Author isationResponse

Authorisation Exchange

Client Server

Authorisationlndi ation

AuthorisationConfirmation

Authorisation Validation

Client Server

ReauthorisatfonRequesf

ReauthorisationResponse

Client Server

Usagelndication

UsageConfirmation

Reauthorization Exchange Usage Reporting

Рис. 81. Примеры пар компонентов