Исследования №9, июль 2018

Сервисы глобальной Сети через призму BGP

Фото аватара
Александр Венедюхин

Введение

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

С точки зрения типичного пользователя, глобальная сеть Интернет состоит из наборов сервисов: веб, электронная почта, приложения в смартфоне и так далее. Надёжность и доступность этих сервисов напрямую зависит от того, как доставляются пакеты данных, то есть от организации марш­рутов в Сети. Рассматривая маршрутную информацию в разрезе сервисов, можно увидеть особенности, которые не ясны из анализа только таблиц BGP. Например, транзитные автономные системы (AS) можно ранжировать по коли­честву сервисов, для которых они являются транзитными. Также содержательные результаты даёт анализ маршрутов и транзитных AS применительно к трафику защищённых протоколов уровня приложений, прежде всего, TLS.

В настоящем исследовании рассматриваются основные сервисы, к которым мы относим веб (в том числе HTTPS/ TLS) и электронную почту. Из распространённых пользо­вательских сервисов не рассматриваются мессенджеры и приложения социальных сетей, предназначенные для смартфонов.

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

Методика

Для обозначения сервисов используются доменные имена. Доступ непосредственно по IP-адресам является довольно редким решением, тем более среди пользовате­лей веб-сайтов и электронной почты. Поэтому исходными данными для построения списков сервисов послужили доменные имена (второго уровня) в российских доменных зонах (.ru, .su, .рф). Второй характеристикой, обозначающей наличие на заданном узле нужного сервиса, является доступность по хорошо известному (для данного приложе­ния) номеру порта.

Рассмотрим доменное имя ididb.ru в качестве примера. Получим для этого имени из DNS значение A-записи: 62.76.121.136 (это IP-адрес). Установив с данным IP-адресом соединение по 80/tcp и отправив HTTP-запрос, мы можем определить, что здесь отвечает веб-сервер (то есть раз­мещён веб-сайт). Снова воспользуемся DNS и определим имя почтового сервера для ididb.ru, запросив MX-запись: mail.ididb.ru. Определим для mail.ididb.ru значение А-записи (62.76.121.133) и проверим, что на обращения по 25/tcp по этому адресу отвечает почтовый сервер (то есть размещён сервис электронной почты). Итак, использовав в качестве отправной точки имя ididb.ru, мы нашли связанные с этим именем два сервиса (веб и почта), имеющие различные IP-адреса.

Таблица 1. Общие показатели по числу IP-адресов (2017, 2018 гг.)

При помощи анализа маршрутной информации в соот­ветствие обнаруженным IP-адресам поставим автономную систему. Это будет та автономная система, которая анонсирует префикс, содержащий нужный IP-адрес, и при этом является оконечной AS (то есть представляет собой назначение маршрута; подроб­нее понятие оконечной AS определено ниже). Таким образом, каждому сервису сопоставляется автономная система и для такой автономной систе­мы изучаются маршруты в глобальных таблицах BGP (Full View), полученных от нескольких источников. Кроме того, мы анализируем маршруты на доступных route-серверах крупнейших российских точек обмена трафиком (MSK-IX и DATAIX). Сервис и маршруты связаны через систему доменных имён (DNS).

Для веб-сайтов мы принимаем, что адресам с префиксом www. соответствует тот же адрес, что и доменному имени второго уровня (как показывает практика, это не вносит больших искажений в данные). Под «веб-узлом» далее мы понимаем узел, подключенный к глобальной Сети, который доступен для TCP-соединений на номер порта 80 и отвечает непустым результатом на HTTP-запрос GET. Веб-узлу соот­ветствуют IP-адреса и имена доменов, связанные между собой DNS-записями. Отдельно рассматриваются веб-узлы, доступные по защищённому протоколу TLS через 443/tcp.

Таким образом, веб-узел характеризуется парой «домен­ное имя, IP-адрес». Нередки варианты, когда одному имени соответствует несколько IP-адресов. Чрезвычайно распространён и «обратный» случай, когда один IP-адрес соответствует большому количеству имён различных веб-сервисов. Эти особенности учитываются отдельно.

С электронной почтой связаны DNS-записи MX, в которых содержится имя сервера, принимающего сообщения для данного домена. (Запись также содержит приоритет данного сервера, но в рамках нашего анализа сервисов мы опрашиваем все указанные узлы вне зависимости от при­оритета.) Предположим, что для test.ru указана MX-запись mail.test.ru. Это означает, что другие серверы, осуществля­ющие доставку, при обнаружении сообщения с адресом внутри test.ru (например, box@test.ru) будут пытаться доставить это сообщение серверу, на который указывает имя mail.test.ru. В отличие от веб-узлов, при отображении DNS-имён в IP-адресное пространство, соответствующее электронной почте, необходима «двухэтапная» схема: на первом этапе определяется имя MX-сервера, на втором – значение A-записи для этого имени (а не для исходного имени второго уровня). Рекомендациями (RFC 5321) допу­скается возможность доставки почты непосредственно по значению A-записи для базового домена (вершины зоны) при отсутствии в ней MX-записей. Однако такой вариант в нашем исследовании не рассматривается.

Итак, сервер электронной почты характеризуется IP-адре­сом и символьным именем, указанным в MX-записи. Один и тот же сервер может иметь не только множество различных IP-адресов и различных имён, он может обслуживать большое число доменных зон, в каждой из которых одно из его имён указано в значении MX-записи. Типичными для Рунета показателями является обслуживание десятков тысяч различных зон одной группой почтовых серверов. Мы считаем почтовым узлом подключенный к глобальной Сети сервер, принимающий TCP-соеди­нения по номеру порта 25 и содержательно отвечающий на SMTP-команду EHLO.

Поддержка TLS (защищённый протокол) исследуемыми узлами определялась только в разрезе HTTPS (443/tcp), путём проведения начальной фазы установления TLS-соединения, в рамках которой от узла, в частности, принимался TLS-сертификат. TLS-сертификаты проверялись в рамках процедуры валидации, сходной с аналогичной процедурой веб-браузеров. Валидация позволяет оценивать потенциальную доступность защи­щённых веб-сервисов и сравнивать статистику по узлам с валидными/не валидными сертификатами.

Итак, список IP-адресов формируется в результате опроса DNS. Каждому IP-адресу из полученного списка при помощи анализа таблиц BGP сопоставляется содержащий его префикс (блок IP-адресов). По префиксу определяется автономная система. Анонсирующая данный префикс автономная система, которая является последней точкой маршрута, называется оконечной автономной системой. В рамках настоящего исследования предполагается, что оконечная автономная система, к которой принадлежит префикс, содержащий IP-адрес сервиса, содержит и этот сервис. Такой подход отражает реальное положение дел лишь с сетевой точки зрения: административно сервис может относиться к организации, не связанной напрямую с данной оконечной автономной системой. Типичный пример – размещение оборудования в дата-центре, где арендуется канал доступа. Тем не менее, сетевая принад­лежность сервиса к той или иной автономной системе в большинстве случаев означает, что, как минимум, между администратором сервиса и администратором автономной системы существуют некоторые договорные отношения. Общие показатели по IP-адресам приведены в таблице 1, с разбивкой по зонам.

  • Мы выделяем российские автономные системы (и сервисы в них). Автономная система относится к российским на основании регистрационных данных, полученных из регистратуры RIPE NCC. При выделении номера автономной системы (и/или блоков IP-адресов) RIPE NCC требует предоставления документов, идентифицирующих юридическое или (в редких случаях) физическое лицо, выступающее в качестве администратора AS. На основании этих документов определяются адреса юрисдикции адми­нистратора, которые позволяют говорить о географической принадлежности AS.
Таблица 2. Число уникальных оконечных AS и соответствующих им маршрутов (октябрь 2017)

В таблице 2 указано общее число автономных систем, являющихся оконечными, то есть автономных систем, в которых находится узел с тем или иным интернет-сервисом. Соответствующие маршруты – это различающиеся хотя бы в одном «хопе» маршруты, которые ведут к автономным системам с сервисами. Так, разнообразие маршрутов, полученных с route-серверов, существенно меньше (в три с лишним раза), чем в глобальных таблицах BGP. Это объясняется достаточно очевидным соображением: маршрутизация в Интернете в целом устроена сложнее, чем маршруты между участниками пиринга на точках обмена трафиком. Таким образом, число различных AS, размещающих сервисы Рунета, измеряется тысячами. При этом существует концентрация ресурсов по AS (см. таблицу 3 ниже), соответствующим крупным хостинг-провайдерам, что, конечно, находится в полном соответствии с эвристиче­скими представлениями об устройстве Сети.

В таблице 3 представлен рейтинг оконечных автономных систем, составленный по числу уникальных IP-адресов (IPv4), соответствующих узлу с тем или иным сервисом из исследуемых (веб, почта, TLS). Кодом RU обозначены рос­сийские AS. Так как это рейтинг по IP-адресам, он отражает политику распределения IP-адресного пространства между ресурсами конкретным провайдером: так, большое число веб-ресурсов, размещённых на узле с одним IP-адресом, будут в данном рейтинге учитываться как один узел.

Верхушка рейтинга из таблицы 3 – это иностранные AS, в частности, один из крупнейших мировых провайдеров Cloudflare. Причина такого положения дел в том, что многие сервисы, адресуемые российскими доменными именами, размещены на иностранных площадках. Данные иностран­ные AS нами не рассматриваются при анализе маршрутов: как указано выше, в таком случае мы не относим ресурс к полностью российским.

Необходимо отметить, что географическая принадлеж­ность автономных систем – понятие в некотором роде условное: проекция политической карты мира в Интернет имеет свои особенности. Например, автономная система, зарегистрированная российским юридическим лицом, может фактически являться иностранной, в том смысле, что основные эксплуатируемые сети физически находятся за пределами России. Напротив, AS, отмеченная на основании регистрационных данных как иностранная, может действовать только на территории России, в интересах того или иного российского провайдера, являясь, таким образом, российской в сетевом смысле. Возможны и более сложные случаи. Практический анализ маршрутной информации в разрезе сервисов полностью подтверждает такое положе­ние дел. Тем не менее, наблюдение над данными географической привязки, проведённой описан­ным способом, и выборочная ручная проверка показывают, что способ этот достаточно точный, а главное – единственный универсальный. Других методов относительно незатратного массового и точного определения принадлежности автоном­ных систем к определённой стране пока не существует.

Анализ маршрутной информации

Понятие автономной системы является базовым для определения маршрутов доставки пакетов данных в Интернете. Если рассматривать это понятие в разрезе протокола IP, то автономная система – это, фактически, набор маршрутизаторов, формирующих видимую для Интернета IP-сеть, находящуюся под единым управлением. Последний момент является определяющим: именно при помощи единого управления определяется то, как пакеты доставляются внутри сети. Это называется политикой маршрутизации. «Автономной» систему делает не то, что у неё есть собственная политика маршрутизации, а то, что данный «набор маршрутизаторов» взаимодействует с другими автономными системами, составляющими Интернет. Это ключевой момент – определение автономной системы является рекурсивным, т.е. нельзя корректно определить понятие AS, если нет других AS. Это выглядит контринтуитивно. Тем не менее, для глобальной Сети такое определение логично и обосновано. Почему? Потому что «единство управления маршрутизацией» возможно определить только с внешней точки зрения. Так, другие автономные системы, взаимодействующие с данной через пограничный узел, видят внутреннюю политику маршрути­зации как единую. Данная оговорка очень важна: политика маршрутизации может не являться единой внутри AS, но в рамках исследования внешних таблиц BGP выявить это в общем случае невозможно. Другими словами: определе­ние автономной системы – не столько техническое, сколько административное.

Таблица 3. Рейтинг оконечных AS, по числу уникальных IP с сервисами (октябрь 2017)

Основу взаимодействия автономных систем через протокол BGP составляет распространение информации о желании соседних AS доставлять пакеты в адрес того или иного IP-префикса. Под “соседними” здесь подразумеваются такие AS, пограничные маршрутизаторы которых взаимодействуют непосредственно в смысле обмена маршрутами (это не означает, что маршрутизаторы «сое­динены напрямую»). Именно эту информацию, в конечном итоге, можно видеть в глобальных таблицах BGP. В рамках настоящего исследования мы используем таблицы BGP Full View, состав которых зависит от точки получения, а конкретно, от пограничного маршрутизатора, послужив­шего источником таблицы. Второй набор маршрутной информации – это данные, полученные с route-серверов точек обмена трафиком. Данный набор также имеет свои ограничения, определяющиеся, в основном, собственными пиринговыми политиками участников обмена. Маршрути­зация в Интернете динамическая, поэтому на состав таблиц маршрутов влияет не только точка получения, но и время.

Всякое исследование BGP как внешнего протокола обмена маршрутами – это не более чем исследование BGP. Реальная связность Интернета существенно сложнее, кроме того, она постоянно меняется. Распространена ситуация, когда некоторые операторы организуют между собой канал, который не анонсируют наружу, то есть соответствующие автономные системы при взгляде через BGP Full View или route-серверы не будут учитываться как соседние, несмотря на то, что они обмениваются IP-пакетами, адресованными друг другу, напрямую. Тем не менее, на основании анализа таблиц BGP можно строить оценки, отражающие распределение адресного пространства между сервисами, а также свойства инфраструктуры, обеспечивающей доставку пакетов. И в этом ключе дополнение BGP-информации сведениями о сервисах, сформированными на основе проверки реальной связности (то есть под данным IP-адре­сом действительно доступен некоторый узел), оказывается весьма полезным, так как предоставляет ещё одну точку опоры при анализе связности и доступности.

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

Второй временной аспект связан с получением инфор­мации о соответствии имён и IP-адресов исследуемым сервисам. Построение исходного набора данных связано с опросом DNS и обнаружением сервисов на узлах: этот процесс, как отмечено выше, сам основан на характери­стиках связности, которую предполагается исследовать. Например, отмечены следующие проблемы: некоторые авторитативные DNS-серверы (то есть серверы, на которых размещена доменная зона) имеют географические настройки и, соответственно, отвечают на запросы по-раз­ному, в зависимости от того, к какому региону принадлежит источник запроса (определяется по IP-адресу); также DNS-сервер может отвечать разным составом значений A-записей в зависимости от текущей загрузки сервиса в целом. Крупные сервис-провайдеры используют anycast-а­дреса, что также вносит сложно устранимые искажения и в интерпретацию маршрутов, и в данные по соответствию имён и сервисов. Тем не менее, эти проблемы имеют локальный характер, и хоть и влияют на точность анализа, но не являются препятствием для построения статистики, учитывающей миллионы имён и сервисов. Эвристическая оценка погрешности, вносимой только что описанными факторами, составляет около 5%.

Транзит интернет-трафика и сервисы

Неотъемлемой частью маршрутизации в Сети являются транзитные автономные системы, обеспечивающие достав­ку пакетов между различными AS. Без транзитных систем маршрутизация в Интернете невозможна. С точки зрения сервисов, важна концентрация маршрутов, ведущих к тем или иным сервисам, по транзитным автономным системам. В качестве иллюстрации в таблице 4 приведён топ-10 рейтинга российских транзитных AS по числу уникальных имён ресурсов, для которых данная AS является тран­зитной. Данный рейтинг построен не по IP-адресам, а по уникальным именам сервисов.

Таблица 4. Транзитные AS в разрезе концентрации сервисов (октябрь 2017)

Данные из таблицы 4 демонстрируют некоторые осо­бенности распределения транзита трафика по различным типам сервисов. Рейтинги в разных колонках существенно различаются. Этому есть несколько причин. Во-первых, разные сервисы, соответствующие одному имени, нередко находятся у разных провайдеров. Обычный пример: веб и почта. Веб-сервер может быть размещён у одного хостинг-провайдера, а почтовый сервер – принадлежать тому или иному массовому почтовому провайдеру. Так, существенный вклад вносит практика размещения сервиса почты на серверах «Яндекса» или Google. По состоянию на август 2017 года MX с именем mx.yandex.ru был указан для 227 тысяч имён в зоне .ru. Более того, существенное число имён вообще не адресуют веб-серверов, но используются для почты. По данным проекта Statdom.ru, таких имён в августе 2017 года было около 525 тысяч в зоне .ru. Что касается TLS, то этот протокол нами рассматривается в разрезе HTTPS, а безопасная версия используется далеко не для всех веб-узлов. Соответственно, выборка по TLS фактически означает сужение выборки всех веб-узлов на те хостинги, где поддерживается HTTPS.

География сервисов и трансграничные переходы

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

Достаточно большая доля (около 30%) интер­нет-сервисов, адресуемых доменными именами в российских зонах, размещена на зарубежных площадках, которые используют адреса из иностранных оконечных AS. Так как в данном случае сам сервис находится в зарубежных сетях, обнаружение дополнительных трансграничных переходов не имеет смысла. Поэтому мы рассма­триваем маршруты, у которых оконечная AS (с сервисом) является российской. В случае анализа маршрутов из BGP Full View, полученных от миро­вых backbone-операторов, первой AS в маршруте является иностранная – это источник маршрутной информации. Тем не менее, так как оконечная AS российская, маршрут должен прийти к одной из российских автономных систем.

Рис. 1  Схема маршрута с трансграничным переходом.

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

Трансграничные переходы определяются при последо­вательном разборе маршрута с сопоставлением каждой автономной системе флага «российская/не российская». В результате выявляются маршруты, в которых трафик дополнительно пересекает «виртуальную границу» – уже после того, как маршрут «пришёл» в российский сегмент.

Таблица 5. Число имён узлов с трансграничными переходами*

*— Приводится число уникальных доменных имён, которые указывают на узел, оказавшийся в маршруте с трансграничным переходом. Одному IP- адресу может соответствовать несколько имён.

В таблице 5 приведено распределение уникальных имён узлов с сервисами по типам сервисов, для маршрутов с трансграничными переходами. Максимальное число относится к веб-узлам: свыше 500 тысяч веб-узлов видны через маршруты с трансграничными переходами. При этом для маршрутов, полученных с route-серверов, число сервисов с трансграничными переходами в маршрутах несколько меньше.

На рис. 2 показана типичная ситуация, наблюдающаяся на практике: AS12976 является оконечной для несколь­ких веб-узлов, данная AS – российская, однако и на route-серверах (левая часть диаграммы), и в Full View backbone-операторов оконечной AS предшествует AS3227, которая не является российской. На данной диаграмме не все маршруты являются маршрутами с трансграничным переходом. Так, трансграничный переход (в нашей терминологии) содержат маршруты Full View, проходящие через российскую AS20485 (это российская AS), а другие маршруты, представленные справа, трансграничных переходов не содержат, так как все входящие в них AS являются иностранными (кроме оконечной). Аналогично, среди маршрутов route-серверов только один маршрут, проходящий через AS50952, содержит трансграничный переход (AS21219 является иностранной).

Рис. 2  Пример практических маршрутов с трансграничным переходом (выделены красным).

В таблице 6 представлены два рейтинга (TOP-10) автоном­ных систем, которые «реализуют» трансграничный переход (см. описание ниже). Рейтинги отражают вариативность маршрутов, в которых данная AS является транзитной. О чём идет речь? Предположим, что у нас есть оконечные автономные системы AS65536 и AS65547, содержащие веб-узлы. Рассмотрим следующие маршруты:

  1. AS65539, AS65538, AS65550, AS65536
  2. AS65539, AS65538, AS65550, AS65547

(То есть два маршрута, различающихся только последней AS.)

Таблица 6. Рейтинг (топ-10) AS, встретившихся в маршрутах с трансграничным переходом, по числу уникальных маршрутов (для веб-узлов)

Будем считать, что AS65550 является иностранной, а остальные AS, присутствующие в маршруте, российские. Оба указанных маршрута содержат трансграничный пере­ход. Соответственно, такие маршруты будут подсчитаны как два уникальных маршрута и отнесены в приведённых в таблице 6 рейтингах к AS65550, которая получит показатель 2 (если других подходящих маршрутов не будет найдено). В случае, если маршрут содержит несколько последователь­ных иностранных AS, учитывается только та из них, которая является соседней слева к российской.

Другими словами, маршруты, ведущие к разным оконечным AS, но проходящие через общую транзитную, являющуюся «пограничной», будут учитываться как различные трансграничные маршруты, в которых участвует данная AS. Рейтинг, соответственно, отражает разнообразие маршрутов, трафик которых иностранная AS может наблю­дать. Это только маршруты, по которым нельзя судить, насколько большой поток трафика передаётся между AS. Так, из того, что какая-то AS «видит» сто различных маршрутов с трансграничным переходом, прямо не следует, что эта AS «видит» больше или меньше трафика, чем AS, которая является «пограничной» всего лишь для трёх маршрутов. Более того, так как трансграничный переход определяется нами административно (по принадлежности AS), его наличие не является ни необходимым, ни достаточ­ным признаком того, что трафик, следующий по данному маршруту, действительно покидает пределы России. Так, возможны конфигурации, когда провайдер, оператор российской автономной системы, использует виртуальные или физические каналы, проходящие через иностранные узлы связи, но при этом данные переходы относятся к уровню ниже IP, соответственно, в BGP наблюдаться не могут. С другой стороны, оператор иностранной AS может для работы внутри России использовать только российские каналы связи и, тем не менее, соответствующие маршруты будут учитываться как маршруты с трансграничным переходом.

Отметим, что таблица 6 в части рейтинга Full View хорошо показывает ограничения географической привязки по дан­ным RIPE NCC. Так, в таблице указана AS2683 (RADIO-MSU), которая в базе данных RIPE NCC принадлежит к региону EU (Европейский Союз). Однако данная AS фактически является российской.

Анализ маршрутов сам по себе не позволяет оценить ни объёмы трафика, ни набор ресурсов, трафик которых проходит через данную транзитную AS. Однако если маршрутную информацию сопоставить с именами ресурсов, то можно определить «населённость» тех или иных марш­рутов сервисами.

Заключительные замечания

Сервисы являются ключевым элементом современного Интернета. Сопоставление маршрутной информации, получаемой при помощи сбора данных BGP, с распределе­нием имён и адресов сервисов, позволяет обнаружить некоторые закономерности и рассчитать показатели связности, которые не видны только из BGP-данных. Например, можно выделить транзитные AS, связанные с большим числом веб-узлов или почтовых серверов; обнаружить кластеры веб-узлов, маршруты в направлении которых содер­жат трансграничные переходы, что потенциально может привести к дополнительным проблемам с доставкой данных в случае нарушения глобальной связности Сети. Нали­чие трансграничного перехода в конфигурации BGP для конкретного момента времени само по себе не означает, что между узлами, которые «разделены» данным перехо­дом, невозможны другие маршруты: в случае нарушения связности одного маршрута, достаточно быстро может быть выбран другой, в том числе, уже не содержащий транс­граничного перехода.

Очередной раз отметим, что речь идёт только о тех маршрутах, в которых оконечная AS – российская, а переход через (виртуальную) границу происходит уже после того, как маршрут «пришёл» в российский сегмент. То есть такой переход часто выглядит лишним, хоть и может быть обоснован с сетевой точки зрения. Для узлов Рунета доля маршрутов, содержащих трансграничный переход, уже не велика. Возникновение трансграничного перехода часто объясняется не столько техническими, сколько ад­министративными причинами (к которым относится, например, стратегия пиринга, ис­пользуемая операторами). Дальнейшему снижению количества подобных маршрутов может способствовать развитие инфраструктуры российских точек обмена трафиком (IXP), так как они служат средой, позволяющей нивелировать как административные, так и технические причины возникновения излишних трансграничных переходов.

При этом сопоставление данных по именам/адресам сервисов с BGP характеризует­ся определёнными трудностями. Так, обход узлов роботами с целью определения до­ступности сервисов занимает заметное время, в течение которого BGP-таблицы могут измениться. BGP-таблицы оказываются самой динамичной частью исходных данных. Значительные изменения в них могут произойти в течение суток. Адресация веб-уз­лов и почтовых сервисов изменяется существенно медленнее, типичным интервалом времени здесь является месяц. Таким образом, при анализе миллионов имён узлов возможные скачкообразные изменения маршрутов (например, утечки маршрутов или кратковременный «угон» префиксов) часто сглаживаются, поэтому оказываются не видны.