The OpenNET Project / Index page

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



"BGPsec получил статус предложенного стандарта"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"BGPsec получил статус предложенного стандарта"  +/
Сообщение от opennews on 01-Окт-17, 12:02 
Комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры интернета, завершил (http://www.ietf.org/mail-archive/web/ietf-announce/current/m...) формирование RFC для протокола BGPsec и опубликовал (https://www.rfc-editor.org/info/rfc8205) связанную с ним спецификацию под идентификатором RFC 8205 (https://www.rfc-editor.org/rfc/rfc8205.txt). RFC получил статус "Предложенного стандарта", после чего начнётся работа по приданию RFC статуса чернового стандарта (Draft Standard), фактически означающего полную стабилизацию протокола и учёт всех высказанных замечаний.


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


Например, в 2008 году попытка блокировки YouTube в Пакистане, выполненная через заворачивание подсети YouTube  на интерфейс null0, привела к публикации ошибочного BGP-анонса и стеканию трафика YouTube в Пакистан. В апреле нынешнего года зафиксировано (https://www.opennet.me/opennews/art.shtml?num=46469)  перенаправление трафика Visa, MasterCard и некоторых банков в сеть Ростелекома из-за того, что по ошибке связанные с ними автономные системы были анонсированы по BGP как находящиеся в сети Ростелекома.

BGPsec вводит (https://www.noction.com/blog/bgpsec_protocol) в обиход новый непереходящий атрибут BGPsec_Path, который можно использовать вместо атрибута AS_Path. Кроме списка автономных систем в BGPsec_Path также приводятся сведения о цифровых подписях, добавляемых на каждом узле и позволяющих при получении сообщения BGP UPDAGE удостовериться в том, что полученный от предыдущих узлов список автономных систем не был модифицирован. Цифровая подпись добавляется на граничном маршрутизаторе каждой автономной системы, через которую проходит маршрут, и  удостоверяет, что на данном участке маршрут передан через системы, указанные в AS_Path. Указанная техника не позволяет поменять какие-то значения AS_Path и гарантирует, что каждая автономная система, перечисленная в сообщении UPDATE, авторизировала  анонс маршрута.


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

URL: http://www.ietf.org/mail-archive/web/ietf-announce/current/m...
Новость: http://www.opennet.me/opennews/art.shtml?num=47303

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "BGPsec получил статус предложенного стандарта"  +/
Сообщение от zanswer CCNA RS and S on 01-Окт-17, 12:02 
Интересно, как будет выглядеть процедура внедрения данного расширения, не техническая процедура конечно, а административная. Наличие RFC вовсе не означает следование его букве, каждой автономной системой, в части его реализации.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "BGPsec получил статус предложенного стандарта"  +2 +/
Сообщение от Аноним (??) on 01-Окт-17, 12:09 
Добровольно и с песней будет, потому что для администраторов сетей это решение проблем с безопасностью.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

4. "BGPsec получил статус предложенного стандарта"  +2 +/
Сообщение от zanswer CCNA RS and S on 01-Окт-17, 12:56 
Что-то опыт других таких же решающих проблемы безопасности RFC, которые почему-то не внедрили все, заставляет сомневаться в этом.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

9. "BGPsec получил статус предложенного стандарта"  +6 +/
Сообщение от qq (??) on 01-Окт-17, 16:50 
Аха, конечно любой админ может прийти к директору и взять на новое железо несколько лямов, и любой бухгалтер с удовольствием найдет в бюджете эти деньги
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

12. "BGPsec получил статус предложенного стандарта"  +/
Сообщение от ram_scan on 01-Окт-17, 20:18 
> Добровольно и с песней будет, потому что для администраторов сетей это решение проблем с безопасностью.

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

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

15. "BGPsec получил статус предложенного стандарта"  +2 +/
Сообщение от nikosd (ok) on 02-Окт-17, 04:51 
Для поиграть с BGP в России надо только  иметь примерно  2К USD, это  вполне позволит подключиться к достаточно крупному провайдеру, который не имеет привычки накладывать фильтры ( личный опыт ошибочных анонсов более специфичных маршрутов в  AS174, который включил из в свой FW). Никаких кар, владелец сетей два дня пытался добиться чего-либо от этого апстрима,   потом написал  нам.  
Ну и кроме Райпа ( где с базой все нормально) есть  еще куча RIR, которые вообще не ведут вменяемых баз.
Про введение -  ой не быстро это будет, но будет, просто потому что  скорости растут, железо меняется, а  в новом все это появится.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

24. "BGPsec получил статус предложенного стандарта"  +/
Сообщение от Аноним (??) on 02-Окт-17, 22:23 
> Ну и кроме Райпа ( где с базой все нормально) есть  еще куча RIR, которые вообще не ведут вменяемых баз.

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

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

28. "BGPsec получил статус предложенного стандарта"  +/
Сообщение от nikosd (ok) on 02-Окт-17, 22:47 
>> Ну и кроме Райпа ( где с базой все нормально) есть  еще куча RIR, которые вообще не ведут вменяемых баз.
> Так, это их проблемы. Вопрос административно решается вполне нормально, как показывает
> опыт ripe.

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

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

29. "BGPsec получил статус предложенного стандарта"  +/
Сообщение от Аноним (??) on 03-Окт-17, 00:17 
>>> Ну и кроме Райпа ( где с базой все нормально) есть  еще куча 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 с херой горой фильтров.

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


Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

31. "BGPsec получил статус предложенного стандарта"  +/
Сообщение от nikosd (ok) on 03-Окт-17, 15:00 
>>>> Ну и кроме Райпа ( где с базой все нормально) есть  еще куча RIR, которые вообще не ведут вменяемых баз.
>>> Так, это их проблемы. Вопрос административно решается вполне нормально, как показывает
>>> опыт ripe.
>> Интересно  как Вы собираетесь обязать RIR что-либо делать?
> Для этого есть icann и iana. Глядя на бд arin, становится страшно.
> Их давно пора вздрючить.

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

В каком мире  Вы живете ?  -  у меня  ныне  покойный провайдер  акртел  анонсировал  сеть  клиента, который от них ушел  и сессию погасил и физику порубил. Могу найти переписку с райпом, но ответ  один -   " у  них нет рычагов влияния", решил только  письмами  апстримам арктела и  на MSK-IX, которые фильтранули  .  Да  сам, как уже писал по ошибке пихнул  чужую /23  как две  по /24 ( в  моем объекте  их не было) -  никаких санкций и возражений не последовало
>> пир с одним Rtcomm это  тысячи строк "что им можно
>>  анонсировать",
> Если Вы про as8342, то я там тысячи никакие не вижу. Посмотрите
> as39792, вот там кошмар.

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

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

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

32. "BGPsec получил статус предложенного стандарта"  +/
Сообщение от anonymous (??) on 03-Окт-17, 16:21 
>>> Интересно  как Вы собираетесь обязать RIR что-либо делать?
>> Для этого есть icann и iana. Глядя на бд arin, становится страшно.
>> Их давно пора вздрючить.
> ага, при этом  ICANN  вообще не  имеет рычагов воздествия
> на RIR..

  Это как же? Насколько я знаю, именно icann присваивает статус rir. И вообще,
как выполняющая роль iana, она является корнем выделения адресов и т.п. - rir лишь её региональные представители. Так же как rir дрючит lir на корректное заполнение доков, можно помучать и rir, я так думаю. Мне думается это всё можно провернуть, было бы желание.

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

  Это как так они настроили свой bgp-сервер? В том, что пользую я, нельзя анонсировать то, что тебе не приходит - этому анонсу просто взяться неоткуда. Единственный вариант прописать это у себя как свой анонс, но это ж пипец. Так никто не делает. Сочуствую Вам. Идиотская ситуация.

> Могу найти переписку с райпом, но ответ  один
> -   " у  них нет рычагов влияния", решил
> только  письмами  апстримам арктела и  на MSK-IX, которые
> фильтранули  .

  СТранно. Сам в такие ситуации не попадал, поэтому хз. Те про которые слышал, там люди по ошибке на себя заворачивали пол европы. Им там по шапке надавали. Возможно ripe просто не хотел возиться ради 1-ого анонса. Так-то, когда получаете asn или ip-сеть, там где-то пишут, что ripe может в случае, если что-то не понравиться, отобрать назад всё.
  
>  Да  сам, как уже писал по
> ошибке пихнул  чужую /23  как две  по /24
> ( в  моем объекте  их не было) -  
> никаких санкций и возражений не последовало

Ну, так жалоб в ripe на это не было, судя по всему.

> у схемы с  рефлектором    есть и куча минусов,

  Можно поподробней об этом :-)? Я, кроме потребности в ещё одном ip в линковой сети, весомых(относительно плюсов) минусов не вижу.

> в том  числе  время схождения, то есть  для
> клиентов время потери связанности с частью сети, при DOWN  одного

  Ну, bgp не ospf - от него мгновенного схождения не добиться в любом случае. Плюс, относительно всей цепочки bgp-серверов сколько Ваш +1 добавит к общему времени? Не думаю, что что-либо ощутимое пользователем :-).

> из провайдеров.   но не об этом - я  
> не знаю кто  я, ну 1200 префиксов  анонсим, то
> есть и  я фильтрую клиентов и  мои апстримы меня
> ( как показывает практика - совсем не все фильтруют).

  Так я об этом и говорю. Похоже не так Вас понял. Т.е. каждый фильтрует свои downstream'ы. Вы свои, Ваши upstream свои(т.е. Вас). Фильтровать upstream надобности нет, кроме таких кривых случаев, как Вы описали, но там это делается по факту, руками.


Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

26. "BGPsec получил статус предложенного стандарта"  +/
Сообщение от Аноним (??) on 02-Окт-17, 22:27 
> Добровольно и с песней будет, потому что для администраторов сетей это решение
> проблем с безопасностью.

Это не нужно.

// адм.сетей

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

27. "BGPsec получил статус предложенного стандарта"  +/
Сообщение от Аноним (??) on 02-Окт-17, 22:28 
> Добровольно и с песней будет, потому что для администраторов сетей это решение
> проблем с безопасностью.

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

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

8. "BGPsec получил статус предложенного стандарта"  +/
Сообщение от пох on 01-Окт-17, 15:11 
> Интересно, как будет выглядеть процедура внедрения данного расширения

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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

11. "BGPsec получил статус предложенного стандарта"  +/
Сообщение от zanswer CCNA RS and S on 01-Окт-17, 19:40 
Вполне вероятно, что и не прийдётся, он имеет статус опционального не транзитивного атрибута.

"3.  The BGPsec_PATH Attribute

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

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

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

16. "BGPsec получил статус предложенного стандарта"  +3 +/
Сообщение от _ (??) on 02-Окт-17, 16:41 
>Для тех кто не знаком с протоколом BGP, это означает, что его можно вообще не реализовывать.

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

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

35. "BGPsec получил статус предложенного стандарта"  +/
Сообщение от Vladimir Goncharov on 03-Окт-17, 20:17 
>> Интересно, как будет выглядеть процедура внедрения данного расширения
> боюсь, никак. Ничего не хочу знать о том, сколько именно займет единичный
> full-view со всеми этими подписями (а единственный, естественно, не нужен).

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

Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

3. "BGPsec получил статус предложенного стандарта"  +/
Сообщение от Аноним (??) on 01-Окт-17, 12:10 
Когда антиспуфинг в БГП будет? Тоже все грозились, что уже подают заявки.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "BGPsec получил статус предложенного стандарта"  +/
Сообщение от zanswer CCNA RS and S on 01-Окт-17, 13:05 
Вы говорите о «BGP Anti-Spoofing Extension (BASE)» или о чём-то другом?
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

6. "BGPsec получил статус предложенного стандарта"  +/
Сообщение от t28 on 01-Окт-17, 13:07 
> антиспуфинг в БГП будет

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

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

7. "BGPsec получил статус предложенного стандарта"  +1 +/
Сообщение от Аноним (??) on 01-Окт-17, 15:00 
наконец-то.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "BGPsec получил статус предложенного стандарта"  +1 +/
Сообщение от Нанобот (ok) on 01-Окт-17, 19:37 
подозреваю, что внедрение затянется на десятилетие-другое
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

13. "BGPsec получил статус предложенного стандарта"  +/
Сообщение от Pahanivo (ok) on 01-Окт-17, 22:24 
> подозреваю, что внедрение затянется на десятилетие-другое

как с ipv6 ))

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

25. "BGPsec получил статус предложенного стандарта"  +/
Сообщение от Аноним (??) on 02-Окт-17, 22:24 
>> подозреваю, что внедрение затянется на десятилетие-другое
> как с ipv6 ))

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

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

14. "BGPsec получил статус предложенного стандарта"  +2 +/
Сообщение от A on 01-Окт-17, 22:29 
Чтобы внедрить это чудо, нужно будет (всего-то ничего!) обновить прошивки на многих (хорошо бы - всех) BGP-роутерах.

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

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

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

17. "BGPsec получил статус предложенного стандарта"  +/
Сообщение от Аноним (??) on 02-Окт-17, 18:38 
BGP-роутеры не вечны. Даже если прошивку не обновлять, рано или поздно встанет вопрос о его замене. Так что десяток лет максимум потребуется на внедрение. Да, долго, но всё же не "не будет этого в жизни". Будет.
Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

33. "BGPsec получил статус предложенного стандарта"  +/
Сообщение от пох on 03-Окт-17, 17:40 
> BGP-роутеры не вечны.

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

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

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

22. "BGPsec получил статус предложенного стандарта"  +/
Сообщение от Аноним (??) on 02-Окт-17, 22:16 
Херня полная. Если раньше full view был 300k маршрутов, то теперь >650k. Даже если не брать во внимание старые девайсы, которые и 2 современных fullview не могут просто вместить, а говорить о софтроутерах с bgp, которые таких проблем не имеют, то можно представить какую нагрузку будет создавать эта хрень на столько маршрутов.

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

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

34. "BGPsec получил статус предложенного стандарта"  +/
Сообщение от пох on 03-Окт-17, 17:42 
> P.S. как сделать так, что б сообщение не удалилось?..

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

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

23. "BGPsec получил статус предложенного стандарта"  –1 +/
Сообщение от Аноним (??) on 02-Окт-17, 22:19 
Ну и кто у нас будет тут продавать воздух в качестве CA?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

30. "BGPsec получил статус предложенного стандарта"  +/
Сообщение от Атоним on 03-Окт-17, 10:15 
Наверное спец службы в этом тоже не заинтересованны. Вот будут подписаны все маршрутами чем-то вроде цифровых подписей. Все будут знать что и куда пошло/пришло. И никто не останется незамеченным.  
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

36. "BGPsec получил статус предложенного стандарта"  +/
Сообщение от Vladimir Goncharov on 03-Окт-17, 21:11 
Сейчас примерно прикинул объес ОЗУ необходимый для хранения 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 это никак не повлияет.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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