Запрос функции: BGP flowspec (RFC5575)

Хотите узнать больше о BGP FlowSpec?  
https://www.nanog.org/sites/default/files/wed.general.trafficdiversion.serodio.10.pdf  
https://www.nanog.org/sites/default/files/tuesday_general_ddos_ryburn_63.16.pdf  
https://conference.apnic.net/data/37/apricot-2014-wei-yin-scalable-ddos-mitigation-using-bgp-flowspec_1393312254.pdf  
http://www.slideshare.net/sfouant/an-introduction-to-bgp-flow-spec  
http://www.slideshare.net/Arbor_Networks/aol-flowspec-2015

хочу!

Спасибо за запрос на добавление функции, однако есть несколько аргументов против реализации такой спецификации:

Общий довод в пользу новых возможностей BGP звучит так: раз BGP — это такая стабильная и широко используемая вещь, давайте добавим в неё всякую случайную ерунду. Но как только начинаешь что-то добавлять, реализация BGP перестаёт быть простой и стабильной, появляется куча новых вариантов сбоев.

Цитата из RFC: «Хотя проблему можно решить и другими способами, авторы считают, что это решение даёт существенное преимущество в виде постепенного добавления к уже существующим механизмам.»

Но всё равно это нужно настраивать на каждом BGP-соседе. Почему бы не сделать под капотом отдельный протокол, чтобы баги в этом не тянули вниз весь BGP?

NLRI в BGP предназначен для передачи адресных префиксов, которые, например, в случае VPNv6 — это 8 байт RD плюс 16 байт IPv6. Структуры данных, которые хорошо работают с такими короткими (до 24 байт) префиксами, обычно не подходят для хранения NLRI произвольной длины (в килобайтах), как предлагает этот RFC.

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

Если BGP-сосед, который распространяет flowspec, подвергается DOS-атаке, то flowspec удаляются у всех соседей. RFC не объясняет, как с этим бороться.

Нужны средства, чтобы администратор мог контролировать и ограничивать объём распределяемой информации. Существующие инструменты для этого непригодны.

Независимо от того, нравится вам Flowspec или нет, именно этим сейчас движется сообщество, так что либо присоединяйтесь, либо вас заменят.

Я согласен с NZ и понимаю обе точки зрения, но скажу, что никто не нагромоздил на BGP столько всего, сколько Cisco, и несмотря на огромное количество проприетарных и RFC-дополнений, BGP остаётся относительно стабильной реализацией. BGP — естественный выбор для расширения функционала, ведь он по сути является основой всех крупных сетей в мире. По мере того как SDN всё больше входит в нашу жизнь, BGP всё активнее используется как основа для многих SDN-решений и будет продолжать развиваться. Чтобы не отстать от постоянно меняющихся угроз и атак, нам нужны те же инструменты, что и у конкурирующих сетевых вендоров.

Все больше клиентов спрашивают об этом, и нам приходится ставить либо Quagga, либо BIRD в качестве граничного маршрутизатора, поскольку MikroTik этого не поддерживает. Я бы предпочел поставить CCR, но не сможем, пока эта функция не будет реализована. Отсутствие этой возможности скажется на продажах CCR в тех сегментах, где нужен DDoS-защита, интегрированная с BGP — а этот рынок в 2016 году стремительно растёт. Вот отличный обзор BGP FlowSpec, который вышел всего неделю назад, там хорошо объясняют, почему эта технология сейчас так активно применяется. https://packetpushers.net/podcast/podcasts/pq-show-78-bgp-flowspec-dos-mitigation/

Я посмотрел на другую платформу для защиты от DDoS, которая требует BGP FlowSpec. Ещё один источник информации о BGP FlowSpec: https://www.youtube.com/watch?v=XBM5lgiPXGc

Более 100 RFC уже утверждены, у других провайдеров это реализовано, разные ISP и транзитные сети это поддерживают — нам это нужно, чтобы не отставать от отрасли. Сначала нужна поддержка нового NLRI, чтобы валидировать, принимать и передавать их. Затем — возможность создавать правила и реально влиять на поток трафика. Но это может появиться позже, гораздо позже, если понадобится больше времени, просто скажите. Вся эта куча API и других функций в MT делает возможным влияние снаружи, но нам нужно оборудование, которое сможет принимать и передавать новую информацию... Вот мои пять копеек.