2 июня 2023 года произошел сбой в работе междоменной маршрутизации сети интернет. Мы получили уведомление о периодических перезагрузках некоторых роутеров, отвечающих за маршрутизацию между сетями, из-за некорректных BGP-пакетов с BGP-атрибутом 28. Здесь мы начнем рассмотрение этого события с помощью RIS [Routing Information Service - проект RIPE NCC, который предназначен для сбора, хранения и обработки информации о маршрутизации в интернете, с нескольких коллекторов, которые распределены по миру] и представим предварительные соображения о том, что могло пойти не так. Многочисленные источники не так давно сообщили нам о событии, произошедшем в системе междоменной маршрутизации в пятницу 2 июня. Согласно первоначальным сообщениям, наблюдалось ощутимое влияние чего-то на междоменную маршрутизацию, в частности, на IPv6. После более тщательного изучения ситуации я пришел к выводу, что пакеты с устаревшим атрибутом BGP под № 28 (определенным в RFC6790, также известным как "BGP Entropy Label Capability Attribute" [BGP-атрибут возможности использования метки энтропии]) вызывали сброс сеанса на определенных версиях маршрутизаторов Juniper, поскольку они некорректно отмечали эти пакеты как поврежденные. Если вы разбираетесь в тонкостях BGP, то, вероятно, понимаете важность этого. Но довольно сложно ввести в курс дела людей, которые не связаны с данной областью. В данном случае все, что нам нужно сказать об BGP-атрибутах, это то, что они представляют собой определенные биты информации, которые содержатся в BGP-сообщениях и помогают маршрутизаторам определить, какие маршруты лучше всего подходят для доставки пакетов к месту назначения. Некоторые из этих BGP-атрибутов являются обязательными (должны распознаваться всеми маршрутизаторами). Другие же совершенно необязательны - и это важно, поскольку маршрутизаторы могут по-разному распознавать те или иные атрибуты. Если маршрутизатор встречает атрибут, который он не распознает, то обычно игнорирует его. Но в данном случае, по-видимому, присутствие неизвестного атрибута привело к тому, что некоторые маршрутизаторы стали считывать входящие BGP-сообщения как ошибочные. Особенностью старой версии BGP является то, что при обнаружении некорректных BGP-пакетов происходит сброс BGP-сессии. Подобная крайность нежелательна, поэтому существует RFC, определяющий лучшее поведение (RFC7606, август 2015 г.). Из этого RFC: Такое поведение нежелательно, поскольку сброс сессии затрагивает не только маршруты с конфликтующим атрибутом, но и другие корректные маршруты, обменивающиеся данными в рамках сессии. В случае необязательных транзитивных атрибутов такое поведение особенно неприятно и может представлять собой потенциальную уязвимость безопасности. Это связано с тем, что атрибуты могут распространяться без проверки на промежуточных маршрутизаторах, которые их не распознают. По сути, атрибуты могли быть переданы туннельным способом; когда они достигают маршрутизатора, который распознает и проверяет атрибуты, сбрасываемый сеанс окажется не связанным непосредственно с неисправным роутером. Что еще хуже, в подобных случаях, несмотря на то, что проблемные атрибуты могли быть вызваны одним обновлением, переданным одним BGP-спикером, к тому моменту, когда они столкнутся с маршрутизатором, который их проверит, они уже будут реплицированы много раз и, таким образом, приведут к сбросу многих пиринговых сессий. В результате, нанесенный ущерб может быть многократно увеличен. Событие, произошедшее в пятницу 2 июня, похоже на случай такого нежелательного поведения. По этой причине мы просматриваем в RIS все то, что сможем найти и узнать об этом. Мы проанализировали все обновления, собранные RIS 2 июня 2023 года (все время указано в UTC). В общей сложности было обнаружено 417 информационных сообщений обновления BGP, содержащих этот неизвестный атрибут. Первые сообщения были найдены в 13:33:46 и выглядят следующим образом: Последнее сообщение такого типа мы видели в 16:34:12. Эти сообщения были замечены на 82 пиринговых сессиях маршрутных коллекторов RIS (из 1527, включая "полные" и частичные [неполные] фиды), для 66 пиринговых ASN (из 609), на 18 различных маршрутных коллекторах (из 23), что дает представление о распространенности этого события. Эти два первоначальных сообщения, которые вы видите выше, содержат два префикса IPv6, которые мы видели во всех обновлениях, содержащих BGP-атрибут 28. В некоторых BGP-сообщениях (которые могут содержать несколько префиксов) мы видели и другие префиксы. Это привело к специфическому распределению префиксов в BGP-сообщениях, содержащих атрибут 28. Интересны также AS-пути, которые мы видим в этих сообщениях [1]. (Полный список префиксов и AS-путей приведен в разделе примечаний ниже, также можно посмотреть файл с полным списком BGP-сообщений в репозитории Github) [2]. Все AS-пути содержат сеть AS262494 (Virtex, BR), при этом в качестве origin (исходной) AS выступает AS269480, либо AS264366. В большинстве AS-путей мы видим AS6939 (Hurricane Electric) в качестве апстрима, что неудивительно, учитывая заметную роль Hurricane Electric в транзите IPv6 в целом. Кроме путей через AS6939, мы также видим пути через прямые пиры RIS - AS41047, AS51185 и AS61595. На этом рисунке показано влияние данного события на конкретную сеть, как это видно на примере AS-гегемонии Internet Health Report (IHR): Верхний график показывает колебания зависимости этой сети от апстримов, а нижний - как за время, в течение которого произошло событие BGP, данная сеть потеряла несколько сетей, которые от нее зависели. Этот график также вызывает дополнительные вопросы: Показатели AS-гегемонии рассчитываются для IPv4, а событие, по крайней мере, как видно из RIS, касалось IPv6. Как такое могло произойти? Поскольку мы не хотим выделять последствия для отдельной конкретной сети, но в то же время стремимся показать, какое влияние это может иметь, то решили не называть ее имя. Другая сеть (крупная CDN) сообщила о том, что "это было очень заметно и у нас", поэтому могут быть и дополнительные свидетельства этого события в данных о маршрутизации, которые мы собираем с помощью RIS, или в прочих системах обработки маршрутов. Мы искали графики (IXPs и другие), дающие представление о количестве перенаправленного из-за этого трафика, но не обнаружили никаких необычных закономерностей, коррелирующих с тем, что мы видим в RIS из-за этого события. Это может свидетельствовать о том, что, несмотря на отмеченные эффекты в некоторых сетях, данное событие прошло без заметного влияния на остальную часть интернета. Этому могли способствовать предпринятые пострадавшими сетями меры по смягчению последствий. Это событие, возможно, было относительно небольшим по масштабам, но оно вызвало у меня немало вопросов. Например, хотя оно было ограничено IPv6, стоит задаться вопросом, что произойдет, если подобное случится в IPv4. Действительно, стоит более детально рассмотреть вопрос о том, может ли такое произойти в IPv4 и каковы будут последствия. Или что произошло бы в мире, где используется только один стек? Еще один момент, который необходимо учитывать, — это способы защиты сетей от такого рода событий. Например, для сетей с оборудованием Juniper существует специальный документ, в котором описаны меры защиты от проблем, связанных с атрибутами. Поэтому тем, кто использует данное оборудование, рекомендуется изменить конфигурацию в соответствии с этим документом. Тем же, у кого установлено другое оборудование, лучше выяснить, защищают ли данные платформы от подобных проблем и каким образом. Стоит отметить, что ранее в RIPE Labs мы уже исследовали атрибуты BGP, неизвестные парсеру bgpdump, и на основе этого составили список неизвестных атрибутов, которые встречались в реальности на тот момент. В это время мы также обнаружили пакеты с атрибутом BGP 28. Интересным исследовательским проектом может стать изучение того, как использование и видимость этих атрибутов менялись с течением времени. Парсинг данных BGP/MRT с такими атрибутами — дело непростое. В данном случае единственное, что мне помогло, это использование bgpdump в многострочном формате и выполнение пользовательской постобработки. Хотя данный способ не является достаточно быстрым для извлечения этого сигнала из собираемых нами данных. Непосредственным следствием этого события стало то, что в пакет инструментов обработки MRT BGPKIT были внесены улучшения, направленные на более эффективную обработку неизвестных и устаревших атрибутов BGP. В следующий раз, когда мне понадобится проанализировать подобное событие, я обязательно воспользуюсь BGPKIT. Вот некоторые из вопросов, которые возникают у меня в связи с этим: В какой степени сложность BGP становится проблемой для интернета? Это не новый вопрос. Аналогично тому, как это происходит с DNS — у нее даже есть имя и соответствующий представитель животного мира: DNS Camel! [Верблюд] — то, возможно, BGP достиг того уровня сложности, который препятствует развитию и функционированию междоменной маршрутизации в интернете. Протокол camel начинался с DNS, а сейчас также включает BGP и NTP. Поскольку наш выбор пиров маршрутных коллекторов достаточно предвзятый ("clue core" [сравнение с ядром]), каковы истинные масштабы этого события, и в какой степени нашему пониманию состояния интернета могут помешать те места, для которых мы не собираем данные о BGP? В какой степени тестируются и укрепляются имплементации BGP? Я считаю Juniper одним из ведущих производителей в этой области, и думаю, что они тратят значительные усилия на обеспечение качества и тестирование. На самом деле меня больше беспокоят поставщики, у которых меньше ресурсов для обеспечения качества и тестирования. Какие здесь таятся баги? В какой степени имплементации BGP подвержены "взлому"? Беглый поиск в интернете показал, что, по крайней мере, некоторые из этих процессов имеют место. Например, вот этот недавний материал об уязвимостях, найденных в результате фаззинга BGP. Есть над чем подумать. Я надеюсь, что у людей есть ответы. Было бы здорово обсудить это в нашей теме на форуме RIPE NCC. Распределение префиксов, встречающихся в BGP-сообщениях, содержащих  атрибут 28 AS-пути О мониторинге протокола BGP продолжим говорить 3 августа на бесплатом открытом уроке. Мы рассмотрим протокол BMP и его возможности для мониторинга обновлений протокола BGP. Настроим коллектор для приема логов BMP и обсудим возможности для их дальнейшей обработки. Записаться можно по ссылке.  Редактор