Отличная статья! А можете уточнить в контексте вашего А/Б теста QUIC vs TCP, какой CC был использован в TCP? Вы сравнивали TCP BBR1 vs ваш СС QUIC внутри NGINX?
Для IPv4 есть только варианты инкапсуляции, наиболее робочее схема с UDP, где в src port отправляется тот же самый хэш. Очевидно, такое удовольствие небесплатно. Но использовать поле QoS для этих целей, как было уже сказано, не очень хорошая/рабочая идея.
С трафиком, идущим через сеть оператора в сторону Anycast, могут быть проблемы. Если он начинает разлетаться между серверами — соединение предсказуемо рвется, и, к сожалению, мы это видели в живую при больших пушах данных. Причем в перспективе нас может ждать SRv6, который в балансировке будет полагаться на значение FL.
Вероятно правильным было бы иметь механизм согласования: может ли в течение жизни TCP соединение менять FL, но в данный момент такой механики нет ни в ядре, ни в IETF.
Да, Java она такая. Я видел работу 2ой версии валидатора в течение пары лет — почти стабильно, но именно почти. Но для прода я бы рекомендовал Routinator 3000 :)
Можно еще посмотреть на реализации от Cloudflare и OpenBGPd.
Если атака преднамеренная, то смысла «маскировать» ее под лик фактически нет. Проще тогда сделать hijack — путь будет короче, а трафика больше. С предмеренными атаками тоже можно бороться, то методы уже будут совсем другими.
А про сброс — несколько лет назад сам тестировал разные варианты вставок на Quagga, проблем не было. В BIRD вообще в функцию prepend() передается номер АС, хочешь свою добавляй, хочешь чужую. Т.е. все работает из коробки.
Нет, длина AS_PATH не имеет привязки к числу хопов. Более того, стандартный способ деприоритизации направления между операторами связи — это как раз добавление несколько раз номера своей АС в AS_PATH (prepend policy), кол-во хопов внутри сети, очевидно, при этом не меняется.
Как написано в статье, обычно делать препенд больше 5 не имеет смысла, но при этом делать его больше никто не запрещает.
Так, чуть-чуть неточно написал, там еще инвертированный порядок сегментов, и «последний» неафектится:
первый сегмент — AS3 AS2 253xAS1
второй сегмент — AS3 AS2 253xAS1
третий сегмент — 53xAS1
В итоге вместо AS3 AS2 AS1x563 получился AS3 AS2 AS1x253 AS3 AS2 AS1x306
Проблема сверх длинных AS_PATH — ей и вправду много лет, и это именно проблема реализаций, а него самого протокола. Да, в одном сегменте не может быть больше 255 номеров, однако никто не запрещает иметь несколько сегментов (тоже обычное появление {}, т.е. одновременно AS_SEQ и AS_SET приводит к разбиению пути на два сегмента).
Проблема в Quagga была в том, что при наличие несклольких сегментов AS_SEQ, неправильно считалась сумма длины всего атрибута — результат NOTIFICATION, а по факту постоянные флапы. Так же Quagga дописывала номера АС не в последний сегмент, а во все сегменты сразу, в итоге получался веселый путь: AS3 AS2 AS3 AS2 253xAS1 AS3 AS2 253xAS1.
вот представьте себе гипотетическую схему организации атаки
1) человек приходит с ноутом к кафе, цепляется к местному вайфаю
2) подключается к китайской проксе, в случае паранойи к нескольким
3) подключается к управляющим центру (ам) ботнета и отдает команду
4) уходит из кафе
действия защищающей стороны:
1) 100500 ботов атакует, система их фильтрует
2) видим живые IP адреса ботнета
— FAIL в случае spoof флуда на сетевом уровне
3) изымаем зараженную машинку, дезассемблируем тело бота, взламываем протокол взаимодействия с центром
— FAIL в случае ботнета без четких управляющих центров (P2P)
4) изымаем центр ботнета, смотрим лог, устанавливаем IP с которого отдана команда на начало атаки
5) разворачиваем список прокси–серверов
6) получаем адрес кафе, едем туда, снимаем данные видео наблюдения, и, КОНЕЧНО, видим номер машины, которая приехала–уехала во время отправки команды на начало атаки
причем 1)–5) за 12 часов — время хранения информации на прокси серверах
для решения поставленной задачи необходимо:
* немеренный административный ресурс
* мана, очень много маны:
вероятность успеха считайте сами ;)
Для крупного банка — копейки
А небольшому магазину уже неподъемно
А для крупного, там уже окажется пара-тройка адресов, которые надо защищать
И получается больше 4М в год (в среднем)
и возникает вопрос, с точки зрения какого рынка это дешево? =)
железок? у вас совсем другая услуга и другой рынок ;)
Отличная статья! А можете уточнить в контексте вашего А/Б теста QUIC vs TCP, какой CC был использован в TCP? Вы сравнивали TCP BBR1 vs ваш СС QUIC внутри NGINX?
Вероятно правильным было бы иметь механизм согласования: может ли в течение жизни TCP соединение менять FL, но в данный момент такой механики нет ни в ядре, ни в IETF.
Можно еще посмотреть на реализации от Cloudflare и OpenBGPd.
А про сброс — несколько лет назад сам тестировал разные варианты вставок на Quagga, проблем не было. В BIRD вообще в функцию prepend() передается номер АС, хочешь свою добавляй, хочешь чужую. Т.е. все работает из коробки.
Как написано в статье, обычно делать препенд больше 5 не имеет смысла, но при этом делать его больше никто не запрещает.
первый сегмент — AS3 AS2 253xAS1
второй сегмент — AS3 AS2 253xAS1
третий сегмент — 53xAS1
В итоге вместо AS3 AS2 AS1x563 получился AS3 AS2 AS1x253 AS3 AS2 AS1x306
Проблема в Quagga была в том, что при наличие несклольких сегментов AS_SEQ, неправильно считалась сумма длины всего атрибута — результат NOTIFICATION, а по факту постоянные флапы. Так же Quagga дописывала номера АС не в последний сегмент, а во все сегменты сразу, в итоге получался веселый путь: AS3 AS2 AS3 AS2 253xAS1 AS3 AS2 253xAS1.
вот представьте себе гипотетическую схему организации атаки
1) человек приходит с ноутом к кафе, цепляется к местному вайфаю
2) подключается к китайской проксе, в случае паранойи к нескольким
3) подключается к управляющим центру (ам) ботнета и отдает команду
4) уходит из кафе
действия защищающей стороны:
1) 100500 ботов атакует, система их фильтрует
2) видим живые IP адреса ботнета
— FAIL в случае spoof флуда на сетевом уровне
3) изымаем зараженную машинку, дезассемблируем тело бота, взламываем протокол взаимодействия с центром
— FAIL в случае ботнета без четких управляющих центров (P2P)
4) изымаем центр ботнета, смотрим лог, устанавливаем IP с которого отдана команда на начало атаки
5) разворачиваем список прокси–серверов
6) получаем адрес кафе, едем туда, снимаем данные видео наблюдения, и, КОНЕЧНО, видим номер машины, которая приехала–уехала во время отправки команды на начало атаки
причем 1)–5) за 12 часов — время хранения информации на прокси серверах
для решения поставленной задачи необходимо:
* немеренный административный ресурс
* мана, очень много маны:
вероятность успеха считайте сами ;)
А небольшому магазину уже неподъемно
А для крупного, там уже окажется пара-тройка адресов, которые надо защищать
И получается больше 4М в год (в среднем)
и возникает вопрос, с точки зрения какого рынка это дешево? =)
железок? у вас совсем другая услуга и другой рынок ;)