Комментарии 15
Никому не хотелось бы вводить лишние механизмы, но — они появились и в том числе как мера борьбы с откровенными ошибками либо даже атаками, нарушающими связность (за последние годы их было все больше).
Собственно, интернет (весь, не только про связность говорю) как система без единого центра и без механизмов обратной связи («наказания», если хотите) никогда не было неуязвим для кривых рук и злого умысла. Тот же банальный SMTP придуман как протокол для отправки почты — а оказалось, что спамеру никак не сделать ай-яй-яй. Придуманные позже RBL — те еще бесконтрольные костыли, и управляются уже отнюдь не «всем сообществом», правильно?
Не буду писать примеры по каждому протоколу, но мы с вами живем в старых мыслях о «разумном сообществе», а реалии давно изменились в сторону «ничего личного, это бизнес/война/так надо». Политика, которую вы упомянули, прямо суперпример — начиная с санкций, вроде бы нифига несимметричных, и заканчивая золотодолларовым стандартом — «те, кто выше» гребут мир в сторону, им более удобную. В этом смысле мы с вами уже давно профукали старый добрый свободный интернет, в т.ч. и потому, что у нас и способа-то не было противостоять (да, как раз согласно нами же придуманным протоколам его).
Поэтому музыку заказывает не сообществом а немногие, «вылезшие вперед». Хорошие они, или плохие — дело десятое (и там даже сразу не понять, кто есть кто в результате), но мы (многие неактивные) в результате только «откидываемся на спинку», и — смотрим, иногда отпуская замечания.
Древовидная выдача сертификатов никак не препятствует построению сети в виде паутины.
Утверждение «По принятому протоколу доверие маршрутам обеспечивается только согласно иерархическим лицензиям, выданным от основных их владельцев — крупнейших телекомов бэкбона Интернета» — это вот просто ерунда, простите. Доверие в RPKI строится по цепочке End User -> LIR -> RIR -> IANA, причем по факту у IANA корень виртуальный, и сейчас всё кончается на RIRах (Региональных Интернет-Регистратурах, в нашем регионе это RIPE NCC). Интернет-регистратура — это НЕ оператор, и НЕ представитель «крупнейших телекомов».
Всё, что делает RPKI — это определяет, какая AS может анонсировать заданный префикс. Эту связку устанавливает ровно тот, кто является держателем префикса, а цепочка подписей уходит в RIR, чтобы можно было убедиться в валидности подписи держателя. Всё. Другими словами, это механизм, который более эффективно делает то, для чего раньше создавалась IRR-часть базы данных RIR (то есть, объекты route:, aut-num: etc). Как с RPKI, так и без него строится плоская сеть, как это было всегда.
Поэтому «Существующие ассоциации (пиринговые центры) наподобие российских MSK-IX или DATAIX, пока что довольно влиятельные, потеряют возможность обмениваться трафиком, так как их участники не смогут обмениваться маршрутами, нарушая границы своих иерархий, то есть обмен налево будет затруднён» — это совершенно неверно. Никакой пиринг не ломается от RPKI. LIR на IX анонсирует свои сети, у анонса валидная подпись (то есть, эта вот AS может анонсировать вот этот вот префикс), и всё живёт как всегда жило.
Российская точка обмена трафиком Msk-IX, кстати, уже проверяет RPKI.
В общем, простите, но вы толком не разобрались в RPKI.
>Российская точка обмена трафиком Msk-IX, кстати, уже проверяет RPKI.
А отбрасывает ли? И как бы пока М(Г)ТС и Ростелеком не введут, фиг мы тут что нормально заведем. isbgpsafeyet.com
>Интернет-регистратура — это НЕ оператор, и НЕ представитель «крупнейших телекомов».
RIR владеют нумерационным ресурсов Интернета, т.е. в принципе Интернетом. Если он отберет AS у оператора… Ему как бы крышка на рынке.
Во-первых, IGF не является органом управления ничего, это просто болтательный форум, причем большой IGF (под эгидой ООН) не имеет права принимать решения. Вы сами поучаствуйте в каком-нибудь IGF, поймёте. В этом году большой IGF вообще в online происходил, был хороший шанс поглядеть, что оно такое.
Во-вторых, NRO/ASO не имеют к RPKI отношения, вверху там виртуальная IANA, и, как я сказал, на самом деле цепочка останавливается на RIRах, на практике-то.
В-третьих, NRO/ASO — такая же часть ICANN, как и IANA. Повторю, если непонятно: это не ICANN является подрядчиком IANA, а IANA является департаментом ICANN, функции которого сейчас вообще отданы внешней организации: функцию IANA сейчас выполняет PTI, в котором RIRы, кстати, прекрасно участвуют.
В-четвертых, Сноуден так ну вот вообще никаких боком. То есть никак.
В-пятых, скажите, а где вы это всё взяли? А то на @enogtalk, кажется, я вот это всё, включая Сноудена, уже слышал, и изумлялся. Думал, один раз, а оно, оказывается, городская легенда Интернета.
>> Российская точка обмена трафиком Msk-IX, кстати, уже проверяет RPKI.
> А отбрасывает ли? И как бы пока М(Г)ТС и Ростелеком не введут, фиг мы тут что нормально заведем.
Кажется, только помечает, давая возможность отбрасывать участникам. Но это неважно, контекст был — что RPKI поломает возможность работы российских IX. Нет, не поломает.
> RIR владеют нумерационным ресурсов Интернета, т.е. в принципе Интернетом. Если он отберет AS у оператора… Ему как бы крышка на рынке.
RIR не может ничего просто так отобрать, действия RIRа диктуются документами (называемыми «политиками»), принятыми в регионе. В регионе RIPE, например, технические политики принимаются широким техническим сообществом в рабочих группах, куда вступить может любой, и это прописано в уставе RIPE NCC (организации, работающей RIR в регионе RIPE).
На случай, если сотрудник RIPE NCC совершает ошибку, есть механизм арбитража. Арбитры выбираются из представителей сообщества, не связанных с RIR. LIR, в отношении которого совершено, как он считает, несправедливое действие, может подать заявку на арбитраж, и один из арбитров получит все материалы по данному случаю, чтобы принять решение о правильности действия. Его решение обязательно для исполнения.
Наконец, все RIRы работают в определенной юрисдикции, и подчиняются обычным законам. В частности, RIPE NCC работает в юрисдикции Нидерландов. Действие RIPE NCC может быть оспорено в суде. А вся система LIR-RIR-ICANN работает, по сути, на доверии. Поэтому RIPE NCC никогда не размахивает шашкой, потому что такую систему гораздо проще поломать, чем потом починить.
Дерегистрация ресурсов иногда случается, да, но это очень редкий случай, и она проходит не по желанию левой пятки RIR, а в результате неоднократного грубого нарушения оператором каких-то политики, и тоже оформляется строго в соответствии с действующими политиками же.
Ну и всё это не имеет отношения к теме, вообще-то. В статье шла речь про то, что большие телекомы с помощью RPKI могут командовать маленькими. Это неверно. Не могут. А RIRам RPKI никаких новых возможностей в этом смысле не даёт. Особенно если учесть, что предшественник RPKI, роутинговая часть RIR DB, существует не первое десятилетие.
Да, действительно, я не продвинутый специалист именно в этой области, хотя некоторый опыт и знания имеются.
Давайте на какой-нибудь конкретной модели разберём, что я имел в виду. На абстрактных понятиях, да ещё без полной уверенности в правильном их понимании трудно объясняться.
Итак, обычная, на мой взгляд, иерархическая схема подключения Интернет-провайдеров к сети. Стрелки с треугольниками — основное подключение с выделением адресов (и соответственно подписей к ним в RPKI). Стрелка галочкой — пиринг.
В этой модели я предполагаю, что провайдеры, подключенные к точке обмена, приходят туда с такой картиной мира, такими цепочками связности и объявляют их.
То есть провайдер P2.2 объявляет маршрут вплоть до P1.1.1 или обобщённо до P1.1 или даже IPS1 как последовательность P2.2 -> ISP2 -> P1.2 -> IPS1 (-> P1.1 -> P1.1.1). По идее, он может это сделать, так как есть физический коннект ISP2 -> P1.2 между сетями 1-го и 2-го регионального провайдера, и о нём известно P2.2.
Точно так же анонсируются цепочка P4.2.1 -> P4.2
Мне бы прояснить, могут ли участники пира объявить в новых условиях пути до подсетей, сокращающих сетевые расстояния, которые к ним прямого отношения не имеют (P1.2, P1.1 и P1.1.1 для P2.2)? Если нет, то это вроде бы значит, что пиринг запрещён/сломан.
Теперь, что касается коммерческих и бюрократических инстанций. Да, подписи анонсов выдаются RIR/NIR или аффилированными структурами. Но получают их в своей массе всё равно те же владельцы адресов, коммерческие сети и в тех же объёмах, в каких у этих сетей есть номерная ёмкость. А значит глобальные игроки получают корневые сертификаты даже не одного региона, а сразу нескольких и могут теоретически распоряжаться ими как угодно.
То есть фактическими распорядителями маршрутов становятся только глобальные телекомы (содержатели физических каналов) и им лояльные суб-провайдеры. В этом моё опасение.
Делегирование от РИРов на первой схеме, конечно отличается от провайдерского.
Во-вторых, поймите одну простую мысль: в RPKI сейчас держатель префикса привязывает его к первой AS в цепочке (есть сейчас драфт ASPA, который, однако, тоже ничего не ломает, но пока давайте с основами разберемся). Вот смотрите. У вас на схеме есть оператор, скажем, P4.2.1. У него есть префикс A.B.C.0/24, например, и автономная система AS X. В RPKI он фиксирует, что в BGP-анонсе префикса A.B.C.0/24 AS PATH должен начинаться с X. Всё. Больше ничего. Как дальше этот анонс пойдет, через Tier-1, или через прямой стык с, например, P4.2.2.1, или через IXP, или ещё как — никак не контролируется вообще. Можно как угодно спрямлять пути хождения трафика, ничего не поломается до тех пор, пока префикс A.B.C.0/24 анонсируется из AS X (и, значит, трафик пойдет навстречу анонсам, то есть, к P4.2.1, а не куда-либо ещё). Вот если этот префикс анонсирует P2.2 из своей автономной системы, вот эти анонсы RPKI позволит отбросить, то есть у P2.2 не получится прикинуться P4.2.1, и украсть его трафик.
В-третьих, откуда вы взяли что «глобальные игроки получают корневые сертификаты даже не одного региона»?! Это какая-то невероятная ерунда. Цепочка доверия идет по иерархии распределения адресов, LIR-RIR-IANA, я это писал уже. Ни у каких операторов корневых сертификатов нет, и всё, что могут сделать глобальные игроки — это привязать свои собственные префиксы к своим собственным автономным системам. В этом смысле это действие ничем не отличается от такой привязки для самого маленького оператора. Повлиять на любою чужую привязку в RKPI никакой, даже самый большой, оператор не может никак. И никаких корневых сертификатов у глобальных операторов нет и быть тоже не может, откуда вы это взяли вообще?!
Про корневые это я оговорился. Имелись в виду сертификаты самого верхнего уровня, привязанные к реальным диапазонам. Но сути это не меняет. Большая часть верхнеуровневых диапазонов, я подозреваю, в собственности крупнейших провайдеров. И тут дело десятое, кем они были выданы — одним ЛИРом или десятью с пяти континентов. Главное, что приоритетное право подписывать огромные пространства сети имеют небольшое число магистральщиков.
И если у одного телекома-ТНК 20% адресов интернета и монопольное право выдавать подписи своим приватным ключом на различные куски этого пространства, то на мой взгляд, очевидно, что "никакой, даже самый большой, оператор не может никак" — не совсем верно.
Спасибо за разъяснение по поводу цели подписи. Получается, что подписывается только голова (последний, или первый слева элемент) AS-PATH. Это действительно тогда защищает от анонса от чужого имени, не ломая маршруты. Но это решает лишь часть проблем с мошенничеством — а именно ддос атаки.
Атаки типа перехвата трафика, прослушки и чёрной дыры всё равно возможны, так как все остальные элементы AS-PATH, его хвост, по-прежнему могут быть произвольными. И если эндпойнт способен принять этот трафик, то он может сделать такой анонс. В крайнем случае, если сам не переварит, завалит трафиком партнёров. Если ещё при этом по-хитрому распределить среди них нагрузку, то и черная дыра остаётся актуальной.
Но тут, видимо нет универсального решения. Либо ограничение трафика, либо безопасность.
"Главное, что приоритетное право подписывать огромные пространства сети имеют небольшое число магистральщиков" — да откуда вы взяли эту чушь? Нет никакого приоритетного права у магистральщиков. Каждый оператор живет на своих адресах, и подписывает их независимо ни от кого, повторяю это в который раз. Адреса все операторы получают у RIRа, делают это независимо, и давить друг друга в этом смысле не могут, какого б размера они ни были. В цепочке доверия мелкого оператора тоже нет никакого магистральщика, есть только он и RIR.
"И если у одного телекома-ТНК 20% адресов интернета и монопольное право выдавать подписи своим приватным ключом на различные куски этого пространства" — ни у одного участника Интернета нет 20% адресов, но даже если бы они были, это адреса только его и End Users под ним. Что бы он там не наподписывал, это окажет влияние только на него одного, у других операторов независимые блоки адресов.
Более того. Если бы схема была такой, как у вас в голове, крупный оператор точно так же мог бы командовать своими даунлинками и без всякого RPKI, и выворачивать им руки. И вот ровно поэтому схема не такая, как вы себе придумали, а такая, как я описал выше.
Надеюсь, теперь стало понятно, почему "повлиять на любою чужую привязку в RKPI никакой, даже самый большой, оператор не может никак" — таки верно.
"Но это решает лишь часть проблем с мошенничеством — а именно ддос атаки. Атаки типа перехвата трафика, прослушки и чёрной дыры всё равно возможны, так как все остальные элементы AS-PATH, его хвост, по-прежнему могут быть произвольными" — это почти полностью верно. Совершенно верно, что оно защищает только от части проблем, сейчас RPKI содержит только ROA (Route Origin Authorization — защиту первой AS). Вмешательством в середину AS PATH всё равно можно нагадить (в том числе и организовать DDoS). Почему RPKI важен даже в таком варианте?
Во-первых, дело в том, что подавляющее число проблем сейчас не порождаются злоумышленниками, а являются следствием человеческих ошибок:
— опечаток в префиксе («синдром толстых пальцев»),
— ошибками в настройке логике работы оборудования.
Qrator Labs в каждый момент времени видит проблемы маршрутизации примерно 6000 префиксов (понятное дело, что ситуация динамическая, одни префиксы приходят, другие уходят, но общее число всегда примерно такое). Другими словами, злоумышленникам достаточно часто очень легко замаскировать свои действия, при таком-то число «мусора». То есть, первая задача — сделать роутинговые инциденты чем-то относительно редким, чтобы оставшиеся уже можно было анализировать детальнее.
Во-вторых, сейчас в статусе draft есть следующий механизм RPKI: ASPA (AS PATH Authorization), который позволяет держателям AS описывать, с кем у них есть связи. Каждую пару AS в AS PATH можно будет проверить на валидность, и подтвердить, что AS PATH тоже не подделан. Это ещё не окончательная панацея, но делает общую ситуацию с безопасностью в BGP уже относительно приемлемой. Понятное дело, что так как каждый оператор сам описывает свои связи, и описывает он только свои связи, не влияя на валидность чужих, то пирингу и тут ничего не угрожает.
Развертывание сейчас RPKI только с ROA позволит операторам намного беспроблемнее в будущем добавить ASPA, так как сама технология будет обкатана и уже понятна в части эксплуатации и свойств.
Хорошо, теперь всё встало на свои места. Реальное устройство, если вам верить, более плоское и простое, чем я себе представлял. В принципе, простота иногда выливается в надёжность.
Если все операторы получают адреса на одном уровне (что по-моему всё-таки не всегда верно), то иерархия существует только в структуре реестров, т.е. сугубо бюрократически обслуживается. Тогда да, действительно, нет прямой связи между диапазонами адресов и физическими подключениями.
Кроме варианта получения статуса LIR у небольшого оператора ещё есть вариант работы с использованием блока адресов в статусе PI (Provider Independent). Теоретически так нельзя, но по факту пока что наказание за это отсутствует. Например, так живут очень многие мелкие украинские провайдеры. Но, по большому счёту, это ничего не меняет: держатель блока PI сам свой блок анонсирует и сам же его подписывает. В этом смысле RPKI тоже ничего не ухудшает.
Для интереса можете посмотреть список LIR, действующих в постсоветских странах, например:
Активное внедрение стандарта Интернета RPKI — полезно ли?