RFC 8445 | Установление интерактивного подключения (ICE): протокол для пересечений преобразователя сетевых адресов (NAT)

RFC 8445 | Установление интерактивного подключения (ICE): протокол для пересечений преобразователя сетевых адресов (NAT)

Аннотация

Этот документ описывает протокол для обхода сетевого адреса (NAT) для связи на основе UDP. Этот протокол называется установлением интерактивного подключения (ICE). ICE использует протокол Session Traversal Utilities for NAT (STUN) и его расширение, Traversal Using Relay NAT (TURN).
Скачать оригинальный документ на английском языке RFC 8445 PDF

Этот документ устарел RFC 5245.

 

Оглавление

1. Введение
2. Обзор ICE
2.1. Сбор кандидатов
2.2. Проверка подключения
2.3. Выдвижение кандидатов в пары и заключение ICE
2.4. ICE Перезапуск
2.5. Lite реализации
3. Использование ICE
4. Терминология
5. ICE Кандидатский сбор и обмен
5.1. Полная реализация
5.1.1. Сбор кандидатов
5.1.1.1. Принимающие кандидаты
5.1.1.2. Сервер-рефлексивные и ретранслированные кандидаты
5.1.1.3. Вычислительные фонды
5.1.1.4. Держать кандидатов живыми
5.1.2. Приоритетность кандидатов
5.1.2.1. Рекомендуемая формула
5.1.2.2. Рекомендации по выбору типа и локальных настроек
5.1.3. Устранение избыточных кандидатов
5.2. Процедуры реализации Lite
5.3. Обмен информацией о кандидатах
5.4. ICE Mismatch
6. Обработка кандидатов в ICE
6.1. Процедуры для полной реализации
6.1.1. Определение роли
6.1.2. Формирование контрольных списков
6.1.2.1. Контрольный список состояния
6.1.2.2. Формирование кандидатских пар
6.1.2.3. Вычислительные пары с приоритетом и порядок пар
6.1.2.4. Обрезка пар
6.1.2.5. Удаление пар с более низким приоритетом
6.1.2.6. Вычислительные состояния пары кандидатов
6.1.3. ICE State
6.1.4. Планирование проверок
6.1.4.1. Очередь с проверкой
6.1.4.2. Выполнение проверок подключения
6.2. Процедуры реализации Lite
7. Выполнение проверок подключения
7.1. Расширения STUN
7.1.1. PRIORITY — ПРИОРИТЕТ
7.1.2. USE-CANDIDATE — ИСПОЛЬЗОВАНИЕ-КАНДИДАТ
7.1.3. ICE-CONTROLLED and ICE-CONTROLLING — ICE-КОНТРОЛИРУЕМЫЙ и ICE-КОНТРОЛЛИРУЮЩИЙ
7.2. Процедуры клиента STUN
7.2.1. Создание разрешений для ретранслируемых кандидатов
7.2.2. Формирование учетных данных
7.2.3. Diffserv Лечение
7.2.4. Отправка запроса
7.2.5. Обработка ответа
7.2.5.1. Роль Конфликт
7.2.5.2. Недостаточность
7.2.5.2.1. Несимметричные транспортные адреса
7.2.5.2.2. Ошибка ICMP
7.2.5.2.3. Тайм-аут
7.2.5.2.4. Неустранимый ответ STUN
7.2.5.3. Успех
7.2.5.3.1. Обнаружение равнодушных кандидатов
7.2.5.3.2. Построение допустимой пары
7.2.5.3.3. Обновление состояний пары кандидатов
7.2.5.3.4. Обновление назначенного флага
7.2.5.4. Обновления состояния контрольного списка
7.3. Процедуры сервера STUN
7.3.1. Дополнительные процедуры для полной реализации
7.3.1.1. Обнаружение и устранение ролевых конфликтов
7.3.1.2. Вычисление сопоставленных адресов
7.3.1.3. Обучение сверстников-рефлексивных кандидатов
7.3.1.4. Триггерные проверки
7.3.1.5. Обновление назначенного флага
7.3.2. Дополнительные процедуры для реализации Lite
8. Заключительная обработка ICE
8.1. Процедуры для полной реализации
8.1.1. Номинация пар
8.1.2. Обновление контрольного списка и состояний ICE
8.2. Процедуры для Lite-реализаций
8.3. Кандидаты на освобождение
8.3.1. Процедуры полного внедрения
8.3.2. Процедуры реализации Lite
9. ICE Перезапускает
10. ICE Вариант
11. Keepalive
12. Обработка данных
12.1. Отправка данных
12.1.1. Процедуры для Lite-реализаций
12.2. Получение данных
13. Вопросы расширения
14. Настройка Ta и RTO
14.1. Генеральный
14.2. Ta
14.3. RTO
15. Примеры
15.1. Пример с адресами IPv4
15.2. Пример с адресами IPv6
16. Расширения STUN
16.1. Атрибуты
16.2. Новые коды ошибок и ответов
17. Операционные соображения
17.1. Типы NAT и межсетевого экрана
17.2. Требования к пропускной способности
17.2.1. STUN и TURN Планирование мощности сервера
17.2.2. Проверка сбора и подключения
17.2.3. Поддержка активность
17.3. ICE и ICE-Lite
17.4. Устранение неполадок и управление производительностью
17.5. Конфигурация конечной точки
18. Соображения IAB
18.1. Определение проблемы
18.2. Стратегия отступления
18.3. Хрупкость представленная ICE
18.4. Требования к долгосрочному решению
18.5. Проблемы с существующими блоками NAPT
19. Вопросы безопасности
19.1. Конфиденциальность IP-адреса
19.2. Атаки на проверки подключения
19.3. Атаки на сервер-рефлексивный сбор адресов
19.4. Атаки на ретранслируемый сбор кандидатов
19.5. Инсайдерские атаки
19.5.1. Усиление атаки STUN
20. Соображения IANA
20.1. Атрибуты STUN
20.2. Ответы на ошибки STUN
20.3. Варианты ICE
21. Отличия от RFC 5245
22. Ссылки
22.1. Нормативные ссылки
22.2. Информационные ссылки
Приложение А. Облегченная и полная реализация
Приложение В. Мотивация дизайна
B.1. Стимуляция транзакций STUN
В.2. Кандидаты с несколькими основаниями
В.3. Назначение атрибутов связанных адресов и связанных портов
В.4. Важность имени пользователя STUN
В.5. Формула приоритета пары кандидатов
В.6. Зачем нужны Keepalive?
В.7. Почему предпочитают рефлексивных кандидатов?
В.8. Почему обязательные показания используются для Keepalive?
В.9. Выбор типа кандидата
Приложение C. Проверка пропускной способности
Благодарности
Адреса авторов

 

Статус этой заметки

Это документ по отслеживанию стандартов Интернета.

Этот документ является продуктом Инженерной рабочей группы по Интернету (IETF). Он представляет собой консенсус сообщества IETF. Он получил общественную рецензию и был одобрен для публикации Руководящей группой по Интернет-разработкам (IESG). Дополнительная информация о Интернет-стандартах доступна в Разделе 2 RFC 7841.
Информацию о текущем состоянии этого документа, любых ошибках и способах предоставления отзывов о нем можно получить по адресу https://www.rfc-editor.org/info/rfc8445.

 

Уведомление об авторских правах

Авторское право (c) Траст IETF 2018 года и лица, указанные в качестве авторов документа. Все права защищены.

На данный документ распространяется действие ПП 78 и Правовые положения IETF Trust, относящиеся к документам IETF (https://trustee.ietf.org/license-info), действующие на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, так как они описывают ваши права и ограничения в отношении этого документа. Компоненты кода, извлеченные из этого документа, должны содержать текст Упрощенной лицензии BSD, как описано в Разделе 4.e Правил доверия, и предоставляются без гарантии, как описано в Упрощенной лицензии BSD.

Этот документ может содержать материалы из Документов IETF или Вкладов IETF, опубликованных или обнародованных до 10 ноября 2008 года. Лица, контролирующие авторские права на некоторые из этих материалов, возможно, не предоставили Трасту IETF право разрешать модификации таких материалов. вне процесса стандартизации IETF. Без получения адекватной лицензии от лица (лиц), контролирующих авторские права на такие материалы, этот документ не может быть изменен вне процесса стандартизации IETF, и его производные работы не могут быть созданы вне процесса стандартизации IETF, за исключением того, что он отформатирован для публикация в качестве RFC или перевод на другие языки, кроме английского.

 

1. Введение

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

Были определены многочисленные решения, позволяющие этим протоколам работать через NAT. К ним относятся шлюзы прикладного уровня (ALG), протокол управления Middlebox [RFC3303], исходная спецификация простого обхода UDP через NAT (STUN) [RFC3489] (обратите внимание, что RFC 3489 устарел в RFC 5389) и IP, специфичный для области [RFC3102] [RFC3103] вместе с расширениями описания сеанса, необходимыми для их работы, такими как атрибут протокола описания сеанса (SDP) [RFC4566] для протокола управления в реальном времени (RTCP) [RFC3605]. К сожалению, у всех этих методов есть свои плюсы и минусы, которые делают каждый из них оптимальным в некоторых топологиях сети, но неудачным выбором в других. В результате администраторы и разработчики делают предположения о топологии сетей, в которых будут развернуты их решения. Это привносит в систему сложность и хрупкость.

Эта спецификация определяет Интерактивное установление соединения (ICE) как метод обхода NAT для потоков данных на основе UDP (хотя ICE был расширен для обработки других транспортных протоколов, таких как TCP [RFC6544]). ICE работает, обмениваясь множеством IP-адресов и портов, которые затем проверяются на предмет подключения путем одноранговых проверок связности. IP-адреса и порты обмениваются с использованием механизмов, специфичных для использования ICE (например, в обмене предложением / ответом), а проверки соединения выполняются с использованием STUN [RFC5389]. ICE также использует Traversal Using Relay вокруг NAT (TURN) [RFC5766], расширение для STUN. Поскольку ICE обменивается множеством IP-адресов и портов для каждого потока мультимедиа, он также позволяет выбирать адреса для хостов с несколькими адресами и с двумя стеками. По этой причине в RFC 5245 [RFC5245] устарели решения, ранее определенные в RFC 4091 [RFC4091] и RFC 4092 [RFC4092].

Приложение B содержит справочную информацию и мотивы, касающиеся проектных решений, которые были приняты при разработке ICE.

 

2. Обзор ICE

В типичном развертывании ICE есть две конечные точки (агенты ICE), которые хотят общаться. Обратите внимание, что ICE не предназначен для прохождения NAT для протокола сигнализации, который, как предполагается, предоставляется через другой механизм. ICE предполагает, что агенты могут установить сигнальное соединение между собой.

Первоначально агенты не знают своих собственных топологий. В частности, агенты могут или не могут быть позади NAT (или нескольких уровней NAT). ICE позволяет агентам находить достаточно информации о своих топологиях, чтобы потенциально найти один или несколько путей, по которым они могут установить сеанс данных.

На рисунке 1 показано типичное развертывание ICE. Агенты обозначены как L и R. Оба L и R находятся за своими собственными NAT, хотя они могут не знать об этом. Тип NAT и его свойства также неизвестны. L и R способны участвовать в процессе обмена кандидатами, цель которого состоит в том, чтобы установить сеанс передачи данных между L и R. Обычно этот обмен будет происходить через сервер сигнализации (например, прокси-сервер SIP).

В дополнение к агентам, серверу сигнализации и NAT, ICE обычно используется совместно с серверами STUN или TURN в сети. Каждый агент может иметь свой собственный сервер STUN или TURN, или они могут быть одинаковыми.

Рисунок 1 - Сценарий развертывания ICE
Рисунок 1 — Сценарий развертывания ICE

Основная идея ICE заключается в следующем: каждый агент имеет множество транспортных адресов-кандидатов (комбинация IP-адреса и порта для конкретного транспортного протокола, который в данной спецификации всегда является UDP), который он может использовать для связи с другим агентом.

Они могут включать в себя:

  • Транспортный адрес на напрямую подключенном сетевом интерфейсе.
  • Переведенный транспортный адрес на общедоступной стороне NAT (адрес сервера)
  • Транспортный адрес, выделенный с сервера TURN («ретранслируемый адрес»)

Потенциально, любой из возможных транспортных адресов L может использоваться для связи с любым из возможных транспортных адресов R. Однако на практике многие комбинации не будут работать. Например, если L и R оба находятся за NAT, их напрямую подключенные адреса интерфейса вряд ли смогут напрямую обмениваться данными (именно поэтому ICE необходим, в конце концов!). Цель ICE — определить, какие пары адресов будут работать. Способ, которым ICE делает это, состоит в том, чтобы систематически пробовать все возможные пары (в тщательно отсортированном порядке), пока он не найдет одну или несколько таких работ.

 

2.1. Сбор кандидатов

Чтобы выполнить ICE, агент ICE идентифицирует и собирает одного или нескольких кандидатов в адреса. У кандидата есть транспортный адрес — комбинация IP-адреса и порта для определенного транспортного протокола (здесь указан только UDP). Есть разные типы кандидатов; некоторые получены из физических или логических сетевых интерфейсов, а другие могут быть обнаружены через STUN и TURN.

Первая категория кандидатов — это кандидаты с транспортным адресом, полученным непосредственно из локального интерфейса. Такой кандидат называется «принимающим кандидатом». Локальный интерфейс может быть Ethernet или Wi-Fi, или это может быть тот, который получен через механизм туннеля, такой как Виртуальная частная сеть (VPN) или Мобильный IP (MIP). Во всех случаях такой сетевой интерфейс представляется агенту как локальный интерфейс, из которого могут быть выделены порты (и, следовательно, кандидаты).

Затем агент использует STUN или TURN для получения дополнительных кандидатов. Они бывают двух видов: переведенные адреса на публичной стороне NAT (сервер-рефлексивные кандидаты) и адреса на серверах TURN (ретранслируемые кандидаты). Когда используются серверы TURN, оба типа кандидатов получают от сервера TURN. Если используются только серверы STUN, из них получаются только серверно-рефлексивные кандидаты. Отношение этих кандидатов к кандидату-хозяину показано на рисунке 2. На этом рисунке оба типа кандидатов обнаруживаются с помощью TURN. На рисунке обозначение X: x означает IP-адрес X и UDP-порт x.

Рисунок 2 - Кандидатские отношения
Рисунок 2 — Кандидатские отношения

Когда агент отправляет запрос TURN Allocate с IP-адреса и порта X: x, NAT (при условии, что он есть) создаст привязку X1 ’: x1’, сопоставляя этого серверно-рефлексивного кандидата с кандидатом на хост X: x. Исходящие пакеты, отправленные кандидатом в хост, будут преобразованы NAT в рефлексивного кандидата в сервер. Входящие пакеты, отправленные кандидату-рефлексивному серверу, будут преобразованы NAT для кандидата в хост и перенаправлены агенту. Хост-кандидат, связанный с данным серверно-рефлексивным кандидатом, является «базой».

Примечание. «База» относится к адресу, с которого агент отправляет конкретного кандидата. Таким образом, в вырожденном случае кандидаты-хозяева также имеют базу, но она такая же, как и кандидат-хозяин.

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

Затем запрос Allocate поступает на сервер TURN. Сервер TURN выделяет порт y из своего локального IP-адреса Y и генерирует ответ Allocate, информируя агента об этом ретранслированном кандидате. Сервер TURN также информирует агента о кандидате-рефлексивном сервере, X1 ’: x1’, путем копирования исходного транспортного адреса запроса Allocate в ответ Allocate. Сервер TURN действует как ретранслятор пакетов, пересылая трафик между L и R. Чтобы отправить трафик на L, R отправляет трафик на сервер TURN в точке Y: y, а сервер TURN перенаправляет его на X1 ‘: x1’, что проходит через NAT, где он сопоставлен с X: x и доставлен в L.

Когда используются только серверы STUN, агент отправляет запрос привязки STUN [RFC5389] на свой сервер STUN. Сервер STUN проинформирует агента о возможном сервере-рефлексивном кандидате X1 ’: x1’ путем копирования исходного транспортного адреса запроса Binding в ответ Binding.

 

2.2. Проверка подключения

Как только L собрал всех своих кандидатов, он упорядочивает их с наивысшим приоритетом и отправляет их в R по каналу сигнализации. Когда R получает кандидатов от L, он выполняет тот же процесс сбора и отвечает своим собственным списком кандидатов. В конце этого процесса у каждого агента ICE есть полный список как его кандидатов, так и кандидатов его сверстников. Он их объединяет, в результате чего получается пара кандидатов. Чтобы увидеть, какие пары работают, каждый агент планирует серию проверок подключения. Каждая проверка представляет собой транзакцию запроса / ответа STUN, которую клиент выполнит для конкретной пары кандидатов, отправив запрос STUN от локального кандидата удаленному кандидату.

Основной принцип проверки подключения прост:

  1. Сортируйте пары кандидатов в порядке приоритета.
  2. Отправьте чеки на каждую пару кандидатов в порядке приоритета.
  3. Подтвердите чеки, полученные от другого агента.

Когда оба агента выполняют проверку пары кандидатов, результатом является четырехстороннее рукопожатие:

Рисунок 3 - Базовая проверка подключения
Рисунок 3 — Базовая проверка подключения

Важно отметить, что запросы STUN отправляются на и с тех же IP-адресов и портов, которые будут использоваться для данных (например, RTP, RTCP или другие протоколы). Следовательно, агенты демультиплексируют STUN и данные, используя содержимое пакетов, а не порт, на котором они получены.

Поскольку для проверки соединения используется запрос привязки STUN, ответ привязки STUN будет содержать переведенный транспортный адрес агента на общедоступной стороне любых NAT между агентом и его партнером. Если этот транспортный адрес отличается от адреса других кандидатов, которых агент уже изучил, он представляет нового кандидата (равноправного кандидата), который затем проверяется ICE так же, как и любой другой кандидат.

Поскольку вышеприведенный алгоритм ищет все пары кандидатов, если рабочая пара существует, алгоритм в конечном итоге найдет ее независимо от того, в каком порядке пробуются кандидаты. Чтобы получить более быстрые (и лучшие) результаты, кандидаты сортируются в указанном порядке. , Результирующий список отсортированных пар кандидатов называется «контрольным списком».

Агент обрабатывает контрольный список, периодически отправляя запрос STUN для следующей пары кандидатов в списке. Это так называемые «обычные чеки». Когда транзакция STUN завершается успешно, одна или несколько пар-кандидатов станут так называемыми «действительными парами» и будут добавлены в список пар-кандидатов, называемый «действительным списком».

Как оптимизация, как только R получает сообщение проверки L, R планирует сообщение проверки соединения, которое будет отправлено L на той же паре кандидатов. Это называется «триггерной проверкой» и ускоряет процесс поиска допустимых пар.

В конце этого рукопожатия и L, и R знают, что они могут отправлять (и получать) сообщения от начала до конца в обоих направлениях.

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

Поток данных может состоять из нескольких компонентов (частей потока данных, которые требуют своего собственного набора кандидатов, например, RTP и RTCP).

 

2.3. Выдвижение кандидатов в пары и заключение ICE

ICE назначает одного из агентов ICE в роли контролирующего агента, а другого — в качестве контролируемого агента. Для каждого компонента потока данных управляющий агент назначает допустимую пару (из допустимого списка), которая будет использоваться для данных. Точные сроки выдвижения кандидатов основаны на местной политике.

При назначении контролирующий агент позволяет проверкам продолжаться до тех пор, пока не будет найдена хотя бы одна действительная пара для каждого компонента потока данных, а затем он выбирает допустимую пару и отправляет запрос STUN для этой пары, используя атрибут для указания контролируемой пэр, что это было назначено. Это показано на рисунке 4.

Рисунок 4 - Номинация
Рисунок 4 — Номинация

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

 

2.4. ICE Перезапуск

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

 

2.5. Lite реализации

Некоторые агенты ICE всегда будут подключены к общедоступному Интернету и имеют общедоступный IP-адрес, по которому он может получать пакеты от любого корреспондента. Чтобы облегчить этим устройствам поддержку ICE, ICE определяет специальный тип реализации, называемый «облегченным» (в отличие от обычной полной реализации). Облегченные агенты используют только кандидатов на хост и не генерируют проверки подключения или запускают конечные автоматы, хотя они должны иметь возможность отвечать на проверки подключения.

 

3. Использование ICE

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

Одним из механизмов, который позволяет агентам обмениваться информацией о кандидатах, является использование семантики предложения / ответа (основанной на [RFC3264]) как части протокола SIP [RFC3261] [ICE-SIP-SDP].

[RFC7825] определяет использование ICE для протокола потоковой передачи в реальном времени (RTSP). Обратите внимание, однако, что использование ICE основано на RFC 5245.

 

4. Терминология

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119], [RFC8174].

Читатели должны быть знакомы с терминологией, определенной в [RFC5389], и требованиями к поведению NAT для UDP [RFC4787].

Эта спецификация использует следующую дополнительную терминологию:

Сессия ICE: Сессия ICE состоит из всех связанных с ICE действий, начиная с сбора кандидатов, после чего следует взаимодействие (обмен кандидатами, проверки подключения, назначения и сообщения поддержки активности) между агентами ICE до тех пор, пока все кандидаты не будут освобождены или перезапуск ICE не завершится. срабатывает.

Агент ICE, Агент: Агент ICE (иногда его просто называют «агентом») — это реализация протокола, участвующая в обмене кандидатами ICE. В типичном обмене кандидатами участвуют два агента.

Инициирующий узел, Инициирующий агент, Инициатор: Инициирующий агент — это агент ICE, который инициирует процесс обмена кандидатами ICE.

Отвечающий одноранговый узел, отвечающий агент, отвечающий: отвечающий агент — это агент ICE, который получает и отвечает на процесс обмена кандидатами, инициированный инициирующим агентом.

Обмен кандидатами ICE, Обмен кандидатами. Процесс, в котором агенты ICE обмениваются информацией (например, кандидатами и паролями), необходимой для выполнения ICE. Предложение / ответ с кодированием SDP [RFC3264] является одним из примеров протокола, который можно использовать для обмена информацией о кандидатах.

Узел: с точки зрения одного из агентов ICE в сеансе, его узел является другим агентом. В частности, с точки зрения инициирующего агента, партнер является отвечающим агентом. С точки зрения отвечающего агента, партнер является инициирующим агентом.

Транспортный адрес: комбинация IP-адреса и порта транспортного протокола (такого как UDP или TCP).

Данные, поток данных, сеанс данных. Когда ICE используется для настройки сеансов данных, данные транспортируются с использованием некоторого протокола. Медиа обычно передаются по RTP, состоящему из потока пакетов RTP. Сеанс данных относится к пакетам данных, которыми обмениваются одноранговый узел на пути, созданном и протестированном с помощью ICE.

Информация о кандидате, кандидате: Транспортный адрес, который является потенциальной точкой контакта для получения данных. Кандидаты также имеют свойства — их тип (серверный, ретранслируемый или хост), приоритет, основание и база.

Компонент: компонент является частью потока данных. Поток данных может потребовать нескольких компонентов, каждый из которых должен работать для того, чтобы поток данных в целом работал. Для потоков данных RTP / RTCP, если RTP и RTCP не мультиплексируются в одном и том же порту, в каждом потоке данных есть два компонента — один для RTP и один для RTCP. Компонент имеет пару кандидатов, которая не может использоваться другими компонентами.

Кандидат в хост: кандидат, полученный путем привязки к определенному порту с IP-адреса хоста. Это включает в себя IP-адреса на физических интерфейсах и логические, например, полученные через VPN.

Server-Reflexive Candidate: кандидат, чей IP-адрес и порт являются связыванием, назначенным NAT для агента ICE после того, как он отправит пакет через NAT на сервер, такой как сервер STUN.

Peer-Reflexive Candidate: кандидат, чей IP-адрес и порт являются связыванием, назначенным NAT для агента ICE после того, как он отправляет пакет через NAT своему партнеру.

Relayed Candidate: кандидат, полученный от сервера ретрансляции, такого как сервер TURN.

База: Транспортный адрес, с которого агент ICE отправляет конкретного кандидата. Для кандидатов на хост, сервер-рефлексив и peerreflexive база совпадает с кандидатом на хост. Для ретранслируемых кандидатов база совпадает с ретранслируемым кандидатом (то есть, транспортный адрес, используемый сервером TURN для отправки с).

Связанный адрес и порт: транспортный адрес, связанный с кандидатом, который полезен для диагностики и других целей. Если кандидат является рефлексивным сервером или одноранговым узлом, связанный адрес и порт равняется основанию для этого сервера или однорангового рефлексивного кандидата. Если кандидат ретранслируется, связанный адрес и порт равны отображенному адресу в ответе Allocate, который предоставил клиенту этот ретранслируемый кандидат. Если кандидат является кандидатом на хост, соответствующий адрес и порт идентичны кандидату на хост.

Основание: произвольная строка, используемая в алгоритме замораживания для группировки похожих кандидатов. Он одинаков для двух кандидатов, имеющих одинаковый тип, базовый IP-адрес, протокол (UDP, TCP и т. д.) И сервер STUN или TURN. Если что-то из этого будет другим, то фундамент будет другим.

Местный кандидат: кандидат, которого агент ICE получил и может отправить своему коллеге.

Удаленный кандидат: кандидат, которого агент ICE получил от своего партнера.

Назначение по умолчанию / Кандидат: назначением по умолчанию для компонента потока данных является транспортный адрес, который будет использоваться агентом ICE, который не знает ICE. Кандидатом по умолчанию для компонента является тот, транспортный адрес которого соответствует назначению по умолчанию для этого компонента.

Пара кандидатов: пара, содержащая местного кандидата и удаленного кандидата.

Проверка, проверка подключения, проверка STUN: запрос привязки STUN для проверки возможности подключения. Проверка отправляется из базы локального кандидата удаленному кандидату пары кандидатов.

Контрольный список: упорядоченный набор пар кандидатов, которые агент ICE будет использовать для создания проверок.

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

Триггерная проверка: проверка подключения, созданная в результате получения проверки подключения от однорангового узла.

Допустимая пара: пара кандидатов, чей локальный кандидат равен сопоставленному адресу успешного ответа проверки подключения, а удаленный кандидат равен адресу назначения, на который был отправлен запрос проверки подключения.

Действительный список: упорядоченный набор пар кандидатов для потока данных, которые были подтверждены успешной транзакцией STUN.

Набор контрольных списков: упорядоченный список всех контрольных списков. Порядок определяется каждым использованием ICE.

Полная реализация: реализация ICE, которая выполняет полный набор функций, определенных в этой спецификации.

Реализация Lite (Lite Implementation): реализация ICE, в которой пропущены определенные функции, реализующая только столько, сколько необходимо для однорангового узла, который не является реализацией lite, чтобы получить преимущества ICE. Реализации Lite не поддерживают ни один из конечных автоматов и не генерируют проверки подключения.

Контролирующий агент (Controlling Agent): Агент ICE, который назначает пару кандидатов. В любом сеансе всегда есть один контролирующий агент и один контролируемый агент.

Контролируемый агент (Controlled Agent): Агент ICE, ожидающий, когда контролирующий агент назначит пару кандидатов.

Назначение (Nomination): Процесс контролирующего агента, указывающий контролируемому агенту, какую пару кандидатов будут использовать агенты ICE для отправки и получения данных. Процесс номинации, определенный в этой спецификации, упоминался как «регулярная номинация» в RFC 5245. Процесс номинации, который упоминался как «агрессивная номинация» в RFC 5245, в данной спецификации не рекомендуется.

Номинированный, назначенный флаг (Nominated, Nominated Flag): После успешного назначения пары кандидатов, пара кандидатов становится назначенной, и значение ее назначенного флага устанавливается равным true.

Выбранная пара, выбранная пара кандидатов (Selected Pair, Selected Candidate Pair): пара кандидатов, используемая для отправки и получения данных для компонента потока данных, называется «выбранной парой». Перед созданием выбранных пар для потока данных любая действительная пара, связанная с компонентом потока данных, может использоваться для отправки и приема данных для компонента. Как только есть назначенные пары для каждого компонента потока данных, назначенные пары становятся выбранными парами для потока данных. Кандидаты, связанные с выбранными парами, называются «выбранными кандидатами».

Использование протокола, ICE Использование: протокол, который использует ICE для прохождения NAT. Спецификация использования определяет специфичные для протокола подробности того, как определенные здесь процедуры применяются к этому протоколу.

Timer Ta: таймер для генерации новых транзакций STUN или TURN.

Таймер RTO (Тайм-аут повторной передачи): таймер повторной передачи для данной транзакции STUN или TURN.

 

5. ICE Кандидатский сбор и обмен

Как часть обработки ICE, как инициирующие, так и отвечающие агенты собирают кандидатов, расставляют приоритеты и исключают избыточных кандидатов и обмениваются информацией о кандидатах с одноранговым узлом, как определено протоколом использования (использование ICE). Специфика механизма кодирования кандидата и семантика обмена информацией о кандидате выходит за рамки данной спецификации.

 

5.1. Полная реализация

5.1.1. Сбор кандидатов

Агент ICE собирает кандидатов, когда считает, что общение неизбежно. Инициирующий агент может сделать это на основе сигнала интерфейса пользователя или явного запроса на инициирование сеанса. У каждого кандидата есть транспортный адрес. Он также имеет тип и базу. Четыре типа определены и собраны этой спецификацией — кандидаты в хосты, серверно-рефлексивные кандидаты, однорангово-рефлексивные кандидаты и ретранслированные кандидаты. Рефлексивные серверные кандидаты собираются с использованием STUN или TURN, а ретранслированные кандидаты — через TURN. Рефлексивные кандидаты получены на более поздних этапах ICE, как следствие проверок подключения.

Процесс сбора кандидатов в отвечающем агенте идентичен процессу для инициирующего агента. РЕКОМЕНДУЕТСЯ, чтобы отвечающий агент начинал этот процесс сразу же после получения информации о кандидате, прежде чем предупреждать пользователя о приложении, связанном с сеансом ICE.

 

5.1.1.1. Принимающие кандидаты

Кандидаты в хосты получают путем привязки к портам на IP-адресе, подключенном к интерфейсу (физическому или виртуальному, включая интерфейсы VPN) на хосте.

Для каждого компонента каждого потока данных, который агент ICE желает использовать, агент ДОЛЖЕН получить кандидата на каждый IP-адрес, который имеет хост, с исключениями, перечисленными ниже. Агент получает каждого кандидата путем привязки к UDP-порту на конкретном IP-адресе. Кандидат в хост (и, действительно, каждый кандидат) всегда связан с конкретным компонентом, для которого он является кандидатом.

Каждому компоненту назначен идентификатор, называемый «идентификатор компонента». Для потоков данных RTP / RTCP, если только RTP и RTCP не мультиплексируются в одном и том же порту UDP (мультиплексирование RTP / RTCP), сам RTP имеет идентификатор компонента 1, а RTCP имеет идентификатор компонента 2. В случае RTP / Мультиплексирование RTCP, идентификатор компонента 1 используется как для RTP, так и для RTCP.

Когда кандидаты получены, если агент не знает наверняка, что будет использоваться мультиплексирование RTP / RTCP (т.е. агент знает, что другой агент также поддерживает и готов использовать мультиплексирование RTP / RTCP), или если агент только поддерживает При мультиплексировании RTP / RTCP агент ДОЛЖЕН получить отдельного кандидата на RTCP. Если агент получил кандидата на RTCP и в конечном итоге использует мультиплексирование RTP / RTCP, агенту не нужно выполнять проверки подключения на кандидате RTCP. Отсутствие идентификатора компонента 2 как такового не подразумевает использование мультиплексирования RTCP / RTP, поскольку это также может означать, что RTCP не используется.

Если агент использует отдельных кандидатов для RTP и RTCP, он будет иметь 2 * K кандидатов на хост, если агент имеет K IP-адресов.

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

Использование нескольких компонентов, кроме потоков RTP / RTCP, не рекомендуется, так как это увеличивает сложность обработки ICE. Если требуется несколько компонентов, идентификаторы компонентов ДОЛЖНЫ начинаться с 1 и увеличиваться на 1 для каждого компонента.

Основой для каждого кандидата в хост является сам кандидат.

Кандидаты в хосты собираются со всех IP-адресов со следующими исключениями:

  • Адреса из петлевого интерфейса НЕ ДОЛЖНЫ быть включены в адреса-кандидаты.
  • Устаревшие IPv4-совместимые адреса IPv6 [RFC4291] и локальные одноадресные адреса IPv6 site [RFC3879] НЕ ДОЛЖНЫ быть включены в список адресов-кандидатов.
  • IPv4-сопоставленные IPv6-адреса НЕ СЛЕДУЕТ включать в список адресов-кандидатов, если только приложение, использующее ICE, не поддерживает IPv4 (т.е. это приложение только для IPv6 [RFC4038]).
  • При сборе одного или нескольких кандидатов на хост, которые соответствуют адресу IPv6, который был создан с использованием механизма, который предотвращает отслеживание местоположения [RFC7721], кандидаты на хост, которые соответствуют адресам IPv6, которые позволяют отслеживать местоположение, настраиваются на одном интерфейсе и часть одного и того же сетевого префикса НЕ ДОЛЖНА собираться. Точно так же, когда собраны кандидаты хоста, соответствующие адресу IPv6, сгенерированному с использованием механизма, который предотвращает отслеживание местоположения, тогда НЕ ДОЛЖНЫ быть собраны кандидаты хоста, соответствующие локальным адресам IPv6 [RFC4291].

Спецификация выбора адреса IPv6 по умолчанию [RFC6724] указывает, что временные адреса [RFC4941] должны быть предпочтительнее постоянных адресов.

5.1.1.2. Сервер-рефлексивные и ретранслированные кандидаты

Агент ICE ДОЛЖЕН собирать серверных и ретранслируемых кандидатов. Однако использование серверов STUN и TURN в некоторых сетях может быть ненужным, а использование серверов TURN может быть дорогостоящим, поэтому некоторые развертывания могут отказаться от их использования. Если агент не собирает серверных или ретранслируемых кандидатов, РЕКОМЕНДУЕТСЯ, чтобы эта функция была реализована и просто отключена через конфигурацию, чтобы ее можно было повторно включить через конфигурацию, если условия изменятся в будущем.

Агент соединяет каждого кандидата в хост с серверами STUN или TURN, с которыми он настроен или обнаружен каким-либо образом. РЕКОМЕНДУЕТСЯ, чтобы доменное имя было настроено, процедуры DNS в [RFC5389] (с использованием записей SRV со службой «оглушение») использовались для обнаружения сервера STUN, а процедуры DNS в [RFC5766] (с использованием записей SRV с услуга «очередь») используется для обнаружения сервера TURN.

Когда доступно несколько серверов STUN или TURN (или когда они изучены с помощью записей DNS и возвращены несколько результатов), агент МОЖЕТ собрать кандидатов для всех из них и ДОЛЖЕН собрать кандидатов по крайней мере для одного из них (один сервер STUN и один TURN сервер). Это достигается путем соединения кандидатов на хост с серверами STUN или TURN, и для каждой пары агент отправляет запрос Binding или Allocate на сервер от кандидата на хост. Запросы на привязку к серверу STUN не проходят проверку подлинности, и любой атрибут ALTERNATE-SERVER в ответе игнорируется. Агенты ДОЛЖНЫ поддерживать режим обратной совместимости для запроса привязки, определенного в [RFC5389]. Запросы на распределение ДОЛЖНЫ быть аутентифицированы с использованием долгосрочных учетных данных, полученных клиентом другими способами.

Процесс сбора контролируется с помощью таймера Ta. Каждый раз, когда истекает Ta, агент может генерировать еще одну новую транзакцию STUN или TURN. Эта транзакция может быть либо повтором предыдущей транзакции, которая завершилась неудачей с исправимой ошибкой (такой как ошибка аутентификации), либо транзакцией для нового кандидата на хост и пары серверов STUN или TURN. Агент НЕ СЛЕДУЕТ генерировать транзакции чаще, чем один раз за каждый срок действия. См. Раздел 14 для получения инструкций о том, как установить Ta и таймер повторной передачи STUN, RTO.

Агент получит ответ Binding или Allocate. Успешный ответ Allocate предоставит агенту сервер-рефлексивный кандидат (полученный из сопоставленного адреса) и ретранслируемый кандидат в атрибуте XOR-RELAYED-ADDRESS. Если запрос Allocate отклонен, поскольку серверу не хватает ресурсов для его выполнения, агент ДОЛЖЕН отправить запрос Binding для получения серверно-рефлексивного кандидата. Ответ Binding предоставит агенту только сервер-рефлексивный кандидат (также полученный из сопоставленного адреса). Основой сервер-рефлексивного кандидата является кандидат хоста, с которого был отправлен запрос Allocate или Binding. Основой ретранслируемого кандидата является сам этот кандидат. Если ретранслируемый кандидат идентичен хост-кандидату (что может случиться в редких случаях), ретранслируемый кандидат ДОЛЖЕН быть отброшен.

Если агент, использующий только IPv6, находится в сети, использующей технологии NAT64 [RFC6146] и DNS64 [RFC6147], он также может собирать и возвращать кандидатов на сервер IPv4 и / или ретранслировать их с серверов STUN или TURN только для IPv4. Агенты только для IPv6 ДОЛЖНЫ также использовать обнаружение префикса IPv6 [RFC7050], чтобы обнаружить префикс IPv6, используемый NAT64 (если есть), и сгенерировать рефлексивных кандидатов на сервер для каждого интерфейса только для IPv6, соответственно. Отражающие серверы-кандидаты NAT64 располагаются по приоритетам, как серверно-рефлексивные кандидаты IPv4.

 

5.1.1.3. Вычислительные фонды

Агент ICE назначает каждому кандидату основание. Два кандидата имеют одинаковую основу, когда выполняются все следующие условия:

  • Они имеют один и тот же тип (хост, ретранслятор, сервер рефлексивный или одноранговый рефлексивный).
  • Их базы имеют одинаковый IP-адрес (порты могут быть разными).
  • Для рефлексивных и ретранслируемых кандидатов серверы STUN или TURN, используемые для их получения, имеют один и тот же IP-адрес (IP-адрес, используемый агентом для связи с сервером STUN или TURN).
  • Они были получены с использованием одного и того же транспортного протокола (TCP, UDP).

Аналогично, два кандидата имеют разные основания, если их типы различны, их базы имеют разные IP-адреса, серверы STUN или TURN, используемые для их получения, имеют разные IP-адреса (IP-адреса, используемые агентом для связи с сервером STUN или TURN), или их транспортные протоколы разные.

5.1.1.4. Держать кандидатов живыми

Как только сервер-рефлексивный и ретранслированный кандидаты распределены, они ДОЛЖНЫ поддерживаться в рабочем состоянии до завершения обработки ICE, как описано в разделе 8.3. Для серверно-рефлексивных кандидатов, изученных с помощью запроса Binding, привязки ДОЛЖНЫ поддерживаться дополнительными запросами Binding к серверу. Обновления для распределений выполняются с использованием транзакции Refresh, как описано в [RFC5766]. Запросы на обновление также обновят сервер-рефлексивный кандидат.

Принимающие кандидаты не истекают, но адреса кандидатов могут измениться или исчезнуть по ряду причин. Агент ICE ДОЛЖЕН контролировать используемые им интерфейсы, делать недействительными кандидатов, база которых исчезла, и по мере необходимости получать новых кандидатов, когда появляются новые IP-адреса (на новых или используемых в настоящее время интерфейсах).

 

5.1.2. Приоритетность кандидатов

Процесс расстановки приоритетов приводит к назначению приоритета каждому кандидату. Каждый кандидат на поток данных ДОЛЖЕН иметь уникальный приоритет, который ДОЛЖЕН быть положительным целым числом от 1 до (2 ** 31 — 1). Этот приоритет будет использоваться ICE для определения порядка проверок подключения и относительного предпочтения кандидатов. Значения с более высоким приоритетом дают больший приоритет перед более низкими значениями.

Агент ICE ДОЛЖЕН вычислить этот приоритет, используя формулу в разделе 5.1.2.1, и выбрать его параметры, используя рекомендации в разделе 5.1.2.2. Если агент решает использовать другую формулу, ICE может потребоваться больше времени для сближения, поскольку агенты не будут координироваться в своих проверках.

Процесс расстановки приоритетов кандидатов является общим для инициирующего и отвечающего агентов.

Рекомендуемая формула объединяет предпочтения для типа кандидата (рефлексивный сервер, одноранговый рефлексивный, ретранслируемый и хост), предпочтение для IP-адреса, для которого был получен кандидат, и идентификатор компонента с использованием следующей формулы:

priority = (2^24)*(type preference) + (2^8)*(local preference) + (2^0)*(256 — component ID)

Предпочтение типа ДОЛЖНО быть целым числом от 0 (наименьшее предпочтение) до 126 (наивысшее предпочтение) включительно, ДОЛЖНО быть одинаковым для всех кандидатов одного и того же типа и ДОЛЖНО быть различным для кандидатов разных типов. Предпочтения типа для одноранговых рефлексивных кандидатов ДОЛЖНЫ быть выше, чем для рефлексивных кандидатов на сервер. Установка значения в 0 означает, что кандидаты этого типа будут использоваться только в качестве крайней меры. Обратите внимание, что кандидаты, собранные в соответствии с процедурами, изложенными в разделе 5.1.1, никогда не будут рефлексивными кандидатами; кандидаты этого типа изучаются из проверок подключения, выполняемых ICE.

Локальное предпочтение ДОЛЖНО быть целым числом от 0 (наименьшее предпочтение) до 65535 (наивысшее предпочтение) включительно. Когда существует только один IP-адрес, это значение ДОЛЖНО быть установлено равным 65535. Если имеется несколько кандидатов для конкретного компонента для конкретного потока данных, имеющих одинаковый тип, локальное предпочтение ДОЛЖНО быть уникальным для каждого. Если агент ICE является двойным стеком, локальные предпочтения ДОЛЖНЫ быть установлены в соответствии с текущей наилучшей практикой, описанной в [RFC8421].

Идентификатор компонента ДОЛЖЕН быть целым числом от 1 до 256 включительно.

5.1.2.2. Рекомендации по выбору типа и локальных настроек

РЕКОМЕНДУЕМЫЕ значения для предпочтений типа: 126 для кандидатов на хост, 110 для одноранговых рефлексивных кандидатов, 100 для серверных рефлексивных кандидатов и 0 для ретранслируемых кандидатов.

Если агент ICE является многосетевым и имеет несколько IP-адресов, СЛЕДУЕТ следовать рекомендациям в [RFC8421]. Если используется несколько серверов TURN, локальные приоритеты для кандидатов, полученных от серверов TURN, выбираются аналогичным образом, как и для многосетевых локальных кандидатов: значение локального предпочтения используется для указания предпочтения среди разных серверов, но предпочтение ДОЛЖНО быть уникальным для каждый.

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

 

5.1.3. Устранение избыточных кандидатов

Затем агенты ICE (инициирующие и отвечающие) исключают избыточных кандидатов. Два кандидата могут иметь один и тот же транспортный адрес, но разные базы, и они не будут считаться избыточными. Часто рефлексивный кандидат на сервер и хост-кандидат будут избыточными, если агент не находится за NAT. Кандидат является избыточным, если и только если его транспортный адрес и база совпадают с адресами другого кандидата. Агент ДОЛЖЕН устранить избыточного кандидата с более низким приоритетом.

 

5.2. Процедуры реализации Lite

В реализациях Lite используются только кандидаты в хосты. Для каждого IP-адреса, независимо от семейства IP-адресов, ДОЛЖЕН быть ноль или один кандидат. С облегченной реализацией ICE не может использоваться для динамического выбора среди кандидатов. Поэтому включение нескольких кандидатов из определенного семейства IP-адресов НЕ РЕКОМЕНДУЕТСЯ, так как только проверка соединения может действительно определить, использовать ли один адрес или другой. Вместо этого РЕКОМЕНДУЕТСЯ, чтобы агенты, имеющие несколько общедоступных IP-адресов, выполняли полную реализацию ICE, чтобы обеспечить наилучшее использование своих адресов.

Каждому компоненту назначен идентификатор, называемый «идентификатор компонента». Для потоков данных RTP / RTCP, если RTCP не мультиплексируется в одном и том же порту с RTP, сам RTP имеет ID компонента 1, а RTCP ID компонента 2. Если агент использует RTCP без мультиплексирования, он ДОЛЖЕН получить кандидатов на него , Однако отсутствие идентификатора компонента 2 как такового не подразумевает использование мультиплексирования RTCP / RTP, поскольку это также может означать, что RTCP не используется.

Каждому кандидату назначается фонд. Основание ДОЛЖНО быть различным для двух кандидатов, назначенных с разных IP-адресов; в противном случае он ДОЛЖЕН быть тем же самым. Достаточно простого целого числа, которое увеличивается для каждого IP-адреса. Кроме того, каждому кандидату ДОЛЖЕН быть присвоен уникальный приоритет среди всех кандидатов для одного и того же потока данных. Если формула в разделе 5.1.2.1 используется для вычисления приоритета, значение предпочтения типа ДОЛЖНО быть установлено на 126. Если хост является только IPv4, локальное значение предпочтения ДОЛЖНО быть установлено на 65535. Если хост — это IPv6 или двойной стек локальное значение предпочтения ДОЛЖНО быть установлено на значение приоритета для IP-адресов, описанных в RFC 6724 [RFC6724].

Затем агент выбирает кандидата по умолчанию для каждого компонента каждого потока данных. Если хост использует только IPv4, для каждого компонента каждого потока данных будет только один кандидат; следовательно, этот кандидат используется по умолчанию. Если хост использует только IPv6, кандидатом по умолчанию обычно будет глобальный IPv6-адрес. Хостам с двумя стеками СЛЕДУЕТ разрешать настройку, независимо от того, используется ли IPv4 или IPv6 в качестве кандидата по умолчанию, и конфигурация должна основываться на том, какой из его администраторов считает, что у него больше шансов на успех в текущей сетевой среде.

Процедуры в этом разделе являются общими для инициирующих и отвечающих агентов.

 

5.3. Обмен информацией о кандидатах

Агенты ICE (инициирующие и отвечающие) нуждаются в следующей информации о кандидатах для обмена. Каждое использование ICE ДОЛЖНО определять способ обмена информацией с использованием протокола. В этом разделе описывается информация, которой необходимо обмениваться.

Кандидаты (Candidates): один или несколько кандидатов. Для каждого кандидата:

  • Адрес: IP-адрес и порт транспортного протокола кандидата.
  • Транспорт: Транспортный протокол кандидата. Это МОЖЕТ быть опущено, если используемый протокол работает только по одному транспортному протоколу.
    Основание: последовательность до 32 символов.
  • Идентификатор компонента: идентификатор компонента кандидата. Это МОЖЕТ быть опущено, если протокол использования не использует концепцию компонентов.
  • Приоритет: 32-битный приоритет кандидата.
  • Тип: тип кандидата.
  • Связанный адрес и порт: связанный IP-адрес и порт кандидата. Они МОГУТ быть опущены или установлены на недопустимые значения, если агент не хочет их раскрывать, например, по соображениям конфиденциальности.
  • Параметры расширяемости: протокол использования может определять средства для добавления новых параметров ICE для каждого кандидата в будущем.

Облегченный или полный (Lite or Full): является ли агент облегченным или полным агентом.

Значение синхронизации проверки подключения (Connectivity-Check Pacing Value): значение синхронизации для проверок подключения, которые агент желает использовать. Это МОЖЕТ быть опущено, если агент желает использовать определенное значение по умолчанию.

Фрагмент имени пользователя и пароль (Username Fragment and Password): значения, используемые для проверки подключения. Значения ДОЛЖНЫ быть неосуществимыми: по меньшей мере 128 битов выходного сигнала генератора случайных чисел используются для генерации пароля и по меньшей мере 24 битного вывода для генерации фрагмента имени пользователя.

Расширения (Extensions): Новые атрибуты медиапотока или сеанса (опции ICE).

Если используемый протокол уязвим и способен обнаруживать несоответствие ICE (раздел 5.4), то агенту-обнаружителю необходим способ передать эту информацию своему партнеру. Это логический флаг.

Протокол использования может (или не может) иметь дело с обратной совместимостью со старыми реализациями, которые не поддерживают ICE. Если механизм возврата к не-ICE поддерживается и используется, то, по-видимому, протокол использования обеспечивает способ передачи кандидата по умолчанию (его IP-адрес и порт) в дополнение к параметрам ICE.

Как только агент отправил информацию о своем кандидате, он ДОЛЖЕН быть готов к приему как STUN, так и пакетов данных по каждому кандидату. Как обсуждалось в разделе 12.1, пакеты данных могут быть отправлены кандидату до его появления в качестве места назначения по умолчанию для данных.

5.4. ICE несовнадение

Определенные промежуточные блоки, такие как ALG, могут изменять информацию сигнализации способами, которые нарушают ICE (например, путем перезаписи IP-адресов в SDP). Это называется «несоответствие ДВС». Если используемый протокол уязвим для несоответствия ICE, отвечающий агент должен иметь возможность обнаружить его и сообщить равноправному агенту ICE о несоответствии ICE.

Каждый использующий протокол должен определить, уязвим ли используемый протокол для несоответствия ICE, как обнаружено несоответствие ICE и нужно ли предпринимать конкретные действия при обнаружении несоответствия ICE.

 

6. Обработка кандидатов в ICE

Как только агент ICE собрал своих кандидатов и обменялся кандидатами со своим коллегой (Раздел 5), он определит свою собственную роль. Кроме того, полные реализации сформируют контрольные списки и начнут выполнять проверки соединения с партнером.

6.1. Процедуры для полной реализации

6.1.1. Определение роли

Для каждого сеанса каждый агент ICE (инициирующий и отвечающий) берет на себя роль. Есть две роли — контролирующая и контролируемая. Контролирующий агент отвечает за выбор пар окончательных кандидатов, используемых для связи. В следующих разделах подробно описываются фактические процедуры, которым следуют контролирующие и контролируемые агенты.

Правила определения роли и влияния на поведение следующие:

  • Оба агента заполнены: инициирующий агент, который начал обработку ICE, ДОЛЖЕН взять на себя контролирующую роль, а другой ДОЛЖЕН занять контролируемую роль. Оба агента будут формировать контрольные списки, запускать конечные автоматы ICE и генерировать проверки подключения. Контролирующий агент выполнит логику в Разделе 8.1, чтобы назначить пары, которые станут (если проверки связности, связанные с назначениями, пройдут успешно) выбранными парами, а затем оба агента завершат ICE, как описано в Разделе 8.1.2.
  • Один агент заполнен, один lite: полный агент ДОЛЖЕН выполнять контролирующую роль, а облегченный агент ОБЯЗАН выполнять контролируемую роль. Полный агент формирует контрольные списки, запускает конечные автоматы ICE и генерирует проверки подключения. Этот агент будет выполнять логику в Разделе 8.1, чтобы назначать пары, которые станут (если проверки связности, связанные с назначениями, пройдут успешно) выбранными парами, и использовать логику в Разделе 8.1.2 для завершения ICE. Реализация lite будет просто прослушивать проверки подключения, получать их и отвечать на них, а затем завершать ICE, как описано в разделе 8.2. Для облегченной реализации состояние обработки ICE для каждого потока данных считается работающим, а общее состояние ICE — работающим.
  • Обе версии lite: Инициирующий агент, который запустил обработку ICE, ДОЛЖЕН взять на себя контролирующую роль, а другой ДОЛЖЕН взять контролируемую роль В этом случае никакие проверки соединения никогда не отправляются. Скорее, после обмена кандидатами каждый агент выполняет обработку, описанную в разделе 8, без проверок подключения. Возможно, что оба агента будут верить, что они контролируются или контролируются. В последнем случае конфликт разрешается с помощью возможностей обнаружения бликов в протоколе сигнализации, обеспечивающих обмен кандидатами. Состояние обработки ICE для каждого потока данных считается работающим, а общее состояние ICE — работающим.

Как только роли определены для сеанса, они сохраняются в течение всего сеанса. Роли могут быть переопределены как часть перезапуска ICE (раздел 9), но агент ICE НЕ ДОЛЖЕН переопределять роль как часть перезапуска ICE, если не выполняется один или несколько из следующих критериев:

  • Full становится lite: если управляющий агент заполнен и переключается на lite, роли ДОЛЖНЫ быть переопределены, если равноправный агент также заполнен.
  • Конфликт ролей: если перезапуск ICE вызывает конфликт ролей, роли могут быть переопределены из-за процедур конфликта ролей, описанных в разделе 7.3.1.1.

ПРИМЕЧАНИЕ. Существуют определенные сценарии управления вызовами сторонних производителей (3PCC) [RFC3725], в которых перезапуск ICE может вызвать конфликт ролей.

ПРИМЕЧАНИЕ. Агенты должны информировать друг друга о том, заполнены они или нет, прежде чем будут определены роли. Механизм для этого специфичен для протокола сигнализации и выходит за рамки документа.

Агент ДОЛЖЕН принять, если одноранговый узел инициирует переопределение ролей, даже если критерии для этого не выполнены. Это может произойти, если узел соответствует RFC 5245.

6.1.2. Формирование контрольных списков

Существует один контрольный список для каждого потока данных. Чтобы сформировать контрольный список, инициирующие и отвечающие агенты ICE формируют пары кандидатов, вычисляют пары приоритетов, упорядочивают пары по приоритетам, сокращают пары, удаляют пары с более низким приоритетом и устанавливают состояния контрольного списка. Если кандидаты добавляются в контрольный список (например, из-за обнаружения одноранговых кандидатов), агент повторно выполнит эти шаги для обновленного контрольного списка.

6.1.2.1. Контрольный список состояния

Каждый контрольный список имеет состояние, которое фиксирует состояние проверок ICE для потока данных, связанного с контрольным списком. Состояния:

  • Выполняется (Running): контрольный список еще не завершен и не завершен. Контрольные списки изначально устанавливаются в состояние выполнения.
  • Завершено (Completed): Контрольный список содержит назначенную пару для каждого компонента потока данных.
  • Не удалось (Failed): Контрольный список не имеет допустимой пары для каждого компонента потока данных, и все пары кандидатов в контрольном списке находятся в состоянии Failed или Succeeded. Другими словами, по крайней мере один компонент контрольного списка имеет пары кандидатов, которые все находятся в состоянии Failed, что означает, что компонент потерпел неудачу, что означает, что контрольный список потерпел неудачу.
6.1.2.2. Формирование кандидатских пар

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

В случае RTP это происходит, когда один агент предоставляет кандидатов на RTCP, а другой — нет. В качестве другого примера, инициирующий агент может мультиплексировать RTP и RTCP на одном и том же порту [RFC5761]. Однако, поскольку инициирующий агент не знает, может ли одноранговый агент выполнить такое мультиплексирование, он включает кандидатов на RTP и RTCP на отдельных портах. Если одноранговый агент может выполнять такое мультиплексирование, он будет включать только один компонент для каждого кандидата — для объединенного мультиплексирования RTP / RTCP. В итоге ICE будет вести себя так, как будто у этого кандидата есть только один компонент.

В IPv6 для хоста характерно наличие нескольких кандидатов на хост для каждого интерфейса. Чтобы сохранить разумное количество результирующих пар-кандидатов и избежать пар-кандидатов, которые вряд ли будут работать, локальные адреса IPv6 НЕ ДОЛЖНЫ быть сопряжены с другими, чем локальные адреса каналов.

Пары кандидатов, локальные и удаленные кандидаты которых являются кандидатами по умолчанию для конкретного компонента, называются «пара кандидатов по умолчанию» для этого компонента. Эта пара будет использоваться для передачи данных, если оба агента не были осведомлены о ICE.

На рисунке 5 показаны свойства и взаимосвязи между транспортными адресами, кандидатами, парами кандидатов и контрольными списками.

Рисунок 5 - Концептуальная схема контрольного списка
Рисунок 5 — Концептуальная схема контрольного списка
6.1.2.3. Вычислительные пары с приоритетом и порядок пар

Агент ICE вычисляет приоритет для каждой пары кандидатов. Пусть G будет приоритетом для кандидата, предоставленного контролирующим агентом. Пусть D будет приоритетом для кандидата, предоставленного контролируемым агентом. Приоритет для пары рассчитывается следующим образом:

приоритет пары = 2 ^ 32 * MIN (G, D) + 2 * MAX (G, D) + (G> D? 1: 0)

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

6.1.2.4. Обрезка пар

Этот отсортированный список пар кандидатов используется для определения последовательности проверок подключения, которые будут выполнены. Каждая проверка включает в себя отправку запроса от локального кандидата удаленному кандидату. Поскольку агент ICE не может отправлять запросы напрямую от рефлексивного кандидата (сервер рефлексивный или одноранговый рефлексивный), но только со своей базы, агент затем проходит через отсортированный список пар кандидатов. Для каждой пары, где местный кандидат является рефлексивным, кандидат ДОЛЖЕН быть заменен его базой.

Агент сокращает каждый контрольный список. Это делается путем удаления пары кандидатов, если она избыточна с парой кандидатов с более высоким приоритетом в том же контрольном списке. Две пары кандидатов являются избыточными, если их локальные кандидаты имеют одинаковую базу, а их удаленные кандидаты идентичны. Результатом является последовательность упорядоченных пар кандидатов, называемая «контрольным списком» для этого потока данных.

6.1.2.5. Удаление пар с более низким приоритетом

Чтобы ограничить атаки, описанные в Разделе 19.5.1, агент ICE ДОЛЖЕН ограничить общее количество проверок связности, которые агент выполняет во всех контрольных списках в наборе контрольных списков. Это делается путем ограничения общего числа пар кандидатов в наборе контрольных списков. Предельное число пар кандидатов по умолчанию для набора контрольных списков составляет 100, но значение ДОЛЖНО быть настраиваемым. В каждом контрольном списке ограничение применяется путем отбрасывания пар кандидатов с более низким приоритетом до тех пор, пока общее число пар кандидатов в наборе контрольных списков не станет меньше предельного значения. Отбрасывание СЛЕДУЕТ делать равномерно, чтобы количество пар-кандидатов в каждом контрольном списке уменьшалось на одинаковую величину.

РЕКОМЕНДУЕТСЯ, чтобы по возможности выбиралось нижнее предельное значение, чем значение по умолчанию, и чтобы в качестве значения было задано максимальное количество вероятных пар кандидатов, которые могут быть созданы в фактической конфигурации развертывания. Требование к конфигурации предназначено для предоставления инструмента для исправления этого значения в поле, если после развертывания оно окажется проблематичным.

6.1.2.6. Вычислительные состояния пары кандидатов

Каждая пара кандидатов в контрольном списке имеет основу (комбинацию основ локального и удаленного кандидатов в паре) и одно из следующих состояний:

  • Ожидание: чек на эту пару не отправлен, но пара не заморожена.
  • Выполняется: проверка была отправлена для этой пары, но транзакция выполняется.
  • Успешно: проверка была отправлена для этой пары, и она дала успешный результат.
  • Сбой: проверка была отправлена для этой пары, и она не удалась (ответ на проверку не был получен, или ответ об ошибке был получен).
  • Замороженный: чек на эту пару не был отправлен, и его нельзя отправить, пока пара не разморозится и не перейдет в состояние ожидания.

Пары перемещаются между состояниями, как показано на рисунке 6.

Рисунок 6 - Конечный конечный автомат парного состояния (FSM)
Рисунок 6 — Конечный конечный автомат парного состояния (FSM)

Начальные состояния для каждой пары в контрольном списке вычисляются путем выполнения следующей последовательности шагов:

  1. Контрольные списки помещаются в упорядоченный список (порядок определяется каждым использованием ICE), называемый «набор контрольных списков».
  2. Агент ICE изначально переводит все пары кандидатов в состояние «заморожено».
  3. Агент устанавливает все контрольные списки в контрольном списке, установленном в состояние выполнения.
  4. Для каждого основания агент устанавливает состояние только одной пары кандидатов в состояние Ожидание (размораживание). Пара кандидатов, подлежащая размораживанию, выбирается путем нахождения первой пары кандидатов (упорядоченной по наименьшему идентификатору компонента и затем по наивысшему приоритету, если идентификаторы компонента равны) в первом контрольном списке (в соответствии с заданным порядком использования набора контрольных списков), который имеет эту основу.

ПРИМЕЧАНИЕ. Вышеприведенные процедуры отличаются от RFC 5245, где только пары кандидатов в первом контрольном списке изначально были переведены в состояние ожидания. Теперь это относится к парам кандидатов в первом контрольном списке, которые имеют это основание, даже если контрольный список не является первым в наборе контрольных списков.

Таблица ниже иллюстрирует пример.

Легенда стола:

Каждая строка (m1, m2, …) представляет контрольный список, связанный с потоком данных. m1 представляет первый контрольный список в наборе контрольных списков.

Каждый столбец (f1, f2, …) представляет фундамент. Каждая пара кандидатов в данном столбце имеет одну и ту же основу.

f-cp представляет пару кандидатов в замороженном состоянии.

w-cp представляет пару кандидатов в состоянии ожидания.

1. Агент устанавливает все пары в контрольном списке, установленном в замороженное состояние.

1 - Агент устанавливает все пары в контрольном списке, установленном в замороженное состояние
1 — Агент устанавливает все пары в контрольном списке, установленном в замороженное состояние

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

Таблица 1 - Пример состояния пары
Таблица 1 — Пример состояния пары

В первом контрольном списке (m1) пара кандидатов для каждого основания помещается в состояние ожидания, так как в состоянии ожидания еще не было помещено ни одной пары для тех же оснований.

Во втором контрольном списке (м2) пара кандидатов для основания f4 переводится в состояние ожидания. Пара кандидатов для фондов f1, f2 и f3 сохраняется в замороженном состоянии, поскольку пары кандидатов для этих фондов уже были переведены в состояние ожидания (в контрольном списке m1).

В третьем контрольном списке (m3) пара кандидатов для основания f5 переводится в состояние ожидания. Пара кандидатов для основания f1 сохраняется в состоянии «заморожено», поскольку пара кандидатов для этого основания уже была переведена в состояние ожидания (в контрольном списке m1).

После обработки каждого контрольного списка одна пара кандидатов для каждого основания в наборе контрольных списков переводится в состояние ожидания.

6.1.3. ICE State

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

6.1.4. Планирование проверок

6.1.4.1. Очередь с проверкой

Как только агент ICE вычислил контрольные списки и создал набор контрольных списков, как описано в разделе 6.1.2, агент начнет выполнять проверки подключения (обычные и сработавшие). Для инициируемых проверок подключения агент поддерживает очередь FIFO для каждого контрольного списка, называемую «очередью инициируемой проверки», которая содержит пары кандидатов, для которых проверки должны отправляться при следующей доступной возможности. Очередь триггерной проверки изначально пуста.

6.1.4.2. Выполнение проверок подключения

Генерация обычных и запускаемых проверок подключения определяется таймером Ta. Как только начальные состояния для пар кандидатов в наборе контрольных списков установлены, проверка для пары кандидатов выполняется в первом контрольном списке в состоянии «Выполнение», следуя процедурам, описанным в разделе 7. После этого всякий раз, когда Ta запускает следующее Контрольный список в состоянии «Выполнено» в наборе контрольных списков выбирается, и выполняется проверка кандидата в этом контрольном списке. После обработки последнего контрольного списка в состоянии «Выполнено» в наборе контрольных списков первый контрольный список выбирается снова и т. д.

Всякий раз, когда срабатывает Ta, агент ICE будет выполнять проверку пары кандидатов в контрольном списке, который был выбран, выполнив следующие шаги:

  1. Если очередь триггерной проверки, связанная с контрольным списком, содержит одну или несколько пар кандидатов, агент удаляет верхнюю пару из очереди, выполняет проверку связности для этой пары, переводит состояние пары кандидатов в состояние In-Progress и прерывает последующие шаги
  2. Если в состоянии Ожидания нет пары-кандидата и если в состоянии «Заморожено» есть одна или несколько пар, агент проверяет основание, связанное с каждой парой в состоянии «Замороженное». Для данного основания, если нет пары (ни в одном контрольном списке в наборе контрольных списков) в состоянии «Ожидание» или «В процессе», агент переводит состояние пары-кандидата в «Ожидание» и переходит к следующему шагу.
  3. Если в состоянии ожидания есть одна или несколько пар кандидатов, агент выбирает пару кандидатов с наивысшим приоритетом (если имеется несколько пар с одинаковым приоритетом, выбирается пара с самым низким ID компонента) в состоянии ожидания, выполняет проверку подключения к этой паре, переводит состояние пары-кандидата в состояние In-Progress и прерывает последующие шаги.
  4. Если этот шаг достигнут, никакая проверка не может быть выполнена для выбранного контрольного списка. Поэтому, не дожидаясь истечения срока действия таймера Ta, выберите следующий контрольный список в состоянии «Выполнение» и вернитесь к шагу # 1. Если это происходит для каждого отдельного контрольного списка в состоянии «Выполнено», то есть нет оставшихся пар-кандидатов, для которых нужно выполнить проверки подключения, прервите эти шаги.

Как только агент выбрал пару кандидатов, для которой должна быть выполнена проверка соединения, агент начинает проверку и отправляет запрос Binding из базы, связанной с локальным кандидатом пары, удаленному кандидату пары, как описано в Раздел 7.2.4.

Исходя из локальной политики, агент МОЖЕТ в любой момент прекратить выполнение проверок подключения для одного или нескольких контрольных списков в контрольном списке. Однако только контролирующий агент может заключить ICE (раздел 8).

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

6.2. Процедуры реализации Lite

Реализации Lite пропускают большинство шагов в Разделе 6, за исключением проверки поддержки партнера ICE и определения его роли в обработке ICE.

Если облегченная реализация является управляющим агентом (что произойдет, только если равноправный агент ICE также является облегченной реализацией), она выбирает пару кандидатов на основе тех, которые находятся в обмене кандидатами (для IPv4 существует только одна пара), и затем обновляет одноранговый узел новой информацией о кандидате, отражающей этот выбор, если это необходимо (это никогда не требуется для хоста только для IPv4).

 

7. Выполнение проверок подключения

В этом разделе описывается, как выполняются проверки подключения.

Агент ICE ДОЛЖЕН соответствовать [RFC5389]. Полная реализация действует и как клиент STUN, и как сервер STUN, в то время как облегченная реализация действует только как сервер STUN (так как она не генерирует проверки подключения).

7.1. Расширения STUN

ICE расширяет STUN с помощью атрибутов: ПРИОРИТЕТ, ИСПОЛЬЗОВАНИЕ-КАНДИДАТ, ICECONTROLLED и ICE-CONTROLLING. Эти атрибуты формально определены в разделе 16.1. В этом разделе описывается использование атрибутов.

Атрибуты применимы только к проверкам подключения ICE.

7.1.1. PRIORITY (ПРИОРИТЕТ)

Атрибут PRIORITY ДОЛЖЕН быть включен в запрос Binding и должен быть установлен на значение, вычисленное алгоритмом в разделе 5.1.2 для локального кандидата, но с предпочтением типа кандидата peerreflexive кандидатов.

7.1.2. USE-CANDIDATE (ИСПОЛЬЗОВАНИЕ-КАНДИДАТ)

Контролирующий агент ДОЛЖЕН включать атрибут USE-CANDIDATE, чтобы назначить пару кандидатов (раздел 8.1.1). Контролируемый агент НЕ ДОЛЖЕН включать атрибут USE-CANDIDATE в запрос Binding.

7.1.3. ICE-CONTROLLED и ICE-CONTROLLING (ICE-КОНТРОЛИРУЕМЫЙ и ICE-КОНТРОЛЛИРУЮЩИЙ)

Контролирующий агент ДОЛЖЕН включить атрибут ICE-CONTROLLING в запрос Binding. Контролируемый агент ДОЛЖЕН включить атрибут ICECONTROLLED в запрос Binding.

Содержимое любого из атрибутов используется в качестве значений разрешения конфликтов при возникновении конфликта ролей ICE (Раздел 7.3.1.1).

7.2. Процедуры клиента STUN

7.2.1. Создание разрешений для ретранслируемых кандидатов

Если проверка соединения отправляется с использованием ретранслируемого локального кандидата, клиент ДОЛЖЕН сначала создать разрешение, если оно еще не было создано ранее. Он создал бы его ранее, если бы сказал серверу TURN создать разрешение для данного ретранслируемого кандидата на IP-адрес удаленного кандидата. Чтобы создать разрешение, агент ICE следует процедурам, определенным в [RFC5766]. Разрешение ДОЛЖНО быть создано для IP-адреса удаленного кандидата. РЕКОМЕНДУЕТСЯ, чтобы агент откладывал создание канала TURN до завершения ICE, и в этом случае разрешения для проверок подключения обычно создаются с использованием запроса CreatePermission. После установления агент ДОЛЖЕН поддерживать разрешение активным, пока ICE не завершит работу.

7.2.2. Формирование учетных данных

Запрос Binding-check для проверки соединения ДОЛЖЕН использовать механизм краткосрочных учетных данных STUN.

Имя пользователя для учетных данных формируется путем объединения фрагмента имени пользователя, предоставленного одноранговым узлом, с фрагментом имени пользователя агента ICE, отправляющего запрос, через двоеточие («:»).

Пароль равен паролю, предоставленному партнером.

Например, рассмотрим случай, когда агент ICE L является инициирующим агентом, а агент ICE R является отвечающим агентом. Агент L включил фрагмент имени пользователя LFRAG для своих кандидатов и пароль LPASS. Агент R предоставил фрагмент имени пользователя RFRAG и пароль RPASS. Проверка соединения от L до R использует имя пользователя RFRAG: LFRAG и пароль RPASS. Проверка соединения от R до L использует имя пользователя LFRAG: RFRAG и пароль LPASS. В ответах используются те же имена пользователей и пароли, что и в запросах (обратите внимание, что атрибут USERNAME отсутствует в ответе).

7.2.3. Diffserv Лечение

Если агент использует метки [DSCP] кодов дифференцированных услуг (RFC2475) в пакетах данных, которые он будет отправлять, агент ДОЛЖЕН применять те же метки к запросам и ответам Binding, которые он будет отправлять.

Если в пакетах данных используется несколько меток DSCP, агент ДОЛЖЕН выбрать одну из них для использования с проверкой соединения.

7.2.4. Отправка запроса

Проверка связности генерируется путем отправки запроса Binding из базы, связанной с локальным кандидатом, удаленному кандидату. [RFC5389] описывает, как создаются и генерируются запросы привязки.

Поддержка обратной совместимости с RFC 3489 НЕ ДОЛЖНА приниматься при выполнении проверок подключения. Механизм FINGERPRINT ДОЛЖЕН использоваться для проверки подключения.

7.2.5. Обработка ответа

В этом разделе определяются дополнительные процедуры для обработки ответов Binding, относящихся к проверкам подключения ICE.

Когда ответ Binding получен, он соотносится с соответствующим запросом Binding с использованием идентификатора транзакции [RFC5389], который затем связывает ответ с парой кандидатов, для которой был отправлен запрос Binding. После этого ответ обрабатывается в соответствии с процедурами для конфликта ролей, сбоя или успеха в соответствии с процедурами, приведенными ниже.

7.2.5.1. Роль Конфликт

Если запрос Binding генерирует ответ об ошибке 487 (Role Conflict) (раздел 7.3.1.1), и если агент ICE включил в запрос атрибут ICE-CONTROLLED, агент ДОЛЖЕН переключиться на управляющую роль. Если агент включил в запрос атрибут ICE-CONTROLLING, агент ДОЛЖЕН переключиться на контролируемую роль.

После того как агент поменял свою роль, агент ДОЛЖЕН добавить пару кандидатов, чья проверка вызвала ответ об ошибке 487, в очередь триггерных проверок, связанную с контрольным списком, которому принадлежит эта пара, и установить состояние пары кандидатов на Ожидание. Когда инициируемая проверка подключения будет выполнена позже, атрибут ICE-CONTROLLING / ICE-CONTROLLED запроса Binding будет указывать новую роль агента. Агент ДОЛЖЕН изменить значение разрешения конфликтов.

ПРИМЕЧАНИЕ. Для переключения ролей требуется, чтобы агент пересчитал парные приоритеты (раздел 6.1.2.3), поскольку значения приоритетов зависят от роли.

ПРИМЕЧАНИЕ. Переключение ролей также повлияет на то, отвечает ли агент за назначение пар кандидатов, и отвечает ли агент за инициирование обмена обновленной информацией кандидата с партнером после завершения ICE.

7.2.5.2. Недостаточность

В этом разделе описываются случаи, когда для состояния пары кандидатов установлено значение Неудачно.

ПРИМЕЧАНИЕ. Когда агент ICE устанавливает состояние пары-кандидатов в состояние Failed в результате ошибки проверки соединения, агент не изменяет состояния других пар-кандидатов с тем же основанием.

7.2.5.2.1. Несимметричные транспортные адреса

Агент ICE ДОЛЖЕН проверить, что транспортные адреса источника и назначения в запросе и ответе Binding являются симметричными. То есть IP-адрес источника и порт ответа ДОЛЖНЫ быть равны IP-адресу и порту назначения, на которые был отправлен запрос Binding, а IP-адрес и порт назначения ДОЛЖНЫ быть равны IP-адресу и порту источника. с которого был отправлен запрос Binding. Если адреса не являются симметричными, агент ДОЛЖЕН установить состояние пары-кандидатов в состояние Failed.

7.2.5.2.2. Ошибка ICMP

Агент ICE МОЖЕТ поддерживать обработку ошибок ICMP для проверки подключения. Если агент поддерживает обработку ошибок ICMP и если запрос Binding генерирует серьезную ошибку ICMP, агент ДОЛЖЕН установить состояние пары кандидатов в состояние Failed. Разработчики должны знать, что ошибки ICMP можно использовать как метод для атак типа «отказ в обслуживании» (DoS) при принятии решения о том, как и следует ли обрабатывать ошибки ICMP.

7.2.5.2.3. Тайм-аут

Если время транзакции запроса Binding истекло, агент ICE ДОЛЖЕН установить состояние пары-кандидатов в состояние Failed.

7.2.5.2.4. Неустранимый ответ STUN

Если запрос Binding генерирует ответ об ошибке STUN, который невозможно исправить [RFC5389], агент ICE ДОЛЖЕН установить состояние пары-кандидатов в состояние Failed.

7.2.5.3. Успех

Проверка подключения считается успешной, если выполняется каждый из следующих критериев:

  • Запрос Binding сгенерировал успешный ответ; а также
  • Транспортные адреса источника и назначения в запросе и ответе Binding являются симметричными.

Если проверка считается успешной, агент ICE выполняет (по порядку) действия, описанные в следующих разделах.

7.2.5.3.1. Обнаружение равнодушных кандидатов

Агент ICE ДОЛЖЕН проверить сопоставленный адрес из ответа STUN. Если транспортный адрес не соответствует ни одному из локальных кандидатов, о которых знает агент, сопоставленный адрес представляет нового кандидата: однорангового рефлексивного кандидата. Как и другие кандидаты, у рефлексивного кандидата есть тип, основание, приоритет и основание.

Они рассчитываются следующим образом:

  • Тип рефлексивный.
  • База — это локальный кандидат из пары кандидатов, из которой был отправлен запрос Binding.
  • Приоритет — это значение атрибута PRIORITY в запросе Binding.
  • Фундамент описан в разделе 5.1.1.3.

Рефлексивный кандидат затем добавляется в список локальных кандидатов для потока данных. Фрагмент имени пользователя и пароль такие же, как и для всех других локальных кандидатов для этого потока данных.

Агент ICE не должен связывать однорангового кандидата с удаленными кандидатами, так как будет создана действительная пара из-за процедур, описанных в разделе 7.2.5.3.2. Если агент желает связать однорангового рефлексивного кандидата с удаленными кандидатами, отличными от одного в допустимой паре, которая будет сгенерирована, агент МОЖЕТ предоставить обновленную информацию о кандидате одноранговому узлу, который включает однорефлексивного кандидата. Это приведет к тому, что равноправный кандидат будет связан со всеми другими удаленными кандидатами.

7.2.5.3.2. Построение допустимой пары

Агент ICE создает пару кандидатов, чей локальный кандидат равен сопоставленному адресу ответа, а удаленный кандидат равен адресу назначения, на который был отправлен запрос. Это называется «действительная пара».

Допустимая пара может равняться паре, сгенерировавшей проверку подключения, другой паре в контрольном списке или паре, в настоящее время не входящей в контрольный список.

Агент ведет отдельный список, называемый «действительным списком». Существует правильный список для каждого контрольного списка в наборе контрольных списков. Действительный список будет содержать действительные пары. Первоначально каждый действительный список пуст.

Каждая действительная пара в допустимом списке имеет флаг, называемый «назначенный флаг». Когда действительная пара добавляется в действительный список, значение флага устанавливается на «ложь».

Действительная пара будет добавлена ​​в действительный список следующим образом:

  1. Если действительная пара равна паре, сгенерировавшей проверку, она добавляется в действительный список, связанный с контрольным списком, к которому принадлежит эта пара; или же
  2. Если действительная пара равна другой паре в контрольном списке, эта пара добавляется в действительный список, связанный с контрольным списком этой пары. Пара, сгенерировавшая проверку, не добавлена ​​в действительный список; или же
  3. Если действительной пары нет ни в одном контрольном списке, агент вычисляет приоритет для пары на основе приоритета каждого кандидата, используя алгоритм в разделе 6.1.2. Приоритет местного кандидата зависит от его типа. Если тип не является одноранговым рефлексивным, приоритет равен приоритету, указанному для этого кандидата в обмене кандидатами. Если тип является одноранговым рефлексивным, он равен атрибуту PRIORITY, который агент поместил в только что завершенный запрос Binding. Приоритет удаленного кандидата берется из информации кандидата партнера. Если кандидат там не появляется, то проверка была инициированной проверкой нового удаленного кандидата. В этом случае приоритет принимается за значение атрибута PRIORITY в запросе Binding, который инициировал только что завершенную проверку. Затем пара добавляется в действительный список.

ПРИМЕЧАНИЕ. Очень часто действительная пара не будет включена ни в один контрольный список. Напомним, что в контрольном списке есть пары, местные кандидаты которых никогда не бывают рефлексивными; у тех пар были их местные кандидаты, преобразованные в основу рефлексивных кандидатов, и затем были сокращены, если они были избыточны. Когда приходит ответ на запрос Binding, сопоставленный адрес будет рефлексивным, если между ними есть NAT. В этом случае допустимая пара будет иметь локального кандидата, который не соответствует ни одной из пар в контрольном списке.

7.2.5.3.3. Обновление состояний пары кандидатов

Агент ICE устанавливает состояния как пары-кандидата, сгенерировавшей проверку, так и созданной действительной пары (которые могут отличаться) на Успешное.

Агент ДОЛЖЕН установить состояние для всех других пар замороженных кандидатов во всех контрольных списках с тем же основанием на Ожидание.

ПРИМЕЧАНИЕ. В данном контрольном списке пары кандидатов с одинаковыми основаниями обычно имеют разные значения идентификатора компонента.

7.2.5.3.4. Обновление назначенного флага

Если контролирующий агент отправляет запрос Binding с установленным атрибутом USECANDIDATE, и если агент ICE получает успешный ответ на запрос, агент устанавливает назначенный флаг пары в значение true. Если запрос не выполняется (Раздел 7.2.5.2), агент ДОЛЖЕН удалить пару кандидатов из допустимого списка, установить состояние пары кандидатов на Failed и установить состояние контрольного списка на Failed.

Если контролируемый агент получает успешный ответ на запрос Binding, отправленный агентом, и этот запрос Binding был инициирован полученным запросом Binding с набором атрибутов USE-CANDIDATE (раздел 7.3.1.4), агент устанавливает назначенный флаг пара к истине. Если инициируемый запрос завершается неудачно, агент ДОЛЖЕН удалить пару кандидатов из допустимого списка, установить состояние пары кандидатов на Failed и установить состояние контрольного списка на Failed.

Как только назначенный флаг установлен для компонента потока данных, он завершает обработку ICE для этого компонента (Раздел 8).

7.2.5.4. Обновления состояния контрольного списка

Независимо от того, была ли проверка подключения успешной или неудачной, для завершения проверки может потребоваться обновление состояний контрольного списка. Для каждого контрольного списка в наборе контрольных списков, если все пары-кандидаты находятся в состоянии Failed или Succeeded, и если в допустимом списке нет допустимой пары для каждого компонента потока данных, связанного с контрольным списком, состояние Контрольный список имеет значение Failed. Если для каждого компонента в допустимом списке есть действительная пара, состояние контрольного списка устанавливается как Успешное.

7.3. Процедуры сервера STUN

Агент ICE (облегченный или полный) ДОЛЖЕН быть готов к приему запросов Binding на основе каждого кандидата, который он включил в свой последний обмен кандидатами.

Агент ДОЛЖЕН использовать механизм краткосрочных учетных данных (то есть атрибут MESSAGE-INTEGRITY) для аутентификации запроса и проверки целостности сообщения. Аналогично, краткосрочный учетный механизм ДОЛЖЕН использоваться для ответа. Агент ДОЛЖЕН считать имя пользователя действительным, если оно состоит из двух значений, разделенных двоеточием, где первое значение равно фрагменту имени пользователя, сгенерированному агентом при обмене кандидатами на выполняемый сеанс. Возможно (и на самом деле очень вероятно), что инициирующий агент получит запрос Binding до получения кандидатов от своего партнера. Если это происходит, агент ДОЛЖЕН немедленно сгенерировать ответ (включая вычисление сопоставленного адреса, как описано в Разделе 7.3.1.2). На данный момент агент обладает достаточной информацией для генерации ответа; пароль от пира не требуется. Как только ответ получен, он ДОЛЖЕН приступить к выполнению остальных необходимых шагов; а именно, см. разделы 7.3.1.3, 7.3.1.4 и 7.3.1.5 для полной реализации. В случаях, когда несколько запросов STUN получены до ответа, это может привести к тому, что несколько пар будут поставлены в очередь в очереди триггерной проверки.

Агент НЕ ДОЛЖЕН использовать механизм ALTERNATE-SERVER и НЕ ДОЛЖЕН поддерживать механизмы обратной совместимости, определенные в RFC 5389 (для работы с протоколом в RFC 3489). Он ДОЛЖЕН использовать механизм FINGERPRINT.

Если агент использует метки DSCP [RFC2475] в своих пакетах данных, он ДОЛЖЕН применять те же метки к ответам Binding. То же самое относится к любым отметкам уровня 2, которые конечная точка может применять к пакетам данных.

 

7.3.1. Дополнительные процедуры для полной реализации

В этом подразделе определяются дополнительные серверные процедуры, применимые к полной реализации, когда полная реализация принимает запрос Binding.

7.3.1.1. Обнаружение и устранение ролевых конфликтов

В некоторых случаях использования ICE (например, 3PCC) оба агента ICE могут выбрать одну и ту же роль, что приведет к конфликту ролей. В этом разделе описан механизм обнаружения и устранения конфликтов ролей. Документ об использовании ДОЛЖЕН указывать, нужен ли этот механизм.

Агент ДОЛЖЕН проверить запрос Binding на наличие атрибута ICECONTROLLING или ICE-CONTROLLED. Он ДОЛЖЕН следовать этим процедурам:

o Если агент играет контролирующую роль, а в запросе присутствует атрибут ICE-CONTROLLING:

  • * Если значение агента разрешения конфликтов больше или равно содержанию атрибута ICE-CONTROLLING, агент генерирует ответ об ошибке привязки и включает в себя атрибут ERROR-CODE со значением 487 (конфликт ролей), но сохраняет свою роль.
  • * Если значение агента разрешения конфликтов меньше, чем содержимое атрибута ICE-CONTROLLING, агент переключается на контролируемую роль.

o Если агент находится в контролируемой роли, а в запросе присутствует атрибут ICE-CONTROLLED:

  • * Если значение агента разрешения конфликтов больше или равно содержанию атрибута ICE-CONTROLLED, агент переключается на управляющую роль.
  • * Если значение агента разрешения конфликтов меньше, чем содержимое атрибута ICE-CONTROLLED, агент генерирует ответ об ошибке привязки и включает в себя атрибут ERROR-CODE со значением 487 (конфликт ролей), но сохраняет свою роль.

o Если агент находится в контролируемой роли, а атрибут ICE-CONTROLLING присутствовал в запросе, или если агент был в управляющей роли, а атрибут ICE-CONTROLLED присутствовал в запросе, конфликт отсутствует.

Изменение ролей потребует от агента пересчета парных приоритетов (раздел 6.1.2.3), поскольку эти приоритеты являются функцией роли. Изменение роли также будет влиять на то, отвечает ли агент за выбор номинированных пар и инициирование обмена с обновленной информацией о кандидате после заключения ICE.

Остальные подразделы в разделе 7.3.1 выполняются, если агент сгенерировал успешный ответ на запрос Binding, даже если агент изменил роли.

7.3.1.2. Вычисление сопоставленных адресов

Для запросов, полученных для ретранслируемого кандидата, транспортный адрес источника, используемый для обработки STUN (а именно, генерация атрибута XOR-MAPPED-ADDRESS), является транспортным адресом, видимым сервером TURN. Этот транспортный адрес источника будет присутствовать в атрибуте XOR-PEER-ADDRESS сообщения индикации данных, если запрос привязки был доставлен через индикацию данных. Если запрос Binding был доставлен через сообщение ChannelData, транспортный адрес источника является тем, который был связан с каналом.

7.3.1.3. Обучение сверстников-рефлексивных кандидатов

Если исходный транспортный адрес запроса не совпадает ни с одним из существующих удаленных кандидатов, он представляет нового рефлексивного удаленного кандидата. Этот кандидат построен следующим образом:

  • Тип рефлексивный.
  • Приоритет — это значение атрибута PRIORITY в запросе Binding.
  • Основа — это произвольное значение, отличное от основ всех других удаленных кандидатов. Если какие-либо последующие обмены кандидатами содержат этого рефлексивного кандидата, это будет сигнализировать фактическое обоснование кандидата.
  • Идентификатор компонента — это идентификатор компонента локального кандидата, которому был отправлен запрос.

Этот кандидат добавлен в список удаленных кандидатов. Однако агент ICE не связывает этого кандидата с местными кандидатами.

7.3.1.4. Триггерные проверки

Затем агент создает пару, локальный кандидат которой имеет транспортный адрес (как он виден агентом), по которому был получен запрос STUN, и удаленный кандидат, равный транспортному адресу источника, откуда поступил запрос (который может быть одноранговым). рефлексивный удаленный кандидат, который только что выучил). Местным кандидатом будет либо кандидат на хост (для случаев, когда запрос не был получен через ретранслятор), либо ретранслируемый кандидат (для случаев, когда он получен через ретранслятор). Местный кандидат никогда не может быть серверно-рефлексивным кандидатом. Поскольку оба кандидата известны агенту, он может получить их приоритеты и вычислить приоритет пары кандидатов. Эта пара затем ищется в контрольном списке. Может быть один из нескольких результатов:

o Когда пара уже находится в контрольном списке:

  • * Если состояние этой пары — Успешно, дальнейшие действия не предпринимаются.
  • * Если состояние этой пары — In-Progress, агент отменяет транзакцию In-Progress. Отмена означает, что агент не будет повторно передавать запросы Binding, связанные с транзакцией проверки подключения, не будет рассматривать отсутствие ответа как сбой, но будет ожидать ответа в течение времени ожидания транзакции. Кроме того, агент ДОЛЖЕН поставить в очередь пару в сработавшем контрольном списке, связанном с контрольным списком, и установить состояние пары на Ожидание, чтобы инициировать новую проверку связности пары. Создание новой проверки подключения позволяет как можно скорее проверять пары In-Progress, не дожидаясь повторной передачи запросов Binding, связанных с исходной транзакцией проверки подключения.
  • * Если состояние этой пары — «Ожидание», «Заморожено» или «Сбой», агент ДОЛЖЕН поставить в очередь пару в сработавшем контрольном списке, связанном с контрольным списком (если он еще не существует), и установить состояние пары на Ожидание, чтобы инициировать новая проверка соединения пары. Обратите внимание, что изменение состояния пары с Неудачно на Ожидание может также вызвать изменение состояния соответствующего контрольного списка.

Эти шаги сделаны, чтобы облегчить быстрое завершение ICE, когда оба агента находятся за NAT.

o Если пары еще нет в контрольном списке:

  • * Пара вставляется в контрольный список в зависимости от ее приоритета.
  • * Его состояние установлено на Ожидание.
  • * Пара помещена в очередь на триггерную проверку.

Когда инициируемая проверка должна быть отправлена, она составляется и обрабатывается, как описано в разделе 7.2.4. Эти процедуры требуют, чтобы агент знал транспортный адрес, фрагмент имени пользователя и пароль для однорангового узла. Фрагмент имени пользователя для удаленного кандидата равен части после двоеточия USERNAME в только что полученном запросе Binding. Используя этот фрагмент имени пользователя, агент может проверить кандидатов, полученных от своего партнера (их может быть больше одного в случае разветвления), и найти этот фрагмент имени пользователя. Соответствующий пароль будет выбран.

7.3.1.5. Обновление назначенного флага

Если контролируемый агент получает запрос Binding с установленным атрибутом USECANDIDATE, и если агент ICE принимает запрос, следующее действие основано на состоянии пары, вычисленной в разделе 7.3.1.4:

  • Если состояние этой пары является Успешным, это означает, что проверка, ранее отправленная этой парой, вызвала успешный ответ и сгенерировала правильную пару (Раздел 7.2.5.3.2). Агент устанавливает номинальное значение флага допустимой пары в значение true.
  • Если полученный запрос Binding инициировал новую проверку, которая будет помещена в очередь в очереди триггерных проверок (раздел 7.3.1.4), после того, как проверка отправлена, и если она генерирует успешный ответ и генерирует правильную пару, агент устанавливает назначенную флаг пары к истине. Если запрос не выполняется (Раздел 7.2.5.2), агент ДОЛЖЕН удалить пару кандидатов из допустимого списка, установить состояние пары кандидатов на Failed и установить состояние контрольного списка на Failed.

Если контролируемый агент не принимает запрос от контролирующего агента, контролируемый агент ДОЛЖЕН отклонить запрос назначения с соответствующим ответом с кодом ошибки (например, 400) [RFC5389].

Как только назначенный флаг установлен для компонента потока данных, он завершает обработку ICE для этого компонента. Смотрите Раздел 8.

7.3.2. Дополнительные процедуры для реализации Lite

Если контролируемый агент получает запрос Binding с установленным атрибутом USECANDIDATE, и если агент ICE принимает запрос, агент создает пару кандидатов, локальный кандидат которой имеет транспортный адрес, по которому был получен запрос, и удаленный кандидат которого равен исходный транспортный адрес запроса, который был получен. Этой паре кандидатов назначается произвольный приоритет и она помещается в действительный список соответствующего контрольного списка. Агент устанавливает назначенный флаг для этой пары в значение true.

Как только назначенный флаг установлен для компонента потока данных, он завершает обработку ICE для этого компонента. Смотрите Раздел 8.

 

8. Заключительная обработка ICE

В этом разделе описывается, как агент ICE завершает ICE.

8.1. Процедуры для полной реализации

Заключение ICE включает в себя назначение пар контролирующим агентом и обновление государственного аппарата.

8.1.1. Номинация пар

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

После того, как контролирующий агент выбрал действительную пару для номинации, он повторяет проверку подключения, которая произвела эту действительную пару (путем помещения пары, сгенерировавшей проверку в очередь триггерной проверки), на этот раз с атрибутом USE-CANDIDATE (раздел 7.2. .5.3.4). Процедуры для контролируемого агента описаны в разделе 7.3.1.5.

В конце концов, если назначения успешны, и у контролирующих, и у контролируемых агентов будет одна назначенная пара в допустимом списке для каждого компонента потока данных. Как только агент ICE устанавливает состояние контрольного списка в «Завершено» (когда есть назначенная пара для каждого компонента потока данных), эта пара становится выбранной парой для этого агента и используется для отправки и получения данных для этого компонента поток данных.

Если агент не может создать выбранные пары для каждого компонента потока данных, агент ДОЛЖЕН предпринять надлежащие действия для информирования другого агента, например, путем удаления потока. Точные действия выходят за рамки данной спецификации.

Критерии прекращения проверок связности и выбора пары для номинации выходят за рамки данной спецификации. Это вопрос локальной оптимизации. Единственное требование заключается в том, что агент ДОЛЖЕН в конечном итоге выбрать одну и только одну пару кандидатов и сгенерировать проверку для этой пары с набором атрибутов USE-CANDIDATE.

После того как контролирующий агент успешно назначил пару кандидатов (Раздел 7.2.5.3.4), агент НЕ ДОЛЖЕН назначать другую пару для того же компонента потока данных в рамках сеанса ICE. Для этого требуется перезапуск ICE.

Контролирующий агент, который не поддерживает эту спецификацию (т.е. она реализована в соответствии с RFC 5245), может назначить более одной пары кандидатов. В RFC 5245 это называлось «агрессивным назначением». Если контролирующим агентом назначено более одной пары кандидатов, и если контролируемый агент принимает несколько запросов на назначение, агенты ДОЛЖНЫ создать выбранные пары и использовать пары с наибольшим приоритет.

Предполагается, что использование опции ICE ’ice2’ (раздел 10) конечными точками, поддерживающими эту спецификацию, не позволяет управляющим агентам, которые реализованы в соответствии с RFC 5245, использовать агрессивные номинации.

ПРИМЕЧАНИЕ. В RFC 5245 использование «агрессивной номинации» позволяло агентам непрерывно назначать пары до того, как пара была в конечном итоге выбрана, чтобы разрешить отправку данных по этим парам. В этой спецификации данные всегда могут быть отправлены по любой действительной паре без номинации. Следовательно, больше нет необходимости в агрессивной номинации.

8.1.2. Обновление контрольного списка и состояний ICE

Как для контролирующего, так и для контролируемого агента, когда назначается пара кандидатов для компонента потока данных, это может повлиять на другие пары в контрольном списке, связанном с потоком данных. Это также может повлиять на состояние контрольного списка:

  • Как только пара кандидатов для компонента потока данных была назначена, и состояние контрольного списка, связанного с потоком данных, выполняется, агент ICE ДОЛЖЕН удалить все пары кандидатов для того же компонента из контрольного списка и из очереди triggeredcheck. , Если состояние пары In In-Progress, агент отменяет транзакцию In-Progress. Отмена означает, что агент не будет повторно передавать запросы Binding, связанные с транзакцией проверки подключения, не будет рассматривать отсутствие ответа как сбой, но будет ожидать ответа в течение времени ожидания транзакции.
  • Как только пары кандидатов для каждого компонента потока данных были назначены, а состояние контрольного списка, связанного с потоком данных, — «Выполняется», агент ICE устанавливает состояние контрольного списка «Завершено».
  • Как только пара кандидатов для компонента потока данных была назначена, агент ДОЛЖЕН продолжать отвечать на любой запрос Binding, который он все еще может получить для назначенной пары и для любых оставшихся пар кандидатов в контрольном списке, связанном с потоком данных. Как определено в Разделе 7.3.1.4, когда состояние пары является Успешным, агент больше не будет генерировать инициированные проверки при получении запроса Связывания для пары.

Как только состояние каждого контрольного списка в наборе контрольных списков завершено, агент устанавливает состояние сеанса ICE на Завершено.

Если состояние контрольного списка не выполнено, ICE не смог успешно завершить процесс для потока данных, связанного с контрольным списком. Правильное поведение зависит от состояния контрольных списков в наборе контрольных списков. Если контролирующий агент хочет продолжить сеанс без потока данных, связанного с контрольным списком Failed, и если в режиме «Выполнено» или «Завершено» все еще есть один или несколько контрольных списков, агент может позволить продолжить обработку ICE. Агент ДОЛЖЕН предпринять надлежащие действия для удаления сбойного потока данных. Если контролирующий агент не хочет продолжать сеанс и ДОЛЖЕН завершить сеанс, состояние сеанса ICE устанавливается на Failed.

Если состояние каждого контрольного списка в наборе контрольных списков является Failed, состояние сеанса ICE устанавливается в Failed. Если контролирующий агент не хочет продолжить сеанс без потоков данных, он ДОЛЖЕН завершить сеанс.

8.2. Процедуры для Lite-реализаций

Когда ICE завершает, облегченный агент ICE может освободить хост-кандидатов, которые не использовались ICE, как описано в Разделе 8.3.

Если одноранговый узел является полным агентом, когда агент lite принимает запрос на выдвижение кандидатской пары, агент lite считает назначенную пару. Как только есть назначенные пары для каждого компонента потока данных, пары становятся выбранными парами для компонентов потока данных. После того, как облегченный агент создал выбранные пары для всех компонентов всех потоков данных, состояние сеанса ICE устанавливается на Завершено.

Если одноранговый узел является облегченным агентом, агент объединяет локальных кандидатов с удаленными кандидатами, которые имеют один и тот же поток данных и имеют одинаковый компонент, транспортный протокол и семейство IP-адресов. Для каждого компонента каждого потока данных, если существует только одна пара кандидатов, эта пара добавляется в действительный список. Если существует более одной пары, РЕКОМЕНДУЕТСЯ, чтобы агент выполнил процедуры RFC 6724 [RFC6724], чтобы выбрать пару и добавить ее в действительный список.

Если все компоненты для всех потоков данных имели одну пару, состояние обработки ICE завершено. В противном случае управляющий агент ДОЛЖЕН отправить обновленный список кандидатов для согласования разных агентов, выбирающих разные пары кандидатов. Обработка ICE завершается после и только после завершения обновленного обмена кандидатами.

8.3. Кандидаты на освобождение

8.3.1. Процедуры полного внедрения

Правила в этом разделе описывают, когда для агента безопасно прекратить отправку или получение проверок кандидата, который не стал выбранным кандидатом (то есть не связан с выбранной парой), и когда освободить кандидата.

Как только контрольный список достигнет состояния «Завершено», агент ДОЛЖЕН подождать еще три секунды, после чего он может перестать отвечать на проверки или генерировать инициированные проверки для всех локальных кандидатов, кроме тех, которые стали выбранными кандидатами. Как только все сеансы ICE прекратили использование данного локального кандидата (кандидат может использоваться несколькими сеансами ICE, например, в сценариях разветвления), агент может освободить этого кандидата. Трехсекундная задержка обрабатывает случаи, когда используется агрессивная номинация, и выбранные пары могут быстро измениться после завершения ICE.

Освобождение серверно-рефлексивных кандидатов никогда не бывает явным; это происходит из-за отсутствия keepalive.

8.3.2. Процедуры реализации Lite

Легкая реализация может освободить кандидатов, которые не стали выбранными кандидатами, как только обработка ICE достигнет состояния «Завершено» для всех сеансов ICE, использующих этих кандидатов.

9. ICE Перезапускает

Агент ICE МОЖЕТ перезапустить ICE для существующих потоков данных. Перезапуск ICE приводит к сбросу всех предыдущих состояний потоков данных, за исключением ролей агентов. Единственное различие между перезапуском ICE и новым сеансом данных состоит в том, что во время перезапуска данные могут продолжать отправляться с использованием существующих сеансов данных, а новый сеанс данных всегда требует определения ролей.

Следующие действия могут быть выполнены только с помощью перезапуска ICE (для этого агент ДОЛЖЕН использовать перезапуски ICE):

  • Изменить места назначения потоков данных.
  • Переход от облегченной реализации к полной реализации.
  • Переход от полной реализации к облегченной реализации.

Чтобы перезапустить ICE, агент ДОЛЖЕН изменить и пароль, и фрагмент имени пользователя для перезапускаемых потоков данных.

Когда ICE перезапускается, набор кандидатов для нового сеанса ICE может включать в себя некоторые, ни одного, или все кандидаты, использованные в текущем сеансе ICE.

Как описано в разделе 6.1.1, агенты НЕ ДОЛЖНЫ переопределять роли как часть перезапуска ICE, если не выполняются определенные критерии, которые требуют переопределения ролей.

10. ICE Вариант

Этот раздел определяет новую опцию ICE, ‘ice2’. Когда агент ICE включает «ice2» в обмен кандидатами, опция ICE указывает, что он соответствует этой спецификации. Например, агент не будет использовать процедуру агрессивного назначения, определенную в RFC 5245. Кроме того, он будет гарантировать, что одноранговый узел, соответствующий RFC 5245, также не будет использовать агрессивное назначение, как того требует Раздел 14 RFC 5245 для одноранговых узлов, которые получают неизвестные. Варианты ICE.

Агент, соответствующий этой спецификации, ДОЛЖЕН проинформировать партнера о соответствии, используя опцию «ice2».

ПРИМЕЧАНИЕ. Кодировка параметра ’ice2’ и сообщения, используемые для передачи его одноранговому узлу, зависят от протокола. Кодирование для SDP [RFC4566] определено в [ICE-SIP-SDP].

11. Keepalive

Все конечные точки ДОЛЖНЫ отправлять сообщения активности для каждого сеанса данных. Эти сообщения поддержки активности служат для поддержания привязок NAT к сеансу данных. Сообщения активности ДОЛЖНЫ быть отправлены в формате, поддерживаемом его партнером. Конечные точки ICE допускают основанные на STUN сообщения активности активности для потоков UDP, и поэтому сообщения поддержки активности STUN ДОЛЖНЫ использоваться, когда агент ICE является полной реализацией ICE и обменивается данными с партнером, который поддерживает ICE (облегченный или полный).

Агент ДОЛЖЕН послать подтверждение активности для каждой пары кандидатов, которая используется для отправки данных, если по этой паре в течение последних Tr секунд не было отправлено ни одного пакета. Агенты ДОЛЖНЫ использовать значение Tr 15 секунд. Агенты МОГУТ использовать большее значение, но НЕ ДОЛЖНЫ использовать значение меньше 15 секунд.

После создания выбранных пар для потока данных сообщения активности отправляются только по этим парам.

Агент ДОЛЖЕН прекратить отправку сообщений активности в потоке данных, если поток данных удален. Если сеанс ICE завершен, агент ДОЛЖЕН прекратить отправку сообщений активности для всех потоков данных.

Агент МОЖЕТ использовать другое значение для Tr, например, на основе конфигурации или характеристик сети / NAT. Например, если у агента есть динамический способ определения времени жизни связывающих NAT, он может использовать это значение для определения Tr. Администраторы, внедряющие ICE в более контролируемых сетевых средах, ДОЛЖНЫ установить Tr на максимально возможную продолжительность в своей среде.

Когда STUN используется для keepalive, используется индикация привязки STUN [RFC5389]. Индикация НЕ ДОЛЖНА использовать какой-либо механизм аутентификации. Он ДОЛЖЕН содержать атрибут FINGERPRINT для помощи в демультиплексировании, но он НЕ ДОЛЖЕН содержать никаких других атрибутов. Он используется исключительно для поддержки привязки NAT. Индикация привязки отправляется с использованием тех же локальных и удаленных кандидатов, которые используются для данных. Несмотря на то, что указатели привязки используются для keepalive, агент ДОЛЖЕН быть готов к получению проверки подключения. Если получена проверка подключения, генерируется ответ, как описано в [RFC5389], но в противном случае это не влияет на обработку ICE.

Агенты ДОЛЖНЫ по умолчанию использовать сообщения активности STUN. Индивидуальное использование ICE и расширения ICE МОГУТ определять специфичные для использования / расширения продолжительные сообщения активности.

12. Обработка данных

12.1. Отправка данных

Агент ICE МОЖЕТ отправить данные по любой действительной паре до того, как выбранные пары будут созданы для потока данных.

После того как выбранные пары созданы для потока данных, агент ДОЛЖЕН отправить данные только по этим парам.

Агент отправляет данные из базы локального кандидата удаленному кандидату. В случае локального ретранслируемого кандидата данные передаются через базу (расположенную на сервере TURN) с использованием процедур, определенных в [RFC5766].

Если локальный кандидат является ретранслированным кандидатом, РЕКОМЕНДУЕТСЯ, чтобы агент создал канал на сервере TURN для удаленного кандидата. Это делается с использованием процедур для создания канала, как определено в разделе 11 [RFC5766].

Выбранная пара для компонента потока данных:

  • пусто, если состояние контрольного списка для этого потока данных выполняется, и ранее нет выбранной пары для этого компонента из-за перезапуска ICE
  • равно предыдущей выбранной паре для компонента потока данных, если состояние контрольного списка для этого потока данных выполняется, и для этого компонента была предыдущая выбранная пара из-за перезапуска ICE

Если агент не может создать выбранную пару для каждого компонента, связанного с потоком данных, агент НЕ ДОЛЖЕН продолжать отправку данных для любого компонента, связанного с этим потоком данных.

12.1.1. Процедуры для Lite-реализаций

Облегченная реализация НЕ ДОЛЖНА отправлять данные до тех пор, пока у нее не будет действительного списка, который содержит пару кандидатов для каждого компонента этого потока данных. Как только это произойдет, агент ICE МОЖЕТ начать отправку пакетов данных. Для этого он отправляет данные удаленному кандидату в паре (устанавливая адрес назначения и порт пакета, равный этому удаленному кандидату) и отправляет их из базы, связанной с парой кандидатов, используемой для отправки данных. В случае ретранслируемого кандидата данные передаются от агента и пересылаются через базу (расположенную на сервере TURN), используя процедуры, определенные в [RFC5766].

12.2. Получение данных

Даже если агентам ICE разрешено отправлять данные только с использованием допустимых пар кандидатов (и, как только выбранные пары были созданы, только для выбранных пар), реализации ICE ДОЛЖНЫ по умолчанию быть готовы к получению данных о любом из кандидатов, представленных в большинстве недавний обмен кандидатом со сверстником. Использование ICE МОЖЕТ определять правила, которые отличаются от этого, например, путем определения того, что данные не будут отправлены, пока не будут созданы выбранные пары для потока данных.

Когда агент получает пакет RTP с новым IP-адресом источника или назначения для определенного потока данных RTP / RTCP, РЕКОМЕНДУЕТСЯ, чтобы агент перенастроил свои буферы дрожания.

В разделе 8.2 RFC 3550 [RFC3550] описан алгоритм обнаружения коллизий и циклов источника синхронизации (SSRC). Эти алгоритмы частично основаны на просмотре разных транспортных адресов источника с одним и тем же SSRC. Однако при использовании ICE такие изменения иногда происходят, когда потоки данных переключаются между кандидатами. Агент сможет определить, что поток данных поступает от того же однорангового узла в результате обмена STUN, который продолжает передачу мультимедийных данных. Таким образом, если есть изменение в транспортном адресе источника, но пакеты мультимедийных данных поступают от одного и того же равноправного агента, это НЕ ДОЛЖНО рассматриваться как коллизия SSRC.

13. Вопросы расширения

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

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

Одна из сложностей в достижении совместимости состоит в том, что ICE полагается на распределенный алгоритм, работающий на обоих агентах, чтобы сходиться на согласованном наборе пар кандидатов. Если два агента используют разные алгоритмы, может быть сложно гарантировать сходимость на одних и тех же парах кандидатов. Процедура назначения, описанная в разделе 8, устраняет необходимость тесной координации, полностью делегируя алгоритм выбора контролирующему агенту, и ICE будет идеально сходиться, даже если оба агента используют разные алгоритмы приоритетов пар. Одним из ключей к такой конвергенции являются инициируемые проверки, которые гарантируют, что назначенная пара проверена обоими агентами.

ICE также расширяем для других потоков данных за пределами RTP и для транспортных протоколов за пределами UDP. В расширениях ICE для потоков данных, не относящихся к RTP, необходимо указать, сколько компонентов они используют, и назначить им идентификаторы компонентов, начиная с 1 для наиболее важного идентификатора компонента. Спецификации для новых транспортных протоколов ДОЛЖНЫ определять, как, если вообще, различные этапы обработки ICE отличаются от UDP.

14. Настройка Ta и RTO

14.1. Генеральный

На этапе сбора ICE (раздел 5.1.1) и в то время, когда ICE выполняет проверки подключения (раздел 7), агент ICE запускает транзакции STUN и TURN. Эти транзакции выполняются со скоростью, указанной Ta, и интервал повторной передачи для каждой транзакции вычисляется на основе таймера повторной передачи для транзакций STUN (RTO) [RFC5389].

В этом разделе описывается, как значения Ta и RTO вычисляются во время фазы сбора ICE и когда ICE выполняет проверки подключения.

ПРИМЕЧАНИЕ. Ранее в RFC 5245 были определены различные формулы для вычисления Ta и RTO в зависимости от того, использовался ли ICE для потока данных в реальном времени (например, RTP).

Приведенные ниже формулы приводят к тому, что агент будет отправлять свой первый пакет для каждой проверки подключения перед выполнением повторной передачи. Это можно увидеть в формулах для RTO (который представляет интервал повторной передачи). Эти формулы масштабируются с N, количество проверок, которые будут выполнены. В результате этого ICE поддерживает приятную постоянную скорость, но становится более чувствительной к потере пакетов. Потеря первого единственного пакета для любой проверки подключения, вероятно, приведет к тому, что этой паре потребуется много времени для проверки, и вместо этого проверка с более низким приоритетом (но для которой не было потери пакетов) гораздо более вероятна завершить первым. Это приводит к тому, что ICE работает неоптимально, выбирая пары с более низким приоритетом по сравнению с парами с более высоким приоритетом.

14.2. Ta

Агенты ICE ДОЛЖНЫ использовать значение Ta по умолчанию, 50 мс, но МОГУТ использовать другое значение, основанное на характеристиках связанных данных.

Если агент хочет использовать значение Ta, отличное от значения по умолчанию, агент ДОЛЖЕН указать предложенное значение своему партнеру во время установления сеанса ICE. Оба агента ДОЛЖНЫ использовать более высокое значение предложенных значений. Если агент не предлагает значение, для этого агента используется значение по умолчанию при сравнении того, какое значение выше.

Независимо от значения Ta, выбранного для каждого агента, комбинация всех транзакций от всех агентов (если в данной реализации запускается несколько одновременных агентов) НЕ ДОЛЖНА отправляться чаще, чем раз в 5 мс (как если бы было одно глобальное значение Ta для стимуляции). все агенты). См. Приложение B.1 для справки об использовании значения 5 мс с ICE.

ПРИМЕЧАНИЕ. В приложении C приведены примеры требуемой полосы пропускания с использованием различных значений Ta.

14.3. RTO

На этапе сбора ICE агенты ICE ДОЛЖНЫ рассчитывать значение RTO по следующей формуле:

RTO = MAX (500ms, Ta * (Num-Of-Cands))

Num-Of-Cands: количество серверно-рефлексивных и ретранслирующих кандидатов

Для проверки подключения агентам СЛЕДУЕТ рассчитывать значение RTO по следующей формуле:

RTO = MAX (500ms, Ta * N * (Num-Waiting + Num-In-Progress))

N: общее количество проверок подключения, которые должны быть выполнены.

Num-Waiting: количество проверок в контрольном списке, установленное в состоянии ожидания.

Num-In-Progress: количество проверок в контрольном списке, установленное в состоянии In-Progress.

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

Агенты МОГУТ рассчитать значение RTO с использованием других механизмов, отличных от описанных выше. Агенты НЕ ДОЛЖНЫ использовать значение RTO меньше 500 мс.

15. Примеры

В этом разделе показаны два примера ICE: один с использованием адресов IPv4 и один с использованием адресов IPv6.

Для облегчения понимания транспортные адреса перечислены с использованием переменных с мнемоническими именами. Формат имени: entity-type-seqno: «entity» относится к объекту, IP-адрес которого находится на транспортном адресе, и является одним из «L», «R», «STUN» или «NAT». Типом может быть «PUB» для транспортных адресов, которые являются общими, или «PRIV» для транспортных адресов, которые являются частными [RFC1918]. Наконец, seq-no — это порядковый номер, который отличается для каждого транспортного адреса одного и того же типа в конкретном объекте. Каждая переменная имеет IP-адрес и порт, обозначенные соответственно varname.IP и varname.PORT, где varname — это имя переменной.

В самом потоке вызовов сообщения STUN снабжены несколькими атрибутами. Атрибут «S =» указывает транспортный адрес источника сообщения. Атрибут «D =» указывает транспортный адрес назначения сообщения. Атрибут «MA =» используется в ответных сообщениях привязки STUN и относится к сопоставленному адресу. «USE-CAND» подразумевает наличие атрибута USE-CANDIDATE.

Примеры потока вызовов опускают операции аутентификации STUN и фокусируются на одном потоке данных между двумя полными реализациями.

15.1. Пример с адресами IPv4

В приведенном ниже примере используется топология, показанная на рисунке 7.

Рисунок 7 - Пример топологии
Рисунок 7 — Пример топологии

В этом примере агенты ICE L и R являются полными реализациями ICE. Оба агента имеют один IPv4-адрес, и оба настроены на один и тот же сервер STUN. NAT имеет свойство отображения, независимое от конечной точки, и свойство фильтрации, зависящее от адреса. IP-адреса агентов ICE, сервера STUN и NAT показаны ниже:

Рисунок 8 - Пример потока
Рисунок 8 — Пример потока

Сообщения 1-4: Агент L собирает кандидата от хоста со своего локального IP-адреса и с этого он отправляет запрос привязки STUN на сервер STUN. Запрос создает привязку NAT. Публичный IP-адрес NAT привязки становится кандидатом агента L на сервер.

Сообщение 5: Агент L отправляет информацию о своем локальном кандидате агенту R, используя протокол сигнализации, связанный с использованием ICE.

Сообщения 6-7: Агент R собирает кандидата от хоста со своего локального IP-адреса и с этого он отправляет запрос привязки STUN на сервер STUN. Поскольку агент R не находится за NAT, сервер-рефлексивный кандидат R будет идентичен кандидату на хост.

Сообщение 8: Агент R отправляет информацию о своем локальном кандидате агенту L, используя протокол сигнализации, связанный с использованием ICE.

Поскольку оба агента являются полными реализациями ICE, инициирующий агент (агент L) становится контролирующим агентом.

Агенты L и R объединяют кандидатов. Оба агента изначально имеют две пары. Тем не менее, агент L удалит пару, содержащую его серверно-рефлексивного кандидата, в результате чего получится только один (L1). В агенте L эта пара имеет локального кандидата в $ L_PRIV_1 и удаленного кандидата в $ R_PUB_1. У агента R две пары. Пара с наивысшим приоритетом (R1) имеет локального кандидата в $ R_PUB_1 и удаленного кандидата в $ L_PRIV_1, а вторая пара (R2) имеет локального кандидата в $ R_PUB_1 и удаленного кандидата в $ NAT_PUB_1. Пары показаны ниже (номера пар приведены только для справочных целей):

Агенты L и R объединяют кандидатов
Агенты L и R объединяют кандидатов

Сообщение 9: Агент R инициирует проверку соединения для пары # 2. Поскольку удаленным кандидатом пары является частный адрес агента L, проверка не будет успешной, так как запрос не может быть перенаправлен с R на L и будет отброшен сетью.

Сообщения 10-13: Агент L инициирует проверку соединения для пары L1. Проверка прошла успешно, и L создает новую пару (L2). Локальный кандидат в новую пару — $ NAT_PUB_1, а удаленный кандидат — $ R_PUB_1. Пара (L2) добавляется в действительный список агента L. Агент L теперь может отправлять и получать данные о паре (L2), если пожелает.

Агент L инициирует проверку соединения для пары L1
Агент L инициирует проверку соединения для пары L1

Сообщения 14-17: Когда агент R получает запрос Binding от агента L (сообщение 11), он инициирует инициированную проверку подключения. Пара соответствует одной из существующих пар агента R (R2). Проверка завершается успешно, и пара (R2) добавляется в действительный список агента R. Агент R теперь может отправлять и получать данные о паре (R2), если пожелает.

Агент R теперь может отправлять и получать данные о паре (R2), если пожелает
Агент R теперь может отправлять и получать данные о паре (R2), если пожелает

Сообщения 18-21: В какой-то момент контролирующий агент (агент L) решает назначить пару (L2) в действительный список. Он выполняет проверку подключения к паре (L2) и включает атрибут USE-CANDIDATE в запрос Binding. Когда проверка прошла успешно, агент L устанавливает значение назначенного флага пары (L2) в значение «истина», а агент R устанавливает значение назначенного флага соответствующей пары (R2) в значение «истина». Поскольку больше нет компонентов, связанных с потоком, назначенные пары становятся выбранными парами. Следовательно, обработка для этого потока переходит в состояние «Завершено». Процесс ICE также переходит в состояние «Завершено».

15.2. Пример с адресами IPv6

В приведенном ниже примере используется топология, показанная на рисунке 9.

Рисунок 9 - Пример топологии
Рисунок 9 — Пример топологии

В этом примере агенты ICE L и R являются полными реализациями ICE. Оба агента имеют один IPv6-адрес, и оба настроены на один и тот же сервер STUN. IP-адреса агентов ICE и сервера STUN показаны ниже:

Рисунок 10 - Пример потока
Рисунок 10 — Пример потока

Сообщения 1-2: Агент L собирает кандидата от хоста со своего локального IP-адреса и с этого он отправляет запрос привязки STUN на сервер STUN. Поскольку агент L не находится за NAT, кандидат-рефлексивный сервер L будет идентичен кандидату на хост.

Сообщение 3: Агент L отправляет информацию о своем локальном кандидате агенту R, используя протокол сигнализации, связанный с использованием ICE.

Сообщения 4-5: Агент R собирает кандидата от хоста со своего локального IP-адреса и с этого он отправляет запрос привязки STUN на сервер STUN. Поскольку агент R не находится за NAT, сервер-рефлексивный кандидат R будет идентичен кандидату на хост.

Сообщение 6: Агент R отправляет информацию о своем локальном кандидате агенту L, используя протокол сигнализации, связанный с использованием ICE.

Поскольку оба агента являются полными реализациями ICE, инициирующий агент (агент L) становится контролирующим агентом.

Агенты L и R объединяют кандидатов. Оба агента изначально имеют одну пару каждый. В агенте L пара (L1) имеет локального кандидата в $ L_PUB_1 и удаленного кандидата в $ R_PUB_1. В агенте R пара (R1) имеет локального кандидата в $ R_PUB_1 и удаленного кандидата в $ L_PUB_1. Пары показаны ниже (номера пар приведены только для справки):

Оба агента изначально имеют одну пару каждый
Оба агента изначально имеют одну пару каждый

Сообщения 7-8: Агент L инициирует проверку соединения для пары L1. Проверка прошла успешно, и пара (L1) добавлена в действительный список агента L. Агент L теперь может отправлять и получать данные о паре (L1), если пожелает.

Сообщения 7-8
Сообщения 7-8

Сообщения 9-10: Когда агент R получает запрос Binding от агента L (сообщение 7), он запускает инициированную проверку подключения. Пара соответствует существующей паре агента R (R1). Проверка успешна, и пара (R1) добавляется в действительный список агента R. Агент R теперь может отправлять и получать данные о паре (R1), если пожелает.

Сообщения 9-10
Сообщения 9-10

Сообщения 11-12: В какой-то момент контролирующий агент (агент L) решает назначить пару (L1) в действительный список. Он выполняет проверку подключения к паре (L1) и включает атрибут USE-CANDIDATE в запрос Binding. Когда проверка прошла успешно, агент L устанавливает значение назначенного флага пары (L1) в значение «истина», а агент R устанавливает значение назначенного флага соответствующей пары (R1) в значение «истина».

Поскольку больше нет компонентов, связанных с потоком, назначенные пары становятся выбранными парами. Следовательно, обработка для этого потока переходит в состояние «Завершено». Процесс ICE также переходит в состояние «Завершено».

16. Расширения STUN

16.1. Атрибуты

Эта спецификация определяет четыре атрибута STUN: PRIORITY, USE-CANDIDATE, ICE-CONTROLLED и ICE-CONTROLLING.

Атрибут PRIORITY указывает приоритет, который должен быть связан с рефлексивным кандидатом, если он будет обнаружен этой проверкой. Это 32-разрядное целое число без знака и значение атрибута 0x0024.

Атрибут USE-CANDIDATE указывает, что пара кандидатов, полученная в результате этой проверки, будет использоваться для передачи данных. Атрибут не имеет содержимого (поле длины атрибута равно нулю); это служит флагом. Он имеет значение атрибута 0x0025.

Атрибут ICE-CONTROLLED присутствует в запросе Binding. Атрибут указывает, что клиент считает, что в данный момент он находится в контролируемой роли. Содержимое атрибута представляет собой 64-разрядное целое число без знака в сетевом порядке байтов, которое содержит случайное число. Число используется для разрешения конфликтов ролей, когда оно упоминается как «значение разрешения конфликтов». Агент ICE ДОЛЖЕН использовать один и тот же номер для всех запросов Binding, для всех потоков в рамках сеанса ICE, если только он не получил ответ 487, и в этом случае он ДОЛЖЕН изменить номер (Раздел 7.2.5.1). Агент МОЖЕТ изменить номер при перезапуске ICE.

Атрибут ICE-CONTROLLING присутствует в запросе Binding. Атрибут указывает, что клиент считает, что в данный момент он играет контролирующую роль. Содержимое атрибута представляет собой 64-разрядное целое число без знака в сетевом порядке байтов, которое содержит случайное число. Что касается атрибута ICE-CONTROLLED, номер используется для разрешения конфликтов ролей. Агент ДОЛЖЕН использовать один и тот же номер для всех запросов Binding, для всех потоков в рамках сеанса ICE, если только он не получил ответ 487, и в этом случае он ДОЛЖЕН изменить номер (Раздел 7.2.5.1). Агент МОЖЕТ изменить номер при перезапуске ICE.

16.2. Новые коды ошибок и ответов

Эта спецификация определяет один код ответа об ошибке:

487 (Role Conflict): запрос Binding содержит атрибут ICECONTROLLING или ICE-CONTROLLED, указывающий роль ICE, которая конфликтует с сервером. Удаленный сервер сравнил значения разрешения конфликтов клиента и сервера и определил, что клиенту необходимо поменяться ролями.

17. Операционные соображения

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

17.1. Типы NAT и межсетевого экрана

ICE был разработан для работы с существующим оборудованием NAT и межсетевым экраном. Следовательно, нет необходимости заменять или перенастраивать существующее оборудование межсетевого экрана и NAT для облегчения развертывания ICE. Действительно, ICE был разработан для развертывания в средах, где оператор передачи голоса по IP (VoIP) не контролирует инфраструктуру IP-сети, включая межсетевые экраны и NAT.

Тем не менее, ICE лучше всего работает в средах, где устройства NAT «ведут себя» в соответствии с рекомендациями, определенными в [RFC4787] и [RFC5382]. В сетях с поведенческим NAT, ICE будет работать без необходимости сервера TURN, улучшая тем самым качество речи, сокращая время установления вызова и уменьшая требования к пропускной способности для оператора сети.

17.2. Требования к пропускной способности

Развертывание ICE может иметь несколько взаимодействий с доступной пропускной способностью сети, которые операторы должны учитывать.

17.2.1. STUN и TURN Планирование мощности сервера

Прежде всего, ICE использует серверы TURN и STUN, которые обычно расположены в центрах обработки данных. Для серверов STUN требуется относительно небольшая пропускная способность. Для каждого компонента каждого потока данных будет одна или несколько транзакций STUN с каждого клиента на сервер STUN. В базовом развертывании VoIP только для голоса IPv4 будет четыре транзакции на вызов (одна для RTP и одна для RTCP как для вызывающего, так и для вызываемого абонента). Каждая транзакция представляет собой один запрос и один ответ, первый из которых имеет длину 20 байтов, а второй — 28.

Следовательно, если в системе N пользователей, и каждый из них делает четыре звонка в час занятости, это потребует N * 1,7 бит / с. Для одного миллиона пользователей это 1,7 Мбит / с, что очень мало (условно говоря).

TURN трафик является более существенным. Сервер TURN будет видеть объем трафика, равный объему STUN (действительно, если серверы TURN развернуты, отдельного сервера STUN не требуется), в дополнение к трафику для фактических данных. Количество вызовов, требующих TURN для ретрансляции данных, сильно зависит от топологии сети и может изменяться с течением времени. В сети со 100% NAT-совместимым поведением он равен нулю.

Приведенные выше соображения планирования становятся более значимыми в мультимедийных сценариях (например, аудио- и видеоконференциях) и при увеличении числа участников сеанса.

17.2.2. Проверка сбора и подключения

Процесс сбора кандидатов и проверки подключений может быть интенсивным. ДВС был разработан для ускорения обоих этих процессов. Фазы сбора и проверки подключения предназначены для генерации трафика примерно с той же пропускной способностью, что и трафик данных, который будет потребляться после завершения процесса ICE. Это было сделано, чтобы гарантировать, что если сеть спроектирована для поддержки трафика связи определенного типа (голосовой, видео или просто текстовый), она будет иметь достаточную емкость для поддержки проверок ICE для этих данных. После того, как ICE завершит работу, последующие сообщения поддержки активности ICE позже приведут к незначительному увеличению общего использования полосы пропускания; однако это, как правило, будет очень небольшое увеличение.

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

17.2.3. Поддержка активность

Сообщения поддержки STUN (в форме индикации привязки STUN) отправляются в середине сеанса данных. Однако они отправляются только при отсутствии фактического трафика данных. В развертываниях с непрерывным мультимедиа и без использования Voice Activity Detection (VAD) или развертываниях, где VAD используется вместе с комфортным шумом с коротким интервалом (макс. 1 секунда), сообщения активности никогда не используются, и использование полосы пропускания не увеличивается. Когда VAD используется без комфортного шума, сообщения активности будут отправляться во время периодов молчания. Это включает в себя один пакет каждые 15-20 секунд, что намного меньше, чем пакет каждые 20-30 мс, который отправляется при наличии голоса. Следовательно, keepalive не оказывает реального влияния на планирование емкости.

17.3. ICE и ICE-Lite

Развертывания, использующие сочетание ICE и ICE-lite, взаимодействуют друг с другом. Они были специально разработаны для этого.

Однако ICE-lite может быть развернут только в ограниченных случаях использования. Эти случаи и оговорки, связанные с этим, описаны в Приложении А.

17.4. Устранение неполадок и управление производительностью

ICE использует сквозные проверки подключения и размещает большую часть обработки в конечных точках. Это создает проблему для оператора сети — как они могут устранять неполадки развертывания ICE? Как они могут знать, как работает ICE?

ICE имеет встроенные функции, помогающие справиться с этими проблемами. Серверы сигнализации, обычно размещаемые в центрах обработки данных оператора сети, будут видеть содержимое обменов-кандидатов, которые передают параметры ICE. Эти параметры включают тип каждого кандидата (хост, сервер рефлексивный или ретранслируемый), а также связанные с ними адреса. Как только обработка ICE завершена, происходит обновленный обмен кандидатами, сигнализирующий о выбранном адресе (и его типе). Эта обновленная сигнализация выполняется именно для целей обучения сетевого оборудования (например, диагностического инструмента, прикрепленного к сигнализации) о результатах обработки ICE.

Как следствие, через журналы, генерируемые сервером сигнализации, оператор сети может наблюдать, какие типы кандидатов используются для каждого вызова и какие адреса были выбраны ICE. Это основная информация, которая помогает оценить, как работает ICE.

17.5. Конфигурация конечной точки

ICE полагается на несколько частей данных, настраиваемых в конечных точках. Эти данные конфигурации включают в себя таймеры, учетные данные для серверов TURN и имена хостов для серверов STUN и TURN. Сам ICE не предоставляет механизм для этой конфигурации. Вместо этого предполагается, что эта информация привязана к любому механизму, который используется для настройки всех других параметров в конечной точке. Для SIP-телефонов были определены стандартные решения, такие как структура конфигурации [RFC6080].

18. Соображения IAB

IAB изучил проблему «односторонней фиксации самоадресации» (UNSAF), которая является общим процессом, посредством которого агент ICE пытается определить свой адрес в другой области на другой стороне NAT с помощью механизма отражения протокола совместной работы [ RFC3424]. ICE является примером протокола, который выполняет этот тип функции. Интересно, что процесс для ICE не односторонний, а двусторонний, и эта разница оказывает значительное влияние на вопросы, поднятые IAB. Действительно, ICE можно считать протоколом двусторонней фиксации адреса (B-SAF), а не протоколом UNSAF. Несмотря на это, IAB обязал, чтобы любые протоколы, разработанные для этой цели, документировали определенный набор соображений. Этот раздел соответствует этим требованиям.

18.1. Определение проблемы

Начиная с RFC 3424, любое предложение UNSAF должно содержать:

Точное определение конкретной проблемы ограниченного масштаба, которая должна быть решена с помощью предложения UNSAF. Краткосрочное исправление не следует обобщать для решения других проблем. Такие обобщения приводят к длительной зависимости и использованию предполагаемого краткосрочного исправления, что означает, что его уже нельзя назвать «краткосрочным».

Конкретные проблемы, решаемые ICE:

Предоставление средств для двух узлов для определения набора транспортных адресов, которые могут использоваться для связи.

Предоставление агенту средства для определения адреса, доступного другому партнеру, с которым он хочет связаться.

18.2. Стратегия отступления

Начиная с RFC 3424, любое предложение UNSAF должно содержать:

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

Сам ICE не так легко вывести из употребления. Тем не менее, даже в глобально подключенном Интернете полезно использовать, например, средство для обнаружения, если сбой маршрутизатора временно нарушил соединение. ICE также помогает предотвратить определенные атаки безопасности, которые не имеют ничего общего с NAT. Тем не менее, то, что делает ICE, это помочь свернуть другие механизмы UNSAF. ICE эффективно выбирает среди этих механизмов, отдавая приоритет тем, которые лучше, и удаляя приоритеты

что хуже. По мере того, как NAT начинает рассеиваться с появлением IPv6, сервер-рефлексивные и ретранслируемые кандидаты (обе формы адресов UNSAF) просто никогда не используются, поскольку существует возможность подключения с более высоким приоритетом для собственных кандидатов на хост. Таким образом, серверы используются все реже и реже и могут быть в конечном итоге удалены, когда их использование достигает нуля.

Действительно, ICE может помочь в переходе с IPv4 на IPv6. Его можно использовать для определения того, использовать ли IPv6 или IPv4, когда два хоста с двумя стеками обмениваются данными с SIP (используется IPv6). Он также может позволить сети с подключением как 6to4, так и собственной версией v6 определять, какой адрес использовать при связи с одноранговым узлом.

18.3. Хрупкость представленная ICE

Начиная с RFC 3424, любое предложение UNSAF должно содержать:

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

ICE фактически устраняет хрупкость существующих механизмов UNSAF. В частности, классический STUN (как описано в RFC 3489 [RFC3489]) имеет несколько точек хрупкости. Одним из них является процесс обнаружения, который требует, чтобы агент ICE попытался классифицировать тип NAT, за которым он находится. Этот процесс подвержен ошибкам. С ICE этот процесс обнаружения просто не используется. Вместо того, чтобы в одностороннем порядке оценивать действительность адреса, его действительность динамически определяется путем измерения возможности подключения к одноранговому узлу. Процесс определения связности очень надежен.

Еще одним недостатком классического STUN и любого другого одностороннего механизма является его абсолютная зависимость от дополнительного сервера. ICE использует сервер для распределения односторонних адресов, но позволяет агентам напрямую подключаться, если это возможно. Поэтому в некоторых случаях сбой сервера STUN по-прежнему допускает выполнение вызова при использовании ICE.

Еще одним недостатком классического STUN является то, что он предполагает, что сервер STUN находится в общедоступном Интернете. Интересно, что с ICE это не нужно. Там может быть множество серверов STUN в различных адресных сферах. ICE обнаружит тот, который предоставил полезный адрес.

Самым тревожным моментом хрупкости классического STUN является то, что он работает не во всех сетевых топологиях. В случаях, когда существует общий NAT между каждым агентом и сервером STUN, традиционный STUN может не работать. С ICE это ограничение снимается.

Классический STUN также вводит некоторые соображения безопасности. К счастью, эти соображения безопасности также смягчены ICE.

Следовательно, ICE служит для восстановления хрупкости, представленной в классическом STUN, и не вносит никакой дополнительной хрупкости в систему.

Наказанием этих улучшений является то, что ICE увеличивает время установления сеанса.

18.4. Требования к долгосрочному решению

Начиная с RFC 3424, любое предложение UNSAF должно содержать следующее:

Определить требования для долгосрочных, надежных технических решений; внести свой вклад в процесс поиска правильного долгосрочного решения.

Наши выводы из RFC 3489 остаются без изменений. Тем не менее, мы считаем, что ICE действительно помогает, потому что мы считаем, что это может быть частью долгосрочного решения.

18.5. Проблемы с существующими блоками NAPT

Начиная с RFC 3424, любое предложение UNSAF должно содержать:

Обсуждение влияния отмеченных практических вопросов на существующие, развернутые NA [P] Ts и отчеты об опыте.

В настоящее время на рынке развернуто несколько блоков NAT, которые пытаются обеспечить «универсальную» функциональность ALG. Эти общие ALG ищут IP-адреса в текстовом или двоичном виде внутри пакета и перезаписывают их, если они соответствуют привязке. Это мешает классическому STUN. Однако в обновлении STUN [RFC5389] используется кодировка, которая скрывает эти двоичные адреса от общих ALG.

Существующие блоки NAPT имеют недетерминированные и обычно короткие сроки действия для привязок на основе UDP. Это требует реализации для отправки периодических сообщений активности для поддержки этих привязок. ICE использует значение по умолчанию 15 с, что является очень консервативной оценкой. Со временем, по мере того, как блоки NAT станут совместимыми с поведением [RFC4787], этот минимум активности активности станет детерминированным и хорошо известным, и таймеры ICE можно будет настроить. Иметь способ обнаружить и контролировать минимальный интервал поддержки активности было бы еще лучше.

19. Вопросы безопасности

19.1. Конфиденциальность IP-адреса

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

Если эти потенциальные атаки не могут быть смягчены, использование ICE может определить механизмы для контроля того, какие адреса обнаружены в процессе согласования и / или проверки. Отдельные реализации могут также иметь специфичные для реализации правила для управления тем, какие адреса выявляются. Например, [WebRTC-IP-HANDLING] предоставляет дополнительную информацию об аспектах конфиденциальности раскрытия IP-адресов через ICE для приложений WebRTC. Реализации ICE, где могут возникнуть такие проблемы, РЕКОМЕНДУЕТСЯ предоставлять программный или пользовательский интерфейс, который обеспечивает контроль над тем, какие сетевые интерфейсы используются для генерации кандидатов.

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

Существует несколько типов атак, возможных в системе ICE. В подразделах рассматриваются эти атаки и их контрмеры.

19.2. Атаки на проверки подключения

Злоумышленник может попытаться нарушить проверки подключения STUN. В конечном итоге все эти атаки вводят агента ICE в заблуждение относительно неправильных результатов проверки подключений. В зависимости от типа атаки злоумышленник должен иметь различные возможности. В некоторых случаях злоумышленник должен быть на пути проверки подключения. В других случаях злоумышленнику не нужно находиться на пути, если он может генерировать проверки подключения STUN. Хотя атаки на проверки подключения обычно выполняются сетевыми объектами, если злоумышленник может контролировать конечную точку, он может инициировать атаки с проверкой подключения. Возможные ложные выводы, которые может предпринять злоумышленник:

  • False Invalid: злоумышленник может обмануть пару агентов, считая, что пара кандидатов недействительна, если это не так. Это может быть использовано для того, чтобы агент предпочел другого кандидата (например, введенного злоумышленником) или для прерывания вызова, заставив всех кандидатов потерпеть неудачу.
  • False Valid: злоумышленник может обмануть пару агентов, полагая, что пара кандидатов является действительной, если это не так. Это может привести к тому, что агент продолжит сеанс, но не сможет получить никаких данных.
  • False Peer-Reflexive Candidate: злоумышленник может заставить агента обнаружить нового рефлексивного кандидата, когда это не ожидается. Это может использоваться для перенаправления потоков данных на цель DoS или злоумышленнику, для прослушивания или других целей.
  • False Valid для False Candidate: злоумышленник уже убедил агента в том, что существует кандидат с адресом, который фактически не направляет его этому агенту (например, путем введения ложного peerreflexive кандидата или ложного сервера-рефлексивного кандидата). Затем атакующий запускает атаку, заставляющую агентов полагать, что этот кандидат действителен.
    Если злоумышленник может вызвать ложного кандидата с рефлексом или ложно действительного для ложного кандидата, он может запустить любую из атак, описанных в [RFC5389].

Чтобы получить ложный неверный результат, злоумышленник должен дождаться проверки соединения от одного из агентов, который будет отправлен. Когда это так, злоумышленнику необходимо ввести поддельный ответ с неисправимым ответом об ошибке (например, 400) или отбросить ответ, чтобы он никогда не достигал агента. Однако, поскольку кандидат фактически действителен, исходный запрос может достигнуть однорангового агента и привести к успешному ответу. Злоумышленник должен заставить этот пакет или его ответ быть отброшенным посредством DoS-атаки, нарушения работы сети уровня 2 или другого метода. Если этого не произойдет, ответ об успешном завершении также достигнет инициатора, предупреждая его о возможной атаке. Способность злоумышленника генерировать фальшивый ответ уменьшается с помощью механизма краткосрочных учетных данных STUN. Для обработки этого ответа злоумышленнику необходим пароль. Если сигнализация обмена кандидатами защищена, у злоумышленника не будет пароля, и его ответ будет отклонен.

Ложные ошибки ICMP (тип 3, коды 2-4) также можно использовать для создания ложных неверных результатов. Если агент ICE реализует ответ на эти ошибки ICMP, злоумышленник может генерировать сообщение ICMP, которое доставляется агенту, отправляющему проверку подключения. Проверка агентом сообщения об ошибке ICMP является его единственной защитой. Для кода типа 3 = 4 внешний заголовок IP не обеспечивает проверки, если только проверка соединения не была отправлена ​​с DF = 0. Для кодов 2 или 3, которые исходят от хоста, ожидается, что адрес будет любым из IP-адресов хоста, рефлексива или ретранслятора-кандидата удаленного агента. Сообщение ICMP включает в себя заголовок IP и заголовок UDP сообщения, инициирующего ошибку. Эти поля также должны быть проверены. IP-адрес и порт назначения UDP должны совпадать либо с адресом и портом целевого кандидата, либо с базовым адресом кандидата. Исходный IP-адрес и порт могут быть любыми кандидатами на один и тот же базовый адрес агента, отправляющего проверку подключения. Таким образом, любой злоумышленник, имеющий доступ к обмену кандидатами, будет иметь необходимую информацию. Следовательно, проверка является слабой защитой, и отправка поддельных ICMP-атак также возможна для злоумышленников вне пути с узла в сети без проверки адреса источника.

Форсирование поддельного действительного результата работает аналогичным образом. Злоумышленник должен дождаться запроса Binding от каждого агента и ввести поддельный ответ об успехе. Опять же, благодаря механизму краткосрочных учетных данных STUN, для того, чтобы злоумышленник ввел действительный ответ об успешном завершении, злоумышленнику требуется пароль. Альтернативно, злоумышленник может направить (например, используя механизм туннелирования) действительный ответ об успешном завершении, который обычно отбрасывается или отклоняется сетью, агенту.

Форсирование ложного результата-рефлекса кандидата может быть сделано либо с поддельными запросами или ответами, либо с повторениями. Мы сначала рассматриваем поддельные запросы и ответы. Он требует, чтобы злоумышленник отправил запрос Binding одному агенту с исходным IP-адресом и портом для ложного кандидата. Кроме того, злоумышленнику необходимо дождаться запроса Binding от другого агента и сгенерировать поддельный ответ с атрибутом XOR-MAPPED-ADDRESS, содержащим ложного кандидата. Как и другие атаки, описанные здесь, эта атака смягчается механизмами целостности сообщений STUN и безопасными обменами кандидатами.

Форсирование ложного однорангового результата-кандидата с повторениями пакетов отличается. Злоумышленник ждет, пока один из агентов не отправит чек. Он перехватывает этот запрос и передает его другому агенту с поддельным IP-адресом источника. Также необходимо предотвратить исходный запрос от достижения удаленного агента, либо запустив DoS-атаку, чтобы вызвать отбрасывание пакета, либо принудительно отбросив его с использованием механизмов уровня 2. Воспроизведенный пакет принимается другим агентом и принимается, поскольку проверка целостности проходит (проверка целостности не может и не охватывает исходный IP-адрес и порт). Затем ответили. Этот ответ будет содержать XORMAPPED-ADDRESS с ложным кандидатом, и он будет отправлен этому ложному кандидату. Затем злоумышленник должен получить его и направить к отправителю.

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

Эту атаку очень сложно запустить, если злоумышленник не опознан поддельным кандидатом. Это связано с тем, что злоумышленнику требуется перехватывать и воспроизводить пакеты, отправленные двумя разными хостами. Если оба агента находятся в разных сетях (например, в общедоступном Интернете), эту атаку может быть сложно координировать, поскольку она должна осуществляться по двум разным конечным точкам в разных частях сети одновременно.

Если злоумышленник идентифицирует самого атакующего, атаку легче координировать. Однако, если путь данных защищен (например, с использованием безопасного транспортного протокола реального времени (SRTP) [RFC3711]), злоумышленник не сможет обработать пакеты данных, но сможет только отбросить их, эффективно отключив поток данных. Однако эта атака требует, чтобы агент прерывал пакеты, чтобы заблокировать проверку соединения от достижения цели. В этом случае, если целью является нарушение потока данных, гораздо проще просто нарушить его тем же механизмом, чем атаковать ICE.

19.3. Атаки на сервер-рефлексивный сбор адресов

Конечные точки ICE используют запросы привязки STUN для сбора серверно-рефлексивных кандидатов с сервера STUN. Эти запросы никак не аутентифицированы. Как следствие, существует множество методов, которые злоумышленник может использовать, чтобы предоставить клиенту ложный сервер-рефлексивный кандидат:

  • Злоумышленник может скомпрометировать DNS, в результате чего DNS-запросы возвращают адрес мошеннического сервера STUN. Этот сервер может предоставить клиенту поддельные серверно-рефлексивные кандидаты. Эта атака смягчается безопасностью DNS, хотя DNSSEC не требуется для ее устранения.
  • Злоумышленник, который может наблюдать за сообщениями STUN (например, злоумышленник в сегменте общей сети, например, Wi-Fi), может ввести поддельный ответ, который действителен и будет принят клиентом.
  • Злоумышленник может скомпрометировать сервер STUN и заставить его отправлять ответы с неверно сопоставленными адресами.

Ложно сопоставленный адрес, полученный этими атаками, будет использоваться в качестве серверно-рефлексивного кандидата при установлении сеанса ICE. Чтобы этот кандидат фактически использовался для данных, злоумышленнику также необходимо атаковать проверки подключения и, в частности, принудительно ввести ложную действительность для ложного кандидата. Эту атаку очень сложно запустить, если ложный адрес идентифицирует четвертую сторону (ни инициатора, ни ответчика, ни злоумышленника), поскольку требует атаки проверок, генерируемых каждым агентом ICE в сеансе, и предотвращается SRTP, если он идентифицирует злоумышленника сам.

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

19.4. Атаки на ретранслируемый сбор кандидатов

Злоумышленник может попытаться сорвать сбор ретранслируемых кандидатов, заставив клиента поверить, что у него есть ложный ретранслятор. Обмен с сервером TURN проходит проверку подлинности с использованием долгосрочных учетных данных. Следовательно, внедрение поддельных ответов или запросов не будет работать. Кроме того, в отличие от запросов Binding, запросы Allocate не подвержены атакам воспроизведения с измененными исходными IP-адресами и портами, поскольку исходный IP-адрес и порт не используются для предоставления клиенту своего ретранслируемого кандидата.

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

19.5. Инсайдерские атаки

Помимо атак, когда злоумышленник является третьей стороной, пытающейся вставить поддельную информацию о кандидате или сообщения STUN, возможны атаки с использованием ICE, когда злоумышленник является аутентифицированным и действительным участником обмена ICE.

19.5.1. Усиление атаки STUN

Атака с усилением STUN похожа на атаку «голосовым молотом», когда злоумышленник заставляет других агентов направлять голосовые пакеты к цели атаки. Однако вместо того, чтобы голосовые пакеты были направлены к цели, проверки подключения STUN направлены к цели. Злоумышленник отправляет большое количество кандидатов, скажем, 50. Отвечающий агент получает информацию о кандидате и начинает свои проверки, которые направлены на цель, и, следовательно, никогда не генерируют ответ. В случае WebRTC пользователь может даже не знать, что эта атака продолжается, поскольку она может быть инициирована в фоновом режиме вредоносным кодом JavaScript, который пользователь получил. Ответчик начинает новую проверку подключения каждые Ta мс (скажем, Ta = 50 мс). Однако таймеры повторной передачи установлены на большое количество из-за большого количества кандидатов. Как следствие, пакеты будут отправляться с интервалом в одну миллисекунду Ta, а затем с увеличивающимися интервалами после этого. Таким образом, STUN не будет отправлять пакеты со скоростью, превышающей скорость отправки данных, и пакеты STUN сохраняются только кратковременно, пока не произойдет сбой ICE для сеанса. Тем не менее, это механизм усиления.

Устранить усиление невозможно, но объем можно уменьшить с помощью различных эвристик. Агенты ICE ДОЛЖНЫ ограничить общее количество проверок подключений, которые они выполняют, до 100. Кроме того, агенты МОГУТ ограничить число кандидатов, которых они примут.

Часто протоколы, которые хотят избежать атак такого рода, заставляют инициатора ждать ответа перед отправкой следующего сообщения. Однако в случае ICE это невозможно. Невозможно выделить следующие два случая:

  • Ответа не было, потому что инициатор используется для запуска DoS-атаки против ничего не подозревающей цели, которая не будет отвечать.
  • Ответа не было, поскольку IP-адрес и порт недоступны для инициатора.

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

20. Соображения IANA

Исходная спецификация ICE зарегистрировала четыре атрибута STUN и один новый ответ об ошибке STUN. Атрибуты STUN и ответ об ошибке воспроизводятся здесь. Кроме того, эта спецификация регистрирует новую опцию ICE.

20.1. Атрибуты STUN

IANA зарегистрировала четыре атрибута STUN:

0x0024 PRIORITY
0x0025 USE-CANDIDATE
0x8029 ICE-CONTROLLED
0x802A ICE-CONTROLLING

20.2. Ответы на ошибки STUN

IANA зарегистрировала следующий код ответа на ошибку STUN:

487 Конфликт ролей: клиент утвердил роль ICE (контролирующую или контролируемую), которая находится в конфликте с ролью сервера.

20.3. Варианты ICE

IANA зарегистрировала следующую опцию ICE в подсистеме «Опции ICE» реестра «Установление интерактивного подключения (ICE)», следуя процедурам, определенным в [RFC6336].

Название опции ICE: ice2

Контакт: Имя: IESG, Электронная почта: iesg@ietf.org

Смена контроллера: IESG

Описание. Параметр ICE указывает, что агент ICE, использующий параметр ICE, реализован в соответствии с RFC 8445.

Ссылка: RFC 8445

21. Отличия от RFC 5245

Целью этой обновленной спецификации ICE является:

  • Уточнение процедур в RFC 5245.
  • Внести технические изменения в связи с обнаруженными недостатками в RFC 5245 и отзывами сообщества, которое внедрило и развернуло приложения ICE на основе RFC 5245.
  • Сделать процедуры независимыми от протокола сигнализации, удалив процедуры SIP и SDP. Процедуры, специфичные для протокола сигнализации, будут определены в отдельных документах об использовании. [ICE-SIP-SDP] определяет использование ICE с SIP и SDP.

Следующие технические изменения были сделаны:

  • Агрессивная номинация удалена.
  • Изменены процедуры расчета состояний пары кандидатов и планирования проверок связности.
  • Процедуры расчета Ta и RTO изменены.
  • Удалены определения активных контрольных списков и замороженных контрольных списков.
  • » ice2 » Добавлена опция ICE.
  • Изменены соображения IPv6.
  • Использование без поддержки для keepalive и keepalive с не-ICE одноранговыми узлами удалено.

22. Ссылки

22.1. Нормативные ссылки

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC4941] Narten, T., Draves, R., and S. Krishnan, «Privacy Extensions for Stateless Address Autoconfiguration in IPv6», RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>.

[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, «Session Traversal Utilities for NAT (STUN)», RFC 5389, DOI 10.17487/RFC5389, October 2008,
<https://www.rfc-editor.org/info/rfc5389>.

[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, «Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)», RFC 5766,
DOI 10.17487/RFC5766, April 2010, <https://www.rfc-editor.org/info/rfc5766>.

[RFC6336] Westerlund, M. and C. Perkins, «IANA Registry for Interactive Connectivity Establishment (ICE) Options», RFC 6336, DOI 10.17487/RFC6336, July 2011,
<https://www.rfc-editor.org/info/rfc6336>.

[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, «Default Address Selection for Internet Protocol Version 6 (IPv6)», RFC 6724, DOI 10.17487/RFC6724, September 2012, <https://www.rfc-editor.org/info/rfc6724>.

[RFC8174] Leiba, B., «Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words», BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

22.2. Информационные ссылки

[ICE-SIP-SDP] Petit-Huguenin, M., Nandakumar, S., and A. Keranen, «Session Description Protocol (SDP) Offer/Answer procedures for Interactive Connectivity Establishment
(ICE)», Work in Progress, draft-ietf-mmusic-ice-sip-sdp-21, June 2018.

[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, «Address Allocation for Private Internets», BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<https://www.rfc-editor.org/info/rfc1918>.

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, «An Architecture for Differentiated Services», RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/info/rfc2475>.

[RFC3102] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, «Realm Specific IP: Framework», RFC 3102, DOI 10.17487/RFC3102, October 2001,
<https://www.rfc-editor.org/info/rfc3102>.

[RFC3103] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, «Realm Specific IP: Protocol Specification», RFC 3103, DOI 10.17487/RFC3103, October 2001,
<https://www.rfc-editor.org/info/rfc3103>.

[RFC3235] Senie, D., «Network Address Translator (NAT)-Friendly Application Design Guidelines», RFC 3235, DOI 10.17487/RFC3235, January 2002,
<https://www.rfc-editor.org/info/rfc3235>.

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, «SIP: Session Initiation Protocol», RFC 3261, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>.

[RFC3264] Rosenberg, J. and H. Schulzrinne, «An Offer/Answer Model with Session Description Protocol (SDP)», RFC 3264, DOI 10.17487/RFC3264, June 2002,
<https://www.rfc-editor.org/info/rfc3264>.

[RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, «Middlebox communication architecture and framework», RFC 3303, DOI 10.17487/RFC3303, August 2002,
<https://www.rfc-editor.org/info/rfc3303>.

[RFC3424] Daigle, L., Ed. and IAB, «IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation», RFC 3424, DOI 10.17487/RFC3424,
November 2002, <https://www.rfc-editor.org/info/rfc3424>.

[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, «STUN — Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)», RFC 3489,
DOI 10.17487/RFC3489, March 2003, <https://www.rfc-editor.org/info/rfc3489>.

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, «RTP: A Transport Protocol for Real-Time Applications», STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <https://www.rfc-editor.org/info/rfc3550>.

[RFC3605] Huitema, C., «Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)», RFC 3605, DOI 10.17487/RFC3605, October 2003,
<https://www.rfc-editor.org/info/rfc3605>.

[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, «The Secure Real-time Transport Protocol (SRTP)», RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>.

[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, «Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)»,
BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004, <https://www.rfc-editor.org/info/rfc3725>.

[RFC3879] Huitema, C. and B. Carpenter, «Deprecating Site Local Addresses», RFC 3879, DOI 10.17487/RFC3879, September 2004, <https://www.rfc-editor.org/info/rfc3879>.

[RFC4038] Shin, M-K., Ed., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, «Application Aspects of IPv6 Transition», RFC 4038, DOI 10.17487/RFC4038, March 2005,
<https://www.rfc-editor.org/info/rfc4038>.

[RFC4091] Camarillo, G. and J. Rosenberg, «The Alternative Network Address Types (ANAT) Semantics for the Session Description Protocol (SDP) Grouping Framework», RFC 4091,
DOI 10.17487/RFC4091, June 2005, <https://www.rfc-editor.org/info/rfc4091>.

[RFC4092] Camarillo, G. and J. Rosenberg, «Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol
(SIP)», RFC 4092, DOI 10.17487/RFC4092, June 2005, <https://www.rfc-editor.org/info/rfc4092>.

[RFC4103] Hellstrom, G. and P. Jones, «RTP Payload for Text Conversation», RFC 4103, DOI 10.17487/RFC4103, June 2005, <https://www.rfc-editor.org/info/rfc4103>.

[RFC4291] Hinden, R. and S. Deering, «IP Version 6 Addressing Architecture», RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.

[RFC4566] Handley, M., Jacobson, V., and C. Perkins, «SDP: Session Description Protocol», RFC 4566, DOI 10.17487/RFC4566, July 2006, <https://www.rfc-editor.org/info/rfc4566>.

[RFC4787] Audet, F., Ed. and C. Jennings, «Network Address Translation (NAT) Behavioral Requirements for Unicast UDP», BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <https://www.rfc-editor.org/info/rfc4787>.

[RFC5245] Rosenberg, J., «Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols», RFC 5245,
DOI 10.17487/RFC5245, April 2010, <https://www.rfc-editor.org/info/rfc5245>.

[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, «NAT Behavioral Requirements for TCP», BCP 142, RFC 5382, DOI 10.17487/RFC5382, October 2008,
<https://www.rfc-editor.org/info/rfc5382>.

[RFC5761] Perkins, C. and M. Westerlund, «Multiplexing RTP Data and Control Packets on a Single Port», RFC 5761, DOI 10.17487/RFC5761, April 2010,
<https://www.rfc-editor.org/info/rfc5761>.

[RFC6080] Petrie, D. and S. Channabasappa, Ed., «A Framework for Session Initiation Protocol User Agent Profile Delivery», RFC 6080, DOI 10.17487/RFC6080, March 2011,
<https://www.rfc-editor.org/info/rfc6080>.

[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, «Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers», RFC 6146, DOI 10.17487/RFC6146, April 2011, <https://www.rfc-editor.org/info/rfc6146>.

[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, «DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers», RFC 6147,
DOI 10.17487/RFC6147, April 2011, <https://www.rfc-editor.org/info/rfc6147>.

[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, «Computing TCP’s Retransmission Timer», RFC 6298, DOI 10.17487/RFC6298, June 2011,
<https://www.rfc-editor.org/info/rfc6298>.

[RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, «TCP Candidates with Interactive Connectivity Establishment (ICE)», RFC 6544, DOI 10.17487/RFC6544,
March 2012, <https://www.rfc-editor.org/info/rfc6544>.

[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, «Increasing TCP’s Initial Window», RFC 6928, DOI 10.17487/RFC6928, April 2013,
<https://www.rfc-editor.org/info/rfc6928>.

[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, «Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis», RFC 7050, DOI 10.17487/RFC7050, November 2013, <https://www.rfc-editor.org/info/rfc7050>.

[RFC7721] Cooper, A., Gont, F., and D. Thaler, «Security and Privacy Considerations for IPv6 Address Generation Mechanisms», RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>.

[RFC7825] Goldberg, J., Westerlund, M., and T. Zeng, «A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP)»,
RFC 7825, DOI 10.17487/RFC7825, December 2016, <https://www.rfc-editor.org/info/rfc7825>.

[RFC8421] Martinsen, P., Reddy, T., and P. Patil, «Interactive Connectivity Establishment (ICE) Multihomed and IPv4/IPv6 Dual-Stack Guidelines», RFC 8421, DOI 10.17487/RFC8421,
July 2018, <https://www.rfc-editor.org/info/rfc8421>.

[WebRTC-IP-HANDLING] Uberti, J. and G. Shieh, «WebRTC IP Address Handling Requirements», Work in Progress, draft-ietf-rtcweb-iphandling-09, June 2018.

Приложение А. Облегченная и полная реализация

ICE допускает два типа реализаций. Полная реализация поддерживает управляющие и контролируемые роли в сеансе, а также может выполнять сбор адресов. Напротив, облегченная реализация — это минималистская реализация, которая мало что делает, но реагирует на проверки STUN, и поддерживает только контролируемую роль в сеансе.

Поскольку ICE требует, чтобы обе конечные точки поддерживали его, чтобы обеспечить преимущества для любой конечной точки, поэтапное развертывание ICE в сети является более сложным. Во многих сеансах используется конечная точка, которая сама по себе не находится за NAT и не беспокоится о прохождении NAT. Очень распространенный случай — одна конечная точка, требующая обхода NAT (например, жесткий телефон VoIP или программный телефон), выполняет вызов на одно из этих устройств. Даже если телефон поддерживает полную реализацию ICE, ICE не будет использоваться вообще, если другое устройство не поддерживает его. Облегченная реализация обеспечивает недорогую точку входа для этих устройств. Как только они поддерживают облегченную реализацию, к ним могут подключиться полные реализации и получить все преимущества ICE.

Следовательно, облегченная реализация подходит только для устройств, которые будут * всегда * подключаться к общедоступному Интернету и иметь общедоступный IP-адрес, по которому он может получать пакеты от любого корреспондента. ICE не будет работать, когда облегченная реализация находится за NAT.

ICE позволяет облегченной реализации иметь одного кандидата на хост IPv4 и несколько адресов IPv6. В этом случае пары кандидатов выбираются управляющим агентом с использованием статического алгоритма, такого как алгоритм в RFC 6724, который рекомендуется в этой спецификации. Однако статические механизмы выбора адресов всегда подвержены ошибкам, поскольку они никогда не могут отражать фактическую топологию или предоставлять реальные гарантии подключения. Это всегда эвристика. Следовательно, если агент ICE внедряет ICE просто для выбора между своими адресами IPv4 и IPv6, и ни один из его IP-адресов не находится за NAT, использование полного ICE по-прежнему РЕКОМЕНДУЕТСЯ для обеспечения наиболее надежной формы выбора адресов.

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

Приложение В. Мотивация дизайна

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

B.1. Стимуляция транзакций STUN

Транзакции STUN, используемые для сбора кандидатов и проверки возможности подключения, выполняются с приблизительной скоростью одной новой транзакции каждые Ta миллисекунды. Каждая транзакция, в свою очередь, имеет таймер повторной передачи RTO, который также является функцией Ta. Почему выполняются эти транзакции и почему используются эти формулы?

Отправка этих запросов STUN часто приводит к созданию привязок на устройствах NAT между клиентом и серверами STUN. Опыт показывает, что многие устройства NAT имеют верхние пределы скорости, с которой они создают новые привязки. Обсуждения в IETF ICE WG во время работы над этой спецификацией показали, что раз в 5 мс хорошо поддерживается. Вот почему Та имеет нижнюю границу 5 мс. Кроме того, передача этих пакетов в сети использует полосу пропускания и должна быть ограничена скоростью агентом ICE. Развертывания, основанные на более ранних черновых версиях [RFC5245], имели тенденцию перегружать каналы доступа с ограниченной скоростью и в целом работают плохо, в дополнение к негативному влиянию на сеть. Как следствие, стимуляция гарантирует, что устройство NAT не будет перегружено и что трафик будет поддерживаться с разумной скоростью.

Определение «разумной» скорости состоит в том, что STUN НЕ ДОЛЖЕН использовать больше полосы пропускания, чем будет использовать сам RTP, как только начнут поступать данные. Формула для Ta разработана таким образом, что если бы пакет STUN отправлялся каждые Ta секунд, он занимал бы столько же пропускной способности, что и пакеты RTP, суммируемые по всем потокам данных. Конечно, у STUN есть ретрансляторы, и их стремление также ускорить. По этой причине RTO устанавливается так, что первая повторная передача в первой транзакции происходит так же, как и первый запрос STUN в последней транзакции. Наглядно:

RTO устанавливается так, что первая повторная передача в первой транзакции происходит так же, как и первый запрос STUN в последней транзакции
RTO устанавливается так, что первая повторная передача в первой транзакции происходит так же, как и первый запрос STUN в последней транзакции

На этом рисунке будут отправлены три транзакции (например, в случае сбора кандидатов есть три пары хост-кандидат / сервер STUN). Это транзакции A, B и C. Таймер повторной передачи установлен так, что первая повторная передача в первой транзакции (пакет A2) отправляется в момент времени 3Ta.

Последующие повторные передачи после первой будут происходить даже реже, чем через миллисекунды Ta, поскольку STUN использует экспоненциальный откат при повторных передачах.

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

o Начните со следующих правил, которые обычно применяются к транспортным протоколам:
1. Пусть MaxBytes будет максимальным числом байтов, разрешенных для выдачи в сети при запуске, которое ДОЛЖНО быть 14600, как определено в Разделе 2 [RFC6928].
2. Пусть HTO будет тайм-аутом транзакции, который ДОЛЖЕН быть 2 * RTT, если RTT известен, или 500 мс в противном случае. Это основано на RTO для сообщений STUN от [RFC5389] и начальном RTO TCP, которое составляет 1 секунду в [RFC6298].
3. Пусть MinPacing будет минимальным интервалом между транзакциями, который составляет 5 мс (см. Выше).

o Обратите внимание, что агенты, как правило, не знают RTT для транзакций ICE (в частности, проверки подключения), что означает, что HTO почти всегда будет 500 мс.
o Обратите внимание, что MinPacing 5 мс и HTO 500 мс дает максимум 100 пакетов / HTO, что для типичной проверки ICE менее 120 байтов означает максимум 12000 ожидающих байтов в сети, что меньше, чем максимально выраженный по правилу 1.
o Таким образом, для ICE набор правил сводится только к правилу MinPacing, что эквивалентно глобальному значению Ta.

В.2. Кандидаты с несколькими основаниями

В разделе 5.1.3 говорится об исключении кандидатов, имеющих одинаковый транспортный адрес и базу. Однако кандидаты с одинаковыми транспортными адресами, но разными базами не являются избыточными. Когда агент ICE может иметь двух кандидатов, которые имеют одинаковый IP-адрес и порт, но разные базы? Рассмотрим топологию на рисунке 11:

Рисунок 11 - Идентичные кандидаты с разными основаниями
Рисунок 11 — Идентичные кандидаты с разными основаниями

В этом случае инициирующий агент является многослойным. Он имеет один IP-адрес 10.0.1.100 в сети C, которая является чистой частной сетью 10. Ответящий агент находится в той же сети. Инициирующий агент также подключен к сети A, которая является 192.168 / 16, и имеет IP-адрес 192.168.1.100. В этой сети есть NAT, подключающийся к сети B, которая является еще одной частной сетью 10, но она не подключена к сети C. В сети B имеется сервер STUN.

Инициирующий агент получает кандидата на хост на своем IP-адресе в сети C (10.0.1.100:2498) и кандидата на хост на своем IP-адресе в сети A (192.168.1.100:3344). Он выполняет запрос STUN к сконфигурированному серверу STUN с 192.168.1.100:3344. Этот запрос проходит через NAT, который назначает привязку 10.0.1.100:2498. Сервер STUN отражает это в ответе STUN Binding. Теперь инициирующий агент получил сервер-рефлексивного кандидата с транспортным адресом, идентичным хост-кандидату (10.0.1.100:2498). Однако сервер-рефлексивный кандидат имеет базу 192.168.1.100:3344, а хост-кандидат имеет базу 10.0.1.100:2498.

Атрибут-кандидат содержит два значения, которые вообще не используются самим ICE — связанный адрес и связанный порт. Почему они присутствуют?

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

Вторая причина связана с механизмами качества обслуживания (QoS) вне тракта. Когда ICE используется в таких средах, как PacketCable 2.0, прокси-серверы, в дополнение к выполнению обычных операций SIP, проверяют SDP в сообщениях SIP и извлекают IP-адрес и порт для трафика данных. Затем они могут взаимодействовать через серверы политики с маршрутизаторами доступа в сети, чтобы установить гарантированное QoS для потоков данных. Это QoS обеспечивается путем классификации трафика RTP на основе 5-кратного набора и последующего предоставления ему гарантированной скорости или соответствующей маркировки его DSCP. Когда присутствует локальный NAT, и ретранслируемый кандидат выбирается для данных, этот ретранслируемый кандидат будет транспортным адресом на фактическом сервере TURN. Этот адрес ничего не говорит о фактическом транспортном адресе в маршрутизаторе доступа, который будет использоваться для классификации пакетов для обработки QoS. Скорее, сервер-рефлексивный кандидат на сервер TURN необходим. Передавая трансляцию в SDP, прокси-сервер может использовать этот транспортный адрес для запроса QoS от маршрутизатора доступа.

В.4. Важность имени пользователя STUN

ICE требует использования целостности сообщения с STUN с использованием его краткосрочной функциональности учетных данных. Фактические краткосрочные учетные данные формируются путем обмена фрагментами имени пользователя в обмене кандидатами. Необходимость в этом механизме выходит за рамки просто безопасности; это на самом деле требуется для правильной работы ДВС в первую очередь.

Предположим, что агенты ICE L, R и Z. L и R находятся в частном предприятии 1, которое использует 10.0.0.0/8. Z находится в частном предприятии 2, которое также использует 10.0.0.0/8. Как оказалось, R и Z оба имеют IP-адрес 10.0.1.1. L отправляет кандидатов в Z. Z отвечает L своими кандидатами в хост. В этом случае кандидатами являются 10.0.1.1:8866 и 10.0.1.1:8877. Как выясняется, в это же время R находится в сеансе и также использует 10.0.1.1:8866 и 10.0.1.1:8877 в качестве кандидатов на хост. Это означает, что R готов принять сообщения STUN на этих портах, как и Z. L отправит запрос STUN на 10.0.1.1:8866, а другой на 10.0.1.1:8877. Тем не менее, они не идут к Z, как ожидалось. Вместо этого они идут в R! Если бы R просто ответил на них, L поверил бы, что у него есть связь с Z, тогда как на самом деле он имеет связь с совершенно другим пользователем R. Для исправления этого используются STUN краткосрочные учетные механизмы. Фрагменты имени пользователя достаточно случайны; таким образом, весьма маловероятно, что R будет использовать те же значения, что и Z. Следовательно, R отклонит запрос STUN, поскольку учетные данные были недействительными. По сути, фрагменты имени пользователя STUN предоставляют форму временных идентификаторов хоста, привязанных к конкретному сеансу, установленному как часть обмена кандидатами.

К сожалению, следствием неединственности IP-адресов является то, что в приведенном выше примере R может даже не быть агентом ICE. Это может быть любой хост, а порт, на который направлен пакет STUN, может быть любым эфемерным портом на этом хосте. Если в этом сокете есть приложение, прослушивающее пакеты, и оно не готово обработать искаженные пакеты для любого используемого протокола, это может повлиять на работу этого приложения. К счастью, поскольку обмениваемые порты эфемерны и обычно извлекаются из динамического или зарегистрированного диапазона, велика вероятность того, что порт не используется для запуска сервера на хосте R, а скорее является агентской стороной какого-либо протокола. Это уменьшает вероятность попадания в выделенный порт из-за переходного характера использования порта в этом диапазоне. Тем не менее, возможность проблемы существует, и сетевые развертыватели должны быть готовы к ней. Обратите внимание, что это не проблема, специфичная для ICE; Случайные пакеты могут прибыть в порт в любое время для любого типа протокола, особенно в общедоступном Интернете. Таким образом, это требование лишь повторяет общее руководство по проектированию для интернет-приложений — будьте готовы к неизвестным пакетам на любом порту.

В.5. Формула приоритета пары кандидатов

Приоритет для пары кандидатов имеет нечетную форму. Это:

pair priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)

Почему это? Когда пары кандидатов сортируются на основе этого значения, результирующая сортировка имеет свойство MAX / MIN. Это означает, что пары сначала сортируются на основе уменьшения значения минимума двух приоритетов. Для пар, имеющих одинаковое значение минимального приоритета, максимальный приоритет используется для сортировки между ними. Если максимальный и минимальный приоритеты совпадают, приоритет контролирующего агента используется в качестве прерывателя связей в последней части выражения. Коэффициент 2 * 32 используется, так как приоритет одного кандидата всегда меньше, чем 2 * 32, в результате чего приоритет пары является «объединением» двух приоритетов компонентов. Это создает сортировку MAX / MIN. MAX / MIN гарантирует, что для конкретного агента ICE кандидат с более низким приоритетом никогда не используется, пока не будут опробованы все кандидаты с более высоким приоритетом.

В.6. Зачем нужны Keepalive?

Как только данные начинают передаваться по паре кандидатов, по-прежнему необходимо поддерживать привязки в промежуточных NAT на время сеанса. Обычно сами пакеты потока данных (например, RTP) соответствуют этой цели. Однако несколько случаев заслуживают дальнейшего обсуждения. Во-первых, в некоторых случаях использования RTP, таких как SIP, потоки данных могут быть «приостановлены». Это достигается с помощью атрибутов SDP «sendonly» или «неактивный», как определено в RFC 3264 [RFC3264]. RFC 3264 предписывает реализациям прекратить передачу данных в этих случаях. Однако это может привести к истечению времени ожидания привязки NAT, и данные не смогут быть заблокированы.

Во-вторых, некоторые форматы полезной нагрузки RTP, такие как формат полезной нагрузки для текстового диалога [RFC4103], могут отправлять пакеты так редко, что интервал превышает таймауты привязки NAT.

В-третьих, если используется подавление молчания, длительные периоды молчания могут привести к тому, что передача данных прекратится достаточно долго для тайм-аутов привязок NAT.

По этим причинам на сами пакеты данных нельзя положиться. ICE определяет простую периодическую поддержку активности с использованием индикации привязки STUN. Это делает его требования к пропускной способности очень предсказуемыми и, следовательно, поддающимися резервированию QoS.

В.7. Почему предпочитают рефлексивных кандидатов?

В разделе 5.1.2 описаны процедуры вычисления приоритета кандидата на основе его типа и локальных предпочтений. В этом разделе требуется, чтобы предпочтение типа для одноранговых рефлексивных кандидатов всегда было выше, чем для рефлексивного сервера. Это почему? Причина связана с соображениями безопасности, приведенными в разделе 19. Злоумышленнику гораздо проще заставить агента ICE использовать ложного кандидата с рефлексом на сервере, а не ложного рефлексивного кандидата. Следовательно, атаки на сбор адресов с помощью запросов Binding предотвращаются ICE, так как они предпочитают кандидатов с рефлексивной привязкой.

В.8. Почему обязательные показания используются для Keepalive?

Средства поддержки данных описаны в разделе 11. Эти средства поддержки используют STUN, когда обе конечные точки поддерживают ICE. Однако вместо использования транзакции запроса Binding (которая генерирует ответ) сообщения поддержки активности используют индикацию. Это почему?

Основная причина связана с сетевыми механизмами QoS. Как только данные начнут поступать, элементы сети будут предполагать, что поток данных имеет довольно регулярную структуру, используя периодические пакеты с фиксированными интервалами, с возможностью дрожания. Если агент ICE отправляет пакеты данных, а затем получает запрос Binding, ему необходимо будет сгенерировать ответный пакет вместе со своими пакетами данных. Это увеличит фактические требования к полосе пропускания для 5-ти кортежей, несущих пакеты данных, и внесет дрожание в доставку этих пакетов. Анализ показал, что это вызывает обеспокоенность в некоторых сетях доступа уровня 2, которые используют довольно узкие планировщики пакетов для данных.

Кроме того, использование индикации привязки позволяет отключить целостность, что может привести к повышению производительности. Это полезно для крупномасштабных конечных точек, таких как шлюзы телефонной сети общего пользования (PSTN) и пограничные контроллеры сеансов (SBC).

В.9. Выбор типа кандидата

Одним из критериев выбора типа и локальных значений предпочтений является использование посредника данных, такого как сервер TURN, туннельная служба, такая как сервер VPN, или NAT. В случае посредника данных, если данные отправляются этому кандидату, он сначала проходит через посредника данных до его получения. Один тип кандидата, который включает посредника данных, является переданным кандидатом. Другой тип — это кандидат на хост, который получается из интерфейса VPN. Когда данные передаются через посредника данных, это может оказать положительное или отрицательное влияние на задержку между передачей и приемом. Это может увеличивать или не увеличивать потери пакетов из-за дополнительных переходов маршрутизатора, которые могут быть приняты. Это может увеличить стоимость предоставления услуги, поскольку данные будут перенаправляться и обратно из посредника данных, управляемого поставщиком. Если эти проблемы важны, предпочтение типа для отобранных кандидатов должно быть тщательно выбрано.

Другим критерием выбора предпочтений является семейство IP-адресов. ICE работает как с IPv4, так и с IPv6. Он обеспечивает механизм перехода, который позволяет хостам с двумя стеками предпочитать подключение по IPv6, но использовать IPv4 в случае отключения сетей v6. Реализация ДОЛЖНА следовать рекомендациям [RFC8421], чтобы избежать чрезмерных задержек на этапе проверки соединения, если существуют разорванные пути.

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

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

Приложение C. Проверка пропускной способности

В приведенных ниже таблицах для IPv4 и IPv6 показана полоса пропускания, необходимая для выполнения проверок подключения, с использованием разных значений Ta (в миллисекундах) и разных размеров ufrag (в байтах).

Результаты были предоставлены Jusin Uberti (Google) 11 апреля 2016 года.

Рисунок 12 - Проверка пропускной способности
Рисунок 12 — Проверка пропускной способности

Благодарности

Большая часть текста в этом документе взята из оригинальной спецификации ICE, RFC 5245. Авторы хотели бы поблагодарить всех, кто внес вклад в этот документ. За дополнительный вклад в пересмотр спецификации мы хотели бы поблагодарить Эмиля Ивова, Пола Кизивата, Пал-Эрика Мартинсена, Саймона Перро, Эрика Рескорла, Томаса Стаха, Питера Тэтчер, Мартина Томсона, Джастина Уберти, Сухаса Нандакумара, Тейлора Брандштеттера, Питер Сен-Андре, Харальд Альвестран и Роман Шпунт. Бен Кэмпбелл сделал обзор AD. Стивен Фаррелл сделал второй обзор. Стюарт Брайант сделал обзор ген-арта. Цинь Мы сделали обзор ops-dir. Магнус Вестерлунд сделал обзор tsv-art.

Адреса авторов

Ari Keranen
Ericsson
Hirsalantie 11
02420 Jorvas
Finland
Email: ari.keranen@ericsson.com

Christer Holmberg
Ericsson
Hirsalantie 11
02420 Jorvas
Finland
Email: christer.holmberg@ericsson.com

Jonathan Rosenberg
jdrosen.net
Monmouth, NJ
United States of America
Email: jdrosen@jdrosen.net
URI: http://www.jdrosen.net