Хабрахабр

«Proof of Transit»: в IETF предложили новый подход для подтверждения пути сетевых пакетов

В IETF (Internet Engineering Task Force) предлагают реализовать Proof of Transit (PoT) — «путевой журнал» для сетевых пакетов. Подробнее об инициативе и принципах работы PoT — под катом.


/ Flickr / JonoTakesPhotos / CC

Зачем понадобился Proof of Transit

Согласно мнению экспертов Cisco, Comcast и JP Morgan Chase виртуализация не позволяет в полной мере удостовериться в том, что сетевые пакеты не были подменены или модифицированы. Такая необходимость может быть обоснована, например, внутренними политиками организации или требованиями регулятора.

Поэтому и был предложен новый подход под названием Proof of Transit. Сейчас эту задачу можно решить косвенным образом, но по мнению авторов инициативы эволюция сетей и появление таких технологий, как NFV, LISP и NSH значительно усложняют этот процесс. Предполагается, что он позволить вести что-то вроде истории или журнала прохождения пакета по заданному маршруту.

Как работает предложенный подход

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

Когда верификатор получает пакет, он проверяет подлинность пути. Каждый узел использует свой ключ или долю секрета для обновления PoT-данных пакетов.

/ CC
/ Flickr / Ryan H.

Если говорить простыми словами, то принцип работы этого метода защиты заключается в пошаговом разделении секрета на условные «координаты» точек (узлов), по которым идет последующая интерполяция заданной кривой (пути пакета) — вычисление интерполяционного многочлена Лагранжа. Для обеспечения безопасности такого подхода эксперты предлагают использовать схему разделения секрета Шамира на этапе генерирования PoT-данных.

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

Алгоритм тут следующий: каждый узел получает секретное значение точки на кривой POLY-1. Для усиления безопасности авторы предлагают использовать 2 полинома: POLY-1 (секретный и постоянный) и POLY-2 (публичный, произвольный и индивидуальный для каждого пакета). Далее каждый из узлов прибавляет значение точки на кривой POLY-1 к точке на POLY-2, чтобы получить точку на POLY-3 и передать ее узлу-верификатору вместе с пакетом. После этого узел генерирует точку на кривой POLY-2, всякий раз, когда через него проходит пакет. В конце пути верификатор на базе полученных данных строит кривую POLY-3 и проверяет соответствие POLY-3 = POLY-1 + POLY-2 (при этом только верификатор знает параметры полинома POLY-1).


/ Flickr / Culture Vannin / CC

Критика PoT

В комментариях на The Register аудитория площадки отмечает ряд несовершенств предложенного подхода. Кто-то, например, опасается, что реализация идеи приведет к тому, что «вес» UDP-пакета значительно увеличится, и PoT не сможет ужиться с IPSec. Помимо этого, не совсем ясно, как будет работать PoT в случае сбоя на одном из заданных узлов. Получается, что в PoT-данных нужно будет закладывать альтернативные маршруты. Что делать в таких случаях IETF пока не пояснили.

Будущее документа

Отметим, что черновой вариант инициативы находится на этапе обсуждения и доработки и пока ни на что не претендует. В течение полугода (до 2 декабря 2018 года) IETF могут его изменить, заменить или признать устаревшим.
О чем можно почитать в корпоративном блоге на сайте VAS Experts:

Теги
Показать больше

Похожие статьи

Добавить комментарий

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

Кнопка «Наверх»
Закрыть