Главная » Хабрахабр » QUIC, TLS 1.3, DNS-over-HTTPS, далее везде

QUIC, TLS 1.3, DNS-over-HTTPS, далее везде

Это транскрипция доклада Артема ximaera Гавриченкова, прочитанного им на BackendConf 2018 в рамках прошедшего фестиваля РИТ++. Хабр, привет!

— Здравствуйте!

В названии доклада приведён длинный список протоколов, мы по нему пройдемся постепенно, но давайте начнем с того, чего в названии нет.

В том посте написано, что HTTP/2 — это не какое-то отдаленное будущее, это наше настоящее; это современный протокол, разработанный Google и сотнями профессионалов из многих продвинутых компаний, выпущенный IETF в качестве RFC в далеком 2015 году, то есть уже 3 года назад. Это (под катом) заголовок одного из блогов, в интернете вы могли таких заголовков видеть очень много.

Стандарты IETF воспринимаются индустрией, как такие железобетонные документы, как могильная плита, фактически.

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

Он должен был повышать производительность сайта, параллельно снижая нагрузку на бэкенд. HTTP/2 должен был быть адаптирован для продвинутого веба, готов к использованию в современных сервисах и приложениях, фактически быть drop-in replacement для старых версий протокола HTTP.

Даже SEO-шники говорили, что им нужен HTTP/2.

В частности, Нил Крейг из BBC писал в своем блоге, что достаточно «просто включить» его на сервере. И его, вроде как, было очень просто поддержать. Еще можно найти множество презентаций, где написано, что HTTP/2 включается следующим образом: если у вас Nginx, то можно в одном месте поправить конфигурацию; если нет HTTPS, нужно ещё дополнительно поставить сертификат; но, в принципе, это вопрос одного токена в конфигурационном файле.

И, естественно, после того, как вы пропишете этот токен, вы сразу начинаете получать бонусы от повышения производительности, новых доступных фич, возможностей – в общем, всё становится замечательно.

medium.com/@DarkDrag0nite/how-http-2-reduces-server-cpu-and-bandwidth-10dbb8458feb
2.
Ссылки со слайда:
1. www.cloudflare.com/website-optimization/http2

Компания имеет некоторый онлайн-сервис, обрабатывающий порядка 500-1000 HTTP-запросов в секунду. Дальнейшая история основана на реальных событиях. Сервис этот находится под DDoS-защитой Cloudflare.

Ожидалось, что при переходе на HTTP/2 и памяти используемой станет меньше, и процессор будет менее нагружен. Существует множество бенчмарков, которые подтверждают, что переход на HTTP/2 снижает нагрузку на сервер вследствие того, что при переходе на HTTP/2 браузер устанавливает уже не 7 соединений, а по плану вообще одно.

Вопрос: почему бы так не сделать? Плюс к этому в блоге Cloudflare и на сайте Cloudflare предлагается включить HTTP/2 просто одним кликом.

Месяц собираются данные. 1 февраля 2018 года компания включает HTTP/2 этой самой кнопочкой в Cloudflare, и на локальном Nginx тоже его включает. На следующем слайде будет процент запросов, пришедших на сервер по HTTP/2. 1-го марта происходит замер потребляемых ресурсов, и потом sysops'ы смотрят число запросов в логах, которые приходят по HTTP/2 на стоящий за Cloudflare сервер. Поднимите руки, кто знает, какой будет этот процент?

[Из зала: «1-2%!»]

По какой причине? — Ноль.

Если в нормальной ситуации браузер напрямую соединяется с вашим Nginx, то есть соединение идет напрямую от браузера до вашего HTTP-сервера, то вы можете использовать тот протокол, который браузер поддерживает. Cloudflare, а так же другие сервисы по защите от атак, MSSP и облачные сервисы, работают в режиме reverse proxy.

В случае, если между браузером и вашим сервером стоит облако, пришедшее TCP-соединение терминируется в облаке, TLS тоже там терминируется, и HTTP-запрос сначала попадает на облако, далее облако фактически обрабатывает этот запрос.

Этот сервер парсит запрос, как-то его обрабатывает, консультируется с кэшами и, в конечном итоге, формирует новый запрос и отправляет его уже на ваш сервер по тому протоколу, который он поддерживает. У облака есть собственный HTTP-сервер, в большинстве случаев тот же самый Nginx, в редких случаях это «самописный» сервер.

Но не поддерживают его на стороне, смотрящей к вам. Все существующие облака, заявляющие о поддержке HTTP/2, поддерживают HTTP/2 на стороне, смотрящей в браузер.

Почему?

Окей, хорошо, это ответ правильный, но не полный. Простой и не совсем правильный ответ: «Потому что в большинстве случаев у них развёрнут Nginx, а Nginx не умеет ходить по HTTP/2 к апстриму».

Дело в том, что в фокусе спецификации HTTP/2, написанной и выпущенной в 2015 году, было повышение производительности браузера на специфичных, например, для Google сценариях использования. Полный ответ нам дают инженеры Cloudflare.

Там, на самом деле, и профита мало, потому что в режиме reverse proxy, из того, что описано в протоколе HTTP/2, например, Server Push не поддерживается, потому что непонятно, как он должен работать, если у нас pipelining. Google использует собственные технологии, не использует reverse proxy перед своими production-серверами, поэтому о reverse proxy никто не подумал, и именно поэтому HTTP/2 от облака до апстрима не используется.

Смысла поддерживать здесь HTTP/2 мало, а накладные расходы и проблемы связанные с этим – большие. То, что HTTP/2 экономит соединения – это круто, но reverse proxy сам по себе их экономит, потому что он не открывает по одному соединению на каждого пользователя.

То есть это технология середины 2000 годов: я еще в школу ходил, а она уже использовалась. Что важно: reverse proxy – это технология, которая начала активно использоваться порядка 13 лет назад. В стандарте, выпущенном в 2015 году, она не упоминается, не поддерживается и работа по ее поддержке, на данный момент, в рабочей группе httpbis в IETF не ведется.

На самом деле, когда разговариваешь с людьми, которые развернули и имеют уже какой-то опыт работы с ним, постоянно слышишь примерно одни и те же слова. Это один пример тех вопросов, которые возникают, когда люди начинают внедрять HTTP/2.

Он написал, что его сильно удивило, насколько отличается взаимодействие конкретно этой функциональности с браузерами, ведь он думал, что это полностью отработанная фича, готовая к использованию в продакшене. Лучше всего их сформулировал Максим Матюхин из Badoo в посте на Хабре, где он рассказывал о том, как работает HTTP/2 Server Push. Эту фразу в отношении HTTP/2 я слышал уже очень много раз: думали, что это протокол, который «drop-in replacement» – то есть включаешь его, и все нормально – почему же на практике всё так сложно, откуда возникают все эти проблемы и недоработки?

Давайте разберемся.

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

Выше него использовался протокол TCP – или UDP, но для 90% случаев (так как 80-90% трафика в интернете – это Web) дальше был TCP, – затем SSL (который потом заменили на TLS), а выше уже был гипертекстовый протокол HTTP. Протоколы использовались следующие: так как мы говорим про Интернет, а не про локальную сеть, то на нижнем уровне начинаем с протокола IPv4. Постепенно сложилась ситуация, что, по плану, к 2020 году архитектура интернета должна была в корне поменяться.

TLS недавно обновили, мы еще обсудим, как это происходило. Протокол IPv6 с нами уже очень давно. И протокол HTTP/2 тоже обновился.

Вы хотели будущего? У замечательного отечественного фантаста Вадима Панова в цикле «Анклавы» была такая прекрасная фраза: «Вы ждали будущего. Вы его не хотели? Оно наступило. Единственное, что осталось практически нетронутым — по состоянию на пару лет назад – это протокол TCP. Оно все равно наступило».

Люди, которые занимаются дизайном интернета, не могли пройти мимо такой вопиющей несправедливости и решили протокол TCP выкинуть тоже.

Проблема не просто в том, что протокол слишком старый. Ладно, это, конечно же, шутка. Особенно многих беспокоило, что протокол HTTP/2 уже написан, стандарт 2015 года уже внедряется, но вот конкретно с TCP он работает не всегда хорошо, и неплохо бы под него подложить какой-нибудь другой транспорт, более подходящий для того, что когда-то называлось SPDY, когда пошли те разговоры, а потом и для HTTP/2. В протоколе TCP есть недостатки.

QUIC – это ныне разрабатываемый протокол для транспорта. Протокол решили назвать QUIC. Первый черновик стандарта был выпущен в июле 2016 года, и текущая версия черновика… Он основан на UDP, то есть это датаграммный протокол.

[Докладчик проверяет почту на телефоне]

—… да, всё ещё 12-я.

Если я не ошибаюсь – я не стал писать на слайде, потому что боялся ошибиться – но на IETF 101 в Лондоне говорилось, что где-то к ноябрю 2018 года планируется выпустить его уже как окончательный документ. На данный момент QUIC еще не является стандартом — его активно пишут. Именно сам стандарт QUIC, потому что в рабочей группе документов ещё восемь штук.

Я перечислил только те конференции, где я был за последние полгода, где про QUIC была хотя бы одна презентация. То есть стандарта еще нет, но уже идет активный хайп. Весь этот хайп длится уже достаточно давно — я уже видел много статей, которые призывали игровую индустрию переходить на QUIC вместо обычного UDP. О том, «какой он крутой», «как нам нужно на него переходить», «что делать операторам», «перестаньте фильтровать UDP — через него сейчас QUIC будет работать».

conferences.sigcomm.org/imc/2017/papers/imc17-final39.pdf
2.
Ссылки со слайда:
1. blog.apnic.net/2018/01/29/measuring-quic-vs-tcp-mobile-desktop

В ноябре 2017 года в рассылке рабочей группы QUIC появляется вот такая ссылка: верхняя на whitepaper, а нижняя для тех, кому тяжело читать whitepaper — это ссылка на блог APNIC с кратким содержанием.

Для сравнения, чтобы не разбираться с тем, кто в чем виноват и где может быть вина Windows, со стороны клиента взяли Chrome под Ubuntu, а также взяли 2 мобильных устройства: какой-то Nexus и какой-то Samsung (прим. Исследователи решили сравнить производительность TCP и QUIC в текущем его виде. ред.: Nexus 6 и MotoG) с Android 4 и 6 версий, и в них тоже запустили Chrome.

Результаты benchmark'ов показали, что, хотя во всех тепличных условиях QUIC действительно выигрывает у TCP, есть некоторые краеугольные кейсы, по которым он проигрывает. Со стороны сервера они поставили Apache для того, чтобы видеть, как работает TCP-сервер, а для того, чтобы отслеживать QUIC, они выдрали кусок опенсорсного кода, который имеется в проекте Chromium.

В 2017-2018 годах, в век мобильных и беспроводных сетей, вообще нет никакой гарантии, что пакет в принципе долетит, не говоря уже о том, в каком порядке. Например, реализация QUIC от Google работает существенно хуже TCP, если в сети происходит packet reordering, то есть пакеты прилетают не в том порядке, в котором были отправлены сервером. QUIC отлично работает на проводной сети, но кто сейчас пользуется проводной сетью?

Вообще, разработчики этого кода в Google, видимо, очень не любят мобилки.

И на мобильных устройствах так же в user space. QUIC – это протокол, который реализован поверх UDP в user space. Что это за состояние? По результатам измерений, в нормальной ситуации, то есть при работе через беспроводную сеть, реализация протокола QUIC 58% времени проводит в Android в состоянии «Application Limited». Для сравнения, на десктопах была цифра около 7%. Это состояние, когда мы какие-то данные отправили и ждем подтверждения.

Естественно, это оказалось в рабочей группе IETF, посвященной QUIC и, естественно, на это отреагировал Google. Всего 2 кейса использования: первый – беспроводная сеть, второй – мобильное устройство; и QUIC работает либо как TCP, либо существенно хуже. Реакция Google была следующая:


mailarchive.ietf.org/arch/msg/quic/QktVML_qNDfqjIGirj4t5D0JRGE

Ну, мы посмеялись, но на самом деле это абсолютно логично.

Потому что дизайн QUIC – хотя мы говорим уже о внедрении в production, но – на самом деле дичайший эксперимент. Почему?

Кто ее помнит здесь? Вот, скажем, семиуровневая модель ISO/OSI. Помните уровни: физический, канальный, сетевой, транспортный, какая-то чушь, какой-то бред и прикладной, да?

QUIC – это эксперимент по устранению самой по себе уровневой системы сети. Да, оно было разработано очень давно, и как-то мы жили с этой уровневой моделью. Все это не в уровневой структуре, а в комбайне, где каждый компонент имеет доступ к API других компонентов. Он объединяет в себе шифрование, транcпорт, надежную доставку данных.

У нас есть и acknowledgement, и flow control, и шифрование, и вся криптография, – все это полностью в одном транспорте, и наши транспортные инновации подразумевают доступ всего этого напрямую к сетевому API, поэтому уровневую архитектуру в QUIC'е мы не хотим. Цитируя одного из дизайнеров протокола QUIC Кристиана Гюитема: «Одно из главных преимуществ QUIC с архитектурной точки зрения – это отсутствие уровневой структуры».

Остается только транспортная функция, которая работает поверх DTLS. Разговор в рабочей группе об этом пошел из-за того, что в начале марта другой дизайнер протокола QUIC, а именно Эрик Рескорла, решил предложить на обсуждение вариант, в котором из QUIC убирается все шифрование, вообще. DTLS, в свою очередь, – это TLS поверх UDP, в сумме получается: QUIC поверх TLS поверх UDP.

Кстати, Рескорла написал большой документ, но вовсе не для того, чтобы это стало стандартом — это был предмет для обсуждения потому, что в процессе дизайна архитектуры QUIC, в процессе тестирования интероперабельности и реализации, возникло очень много проблем. Откуда возникло такое предложение? В основном, связанных с «потоком 0».

Это такая же идея, как и в HTTP/2: у нас есть одно соединение, внутри него у нас есть несколько мультиплексируемых потоков. Что такое «поток 0» в QUIC? Сделано это было следующим образом: открывается «магический» поток номер 0, который отвечает за установку соединения, рукопожатие и шифрование, после чего этот поток 0 шифруется и все остальные шифруются тоже. По дизайну QUIC, напоминаю, шифрование обеспечивается тем же протоколом. Выделю только один, который мне очень нравится. С этим возникло достаточно много проблем, они перечислены в списке рассылки, там 10 пунктов, я не буду на каждом останавливаться.


www.ietf.org/mail-archive/web/quic/current/msg03498.html

А при этом, например, на стороне сервера соединение уже может быть отмечено, как шифрованное, а потерянный пакет относится ещё ко времени, когда оно было незашифровано. Проблема, связанная с потоком 0, – одна из – состоит в том, что в случае, если у нас идет потеря пакетов, нам нужно их перепосылать. В этом случае при перепосылке реализация может случайно шифровать пакеты.

Ещё раз:

Случайно шифровать пакеты.

В разработке QUIC фактически используется эрзац-agile-подход. Это довольно сложно прокомментировать, кроме того, чтобы рассказать, как это все на самом деле дизайнится. Нет. То есть не то, чтобы кто-то написал железобетонный стандарт, который через пару итераций можно официально выпустить.

Запускается черновик стандарта, например, номер 5;
2. Работа происходит следующим образом:
1. Google внедряет какие-то из изменений в Chrome, в собственной инфраструктуре, анализирует последствия и далее счетчик инкрементируется и появляется стандарт 6. В списках рассылки, а также на IETF-встречах – три штуки в год — проходит обсуждение, потом на хакатонах проходит реализация, interop testing, собирается обратная связь;
3.

ред.: по состоянию на 10 июля 2018 г. Сейчас, напоминаю, 12 версия.
Прим. уже 13-я.

Что здесь важно?

В этом процессе, на самом деле, можно участвовать. Во-первых, минусы мы только что увидели, но есть и плюсы. Но на данный момент вы можете на это повлиять, с этим можно как-то работать. Feedback собирается со всех вовлеченных сторон: если вы занимаетесь gaming'ом, если вы думаете, что вы в игровой индустрии можете просто взять и поменять UDP, поставить вместо него QUIC, и все будет работать – нет, не будет.

Feedback от вас ожидается, все хотят его видеть. И это, на самом деле, общая история.

Компании, которые занимаются другими вещами (если это не совсем типичные Web, gaming или мобильные приложения, SEO то же самое), они не могут по умолчанию рассчитывать, что протокол будет учитывать их интересы: не только потому, что это никого не интересует, а потому, что никто просто не знает про эти интересы. Google разрабатывает протокол, в него какие-то идеи вкладывает – для своих целей.

Конечно же, вопрос ко мне, почему мы, как Qrator Labs, в частности, не участвовали в разработке протокола HTTP/2 и не сказали никому про reverse proxy. Это, кстати, явка с повинной. Но те же Cloudflare и Nginx тоже там не участвовали.

Чтобы вы знали, в около-IETF'ной тусовке слово «академик» – оно, скажем так, не похвальное. Пока в этом не участвует индустрия, разработкой занимаются Google, Facebook, какие-то еще компании и академики. Люди часто приходят без каких-либо практических целей, без понимания реальных задач, но вписываются туда, потому что так проще на докторскую диссертацию наработать. Оно звучит наподобие эпитетов «шизофреник» и «ипохондрик».

В этом всём, конечно, нужно участвовать и вариантов других нет.

«Реализован в user space». Возвращаясь к QUIC: итак, протокол реализован в user space, на мобильных устройствах существует… Бла-бла. Давайте поговорим об этом.

Как он устроен сейчас в продакшене? Как у нас вообще был устроен транспорт до того, как начали придумывать QUIC? Есть протокол TCP, если мы говорим про Web.

Оно нужно для целого ряда вещей: чтобы не позволять использовать сервер для атак на других, чтобы успешнее фильтровать определенные атаки на протокол TCP, такие, как SYN-флуд. В протоколе TCP есть такая штука, как тройное рукопожатие: SYN, SYN/ACK, ACK. Только после того, как 3 сегмента тройного рукопожатия прошли, у нас начинается отправка данных.

При этом тут 4 действия, 3 из которых происходят в ядре, происходят они достаточно эффективно, а в user space попадают уже данные, когда соединение установлено.

Тут звездочка стоит, потому что там терминология не совсем «SYN, SYN/ACK», но, по сути, это тот же самый хендшейк, только переехавший полностью в user space. В ситуации с QUIC всё это счастье – в юзерспейсе. И там их нужно как-то поддерживать. Если летит 20 Гбит/с флуда и раньше в TCP их можно было обработать в ядре SYN-куками, то теперь их нужно обрабатывать в user space, так как они пролетают все ядро и через вcе context switch'и.

Почему QUIC – это протокол user space'овый? Почему сделано так? Хотя транспортный, казалось бы, самое место ему где-то на системном уровне.

Они хотят видеть новый протокол внедренным, они не хотят ждать, пока все операционные системы в округе обновятся. Потому что, опять же, в этом интерес Google и других участников рабочей группы. Если он реализован в user space, его можно использовать (в частности, в браузере, но не только) уже сейчас.

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


www.ietf.org/mail-archive/web/quic/current/msg03736.html

Это буквальная цитата: «Мы хотим деплоить QUIC на любую машину без поддержки операционной системы. На экране буквальная цитата из рассылки QUIC, где проходило обсуждение как раз о том, что протокол планируется к реализации в user space. QUIC уже настолько развесистый, что уносить это в ядро с шифрованием и со всем остальным уже страшновато, но рабочая группа на эту тему тоже особо не запаривается. Если у кого будут проблемы с производительностью, то они унесут это все в ядро».

Но тот же подход используется на стороне сервера. Причем почему этот подход используется на стороне клиента – я могу понять. И когда это произойдет – не очень понятно. Теоретически, в этом случае QUIC действительно стоило бы уносить в ядро, но, опять же, работа над этим не ведется, а когда она будет закончена, мы уже в лучшем случае все седыми будем, и я не планирую жить вечно.

Говоря про ядро Linux, нельзя не упомянуть, что одним из главных смыслов существования QUIC было то, что он реализован поверх легковесного протокола UDP, и благодаря этому работает более эффективно, более быстро… и вообще зачем тогда нам TCP, такой большой и громоздкий.


vger.kernel.org/netconf2017_files/rx_hardening_and_udp_gso.pdf

Выясняется, что отправка UDP-датаграмм в Linux дороже, чем отправка TCP-потока, причем существенно дороже, заметно дороже. Тут представлена другая ссылка на бенчмарк. Там есть 2 главных момента (то есть много моментов, но только два главных):

Поиск по таблице маршрутизации занимает больше времени в случае UDP-датаграммы;
2. 1. В TCP мы большой поток данных можем просто сгрузить в передачу, не обязаны его разбивать по сегментам на CPU, в то время как в UDP нам нужно подготовить каждую датаграмму, у нас нет потока. Штука под названием «large segment offload». В данный момент разработчики ядра думают, что с этим делать, но, по большому счету, на данный момент, TCP работает на посылке больших данных, не влезающих в один пакет, эффективнее, чем UDP, на котором основан QUIC.


www.ietf.org/mail-archive/web/quic/current/msg03720.html

Ведь мы можем просто попытаться обвинить Linux, сказать, что под Windows, может быть, не так все плохо, но нет. Вот это опять же цитата сотрудника Google, я, в частности, тоже задавал ему этот вопрос. То есть это не просто Linux такой, а это общий подход. Утверждается, что на любой платформе, на которой Google деплоил QUIC, есть проблема с повышенной стоимостью (с точки зрения центрального процессора) отправки UDP-пакета против TCP-потока.

Что приводит нас к одной простой мысли.

Достаточно. Хватит говорить про QUIC. 1, QUIC вместо TCP, шифрование DNS, IPv6 вместо IPv4… первое, что нужно сделать, перед принятием решения и выкладкой на production – это, естественно, benchmarking. Простая идея, которую нужно отсюда вынести – это то, что перед внедрением любого нового протокола вместо старого: HTTP/2 против HTTP/1.

Никогда такого не будет – и не было никогда, и не будет в будущем, и никто такое не гарантирует. Не верьте никому, кто говорит, что протокол «можно просто поменять/включить/нажать кнопку» – нет!

Поэтому только бенчмарк, и, естественно, что если вы этого не сделаете, а просто развернете что-нибудь, то, конечно, гарантию качественной работы вам никто не предоставит.

Дело в том, что во времена IPv6, когда он разрабатывался, протоколы разрабатывались как-то более прямолинейно, то бишь без agile-технологий. Кстати, про IPv6. И, на данный момент, все еще продолжается, и все еще висит на уровне 10-20% в случае IPv6. Но их адаптация в интернете всё равно заняла очень большое существенное время. Причем в зависимости от страны, потому что в России еще ниже.

Кто знает, что такое «Happy Eyeballs»? На пути внедрения IPv6 было решено очень много проблем. Скажем, ты закрываешь ноутбук, выходишь из дома, где у тебя есть IPv6, приходишь в кафе, где IPv6 нет, открываешь лэптоп – ничего не работает, потому что кэши браузера и операционной системы – все это продолжает смотреть в IPv6, а локальной связности нет. В общем, было очень много проблем, связанных с IPv6, причём таких, когда жаловались живые пользователи.

Был придуман подход под названием «Happy Eyeballs» (тоже являющийся стандартом, выпущенным IETF): если в течении 0,3 с мы не нашли IPv6-связности, не смогли соединиться, мы откатываемся на IPv4.

Постоянно возникают мистические проблемы с реализацией. Костыль, но работает, вроде бы, почти всегда, но! В частности, одна из самых популярных проблем почему-то была почему-то с iPad, которые из IPv6 в IPv4 и обратно переключались существенно медленнее, чем за 0,3 секунды: около 1 секунды – а то и 1 минуты.

Собирать syslog со всех подключенных устройств – никто, конечно, на это не согласился. Даже в какой-то момент возникло безумное предложение на IETF 99 в Праге: «а давайте Happy Eyeballs будет в каждой сети по syslog'у на централизованный сервер, если проблемы, – что-нибудь отправлять». Но это показатель того, что проблем достаточно много.

Этим нужно как-то заниматься, это все должно быть реализовано. Другие проблемы – это борьба со всякими злонамеренными активностями, потому что локальная сеть в IPv6 – это /64 и очень много адресов, которые атакующий может начать перебирать, защите нужно их вовремя агрегировать, и все такое.

Нет, его начали отключать обратно. В результате мы все равно получили проблемы с внедрением, которые не только выражаются в том, что кто-то IPv6 медленно внедряет. Потому что и без проблем тяжело было обосновать менеджменту преимущества перехода, но если после включения ещё и пользователи начали жаловаться — сразу всё. Обратно переходить в IPv4. Это такой пример, когда даже протокол, который разработан был с видом на внедрение, всё равно вызывает дичайшие проблемы с внедрением, которые выражаются в головомойке техническому департаменту.

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


blog.apnic.net/2018/02/26/peak-dnssec

Я не буду просить вас поднять руки, чтобы узнать, у кого оно есть, потому что знаю, что ни у кого нет. Другой пример на эту тему – DNSSEC.

Начиная с конца прошлого года, внедрение DNSSEC в мире замедлилось и пошло в обратном направлении. Развёртывание IPv6, с одной стороны, развивается, с другой стороны, с ним есть проблемы, но оно хотя бы идет.

Здесь очень четко виден медвежий тренд: вот он, стартует после последнего пика, и этот пик – октябрь 2016 г. На этом графике мы видим ежедневное количество интернет-пользователей (по замерам APNIC Labs), использующих резолверы, которые валидируют DNSSEC.

У DNSSEC есть цель, есть правильные задачи, но его развертывание фактически остановилось и пошел какой-то обратный процесс, и еще предстоит расследовать, откуда этот процесс взялся.


datatracker.ietf.org/meeting/101/materials/slides-101-dnsop-sessa-the-dns-camel-01

В рабочей группе IETF dnsop сейчас 3 председателя, 15 черновиков, что называется, «в полете»: готовятся к выходу как RFC. Вообще с DNS очень много проблем.

Поверх TCP он работал давно (но еще нужно людям показать, как это правильно делать). DNS, в частности, научились передавать поверх всего. Теперь его начали пускать поверх TLS, поверх HTTPS, поверх QUIC.

В марте 2017 г. Все это выглядело совершенно замечательно, пока люди не начали это реализовывать, и у них не начало болеть в пятой точке. Презентация сводится к следующей мысли: насколько еще мы можем нагрузить этого верблюда (aka протокол DNS), прежде чем очередная хворостинка сломает ему хребет? разработчики OpenDNS привезли на IETF презентацию под названием «DNS Camel», или «верблюд DNS».

Фичи добавляются, фич очень много, они друг с другом интерферируют по-разному. Это общий подход к тому, как мы видим сейчас дизайн. Внедрение каждой такой новой фичи, реализация, внедрение в production – добавляют набор потенциальных точек отказа в каждом месте, где происходит такая интерференция. И не всегда предсказуемым образом, и не всегда авторы реализации понимают все возможные точки интерференции. Без бенчмарка, без мониторинга – никуда.

Потому что стандарт IETF – «RFC» – это все-таки стандарт. Почему важно участвовать во всем этом процессе? Есть вот такая хорошая статистика: сроки разработки различных версий протоколов шифрования SSL и TLS.

9 и 1. Обратите внимание, что версионирование SSL начинается с номера 2, потому что версии 0. Поэтому история началась с протокола SSL 2. 0 никогда не были выпущены в production, они были более дырявыми, чем Netscape мог позволить себе выпустить. Потом SSL 3. 0, который разрабатывался год. 0 разрабатывался ещё один год.

0 разрабатывался 3 года; версия 1. Затем TLS 1. 2 разрабатывался только 2 года, потому что там не такие большие изменения были; но последняя версия, которая была выпущена в марте этого года – 27-й черновик, кстати – разрабатывалась 10 лет. 1 – 7 лет; 1.

3 ломает очень много use case'ов, в частности, в финансовых организациях, с их мониторингом и файрволлами. В соответствующей рабочей группе в определенный момент на эту тему была большая паника, потому что выяснилось, что TLS 1. S. Но изменить это, придя к осознанию уже на стадии восемнадцатого черновика, не смогли даже такие крупные компании, как U. Они ничего не успели с этим сделать, потому что, когда ты приходишь на вечеринку в момент, когда всем уже раздают счет, ты не можешь ожидать, что к твоему предложению продолжить веселье отнесутся с пониманием. Bank.

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

Здесь на слайде, собственно, три главных вывода из всего этого процесса.

Это расписанный план внедрения, оценка целесообразности с обязательными бенчмарками, как в реальности это все себя поведет. Первый: как я говорил, внедрение нового протокола – это не просто в конфигурации «что-то подкрутить».

Пункт номер два: протоколы не инопланетянами разрабатываются, они не даны нам свыше, в этом процессе можно и нужно участвовать, потому что за вас никто ваши юзкейсы продвигать не будет.

Самое главное, что тот же Google, он не злой, он просто преследует свои собственные цели, у него нет задачи разрабатывать протокол для вас и за вас, это можете сделать только вы. И третье, действительно: фидбэк нужен.

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

Спасибо!


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Сетевой дайджест: 20 экспертных материалов о протоколах, стандартах и информационной безопасности

В эту подборку мы включили свежие посты, подготовленные специалистами компании VAS Experts. Главные темы подборки — сетевые протоколы, 5G и информационная безопасность. Под катом вы также найдете ряд рекомендаций по построению сетей операторов связи. / Pxhere / PD Про ИБ ...

[Перевод] Забудьте о мегаструктурах инопланетян: новые наблюдения объясняют поведение звезды Табби одной только пылью

Художественное изображение KIC 8462852, яркость которой за последние несколько лет менялась необычным образом Когда планета проходит перед её родительской звездой, если смотреть с нашей точки зрения, часть света звезды на некоторое время исчезает. Научная охота за планетами в XXI веке ...