 |
|
|
|
Всё, что вы хотели знать о протоколе SIP
Всё, что вы хотели знать о протоколе SIP Мир IP, возможно, и родственен классической телефонии, однако стоящие перед ним проблемы носят особый характер. Сервер трансляции сетевых адресов (NAT) создаёт серьёзные препятствия нормальной работе с VoIP. Как решается проблема NAT в сетях IP-телефонии на базе протокола SIP? Как бороться с угрозами безопасности в таких сетях? Ответы на эти вопросы вы узнаете из заключительной части статьи. Проблема обхода NAT Вряд ли стоит долго объяснять, почему NAT является проблемой для голосового трафика. Достаточно уже того факта, что голосовой трафик обособлен от сигнализации и использует динамически назначенные номера портов. А IP-адреса и номера портов, помещаемые находящимся за NAT-пользовательским агентом в поля заголовков Contact и Via, а также в SDP-сообщение, не маршрутизируемы. Маршрутизатор с поддержкой NAT-транспортного уровня модели OSI, а SIP-заголовки формируются на уровне приложения. Следовательно такое устройство не может проанализировать заголовки и SDP-сообщение и переопределить анонсированные там IP-адреса и номера портов (а также открыть обратный канал для маршрутизации входящего трафика к пользовательскому агенту), равно как и не может знать, к какому SIP-диалогу относится тот или иной медиапоток. Как результат, каждый не понаслышке знакомый с IP-телефонией человек сталкивался с явлениями односторонней слышимости или вовсе отсутствия звукового потока. Сразу следует заметить, что «серебряной пули» здесь нет: все решения этой проблемы в большей или меньшей степени частные. Впрочем, проблема обхода NAT медиатрафиком – это лишь одна сторона медали. Вначале мы рассмотрим, какие препятствия создаёт NAT для сигнальных сообщений и какие расширения SIP были разработаны для их преодоления. Обход NAT SIP-сигнализацией При использовании протоколов транспортного уровня без гарантии доставки отправка ответа на SIP-запрос производится на тот IP-адрес, с которого запрос был получен. Этот IP-адрес транспортный уровень протокола SIP заносит в параметр received заголовка Via перед передачей сообщения вышележащим уровням. Номер же порта для отправки извлекается из заголовка Via. В случае применения NAT – это порт, на котором ожидает ответа находящийся за NAT пользовательский агент, а не тот порт, через который происходит NAT-трансляция и на котором NAT ожидает поступления ответа; следовательно, ответ не может достичь адресата. Решение этой проблемы было предложено в RFC 3581 [1] и заключается в отправке ответа на порт, с которого запрос был получен, вместо порта, взятого из заголовка Via. При этом сам порт заносится в специальный параметр rport-заголовка Via. Таким образом, прокси-сервер отсылает ответное сообщение на порт и IP-адрес, с которых пришёл запрос. Это позволяет ответу найти соответствие в таблице трансляции NAT и достичь целевого узла. Этот метод называется симметричной маршрутизацией ответов. Вторая проблема заключается в необходимости корректной маршрутизации входящих SIP-запросов. SIP не обеспечивает механизма, который бы позволял отправлять новые запросы по тому соединению транспортного уровня, которое было образовано при регистрации пользователя. Записи в таблице трансляции NAT имеют ограниченное время жизни (чтобы таблица не переполнялась в том числе) и, чтобы входящие SIP-запросы могли достичь UA за NAT, записи в таблице трансляции NAT надо периодически обновлять. Это касается как протоколов без установления соединения, так и протоколов с установлением соединения. На рис. 1 запрос REGISTER был отправлен клиентом с порта 8023 и получен прокси-сервером на порту 5060, создав при этом запись в таблице трансляции NAT и (в случае использования транспортного протокола с установлением соединения) соединение транспортного уровня. При необходимости отправки запроса данному UA, прокси-сервер отправляет сформированный запрос на IP-адрес и порт, взятые из заголовка Contact при регистрации. Этот же IP-адрес не маршрутизируем; следовательно, для корректной маршрутизации входящих запросов сервер регистрации должен сохранить в базе данных с информацией о местоположении пользователей IP-адрес и номер порта, с которых запрос был на самом деле получен, в качестве контакта пользователя.
Рисунок 1. Маршрутизация входящих запросов Но запись в таблице трансляции NAT удаляется после истечения определенного промежутка времени (чаще всего – несколько минут). Проблема актуальна не только в период после регистрации пользователя: во время SIP-диалогов новые сообщения также могут не поступать в течение длительного промежутка времени, чего достаточно для того, чтобы запись из таблицы трансляции была удалена. Имеющиеся SIP-стеки решают эту проблему путём периодической посылки SIP-запросов re-INVITE, OPTIONS, INFO, NOTIFY или (при использовании UDP) дейтаграмм, не содержащих полезной нагрузки. Более полная и совершенная техника описана в проекте Managing Client Initiated Connections in SIP Инженерной проблемной группы Интернет (IETF) [2]. Остановимся на ней подробнее. При регистрации пользователя регистратор сохраняет данные о транспортном соединении, через которое был получен запрос. Два специальных параметра instance-id и reg-id заголовка Contact позволяют найти в базе данных сервера регистрации данные о соединении и направить входящий запрос к UA по тому соединению транспортного уровня, через которое был получен запрос регистрации. Также в черновике описаны механизмы для постоянного обновления записей таблицы трансляции NAT. Подытожим сказанное небольшим примером регистрации пользователя, находящегося за NAT и использующего UDP (см. рис. 2).
Рисунок 2. Обход NAT SIP-сигнализацией Запрос REGISTER содержит параметр заголовка Via rport, информирующий UAS о поддержке RFC 3581, а также параметры reg-id и +sip.instance в заголовке Contact:
Ответ прокси-сервера выглядит так:
Параметры reg-id и +sip.instance делают возможным повторное использование соединения транспортного уровня, по которому был получен REGISTER, в соответствии с [2]. Заметьте, что IP-адрес и порт, с которых был получен запрос, прокси-сервер заносит в параметры received и rport заголовка Via. На них же и производится отправка ответа в соответствии с RFC 3261 и RFC 3581. Причём ответ должен быть отправлен прокси-сервером с того же IP-адреса и порта, на котором был получен запрос, чтобы ответ был опознан NAT-транслятором, как принадлежащий к установленному соединению. Обход NAT медиатрафиком Решение проблемы обхода NAT медиатрафиком требует более сложных изменений, поскольку необходимо заменить IP-адрес и номер порта, анонсированные в SDP-сообщении, таковыми, что обеспечат доставку потоков нужному адресату за NAT (см. рис. 3).
Рисунок 3. Обход NAT медиатрафиком Simple Traversal of UDP through NAT (STUN) Терминология NAT и сведения о разных типах NAT были изложены в [3]. Там же был рассмотрен протокол STUN (Simple Traversal of UDP through NAT, RFC 3489 [4]), позволяющий определить факт наличия NAT и его тип путем отправки на STUN-сервер последовательности зондирующих запросов. В контексте SIP нас интересует возможность определения пользовательским агентом публичного IP-адреса NAT и записей в таблице трансляции с помощью STUN. Но вначале напомню специфику разных типов NAT.
Алгоритм работы STUN следующий. Клиент STUN (встроенный в UA) отправляет на расположенный снаружи NAT STUN-сервер зондирующие сообщения. STUN-сервер анализирует это сообщение и информирует клиента о том, какие IP-адрес и порт были использованы NAT (cм. рис. 4). Эти IP-адрес и порт клиент и помещает в SDP-часть SIP-запроса (а также поля заголовков Via и Contact). Путём отправки специальной последовательности запросов клиент может точно определить тип NAT.
Рисунок 4. STUN Наконец, мы подошли к главному. STUN не решает проблему обхода NAT в SIP в общем случае. Да, он работает в сценариях Port Restricted Cone NAT, а иногда – и в Restricted Cone NAT, но наиболее распространенным типом NAT был и остается симметричный, и здесь STUN бесполезен. К тому же не все UA даже в случае более дружественных типов NAT хорошо «дружат» с STUN, а в более старых устройствах поддержка STUN не была широко распространена. Ещё одна «ложка дёгтя» – в существующих реализациях STUN не работает с SIP поверх TCP, поскольку не отслеживает должным образом состояние открытых TCP-сессий. Traversal Using Relay NAT (TURN) Дальнейшим развитием STUN является протокол TURN (Traversal Using Relay NAT). TURN позволяет клиенту получить маршрутизируемый IP-адрес для общения с одним внешним узлом (и не пригодный для чего либо еще). TURN-сервер, обычно располагаемый DMZ абонентской сети или в сети сервис-провайдера, имитирует поведение Restricted Cone NAT: он транслирует пакеты с внешнего IP-адреса к клиенту только в том случае, если клиент ранее уже отправлял пакеты на внешний узел через TURN-сервер. Таким образом, TURN-сервер служит транзитным узлом (прокси-сервером) для всего последующего сигнального и медиатрафика (см. рис. 5). При этом он приемлемо работает даже с клиентами за симметричным NAT. Для выделения IP-адреса и отправки пакетов в спецификации протокола определены специальные запросы Allocate и Send; в остальном же структура протокола аналогична STUN. В качестве транспортных протоколов для сигнального и медиатрафика TURN поддерживает TCP и UDP.
Рисунок 5. Обход NAT SIP-сигнализацией Недостаток данного метода очевиден: вследствие проксирования всего трафика увеличивается односторонняя задержка и повышается вероятность потери пакетов. По этой причине TURN рекомендуется использовать лишь в тех случаях, когда менее «дорогие» методы обхода NAT бессильны. Заметим, что с недавнего времени TURN больше не считается самостоятельным протоколом: сейчас он описан как расширение к STUN в [5]. Interactive Connectivity Establishment (ICE) TURN-сервер проксирует весь RTP-трафик даже тогда, когда простого STUN было бы достаточно для обхода NAT. С целью выбора наименее «дорогого» метода обхода NAT путем проведения согласования возможных опций между конечными точками ассоциация IETF предложила инфраструктуру ICE (Interactive Connectivity Establishment). Это не протокол в привычном смысле этого слова; ICE называют инфраструктурой (framework), и базируется он на существующих протоколах STUN и TURN и расширениях SIP. Механизм работы ICE следующий. Пользовательские агенты производят поиск возможных маршрутов между собой. Каждый UA для начала диалога может использовать либо IP-адрес одного из локальных сетевых интерфейса, либо определённый с помощью STUN (или UPnP, Universal Plug and Play) маршрутизируемый IP-адрес, либо же IP-адрес TURN-сервера. Список маршрутов-кандидатов образуют пары – все возможные комбинации транспортных адресов одного пользовательского агента с транспортными адресами другого. В списке маршрутов-кандидатов наивысший приоритет получают маршруты без задействования STUN, более низкий – маршруты с задействованием STUN, и наиболее низкий – маршруты с проксированием медиатрафика через TURN-сервер. Изложение здесь намеренно усложнено: на самом деле гибкая система приоритетов позволяет учитывать топологию сети, данные о задержке и вариации задержки, требования к безопасности и т. д. В итоге каждый маршрут получает уникальное значение приоритета. Затем проверяется их работоспособность (достижимость противоположной стороны). Из маршрутов, прошедших проверку, выбирается один с наивысшим приоритетом. Если в роли транспортного протокола выступают RTP/RTCP, для которых назначаются порты со смежными номерами, с целью оптимизации выполняется согласование маршрутов только для одного порта. К слову, если в результате использования STUN или TURN, назначение для RTCP-порта с номером на единицу большим, чем у порта, выделенного для RTP-трафика, невозможно, специальный атрибут rtcp в SDP-части (RFC 3605) может содержать произвольный номер порта и IP-адрес, на котором UA готов принимать RTCP-сообщения. Словом, спецификация ICE выглядит весьма многообещающе, и это решение находит поддержку VoIP-индустрии. Описание ICE дано в [6]. Проксирование медиатрафика Один пример с проксированием как SIP-сигнализации, так и медиатрафика, мы уже видели – это TURN. Рассмотрим, каким образом можно реализовать проксирование одного лишь медиатрафика при помощи RTP-прокси-сервера и B2BUA («Back-to-back user agent» – SIP-узел, состоящий из двух SIP UA, которые общаются между собой строго на прикладном уровне). Критерием для определения факта присутствия NAT чаще всего служит наличие немаршрутизируемого IP-адреса в поле заголовка Contact. Далее, нам известно, что для того, чтобы RTP-трафик достиг UA за NAT, в качестве адреса и порта назначения следует использовать IP-адрес NAT-устройства и порт, анонсированный в определении медиапотока в SDP части. Следовательно, когда факт присутствия NAT установлен, B2BUA «запоминает» IP-адрес, с которого был получен запрос, и сообщает пару «IP-адрес : номер порта» устройству RTP-прокси, чтобы тот использовал эти данные для отправки трафика инициатору вызова в дальнейшем. RTP-прокси создаёт новый сеанс, выделяет новую пару IP-адрес: порт для медиа-потока и сообщает её B2BUA. Тот подставляет полученные (маршрутизируемый) IP-адрес и порт в SDP-сообщение перед пересылкой запроса адресату. Аналогичные манипуляции выполняются c SDP-сообщением адресата. В результате весь медиатрафик протекает через RTP-прокси. Для функционирования этого механизма принципиально важным является свойство симметричности пользовательского агента: использование для передачи и приёма одного и того же порта (UA должен отправлять медиа-поток с того порта, который он анонсировал в SDP). Но такой подход идеален в смысле точности данных: не требуется ничего, кроме собственно пакета, и поскольку пакет приходит на тот порт, с которого будет посылаться встречный поток – решаются проблемы со всеми видами NAT. В таком прокси-сервере можно реализовать любую дополнительную функциональность, связанную с модификацией SDP-части. В то же время это вносит дополнительную задержку в сеанс, повышает нагрузку на прокси-сервер и расходы сервис-провайдера. Расширения Cisco COMEDIA Если быть кратким, эти расширения [7] позволяют маршрутизатору обновить IP-адрес и порт источника, сохранённые для RTP-потока на этапе установления сессии, IP-адресом и портом, с которых был получен первый (прошедший через NAT) RTP-пакет. Ведь пользовательский агент, находящийся за любым видом NAT, может успешно слать RTP-пакеты другому агенту с маршрутизируемым IP-адресом, а тот, в свою очередь, может достичь инициатора этого трафика по IP-адресу и номеру порта, с которых был получен первый RTP-пакет (при условии, что первый пользовательский агент симметричен). Такой подход напоминает симметричную маршрутизацию ответов, описанную в RFC 3581 [1], но для медиатрафика. Рассмотрим, как это работает в случае обоюдной поддержки COMEDIA сторонами. Пусть в INVITE было получено SDP-описание следующего содержания:
Наличие атрибута direction говорит о поддержке COMEDIA. Ответный SDP от UAS имеет такой вид:
UAS обязан дождаться первого пакета от UAC, прежде чем начать отправлять медиапакеты. Затем UAS должен слать RTP-трафик на IP-адрес и порт, с которых пришёл первый медиапакет, вместо анонсированных в первом SDP-предложении 10.1.2.23:49172. При реализации COMEDIA Cisco руководствовалась сильно устаревшим на сегодняшний день проектом IETF [8] четвёртой версии. После десятой версии данного документа он был принят как RFC 4145 – TCP-Based Media Transport in SDP и касается теперь лишь передачи медиатрафика поверх TCP. На моей памяти множество случаев, когда применение COMEDIA вызывало потерю аудио при сопровождаемом переводе или разветвлении вызова: фактически маршрутизатор продолжал посылать медиапоток на пару IP-адресов: порт, полученную в первом SDP-предложении, упорно игнорируя все последующие. Причём решить проблему помогало именно отключение (!) поддержки COMEDIA. Посему применять COMEDIA в вышеназванных сценариях следует с долей осторожности. Другие технологии Нередко в качестве решения предлагается применять шлюзы уровня приложений (Application Layer Gateway, ALG), обрабатывающие как заголовки пакета IP, так и его информационное наполнение. Функции ALG могут выполнять пограничные контроллеры соединений (Session Border Controller, SBC) или маршрутизаторы, транслирующие управляющие сообщения SIP. К сожалению, обработка каждого пакета требует высокой производительности и повышает стоимость решения. К тому же новые модификации протокола требуют, чтобы ПО SIP ALG постоянно обновлялось, а его производитель следил за всеми изменениями, реализуемыми поставщиками устройств SIP. «Нечестный» SIP ALG может повлиять на нормальное функционирование находящихся за ним устройств. Технология UPnP (Universal Plug and Play) чаще применяется в сегменте SOHO и малых инсталляциях. Впрочем, она не является специфичной для VoIP и к тому же и так неплохо освещена в Сети. Напоследок, ценным сводным документом по описанным здесь решениям проблемы NAT является [9]. Безопасность SIP Члены рабочей группы IETF SIP Working Group разработали исчерпывающий набор базисных элементов защиты, предотвращающих прослушивание, перехват сессий и активные атаки SIP-систем, а также позволяющих убедиться в подлинности собеседника. Оставшаяся часть статьи посвящена рассмотрению этих элементов. Аутентификация Аутентификация в SIP принимает две формы. Первая – это аутентификация прокси-сервером, сервером переадресации или сервером регистрации пользовательского агента. Вторая – это аутентификация одним пользовательским агентом другого. Аутентификация пользовательского агента прокси-сервером нужна для проверки законности доступа к определённой услуге или функции. К примеру, прокси-сервер может потребовать аутентификацию перед пересылкой полученного INVITE адресату или предоставлением любой другой услуги. Сервер регистрации может потребовать аутентификацию для предотвращения регистрации не легитимного клиента и перехвата им входящих вызовов. Взаимная аутентификация пользовательских агентов имеет смысл для проверки того, что каждый из них на самом деле тот, за кого он себя выдаёт, ведь заголовок From (содержимое которого отображается пользовательскими агентами в качестве номера и имени вызывающего абонента) может быть сфальсифицирован. В SIP предусмотрено две схемы аутентификации: дайджест-аутентификация в стиле HTTP (RFC 2617 [10]), и аутентификация с использованием сертификатов (для SIP поверх TLS). Дайджест-аутентификация При использовании дайджест-аутентификации в стиле HTTP прокси-сервер отвечает на INVITE ответом 407 Proxy Authorization Required, в котором присутствует поле заголовка Proxy-Authenticate, с данными для вычисления отклика аутентификации. После отправки сообщения ACK на 407 Proxy Authorization Required пользовательский агент может переслать INVITE, но на этот раз – с заголовком Proxy-Authorization, содержащим удостоверение пользователя (см. рис. 6).
Рисунок 6. Дайджест-аутентификация Рассмотрим выполнение дайджест-аутентификации на примере. На рис. 6 показано содержимое начального INVITE, ответа 407 Proxy Authorization Required и INVITE с удостоверением пользователя. Нужно отметить, что пользовательские агенты, серверы регистрации и переадресации вместо 407 Proxy Authorization Required используют ответ 401 Unauthorized, а заголовок с данными для вычисления отклика аутентификации в нём называется просто Authenticate. В ответ на него UA должен прислать INVITE с заголовком Authorization. Дайджест сообщения – это уникальная символьная строка фиксированного размера, она является результатом обработки данных (зашифрованных имени пользователя и пароля) с помощью односторонней хэш-функции MD5. Сервер SIP сравнивает данные заголовка Authorization с результатом применения той же хэш-функции к данным, хранящимся в базе. Заголовок Authentication-Info позволяет пользовательскому агенту аутентифицировать прокси-сервер, используя тот же механизм дайджест-аутентификации. К сожалению, схема дайджест-аутентификации не обеспечивает аутентификацию тела сообщения и механизм проверки целостности сообщения – для этого следует использовать TLS или S/MIME. Возможно, в будущем дайджест-аутентификацию в SIP заменит более безопасный стандарт EAP-AKA (RFC 4178 [11]) базирующийся на протоколе EAP (Extensible Authentication Protocol, RFC 3478) и AKA (Authentication and Key Agreement, наработка мобильных сетей третьего поколения UMTS и CDMA2000). Transport Layer Security (TLS) Как и в случае с HTTP, передача SIP-данных может осуществляться с помощью протокола защищённого канала Transport Layer Security (TLS). SIP over TLS обеспечивает конфиденциальность и целостность информации в канале, осуществляет аутентификацию прокси-серверов с использованием сертификатов (которыми, согласно RFC 3261, должны обладать прокси-серверы, серверы регистрации и серверы переадресации). В рамках модели SIP over TLS безопасность достигается на каждом участке по пути следования сигнальных сообщений (см. рис. 7).
Рисунок 7. TLS На пути от пользовательского агента до прокси-сервера применяется TLS, а сигнализация между серверами может быть защищена с помощью TLS или IPSec (который считается опциональным, но более стойким). После успешной аутентификации прокси-серверы SIP дешифруют каждое сообщение (на каждом участке пути применяется отдельный ключ), что даёт им возможность «видеть» все заголовки и корректно выполнять маршрутизацию сообщений. Однако конечные абоненты должны безоговорочно «доверять» прокси-серверам. Среди слабых мест протокола TLS традиционно упоминают подверженность атакам «человек посередине» (Man-in-the-Middle). Есть и специфические для SIP проблемы: хотя TLS-соединение служит свидетельством аутентичности обеих сторон, этого мало для того, чтобы быть уверенным в аутентичности (или обеспечить невозможность отречения) от произвольного SIP-сообщения, передаваемого по этому каналу. TLS способен обеспечить эти цели в рамках протокола HTTPS, где появление иконки с изображением замка в браузере автоматически означает наличие безопасного канала между браузером и веб-сервером. SIP же гораздо более сложен. Представьте, например, TLS-соединение между двумя прокси-серверами: через него может передаваться трафик, принадлежащий разным транзакциям или диалогам. Следовательно, злоумышленник из одного домена может провести атаку с инжекцией трафика в другой домен, и это не будет обнаружено или предотвращено TLS-соединением. Корень проблемы в том, что конечные точки TLS-соединения не «знакомы» со структурой передаваемых через них сообщений протокола SIP настолько, чтобы применить достаточно жёсткую политику безопасности. Наконец, формирование доверительных отношений в рамках TLS и даже установка TCP-соединений может стать настоящей проблемой для сервис-провайдера, обслуживающего уже несколько сотен тысяч абонентских устройств. Не нужно обладать богатой фантазией, чтобы представить, на что будет похож поток SYN-пакетов во время формирования TLS-соединений. Интересующиеся перспективными разработками могут обратиться к RFC 4347 [12], описывающему протокол DTLS, работающий поверх UDP. А текущая версия протокола TLS описана в RFC 4346 [13]. Secure MIME (S/MIME) Давайте посмотрим, что может стать известным злоумышленнику, перехватившему SIP-сообщения, относящиеся к этапу установки сессии:
Сквозное (в отличие от протокола TLS, действующего от узла к узлу) обеспечение целостности, конфиденциальности и аутентификации SIP-сообщений возможно при помощи технологии S/MIME (RFC 3851 [14]). Замечу, что в предыдущих редакциях SIP RFC в качестве метода обеспечения аутентификации и секретности предлагался PGP, но сейчас его использование признано устаревшим. 23-я глава RFC 3261 описывает применение схемы S/MIME. Рассмотрим, как она интегрируется в модель использования SIP. Сертификат S/MIME удостоверяет то, что его обладатель идентифицируется в сети SIP определённым списочным адресом. Эти сертификаты также ассоциируются с ключами шифрования. Тело сообщения подписывается личным ключом и шифруется открытым ключом предполагаемого получателя сообщения. Открытый ключ может быть вложен в само сообщение. Предполагается, что отправитель сообщения уже установил подлинность открытого ключа получателя. Сами же открытые ключи хранятся в UA на некой связке ключей в виде пар «списочный адрес – ключ». Как и любой другой, основанный на инфраструктуре открытых ключей протокол, S/MIME полагается на надёжную схему распределения ключей, а значит, каждый пользователь должен иметь сертификат подлинности, а также безопасный способ его передачи собеседнику. Рассмотрим пример сообщения с телом S/MIME (см. рис. 8).
Рисунок 8. S/MIME На рис. 8 показана методика защиты тела SIP-сообщения с помощью S/MIME. Для защиты SIP-заголовков сообщение может быть помещено в MIME-тело с типом «message/sip», и инкапсулировано в новое SIP-сообщение с дублированными из оригинального сообщения заголовками с маршрутной информацией. В свою очередь, к сообщению-контейнеру может применяться S/MIME-подпись. Наконец, может выполняться и шифрование SIP-заголовков: в таком случае в сообщение-контейнер инкапсулируется шифрованный объект S/MIME. Такие сообщения не воспринимаются как новый диалог или транзакция, но пользуются всеми преимуществами сквозного шифрования и аутентификации. Заголовки Request-URI, Via, Record-Route, Route, Max-Forwards, и Proxy-Authorization не должны учитываться при подсчёте контрольных сумм, поскольку они могут (или должны) изменяться при прохождении через промежуточные прокси-серверы. Расширения SIP для обеспечения приватности имени и номера абонента Набор расширений RFC 3323 [15] и RFC 3325 [16] обеспечивает поддержку функций приватности абонента: сокрытия и верификации сетью отображаемого имени и номера участвующего в диалоге абонента (сеть удостоверяет личность вызывающего абонента, тот ли он, за кого он себя выдаёт). Поддержка приватности в сети SIP является сложной задачей уже потому, что протокол имеет текстовую природу, и участники диалога могут обмениваться сообщениями без привлечения какого-либо сервис-провайдера. В то же время от SIP UA требуется как минимум функции скрытия отображаемого имени и номера абонента, ставшие привычными в ТфОП. Наиболее прямолинейный подход – предоставление ограниченной информации в заголовке From – может вызвать проблемы при терминации звонка в сеть другого оператора или ТфОП или сделать невозможным предоставление ряда услуг. В RFC 3325 описывает функции обеспечения приватности личных данных абонента с сохранением возможности его идентификации. Такой механизм идентификации работает в рамках одного домена. Для его реализации были представлены новые заголовки P-Preferred-Identity и P-Asserted-Identity. Заголовок P-Preferred-Identity используется UA в транзакциях с доверенным прокси-сервером. Клиент конструирует запрос INVITE, не содержащий данных о личности абонента в поле From, но с реальным SIP URI и (опционально) отображаемым именем в поле P-Preferred-Identity. Также добавляется заголовок Privacy, принимающий одно из следующий значений:
Прокси-сервер обязан выполнить дайджест-аутентификацию для узла, с которым не установлены доверительные отношения. После этого прокси-сервер должен добавить заголовок P-Asserted-Identity с идентификатором личности абонента, который был аутентифицирован. Если прокси-сервер получает запрос от узла, с которым доверительные отношения уже установлены, используется уже имеющийся там заголовок P-Asserted-Identity. Процедура отправки сообщения следующая. Если вызываемый абонент расположен в домене доверия (см. рис. 9), прокси-сервер передаёт абоненту запрос без удаления заголовка P-Asserted-Identity.
Рисунок 9. Механизм обеспечения приватности в рамках одного домена Если же абонент находится за пределами домена доверия (см. рис. 10), при выходе сообщения за пределы домена доверия прокси-сервер выполняет удаление или изменение всех заголовков с информацией о личности отправителя (From, Contact, Reply-To, Call-ID, Call-Info, Via, User-Agent, Organization, Server, Subject, In-Reply-To, Record-Route и Warning). P-Asserted-Identity обрабатывается в соответствии со значением заголовка Privacy, а сам заголовок Privacy должен быть удалён.
Рисунок 10. Механизм обеспечения приватности вне домена доверия Разумеется, картина защиты будет неполной без обеспечения целостности и конфиденциальности данных в рамках одного домена доверия на сетевом уровне. Узлы домена должны быть взаимно аутентифицированы, а транзакции между узлами (и между UA и узлами домена) должны быть защищены с помощью TLS или IPSec. Заключение Есть и альтернативные методы, удостоверяющие личность вызывающего или вызываемого абонента: так, RFC 4474 [17] предписывает использование специальных заголовков Identity и Identity-Info для сквозной аутентификации личности инициатора запроса, а RFC 4916 [18] – средства аутентификации получателя диалогообразующего запроса с помощью дополнительного запроса UPDATE в обратном направлении. Остаётся сказать несколько слов об обеспечении защиты медиа-потока. В RFC 3711 [19] описан протокол SRTP (Secure Real-time Transport Protocol), который дополняет RTP функциями обеспечения конфиденциальности, аутентификации сообщений и защиты от атак с воспроизведением. Следует упомянуть и детище автора PGP Фила Циммермана – привлекающий внимание простотой и эффективностью протокол ZRTP. Он использует алгоритм Diffie-Hellman для формирования сеансового ключа и SRTP в качестве транспорта. Интересующиеся могут обратиться к [20]. Принимая во внимание всё разнообразие протоколов, заботящимся о сохранности своих секретов, пользователям следует уделять особое внимание выбору клиентского ПО или устройств. Cводка основных SIP RFC
|
Андрей Погребенник
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
