Voice Over IP Security

Voice Over IP Security

Доброго времени суток, уважаемые читатели!

Voice over IP – передача голоса по IP-сетям с коммутацией пакетов – одна из самых важных тенденций в области телекоммуникаций. Как и во многих новых технологиях, VOIP представляет как риски безопасности, так и возможности. VOIP имеет совершенно другую архитектуру, чем традиционная телефонная система, и эти различия приводят к серьезным проблемам безопасности. Более низкая стоимость и большая гибкость являются одними из возможностей VOIP для предприятия, но VOIP не следует устанавливать без тщательного рассмотрения проблем безопасности. Администраторы могут ошибочно предположить, что, поскольку оцифрованные голоса перемещаются в пакетах, они могут просто подключать компоненты VOIP к уже обеспеченным сетям и оставаться в безопасности. Однако процесс не так прост. В этой публикации объясняются проблемы безопасности VOIP для агентских и коммерческих пользователей VOIP и излагаются шаги, необходимые для защиты сети VOIP организации. Вопросы безопасности VOIP для коммутируемой телефонной сети общего пользования (PSTN) в значительной степени выходят за рамки настоящей статьи.
Системы VOIP используют самые разнообразные формы, в том числе традиционные телефонные системы, устройства для проведения конференций и мобильные устройства. Помимо оборудования конечного пользователя, системы VOIP включают в себя множество других компонентов, включая процессоры вызовов, шлюзы, маршрутизаторы, брандмауэры и протоколы. Большинство этих компонентов имеют аналоги, используемые в сетях передачи данных, но требования к производительности VOIP означают, что обычное сетевое программное обеспечение и аппаратное обеспечение должны быть дополнены специальными компонентами VOIP. VOIP требует более высокой производительности, чем большинство систем данных, и требует критически важные сервисы, такие как Система-112. Одним из основных источников “каши в гллове” для новичок в сфере VOIP, является (естественное) предположение, что, поскольку оцифрованный голос перемещается в пакетах так же, как и другие данные, существующие сетевые архитектуры и инструменты могут использоваться без изменений. Однако VOIP добавляет ряд осложнений к существующим сетевым технологиям, и эти проблемы усиливаются соображениями безопасности.
Качество обслуживания (QoS) имеет основополагающее значение для функционирования сети VOIP, которая отвечает ожиданиям качества пользователей. Однако реализация различных мер безопасности может привести к значительному ухудшению качества обслуживания. Эти осложнения варьируются от брандмауэров, задерживающих или блокирующих настройки вызовов, на зашифрованную задержку и изменение задержки (джиттер). Из-за критически важного характера VOIP и его низкой толерантности к сбоям и потерям пакетов многие меры безопасности, реализованные в традиционных сетях передачи данных, просто не применимы к VOIP в их нынешнем виде; брандмауэры, системы обнаружения вторжений и другие компоненты должны быть специализированы для VOIP. Текущие системы VOIP используют либо собственный протокол, либо один из двух стандартов, H.323 и протокол инициации сеанса (SIP). Хотя SIP, похоже, набирает популярность, ни один из этих протоколов еще не стал доминирующим на рынке, поэтому часто имеет смысл включать компоненты, которые могут поддерживать оба протокола. В дополнение к SIP и H.323 существуют еще два стандарта: протокол управления медиа-шлюзом (MGCP) и Megaco/H.248, которые могут использоваться в больших системах шлюзования. Эти стандарты могут использоваться для облегчения обработки сообщений с помощью медиашлюзов, или, с другой стороны, они могут быть легко использованы для реализации терминалов.
Пакетные сети зависят от их успешной работы с большим количеством настраиваемых параметров: IP и MAC (физические) адреса голосовых терминалов, адресов маршрутизаторов и брандмауэров и специального программного обеспечения VOIP, таких как IP PBX. Многие из этих сетевых параметров устанавливаются динамически каждый раз при перезапуске сетевых компонентов или при возобновлении или добавлении телефона VOIP в сеть. Поскольку в сети имеется так много мест с динамически настраиваемыми параметрами, злоумышленники имеют широкий набор потенциально уязвимых точек для атаки.
Брандмауэры являются основным продуктом безопасности в современных IP-сетях. Независимо от того, защищаете ли LAN или WAN, инкапсулируете DMZ или просто защищаете один компьютер, брандмауэр обычно является первой линией защиты от злоумышленников. Брандмауэры работают, блокируя трафик, считающийся инвазивным, навязчивым или просто злым от прохождения через них. Приемлемый трафик определяется набором правил, запрограммированных в брандмауэре сетевым администратором. Внедрение брандмауэров в сеть VOIP усложняет несколько аспектов VOIP, в первую очередь – динамическую маршрутизацию трафика и процедуры установления соединения.
Трансляция сетевых адресов (NAT) – это мощный инструмент, который может использоваться для скрытия внутренних сетевых адресов и включения нескольких конечных точек в локальной сети для использования одного и того же (внешнего) IP-адреса. Преимущества NAT – это цена. Во-первых, попытка сделать вызов в сети становится очень сложной при вводе NAT. Ситуация несколько похожа на офисное здание, где почта адресована именами сотрудников и адресом здания, но внутренняя адресация обрабатывается почтовым отделением компании. Также есть несколько проблем, связанных с передачей голосовых данных через NAT, включая несовместимость с IPsec. Хотя использование NAT может быть уменьшено по мере принятия IPv6, они будут оставаться общим компонентом в сетях на долгие годы, поэтому системы VOIP должны иметь дело со сложностями NAT.
Брандмауэры, шлюзы и другие подобные устройства также могут помочь злоумышленникам нарушить целостность сети. Однако брандмауэры не защищают от внутреннего хакера. Другой уровень защиты необходим на уровне протокола для защиты голосового трафика. В VOIP, как и в сетях передачи данных, это может быть достигнуто путем шифрования пакетов на уровне IP с использованием IPsec или на уровне приложения с защищенным RTP – транспортным протоколом реального времени (RFC 3550). Однако несколько факторов, в том числе расширение размера пакета, латентность шифрования и нехватка QoS-срочности в самом криптографическом процессоре, могут вызвать чрезмерную задержку в доставке пакета VOIP. Это приводит к ухудшению качества голоса, снова подчеркивая компромисс между безопасностью и качеством голоса и подчеркивая необходимость скорости.
VOIP по-прежнему является новой технологией, поэтому сложно составить полную картину того, как будет выглядеть зрелая всемирная сеть VOIP. По мере появления SIP, новые технологии и новые проекты протоколов способны радикально изменить VOIP. Хотя в настоящее время существует множество различных архитектур и протоколов на выбор, в конечном итоге появится истинный стандарт. Если не появится широко распространенный открытый стандарт, решения, вероятно, будут включать в себя ряд проприетарных элементов, которые могут ограничить выбор предприятия. Наиболее широко используемыми конкурирующими стандартами являются SIP и H.323. Крупные поставщики инвестируют растущую часть своих усилий по развитию в продукты SIP. В продукты, поддерживающие Мгновенный обмен сообщениями, входит расширение стандарта SIP – SIP для мгновенного обмена сообщениями и обеспечения доступности (SIMPLE). Пока не появится действительно доминирующий стандарт, организации, перемещающиеся в VOIP, должны рассмотреть шлюзы и другие сетевые элементы, которые поддерживают как H.323, так и SIP. Такая стратегия помогает обеспечить стабильную и надежную сеть VOIP в ближайшие годы, независимо от того, какой протокол превалирует.
Проектирование, развертывание и безопасная работа с сетью VOIP – это сложная работа, требующая тщательной подготовки. Интеграция системы VOIP в уже перегруженную сеть может создать серьезные проблемы для организации. Организация должна тщательно изучить, как ее сеть построена и какое решение лучше всего соответствует ее потребностям.

Содержание

1. Убедитесь в том, что организация проверила и может с достаточной степенью вероятности управлять рисками для своей информации, системных операций и непрерывности основных операций при развертывании систем VOIP.

Особенно сложная среда безопасности создается при развертывании новых технологий. Риски часто не полностью понятны, администраторы еще не имеют опыта с новой технологией, а элементы управления и политики безопасности должны обновляться. Поэтому учреждениям следует тщательно учитывать такие вопросы, как уровень знаний и обучения в этой технологии, зрелость и качество их методов безопасности, средств контроля, политики и архитектуры и их понимание связанных с этим рисков безопасности. Эти вопросы следует учитывать для всех систем, но особенно важны для развертывания VOIP для основных услуг, таких как “Информационно-справочные системы” федерального уровня.
VOIP может обеспечить более гибкое обслуживание по более низкой цене, но есть значительные аспекты, которые необходимо учитывать. Системы VOIP могут быть более уязвимы, чем обычные телефонные системы, отчасти потому, что они привязаны к сети передачи данных, что приводит к дополнительным недостаткам в безопасности и возможностям атаки. Конфиденциальность может подвергаться большему риску в системах VOIP, если не применяются и не поддерживаются сильные меры контроля. Дополнительной проблемой является относительная нестабильность технологии VOIP по сравнению с существующими системами телефонии. Сегодня системы VOIP все еще созревают, а доминирующие стандарты не появились. Эта нестабильность усугубляется зависимостью VOIP от пакетных сетей в качестве транспортной среды. Коммутируемая телефонная сеть является сверхнадежной. Интернет-сервис, как правило, менее надежный, и VOIP не может функционировать без подключения к Интернету, за исключением крупных корпоративных или других пользователей, которые могут работать в частной сети. Существенные телефонные услуги, если они не будут тщательно спланированы, развернуты и сохранены, будут подвергаться большему риску, если они основаны на VOIP.

2. Оцените затраты на дополнительные системы резервного питания, которые могут потребоваться для обеспечения непрерывной работы во время сбоев питания.

Необходимо провести тщательную оценку, чтобы обеспечить достаточную резервную мощность для коммутатора VOIP офиса, а также для каждого настольного инструмента. Затраты могут включать в себя электроэнергию для поддержания заряда ИБП, периодические затраты на техническое обслуживание резервных систем выработки электроэнергии и стоимость замены ИБП. Если требуется аварийное/резервное питание в течение нескольких часов, потребуются электрические генераторы. Затраты на них включают топливо, хранилища топлива и стоимость утилизации топлива в конце срока хранения.

3. Необходимо использовать VOIP-брандмауэры и другие соответствующие механизмы защиты. Предприятия должны включать, использовать и регулярно проверять функции безопасности, которые включены в системы VOIP.

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

4. Если это целесообразно, «программные телефоны», которые используют VOIP с использованием обычного ПК с гарнитурой и специальным программным обеспечением, не должны использоваться там, где существует проблема безопасности или конфиденциальности.

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

5. Если мобильные устройства должны быть интегрированы с системой VOIP, используйте продукты, реализующие Wi-Fi защищенный доступ (WPA), а не 802.11 Wired Equivalent Privacy (WEP).

Функции безопасности 802.11 WEP обеспечивают небольшую защиту, поскольку WEP может быть взломан с помощью общедоступного программного обеспечения. Более поздний WiFi Protected Access (WPA), моментальный снимок существующего стандарта 802.11i, предлагает значительные улучшения в области безопасности и может помочь в интеграции беспроводной технологии с VOIP. NIST настоятельно рекомендует, чтобы WPA (или WEP, если WPA недоступен), функции безопасности использовались как часть общей стратегии углубленной защиты. Несмотря на свои недостатки, механизмы безопасности 802.11 могут обеспечить определенную степень защиты от несанкционированного раскрытия, несанкционированного доступа к сети или других активных зондирующих атак. Тем не менее, Федеральный стандарт обработки информации (FIPS) 140-2, Требования безопасности для криптографических модулей, является обязательным и обязательным для федеральных агентств, которые определили, что определенная информация должна быть защищена с помощью криптографических средств. Как определено в настоящее время, ни WEP, ни WPA не соответствуют стандарту FIPS 140-2. В этих случаях необходимо будет использовать криптографические протоколы и приложения более высокого уровня, такие как защищенная оболочка (SSH), безопасность транспортного уровня (TLS) или безопасность протокола IP (IPsec) с проверенными криптографическими модулями FIPS 140-2 и связанными с ними алгоритмами для защиты информации, независимо от того, используются ли протоколы безопасности нелицензированных каналов передачи данных.
Существующие функции безопасности в рамках протокола SIP
RFC 3261 описывает несколько функций безопасности для SIP, которые я опишу в этой статье. RFC 3261 разъясняет несколько функций безопасности, которые были высказаны в оригинальном RFC 2543, например, использование PGP и HTTP Basic Authentication.
5.1 Аутентификация данных сигнализации с использованием проверки подлинности HTTP Digest
Схема аутентификации Digest основана на простой парадигме «запрос-ответ». Схема аутентификации дайджеста препятствует удаленному концу с использованием значения nonce. Идентификация дайджеста SIP основана на аутентификации дайджеста, определенной в RFC 2617. Здесь действительный ответ содержит контрольную сумму (по умолчанию, контрольную сумму MD5) имени пользователя, пароля, заданного значения nonce, метода HTTP и запрошенной URI. Таким образом, пароль никогда не отправляется в открытом виде. Из-за слабой безопасности и предотвращения атак путем понижения требуемого уровня безопасности проверки подлинности HTTP Basic Authentication не была рекомендована в текущем проекте RFC 3261.
5.2 Использование S/MIME в SIP
Сообщения SIP переносят стандарт MIME. Сам MIME определяет механизмы защиты целостности и шифрования содержимого MIME. SIP может использовать S/MIME для включения механизмов, таких как распространение открытого ключа, аутентификация и защита целостности, или конфиденциальность данных сигнализации SIP. S/MIME может рассматриваться как замена PGP для обеспечения средств защиты целостности и шифрования сообщений SIP. Для защиты полей заголовка SIP задано туннелирование сообщений SIP в телах MIME. Как правило, предлагаемое туннелирование SIP для защиты заголовка SIP создает дополнительные накладные расходы. S/MIME требует использования сертификатов и закрытых ключей, тогда как сертификаты могут выдаваться доверенной третьей стороной или могут быть сгенерированы автоматически. Последний случай может не обеспечивать подлинную аутентификацию пользователя, но может использоваться для обеспечения ограниченной защиты целостности сообщений.
В текущем документе RFC 3261 рекомендуется использовать S/MIME для User-Agent – UA. Более того, если S/MIME используется для туннельных сообщений (описано ниже), рекомендуется использовать TCP-соединение из-за больших сообщений. Это делается для того, чтобы избежать проблем, которые могут возникнуть в результате фрагментации пакетов UDP. Могут быть реализованы следующие услуги:
проверка подлинности и целостность данных сигнализации
конфиденциальность данных сигнализации
5.3 Конфиденциальность Медиа-данных
Сам SIP не рассматривает шифрование медиаданных. Использование RTP-шифрования, как определено в RFC 1889, может обеспечивать конфиденциальность данных мультимедиа. Другим вариантом защиты медиапотока является использование протокола SRTP [DSRTP]. Для управления ключами может использоваться SDP (см. RFC 2327). SDP может передавать ключи сеанса для медиапотоков. Обратите внимание, что использование SDP для обмена ключами не дает возможность отправить зашифрованный медиапоток. Следовательно, запрос сигнализации должен быть зашифрован, предпочтительно с использованием сквозного шифрования.
5.4 Использование TLS в SIP
RFC 3261 предусматривает использование TLS для прокси-серверов, серверов перенаправления и регистраторов для защиты сигнализации SIP. Рекомендуется использовать TLS для UA. TLS может защищать сообщения сигнализации SIP от потери целостности и конфиденциальности. Он обеспечивает интегрированное управление ключами с взаимной аутентификацией и безопасным распределением ключей. TLS применим для переходов между UA/proxy или между прокси. Недостатком TLS в сценариях SIP является требование надежного транспортного стека (сигнализация SIP на основе TCP). TLS не может применяться к сигнализации SIP на основе UDP. Так же, как безопасный HTTP указывается с помощью «https:», безопасный SIP задается с помощью универсального индикатора ресурса (URI), который начинается с «sips:».
5.5 Использование IPsec в SIP
IPsec также может использоваться для обеспечения безопасности для сигнализации SIP на сетевом уровне. Этот тип безопасности наиболее подходит для обеспечения безопасности SIP-хостов в сценарии SIP VPN (SIP-пользовательские агенты/прокси) или между административными доменами SIP. IPsec работает для всех сигналов SIP UDP, TCP и SCTP. IPsec может использоваться для обеспечения аутентификации, целостности и конфиденциальности передаваемых данных и поддерживает сквозные, а также сценарии перехода по ходу. На данный момент нет стандартного набора шифров для IPsec, определенного в SIP. Обратите внимание, что RFC 3261 не описывает структуру для использования IPsec, и не требуется указывать, как должно выполняться управление ключами, или какой заголовок и режим IPsec должны использоваться. Одним из принятых протоколов для управления ключами является Internet Key Exchange (IKE), гибридный протокол на основе Ассоциации интернет-безопасности и протокола управления ключами (ISAKMP), Протокола определения ключа Oakley (RFC 2412) и Механизма обмена безопасными ключами для Интернета (SKEME). Протокол IKE обеспечивает автоматизированные механизмы обмена ключами и управления криптографическими ключами для IPsec. IKE используется для согласования ассоциаций безопасности (SA) для использования с собственными обменом управления ключами (так называемая Фаза 1) и для других служб, таких как IPsec (называемая Фазой 2). IKE особенно используется при создании VPN.
5.6 Улучшения безопасности для SIP
В настоящее время в рамках IETF обсуждаются несколько проектов, касающихся безопасности, с целью обеспечения общего решения безопасности для сценариев SIP. Было подготовлено несколько проектов, касающихся аутентификации, целостности и конфиденциальности для SIP. Этот список интернет-проектов не является полным, так как это постоянно развивающаяся область, но здесь рассматриваются наиболее важные проекты.
5.6.1 Подлинность аутентификации SIP
SIP Authenticated Identity Body (AIB) определяет общий токен аутентификации SIP. Маркер предоставляется путем добавления тела S/MIME к запросу или ответу SIP, чтобы обеспечить целостность ссылок над его заголовками. Документ определяет формат для этого тела сообщения, называемого аутентифицированным телом (AIB). Это сообщение SIP с цифровой подписью (sip/message) или фрагмент сообщения (sip/frag).
5.6.2 Требование S/MIME AES для SIP
RFC 3261 определяет 3DES как необходимый минимальный алгоритм шифрования для реализации S/MIME в SIP. Хотя 3DES по-прежнему является жизнеспособным алгоритмом, NIST выбрал улучшенный алгоритм AES в качестве замены DES и 3DES. Стандарт RFC 3853, требование S/MIME AES для SIP, обновляет нормативное руководство RFC 3261, чтобы потребовать AES для S/MIME. AES обеспечивает более высокую пропускную способность и меньшую вычислительную сложность, чем 3DES, и может быть реализована с низкими требованиями к памяти, что делает ее более подходящей для мобильных или встроенных устройств, включая телефоны VOIP.
5.6.3 Соглашение о механизме безопасности для SIP
SIP имеет ряд механизмов безопасности. Некоторые из них были встроены непосредственно в протокол SIP, например, HTTP-аутентификация. Эти механизмы имеют альтернативные алгоритмы и параметры. Идея исходит из проекта партнерства третьего поколения (3GPP), сотрудничества телекоммуникационных компаний и предоставляет механизм выбора механизмов безопасности для использования между двумя объектами. Сам RFC 3261 не предоставляет никаких вариантов соглашения о механизме. Более того, даже если для выполнения соглашения о механизме использовались некоторые механизмы, такие как OPTIONS, соглашение было бы уязвимым для атак Bidding-Down (тип атаки «человек по середине», когда злоумышленник маскирует сообщения, чтобы убедить стороны, что они поддерживают связь друг с другом). Три поля заголовка определены для согласования механизмов безопасности в SIP между объектом SIP User Agent и SIP сервером. Это предлагаемый стандарт (RFC 3329) от IETF. В настоящее время поддерживаются пять механизмов:
– TLS
– HTTP Digest
– IPsec с IKE
– IPsec с ручным ключом без IKE
– S/MIME
5.6.4 Проблемы безопасности SIP
Текстовое кодирование SIP упрощает анализ с использованием стандартных инструментов синтаксического анализа, таких как Perl или lex и yacc. Тем не менее, некоторые новые требования размещаются на брандмауэре в сети VOIP на основе SIP. Во-первых, брандмауэры должны быть с сохранением состояния и контролировать трафик SIP для определения того, какие порты RTP должны быть открыты и доступны для каких адресов. Эта ответственность похожа на задачи брандмауэры в сети на базе H.323, за исключением того, что настройка вызова и разбор заголовков намного проще. Другие проблемы SIP-basedс брандмауэрами связаны с трафиком RTP и входящими вызовами. Как и в случае с H.323, большой проблемой для SIP является NAT.
NAT запрещает механизмы регистрации и связи SIP и требует инновационных решений для решения этих проблем. Проблемы существуют, потому что в SIP-сети прокси-сервер SIP обычно находится за пределами устройства NAT. Существует три основных сценария использования прокси-сервера SIP:
– Прокси-сервер находится в корпоративной локальной сети, а подключение извне
– Прокси-сервер находится на стороне сотовой связи и клиенты, например, из небольших компаний, подключающихся к этому прокси для службы VOIP
– Два административных домена подключены, оба имеют свой собственный прокси.
Таким образом, проблема заключается в обмене информацией между прокси-сервером, который имеет дело с глобальными IP-адресами и машиной, которому был назначен выделенный сетевой адрес. В такой архитектуре SIP трафик можно классифицировать на три разных проблемы: отправляет запросы, получает запросы и обрабатывает RTP. Мы уже рассмотрели несовместимости RTP с NAT, и теперь мы увидим проблемы, которые NAT представляет сам процесс настройки вызова.
Чтобы инициализировать сеанс из-за NAT, вызывающий может просто отправить сообщение INVITE. Номер исходящего порта (5060) будет сохранен NAT, но ответное сообщение может быть нарушено. Если SIP реализован поверх UDP (вызов SIP является независимым от протокола), прокси-сервер должен отправить ответ UDP на адрес и порт, на который был отправлен запрос. Более простым решением является использование стандартной практики маршрутизации SIP-связи через TCP. С TCP ответ от вызываемого абонента будет поступать по тому же каналу, что и оригинал INVITE, и поэтому NAT не будет представлять проблемы.
Мы уже обсуждали некоторые проблемы с входящими соединениями VOIP с NAT. Теперь я подробно рассмотрю специфические проблемы SIP с входящими вызовами. Когда пользователь связывается с регистратором, они предоставляют свой IP-адрес в качестве своего доступного адреса, и он сохраняется на сервере местоположения. Однако это их серый IP-адрес. Прокси-сервер имеет дело только с глобальными IP-адресами, поэтому, когда приходит сообщение для username@domain.com, он попытается перенаправить этот вызов на зарегистрированный адрес, но в публичной сети. Например, если username@domain.com зарегистрирован на внутренний IP-адрес 10.7.34.189, тогда прокси-сервер попытается перенаправить трафик на этот адрес, но в публичную сеть. Этот адрес недоступен для прокси-сервера, и в соединении будет отказано. Решением этого является тонкое манипулирование IP-адресами и расширение обязанностей прокси-сервера SIP.
Межсетевые экраны и NAT представляют огромную проблему для разработчиков VOIP. Тем не менее, есть решения этих проблем, если вы готовы заплатить. Обычно используемые решения, которые могут быть интегрированы в стандартную сетевую инфраструктуру, содержащую межсетевой экран и/или NAT, представлены здесь. Большая часть работы по стандартам была проделана для SIP в IETF. Важно отметить, что все три основных протокола VOIP, SIP, H.323 и H.248/MEGACO имеют аналогичные проблемы с межсетевыми экранами и NAT. Несмотря на то, что использование NAT может быть уменьшено по мере принятия IPv6, они останутся общим компонентом в сетях на долгие годы, и IPv6 не уменьшит потребность в межсетевых экранах, таким образом, системы VOIP должны иметь дело со сложностями межсетевых экранов и NAT.