The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги | ]

01.10.2017 10:53  BGPsec получил статус предложенного стандарта

Комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры интернета, завершил формирование RFC для протокола BGPsec и опубликовал связанную с ним спецификацию под идентификатором RFC 8205. RFC получил статус "Предложенного стандарта", после чего начнётся работа по приданию RFC статуса чернового стандарта (Draft Standard), фактически означающего полную стабилизацию протокола и учёт всех высказанных замечаний.

BGPsec определяет расширение для протокола маршрутизации BGP (Border Gateway Protocol), обеспечивающее авторизацию списка автономных систем (AS), передаваемых в сообщениях об обновлении маршрута (BGP UPDATE), привязывая их к точке доверия (Trust Anchor). Изначально протокол BGP не предусматривал средств для защиты от модификации цепочки AS, что создавало угрозу совершения атак по перенаправлению трафика на сторонние узлы через подстановку фиктивных записей в AS_Path.

Например, в 2008 году попытка блокировки YouTube в Пакистане, выполненная через заворачивание подсети YouTube на интерфейс null0, привела к публикации ошибочного BGP-анонса и стеканию трафика YouTube в Пакистан. В апреле нынешнего года зафиксировано перенаправление трафика Visa, MasterCard и некоторых банков в сеть Ростелекома из-за того, что по ошибке связанные с ними автономные системы были анонсированы по BGP как находящиеся в сети Ростелекома.

BGPsec вводит в обиход новый непереходящий атрибут BGPsec_Path, который можно использовать вместо атрибута AS_Path. Кроме списка автономных систем в BGPsec_Path также приводятся сведения о цифровых подписях, добавляемых на каждом узле и позволяющих при получении сообщения BGP UPDATE удостовериться в том, что полученный от предыдущих узлов список автономных систем не был модифицирован. Цифровая подпись добавляется на граничном маршрутизаторе каждой автономной системы, через которую проходит маршрут, и удостоверяет, что на данном участке маршрут передан через системы, указанные в AS_Path. Указанная техника не позволяет поменять какие-то значения AS_Path и гарантирует, что каждая автономная система, перечисленная в сообщении UPDATE, авторизировала анонс маршрута.

Цифровые подписи формируются при помощи фреймворка RPKI (Resource Public Key Infrastructure), применяющего методы инфраструктуры открытых ключей для построения цепочки доверия к сетевым ресурсам. По аналогии со схемой, когда удостоверяющий центр заверяет SSL-сертификат сайта, в RPKI для автономных систем и IP-адресов строится цепочка доверия от IANA к региональным регистраторам (RIRs), а затем к провайдерам (LIR) и конечным потребителям. В итоге, RPKI позволяет третьим лицам удостовериться, что операция с ресурсом была произведена его владельцем.

  1. Главная ссылка к новости (http://www.ietf.org/mail-archi...)
  2. OpenNews: Зафиксировано перенаправление трафика крупнейших финансовых сервисов через BGP
  3. OpenNews: В рамках проекта GoBGP развивается реализация протокола BGP на языке Go
  4. OpenNews: Проблемы в BGP названы одной из самых опасных уязвимостей Интернета
  5. OpenNews: Выявлена техника MITM-атак, основанная на подстановке фиктивных BGP-маршрутов
  6. OpenNews: Разбор причин нарушения работы сети Internet, вызванных некорректным BGP анонсом
Лицензия: CC-BY
Тип: К сведению
Ключевые слова: bgp, route, bgpsec
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, zanswer CCNA RS and S (?), 12:02, 01/10/2017 [ответить] [показать ветку] [···]    [к модератору]
  • +/
    Интересно, как будет выглядеть процедура внедрения данного расширения, не техническая процедура конечно, а административная. Наличие RFC вовсе не означает следование его букве, каждой автономной системой, в части его реализации.
     
     
  • 2.2, Аноним (-), 12:09, 01/10/2017 [^] [ответить]    [к модератору]
  • +2 +/
    Добровольно и с песней будет, потому что для администраторов сетей это решение проблем с безопасностью.
     
     
  • 3.4, zanswer CCNA RS and S (?), 12:56, 01/10/2017 [^] [ответить]    [к модератору]
  • +2 +/
    Что-то опыт других таких же решающих проблемы безопасности RFC, которые почему-то не внедрили все, заставляет сомневаться в этом.
     
  • 3.9, qq (??), 16:50, 01/10/2017 [^] [ответить]    [к модератору]
  • +6 +/
    Аха, конечно любой админ может прийти к директору и взять на новое железо несколько лямов, и любой бухгалтер с удовольствием найдет в бюджете эти деньги
     
  • 3.12, ram_scan (?), 20:18, 01/10/2017 [^] [ответить]    [к модератору]
  • +/
    > Добровольно и с песней будет, потому что для администраторов сетей это решение проблем с безопасностью.

    Не будет. Во первых не предъявив кучу бумажных документов поиграть с BGP в мировой масштабе просто не пускают. А если накосорезил, то анальную кару выписывают в известный адрес. Во вторых худо бедно вопросы с безопасностью так или иначе на сегодня решаются фильтрами которые прибиты к райповской базе, в которой пиринг партнеры записаны, поэтому чужой анонс теоретически конечно просунуть можно, но практически чуть более чем все все эти случаи связаны с местечковым долбоклюйством, а не с "русскими хакерами". В третьих если стандарт будет опциональный, то нельзя гарантировать его соблюдение, следовательно даже если ты мехом внутрь вывернулся и все это дело у себя запилил сильно не факт что твой партнер по пирингу тоже на это озаботился, а не пошел водку пить и девок тискать. Что сводит весь этот блудняк на нет.

     
     
  • 4.15, nikosd (ok), 04:51, 02/10/2017 [^] [ответить]    [к модератору]  
  • +2 +/
    Для поиграть с BGP в России надо только  иметь примерно  2К USD, это  вполне позволит подключиться к достаточно крупному провайдеру, который не имеет привычки накладывать фильтры ( личный опыт ошибочных анонсов более специфичных маршрутов в  AS174, который включил из в свой FW). Никаких кар, владелец сетей два дня пытался добиться чего-либо от этого апстрима,   потом написал  нам.  
    Ну и кроме Райпа ( где с базой все нормально) есть  еще куча RIR, которые вообще не ведут вменяемых баз.
    Про введение -  ой не быстро это будет, но будет, просто потому что  скорости растут, железо меняется, а  в новом все это появится.
     
     
  • 5.24, Аноним (-), 22:23, 02/10/2017 [^] [ответить]     [к модератору]  
  • +/
    Так, это их проблемы Вопрос административно решается вполне нормально, как пока... весь текст скрыт [показать]
     
     
  • 6.28, nikosd (ok), 22:47, 02/10/2017 [^] [ответить]    [к модератору]  
  • +/
    >> Ну и кроме Райпа ( где с базой все нормально) есть  еще куча RIR, которые вообще не ведут вменяемых баз.
    > Так, это их проблемы. Вопрос административно решается вполне нормально, как показывает
    > опыт ripe.

    Интересно  как Вы собираетесь обязать RIR что-либо делать? Ну и как обяжете  всех накладывать фильтры на анонсы ( даже от пиров), пир с одним Rtcomm это  тысячи строк "что им можно  анонсировать", память и проц с  бордерах денег стоят. (мне пришлось  ограничиться проверкой  разрешененных путей, так как  префиксы просто никуда  влезть не могли при включении пиринга с he.net И de-cix)

     
     
  • 7.29, Аноним (-), 00:17, 03/10/2017 [^] [ответить]     [к модератору]  
  • +/
    Для этого есть icann и iana Глядя на бд arin, становится страшно Их давно пора... весь текст скрыт [показать]
     
     
  • 8.31, nikosd (ok), 15:00, 03/10/2017 [^] [ответить]     [к модератору]  
  • +/
    ага, при этом ICANN вообще не имеет рычагов воздествия на RIR В каком мире ... весь текст скрыт [показать]
     
     
  • 9.32, anonymous (??), 16:21, 03/10/2017 [^] [ответить]     [к модератору]  
  • +/
    Это как же Насколько я знаю, именно icann присваивает статус rir И вообще, к... весь текст скрыт [показать]
     
  • 3.26, Аноним (-), 22:27, 02/10/2017 [^] [ответить]    [к модератору]  
  • +/
    > Добровольно и с песней будет, потому что для администраторов сетей это решение
    > проблем с безопасностью.

    Это не нужно.

    // адм.сетей

     
  • 3.27, Аноним (-), 22:28, 02/10/2017 [^] [ответить]    [к модератору]  
  • +/
    > Добровольно и с песней будет, потому что для администраторов сетей это решение
    > проблем с безопасностью.

    Какие проблемы с безопасностью?

     
  • 2.8, пох (?), 15:11, 01/10/2017 [^] [ответить]    [к модератору]  
  • +/
    > Интересно, как будет выглядеть процедура внедрения данного расширения

    боюсь, никак. Ничего не хочу знать о том, сколько именно займет единичный full-view со всеми этими подписями (а единственный, естественно, не нужен).

     
     
  • 3.11, zanswer CCNA RS and S (?), 19:40, 01/10/2017 [^] [ответить]    [к модератору]  
  • +/
    Вполне вероятно, что и не прийдётся, он имеет статус опционального не транзитивного атрибута.

    "3.  The BGPsec_PATH Attribute

    The BGPsec_PATH attribute is an optional non-transitive BGP path attribute."

    Для тех кто не знаком с протоколом BGP, это означает, что его можно вообще не реализовывать.

     
     
  • 4.16, _ (??), 16:41, 02/10/2017 [^] [ответить]    [к модератору]  
  • +3 +/
    >Для тех кто не знаком с протоколом BGP, это означает, что его можно вообще не реализовывать.

    Для тех кто знаком с SMTP - помните времена когда можно было не прикручивать TLS, SPF, DKIM & DMARC и почта всё равно ходила? А всё! И тут так же будет. Но не завтра, да :)

     
  • 3.35, Vladimir Goncharov (?), 20:17, 03/10/2017 [^] [ответить]    [к модератору]  
  • +/
    >> Интересно, как будет выглядеть процедура внедрения данного расширения
    > боюсь, никак. Ничего не хочу знать о том, сколько именно займет единичный
    > full-view со всеми этими подписями (а единственный, естественно, не нужен).

    На роутерах обычно проблемы с дорогущей CAM/TCAM памятью, в которой хранится FIB. А для храннения подписей будет расходоваться RAM, которая очень дешевая. Поставят вместо 2х Гб в роутер 8 Гб и все, роутер подорожает на 100 баксов.

     
  • 1.3, Аноним (-), 12:10, 01/10/2017 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Когда антиспуфинг в БГП будет? Тоже все грозились, что уже подают заявки.
     
     
  • 2.5, zanswer CCNA RS and S (?), 13:05, 01/10/2017 [^] [ответить]    [к модератору]  
  • +/
    Вы говорите о «BGP Anti-Spoofing Extension (BASE)» или о чём-то другом?
     
  • 2.6, t28 (?), 13:07, 01/10/2017 [^] [ответить]    [к модератору]  
  • +/
    > антиспуфинг в БГП будет

    … в каком-то другом Интернете.

     
  • 1.7, Аноним (-), 15:00, 01/10/2017 [ответить] [показать ветку] [···]    [к модератору]  
  • +1 +/
    наконец-то.
     
  • 1.10, Нанобот (ok), 19:37, 01/10/2017 [ответить] [показать ветку] [···]    [к модератору]  
  • +1 +/
    подозреваю, что внедрение затянется на десятилетие-другое
     
     
  • 2.13, Pahanivo (ok), 22:24, 01/10/2017 [^] [ответить]    [к модератору]  
  • +/
    > подозреваю, что внедрение затянется на десятилетие-другое

    как с ipv6 ))

     
     
  • 3.25, Аноним (-), 22:24, 02/10/2017 [^] [ответить]    [к модератору]  
  • +/
    >> подозреваю, что внедрение затянется на десятилетие-другое
    > как с ipv6 ))

    ipv6 тормозит сам ripe

     
  • 1.14, A (?), 22:29, 01/10/2017 [ответить] [показать ветку] [···]    [к модератору]  
  • +2 +/
    Чтобы внедрить это чудо, нужно будет (всего-то ничего!) обновить прошивки на многих (хорошо бы - всех) BGP-роутерах.

    Хотим мы того, или нет, это нереально. Часть железок никогда не обновляется ("работает - не трогай", и "а у нас нет доступа к свежим IOS, чтобы обновляться"), часть даже не обслуживается админами постоянно (т.е. настроил кто-то, и оно работает).

    В общем, спасибо за предложение, но... не будет этого в жизни.

    Не говоря, что некоторая часть админов просто не осилит еще и тут ключи внедрять, и внедрение этого чуда еще и поломает связность там, где раньше она хотя бы была.

     
     
  • 2.17, Аноним (-), 18:38, 02/10/2017 [^] [ответить]     [к модератору]  
  • +/
    BGP-роутеры не вечны Даже если прошивку не обновлять, рано или поздно встанет в... весь текст скрыт [показать]
     
     
  • 3.33, пох (?), 17:40, 03/10/2017 [^] [ответить]    [к модератору]  
  • +/
    > BGP-роутеры не вечны.

    оптимииииист... Как тебе 7200 в роли пира? Да, там не full-view, но и не полтора инвалида - вполне себе живой и работающий оператор связи за ней.

    Ну и помимо проблем с операторами, есть еще такая "мелкая" проблема как требуемый этой фичей объем памяти - что мелкий оператор-то решит заменой железа, когда-нибудь, теоретически, а вот магистралы и IX'ы - могут, внезапно, обнаружить, что при их масштабах "мелкая проблема" требует памяти больше, чем физически можно засунуть вообще в любой существующий ящик.
    Да и насчет вычислительных ресурсов неочевидно.

     
  • 1.22, Аноним (-), 22:16, 02/10/2017 [ответить] [показать ветку] [···]     [к модератору]  
  • +/
    Херня полная Если раньше full view был 300k маршрутов, то теперь 650k Даже ес... весь текст скрыт [показать]
     
     
  • 2.34, пох (?), 17:42, 03/10/2017 [^] [ответить]    [к модератору]  
  • +/
    > P.S. как сделать так, что б сообщение не удалилось?..

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

     
  • 1.23, Аноним (-), 22:19, 02/10/2017 [ответить] [показать ветку] [···]    [к модератору]  
  • –1 +/
    Ну и кто у нас будет тут продавать воздух в качестве CA?
     
  • 1.30, Атоним (?), 10:15, 03/10/2017 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Наверное спец службы в этом тоже не заинтересованны. Вот будут подписаны все маршрутами чем-то вроде цифровых подписей. Все будут знать что и куда пошло/пришло. И никто не останется незамеченным.  
     
  • 1.36, Vladimir Goncharov (?), 21:11, 03/10/2017 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Сейчас примерно прикинул объес ОЗУ необходимый для хранения full view с подписями.
    Я взял одного из своего апстримов, с него я получаю 661251 маршрут. В сумме AS PATH всех маршрутов получился 3174042.
    Если смотреть по RFC8208, там в примере BGPSEC Path Attribute занимает 209 байт, то умножив получаем, что в моем случае около 632 МБ памяти будет занимать каждый Full View (на самом деле чуть меньше, поскольку препенды не будут занимать дополнительного места, для них есть поле pCount).
    Для бордера, может быть, это и проблема, особенно если аплинков 4-5, но для магистральных роутеров - не думаю что создаст какие-то трудности.
    Я очень бегло глянул RFC, и не до конца понял как маршрутизаторы будут получать публичные ключи для проверки маршрутов. Если придется в роутере хранить кеш всех публичных ключей, это может занять еще по 64 байта на ASN, плюс номер ASN, плюс указатели... 72-80 байт на ASN. Если предположить что имеется 128тыс ASN (не представляю сколько их прямо сейчас) и по 80 байт то получается нам надо еще целых 10 МБ ОЗУ.

    Так что по ОЗУ тут не так все страшно. На дорогую CAM/TCAM, в котором лежит FIB это никак не повлияет.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:


      Закладки на сайте
      Проследить за страницей
    Created 1996-2018 by Maxim Chirkov  
    ДобавитьПоддержатьВебмастеруГИД  
    Hosting by Ihor