/ Flickr / JonoTakesPhotos / CC
Зачем понадобился Proof of Transit
Согласно мнению экспертов Cisco, Comcast и JP Morgan Chase виртуализация не позволяет в полной мере удостовериться в том, что сетевые пакеты не были подменены или модифицированы. Такая необходимость может быть обоснована, например, внутренними политиками организации или требованиями регулятора.
Сейчас эту задачу можно решить косвенным образом, но по мнению авторов инициативы эволюция сетей и появление таких технологий, как NFV, LISP и NSH значительно усложняют этот процесс. Поэтому и был предложен новый подход под названием Proof of Transit. Предполагается, что он позволить вести что-то вроде истории или журнала прохождения пакета по заданному маршруту.
Как работает предложенный подход
Решение, представленное в документе, основано на добавлении небольшого объема данных к каждому пакету. Эти данные используются для составления истории и проверки корректности пути. Параметры обязательных к прохождению узлов описываются с помощью секретных ключей либо схемы разделения секрета.
Каждый узел использует свой ключ или долю секрета для обновления PoT-данных пакетов. Когда верификатор получает пакет, он проверяет подлинность пути.
Для обеспечения безопасности такого подхода эксперты предлагают использовать схему разделения секрета Шамира на этапе генерирования 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 / CC
Критика PoT
В комментариях на The Register аудитория площадки отмечает ряд несовершенств предложенного подхода. Кто-то, например, опасается, что реализация идеи приведет к тому, что «вес» UDP-пакета значительно увеличится, и PoT не сможет ужиться с IPSec. Помимо этого, не совсем ясно, как будет работать PoT в случае сбоя на одном из заданных узлов. Получается, что в PoT-данных нужно будет закладывать альтернативные маршруты. Что делать в таких случаях IETF пока не пояснили.
Будущее документа
Отметим, что черновой вариант инициативы находится на этапе обсуждения и доработки и пока ни на что не претендует. В течение полугода (до 2 декабря 2018 года) IETF могут его изменить, заменить или признать устаревшим.
О чем можно почитать в корпоративном блоге на сайте VAS Experts:
Комментариев нет:
Отправить комментарий