Исключениями являются либо страны, где всё регулируется (скажем, Беларусь) — ну там и с IX, мягко говоря, не очень, или сверхмелкие хитрые «провайдеры», которые покупают трафик как физлица, а потом продают по соседям — но их ни на каких IX и нет. И понятно, что последний случай крайне маргинален. Так что то, что я написал выше, работает в подавляющем числе случаев случаев.
Кроме варианта получения статуса LIR у небольшого оператора ещё есть вариант работы с использованием блока адресов в статусе PI (Provider Independent). Теоретически так нельзя, но по факту пока что наказание за это отсутствует. Например, так живут очень многие мелкие украинские провайдеры. Но, по большому счёту, это ничего не меняет: держатель блока PI сам свой блок анонсирует и сам же его подписывает. В этом смысле RPKI тоже ничего не ухудшает.
Для интереса можете посмотреть список LIR, действующих в постсоветских странах, например:
"Про корневые это я оговорился. Имелись в виду сертификаты самого верхнего уровня, привязанные к реальным диапазонам. Но сути это не меняет. Большая часть верхнеуровневых диапазонов, я подозреваю, в собственности крупнейших провайдеров" — это по-прежнему ерунда. Вы продолжаете путать цепочку связности и цепочку распределения адресов. Адреса распределяются по цепочке IANA-RIR-LIR-End User (в некоторых регионах есть ещё NIR, но сути это не меняет никак). При этом блоки адресов на уровне IANA, RIRов и NIRов не анонсируются в Интернете. А LIR — это, собственно, обычный участник сети Интернет. Произвольный. Какой-то мелкий оператор из Тамбова — это точно такой же LIR, как и оператор Tier-1 вроде Telia и DTAG, адреса у этого мелкого оператора точно так же от RIPE NCC, а не от другого оператора. В РФ сейчас около 2000 LIRов (а всего в регионе RIPE — больше 20000), например, и все они получили адреса у RIRа (RIPE NCC). Если хотите, вы, как физлицо, можете в течение нескольких дней оформить самостоятельное членство в RIPE NCC, то есть стать LIRом, и получить свой блок /24 (столько сейчас получает новый LIR).
"Главное, что приоритетное право подписывать огромные пространства сети имеют небольшое число магистральщиков" — да откуда вы взяли эту чушь? Нет никакого приоритетного права у магистральщиков. Каждый оператор живет на своих адресах, и подписывает их независимо ни от кого, повторяю это в который раз. Адреса все операторы получают у 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, так как сама технология будет обкатана и уже понятна в части эксплуатации и свойств.
Во-первых, у вас на схеме принципиальная путаница: часть стрелок соответствует отношению «делегирование адресов», часть — отношению «наличие сетевой связности». Это совершенно разные отношения. Поэтому на схеме видим смесь мягкого с теплым, что делает её полностью бессмысленной. Уж простите.
Во-вторых, поймите одну простую мысль: в 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 никакой, даже самый большой, оператор не может никак. И никаких корневых сертификатов у глобальных операторов нет и быть тоже не может, откуда вы это взяли вообще?!
Простите, но первый абзац — это ядерная чушь.
Во-первых, 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, существует не первое десятилетие.
Если честно, то совершенно не понял, от кого и кому что перетекает :) Система Tier-N в Интернете никак вообще не связана с RPKI, например.
Утверждение «По принятому протоколу доверие маршрутам обеспечивается только согласно иерархическим лицензиям, выданным от основных их владельцев — крупнейших телекомов бэкбона Интернета» — это вот просто ерунда, простите. Доверие в 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.
Слушайте, RTT до 8.8.8.8 и «пинг» до него же — синонимы. Ну вот так жизнь устроена. То, что в данном случае 8.8.8.8 означает ту ноду Google DNS, которая «ближе» всего — этот факт ни на йоту не меняет. Это по прежнему round trip time до этой ноды, где бы географически она ни находилась. И никакой ереси, это вы придумали зачем-то :)
Ещё раз, внимательно. Ping и RTT — это просто одно и то же. Идентичные вещи. Конечно, чтобы была цифра, нужно понимать точку назначения. И без неё обсуждать что-то странно. С этим я не спорил нигде. Вообще непонятно, зачем вы мне про руководство Старлинка пишите — я его не обсуждал и не защищал, прочитайле мои комментарии.
Мой тезис простой: ваше утверждение «то что кличут пингом в интернете — это непонятная ересь. Для человека гораздо больше скажет термин RTT» является тотально некорректным, потому что пингом в интернете «кличут» не непонятную ересь, а этот самый RTT. Соответственно, и области определения у них идентичны: если имеет смысл «пинг», то имеетт смысл и RTT. А если «пинг» смысла не имеет, то и RTT тоже. Потому что это одно и то же.
1 — я послал ping на адрес 8.8.8.8, это же очевидно из команды (точнее, на ближайший в терминах BGP инстанс 8.8.8.8, ибо это эникаст)
2 — лучше это спросить у автора твита, разве нет? :) В любом случае, там и слова ping нет, там есть термин latency, так что при чем этот твит к моему замечанию, непонятно.
На всякий случай повторю мысль: ping и RTT — это синонимы, только ping — слово жаргонное, но жаргонность сути не меняет.
По сути верно, но справедливости ради: ping, как и RTT, всегда имеет точку назначения, и результатом его работы является именно этот самый RTT, о чем написано в его выводе, в последней строке:
% ping -c 1 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=116 time=32.544 ms
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 32.544/32.544/32.544/0.000 ms
Так что это не непонятная ересь, а просто жаргонный синоним RTT.
Я про второй вариант, описанный дальше: «Альтернатива данному варианту — это обработка информации на борту спутника. То есть полученный от абонентского терминала радиосигнал демодулируется и декодируется до уровня IP-пакетов, направляется в маршрутизатор, который уже распределяет информацию в радиочастотный или оптический канал связи.
Данный метод позволяет гибко использовать весь доступный частотный диапазон и не требует специальных абонентских терминалов, но требует наличия на борту маршрутизатора, способного обработать пакеты на скорости до 20 Гбит/с»
Мысль в том, что в этом случае маршрутизатор, скорее всего, тоже не нужен, достаточно заметно более простого устройства. Для которого 20Gbps по нынешним временам — задача тривиальная.
«То есть полученный от абонентского терминала радиосигнал демодулируется и декодируется до уровня IP-пакетов, направляется в маршрутизатор, который уже распределяет информацию в радиочастотный или оптический канал связи.»
Не обязательно. Нам не надо, по совести, работать с BGP Full View на орбите, нам нужно приземлить трафик на нужную станцию, которых относительно немного, и которые в космосе являются, собственно точками назначения. Другими словами, тут правильнее делать маршрутизацию не по IP-префиксам в произвольной архитектуре сети, а по максимуму использовать то, что мы знаем про способ построения этой самой нашей сети. Насколько я понимаю, пакет может перекидываться от спутника ко вполне определенным группам других спутников, и никуда больше. То есть, задача — построить путь по этим самым группам, а потом опустить пакет вниз.
Думается, что тут можно задействовать упрощенную инкапсуляцию поверх IP, или просто заведение метки (или несколько меток) — как в MPLS — ещё на Земле. На спутнике тогда задача становится весьма простой: форварднуть пакет в соответствии с этими самыми метками или их аналогом, которые могут (и должны) быть устроены проще, чем IP-адреса. Чтобы не сигналить правила форвардинга, но при этом сохранить гибкость, можно использовать что-то типа MPLS Segment Routing (который и сам тут выглядит весьма к месту), с необходимым просчетом на Земле.
В сумме на спутниках, если делать по уму, получается весьма дешевая с вычислительной точки зрения архитектура.
Справедливое замечание. Потеря скорости появляется вместе с появлением какого-либо управления потоком. Если, скажем, фигачить по UDP (который, как и IP, работает по принципу fire&forget) на максимальной скорости — оно так и будет лететь, никакого уменьшения скорости из-за RTT не случится. Но если там поверх работает приложение, которое как-то контролирует передачу — тут может уже быть по-разному.
А вообще, работа протоколов в сетях-слонах (от elephant, что, в свою очередь, от LFN, что является аббревиатурой от Long Fat Network — длинная сеть с высокой пропускной способностью) активно исследуется последние 20 лет с разных сторон, и наработок там много. Так что не всё так плохо, конечно :)
Но интернет, особенно в 1985 году — это, в первую очередь, всё же принцип организации сетей связи. То есть, не отрицая интересности материала и самого по себе, и с точки зрения истории вычислительных систем, должен отметить, что ответом на вопрос в тексте «чем не интернет» является «ну… ничем не интернет». Что совершенно не обесценивает историю.
Собственно, в СССР были планы и построения неких сетей на всю страну, но изучение принципов, которые в них предполагалось заложить, показывает, что это были планы всесоюзного интранета, что немного другое. Хотя это всё равно огромные проекты, сложные и интересные, конечно.
Мое замечание относилось только лишь к фразе, что /etc/hosts не умеет в вайлдкард записи ) И, да, это работает только для исходящих соединений.
А что там за топология сети у автора и как он выходит в интернеты — я вообще без понятия. Почему-то этот вопрос не освещён в заметке
Ну, догадаться несложно :) Достаточно много автор написал :)
в остальном — никакого противоречия не вижу )
В таком варианте — да :)
Кстати, не факт. Соединение могло быть установлено изнутри, по крайней мере явных указаний на обратное в этой строчке я не увидел.
Ну да, конечно. Исходящее соединение на эфемерный порт, с портом источника 8843. И оттуда приходит в ответ SYN без ACK, ага. Не, теоретически сварганить можно, если обе стороны задействовать. Но на практике — очевидно, что это таки входящее.
Очевидно, что scanner-12.ch1.censys-scanner.com сам пришел по TCP на локальный узел. Отключение резолвинга только усложнит диагностику автору, но на саму TCP-сессию повлияет никак.
«Фабрика охлаждения» — это мокрые градирни? Ну так там не полный обратный термодинамический процесс, который в этом случае нафиг не нужен. Поэтому чтобы отвести 20МВт не требуется десятки МВт энергии, к счастью.
Ещё раз обращу внимание на PUE. Поглядите эту величину и для других датацентров. Ну, 1.6 я встречал в грустных случаях, это да. Но 2 — это уже ни в какие рамки, разве что если электричество бесплатное, а девать его некуда.
Хладагент используется, чтобы не просто охлаждать, а охлаждать контролируемо. С радиаторами можно легко переохладить оборудование, что тоже будет ему неполезно.
Кроме варианта получения статуса LIR у небольшого оператора ещё есть вариант работы с использованием блока адресов в статусе PI (Provider Independent). Теоретически так нельзя, но по факту пока что наказание за это отсутствует. Например, так живут очень многие мелкие украинские провайдеры. Но, по большому счёту, это ничего не меняет: держатель блока PI сам свой блок анонсирует и сам же его подписывает. В этом смысле RPKI тоже ничего не ухудшает.
Для интереса можете посмотреть список LIR, действующих в постсоветских странах, например:
"Главное, что приоритетное право подписывать огромные пространства сети имеют небольшое число магистральщиков" — да откуда вы взяли эту чушь? Нет никакого приоритетного права у магистральщиков. Каждый оператор живет на своих адресах, и подписывает их независимо ни от кого, повторяю это в который раз. Адреса все операторы получают у 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, так как сама технология будет обкатана и уже понятна в части эксплуатации и свойств.
Во-вторых, поймите одну простую мысль: в 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 никакой, даже самый большой, оператор не может никак. И никаких корневых сертификатов у глобальных операторов нет и быть тоже не может, откуда вы это взяли вообще?!
Во-первых, 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, существует не первое десятилетие.
1) крайне неудобно,
2) совершенно не нужно (описанных в статье проблем на самом деле просто не существует).
Утверждение «По принятому протоколу доверие маршрутам обеспечивается только согласно иерархическим лицензиям, выданным от основных их владельцев — крупнейших телекомов бэкбона Интернета» — это вот просто ерунда, простите. Доверие в 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.
Ещё раз, внимательно. Ping и RTT — это просто одно и то же. Идентичные вещи. Конечно, чтобы была цифра, нужно понимать точку назначения. И без неё обсуждать что-то странно. С этим я не спорил нигде. Вообще непонятно, зачем вы мне про руководство Старлинка пишите — я его не обсуждал и не защищал, прочитайле мои комментарии.
Мой тезис простой: ваше утверждение «то что кличут пингом в интернете — это непонятная ересь. Для человека гораздо больше скажет термин RTT» является тотально некорректным, потому что пингом в интернете «кличут» не непонятную ересь, а этот самый RTT. Соответственно, и области определения у них идентичны: если имеет смысл «пинг», то имеетт смысл и RTT. А если «пинг» смысла не имеет, то и RTT тоже. Потому что это одно и то же.
2 — лучше это спросить у автора твита, разве нет? :) В любом случае, там и слова ping нет, там есть термин latency, так что при чем этот твит к моему замечанию, непонятно.
На всякий случай повторю мысль: ping и RTT — это синонимы, только ping — слово жаргонное, но жаргонность сути не меняет.
% ping -c 1 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=116 time=32.544 ms
--- 8.8.8.8 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 32.544/32.544/32.544/0.000 ms
Так что это не непонятная ересь, а просто жаргонный синоним RTT.
Я про второй вариант, описанный дальше: «Альтернатива данному варианту — это обработка информации на борту спутника. То есть полученный от абонентского терминала радиосигнал демодулируется и декодируется до уровня IP-пакетов, направляется в маршрутизатор, который уже распределяет информацию в радиочастотный или оптический канал связи.
Данный метод позволяет гибко использовать весь доступный частотный диапазон и не требует специальных абонентских терминалов, но требует наличия на борту маршрутизатора, способного обработать пакеты на скорости до 20 Гбит/с»
Мысль в том, что в этом случае маршрутизатор, скорее всего, тоже не нужен, достаточно заметно более простого устройства. Для которого 20Gbps по нынешним временам — задача тривиальная.
Не обязательно. Нам не надо, по совести, работать с BGP Full View на орбите, нам нужно приземлить трафик на нужную станцию, которых относительно немного, и которые в космосе являются, собственно точками назначения. Другими словами, тут правильнее делать маршрутизацию не по IP-префиксам в произвольной архитектуре сети, а по максимуму использовать то, что мы знаем про способ построения этой самой нашей сети. Насколько я понимаю, пакет может перекидываться от спутника ко вполне определенным группам других спутников, и никуда больше. То есть, задача — построить путь по этим самым группам, а потом опустить пакет вниз.
Думается, что тут можно задействовать упрощенную инкапсуляцию поверх IP, или просто заведение метки (или несколько меток) — как в MPLS — ещё на Земле. На спутнике тогда задача становится весьма простой: форварднуть пакет в соответствии с этими самыми метками или их аналогом, которые могут (и должны) быть устроены проще, чем IP-адреса. Чтобы не сигналить правила форвардинга, но при этом сохранить гибкость, можно использовать что-то типа MPLS Segment Routing (который и сам тут выглядит весьма к месту), с необходимым просчетом на Земле.
В сумме на спутниках, если делать по уму, получается весьма дешевая с вычислительной точки зрения архитектура.
А вообще, работа протоколов в сетях-слонах (от elephant, что, в свою очередь, от LFN, что является аббревиатурой от Long Fat Network — длинная сеть с высокой пропускной способностью) активно исследуется последние 20 лет с разных сторон, и наработок там много. Так что не всё так плохо, конечно :)
Собственно, в СССР были планы и построения неких сетей на всю страну, но изучение принципов, которые в них предполагалось заложить, показывает, что это были планы всесоюзного интранета, что немного другое. Хотя это всё равно огромные проекты, сложные и интересные, конечно.
Ну, догадаться несложно :) Достаточно много автор написал :)
В таком варианте — да :)
Ну да, конечно. Исходящее соединение на эфемерный порт, с портом источника 8843. И оттуда приходит в ответ SYN без ACK, ага. Не, теоретически сварганить можно, если обе стороны задействовать. Но на практике — очевидно, что это таки входящее.
scanner-12.ch1.censys-scanner.com.62651 > 192.168.1.150.8843: Flags [S]
Очевидно, что scanner-12.ch1.censys-scanner.com сам пришел по TCP на локальный узел. Отключение резолвинга только усложнит диагностику автору, но на саму TCP-сессию повлияет никак.
В общем, читайте книжки, они рулез (С)
Ещё раз обращу внимание на PUE. Поглядите эту величину и для других датацентров. Ну, 1.6 я встречал в грустных случаях, это да. Но 2 — это уже ни в какие рамки, разве что если электричество бесплатное, а девать его некуда.