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 В каком мире ... большой текст свёрнут, показать | |
|
|
|
|
|
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.6, t28 (?), 13:07, 01/10/2017 [^] [^^] [^^^] [ответить]
| +/– |
> антиспуфинг в БГП будет
… в каком-то другом Интернете.
| |
|
|
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.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 это никак не повлияет.
| |
|