The OpenNET Project / Index page

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

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

01.10.2017 10:53

Комитет 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 3.0
Короткая ссылка: https://opennet.ru/47303-bgp
Ключевые слова: bgp, route, bgpsec
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (32) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | 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 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну и кроме Райпа ( где с базой все нормально) есть  еще куча RIR, которые вообще не ведут вменяемых баз.

    Так, это их проблемы. Вопрос административно решается вполне нормально, как показывает опыт ripe.

     
     
  • 6.28, nikosd (ok), 22:47, 02/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> Ну и кроме Райпа ( где с базой все нормально) есть  еще куча RIR, которые вообще не ведут вменяемых баз.
    > Так, это их проблемы. Вопрос административно решается вполне нормально, как показывает
    > опыт ripe.

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

     
     
  • 7.29, Аноним (-), 00:17, 03/10/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >>> Ну и кроме Райпа ( где с базой все нормально) есть  еще куча RIR, которые вообще не ведут вменяемых баз.
    >> Так, это их проблемы. Вопрос административно решается вполне нормально, как показывает
    >> опыт ripe.
    > Интересно  как Вы собираетесь обязать RIR что-либо делать?

    Для этого есть icann и iana. Глядя на бд arin, становится страшно. Их давно пора вздрючить.

    > Ну и как
    > обяжете  всех накладывать фильтры на анонсы ( даже от пиров),

    Да, вроде, сейчас с кем ни сталкивался, все фильтруют и так.
    Я не очень понимаю зачем драконовские фильтры в ix - каждый адекватный участник должен сам контролить своих downstream'ов.
    Насчёт серьёзных косяков, те случаи, которые я слышал по нашей месности, оборачивались хмурой реакцией ripe и желающих такое повторять особо нет, что б не лишиться asn.

    > пир с одним Rtcomm это  тысячи строк "что им можно
    >  анонсировать",

    Если Вы про as8342, то я там тысячи никакие не вижу. Посмотрите as39792, вот там кошмар.

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

    Если Вы конечный потребитель или небольшой транзитёр, то не понятно зачем вообще от upstream'ов фильтроваться - это им надо от Вас фильтроваться. Если Вы магистрал, то это Ваш непосредственный зароботок и вопрос денег для бордера стоять не должен так, плюс кто ж, кроме цисководов, занимается таким безумием, что б на нагруженном бордере bgp с фильтрами и кучей view получать? Это делается на отдельном bgp-сервере, откуда нужные маршруты заливаются на пограничный маршрутизатор. А раз так, то сервера с linux/bsd + bird + 4GB ram хватит минимуи на 6-10 fullview с херой горой фильтров.

    Может я не правильно Вас понял?


     
     
  • 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 современных fullview не могут просто вместить, а говорить о софтроутерах с bgp, которые таких проблем не имеют, то можно представить какую нагрузку будет создавать эта хрень на столько маршрутов.

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

    P.S. как сделать так, что б сообщение не удалилось?..

     
     
  • 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:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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