sip tls что это

Шифрование голоса в VoIP – протоколы SRTP и TLS

Когда обсуждается внедрение бизнес-телефонии у клиента, очень серьёзно рассматриваются вопросы безопасности. Чем больше нашей информации попадает в Интернет, тем более мы уязвимы. Описать криптографические протоколы VoIP заказчику без инженерных знаний всё-таки довольно сложно. Можно ошеломить его множеством специальных терминов. Поэтому мы предлагаем краткий обзор методов обеспечения безопасности VoIP-телефонии – шифрование голоса в VoIP и шифрование служебных сообщений – стараясь сохранить понятную терминологию.

Обзор VoIP-технологии

Перед тем как говорить о технологиях безопасности, попробуем объяснить принцип VoIP простыми словами. Когда разговор передается через Интернет, он разбивается на небольшие пакеты, представляющие из себя набор так называемых слоев или уровней данных. Каждый уровень играет важную роль в передаче пакета – это работает наподобие матрешки или конвейера. Каждый уровень обеспечивает доставку информационного пакета в правильном порядке и нужном направлении, чтобы полученная информация не отличалась от переданной. В этой статье мы сосредоточимся на верхних уровнях – Прикладном и Транспортном, как показано на схеме ниже. Если вы используете IP-телефон, то Прикладной уровень – это протокол SIP. Звонок начинается с SIP-сообщения. Затем Транспортный уровень определяет, как быстро и в каком порядке информация должна быть доставлена получателю. Дополнительно о работе протоколов для передачи голоса можно узнать здесь.

Шифрование голоса в VoIP – протокол SRTP

Когда голос передается по технологии VoIP, и требуется шифрование, используется транспортный протокол Secure Real-time Transport Protocol (SRTP). Он обеспечивает шифрование трафика, аутентификацию сообщений и защиту от атак повторного воспроизведения. Это простой и быстрый криптографический протокол. Он защищает вашу информацию при передаче в открытых сетях. Представьте протокол SRTP как ремень безопасности в автомобиле. Он не влияет на скорость автомобиля и его маршрут, однако защищает пассажиров.

Протокол SRTP хорош еще и тем, что использует стандарт шифрования Advanced Encryption Standard (AES). Это стандарт шифрования мультимедиа-потоков, который используется американским правительством, финансовыми организациями и международными институтами для надежной защиты информации.

Если вам необходимо сделать действительно зашифрованный звонок, протокол SRTP должен быть включен на обеих сторонах вызова. На поддерживаемых 3CX телефонах вы можете увидеть, что шифрование включено, по маленькой иконке замка на LCD-дисплее. Таким образом, еще до того как вы начинаете говорить, вы можете быть уверены, что разговор не прослушают.

Протокол SIP over Transport Layer Security (TLS)

Второй протокол – Transport Layer Security (TLS) – шифрует другую информацию. В время вызова передаются служебные сообщения – телефонные номера, имена пользователей и т.п., которые следует также надежно “спрятать”. Этот протокол защищает вас от перехвата и модификации сообщений SIP. Таким образом, хотя TLS и SRTP – это два криптографических протокола, они защищают разные типы информации: SRTP – сам голос, TLS – служебную информацию.

Подробное изучение этих протоколов? разумеется, выходит за рамки этой статьи. Но надеемся, она поможет вам понять, как работает шифрование голоса в VoIP. Если вы занимаетесь внедрением UC-систем, стоит изучить дополнительную информацию по безопасности VoIP-технологий. Особенно это актуально, если ваши АТС объединены в единую систему через Интернет или есть удаленные пользователи.

Про реализацию протоколов SRTP и TLS в IP-АТС 3CX можно узнать из этой статьи.

Источник

Freeswitch SIP Encryption

Анатомия SIP соединений

SIPS соединение

Решение этой проблемы представлено на рисунке 2 и представляет собой шифрование контрольных пакетов при помощи SSL или TLS. В этом случае уже непросто перехватить и расшифровать переданные данные. Но аудио потоки по прежнему не зашифрованы и доступны для прослушивания.

SIPS и SRTP

Возможности шифрования FreeSWITCH

Данный документ рассматривает TLS/SSL и SRTP. ZRTP рассматривается только вскользь.

TLS/SSL и SRTP шифрование

FreeSWITCH поддерживает SIPS через SSL и/или TLS, совместно с SRTP шифрованием. Шифрование видео не поддерживается в данный момент.

ZRTP шифрование

Гибридное шифрование

FS может шифровать трафик проходящий через него. Т.е. если к вас есть IP телефоны не поддерживающие шифрование, FS может шифровать трафик проходящий через него для другой стороны, поддерживающей шифрование.
Это находит свое применение во множестве практических ситуаций.

Тоже самое касается и шифрования SIPS совместно с SRTP.

Сравнение методов шифрования FS

Freeswitch предоставляет разные методы шифрования:

Настройка TLS/SSL в Freeswitch

Fs должен быть скомпилирован с поддержкой ssl:

Будет создан сертификат УЦ и ключ в ../freeswitch/conf/ssl/CA и сертификат УЦ в ../freeswitch/conf/ssl директории.
Или же:

Вы можете изменить «DAYS=2190» параметр в файле gentls_cert, чтобы продлить действие сертификата подольше.

Просмотр сертификата

Вы можете посмотреть данные сертификата командой:

Важно задать права пользователя на »agent.pem» и »cacert.pem»

Неправильно заданные права не позволят службе TLS использовать сертификат.

Также TLS параметры могут назначаться в конкретном SIP профиле:

Дополнительные параметры TLS

Дополнительные параметры TLS могут быть назначены в SIP профиле. См.Sofia Tls.

Множество SIP TLS профилей

Клиент должен, как минимум, иметь установленный сертификат удостоверяющего центра (УЦ), для обеспечения безопасности. Без включения проверки цепи (был ли сертификат сервера выпущен УЦ) возможна MITM (Человек Посередине) атака на клиент.

Дополнительно, возможно создать клиентский сертификат выпущенный УЦ. Для некоторых устройств это обязательно. Это можно сделать командой:

Будет создан файл Client1.pem (пример), используйте собственное имя, какое угодно. Этот файл содержит пару «сертификат/ключ» и устанавливается на клиент (рекомендуется разные серт. для каждого клиента, но не обязательно). Эти серт. не требуется хранить на сервере.

Коммерческие сертификаты

Пример использования сертификата Letsencrypt в Freeswitch

Нажмите, чтобы отобразить

Нажмите, чтобы скрыть

Использование Freeswitch как SSL/TLS клиент

Freeswitch может коммуницировать с другим сервером, выступая в качестве клиента. Для этого вы должны иметь cafile.pem на клиенте в директории /etc/freeswitch/tls с сертификатом УЦ. Вам также понадобится файл agent.pem (это может быть произвольно созданная пара открытого / закрытого ключа или действительный сертификат клиента) в той же папке, что и клиентский сертификат.

Быстрая настройка SSLv23 + SRTP

Быстрая настройка «Internal Profile», предположим, что имя хоста: pbx.freeswitch.org

Если клиенты поддерживают проверку сертификата сервера, скопируйте cafile.pem на клиент

Укажите для клиентов порт 5061 вместо 5060 и включите TLS и SRTP на клиентах. Если клиент другой FS, установите «transport=tls», для параметра tls-bind-params в дополнение к вышепепечисленным параметрам сервера. И наконец, для включения поддержки SRTP используйте rtp_secure_media=true в строке набора.

Перезагрузите FS или mod_sofia и зарегистрируйте клиентов. Для повышения безопасности, проверьте все параметры TLS и включите проверку сертификатов (чтобы обезопаситься от Человека_посередине).

Calls that originate from the phone have rtp_secure_media set if TLS is set up. Check the global extension. There is a section commented that out will require SRTP on the outbound leg if the inbound leg is encrypted. Enabling this will be problematic with most ITSPs since they do not support TLS.

For calls that originate from (or are routed through) FreeSWITCH and are terminated on the user/ endpoint (e.g., calls to a phone), the following change will enable SRTP if the endpoint registered with TLS. Note that it is a valid configuration to register with TLS but not require SRTP. This disables that valid configuration option for user/ endpoints. It would also require further refinement to support ZRTP on user/ endpoints that connect with TLS. In that case, a better approach would be to set something on the user’s directory entry that specifies which RTP encryption to support. (In other words, there is a reason this is not the default setting.)

Edit conf/directory/default.xml and change the dial-string param to:

Why it’s a good idea

See Secure RTP page of the FreeSWITCH Wiki for how to deploy SRTP.

Troubleshooting

Issues with TLSV1

If you’ve opted for this configuration in your sip_profile:

There are a number of gotchas and snafus possible with TLS. TLS runs on TCP, rather than UDP, so make sure any firewalls are configured to work with TCP. Generate the proper certificate, and make sure it’s loaded into the phone or ATA. Also, ensure that the time is configured properly on your endpoint as you will get cryptic «bad certificate» error messages if the time is too far off, and it will fail to handshake properly. (For example, certificates have «not valid before» and «not valid after» attributes.) If your phone won’t register, or fails to work properly, you might consider checking the Interoperability list, and/or your phones documentation and firmware revision. If it still fails to work properly, you might consider sslv23 as a fallback.

Issues with SSLV23

If you’ve opted for this configuration option in your sip_profile:

This will give you the ability to encrypt the data. Security is similar to that of with web servers, certificate trusted roots can be checked, client certificate authentication is supported, subjects and cert dates can be validated (some of these do depend on client support for the feature). This may in fact be what you want, and considering that several phones do not support TLS, but do support SSL, you may want to configure accordingly.

If your SIP profile fails to start up

If you go into the FreeSWITCH CLI and type:

You might find that your sip_profile for which you configured the TLS/SSL settings is missing. Should that be the case, you’re probably missing the libssl-dev package or the agent.pem file is not in place or has incorrect permissions. Ensure the user FreeSWITCH runs as has read permissions to the certificates and keys. Turning on sofia tport debug logging to high will help print out errors on why it is not starting up properly. Refer to your distribution in order to install the OpenSSL development package. This is necessary for the code which performs the encryption within FreeSWITCH to be compiled into the binary. Enabling a higher level of debug in sofia (sofia loglevel all 9, or sofia loglevel tport 9 generally give enough) and in the console can help debug issues and handshake problems.

TLS Negotiation Error ‘No matching cipher’

If you receive a ‘no matching cipher’ error message, first check to ensure you have concatenated your certificate key into your agent.pem file. If you still receive the error, regenerate both the key and the certificate and make a new agent.pem with the new key and certificate, then try again.

Further Debugging Steps

If you are still having issues getting TLS running the following are suggested:

Configuring DNS NAPTR and SRV for TLS

This isn’t required as TLS will function without it, but it is recommended. If you’re going to set up TLS you might take the time to set up the correct DNS SRV and NAPTR records.

Here is an example of the NAPTR records you will need (make subtitutions for «domain.com» as necessary):

If you configure with –enable-sctp and have sctp loaded on Linux you can add this record:

Then you will want to set up these SRV records in addition to the above NAPTR:

If you configure with –enable-sctp and have SCTP loaded on Linux you can add this record:

Example: Snom phones will fully honor both the NAPTR and SRV as will Sofia-SIP on outbound calls originating from FreeSWITCH.

Источник

IPsec vs TLS/SRTP в обеспечении безопасности VoIP

Предисловие

Под катом перевод оригинальной статьи, который мне необходимо было сделать для сдачи кандидатского зачёта по английскому языку в магистратуре. Мною был выбран именно этот текст, поскольку, ещё во время написания дипломной работы, я достаточно хорошо ознакомился с его содержимым. С тех пор прошёл уже где-то год, и только сейчас я решил его опубликовать. Примечательно, что за это время, решая задачи защиты IP-телефонии, мне довелось поработать как с TLS/SRTP, так и с IPsec. Надеюсь, для кого-то это будет полезным (как для меня, в своё время), или хотя бы просто интересным чтением. Пишите своё мнение по поводу этого материала.

P.S. В силу достаточно большого объёма, некоторые вещи я умышленно опустил, пропуски отмечены троеточием. Без перевода остался термин Information Assurance, я так и не встретил аналогии на русском.

1. Введение

…
В связи с требованиями IETF (Internet Engineering Task Force) о включении IPsec в каждую реализацию IPv6, разумно рассматривать IPsec в качестве подходящего протокола, для обеспечения безопасности VoIP. Однако, сейчас этому предпочитают использование протокола TLS (Transport Layer Security) — для обеспечения безопасности SIP (Session Initiation Protocol), и применение SRTP (Secure Real-time Transport Protocol), для защиты RTP.

В настоящее время (прим. перев. — на момент написания оригинала, 2007 год) сравнение этих двух подходов отсутствует, настоящей работой предоставляется такое сравнение, рассматриваются достоинства и недостатки каждого из подходов. На основе настоящей работы исполнители и проектировщики IA (Information Assurance) смогут принимать взвешенные решения.

SIP становится доминирующим протоколом организации сеансов связи VoIP. RTP является главенствующим протоколом упаковки голосовых данных и, последующей их транспортировке, между оконечными устройствами, по IP-сетям. TLS, SRTP и IPsec это протоколы, использующиеся для обеспечения безопасности сеансов SIP и RTP, они обеспечивают аутентификацию, целостность и конфиденциальность связанных с VoIP IP-пакетов.… На рисунке ниже, показано расположение протоколов TLS, IPsec, SRTP, SIP и RTP внутри модели OSI.

Рисунок ниже показывает общую схему звонка по SIP и RTP.

2. Обзор протоколов

SIP описан в RFC 3261 как управляющий протокол прикладного уровня, предназначенный для создания, изменения и завершения сеансов связи с одним или более участниками. Поставщики услуг VoIP вкладывают значительные средства в развитие SIP, используемый для сигнализации в VoIP. Схема, на рисунке выше, в целом, показывает поток сообщений, связанных с установлением SIP сеанса голосовой связи.
.

RTP описан в RFC 3550 как протокол, обеспечивающий функции сквозной сетевой передачи, подходящий для приложений, передающих данные в реальном времени, как, например, аудио, в широковещательных или целевых сетевых службах. В данный момент это единственный протокол, подходящий для передачи голоса в VoIP. Сеанс RTP инициируется каждым SIP клиентом по получении ACK или OK сообщения, как показано на рисунке выше.

IPsec

IPsec описан в RFC 4301 как набор служб безопасности на уровне IP, который позволяет целевой системе выбирать необходимые протоколы безопасности, определять алгоритмы и вводить в действие криптографические ключи необходимые для предоставления запрашиваемых услуг. IPsec SA (Security Association) устанавливается до инициации сеансов SIP и RTP, и как только она установлена, IPsec будет автоматически использован для обеспечения безопасности SIP и RTP пакетов, поскольку они проходят через сетевой уровень модели OSI, в пределах IP-стека.

TLS описан в RFC 4346 как протокол, обеспечивающий безопасность связи в сети Интернет. Протокол позволяет клиент-серверным приложениям общаться способом, защищённым от подслушивания, порчи и/или подделки сообщений. TLS версии 1.0 так же известен как SSL (Secure Socket Layer) версии 3.1. Безопасное соединение TLS устанавливается до инициации SIP сеанса. TLS используется для обеспечения безопасности SIP пакетов, поскольку они проходят через транспортный уровень модели OSI, в пределах IP-стека.

SRTP описан в RFC 3711 как профиль RTP, который может обеспечить конфиденциальность, аутентификацию сообщений и защиту от повтора RTP и RTCP (Real-time Transport Control Protocol). Общая схема передачи сообщений для SRTP и SIP такая же, как на рисунке выше. SRTP используется для обеспечения безопасности RTP-пакетов, поскольку они проходят через транспортный уровень модели OSI, в пределах IP-стека, он полагается на SIP-сообщения, для обмена ключами, и TLS, для аутентификации SIP-клиентов.

3. Сравнение

Сложность реализации и покрытие стандартами

В плане реализации, TLS проще, чем IPsec, интегрировать с SIP. RFC 4346 предъявляет около 200 требований к реализации TLS. С другой стороны, IPsec имеет более 500 требований, определяющих реализацию и описанных примерно в 11 RFC.

IETF опубликовано несколько документов о том, как могут быть интегрированы SIP, TLS и SRTP. В добавок к этому, Министерством Обороны (прим. перев. — страна не указана) разработаны технические требования по совместимости, применимые к обеспечению безопасности SIP с помощью TLS и интеграции SIP/TLS с SRTP. Авторам настоящей статьи не известно о существовании документов IEFT, описывающих как IPsec может быть интегрирован с SIP или RTP, этот вопрос недостаточно хорошо изучен отраслью связи. Тем не менее, появились некоторые исследовательски-направленные реализации показывающие, что осуществить такое сложнее, в связи с необходимостью доступа к ядру операционной системы. Поставщики VoIP, как правило, устанавливают свои VoIP-приложения на существующие операционные системы, такие как Windows, Linux или UNIX, и, обычно, имеют ограниченный доступ, либо вообще не имеют доступа к ядру операционной системы.

Реализация обоих подходов на VoIP-устройствах может быть невозможной, в зависимости от поставщика и типа устройства. К примеру, некоторые оконечные устройства ограничены в памяти, размере хранилища данных и вычислительной способности и могут не поддерживать одновременно реализации TLS, SRTP и IPsec.

Поддержка иерархической сигнализации

Основной маркетинговой особенностью IPsec является то, что он обеспечивает сквозное шифрование, что и требуется большинству приложений, работающих с данными. Тем не менее, коммерческие предложения передачи голоса основаны на иерархической модели сигнализации, в которой ОУ (оконечное устройство) оповещает LCC (Local Call Controller), с целью установления сеанса связи, по собственному протоколу сигнализации. LCC, как правило, оповещает SS (Software Switch) провайдера, используя SIP, для выхода во внешнюю сеть, далее, SS может оповещать другой SS или LCC с целью завершения установления сеанса связи с удалённым ОУ, как это показано на рисунке ниже (слева). Собственный протокол сигнализации используется между ОУ и LCC для того, что бы поставщик услуг имел возможность предоставлять пользователю уникальные функции с добавленной стоимостью, что невозможно, если был принят стандартизированный протокол.

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

Сквозная модель безопасности используется для огранизации канала передачи данных и может быть реализована, используя как SRTP, так и IPsec. IEFT опубликован способ обмена ключми для SRTP через SIP-пакеты, таким образом, сеанс связи может быть установлен после завершения сигнализации. Похожий подход может быть разработан и для IPsec, но этого, в настоящее время, не сделано.

Эффективность использования полосы пропускания

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

Сравнивать размер пакетов IPsec с SRTP довольно трудно, поскольку они зависят от используемого режима (транспортный или туннельный), количество байт заполнения (padding), используемых алгоритмов аутентификации и контроля целостности. Приняв, что протокол ESP (Encapsulating Security Payload) в IPsec используется в транспортном режиме с минимальным заполнением и малым размером имитовставки, можно утверждать, что SRTP на 6% более эффективен для IPv6-пакетов, чем IPsec. Если требуется контролировать целостность IP-заголовка, то в IPsec может быть использован протокол AH (Authentication Header), что повлечёт за собой появление дополнительных накладных расходов.

Используя те же предпосылки в случае SIP, IPsec требует на 2 байта больше, по сравнению с TLS, для защиты SIP.

Без оценки осталось влияние сжатия RTP-заголовка. В средах, где используется такое сжатие, SRTP оказывается на 10 байт более эффективным, чем IPsec. В таблице ниже подытожено вышесказанное.

Коммерческое применение

Коммерческие поставщики услуг VoIP вкладываю серьёзные средства в использование TLS и SRTP, для обеспечения безопасности VoIP. IPsec так же рассматривался для этой задачи, однако TLS и SRTP были признаны лучшим решением. На данный момент не существует коммерческой реализации IPsec, предназначенной для обеспечения безопасности VoIP основанной на SIP. Поставщики, использующие legacy-сигнализацию H.323 для своих решений передачи голоса, скорее всего, выберут IPsec для защиты своих решений. Однако большинство поставщиков H.323, в настоящее время, используют решения без шифрования и переходят к решениям, основанным на SIP.

Information Assurance

Другим отличием между IPsec и SRTP является то, что IPsec зашифровывает заголовок RTP, в то время как SRTP этого не делает. Преимущество использования IPsec здесь в том, что он скрывает полезную информацию от потенциального злоумышленника. Недостаток состоит в том, что это ограничивает способность межсетевых экранов и SBC (Session Border Controllers) в применении микроканалов на определённых портах. Это становится особенно критичным для межсетевых экранов и SBC выступающих в роли устройств преобразования сетевых адресов (NAT) для нескольких перекрывающихся LCC. Поскольку IP-адреса всех прибывающих VoIP-пакетов направлены на межсетевой экран или SBC, единственной отличительной особенностью, которую экран или SBC могут использовать для определения соответствующего целевого LCC, это номер порта.

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

Установка соединения, смена ключей и время восстановления связи

Для избежания чрезмерно долгого времени установки сеанса и эффекта отсечки (потери пакетов в начале сеанса голосовой связи) крайне важно, что бы ключ шифрования канала передачи данных был распространён как часть процесса сигнализации. IEFT определило способо распространения ключей SRTP как части SIP сигнализации, помещая ключ в тело SDP (Session Description Protocol) SIP-сообщения. IEFT на данный момент не разработан механизм SDP распространения ключей шифрования в IPsec. Более того, модель запрос/ответ из RFC 3264 может препятствовать включению ключевой информации IPsec в сигнальные сообщения SIP.

Другой вопрос это задержка, связанная со сменой ключей. Недавние исследования, в которых сравнивается время смены ключей сеанса TLS и сеанса IPsec, показали, что IPsec требует примерно в 20 раз (26 мс против 1.3 мс) больше времени на смену ключей, чем TLS. Это не большой период для единичной смены, но это может стать проблемой, если тысячи оконечных устройств попытаются сменить ключи одновременно.

Последний вопрос – это задержка, связанная с восстановлением безопасного соединения. SIP с использованием TLS требует минимум 6 обменов сообщениями. Восстановление соединения SIP с использованием IPsec в основном связано с выполнением протокола IKE (Internet Key Exchange) и будет зависеть от того как режим, основной, базовый или агрессивный, используется в первой фазе обмена. Полагая, что используется основной режим, IPsec требует 9 обменов сообщениями (прим. перев. — в оригинале речь идёт об IKEv1 который, в настоящий момент замещён IKEv2, а IKEv2, в свою очередь, требует 4 обмена, если не используется EAP).

Управление сетью

Главным преимуществом SRTP над IPsec является то, что заголовки UDP и RTP пакетов открыты для персонала обслуживания сети, они могут использовать полученную информацию для поиска и устранения сетевых проблем. IPsec зашифровывает эти заголовки, уничтожаят такую информацию С этой же точки зрения, IPsec и TLS сопоставимы.

Сокрытие топологии

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

4. Заключение

На основании нашего предварительного сравнения использования IPsec и связки TLS+SRTP для защиты VoIP, рекомендуется, что бы разработчики использовали TLS и SRTP. Такой подход проще внедрить и поддерживать, так же он более выгодный, чем IPsec, с точки зрения использования полосы пропускания. Существенного преимущества в безопасности от использования IPsec, в сравнении с TLS и SRTP, нет.

Такие выводы основываются на анализе существующих стандартов, текущих реализаций TLS и SRTP у поставщиков VoIP и научно-ориентированных реализаций IPsec, а так же на ранее опубликованных сравнениях. Однако, опубликованных работ, в которых сравниваются реализации IPsec и TLS/SRTP для обеспечения безопасности сеансов голосовой связи в рабочих условиях либо не существует, либо они ограничены и предлагают лишь почву для дальнейших использований. Одной из целей дальнейших исследований могут стать эффективные механизмы передачи ключевой информации IPsec через SIP сообщения и сравнение безопасности и производительности для каждого подхода.

Источник