Анализ внедрения MPTCP в Интернете

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

Несколько организаций объявили о включении MPTCP в свои продукты и услуги, в том числе Apple и Linux:

• Apple использует MPTCP в своих iOS-устройствах (например, Siri, Music, Maps, Wi-Fi Assist), а также позволяет сторонним разработчикам использовать протокол в несистемных приложениях.

• Linux использует MPTCPv1 (RFC 8684) на всех своих машинах с ядром версии 5.6 и выше. Старая версия разработки теперь известна как MPTCP версии 0 (MPTCPv0).

Несмотря на значительный интерес со стороны этих и других компаний, текущее состояние развертывания и использования MPTCP в Интернете остается в значительной степени неизвестным. В этой статье мы обобщим основные результаты нашего исследования, что поможет обрисовать наиболее точную картину истинного развертывания MPTCP на сегодняшний день. Часть исследования была опубликована в IFIP Networking 2021, а расширенная версия в настоящее время находится на рассмотрении. Если вам интересно узнать больше о нашей работе, рекомендуем прочитать подробный анализ и скачать актуальные результаты сканирования на mptcp.io.

Ключевые моменты:

• Развертывание MPTCP охватывает экономику более 80 стран.

• Поддержка MPTCPv1 до октября 2021 года практически отсутствовала как для IPv4, так и для IPv6.

• Почти половина всех хостов IPv4 MPTCPv0 развернута в Гонконге благодаря Hong Kong Broadband.

• В конце 2021 года Apple занимала второе место по поддержке MPTCPv0 в IPv4, но имела наибольшее присутствие в IPv6 и была единственной компанией, которая активно поддерживала MPTCPv1. В феврале 2022 года поддержка MPTCPv1 поверх IPv4 была увеличена в 10 раз.

Сканирование для MPTCP — пособие для начинающих

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

MPTCP расширяет обычный протокол TCP и использует необязательные поля заголовка TCP для передачи сигналов (см. RFC 6824). Наиболее примечательной опцией является MP_CAPABLE, которая включает флаг MP_CAPABLE, сигнализирующий о том, что конкретный хост поддерживает MPTCP во время установления соединения. Кроме того, опция также включает случайную 64-битную последовательность, известную как ключ отправителя, которую хосты используют для аутентификации.

На рисунке 1 показана процедура установления соединения MPTCPv0 между двумя хостами, Бобом и Алисой. Процедура имитирует трехэтапное рукопожатие TCP. Боб инициирует соединение отправкой пакета SYN, содержащего флаг MP_CAPABLE с поддержкой MPTCPv0 и собственный ключ отправителя. Если Алиса также поддерживает MPTCP, она ответит SYN-ACK, содержащим флаг MP_CAPABLE и собственный ключ отправителя. Наконец, Боб устанавливает соединение, отправив ACK с обоими ключами в опции MP_CAPABLE. Если во время обмена какая-либо из опций MPTCP сбрасывается (например, Алиса не поддерживает MPTCP), соединение возвращается к обычному TCP.

Установление соединения MPTCPv1, с другой стороны, немного отличается от MPTCPv0. В дополнение к различным номерам версий MPTCP в MP_CAPABLE, Боб не отправляет ключ отправителя в SYN, ключ отправляется Алисе только в финальном SYN-ACK. Мы обсудим влияние этого изменения на механизм рукопожатия немного позже.

Мы можем использовать механизм рукопожатия MPTCP для определения поддержки MPTCP в Интернете. Мы использовали ZMap и сгенерировали MPTCP SYN с опцией MP_CAPABLE. Для сканирования MPTCPv0 мы также использовали фиксированную 64-битную последовательность в качестве ключа и отправляли ее в пакете SYN. Если целевой хост ответил SYN-ACK, который также включал параметр MP_CAPABLE и ключ отправителя, он, вероятно, поддерживал MPTCP.

Мы проверили все адресное пространство IPv4 на 80 порту (≈74 млн уникальных отвечающих IP-адресов) и на порту 443 (≈52 млн уникальных IP-адресов с откликом). В IPv6 мы использовали Hitlist IPv6 для проверки порта 80 (≈746 тыс. реагирующих IP-адресов) и порта 443 (≈544 тыс. реагирующих IP-адресов) из-за размера адресного пространства. Мы получили результаты сканирования MPTCPv0 за восемнадцать месяцев (с июля 2020 г. по декабрь 2021 г.) и MPTCPv1 за девять месяцев (с апреля по декабрь 2021 г.). Более того, сканирование все еще продолжается, и наши последние результаты доступны на mptcp.io.

Промежуточные устройства Интернета против MPTCP: борьба за совместимость

Во-первых, мы обнаружили, что лишь небольшой процент опробованных хостов отвечает на наши сканирования флагом MP_CAPABLE в SYN-ACK (≈5%). Глядя на абсолютное количество хостов, а не на проценты (около 300 000 в MPTCPv0 и 200 000 в MPTCPv1), может показаться, что MPTCP широко поддерживается в Интернете. Однако при сканировании MPTCPv0 мы заметили, что только часть из 300 000 хостов (≈4%) отправила нам значение ключа отправителя в SYN-ACK, отличное от значения статического ключа отправителя, которое мы отправили в исходном SYN. Такое поведение противоречит RFC 6824, в котором говорится: «… ключ должен быть трудно угадываемым, и он должен быть уникальным для отправляющего хоста в любой момент времени».

Поскольку ключ представляет собой случайную 64-битную последовательность, сумма независимых случайных величин должна стремиться к нормальному распределению в соответствии с центральной предельной теоремой. На рис. 4 показан вес Хэмминга ключей отправителя, полученных от потенциальных хостов MPTCP IPv6 через порт 443. Обратите внимание на выброс с весом Хэмминга 16, который не соответствует распределению. Мы обнаружили, что этот выброс присутствует во всех наших сканированиях MPTCPv0 для портов 80 и 443 (более распространен в IPv4, чем в IPv6). Интересно, что вес Хэмминга выброса точно соответствует весу статического ключа, который мы отправили в нашем SYN-пакете хостам.

В распределении подчеркивается распространенность промежуточных устройств в Интернете, которые не поддерживают расширения заголовков TCP и поэтому обрабатывают такие пакеты нетипичными способами. Многие промежуточные устройства отбрасывают пакеты с расширениями заголовка TCP, в то время как другие могут удалять расширения, но пересылать пакет адресату. Приведенный выше кейс показывает, что на сканирование MPTCPv0 влияют промежуточные устройства, которые повторяют расширения в заголовке SYN пакета обратно нам в ответе. Мы отфильтровали такие промежуточные устройства из нашего анализа, проверив, отличается ли возвращенный ключ отправителя в SYN-ACK от отправленного в SYN.

Обратите внимание, что проектное решение MPTCPv1 по удалению ключа отправителя в SYN было направлено на особую обработку подобных устройств-повторителей, поскольку ожидается, что возвращенный SYN-ACK будет иметь значение ключа отправителя вместе с установленными опциями MP_CAPABLE. Мы отфильтровали промежуточные устройства в нашем анализе MPTCPv1, используя именно этот критерий.

После фильтрации мы обнаружили, что количество отвечающих хостов значительно сократилось — почти 100 000 IPv4 и 2000 IPv6 для MPTCPv0 и 120 IPv4 и 80 IPv6 для MPTCPv1. Мы также обнаружили, что поддержка MPTCPv1 практически отсутствовала как для IPv4, так и для IPv6 до октября 2021 года, после которого мы наблюдали внезапный всплеск отзывчивых хостов.

Поддержка MPTCP в IPv4 и IPv6

Мы дополнительно проверили наличие мешающих промежуточных устройств, запустив Tracebox для всех целей, которые отправили параметр MP_CAPABLE в наших сканированиях ZMap. В ответе Tracebox мы получили ответы от промежуточных маршрутизаторов на пути, включая все сделанные модификации. Чтобы ознакомиться с подробной методологией, рекомендуем прочитать вот эту статью.

Во-первых, мы заметили, что большой процент целей не отвечал на наши запросы Tracebox и был недоступен. В IPv4 почти 90% и 48% хостов на портах 443 и 80 были недоступны. В IPv6 только порт 443 имел недоступные хосты (≈82%). Дальнейший анализ показал, что одной из основных причин является блокировка со стороны интернет-провайдера целевого хоста.

После удаления недоступных хостов мы обнаружили, что истинная поддержка MPTCPv0 в IPv4 на конец декабря 2021 года составляет ≈16 500 на порту 80 и ≈13 500 на порту 443. В случае IPv6 1195 и 1184 хоста на портах 80 и 443 действительно поддерживает MPTCPv0.

Поддержка MPTCPv1 значительно ниже, чем MPTCPv0, поскольку 100–150 хостов поддерживают более новую версию для IPv4 и IPv6 на портах 80 или 443. На рисунке 5 показано покрытие по портам для хостов с действительной поддержкой MPTCP (как v0, так и v1), и оно подчеркивает значительную одновременную поддержку как HTTP, так и HTTPS.

Использование MPTCP в организациях

Мы также обнаружили, что почти половина всех хостов IPv4 MPTCPv0 развернута в Гонконге благодаря гонконгской (HK) широкополосной связи (таблица 1), на долю которой приходится наибольшая доля. Большинство хостов HK Broadband заработали в 2021 году, до этого самая высокая поддержка MPTCPv0 была у Apple.

Таблица 1 — Топ-10 AS, на которых размещаются хосты IPv4 MPTCPv0.

В конце 2021 года Apple занимала второе место по поддержке MPTCPv0 в IPv4, но имела наибольшее присутствие в IPv6 (таблица 2), при этом большинство ее серверов находились в США.

Таблица 2 — Топ-5 AS, на которых размещаются хосты IPv6 MPTCPv0.

Мы также видим, что Apple — единственная организация в Интернете, которая начала активно поддерживать новую версию MPTCPv1 (таблица 3).

Таблица 3 — Топ-5 AS, на которых размещаются хосты IPv4 MPTCPv1.

На рис. 6 показано количество хостов IPv4 в сетях Apple (AS6185 и AS714), которые, как сообщается, поддерживают MPTCPv0 и MPTCPv1 с апреля 2021 года. Хосты Apple MPTCPv0 остаются довольно стабильными — вероятно, они поддерживают основные приложения и сервисы Apple. Мы обнаружили, что Apple не поддерживала MPTCP в IPv6 до сентября 2021 года и MPTCPv1 в IPv4 до октября 2021 года, что также является причиной внезапного роста числа хостов MPTCPv1 во всем мире.

В феврале 2022 года Apple увеличила поддержку MPTCPv1 по сравнению с IPv4 в 10 раз, почти сравнявшись с хостами MPTCPv0. Дальнейшее расследование показало, что это те же самые хосты, которые ранее поддерживали MPTCPv0, а теперь также поддерживают MPTCPv1.

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

Вы используете MPTCP? Если да, напишите нам

В обозримом будущем мы планируем продолжить наше исследование поддержки MPTCP, которое можно просмотреть и скачать на сайте mptcp.io. Чтобы узнать больше о влиянии промежуточных устройств на передачу данных MPTCP и распределение трафика MPTCP IPv4 и IPv6 в Интернете, читайте эту статью.

Нам также очень интересно узнать о приложениях, использующих MPTCP в Интернете. Если вы знаете о таких вариантах использования, управляете серверами, участвующими в таких обменах, или хотите узнать на эту тему больше, свяжитесь с нами по адресу info@mptcp.io.

Приходите на открытое занятие «Внедрение Firewall в фабрику». Определим, зачем необходим Firewall и как он мешает работе сервиса. Рассмотрим дизайн построения сетевой фабрики. Разберем особенности и недостатки внедрения Firewall. Реализуем внедрение Firewall в сетевую фабрику. Регистрация по ссылке.