«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 виртуализация не позволяет в полной мере удостовериться в том, что сетевые пакеты не были подменены или модифицированы. Такая необходимость может быть обоснована, например, внутренними политиками организации или требованиями регулятора.

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

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


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

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


    / Flickr / Ryan H. / CC

    Для обеспечения безопасности такого подхода эксперты предлагают использовать схему разделения секрета Шамира на этапе генерирования 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:

    • +21
    • 6,7k
    • 8

    VAS Experts

    180,00

    Российский разработчик DPI-системы СКАТ

    Поделиться публикацией
    Комментарии 8
      +10
      Какой смысл в том, чтобы заставлять пакет идти по конкретному маршруту? Если важно, чтобы никто не мог прочитать содержимое, зашифруйте его. Если нужно, чтобы никто не мог его подменить, используйте HMAC. Если нужно убедиться в том, что отправил именно тот, кто должен, используйте криптографические подписи. Все это можно тривиально реализовать поверх UDP, если есть охота изобрести велосипед. Какой бизнес-кейс решает схема, предложенная IETF?
        +16
        Под это можно продать новое оборудование, например.
          0
          Вот тоже об этом же подул.

          У меня мысль скорее возникает о том, что весь трафик на уровне IP должен быть зашифрован, а адреса не должны кем-то выдаваться. Т.е. то, что предлаегает CJDNS. Тогда и не нужно думать о подмене, поиске маршрутов, анализе данных и блокировке по содержимому (либо весь трафик блокируешь нуглухо и досвидос экономира страны, либо не лезешь и мы снова в свободном интернете)
            0
            Вы, вероятно, не заглядывали в первоисточник:

            In certain cases,
            regulatory obligations or a compliance policy require operators to
            prove that all packets that are supposed to follow a specific path
            are indeed being forwarded across and exact set of pre-determined
            nodes.
            +7
            для дополнительного цензурирования трафика подойдет.
              +4
              Блокчейн надо на каждый IP пакет, было бы современное решение :)
              А вообще, ощущение, что сетевое протоколостроение давно зашло в творческий кризис.
              Появляются или инновации решающие проблемы, но имеющие спорный дизайн и большие трудности во внедрении. Или не понятно, что решающие, но зато чрезмерно сложные и гарантированно создающие проблемы в эксплуатации.
                0
                Ну вот, очередной костыль. Правда от IETF, так что теперь хватает плюсов в карму.

                Хотя для моей идеи этого не требовалось бы.
                habr.com/company/globalsign/blog/355006/#comment_10791940
                habr.com/company/globalsign/blog/355006/#comment_11335690
                habr.com/company/globalsign/blog/355006/#comment_11336604
                habr.com/company/globalsign/blog/355006/#comment_11337128

                Все это пустота. Proof of transit не защитит от MiTM, т.к. вы все равно будете доверять старой подложке — IP, где все условно. Никто не помешает склонировать рутер и дать ему тот же самый ключ. Как они защищать VM будут, вообще вопрос, ведь с ВМ можно снять образ памяти и клонировать систему подменив все ключи или вручную валидировать каждый пакет из хоста подменяя память, если уж понадобиться…
                  +1
                  В тексте не написано главное: речь про внутренний трафик организаций для целей аудита и управления пакетами. Речь не про «путь пакета в интернете», а исключительно про интранет.

                  Идея с одной стороны интересная, с другой стороны, ну вы себе представляете нормальный сервер (допустим, раздающий артефакты по http), у которого каждый пакет имеет такую штуку? Всё взорвётся на первом же apt-get dist-upgrade с такого сервера.

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

                  Самое читаемое