Еще больше «утечек» маршрутов

Джефф Хьюстон

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

Большую часть времени почти везде большая часть Интернета функцио­нирует просто прекрасно. И действи­тельно, кажется, что Интернет работает до­статочно хорошо – вплоть до того момента, когда начинаются серьезные неприятности. После этого он превращается в повод для за­головков в отраслевой прессе.
В этот раз проблемы начались 12 июня в Малайзии у крупного интернет-провайдера страны – компании Telekom Malaysia. Рас­сматривая сейчас, что случилось и почему это произошло, возможно, полезно будет начать с краткого резюме, описав то, каким образом Интернет «знает», где все находит­ся. Итак, краткое отступление на тему си­стемы маршрутизации.
Связность и маршрутизация в Интернете – краткий курс
При установлении соединения двух сетей способ, с помощью которого они узнают друг о друге, заключается в обмене марш­рутной информацией. В этом случае сеть можно себе представить как набор дости­жимых IP-адресов (маршрутов), а соеди­нение двух сетей реализует простую форму следующего утверждения: «Я скажу тебе мои маршруты, а ты расскажешь мне о своих».
Давайте рассмотрим две сети и назовем их A и B. И давайте предположим, что сети A и B соединены между собой таким спосо­бом. Теперь если источник в сети A желает отправить пакет в некий пункт назначения в сети B, то поскольку A и B напрямую со­единены между собой, сеть A знает все о наборе IP-адресов, которые достижимы в сети B.
Поэтому система маршрутизации сети А направит пакет в сеть В.

Теперь давайте добавим в эту модель тре­тий элемент. Что если у нас имеется третья сеть, C, которая соединена с сетью B? Если сеть B была подготовлена, чтобы действо­вать в качестве «транзитного» провайдера услуг, тогда В может объявить маршруты сети С в А в дополнение к своим собствен­ным маршрутам и объявить маршруты сети А в С. Теперь все точки этих трех сетей мо­гут достигнуть друг друга. Если источник в сети А отправляет пакет в пункт назначения в сети С, то система маршрутизации сети А направит пакет в сеть В, поскольку сеть А узнала о маршрутах в С через сеть В. Систе­ма маршрутизации сети В признает адрес назначения как расположенный в сети С и передаст пакет в С.

Обычно мы называем сети A, B и C Авто­номными системами, а протоколом маршру­тизации, используемым для обмена марш­рутами в Интернете, является BGP (Border Gateway Protocol, Протокол пограничной маршрутизации). Если вы повторите выше­приведенный сценарий межсетевого соеди­нения еще 50 тысяч раз для учета взаимных соединений 50 тысяч сетей и примените протокол BGP для обмена информацией о маршруте по 560 тысячам маршрутов, то у вас получится что-то, по масштабам напо­минающее современный Интернет.
Существует множество способов для сое­динения между собой 50 тысяч Автономных систем с использованием базового парного соединения. Можно использовать линей­ные соединения, кольца, веерную структуру или любую форму топологии соединений. Один из примеров визуализации межсете­вого соединения в Интернете показан ниже: Что формирует конкретную конфигура­цию Интернета? Лучший ответ, который я могу предложить, заключается в том, что форму Интернета определила комбинация денег и географии. География – это тен­денция сетей соединяться с другими сетя­ми, которые расположены на физически близком расстоянии. Существует мощная индустрия, посвященная эксплуатации так называемых точек обмена по всему миру.
Точка обмена представляет собой вы­деленную систему, к которой локальные сети могут подсоединиться и использо­вать коммутационное оборудование точки обмена для установления соединения со всеми другими сетями, представленными в этой точке. Заинтересованность в гео­графической близости объясняется про­изводительностью и, конечно, деньгами. Если две сети соединены каналом, кото­рый проходит по всему миру, то время, необходимое пакету для прохода по этому расширенному пути, будет гораздо боль­ше того интервала, который потребуется пакету для путешествия по соединению, охватывающему область города или реги­она. Поэтому более близкое соединение позволяет предоставить более качествен­ные услуги пользователям. И хотя это и не является универсальной истиной, чаще всего более протяженные маршруты, осо­бенно пересекающие один или несколько океанов, имеют более высокую стоимость из расчета на пакет, чем менее длинные «дороги». В общем, получается, что более короткие пути дешевле.
Деньги являются главной движущей си­лой для установления межсетевых соеди­нений, поскольку в конечном счете именно деньги двигают вперед эту индустрию. Для того, чтобы это проиллюстрировать, давай­те вернемся к нашему простому примеру сетей A, B и C. Когда сеть C соединяется с B, что будет мотивировать сеть B на анонсиро­вание маршрутов в C для сети A? Не забудь­те о том, что в этом случае трафик, текущий между A и C, будет потреблять сетевые ре­сурсы B, однако сеть B не имеет прямых отношений с любым из конечных пользо­вателей, которые генерируют этот поток трафика. Поэтому сеть B не может выста­вить счета ни заказчику сети А, ни заказ­чику сети С для получения компенсации за предоставление этой услуги. Одно из жиз­неспособных решений заключается в том, что сеть С платит сети В за эту транзитную услугу. В действительности сеть B является провайдером сети С или, если посмотреть с другой стороны, С является клиентом В. Теоретически возможно так организовать мир соединенных между собой сетей, чтобы превратить его в соединительную сетку, ис­пользуя для этого только взаимоотношения типа клиент-провайдер, однако сделать это порой довольно сложно. Для того, чтобы это проиллюстрировать, давайте добавим в наш пример еще одну сеть – сеть D, кото­рая является клиентом A. Теперь, когда D обменивается трафиком с C, эта сеть будет платить A, а C будет платить сети B – соглас­но тому, что можно ожидать от отношений типа клиент-провайдер. Но что можно ска­зать об отношениях между сетями A и B? В ряде случаев, когда A и B имеют сходный размер и масштаб, нелегко естественным образом определить, кто является про­вайдером, а кто клиентом. Индустрия ISP (провайдеров интернет-услуг) изобрела до­полнительную форму отношений для раз­решения именно такой ситуации, которая представляет собой отношение «с равным по положению», в рамках которого две сети соединяются между собой, но соглашаются не выставлять друг другу счета (это пред­ставляет собой старое соглашение SKA, или Sender Keeps All – соглашение о бесплатном пиринге).
В результате у нас имеются три возможные роли сети в сфере межсетевого соединения: клиент, провайдер и равный партнер, или пир. При этом многие сети играют все три роли одновременно. Имея в виду, что сеть генерирует доход со своих клиентов, тра­тит деньги на провайдеров и занимает ней­тральное положение в отношении доходов для своих пиров, очевидно, что провайдеры стремятся максимизировать привилегии в отношении своих клиентов по сравнению с пирами и провайдерами и предпочитают партнеров провайдерам. Таким способом провайдер может максимизировать свой до­ход и свести к минимуму расходы.
Способ, которым это реализовано в маршрутизаторах сети, заключается в ис­пользовании в BGP локальных настроек предпочтений. Все внешние соединения просто относят к одной из этих категорий, после чего можно использовать локальную настройку предпочтений, чтобы предпо­честь объявленные клиентом маршруты по сравнению с объявленными партнером и провайдером, а объявленные партнером маршруты – по сравнению с объявленны­ми провайдером. Поэтому если сеть видит один и тот же маршрут, анонсированный со стороны клиента, а также со стороны партнера или провайдера, то локальная настройка предпочтений гарантирует, что сеть выберет маршрут через клиента, а не через партнера.
Эти локальные настройки предпочте­ний имеют высокий приоритет в алгорит­мах принятия решений BGP: локальные предпочтения переопределяют алгоритм сравнения BGP по умолчанию, который сравнивает длину маршрутов между Авто­номными системами. Поэтому даже если сеть использует механизм добавления АS в AS-PATH для того, чтобы повлиять на вы­бор маршрута, настройки локальных пред­почтений берут вверх.
Кроме того, полезно понимать предпочте­ния сети относительно ре-анонсирования, поскольку они также являются частью про­цесса попыток сети оптимизировать свое положение за счет максимизации доходов и минимизации расходов, а также прекратить «бесплатную езду», при которой ресурсы сети используются нефинансируемым тра­фиком.
Для выполнения этой задачи большин­ство сетей использовало следующие базо­вые правила распределения анонсов:

• маршруты, о которых стало известно от клиента, анонсируются клиентам, пирам и провайдерам;
• маршруты, о которых стало известно от пира, анонсируются клиентам, но не дру­гим партнерам или провайдерам;
• маршруты, о которых стало известно от провайдера, анонсируются клиентам, но не другим провайдерам или пирам.

Эти правила схематично показаны на ри­сунке ниже. Крестиками отмечены недопу­стимые анонсы.

Что произошло?
Теперь давайте возвратимся в 12 июня и посмотрим на то, что случилось. Совершен­но определенно что-то произошло, как это можно увидеть на приведенных ниже двух графиках. Первый представляет собой по­часовой график общего количества пре­фиксов, объявленных в таблице маршрути­зации Интернета (рис.1).
Рис. 1  Размер таблицы маршрутизации: неделя, начинающаяся с 9 июня 2015 г. (www.potaroo.net)

Это выглядит так, будто в систему марш­рутизации были добавлены дополнитель­ные 2500 маршрутов, а затем через пару часов примерно 5500 маршрутов были ото­званы, после чего 2500 маршрутов были восстановлены, оставив в таблице маршру­тизации примерно на 500 маршрутов мень­ше по сравнению с исходным состоянием.
Похожая картина становится очевидной при взгляде на обновления в BGP за тот же самый период, в рамках которого измене­ние в размере таблицы BGP совпало с соответ­ствующим взрывом в опе­рациях обновления BGP. Смотреть рисунок 2.
Этот взрыв активности имел своим источником AS4788 – сеть, которую эксплуатирует компания Telekom Malaysia.
Telekom Malaysia – это относительно крупный провайдер в Малайзии. Клиентская база этой компании составляет примерно 15 миллио­нов пользователей из своей собственной сети, кроме того, она предоставляет тран­зитные услуги 64 другим сетям, большая часть из которых базируется в Юго-Вос­точной Азии. Эта сеть также, по-видимо­му, соединена с 13 восходящими (более крупными) провайдерами. Восходящие провайдеры и количество префиксов, ви­димых через каждого провайдера с пункта наблюдения, расположенного в Австралии в AS131072, имеют следующий вид: Смо­треть таблицу 1 (*По-видимому это некий вид ошибки маршрутизации)

• Таблица 1 Провайдеры транзита и количество префиксов

Рис. 2 Активность обновления маршрутизации: неделя, начинающаяся с 9 июня 2015 г.

Подобно многим другим ISP с большим набором восходящих провайдеров, Telekom Malaysia использует метод анонсирования более детальных маршрутов для управле­ния нагрузкой трафика через различные межсетевые соединения. В данном случае компания Telekom Malaysia взяла 56 блоков адресов IPv4, которые она получила от сво­ей локального Регионального Интернет-ре­гистратуры и анонсировала примерно 2.200 отдельных префиксов, в основном исполь­зуя префиксы /24 («more specifics» – более детальные префиксы, которые имеют прио­ритет в маршрутизации BGP), извлеченные из изначальных блоков адресов. Анонси­рование 1.144 более детальных префиксов делает Telekom Malaysia одним из крупней­ших генераторов таких префиксов в совре­менном Интернете, но отнюдь не самым крупным. Этот подход, который заключает­ся в регулировании трафика, передаваемого по различным физическим соединениям, при помощи выборочного анонса более детальных префиксов, может быть общей практикой, однако он по-прежнему остается сложным. И конечно, сложные подходы ча­сто превращаются в эксплуатационно хруп­кие способы и методы реализации, которые имеют склонность к поломкам.
И это именно то, что случилось 12 июня с Telekom Malaysia.
То, что увидел остальной мир, было вспле­ском анонсов маршрутов, источником кото­рого стала сеть AS4788, включая примерно 2500 новых префиксов, которых раньше не было. Через пару часов случился крупно­масштабный отзыв примерно 5500 префик­сов, после чего состоялась стабилизация с повторным объявлением около 2500 пре­фиксов, согласно показанному на рис. 3.
Если мы посмотрим на сеть AS4788 и взглянем на обновления, поступающие из этой Автономной системы, то их можно разбить на префиксы, порожденные самой сетью AS4788, и префиксы, для которых AS4788 является транзитным провайдером. График анонсов для AS4788 за 12 июня по­казывает быстрый рост активности в 08:43, который продолжается 9 минут.
Большая часть этой активности по обнов­лению маршрутов имела место в виде анон­сов маршрутов, в которых сеть AS4788 была транзитной АS, а не новых маршрутов от самой AS4788.
Так что же произошло? Существуют два главных вида утечки маршрутов: один, при котором сеть импортирует узнанные через eBGP маршруты в одной части своей сети и преобразовывает внутренние маршруты в экспортируемые eBGP маршруты в другой части сети. Маршруты, которые по ошибке обрабатываются таким образом, видятся другим сетям, как будто они берут начало в этой сети. Другой вид утечки заключается в том, что полученные через eBGP маршруты из одной сети-пира по ошибке экспортиру­ются другому пиру. В этом случае внешнее представление заключается в том, что утек­шие маршруты указывают на эту сеть как на транзитную.
В случае данной конкретной утечки мы видим утечку транзитных маршрутов, при которой сеть AS4788 ошибочно аннонсиро­вала маршруты, узнанные от одного пира, другому пиру.
Какие маршруты были при этом затрону­ты? Список, включающий все 22.577 марш­рута, слушком длинный, чтобы приводить его здесь, однако давайте взглянем на набор соседних Автономных систем, чьи маршру­ты, по-видимому, повторно аннонсирова­лись сетью AS4877 в течение этого периода. В таблице 2 приведены верхние 20 строк списка, увиденные с наблюдательного пун­кта BGP, расположенного в сети AS4777 в Японии.
Этот список сильно отличается от списка провайдеров транзита, который приведен в таблице 1. Вероятная причина заключается в том, что сеть AS4788 присутствует в целом ряде точек обмена (трафиком) и принимает большое число маршрутов из этих точек об­мена. В ходе этого инцидента с маршрутами сеть AS4788 переаннонсировала эти полу­ченные маршруты обратно провайдерам транзитам. Для маршрутов, транзитный путь которых через AS4877 являлся более коротким, этот альтернативный путь был выбран этими транзитными сетями и рас­пространен дальше их собственным пирам.
Теперь мы, вероятно, достаточно близки к тому, чтобы понять, что произошло 12 июня внутри сети AS4788. В рамках приведенно­го выше «букваря» маршрутизации говори­лось, что, как показывает опыт, существуют три руководящих принципа маршрутиза­ции:

• маршруты, о которых стало известно от клиента, анонсируются клиентам, пирам и провайдерам;
• маршруты, о которых стало известно от пира, анонсируются клиентам, но не дру­гим партнерам или провайдерам;

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

• Таблица 2 Утечка транзитных маршрутов

• Судя по всему, сеть AS4877 переанонси­ровала маршруты, которые она получила от пиров (возможно от DECIX), своим про­вайдерам транзита, осуществив своего рода «захват» маршрутов. По-видимому, это произошло из-за ошибки конфигурации политики маршрутизации в маршрутизаторе eBGP внутри сети AS4877.
• Предотвращение
• Этот вид утечки маршрутов не является ред­костью. Однако когда это происходит, послед­ствия могут быть крайне разрушительными. Можно ли предотвратить такую утечку?
• RPKI?
• Сегодня мы слышим много рассуждений об инфраструктуре открытых ключей для ресурсов нумерации (Resource Public Key Infrastructure, RPKI) и объектов авторизации маршрутов (Route Origination Authorisations, ROA). Если бы соседи сети AS4877 по eBGP внедрили управление фильтрацией на ос­нове ROA, то предотвратили бы эту утечку маршрутов?
• Объекты ROA удостоверяют источник маршрута и не дают неавторизованным Ав­тономным системам инициировать марш­рут для префикса. В нашем случае из 22 577 утекших маршрутов только 1594 имели своим началом сеть AS4877. Это означает, что в лучшем случае механизм фильтрации маршрутов на основе ROA – если бы он был внедрен всеми пирами AS4877 и всеми дер­жателями префиксов – был бы эффективен при отфильтровывании только 7% утекших маршрутов. Проблема же заключается в том, что утекала информация о транзите, поэтому фильтры, базирующиеся на опре­делении происхождения (маршрутов), ока­зались бы, в основном, не эффективны.
• Если это так, то что произойдет, когда мы реализуем защиту пути следования АS-PATH? Что если все соседи сети AS4877 внедрили бы полный пакет BGPSEC и при­менили валидацию пути для всех маршру­тов, полученных от AS4877. Наверняка это позволит обнаружить проблему и отклонить утекшие маршруты. Да?
• Нет.

Если вы получаете маршрут с AS-PATH: A B C и источник в АS C был проверен, то един­ственным способом, с помощью которого вы можете определить, что этот маршрут явля­ется ненамеренной утечкой по сравнению с обычной работой BGP, это не просмотр того, как работает протокол сам по себе, а изуче­ние намерений в политике маршрутизации сетей A, B и C и определение того, является ли, согласно наблюдениям, поведение пути следования АС намеренным в рамках по­литик маршрутизации этих сетей. Однако защищенный протокол BGP не содержит информации о политиках маршрутизации. Защищенный протокол BGP может позво­лить вам проверить, что держатель префик­са уполномочил С на инициацию маршрута, а это он и делает. Защита пути в рамках за­щищенного BGP может также позволить вам проверить, что сеть С передала объявление в сеть B, которая, в свою очередь, передала его в A. Поэтому с точки зрения безопасного BGP в этом маршруте нет ничего недопусти­мого. BGPSEC не может информировать вас о том, является ли это намеренным объяв­лением маршрута или неавторизованной утечкой маршрута.
Поэтому сервис RPKI здесь не поможет. Нет ничего «неправильного» в работе про­токола маршрутизации BGP как такового, и не было и умышленных попыток фаль­сифицировать информацию о маршрути­зации. Проблема заключается в том, что информация о маршрутизации, которая в остальном является правильной, была пере­анонсирована соседям, которые не ожидали услышать об этих маршрутах. Клиент сети переанонсировал транзитные маршруты, и без наличия дополнительных знаний о кон­цепциях политики маршрутизации, таких, как «транзит», «клиент» и «пир», система маршрутизации не может автоматически обнаружить такие пробелы в целостности предполагаемой политики маршрутизации.
Реестры маршрутов?
Использование Реестров интернет-марш­рутизации (Internet Routing Registries) и связанного с ними Языка специфика­ций политики маршрутизации (Routing Policy Specification Language, RPSL) (RFC 2622, RFC4012) является альтернативным подходом к ручному управлению фильтра­ми маршрутов. RPSL – это относительно богатый язык, он, как говорит его название, позволяет пользователю описывать поли­тики импорта и экспорта сети в терминах взаимоотношений с соседними Автоном­ными системами и ее политики транзита (переанонсирования).
Использование таких описаний в кон­тексте реестра маршрутизации позволяет оператору сети перечислить все префиксы, инициированные локальной Автономной системой, и политики транзита, которые связаны с этими маршрутами. Кроме того, это позволяет оператору сети описать свои политики анонсирования, задав соседние АS и политики маршрутизации для марш­рутов, полученных от соседних АS.
Если бы каждая Автономная система поддерживала точный, актуализирован­ный и полный набор префиксов и записей политики маршрутизации в Реестре ин­тернет-маршрутизации, то, по-видимому, для АS было бы теоретически возможным сгенерировать набор фильтров префиксов и AS-PATH для всех своих соседей путем по­иска в рамках всего содержимого реестра. И действительно, существуют инструменты, которые пытаются сделать именно это для существующих реестров маршрутов.
Тогда почему мы все не делаем именно это? Почему мы не используем эти инструменты для реестра маршрутов как часть стандарт­ной процедуры эксплуатации?
История использования реестров маршру­тов вызывает очень смешанные чувства.
Эти реестры существуют в той или иной форме вот уже на протяжении почти двад­цати лет. Некоторые регионы мира очень усердно принуждали каждого сетевого оператора своего региона вести точную ин­формацию в локальных реестрах маршру­тизации. Однако в других случаях история реестра маршрутов не была столь обнаде­живающей.
RPSL – это сложный язык, с его помощью может быть довольно трудно точно описать хитросплетения некоторых политик марш­рутизации. Часто происходит, что реестр заполнен записями «на всякий случай», а также историческими записями, поэтому чрезвычайно трудно отсортировать то, что относится к текущим концепциям марш­рутизации от других посторонних данных. Выполнение этой задачи с помощью авто­матического инструмента для сканирования реестров до сих пор оказывалось невозмож­ным. Справедливо также и то, что сетевые операторы часто используют уровень де­тализации, связанный с каждым сеансом eBGP между соседними АS, тогда как RPSL использует более грубый уровень детализа­ции – отдельные АS. Поэтому труднее опи­сать отдельные политики маршрутизации, которые применяются к различным сеан­сам BGP между одними и теми же двумя АS. Кроме того, существует вопрос относитель­но того, насколько комфортна для сетевых операторов публикация такой детальной информации о своих политиках маршрути­зации.
Используемые сегодня реестры маршру­тов имеют разнообразные модели аутен­тичности и целостности. Во многих случаях возможно, чтобы пользователь реестра вво­дил информацию о маршрутизации для сто­ронних префиксов, не имея полномочий со стороны фактического владельца префикса. Отделение достоверной информации от не­достоверной не поддерживается моделью данных реестра, которая обычно не вклю­чает в себя информацию о валидации или полномочиях. Кроме того, существует мно­жество реестров маршрутов, и часто они содержат противоречащую информацию. Какой из реестров должен иметь приори­тет, если кто-то попытается разрешить эти содержащиеся в данных противоречия? И почему?
Эта проблема достаточно сложна уже сама по себе, однако ее еще больше усугубляет тот факт, что во многих областях Интерне­та операторы отказались от применения реестров маршрутов и полагаются на соб­ственные кастомизированные инструмен­ты. Поэтому меняется не только качество информации, содержащейся в реестрах маршрутов, но и полнота этой информации.

• Рис. 3 Активность обновления маршрутизации: AS4788 0830 – 09:30, 12 июня

«Безовражная» маршрутизация?
Возможно мы пытаемся быть слишком умными и используем излишне сложные инструменты для решения того, что в дей­ствительности является простой пробле­мой. Проблема, которая произошла в сети AS4778, заключалась в переанонсировании маршрутов, о которых стало известно от пи­ров и транзитных систем, другим транзит­ным системам.
Принцип политики маршрути­зации, целью которого являет­ся предотвращение этого вида утечки маршрутов – это концепция, получившая название «valley-free routing» — маршрутизация «без долин» или «безовражная» марш­рутизация.
Если маршрут проходит из сети клиента в сеть транзитного провайдера, то этот сег­мент называют «восходящим» сегментом. Если маршрут проходит пиринговое соеди­нение, то это «пересекающий» сегмент. И если маршрут проходит из сети транзитного провайдера в сеть клиента, то это «нисхо­дящий» сегмент. Последовательность этих маршрутных пар может начинаться с после­довательности восходящих сегментов, затем самое большее один пересекающий сегмент и после этого последовательность нисходя­щих сегментов. Путь «безовражного» марш­рута не включает нисходящий сегмент, сра­зу за которым следует восходящий.

Рис. 4 Пример топологии между АС для маршрутизации без долин

В показанном здесь примере (рис. 4) маршрут, начинающийся в АS А, может быть распространен по пути A B C D до сети AS4788, и при этом он удовлетворяет «без­овражному» ограничению. Однако после получения сетью AS4778 маршрут не мо­жет быть продолжен в E или F, поскольку это нарушит «безовражное» ограничение (эти пути формируют своего рода овраг – прим. ред). Маршрут, начатый в G, может быть продолжен в D, E и F согласно тому же принципу. Если он продолжен в D, то согласно данному принципу он может быть далее продолжен из D в C, B и A. С другой стороны, маршруты, начинающиеся из E и F, могут быть продолжены сетью AS4788 только в G, но не в D.
Такое ограничение можно относительно легко встроить в протокол BGP как атри­бут транзитного сообщества, называемый UP. Если маршрут начинается с атрибу­том UP, то его можно анонсировать во все соседние узлы eBGP. Однако обращение с атрибутом при продолжении маршрута зависит от отношения между сетью и со­седней сетью. Если сосед является транзит­ным провайдером, то атрибут UP остается неизменным. Если сосед является пиром или нисходящим клиентом, то атрибут UP снимается при переходе маршрута к соседу. Если маршрут начинается без атрибута UP, то его можно передать только нисходящим соседям-клиентам.
Хотя такой механизм является простым и, несомненно, эффективным во многих сце­нариях, возможно, он слишком простой. В теории, каждая АS имеет единую политику маршрутизации, и все отношения Автоном­ных систем можно однозначно классифи­цировать как провайдер-клиент или пи­ринг, однако в реальном мире присутствуют более тонкие нюансы, и отношения между АS нельзя втиснуть в эту очень простую мо­дель.
И это весьма печально в некоторых от­ношениях, поскольку такой более простой мир сделал бы обнаружение и предотвра­щение утечек маршрутизации гораздо бо­лее легкой задачей!
Куда теперь?
Некоторые многолетние проблемы явля­ются такими давними из-за того, что мы не сумели применить подходящий аналитиче­ский подход к их решению. Решение где-то рядом, но нужно приложить некоторые уси­лия по его поиску!
Мы можем в очередной раз попробовать принудить индустрию к использованию реестров маршрутов для внешней маршру­тизации, однако чем будет отличаться этот призыв к использованию реестров марш­рутов от всех других подобных призывов в прошлом? И если отличий не будет, то поче­му такой призыв встретит более радостный отклик по сравнению с тем, что случилось в прошлом?
Возможно, мы могли бы использовать цифровые подписи и RPKI, чтобы объеди­нить аутентичность информации с реестра­ми маршрутов. Однако проблема, с которой мы столкнемся в этом случае, будет заклю­чаться в том, что и так уже сложная система станет еще более сложной и трудной в ис­пользовании.
Возможно, данная конкретная пробле­ма относится к другому типу многолетних проблем. Некоторые проблемы становятся давними просто потому, что они являются исключительно трудными проблемами!
Это заставляет меня задаться вопросом, существуют ли альтернативные перспекти­вы в той области, в которой мы работаем. Например, не стали бы мы рассматривать эту проблему по-другому, если бы думали о маршрутизации не как об инструменте топологии и достижимости, а как о распре­деленном алгоритме для решения системы уравнений. Уравнения здесь выражают по­литики маршрутизации, а целью алгоритма является нахождение решений, которые ре­шают отдельные уравнения, а также нахож­дение общесетевого решения максимальной связности. Будет ли такая перспектива обе­спечивать получение отличающихся выво­дов относительно способа, в рамках которо­го взаимодействуют политики и протоколы маршрутизации? И может ли такая перспек­тива обеспечить получение предложений относительно того, каким образом мы мо­жем защитить систему маршрутизации не только от умышленных злоупотреблений и неправомерных действий, но от несчастных случаев в форме утечек маршрутов?

Источник: “More Leaky Routes” . Geoff Huston. The ISP Column