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

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

^[3]
/ Flickr / JonoTakesPhotos ^[4] / CC ^[5]

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

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

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

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

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

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

/ Flickr / Ryan H. ^[11] / CC ^[5]

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

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

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

/ Flickr / Culture Vannin ^[13] / CC ^[14]

Критика PoT

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

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

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

Автор: VAS Experts

Источник ^[19]