Здравствуй, Хабр! Это — одновременно транскрипция и частичный перевод часовой сессии под названием «Почему Интернет до сих пор онлайн?» с пятнадцатой встречи «Евразийской группы сетевых операторов». 

Qrator Labs благодарит всех участников обсуждения: Алексея Семеняку, RIPE NCC; Игнаса Багдонаса, Equinix; Мартина Дж. Леви, Cloudflare; Александра Азимова, Qrator Labs и модератора Алексея Учакина из команды подкаста LinkmeUp за разрешение опубликовать данный текст.

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

Алексей Учакин: Всем привет, меня зовут Алексей, команда LinkmeUp — первый подкаст для связистов. За меня, на самом деле, коллега из Qrator Labs очень много рассказал о том, как защищаться от спуфинга, но я хотел бы поговорить, на самом деле, более широко. Потому что интернет – это штука безусловно децентрализованная и создавалась, в том числе, для того, чтобы выжить после ядерного взрыва, но, как показывает практика, обладая дешевым оборудованием и не имея прав на настройку BGP, можно это все очень успешно поломать. Поэтому я хотел сегодня вместе с экспертами обсудить, как от этого защищаться, как это мониторить и что со всем этим делать.

Сегодня участвуют: Александр Азимов — Qrator Labs, Алекс Семеняка — RIPE NCC, Игнас Багдонас — Equinix и Мартин Дж. Леви — Cloudflare. Собственно, коллеги, первое, с чего хотелось бы начать, первый вопрос: насколько сейчас интернет защищен от того, что условно маленький региональный оператор начнет вдруг анонсировать префиксы условного Google, Яндекс или кого-либо. Есть ли какая-нибудь оценка того, как сейчас с этим дело обстоит?

Александр Азимов: Ну, давайте тогда я начну эту грустную историю, потому что она реально грустная. К сожалению, крупные операторы, в том числе в России, имеют исключения, т.е. они иногда настраивают фильтры, а иногда — нет. Я не хочу тыкать пальцем в весь крупный операторский рынок России, но значимая часть тех, кого мы считаем Тier-1 операторами, имеет такие исключения. В результате те, для кого эти исключения реализованы, имеют возможность проанонсировать все, что угодно, и такое уже было. Собственно, мы наблюдали, как в прошлом году протекала Корбина, как протекал Вымпелком. Есть те, кому гром еще не грянул, но потенциал есть.

Алексей Учакин: То есть сейчас все совсем плохо, да?

Алексей Семеняка: Так, давайте не нагнетать градус саспенса — это, наверное, немножечко лишнее. Ну, что значит плохо? Да, есть дырки. Саша совершенно справедливо сказал: кто-то фильтрует, кто-то не фильтрует, т.е. все на таком уровне. Все-таки здесь давайте начнем с того, что интернет строился на принципах, скажем так, взаимопонимания, и в достаточной степени он до сих пор на этих принципах существует. Предполагается, что это не только техническая конструкция, но это еще и какие-то компании, в которых работают какие-то люди, которые совершают какие-то осознанные действия. Когда в интернете появляется какая-то подобная вещь, все остальные как-то на все это дело реагируют, примерно так. Хотя, действительно, аварии случаются регулярно. Замечательная история о доверии — когда все доверяли Google, а он взял и оставил Японию… ну, короче, не очень с интернетом. История опять-таки прошлого года, но это прекрасный пример. Я бы предпочел говорить о технической стороне, а не о формулировках: все ли хорошо / все ли плохо. Ну, то есть это слишком как-то непрофессиональный подход.

Александр Азимов: Хорошо, ладно, продолжая этот непрофессиональный подход, я бы задал вопрос — может ли сеть коллективного доверия не стать сетью коллективных проблем, когда объектов стало 55 000. Говоря про технику, сейчас в рамках IETF при посильном участии Qrator Labs, в том числе, но и не только, тема BGP security активно двигается. Есть надежда, что ситуация станет лучше именно с технической точки зрения, что даст залатать значимую часть дыр в протоколе BGP и сделать его более безопасным, прежде всего для новичков. Чтобы они имели меньше возможности убить себя и окружающих.

Алексей Учакин: Выдавать права на настройку BGP все же нужно?

Алексей Семеняка: Я думаю, что Игнасу есть, что сказать.
 

Игнас Багдонас: У меня бы, я бы сказал, что есть 2 разные части проблемы или 2 группы проблем. 

Одна – это те самые лики и прочие дела, которые появляются в результате ошибки, неумышленной ошибки. Жирные, толстые пальцы — что-то подобное. С одной стороны мы движемся в сторону автоматизирования и это как бы, можно сказать, что это будет решение, но все системы автоматизирования работают на данных. Если наши данные испорчены или некорректны, это будет то же самое, только намного эффективнее. 

Другая группа – это специфические умышленные атаки, и с моей точки зрения большинство этих атак осуществляется, и они являются успешными, только из-за того, что во всей сети есть довольно большой уровень, скажем прямо — бардака. Это операционная гигиена, которая дает результат только, когда все участники, или большинство участников в этом участвуют и делают это более или менее корректно. Это вопрос образования. Вы здесь, в этой комнате, вы знаете, что такое фильтрование, знаете, как это работает, но вы ведь представляете малую часть тех людей, которые занимаются технической работой и поддержкой, и нельзя из этого делать вывод, что у всех уровень понимания такой же. Конечно, есть такие ситуации, где кто-то прочитал в документации у какого-то вендора, что вот набейте команду и будет вам счастье. Они это делают и получают счастье, только в процессе этого, они делают урон другим, не нарочно и не понимая это. Вопрос обучения — он действительно важен в этой ситуации. Я вижу, что это двигается в хорошую сторону, но это не быстрый процесс.

Алексей Семеняка: Небольшое замечание по поводу образования — образование действительно совершенно критическая вещь здесь и ровно так же, как в части тех проблем, которые мы обсуждали после Сашиного доклада, только что. Есть такой наглядный пример, который касается нашей организации RIPE NCC, мы ведем, как вы понимаете и хорошо знаете, базу данных RIPE DB. У нас там есть раутинговые объекты, я хорошо помню время, это было недавно – 20 лет назад – когда правилом хорошего тона было строить фильтры по RIPE DB. Сейчас это категорически не так — есть организации, которые на свой страх и риск это делают, но достаточно многие жалуются на то, что если просто верить тому, что написано в RIPE DB, то получается отстреливание ноги себе. Мы только ведем, мы технические операторы RIPE DB, мы не можем заставить писать вас правду, т.е. нету прав, это вы нам не дали таких прав, вы нам не сказали: «пожалуйста, следите, чтобы там было написано что-то корректное». И вы, собственно, уважаемые участники, туда пишете всякую чушь регулярно. Да, это проблема масштабирования и проблема образования, наложенные друг на друга. Не потому, что вы глупые или не потому, что у вас не хватает образования в части протокола BGP. Нет, это просто, действительно, бардак. У вас не доходят руки до этого, у вас нет времени с этим разобраться, вы не понимаете, зачем это нужно, и образовывать сильно растущее число участников, это действительно очень большой вызов, который, на самом деле, эффективно на нынешний момент, на мой взгляд, не решается. Это действительно проблема образования, но не в том смысле проблема образования, что кто-то мог сделать и не сделать, это действительно не понятно, как делать в контексте растущего интернета, растущего числа участников и т.д. и т.д. Это более или менее системная проблема. Мартин?

Мартин Леви: Вы немного сбили меня с изначальной темы — я сначала вернусь назад. У меня уже седые волосы, видите? Это потому что я занимаюсь сетями уже очень долго. И в качестве основы всего интернета у нас есть протоколы, которые были созданы задолго до того как он приобрёл свои современные масштабы. Кто из присутствующих знает, кто первым стал предлагать подключение к интернету в России? Неважно кто это был, важно сколько людей это знает и важно, что вы знаете. И если вам нужно было поднять телефон и позвонить куда-то — вы знали, кому звонить. А кто из присутствующих управляет ASN и не знает меня или не знает других людей, поднявших руки? Протокол просто не поспевает за таким темпом роста. И все, о чем мы говорили и на предыдущих ENOG’ах, и 10 минут назад или на других конференциях — об одном. О том, как же догнать темп роста. Потому что одна из наиболее удивительных вещей, касающаяся интернета и протоколов — это то, что они выходят из процесса происходящего не на 100%, но в основном внутри IETF.

Существует такая фраза, как «permissionless innovation» (инновации без разрешения) — существующие протоколы «не спрашивали разрешения» у операторов связи или интернет-провайдеров. Созданы они были тем типом людей, что находится сегодня здесь — и эти вещи работают. Многое из того, что вы здесь говорили — о том как догнать прогресс, или чего не хватает, или на чем нам всем необходимо согласиться. Вещи философского порядка, а я бы хотел оставаться приземленным. И в этот момент я вынужден сказать, что вы неправы. Я объясню: единственный способ, которым работает современный интернет — это поддержка этих баз данных маршрутов, которые мы лениво, я повторю еще раз — лениво используем для того, чтобы кто-то не мог помешать нормальной связности другого. Сегодня во время обеда мы обсуждали: я владелец сети, которой кто-то пытался манипулировать не далее, чем 5 дней назад. И хотя раут лик и продолжался всего 30 или 40 секунд — в твиттере и остальных социальных сетях он продолжался в течение нескольких дней. Так что я испытываю самый настоящий ангажированный интерес в том, чтобы убедить вас и всех остальных, присутствующих, в том, что это очень важная тема. Так дайте я объясню, где по моему мнению вы были неправы и почему я так среагировал. Кто-то в определенный момент должен быть ответственен за то, чтобы быть владельцем именно таких данных, которые позволят утверждать о легитимном или нелегитимном анонсе. Потому что конкретно в этом окружении «без разрешения» не очень работает. И так как вы являетесь RIR-участником данного обсуждения, я откатываюсь назад к вам и спрашиваю: «Вам сложно поддерживать IRR в чистом и корректном состоянии?» Всем сложно. Кто-то должен встать и сказать: «Хватит. Я найду способы починить это и сделать лучше». Вторая часть моего ответа заключается в том, что кому-то из присутствующих придется начать этот процесс и сейчас я выберу вас, как RIR’а, для этой задачи. Давайте посмотрим, куда дальше пойдет данное обсуждение.
 

Алексей Семеняка: Во-первых, я не могу согласиться с несогласием потому, что это никоим образом не противоречит тому, что я говорил. Я не говорил, что наши данные – абсолютная чушь, я говорил про то, что достаточно много случаев, когда там написана чушь. К счастью, далеко не всегда. Раутинговая часть базы данных — достаточно важная часть, все-таки как-то она работает. Особенно там, где есть enforcement — особенно прекрасно работает поддержание актуальности этих данных, особенно прекрасно, если речь идет об ответственном операторе, который работает со своими даунлинками. Или практически всегда это работает — эти записи, актуальные для точек обмена трафика, потому что точки обмена трафика очень внимательно следят за тем, что написано в их базе данных. Скажем так, в массе своей. Бардак там есть — бардак, к сожалению, не точечный, он более или менее распределен, но, к счастью, это проблема, а не катастрофа. Мартин, я прошу прощения, скажем так, это украденное продолжение разговора. Я абсолютно согласен, что надо бы заняться этим делом. Вот Саша как раз хочет забрать у меня микрофон и сказать, что он именно тот человек, который этим займется, я правильно понял? Но я все-таки договорю. Другой Саша из зала подсказывает, что есть еще кое-кто. Все верно, но в интернет сообществе, как мы понимаем давление со стороны RIR не работает. Если RIR начинает просто давить на участников и говорить: «Так, а ну-ка быстро все построились и пошли строем» — ничего не произойдет. Работает обсуждение, работает кристаллизация проблемы, работает создание, собственно говоря, осознания. Это та же самая часть образования, в каком-то смысле, и когда она пройдена, появляются те самые люди, с которыми можно работать и которым мы, как RIR, будем всячески содействовать. У нас действительно есть система, которая позволяет следить за тем, как чего происходит — и мы готовы продвигать эту проблему, но мы не можем заменить сообщество. Мы можем работать с сообществом — это мы можем, будем и готовы, но мы не можем заменить сообщество — мы не можем создать тех, кто будет это делать.

Александр Азимов: Давайте чуть-чуть вернемся назад — нужно же найти все-таки корень зла, и попробуем доказать, что это RIR. Обычно, когда вы добавляете номер автономной системы в свой SET, если вы транзит, вы это делаете с какой целью? Для того, чтобы оказывать им сервис. Не для того, чтобы их защитить завтра или чтобы у них все хорошо работало, а чтобы вышестоящие тоже добавили их префикс в SET, и чтобы дальше все работало. А как часто вы удаляете из своего SET то, что туда было добавлено ранее? Поднимите, пожалуйста, руку те, кто этого не делает, или делает редко? (поднимает руку) Я буду здесь честен. (вопрос из зала: «Совсем редко?») Да, от случая к случаю. По сути, возлагая на AS-SET’ы защиту от ликов, хайджеков, мы все перепутали, на самом деле. Этот механизм разрабатывался для другой цели. Они связаны, но юзкейс у него другой. В данном случае, по сути происходит делегирование безопасности, поскольку ваш номер вообще может добавить кто-угодно, другим игрокам. И структурно исправить протокол BGP можно собственно только если, отвечая на то, что говорил Мартин, это только в том случае, если ваша безопасность будет зависеть только от ваших действий. И больше ни от кого. Собственно, на мой взгляд, именно в эту сторону должен развиваться протокол и его изменение.

Мартин Леви: Протокол – он зависит только от данных. Если помойка внутри, то помойка и снаружи. Дрянь внутрь, дрянь наружу, это все.
 

Александр Азимов: Я запутался. Проблема в том, что мусор всегда можно создать, но я хочу жить в ситуации, когда мусор для своих сетей могу создать только я сам. Я буду ответственен за создание мусора. Ситуация, когда мусор для моей сети создают другие игроки – она тупиковая. И, обратно, я хочу быть ответственен за безопасность моей сети.

Мартин Леви: Я согласен с этим, понимаю, хорошо. Давайте тогда попробуем что-то новое и с другой стороны подойдем к этому вопросу. Куда я могу послать счет или запрос на предоплату, когда что-то приходит в мою сеть? А оно туда приходит — то, чего я не просил, то, что прошло через многих игроков и не имеет для меня никакой ценности. Я могу сам послать очень много запросов на оплату, как я обработаю весь этот объем? Это в какой-то степени риторический вопрос, потому что мы знаем, что это не может существовать. Но в то же время, это отличный аргумент против этого. Мы все в одной лодке сейчас именно из-за ограниченного количества и качества фильтров. И это достаточно большое количество трафика, который мог бы и не существовать. Мы можем также можем обсуждать это не с точки зрения данных, но и управления (имеется в виду data plane/control plane) или с точки зрения качества BGP маршрутизации и поговорить о чрезмерной деагрегации — но это другой разговор.

Алексей Учакин: Хорошо, это другой вопрос. Но у нас есть RIPE DB, у нас есть база данных других LIR’ов и мы даем честное пионерское, что мы будем себя хорошо вести и будем писать туда правильные данные. А как защищаться от спуфинга — от того, что мы можем заанонсить чужой номер автономки и с теми же адресами, валидными для этой автономки, но для каких-то своих целей. Может ли нам в этом как-то помочь BGPSec c RPKI или что-то такое?

Александр Азимов: BGPSec нам помочь ничем не может, извините.

Алексей Учакин: То есть будет, как с DNSSec, что идея хорошая, но никто не применяет?

Алексей Семеняка: Я думаю, что про BGPSec мы должны спрашивать у представителя будущего, то есть у Игнаса. Вот, кто у нас отвечает за будущее, мы то про настоящее. BGPSec’а сейчас нет в планах по поддержке ни у одного вендора. Я не говорю про железо — пока что ни один вендор в roadmap не добавил. Мы, люди, которые более или менее к настоящему имеют отношение BGPSec, наверное, затруднимся обсуждать. В идеальном мире, представим себе, что у нас есть RPKI, есть абсолютно точная база данных, и все валидируют всё — все проверяют RPKI, и все проверяют соответствие того, что приходит тому, что они видят в базе данных. Тогда все будет работать. Я сомневаюсь, что это был вопрос — но согласен, что в идеальном мире все будет работать.

Алексей Учакин: А если не в идеальном?

Алексей Семеняка: А если в реальности, то не будет.

Алексей Учакин: А зачем тогда вообще RPKI?

Игнас Багдонас: Я, как смотрящий на будущее, отвечу коротко: «Будущее будет светлое». Но до тех пор пока этот момент не наступит будет много темноты, бардака и прочих других дел. BGPSec и прочие связанные с ним дела? Совсем ничего плохого, говоря об академической общественности, BGPSec, по большей части – это академический эксперимент. Да, он выглядит как бы полно, теоретически может работать и теоретически может решать те проблемы, которые на него накладывались, но если мы смотрим с практической стороны, то все выглядит немного иначе. Очень простой аспект: если, допустим, были сделаны тесты производительности, простого performance, как быстро работает валидирование. Если я могу валидировать 50 префикс-апдейтов в секунду, я получаю full feed. У меня займет намного больше времени, пока я завалидирую все, и за это время половина всего уже поменяется несколько раз. Да, это почти идеальный все разрешающий механизм. Нужен ли он нам? Наверное. С другой стороны, если бы у нас был механизм, который бы решал хотя бы 80% всего, ну хорошо, 85%, ну хоть 85,5% проблем тех, которые у нас есть практических, но не работал в некоторых сложных и исключительных случаях. Я думаю, что такой механизм и подход был бы намного более практичным, и вендоры это все бы реализовали и это все бы использовалось. Если говорить со стороны вендоров, то у них ответ очень простым: «А вы готовы платить столько, сколько это будет стоить, когда мы это сделаем, как продукт?» И ответ из тех же самых операторов очень неочевиден. Я слышал, кто-то сказал «да» в зале, но многие говорят «конечно нет». «Даже и не думайте об этом — это ваша проблема, вы и реализуйте это, мы будем покупать вашу платформу, а то, что она делает — зачем же нам платить что-то? Мы просто думаем, что это это должно быть и все». Получается замкнутый круг. Да, у нас есть все протоколы, вся механика и прочие другие дела. У нас есть базы данных — в них мусор. Если мы все это складываем, то решение оно как бы и есть, но оно не может работать чисто технически, когда все компоненты связаны вместе. И даже если это может работать, с теми данными, которые есть в системе, опять никакого позитивного результата не будет. Это вот такой цикл и не очень очевидно, как из этого выйти. Да, IETF и другие организации больше десятилетия работали над BGPSec и получается так, что много людей отдали много времени и сил, а получился какой-то полуфабрикат, если можно так сказать, который как бы работает, но его нельзя использовать. Что делать сейчас? Пробовать довести BGPSec до ума, практического ума или просто сказать, что да, это была ошибка/победа, зависит от вашей точки зрения, все это выбросить и сделать все заново.
 

Мартин Леви: Если брать в расчет 50 секунд, которые вы назвали, то получится порядка 4-5 часов для валидации полной таблицы, что просто неприемлемо, если вы оператор.

Игнас Багдонас: Да-да. Это данные, которые были получены на IETF — там проводились тесты производительности BGPSec на современном оборудовании.

Алексей Семеняка: Современном оборудовании! Был вопрос, который не получил ответа. Я коротко скажу. Абсолютно согласен с тем, что сказал Игнас про то, что если можно отфильтровать большое количество каких-то простых случаев – это очень полезно сделать. Искать серебряную пулю – это не метод в индустрии, так не работает. Работают практические подходы. История про RPKI – это ровно эта история. Это история отфильтровать случаи, которые вызваны синдромом толстых пальцев. Конечно, обойти защиту RPKI злоумышленнику не стоит, приблизительно, ничего. Но в подавляющем большинстве случаев и слева, и справа от меня сидят люди, которые это меряют, которые знают цифры. Я сейчас передам Саше Азимову микрофон, Мартин, я думаю, тоже прокомментирует это. Количество тех инцидентов, которое мы видим в протоколе BGP и которое вызвано синдромом «толстых пальцев» — оно огромно. Если возможно его уменьшить, то это нужно делать. Собственно говоря, именно такой подход лежал в основе RPKI — это не серебряная пуля и не попытка защитить целостность от злоумышленника, т.е. человека, который пытается что-то специально сделать. Но, в любом случае, если у вас для поиска чего-то, какой-то улики, нужно разгрести целый мусорный контейнер или небольшую коробочку, то второй случай намного проще. Это, в том числе, может помочь и в выявлении тех случаев, когда что-то делается умышленно, если, все-таки, количество неумышленных случаев у нас будет уменьшаться, потому что в нынешней куче их очень сложно увидеть. Атрибуция каких-то раутинговых атак началась совсем недавно. Я уверен, что они были раньше, но каких-то доказанных случаев атрибуции, они достаточно новые. Когда было понятно, что да, это была раутинговая атака, которая была проведена действительно злоумышленниками и они получили то-то и то-то. За последние годы таких случаев уже n-ое количество, а раньше это было только на уровне подозрений, по большей части.

Александр Азимов: Я сейчас продолжу то, что говорил Алексей и Мартин. В последнее время меня стали обвинять, что у меня очень депрессивный взгляд на BGP. Отчасти, наверное, это правда. Однако, в этом году произошло событие, которое, на мой взгляд, для индустрии будет весьма и весьма значимым. На протяжение многих лет шли попытки запустить ROA validation, то, что мы называем RPKI, массово. Почему это важно? Потому что это не может решить проблему ликов, не может решить проблему malicious activity — это решает всего лишь проблему accidental hijacks. Это решает проблему той самой утечки статики, что происходит постоянно. То, что было в России не так давно, то, что сейчас зацепило Cloudflare с их DNS service, к счастью, ненадолго. А это способ борьбы. И хорошая новость не в том, что сам RPKI выпустился уже достаточно давно. Проблема не только в том, что возникает аномалия, а в том, что она распространяется. Если аномалия распространяться не будет, уровень беды снизится драматически. И, собственно, наконец хорошая новость – крупные европейские IX’ы, такие как MSK-IX, включая DEC-IX, включая AMS-IX в ближайшее время собираются начать дропать инвалидные маршруты, согласно ROA. Что это значит? Это значит, что если вы подпишете свое адресное пространство, то есть подумаете о собственной безопасности, вы увеличите шансы, что в следующий раз, когда где-то произойдет аномалия, она не утащит весь или значимый процент вашего трафика, а возможно будет локализована. Поэтому я настоятельно рекомендую вам подписать свое адресное пространство — это не сложно. Сегодня с Алексеем Семенякой после этой секции мы будем делать work shop и постараемся помочь тем, у кого возникают технические вопросы, как это сделать. Да, мы здесь будем работать исключительно для региона RIPE. На самом деле, RIPE проделал шикарную работу и сделать это очень-очень просто, у меня это заняло 10 минут. Думаю, что вы справитесь быстрее.

Алексей Семеняка: В любом случае, workshop для тех, кто может зайти в LIR-портал. Если у вас нет доступа в ваш LIR-портал — сожалею. Вы тоже можете прийти, но тогда вам придется только понаблюдать из-за плеча, к сожалению. Для тех, у кого есть доступ в LIR-портал — это возможность сделать это прямо сегодня, сейчас, здесь.
 

Мартин Леви: Мне не остается ничего, кроме как поддержать — это правильное направление. Обновление для вас — AMS-IX теперь на 100% фильтрует анонсы по данным RPKI, две недели как. Об этом также должны узнать все IX-операторы, те кто поддерживает базу маршрутов в своей IX. Можно сделать это по примеру AMS-IX — сначала софтово собрать и проанализировать данные, а после уже воплотить фильтрацию в железе на данных RPKI и RIR.

Александр Азимов: Это просто замечательная новость! Одно дело говорить, что они только будут, а другое, когда это уже началось. Здесь еще существенный момент, что вместе с началом активного использования, появляется опыт операционного использования ROA validation. Соответственно вслед за IX’ами, после того, как будут совершены первые ошибки, начнут подтягиваться транзиты — очень хочется в это верить.

Мартин Леви: И это ключевой пункт. Вы пригласили людей на обучение и сказали, что это легко. Давайте я покажу и другую сторону. Для каждой сети в этом регионе, которая использует транзитных провайдеров, которые каким-то способом имеют пиринг в других городах в Европе, таких как Амстердам, Франкфурт или Лондон… я буду говорить сейчас об Амстердаме, потому что считаю, что любая крупная сеть соединяется с Амстердамом в какой-то точке. Если такая сеть не имеет валидной IRR-записи или, что может быть еще важнее — RPKI-записи, то маршрут не пройдёт через route-сервер. Именно поэтому вы не получите оптимальный путь трафика. Сегодня вы можете пойти через Франкфурт, но это скоро изменится. Кто-то здесь в аудитории может, наверное, сказать «когда». Может быть трафик пойдет через Лондон, Варшаву — это уже тренд. Даже если у нас появляется только одна дополнительная точка, мы можем уже сказать, что это тренд. И, таким образом, получить точные данные по маршрутам в интересах такой сети гораздо больше сейчас, чем это было 2 недели назад. Надеюсь, что в будущем это продолжится, однако мотивация сказать: «Эй, это просто, приходите и мы покажем» – это одно. На мой взгляд, будет лучше если вы скажете: «Если вы не придете на мастер-класс, ваша сеть не будет работать достаточно эффективно».

Александр Азимов: И вообще, всегда хорошо, когда у нас есть мотивация. Боюсь, Мартин эту шутку не поймет, но когда у нас морковка и спереди, и сзади. В нашем регионе это работает особенно хорошо.

Алексей Учакин: Хорошо, тогда такой вопрос: я правильно понимаю, что в основном тот же RPKI и ROA validation и все прочее – это уже такая неотвратимая штука? BGP-протокол, он же изначально trust-based и, изначально, он так быстро вырос, собственно, в том числе потому, что протокол основан на доверии друг другу, что члены сообщества друг другу доверяют. И сейчас мы говорим о вещах, которые в общем то ограничивают свободу, можно так сказать. Не будет ли это тормозом в развитие интернета вообще или это прям необходимость-необходимость, которую уже давно пора?

Алексей Семеняка: Ну скажи, а дверные замки сильно ограничивают людей от того, чтобы ходить друг к другу в гости?

Алексей Учакин: Не, ну я понимаю.

Алексей Семеняка: Ну вот это вот ровно то, о чем мы говорим. Про механизмы, которые никак не мешают людям, которые ведут нормальную активность, строить сети. То, что мы обсуждаем – это достаточно дешевые технологии. BGPSec и то, что говорил Игнас — в будущем, а для настоящего это слишком тяжелая технология. То, что мы сейчас обсуждаем – это дешевые технологии, которые аналогичны дверному замку. Да, чтобы пойти в гости нам нужно, во-первых, вот здесь выйти, то есть открыть замок, закрыть замок, прийти, позвонить в замок — там нам откроют, потом за нами закроют. Это дешево по сравнению со всей историей похода, да? Насчет неотвратимости – хотелось бы верить. Прошу прощения, Арно Днипер, он сейчас в аудитории, или он отлучился? У него, как у представителя DE-CIX хотелось бы узнать, есть какие-нибудь планы? Нет? Ну, MSK-IX, они здесь точно есть. MSK-IX скажите, у вас есть планы ввести валидацию?
 

Александр Ильин, технический Директор MSK-IX: Мы эксперименты эти ведем уже с прошлого года, просто у нас задача все это корректно отработать не только с точки зрения валидации, но и что делать с теми, кто либо неправильно подписал, либо не подписал вообще. Мы хотим сделать инструментарий, который сразу же с ними проводил бы разъяснительную работу, как сейчас у нас ведется по любым ошибкам, которые мы встречаем в route-объектах. Если сейчас какое-то несоответствие, то сразу автоматически высылается письмо с просьбой это дело исправить. В частности, на днях мы даже обнаружили петлю в описание AS-SET у участников, то есть такие вещи достаточно важные. Это, на мой взгляд, не менее важно, чем валидировать — еще и вести разъяснительную работу с теми, кто не делает, или делает неправильно.

Алексей Семеняка: Как раз вопрос о точности информации в RIPE DB. Спасибо большое. Вот мы наблюдаем историю, когда есть кому контролировать, там, где контролируется — там точность как-то обеспечивается. За счет, в частности, вот этих механизмов, которые есть локально — они сильно помогают точности раутинговых частей баз данных RIR. Да, подход здесь, конечно, должен быть системнее, на мой взгляд. На мой взгляд, по поводу «насколько это неизбежно» — я думаю, что проникновение будет увеличиваться, но ожидать, что в ближайшие 1-3 года у нас эта технология получит проникновение близкое к 100%, это очень наивно.

Мартин Леви: Да, близко к 100% — маловероятно, не нужно даже нацеливаться. Могу сказать только хорошее по поводу MSK-IX. Это трудное путешествие — вы знаете, и я знаю, но если вы не начнете, никогда не увидите, чем этот путь завершится и куда он ведет. В реальности, возвращаясь к очень ранним частям разговора, что когда-то было очень легко сети присоединиться к глобальному сообществу, сейчас стало гораздо сложнее. В конце 1990 гг. когда вы сначала настраивали BGP — это было так легко и, в большинстве случаев, просто проанонсировали и работает, а сейчас мы выросли и вот этот «наивный ребенок» должен вырасти и начать строить уже гораздо более сложные системы. Биржи обмена трафиком, большими его порциями, являются важными порталами в сеть и одновременно испытанием. Если вы, например, как участник IX’а, вы получаете письмо, где вам говорят: «У вас раутинг тут не очень правильный, база путей или настройки RPKI». Очень легко сегодня так сделать. Вы видите ошибки или вы видите успех. У вас вообще в этом случае неплохие шансы на эффективную коммуникацию с аудиторией. На больших точках обмена трафика это также важно, как и на маленьких — иногда на маленьких, просто вследствие масштаба, куда проще обратиться ко всем участникам обмена. Но давайте откатимся чуть-чуть назад и поговорим о технологиях. У меня пока не было шанса сказать, что я думаю по поводу BGPSec, но Игнас выразился достаточно полно. Это отличный академический протокол, но как оператор сети, я никогда не стану его использовать — он слишком сложный и построен не для реальных операторов, а как академическое упражнение. Поэтому сейчас нам, как сообществу, необходимо прийти к пониманию того, что же станет следующей вещью, которой мы займемся в IETF. Проблема у нас только одна — нехватка времени. RPKI уже десять лет, если считать от первых черновиков — в конце этого года будет 10. Сейчас у нас нет десяти лет для того, чтобы заниматься улучшениями — нам нужно сегодня как-то справляться с проблемами, используя то, что имеется. Я чуть ранее это уже говорил, возможно в ироничном тоне, сейчас я повторю это уже всерьез: «Это всем нам чего-то стоит», такой подход. Есть стандартные методики подсчета для ecommerce, допустим вы какой-то банк или платежный оператор, вы выходите онлайн и на 5 минут оказываетесь недоступны. Это абсолютно реальные убытки, в любой валюте, в любой точке мира — это деньги. Отсюда и растет наша необходимость, как сообщества сетевых инженеров, к осознанию того, что сегодня интернет это уже не та безобидная игровая площадка, какой она была 30 с небольшим лет назад. Сейчас в ней находятся почти все люди по всему миру, почти все компании в мире. Мы уже не можем вести себя в ней игриво — нужно становится серьезнее, объясняя потребителям, почему что-то отключилось на 5 минут. А мы, получается, этого делать не хотим.

Игнас Багдонас: По поводу 100% и стремлению к 100%. Нужно ли это и не является ли это злом? Допустим, мы пробуем решить проблему с BGPSec или сделать новый BGPSec, который решает 100% проблем, которые на него накладываются. А не получится ли у нас то же самое, что у нас уже есть, еще и аналогично функционирующее? Совсем не очевидно. Если бы был механизм, который решает большую часть, хорошо 80%, фундаментальных проблем, а то, что остается решается как-то. Но, если во всей глобальной сети было бы так, давайте назовем это «критической массой», что большинство игроков в сети делает валидацию, делает фильтрацию — в общем, делают ту операционную гигиену, которую нужно соблюдать — это бы очень сильно снизило шанс возникновения проблем и у тех, кто этим не занимается. А атаки, они были бы более локализованы потенциально с меньшей угрозой, с меньшим вредом и прочим делами. Другой комментарий по поводу изменений в BGP протоколах, архитектурах и прочих делах: теперешний интернет, он слишком большой, чтобы можно было что-то изменить без того, чтобы не сломать все остальное. Да, 30 лет назад можно было бы заменить BGP на что-то другое, что решает все проблемы. Во-первых, в то время мы не знали, даже не предвидели всех этих проблем. Во-вторых, сейчас заменить BGP на что-то другое, мне персонально не кажется выполнимым из-за того, что мы слишком сильно полагаемся на BGP.
 

Алексей Учакин: Что делать с теми, у кого нет объектов в RIPE? Мой аплинк работает в Европе, но у него нет никаких объектов в RIPE DB — он не использует ее как альтернативную базу данных. Что делать с теми, кто RIPE DB по разным причинам не использует?

Мартин Леви: Как по-русски «Name and Shame»? «Назови и устыди». Потому что это самый простой ответ на это. Мы должны использовать сообщество, убедить сообщество, в необходимости улучшений. Это коллективный интернет — ткни пальцем, чтобы кому-то стало стыдно. Возможно это единственный правильный способ движения вперед — озвучить, у кого плохо, а у кого хорошо, и как соответствовать.

Александр Азимов: Встречный вопрос: а ваш вышестоящий оператор, он из европейского региона?

Алексей Учакин: Ну, формально да, но он работает и в Европе, и в Америке.

Александр Азимов: Нет, у него нет вообще объектов? Или у него нет объектов в RIPE DB?

Алексей Учакин: У него есть объект в AS, но нет route objects в RIPE DB.

Александр Азимов: В других базах у него есть объекты?

Алексей Учакин: В RADB.

Александр Азимов: Ну тогда это, на самом деле, не такая драматичная ситуация, как показалось на первый взгляд.

Алексей Учакин: Нет, он просто не использует именно RIPE DB.

Александр Азимов: RIPE DB замечательна тем, что имеет авторизацию. Она имеет авторизацию только для участников. Ни для каких внешних сетей авторизации нет. Получается, по сути, та же самая надпись на заборе — создавай объекты какие-угодно, кто-угодно и так далее. И это обсуждение идет на встречах RIPE в рамках групп по базам данных: «А что нам делать с foreign объектами?», — продолжается сейчас. Договорились маркировать их по крайней мере отдельно, чтобы было сразу понятно, что этим объекты, не стоит им так же доверять, как остальным. А RADB… в ситуации, когда в разных регионах разные регистраторы имеют разные правила того, что есть и чего нет, а есть такой большой и быстрорастущий регион, как LACNIC, где вообще нет route-объектов, RADB — это благо. И наличие там объектов – ну, хорошо, пусть там будут объекты. Уж точно лучше, чем ничего.

Алексей Семеняка: Вопрос сначала был ко мне, то мне очень приятно видеть ровно то, что является идеальным примером взаимодействия сообщества и RIR. Сначала сообщество вырвало микрофон и сказало: «Да вы что, сдурели вообще»? А потом уже я, как RIR, могу взять микрофон и сказать, что: «Да, я совершенно согласен». Вообще неплохо было бы задать вопрос, по какой причине те объекты, которые относятся к региону RIPE — почему их нет в RIPE DB. Это религиозная причина, или из-за чего?

Алексей Учакин: Это как раз из их опыта, что в RIPE DB написано очень много мусора, и они ему просто не доверяют.

Алексей Семеняка: Подождите, т.е. они себе не доверяют?

Алексей Учакин: Нет, они RIPE DB не доверяют.

Алексей Семеняка: Смотрите, позиция «я не пишу ничего в свой объект, потому что не доверяю RIPE DB» — это звучит шизофренически, честное слово.

Алексей Учакин: Не хочу сейчас говорить за другого, но как есть.

Алексей Семеняка: Давайте сейчас отложим эту дискуссию, но вообще неплохо было бы сесть, возможно нас позвать, и обсудить всем вместе, как так получается. Это предмет для дискуссии, но не для всего зала.

Алексей Учакин: Еще второй момент: должен ли RIR следить за перехватами, и за правильным использованием объектов в своем регионе, или это задавать нотку BGPMon, Qrator.Radar, еще кому либо?

Алексей Семеняка: Ну, смотрите. Ровно то, что я говорил, мы должны делать то, что нам, собственно говоря, доверили наши члены. Грубо говоря, то, что мы делаем стоит каких-то денег, эти деньги как-то учитываются членством — мы несем какую-то ответственность. Мы, как RIR, видим, что эта проблема горячая, и мы готовы расширять наши активности в эту сторону. Здесь требуется, скажем так, прогрев сообщества и какая-то его реакция, со стороны наших рабочих групп, со стороны нашего членства, которые скажут: «Да, ребята, это важный вопрос — давайте вы здесь будете работать больше. Мы – ваши члены – согласны, что вы будете тратить на это деньги. Мы – рабочая группа – готовы создавать под это соответствующие политики». И мы готовы. Но здесь это не может быть гласом вопиющего в пустыне, не может быть организация RIR, организация 150 человек, RIPE NCC, которая зарегистрирована в нидерландском праве, которая вдруг начинает все делать и у нее получается. Так не будет работать.

Алексей Учакин: Окей, тогда, в целом, у меня темы закончились, может у кого-то из зала есть вопросы?

Русский язык

Английский язык