Кратко

  • RFC 1441 представлял SNMPv2 как семь взаимосвязанных областей, включая административный фреймворк, который задавал смысл аутентификации и авторизации оболочки. «Версия 2» называла архитектуру, а не неделимый протокол.
  • Исходная схема с parties не стала долговременным путём внедрения. RFC 1901 соединил новые PDU с прежним механизмом communities; новое значение версии различало грамматику, но не обеспечивало сильную защиту.
  • RFC 3411 формально разделил обработку сообщений, безопасность и контроль доступа. Один движок может поддерживать несколько моделей, поэтому оператору нужна ведомость фактической сборки, а не вывод из номера.

Соседние байты отвечали на разные вопросы

Оболочка SNMPv2c содержит целое версии, строку community и PDU. Поскольку перечисление начинается с нуля, ноль обозначает SNMPv1, а единица — SNMPv2c. Это инструкция декодеру, а не естественный порядковый номер поколения.

Community относится к унаследованному администрированию. PDU задаёт чтение, запись или уведомление. Близость полей не делает их общей гарантией. Версия не аутентифицирует источник, корректная операция не даёт права, а ответ не доказывает внешний результат.

В этой странности сохранился след нелинейной миграции. Одни части SNMPv2 продолжили путь, другие потеряли согласие, третьи были заменены старой конструкцией. Название оказалось устойчивее собственной сборки.

RFC 1441 описывал карту фреймворка

Опубликованная в апреле 1993 года и ныне Historic, карточка RFC 1441 называет предмет вторым фреймворком стандартного сетевого управления Интернета. Главное слово здесь — «фреймворк».

Текст RFC 1441 выделял семь частей. SMI определяла описание управляемых объектов. Textual Conventions уточняли смысл типов. Protocol Operations задавали PDU, Transport Mappings — способы переноса. Instrumentation описывала поведение сущностей. Административный фреймворк определял аутентификацию и авторизацию. Conformance Statements различали нижнюю планку и реализованные возможности.

Одна часть не доказывала остальные. Определение MIB не выбирало транспорт. Достижимый адрес не выдавал разрешение. Правильная PDU не удостоверяла отправителя. Заявленная возможность не подтверждала активную конфигурацию на данном устройстве.

Форма и значение оболочки, согласно RFC, определялись административным фреймворком. Следовательно, Get и Set были глаголами, а не полномочиями. Кто отправил запрос и какие объекты ему доступны, решалось отдельно.

Изначальный контекст обеспечивали parties

В проекте 1993 года SNMPv2 party была виртуальным контекстом исполнения, ограниченным административно заданным подмножеством операций сущности. С каждой party связывались один протокол аутентификации и один протокол конфиденциальности; свойства представляла Party MIB.

Это не было украшением в приложении к PDU. Контекст должен был превращать синтаксическую операцию в административно осмысленное действие. Замена оболочки и party меняла историю идентичности и прав, даже если PDU продолжала называться SNMPv2.

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

SNMPv2c соединил новое со старым

В январе 1996 года RFC 1901 определил community-based SNMPv2. Он не упрощал parties, а вернул административный фреймворк SNMPv1, связал каждое сообщение с community и поместил в оболочку новые PDU и коды ошибок.

Значение версии стало 1, поскольку новые типы и ошибки требовали правильных правил разбора. Это было важное различие формата, но не превращение строки community в сильную аутентификацию.

Расширенные счётчики, bulk-получение, подтверждаемые уведомления, богатые ошибки и улучшенные операции со строками сохраняли ценность. Их выживание не означало выживания исходной административной модели. Модульность сохранила инвестиции и одновременно лишила ярлык v2 однозначной связи с безопасностью.

Статус документа и работающий код разошлись

Ретроспектива IETF 2002 года RFC 3410 относит party-based SNMPv2p к 1993–1995 годам. Более поздний SNMPv2 не имел собственного стандартизованного фреймворка безопасности и администрирования. SNMPv2c получил наибольшую поддержку, но не имел этих функций; защищённые варианты не получили консенсуса.

Когда безопасность и администрирование SNMPv3 достигли статуса Standard, SNMPv1 и экспериментальный SNMPv2c объявили Historic из-за фундаментальной слабости открытых строк communities. Остальные варианты были историческими либо не входили в стандартизационный процесс.

Тем не менее документ ожидал продолжения реализаций, говорящих на v1 или v2c вместе с v3. Процесс IETF не управляет решениями поставщиков и пользователей. Статус текста, рекомендация и работающий код принадлежат разным слоям реальности.

Historic не означает отсутствие. Доступность не означает безопасность. Ответ v2c подтверждает действующий путь, но не современную рекомендацию. Изменение каталога не доказывает, что community-доступ выключен на всех интерфейсах.

Версия стала входом диспетчера

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

Он различил фреймворк, модель и реализацию: фреймворк собирает подсистемы, модель описывает конкретный дизайн подсистемы, реализация воплощает одну или несколько моделей. В документе прямо сказано: SNMPv2 не имеет определения сообщения; SNMPv2c добавляет формат, похожий на v1.

Поле версии обычно определяет Message Processing Model. Движок может поддерживать несколько. Безопасность сообщения занимается аутентификацией, шифрованием и своевременностью. Контроль доступа отдельно решает, допустима ли операция над управляемым объектом. Несколько Security Models тоже могут сосуществовать.

Начальная цифра — координата для диспетчера, а не подписанное резюме защиты. Даже SNMPv3 не доказывает, что конкретный обмен применял аутентификацию и конфиденциальность: нужны выбранные модель и уровень.

Ведомость компонентов честнее столбца версии

Значения v2c или v3 удобны для поиска, но слишком грубы для подтверждения миграции. Один движок отвечает на разные версии, старый интерфейс может сохранять community, а новый канал — применять сильную модель; права меняются с субъектом и контекстом.

Надёжная запись разделяет транспортную точку, распознанную модель обработки, модель и уровень безопасности, заявленную или удостоверенную идентичность, контекст, контроль доступа и разрешённое представление, затем PDU, ответ и независимое наблюдение результата.

Идентификатор запроса связывает их, но не делает заменяемыми. Версия не доказывает субъекта. Субъект не доказывает права на объект. Разрешение не доказывает изменение устройства. Успешный ответ не доказывает сохранение после перезапуска.

Комплект RFC 1441 не уцелел целиком, зато его разделение позволило полезным моделям информации и операций пережить неудачу одной административной схемы. Если компоненты живут выборочно, доказательства также должны называться по компонентам.

Источники

  • Карточка и текущий статус RFC 1441.
  • Введение во фреймворк RFC 1441.
  • Community-based дополнение RFC 1901.
  • История применимости и стандартизации RFC 3410.
  • Модульная архитектура RFC 3411.