Кратко

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

Четыре вопроса в одном ответе

Пользователь просит именованный фрагмент записи лекции. Ближайшая пригодная копия уже находится в Content Store маршрутизатора. Исходный сервер в этой выдаче не участвует, а потребителю не нужно знать адрес машины, которая сохранила копию. Пакет Data возвращается по состоянию, созданному пакетом Interest.

Для сети, построенной вокруг адресов, эта картина похожа на потерю гарантии. Почему доверять содержимому, если оно пришло не по новому соединению с ожидаемым хостом? Named Data Networking, или NDN, отвечает не новым универсальным знаком доверия, а отказом заставлять один признак выполнять четыре разные задачи.

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

Именно в таком разделении состоит значение работы Lixia Zhang. Согласно её биографии UCLA, с 2010 года она руководит проектированием и разработкой межуниверситетского проекта NDN. Это явно коллективная архитектура, а не одиночное изобретение. Роль Zhang заключалась в том, чтобы сохранять исследовательскую программу, где адресованный конечному узлу пакет рассматривался не как закон природы, а как инженерный выбор.

От «где» к «что»

Статья 2009 года «Networking Named Content» начинается с несоответствия. Люди ценят сеть за доступное содержание, но сама сеть продолжает описывать разговоры между машинами. Приложению приходится сначала переводить желаемое «что» в адресное «где».

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

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

В 2014 году «Named Data Networking» описала переход как новую узкую талию архитектуры. Общая служба IP доставляет пакет на адрес назначения. Предлагаемая служба NDN получает данные, определённые именем. Потребитель помещает имя в Interest, маршрутизаторы направляют его к возможным производителям, а первый узел с подходящими данными возвращает Data с именем, содержимым и подписью производителя.

Адреса источника и назначения этому обмену не нужны. Маршрутизаторы сохраняют состояние ожидающих Interests, по нему возвращают ответ и могут оставить пакет для следующих запросов. Сервер не исчезает: кто-то производит данные, хранит ключи и делает имена достижимыми. Исчезает лишь требование заново устанавливать сквозное соединение с той же машиной при каждом доверенном получении.

Подпись — не вердикт

Слово «подписано» легко прочитать как «истинно». Однако корректная подпись не доказывает истинность утверждения, институциональное право подписанта, отсутствие более новой версии или доступность исходного производителя.

Действующая спецификация подписей NDN проводит эти границы явно. Простой SHA-256 защищает от неожиданного изменения, но не сообщает происхождение и не гарантирует исходный источник. Проверенная подпись с открытым ключом даёт сильные основания считать, что пакет создал заявленный производитель и что содержимое не изменилось. Но именно модель доверия приложения устанавливает, какой издатель может подписывать какое имя Data.

Поэтому работа 2014 года называет удобное управление доверием исследовательской задачей. Математического результата недостаточно: потребителю нужна норма, связывающая пространство имён ключей с пространством имён данных. Более поздняя работа о схемах доверия делает связь исполняемой. Шаблоны имён ограничивают, какие ключи подписывают какие данные, помогают находить сертификаты и удерживают ключ в узком диапазоне полномочий.

Аутентификация приближается к объекту. Полномочие не рождается из криптографии — оно становится проверяемой политикой.

Несвежий не значит недействительный

Кэш создаёт ещё одно смешение. Обязательно ли старые данные неверны? NDN разводит состояния. Спецификация Data определяет FreshnessPeriod: после этого срока узел помечает сохранённый пакет как несвежий. При этом данные остаются действительными; производитель лишь мог создать более новый вариант. В спецификации Interest флаг MustBeFresh запрещает хранилищу отвечать несвежей копией на данный запрос.

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

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

Имя как свобода и юрисдикция

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

Но свобода именования не нейтральна. Иерархия определяет агрегацию маршрутов, предсказуемость для потребителя, область совпадения правила доверия и организацию, которая выглядит владельцем префикса. Управление пространством имён вынесено за пределы базовой архитектуры, как управление адресами вынесено за пределы IP. «За пределы» не означает «неважно»: это граница, на которой институты должны принять решение, намеренно не принятое узким общим слоем.

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

Эксперимент важнее показателя внедрения

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

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

Исторический вклад Zhang — в сохранении этого вопроса: если данные можно получить откуда угодно, какие доказательства должны оставаться с ними, а какие решения обязан сознательно принимать получатель? NDN не отменяет доверие. Она показывает, где оно было спрятано.

Источники