Предисловие
Под катом перевод оригинальной статьи, который мне необходимо было сделать для сдачи кандидатского зачёта по английскому языку в магистратуре. Мною был выбран именно этот текст, поскольку, ещё во время написания дипломной работы, я достаточно хорошо ознакомился с его содержимым. С тех пор прошёл уже где-то год, и только сейчас я решил его опубликовать. Примечательно, что за это время, решая задачи защиты 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
SIP описан в RFC 3261 как управляющий протокол прикладного уровня, предназначенный для создания, изменения и завершения сеансов связи с одним или более участниками. Поставщики услуг VoIP вкладывают значительные средства в развитие SIP, используемый для сигнализации в VoIP. Схема, на рисунке выше, в целом, показывает поток сообщений, связанных с установлением SIP сеанса голосовой связи.
...
RTP
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
TLS описан в RFC 4346 как протокол, обеспечивающий безопасность связи в сети Интернет. Протокол позволяет клиент-серверным приложениям общаться способом, защищённым от подслушивания, порчи и/или подделки сообщений. TLS версии 1.0 так же известен как SSL (Secure Socket Layer) версии 3.1. Безопасное соединение TLS устанавливается до инициации SIP сеанса. TLS используется для обеспечения безопасности SIP пакетов, поскольку они проходят через транспортный уровень модели OSI, в пределах IP-стека.
SRTP
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. В таблице ниже подытожено вышесказанное.
Протокол | Размер пакета, байт | Полоса пропускания, кбайт/с |
---|---|---|
SRTP | 254 | 101,6 |
RTP/IPsec | 270 | 108,0 |
SIP/TLS | 1280 | N/A |
SIP/IPsec | 1282 | N/A |
Коммерческое применение
Коммерческие поставщики услуг VoIP вкладываю серьёзные средства в использование TLS и SRTP, для обеспечения безопасности VoIP. IPsec так же рассматривался для этой задачи, однако TLS и SRTP были признаны лучшим решением. На данный момент не существует коммерческой реализации IPsec, предназначенной для обеспечения безопасности VoIP основанной на SIP. Поставщики, использующие legacy-сигнализацию H.323 для своих решений передачи голоса, скорее всего, выберут IPsec для защиты своих решений. Однако большинство поставщиков H.323, в настоящее время, используют решения без шифрования и переходят к решениям, основанным на SIP.
Information Assurance
Наиболее распространённый аргумент в пользу использования IPsec заключается в том, что он обеспечивает сквозное шифрование. Однако, это преимущество не используется в случае сигнализации VoIP, поскольку большинство реализаций основаны на, как говорилось ранее, иерархической модели сигнализации, а TLS лучше подходит для этой модели. ...
Преимущество IPsec заключается в том, что он защищает данные на сетевом уровне IP, что ниже в стеке протоколов, чем TLS, который обеспечивает защиту на транспортном уровне. ...
Другим отличием между 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 сообщения и сравнение безопасности и производительности для каждого подхода.
Комментарии (11)
EminH
18.01.2018 10:39А почему на картинках все на английском?
HenadziMatuts Автор
18.01.2018 11:06Изначально, в предисловии я собирался упомянуть о том, что некоторые иллюстрации не переведены, но, позже, эту фразу я убрал. Если вам это будет интересно, то я могу доперевести оставшиеся иллюстрации.
EminH
18.01.2018 11:41Мне лично на английском даже понятнее, просто если это перевод, то я бы ожидал увидеть все на русском.
HenadziMatuts Автор
18.01.2018 11:44Тут согласен, нужно было делать всё на одном языке, возможно позже верну оригиналы иллюстраций.
Mnemonik
18.01.2018 13:09Как насчет освещения вопроса о том, что законодательно SRTP вообще запрещен к использованию в России и устройства поставляемые в Россию официально идут с отключенным SRTP?
HenadziMatuts Автор
18.01.2018 13:21Если честно, то я плохо осведомлён о том, как обстоят дела в России, поскольку сам живу и работаю в Беларуси, а у нас с этим пока всё в порядке. Где-то полтора года назад я слышал о проблемах в зашифрованным VoIP'ом, но о том, что SRTP запрещён законодательно слышу впервые.
А в чём там собственно проблема? В неиспользовании национальной крипты, или что-то другое?Mnemonik
18.01.2018 13:46Да я бы и сам бы рад был узнать точно, потому что это именно то, что знатно меня удивило при исследовании вопроса — а как бы нам зашифровать войс — то что во всех официальных устройствах поставляемых в россию эта функция отключена в прошивке, и это в принципе получается довольно шатким шагом. все PBX без SRTP, все хардварные устройства без SRTP, слишком много надо городить чтобы включить это все.
EminH
18.01.2018 15:34А в Беларуси с Voip точно все в порядке? По моей информации VoIP работает только внутри страны. Не знаю на законодательном ли уровне, но похоже запрет все же есть.
HenadziMatuts Автор
18.01.2018 16:04Вот как сейчас обстоят дела:
Таким образом, указ не коснется звонков между мессенджерами, однако, например, для возможности совершения звонка из Беларуси через Skype на городские/международные номера, мессенджеру придется заключить договор с оператором.
gotch
Как вы оцениваете результат вашей работы сегодня, 10 лет спустя?
HenadziMatuts Автор
Стоит отметить, что моя работа здесь — это лишь перевод и публикация (если под «вашей работой» вы имели ввиду, непосредственно, сравнение). Однако, как отмечено в предисловии, с момента моего первого знакомства с оригиналом, я поработал с обоими подходами, и поэтому, некоторые мысли на этот счёт у меня всё же есть.
На сегодняшний день, я вижу, что преимущество TLS/SRTP, обоснованное в статье, если не увеличилось, то как минимум сохранилось на том же уровне. Мне так же не известно ни об одном VoIP-приложении интегрирующим IPsec. Ещё можно сказать о том, что если от безопасности SIP нам требуется только защита процесса согласования ключей, то TLS заменяется на ZRTP, что значительно упрощает разработку.
Однако, если задача поставлена чуть шире, и требуется обеспечить безопасность не только VoIP, но и в принципе любых данных передаваемых по IP, то тут вполне обоснованно можно использовать IPsec (как отдельное приложение), поскольку он, в том числе, закроет и VoIP.
К примеру, мы делали такую вещь: на серверную машину ставили Asterisk и IPsec-реализацию — StrongSwan; на клиентские Android-устройства ставили VoIP-звонилки — CSipSimple и клиентский StrongSwan. Сначала клиенты поднимают туннель с сервером через StrongSwan, а после общаются через CSipSimple, в результате весь SIP/RTP оказывается закрыт IPsec'ом. В то же время, можно выкинуть StrongSwan и настоить в CSipSimple защиту ZRTP/SRTP. Получим тот же результат.