Семейство стандартов SNMP

Семейство стандартов простого протокола управления сетями (Simple Network Management Protocol, SNMP) предназначено для управления сетями. Семейство определено сообществом проектирования Интернета (Internet Engineering Task Force, IETF) и является частью семейства стандартов Интернета.

О книге

Первоначальный автор — Anrie Nord.

Книга стремится познакомить со стандартами в области управления сетями, а также научить архитектурным принципам семейства стандартов SNMP. Архитектура рассматривается в рамках классификации сетевых программных архитектур^[1]. Описывается история развития стандартов и даются комментарии по причинам принятия новых версий SNMP.

Стандарты управления сетями

Помимо стандартов SNMP сообщества IETF есть стандарты, принимаемые международными органами стандартизации^[2]; вот крупнейшие из них:

Организация	Стандарты	Особенности
IETF	SNMP	Управление должно быть простым, ориентировано на переменные
ISO	CMIP, CMIS	Управление должно быть мощным, объектно-ориентированное
ITU-T	TMN	Определяется только архитектура
DMTF	WBEM, CIM	Управление сетями и системами, объектно-ориентированное
OMG	CORBA	Архитектура удалённых объектов

Ныне самым успешным семейством стандартов является SNMP^[2]; он лидирует по числу управляемых систем (агентов). Управляющие системы (менеджеры) обычно поддерживают множество стандартов, поэтому здесь сложно говорить о лидерстве SNMP. По количеству вложенных денег, возможно, лидирует Telecommunications Management Network (TMN).

Показательно проследить зависимость популярности стандартов от среды их применения. В локальных и глобальных сетях передачи данных, использующих Протокол интернета (Internet Protocol, IP) наиболее широко распространён стандарт SNMP. В системах учрежденческих автоматических телефонных станций (УАТС) и в публичных телефонных сетях наиболее часто используются проприетарные решения. В мобильных сетях в основном используются решения на основе стандартов Международной Стандартизационной Организации (ISO).

Почти все успехи SNMP связаны с особенностями процесса стандартизации в IETF:

Стандарты бесплатны и свободно распространяемы
Стандарты легко доступны в электронной форме
Быстрое развитие стандартов, продуманные этапы стандартизации
На всех этапах ведётся техническая экспертиза
Рабочие группы возглавляют технические, а не политические лидеры
Прототипы систем на основе стандартов демонстрируют их применимость

Задачи

Функциональные группы задач управления системами определены в стандарте ITU-T X.700:

Управление конфигурацией (Configuration Management)
Обработка ошибок (Fault Management)
Анализ производительности и надёжности (Performance management)
Управление безопасностью (Security Management)
Учёт работы (Accounting Management)

Семейство стандартов SNMP создано для решения задач обработки ошибок и анализа производительности и надёжности.

Обработка ошибок: выявление, определение и устранение последствий сбоев и отказов в работе сети^[3]. На этом уровне выполняется регистрация сообщений об ошибках, их фильтрация, маршрутизация и анализ на основе некоторой корреляционной модели.

Анализ производительности и надёжности: оценка на основе статистической информации таких параметров, как время реакции системы, пропускная способность каналов связи, интенсивность трафика в отдельных сегментах сети, вероятность искажения данных, коэффициент готовности служб сети. Результаты такого анализа позволяют контролировать соглашение об уровне обслуживания (Service Level Agreement, SLA).

Согласно идеологии SNMP, управление должно быть простым, пусть даже ценой потери мощности, масштабируемости и защищённости^[2]. Поэтому при разработке стандартов SNMP учитывались следующие условия:

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

История

Одной из самых первых инициатив по управлению сетями была инициатива ISO Open Systems Interconnection (OSI). Соответствующие группы по стандартизации инфраструктуры управления OSI (OSI Management Framework) были созданы в 1981 году.

К концу 1980-х годов сеть Интернет стала достаточно большой и потребовала стандартов управления. Однако группа ISO OSI была далека от завершения работ над семейством стандартов. Поэтому в 1987 году сообществом IETF было принято решение временно создать набор упрощённых стандартов управления в Интернете на основе наработок ISO OSI. Данные стандарты получили название Simple Network Management Protocol (SNMP). В дальнейшем предполагалось переключиться на стандарты ISO по мере их готовности. Таким образом, многие идеи SNMP были взяты из стандартов ISO:

Концепция «менеджер-агент»
Идея баз управляющей информации (Management Information Bases, MIBs)
Использование синтаксиса Abstract Syntax Notation One (ASN.1)
Часть терминологии

Другими проектом стандарта, на базе которого началась разработка SNMP, был проект простого протокола мониторинга шлюзов (Simple Gateway Monitoring Protocol, SGMP) сообщества IETF.

В дальнейшем в рамках ISO OSI было предложено много новых идей, в частности, объектно-ориентированный подход. Однако эти идеи уже не вошли в стандарты SNMP. Одно время IETF продолжала инициативу CMIP over TCP (CMOT), которая предполагала использование общего протокола управляющей информации (Common Management Information Protocol, CMIP) стека протоколов ISO OSI в стеке IETF TCP/IP. В 1992 году эта инициатива была прекращена в связи с успехом и распространённостью SNMP.

Стандарты SNMP продолжали развиваться на протяжении 1990-х годов. Основным направлением развития было совершенствование вопросов безопасности. Были разработаны следующие версии SNMP: SNMPv1, SNMPv2, SNMPv2c, SNMPv2u и SNMPv3. Их обсуждение будет продолжено в главе «Версии SNMP».

Архитектура

Архитектуру распределённой системы можно описать в терминах обрабатывающих элементов (или компонентов), соединяющих элементов (или соединителей) и элементов данных^[4]. Перечислим составные элементы системы управления SNMP^[5]:

Компоненты
- Агент
- Менеджер
Соединители
- Транспортный протокол
- Протокольные блоки данных (Protocol Data Units, PDU) и сообщения SNMP
Данные
- Управляющая информация MIB

Опишем подробнее и проанализируем архитектуру SNMP с позиции достижения поставленных перед SNMP целей. Для этого используем понятие архитектурного стиля сетевого программного обеспечения^[1]. Архитектурный стиль — это согласованный набор архитектурных ограничений, накладываемых на роли и особенности архитектурных элементов (компонентов, соединителей и данных) и отношений между ними, проявляющийся в любой архитектуре, которая удовлетворяет этому стилю.

Компоненты

Вначале поговорим об архитектурных компонентах. Архитектура SNMP предполагает построение системы управления по схеме «менеджер-агент», т. е. использование архитектурного стиля «клиент-сервер». Система SNMP содержит множество управляемых узлов, на каждом из которых размещается достаточно простой сервер — агент SNMP, а также, по крайней мере, один узел, содержащий сложного клиента — менеджера SNMP.

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

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

Более детальная классификация компонентов по ролям:

Менеджер
- Менеджер промежуточного уровня
- Система управления сетями
Агент
- Минимальный агент
- Прокси-агент
- Менеджер промежуточного уровня

Компоненты в SNMP обобщённо называются сущностями SNMP.

Данные

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

Скалярные переменные
Таблицы переменных

Схема данных описывается структурой управляющей информации (Structure of Management Information, SMI). Схема данных определяет, как выглядит управляющая информация, т. е. описывает её синтаксис. SMI базируется на Abstract Syntax Notation One (ASN.1).

Конкретные наборы управляющей информации для разных типов устройств, протоколов и т. д. описываются базами управляющей информации (Management Information Bases, MIBs). Базы MIB определяют, какая управляющая информация существует. Например, для устройства, поддерживающего IP, MIB описывает таблицу маршрутизации, флажок активации функции маршрутизации, число переданных и принятых пакетов, число ошибок различного характера и т. д.

Таким образом, каждое устройство содержит набор значений переменных, определённых в некотором количестве MIB, описанных по правилам SMI. Этот набор переменных и является данными, управляющей информацией для протокола SNMP.

Важным вопросом является именование переменных. В SNMP каждой переменный присваивается уникальный идентификатор объекта (Object Identifier, OID). Пространство имён OID является иерархическим и контролируется организацией по распределению номеров в Интернете (Internet Assigned Numbers Authority, IANA). Каждый компонент имени является числом. В текстовом виде имена записываются как десятичные числа, разделённые точками, слева направо. Числам могут быть поставлены в соответствие текстовые строки для удобства восприятия. В целом, структура имени похожа на систему доменных имён Интернета (Domain Name System, DNS).

Каждая MIB определяет набор переменных, т. е. определённую ветку дерева OID, описывающую управляющую информацию в определённой области. Например, ветка 1.3.6.1.2.1.1 (мнемонический эквивалент: iso.org.dod.internet.mgmt.mib-2.system) описывает общую информацию о системе. Опишем некоторые переменные из этой ветки:

sysDescr (1.3.6.1.2.1.1.1) — краткое описание системы
sysUpTime (1.3.6.1.2.1.1.3) — время с момента последнего перезапуска
sysName (1.3.6.1.2.1.1.5) — имя системы

Переменные и сведения об их типе определены также в MIB. А сами типы переменных — в SMI.

Помимо непосредственно данных, необходимо ввести операции над ними. Набор этих операций изменялся и расширялся по мере развития SNMP. Основными операциями являются:

Чтение переменной
Запись переменной
Чтение переменной, следующей за заданной переменной (требуется для просмотра таблиц переменных)

Более подробно операции над данными описаны ниже при обсуждении соединителей в архитектуре SNMP.

В целом, операции над данными в SNMP похожи на удалённую отладку некоторого приложения: состояние системы описывается неким набором переменных, которые можно просматривать и изменять.

Соединители

Для обмена данными между компонентами используются соединители. В случае SNMP в качестве соединителя используется протокол прикладного уровня Simple Network Management Protocol (SNMP), обычно работающий поверх стека протоколов UDP/IP. Современные стандарты SNMP разрешают использование и других транспортных протоколов.

Рассмотрим стек протоколов более подробно, указав привязку протоколов к Open Systems Interconnection Reference Model (OSI RM).

#	Протокол	Комментарий
7	SNMP	Сообщения, PDU, операции
6	ASN.1 BER	Кодирование данных
5	—	—
4	UDP	Транспорт между службами
3	IP	Связь между узлами сети

SNMP вводит свой протокол прикладного уровня. Имеются четыре версии данного протокола: SNMPv1, SNMPv2, SNMPv2c и SNMPv3. В процессе развития SNMP расширялись возможные операции, т. е. типы протокольных блоков данных (Protocol Data Units, PDUs), а также вводились новые форматы сообщений SNMP для обеспечения безопасности.

Сообщение SNMP содержит номер версии SNMP, информацию о безопасности и протокольный блок данных PDU, который характеризует выполняемую операцию и её параметры. Например, SNMPv1 описывает следующие PDU и соответствующие операции:

Get-Request — запрос на получение значений 1..N переменных
Get-Next-Request — запрос на получение значений 1..N переменных, чьи OID идут следом за OID указанных 1..N переменных
Get-Response — ответ на запросы Get-Request, Get-Next-Request и Set-Request
Set-Request — установка значений 1..N переменных
Trap — ловушка (см. ниже)

Описанные PDU, как уже упоминалось, являются частью сообщения SNMP. Сообщения кодируются для передачи по сети при помощи ASN.1 Basic Encoding Rules (BER). Это функция шестого уровня (уровня представления) эталонной модели OSI. Далее закодированные сообщения отправляются одним компонентом SNMP другому при помощи транспортного протокола.

Как уже отмечалось, стандарт предусматривает использование различного транспорта для SNMP, но почти что всегда используется протокол пользовательских датаграмм (User Datagram Protocol, UDP). Агенты используют хорошо известный порт UDP 161. Этот протокол предоставляет минимальные транспортные услуги (доставка сообщений от службы к службе и проверка контрольной суммы) и не предполагает организацию сеансов и потоковую передачу данных, как Transmission Control Protocol (TCP). За счёт этого удаётся добиться большой скорости реакции и быстродействия, что соответствует поставленным перед SNMP целям.

Для повышения скорости реакции менеджера на срочные события вводится специальный тип операции протокола SNMP, называемый «ловушка» (Trap). Он позволяет агентам асинхронно информировать менеджера (по собственной инициативе) о наступлении ограниченного числа значимых событий. В этом случае агент выступает в необычной для себя роли клиента, а менеджер — в роли сервера. В случае использования транспорта UDP для входящих соединений менеджер использует хорошо известный порт UDP 162.

Как мы видим, ни одна из этих операций не предполагает, что агент хранит информацию о сессии с менеджером. Для выполнения операции Trap такая информация хранится статически, т. е. сессия в таком случае статична и перманентна. Помимо этого операции SNMP определяют единые, унифицированные интерфейсы агентов и менеджеров SNMP. Таким образом, SNMP — это протокол без сохранения состояния, который соответствует архитектурному стилю «унифицированный многоуровневый клиент-сервер без сохранения состояния».

Опишем некоторые свойства операций SNMP на примере SNMPv1:

Имя	Безопасная	Подтверждаемая	Идемпотентная
`Get-Request`	1	1	1
`Get-Next-Request`	1	1	1
`Get-Response`	1	0	?
`Set-Request`	0	1	?
`Trap`	1	0	?

Таким образом, мы рассмотрели все основные архитектурные особенности SNMP, кроме моделей безопасности. Вопросы, связанные с защитой информации, будут рассмотрены ниже при обсуждении версий стандартов SNMP.

Соответствие архитектурному стилю REST

Архитектурный стиль REST — это унифицированный многоуровневый кэшируемый клиент-серверный стиль с кодом по запросу и без сохранения состояния (Unified-Layered-Code-on-Demand-Client-Cached-Stateless-Server, ULCODCСSS)^[1]. Как мы определили в результате анализа архитектуры SNMP, система SNMP определяется унифицированным многоуровневым клиент-серверным стилем без сохранения состояния (Unified-Layered-Client-Stateless-Server, ULCSS).

Как мы видим, на SNMP не накладываются ограничения, связанные с репликацией (наличие кэша) и мобильным кодом (применение кода по запросу). В этом смысле стиль SNMP — более свободный, чем REST, т. е. содержит меньше архитектурных особенностей, которые, например, необходимо учитывать при моделировании систем с такой архитектурой.

Однако, даже в SNMPv1 есть особая операция Trap, инициируемая агентом асинхронно по отношению к менеджеру. В SNMPv2 вводится операция Inform-Request, которая также выполняется асинхронно, но между двумя менеджерами. При выполнении таких операций клиент и сервер меняются ролями. При этом используется принцип интеграции на основе извещений. Это элементы однорангового стиля взаимодействия (Peer-to-Peer), хотя в данном случае роли клиента и сервера для конкретных типов протокольных операций выражены явно. В этом смысле стиль SNMP — более ограниченный, чем REST.

Таким образом, при определённых ограничениях система SNMP может быть рассмотрена как REST-овская распределённая система.

Структура стандартов

Стандарты SNMP описывают аспекты, отражённые ниже^[5]:

Общая информация
Обработка сообщений (SNMP Messages)
- Привязки к транспорту
- Разбор и диспетчеризация сообщений
- Безопасность (аутентификация, шифрование, своевременность)
Обработка протокольных блоков данных (SNMP PDUs)
- Операции протокола
- Приложения SNMP
- Управление доступом
Информационная модель
- Структура управляющей информации (SMI)
- Текстовые конвенции
- Выражения соответствия
Модули баз управляющей информации (MIB)

Изначально в стандартах выделялись не все эти аспекты. Тем не менее, структура стандартов SNMP всех версий вписывается в эту схему.

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

Среди важных аспектов, не рассмотренных при анализе архитектуры SNMP, остаётся информационная безопасность, описываемая в разделах «Безопасность» и «Управление доступом». Перейдём к рассмотрению этих вопросов.

Информационная безопасность

Рассмотрим, как учитываются в SNMP основные элементы информационной безопасности:

Конфиденциальность
Целостность
Доступность
Контролируемость

В ходе развития стандартов SNMP инфраструктура безопасности подвергалась наибольшим изменениям. Для того, чтобы проследить эти изменения, вначале опишем требования безопасности и угрозы, затем структуру моделей безопасности, после чего рассмотрим использующиеся в различных версиях SNMP модели.

Требования и угрозы безопасности

Опишем требования безопасности в архитектуре SNMP^[5]. Угрозами безопасности, против которых должна предоставлять защиту любая модель безопасности SNMP, являются:

Первичные угрозы
- Модификация информации
- Маскарад
Вторичные угрозы
- Модификация потока сообщений
- Разглашение

Угроза модификации информации — это возможность того, что некоторая неавторизованная сущность может изменить сообщения SNMP, сгенерированные по запросу авторизованного принципала, на пути их следования таким образом, что это приведёт к неавторизованным операциям управления, включая фальсификацию значения объекта (переменной).

Угроза маскарада — это возможность того, что операции управления, не авторизованные для некоторого принципала, могут быть предприняты при подстановке идентификатора другого принципала, для которого подобные действия авторизованы.

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

Угроза разглашения — это возможность прослушивания обменов сообщениями между сущностями SNMP. Защита от этой угрозы может требоваться локальной политикой безопасности.

Модель безопасности может не бороться с такими угрозами, как, например, отказ в обслуживании, т. к. состояние сетевых сбоев и ошибок (нормальное для SNMP) часто неотличимо от ситуаций отказа в обслуживании.

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

Структура моделей безопасности

Устоявшаяся структура моделей безопасности была описана в документе по архитектуре SNMP^[5]. Сущность SNMP содержит две подсистемы:

Подсистема безопасности
Подсистема управления доступом

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

Подсистема управления доступом функционирует на уровне SNMP PDU. Очевидно, что она отвечает за управление доступом к управляемым объектам (переменным). Документы, описывающие её, также определяют модуль MIB для удалённой настройки параметров.

Модели безопасности

Перечислим основные модели безопасности и соответствующие им инфраструктуры:

SNMPv1
- SNMPv1 — Community-based Security Model
SNMPv2
- SNMPv2p — Party-based Security Model
- SNMPv2c — Community-based Security Model
- SNMPv2u — User-based Security Model
SNMPv3
- SNMPv3 USM User-based Security Model

Модель безопасности на основе сообществ (Community-based Security Model) была первой, самой простой и самой небезопасной. Она подразумевает лишь аутентификацию на основе «строки сообщества», фактически, пароля, передаваемого по сети в теле сообщения SNMP в открытом тексте. Эта модель безопасности не в состоянии бороться ни с одной из угроз информационной безопасности в SNMP. Тем не менее, она часто используется до сих пор в связи со своей простотой, а также благодаря наличию внешних, не связанных с SNMP систем безопасности, например, межсетевых экранов.

Модель безопасности на основе сторон (Party-based Security Model) подразумевает введение понятие стороны. Сторона — это виртуальное окружение исполнения, в котором набор допустимых операций ограничен административно. Сущность SNMP при обработке сообщения действует как сторона, поэтому ограничена операциями, определёнными для этой стороны. Сторона определяется следующими параметрами:

Уникальный идентификатор стороны
Логический сетевой адрес (область адресов транспортного протокола и адрес транспортного протокола)
Протокол аутентификации и параметры, требующиеся для аутентификации всех сообщений стороны
Протокол шифрования и параметры, требующиеся для шифрования всех сообщений стороны

Могут использоваться различные алгоритмы для протоколов аутентификации и шифрования. Обычно в качестве алгоритма для протокола аутентификации используют хэш-функцию Message Digest 5 (MD5), а для протокола шифрования — алгоритм Data Encryption Standard (DES) в режиме Cipher Block Chaining (CBC).

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

Модель безопасности на основе пользователей (User-based Security Model) вводит понятие пользователя, от имени которого действует сущность SNMP. Этот пользователь характеризуется именем пользователя, используемыми протоколами аутентификации и шифрования, а также закрытым ключом аутентификации и шифрования. Аутентификация и шифрование являются необязательными. Их наличие описывается одним из параметров модели, качеством обслуживания (Quality of Service, QoS). Модель безопасности во многом похожа на модель на основе сторон, но она упрощает идентификацию пользователей, распределение ключей и проткольные операции.

Версии SNMP

Кратко опишем различия между версиями SNMP и документы, определяющие эти версии. Заметим, что здесь приведены первые версии RFC каждой из версий SNMP, т. е. почти все из них были замещены более новыми RFC и признаны устаревшими. По состоянию на 2006 год, единственной не устаревшей версией SNMP является SNMPv3, определённая в RFC 3411-3418.

SNMPv1

Первые RFC, описывающие стандарты SNMP, появились в 1988 году. Версия 1 подверглась критике за её посредственную модель безопасности на основе сообществ^[6]. В то время безопасность в Интернете не входила в круг первоочередных задач рабочих групп IETF.

Обработка сообщений
- RFC 1067. A Simple Network Management Protocol
Обработка PDU
- RFC 1067. A Simple Network Management Protocol
Информационная модель
- Структура управляющей информации
  - RFC 1065. Structure and Identification of Management Information for TCP/IP-based internets
Модули MIB
- RFC 1066. Management Information Base for Network Management of TCP/IP-based internets

SNMPv2

Версия 2, известная так же, как Party-based SNMPv2, или SNMPv2p, не получила широкого распространения из-за серьёзных разногласий по поводу инфраструктуры безопасности в стандарте.

SNMPv2 улучшал версию 1 в области быстродействия, безопасности, конфиденциальности и взаимодействий «менеджер-менеждер». Он представил новый тип PDU Get-Bulk-Request, альтернативу Get-Next-Request для получения больших объёмов информации при помощи одного запроса. Тем не менее, новая система безопасности на основе сторон выглядела для многих как чересчур сложная и не была широко признана.

Общая информация
- RFC 1441. Introduction to version 2 of the Internet-standard Network Management Framework
- RFC 1452. Coexistence between version 1 and version 2 of the Internet-standard Network Management Framework
Обработка сообщений
- Привязки к транспорту
  - RFC 1448. Transport Mappings for SNMPv2
- Безопасность
  - RFC 1445. Administrative Model for SNMPv2
  - RFC 1446. Security Protocols for SNMPv2
Обработка PDU
- Управление доступом
  - RFC 1445. Administrative Model for SNMPv2
- Протокольные операции
  - RFC 1448. Protocol Operations for SNMPv2
Информационная модель
- Структура управляющей информации
  - RFC 1442. Structure of Management Information SNMPv2
- Текстовые конвенции
  - RFC 1443. Textual Conventions for SNMPv2
- Выражения соответствия
  - RFC 1444. Conformance Statements for SNMPv2
Модули MIB
- RFC 1447. Party MIB for SNMPv2
- RFC 1450. MIB for SNMPv2
- RFC 1451. Manager-to-Manager MIB

SNMPv2c

Community-based SNMPv2, или SNMPv2c, представил SNMPv2 без новой модели безопасности версии 2. Вместо неё предлагалось использовать старую модель безопасности версии 1 на основе сообществ. Соответствующее предложение RFC было принято только как черновик стандарта, однако стало де факто стандартом SNMPv2. Безопасность SNMP снова оказалась нерешённым вопросом.

Обработка сообщений
- Безопасность
  - RFC 1901. Introduction to Community-based SNMPv2

SNMPv2u

User-based SNMPv2, или SNMPv2u, является компромиссом между незащищённостью SNMPv1 и чрезмерной сложностью SNMPv2p. Предложенная модель безопасности на основе пользователей была положена в основу SNMPv3.

Обработка сообщений
- Безопасность
  - RFC 1909. An Administrative Infrastructure for SNMPv2
  - RFC 1910. User-based Security Model for SNMPv2
Обработка PDU
- Управление доступом
  - RFC 1909. An Administrative Infrastructure for SNMPv2

SNMPv3

SNMPv3 наконец-то решил проблемы с безопасностью способом, который многие посчитали приемлемым. Версия 3 SNMP принята IETF как стандарт Интернета (IETF STD 62). Почти все предыдущие RFC признаны устаревшими.

Общая информация
- RFC 3411. An Architecture for Describing SNMP Management Frameworks
Обработка сообщений
- Привязки к транспорту
  - RFC 3417. Transport Mappings for the SNMP
- Разбор и диспетчеризация сообщений
  - RFC 3412. Message Processing and Dispatching for the SNMP
- Безопасность
  - RFC 3414. User-based Security Model (USM) for SNMPv3
Обработка PDU
- Операции протокола
  - RFC 3416. Version 2 of the Protocol Operations for SNMP
- Приложения SNMP
  - RFC 3413. SNMP Applications
- Управление доступом
  - RFC 3415. View-based Access Control Model (VACM) for the SNMP
Модули MIB
- RFC 3418. MIB for the SNMP

Блиц-сравнение с другими технологиями

SNMP похож на WBEM тем, что это семейство стандартов управления распределёнными объектами, построенное по схеме менеджер-агент.

SNMP похож на APP тем, что это почти REST-овский протокол, который использует стандартный транспорт (UDP и TCP, соответственно), что использует стандартный формат кодирования информации на 6 уровне OSI (обменивается скорее данными, чем командами: ASN.1 и XML), хотя и использует собственный прикладной протокол (SNMP и HTTP).

SNMP похож на ONC RPC тем, что оба используют метаязыки L0, L1, L2 для кодирования передаваемой информации на 6 уровне OSI (XDR Encoding и ASN.1 BER) и L2 для описания формата данных (XDR Language и ASN.1).

Ещё раз о метаязыках. Например, в программировании:

L0 — значения переменных Python, "12": 12
L1 — переменные Python, "i = 12; i": 12
L2 — классы Python, "type(i)": <type 'int'>
L3 — метаклассы Python, "type(type(i))": <type 'type'>

Например, в распределённых системах:

L0 — данные в RPC, данные в XDR Encoding
L1 — экземпляры переменных в RPC, описатели полей структур в XDR Encoding
L2 — типы данных в RPC, типы полей структур в XDR Encoding, типы XDR Language
L3 — типы типов RPC, формальная спецификация XDR Language

SNMP похож на HTTP тем, что вопросы интерфейса между приложениями в основном решаются на уровне сетевого API, т. е. на 7 уровне OSI, а не на уровне программного интерфейса (хотя последующие версии SNMP описывают абстрактный программный API).

Существующие реализации

Поддержка SNMP — во многих значимых системах управления сетями, в частности:

HP Network Node Manager
IBM Tivoli NetView
OpenNMS

Заключение

SNMP широко используется для управления сетями, особенно IP-сетями
Успех SNMP по сравнению с другими стандартами управления показывает преимущества процесса стандартизации IETF
История развития SNMP показывает важность задач защиты информации
Архитектура SNMP интересна как пример для анализа архитектуры сетевого программного обеспечения; она соответствует поставленным перед SNMP целям
Архитектура SNMP соответствует архитектурному стилю ULCSS сетевого программного обеспечения
В SNMP для решения функций 6 уровня модели OSI RM используется ASN.1, что необычно для стандартов IETF и положительно сказывается на вопросах формализации протоколов, однозначности стандартов, удобства проектирования приложений
Структура стандартов SNMP хорошо продумана и показательна как пример для изучения стандартов
Лишь некоторые модели безопасности SNMP отвечают поставленным перед системой безопасности SNMP целям
SNMP сравним со всеми объектами в мире, а в случае сетевых технологий 4-7 уровня OSI RM это к тому же имеет практический смысл и может иметь теоретический смысл
Агенты и менеджеры SNMP просты в программной реализации, однако всегда нужно помнить об информационной безопасности

Внешние ссылки

SNMP менеджеры
- Бесплатная система управления Polygon SNMP Manager на базе протокола SNMP
Общая информация по SNMP
- SNMP в Википедии
Изучение SNMP
- SNMP tutorials in Real format
- SNMP interactive exercises
Простые реализации SNMP
- Getif
- PySNMP
Сетевое программирование на Python
- Socket Programming HOWTO
- ASN.1 tools for Python
Для работы с SNMP

Примечания

↑ ^а ^б ^в Fielding R. T. Architectural Styles and the Design of Network-based Software Architectures. Ph. D. Dissertation. — University of California, Irvine. — 2000. http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
↑ ^а ^б ^в Pras A. Internet Management Protocols Course — University of Twente, 2000. http://www.simpleweb.org/
↑ Олифер В. Г., Олифер Н. А. Компьютерные сети. Принципы, технологии, протоколы. — СПб.: Питер, 2001
↑ Perry D. E., Wolf A. L. Foundations for the Study of Software Architecture // ACM SIGSOFT Software Engineering Notes. — 1992. — #17(4). — pp. 40-52
↑ ^а ^б ^в ^г Harringson D., et al. An Architecture for Describing SNMP Management Frameworks. IETF STD 62, RFC 3411. — 2002. http://www.ietf.org/rfc/rfc3411.txt
↑ Simple Network Management Protocol. — Wikipedia, The Free Encyclopedia. 2006-05-07 00:11Z http://en.wikipedia.org/w/index.php?title=Simple_Network_Management_Protocol&oldid=51905318

[fielding-1] а ^б ^в Fielding R. T. Architectural Styles and the Design of Network-based Software Architectures. Ph. D. Dissertation. — University of California, Irvine. — 2000. http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

[pras-2] а ^б ^в Pras A. Internet Management Protocols Course — University of Twente, 2000. http://www.simpleweb.org/

[3] Олифер В. Г., Олифер Н. А. Компьютерные сети. Принципы, технологии, протоколы. — СПб.: Питер, 2001

[4] Perry D. E., Wolf A. L. Foundations for the Study of Software Architecture // ACM SIGSOFT Software Engineering Notes. — 1992. — #17(4). — pp. 40-52

[snmp-arch-5] а ^б ^в ^г Harringson D., et al. An Architecture for Describing SNMP Management Frameworks. IETF STD 62, RFC 3411. — 2002. http://www.ietf.org/rfc/rfc3411.txt

[6] Simple Network Management Protocol. — Wikipedia, The Free Encyclopedia. 2006-05-07 00:11Z http://en.wikipedia.org/w/index.php?title=Simple_Network_Management_Protocol&oldid=51905318

[1]

[2]

[3]

[4]

[5]

[6]