Комитет 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.ru/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.ru/opennews/art.shtml?num=47303
