SNMP v3的发展及其主要技术.docx

SNMP v3的发展及其主要技术.docx

《SNMP v3的发展及其主要技术.docx》由会员分享，可在线阅读，更多相关《SNMP v3的发展及其主要技术.docx（15页珍藏版）》请在冰豆网上搜索。

SNMPv3的发展及其主要技术

SNMPv3的发展及其主要技术

华中师范大学计算机系钟义杰陈晓明谢双一肖德宝

随着Internet在全球范围内的飞速增长,如何管理和监视这个全球网络成为越来越重

要的研究课题。

在Internet的管理框架中,简单网络管理协议SNMP（SimpleNetworkMan

agementProtocol）扮演了主要角色,它是TCP/IP协议家族的重要成员。

本文在追踪国际

上有关网络管理最新动态的基础上,着重讨论SNMPv3的最新发展,包括SNMP的历史及发展

现状、SNMPv3的框架结构、SNMPv3的报文处理（MessageHandling）和SNMPv3的PDU处

理（PDUHandling）。

SNMP的历史与现状

1.SNMP的诞生

早在十年前,负责Internet标准化工作的国际性组织IETF（InternetEngineeringT

askForce）意识到单靠人工是无法管理以爆炸速度增长的Internet。

于是经过一番争论

最终决定采用基于OSI的CMIP（CommonManagementInformationProtocol）协议作为In

ternet的管理协议。

为了让它适应基于TCP/IP的Internet,大量的繁琐的修改是必须的,

修改后的协议被称作CMOT（CommonManagementOverTCP/IP）。

但CMOT的出台遥遥无期,

为了应急,IETF决定把现有的SGMP（SimpleGatewayMonitoringProtocol）进一步开发

成一个临时的替代解决方案。

这个在SGMP基础上开发的临时解决方案就是著名的SNMP,它

有以下特点:

·简单性:

顾名思义,SNMP非常简单,容易实现且成本低;

·可伸缩性:

SNMP可管理绝大部分符合Internet标准的设备;

·扩展性:

通过定义新的"被管理对象"即MIB,可以非常方便地扩展管理能力;

·健壮性（Robust）:

即使在被管理设备发生严重错误时,也不会影响管理者的正常工

作。

SNMP出台后,在短短几年内得到了广大用户和厂商的支持。

在实践中,它确实显示出

能管理绝大部分与Internet相连的设备的强大能力。

现今的数据通信设备生产厂家都把

他们的产品缺省地兼容SNMP。

由此可见,SNMP是在当时出现的恰当的解决方案（therigh

tsolutionattherightmoment）。

无论是谁,即使是IETF自己也没有预料到SNMP会如此成功,以致于1992年取消了用CM

OT代替SNMP的原定计划,这正是"有心栽花花不发,无意插柳柳成荫"。

SNMP已经成为Inte

rnet网络管理的最重要的标准。

初版简单网络管理协议具体内容可参看以下的SNMPv1的

RFC文本:

RFC1140-IABOfficialProtocolStandards

RFC1147-ToolsforMonitoringandDebugging

TCP/IP

InternetsandInterconnectedDevices

[supercededbyRFC1470〗

RFC1155-StructureandIdentificationofMan-

agement

InformationforTCP/IPbasedinternets.

RFC1156（H）-ManagementInformationBase

Network

ManagementofTCP/IPbased

internets

RFC1157-ASimpleNetworkManagement

Protocol

RFC1158-ManagementInformationBaseNetwork

ManagementofTCP/IPbased

internets:

MIB-II

RFC1161（H）-SNMPoverOSI

RFC1187-BulkTableRetrievalwiththeSNMP

RFC1212-ConciseMIBDefinitions

RFC1213-ManagementInformationBasefor

NetworkManagementof

TCP/IP-basedinternets:

MIB-II

RFC1215（I）-AConventionforDefiningTrapsfor

usewiththeSNMP

RFC1224-TechniquesforManaging

Asynchronously-GeneratedAlerts

RFC1270（I）-SNMPCommunicationServices

RFC1303（I）-AConventionforDescribing

SNMP-basedAgents

RFC1470（I）-ANetworkManagementToolCatalog

RFC1298-SNMPoverIPX（已作废,见RFC1420）

RFC1418-SNMPoverOSI

RFC1419-SNMPoverAppleTalk

RFC1420-SNMPoverIPX（被RFC1298代替）注:

H即historic历史的,已作废;I即

informational非正式的。

2.第二版简单网络管理协议SNMPv2

SNMP如同TCP/IP协议簇的其他协议一样,并没有考虑安全问题,因此许多用户和厂商

提出了修改初版SNMP、增加安全模块的要求。

于是,IETF于1992年雄心勃勃地开始了SNM

Pv2的开发工作。

它宣布计划中的第二版将有以下改进:

·提供验证、加密和时间同步机制,提高安全性;

·GETBULK操作提供一次取回大量数据的能力,用更有效的方式传递管理信息;

·建立一个层次化的管理体系。

增加Manager-to-Manager之间的信息交换机制,从

而支持分布式的管理体系;增加中级（子）管理者（Middle-LevelManagerorSub-Manage

r）,分担主管理者的任务,增加远程站点的局部自主性。

1993年,SNMPv2成为提案标准（proposedstandard）,即RFC14xx系列,此时有多个研

究小组开始建造SNMPv2原型系统的项目。

在实施过程中,他们发现SNMPv2比人们原先的

预想复杂多了,失去了Simple的特点。

1994年,当一个问题摆在IETF面前,即是否有足够多

的支持使SNMPv2升级成为草案标准（DraftStandard）时,一场关于SNMPv2复杂性的大讨

论轰轰烈烈地开始了。

讨论的焦点集中在所谓的可管理的模型上面,即实现SNMPv2安全

模型的数据应该怎样被管理。

在这个模型中,引入了"Parties"和"Context"的概念,它们

标识了在每个要发送的报文中应该包括的内容。

在如何实现这个模型的问题上,出现了两

种不同意见,即通常所说的SNMPv2*和SNMPusec（SNMPv2u）。

双方各持已见,任何一方都

没有足够的支持成为下一版标准,当开发计划的结束时间到来时,IETF只好把几乎所有与

安全相关的内容从SNMPv2中去掉,从而形成现在看到的最终的SNMPv2草案标准,即RFC

19xx系列。

SNMPv2中最初没有报文的定义,后来又出现了SNMPv2C（Community-based

SNMPv2）作为SNMPv2的补充,它增加了v2的报文定义,但与v1的报文非常类似。

SNMPv2的开发最终还是失败了,IETF解散SNMPv2工作组,决定把统一SNMPv2*和SN

MPv2u的工作留给SNMPng（nextgeneration）即现在的SNMPv3去做。

第二版简单网络管理协议具体内容可参看以下SNMPv2的RFC文档:

HistoricalStandard（历史的RFC14xx系列提案标准）:

RFC1441-IntroductiontoSNMPv2

RFC1442-SMIForSNMPv2

RFC1443-TextualConventionsforSNMPv2

RFC1444-ConformanceStatementsforSNMPv2

RFC1445-AdministrativeModelforSNMPv2

RFC1446-SecurityProtocolsforSNMPv2

RFC1447-PartyMIBforSNMPv2

RFC1448-ProtocolOperationsforSNMPv2

RFC1449-TransportMappingsforSNMPv2

RFC1450-MIBforSNMPv2

RFC1451-ManagertoMangerMIB

RFC1452-CoexistencebetweenSNMPv1and

SNMPv2

DraftStandard（RFC19xx系列草案标准）:

RFC1902-SMIforSNMPv2

RFC1903-TextualConventionsforSNMPv2

RFC1904-ConformanceStatementsforSNMPv2

RFC1905-ProtocolOperationsforSNMPv2

RFC1906-TransportMappingsforSNMPv2

RFC1907-MIBforSNMPv2

RFC1908-CoexistencebetweenSNMPv1

andSNMPv2

ExperimentalStandard（实验提案）:

RFC1901-IntroductiontoCommunity-based

SNMPv2

RFC1901-AnAdministrativeInfrastructure

forSNMPv2

RFC1910-User-basedSecurityModelfor

SNMPv2SNMPv3的框架结构

1.SNMPv3现状

尽管SNMPv2的开发结束了,但人们对安全的需求仍然存在。

1997年4月,IETF成立了

SNMPv3工作组,决心完成v2未完成的事业。

v3将统一v2*和v2u中的概念和技术思想,并不

考虑增加新的功能,而是回到SNMPv1Simple的老路上,他们的目标是:

·尽量利用现有的成果,尤其是v2*和v2u;

·达到SET安全标准的要求;

·尽可能简单;

·支持大规模的网络;

·定义一个可以长久使用的框架;

·尽量使之沿着标准化的大道前进。

SNMPv3工作组的工作重点是安全、可管理的体系结构和远程配置。

他们计划于199

8年4月提交所有的说明书给IESG以成为提案标准（proposedstandard）。

2.SNMPv3的框架结构

SNMPv3的协议文本集框架如图1所示:

@@0236000.JPG;图1SNMPv3的协议文本集@@

在图1中,标注了"*"的文本表示现在还未写,准备将来其它文本完成后才动笔,它们是

:

DocumentRoadmap文本路标,用来指示文本变化状况;ApplicabilityStatement适用性

声明,用来说明SNMPv3的适用环境;CoexistenceandTransition共存与过渡,用来说明

SNMPv3如何与v1、v2及其它版本的共存与过渡问题。

在报文处理模块中,传输映射文本定义了SNMP报文在传输过程中的映射关系,它沿用

了v2的RFC1906,未作变动;报文处理与调度文本定义了报文格式和MIB模块,在其中SNMP

v3定义了一种全新的报文格式以适应安全管理的需要。

安全文本描述SNMPv3中的安全模

型以及这个模型所对付的安全威胁、它的目标、所用协议、用于安全管理的MIB模块,它

还允许报文级别的安全参数的远程配置,如密码的远程修改。

在PDU处理模块中,访问控制文本说明了如何决定是否允许访问一个被管对象,它还定义了一个MIB块,用来远程配置访问控制的策略;协议操作文本定义了关于处理PDU的协议操作;应用程序文本定义了支持这些协议操作的应用程序。

在信息模型这个模块中,SMI管理信息文本定义MIB的结构;正文规范文本定义供SMI使用的新类型;一致性声明文本说明了可接受的最低限度的实现和实际中取得的实现。

在MIB模块中,SNMPv3可使用各种不同格式的MIB。

信息模型和MIB模块实际还是使用以前的协议文本,SNMPv3并未作任何改动。

而真正改动体现在报文处理和PDU处理两大模

块中,它们大量采用SNMPv2历史版本RFC14xx中的概念和技术思想。

最终实现的SNMPv

3将只涉及到安全。

其余部分仍沿用以前版本的定义（主要是RFC19xx系列的SNMPv2）。

3.SNMPv3与安全管理

SNMPv3相对于v2（RFC19xx系列）主要增加了安全特性。

在网络管理系统中,常见的

安全威胁有如下几种类型:

·修改信息（ModificationofInformation）:

某些非授权的SNMP实体可以对传输过

程中的由合法的SNMP实体产生的报文进行修改,用这样的方法来进行非授权的管理操作（

如修改某个对象的值）,因此,协议应该能够验证收到的报文是否在传输过程中被修改过。

·伪装（Masquerade）:

没有授权的用户可能冒充别的合法用户的身份识别（identit

y）来取得授权,因此,协议应该能够验证报文发送者的真实性。

·报文流的改变（MessageStreamModification）:

由于SNMP是基于无连接的UDP之

上的,报文的延迟、重发以及顺序的改变都是可能的。

某些破坏者可能会故意将报文延迟

重发以及改变报文流的顺序以达到破坏目的。

·泄密（Disclosure）:

破坏者可能会截获传输中的报文,窃取其中的保密内容。

要对付以上的安全威胁,实现安全的管理,通常经由以下两个阶段:

·传送/接收报文的过程

·在处理报文内容的过程

这两个阶段分别对应于报文处理和PDU处理模块,因此在SNMPv3中的安全是指在报文

级别实现的安全,而访问控制则对应于在协议操作级别实现的安全。

由两者共同实现安全

的管理框架。

SNMPv3的报文处理（MessageHandling）

1.报文处理

在SNMPv3中,通过对报文的处理来完成实体间的服务。

它描述了这样几个子系统:

调度子系统、报文处理子系统、安全子系统。

图1显示出了报文处理模块的结构框图。

@@0261700.JPG;图1报文处理模块的结构@@

图1中,调度者（Dispatcher）是SNMP引擎中一个关键的部分,每个引擎中只有一个调度者。

它的功能是由它的3个模块所决定的,即调度PDU给各种应用程序;调度任务能够解决多种报文版本的报文处理子系统;同时还定义了SNMP和传输之间的映射。

对于这个子系统来说,当它发送和接收SNMP报文时,收集关于SNMP报文的统计信息和被管对象中的engine的行为,使它们能够访问远程实体。

报文处理子系统（messageprocessingsubsystem）是引擎的一部分。

它定义了报文格式和MIB模型。

该子系统由不同的版本报文处理模块所组成,且这几种模块相互独立。

一个引擎可包含一个或多个报文处理模块。

该系统与调度子系统相联系,用于支持发送和接收SNMP报文的多版本。

由图1可以看出,发送一个报文,首先应用程序发出一个PDU,再加上构成一个报文的其它数据单元,由调度模块将这个报文传送给所对应的版本报文处理模块进行处理,并且通过安全模块的安全检查之后,报文就形成了。

这样,通过传输映射将该报文发送出去。

对于接收过来的报文,大体上就是其逆过程。

2.报文格式

对待一个SNMPv3的报文,它有如下的格式:

@@0261701.JPG;表1@@

其中,msgVersion字段的值被设成snmpv3（3）,用来标识SNMP的版本号为v3。

而msgGlobalData又由四部分组成:

SmsgID（0～231-1）:

用在两个SNMP实体间来协同请求报文和回答该请求,以避免使用其它任何未完成的变量作为msgID。

这样可以防止重发。

通常来说,设定msgID的值的策略是用SNMPEngineBoots的低段作为msgID的高段,而msgID的低段则单调增长其值。

msgMaxsize（484～231-1）:

表示发送报文所能支持的最大报文长度。

msgFlags（一个字长）:

用来表示其发送的报文的安全等级（LoS）。

msgSecurityModel:

由于v3的报文子系统支持用于提供安全服务的多个安全模块并发存在,这个字段被发送者用来标识使用哪个安全模块来处理产生或接收的报文。

msgSecurityParameters（字串）:

用于在发送和接收报文中安全模块间的通信。

该字段的数据归安全模块所独用,并且其内容和格式由安全模式所定义。

msgData字段可以是一段明文或一段字串所组成的密码文。

采取哪种方式取决于msgFlags中所定义的安全等级。

如果是一段明文,则由contextID、contextname和一段数据所组成,contextID用来标识目标实体的引擎号,而contextname则被本地处理模块LPM（Localprocessingmodule）所使用。

在实际的应用中,报文常常有不同的类型,它们是:

request、inform、Response、Trap和Report,另外,在SNMPv3中,对于无论是接收还是发送报文时,通常使用sendPDUHandle这样的句柄来完成子系统间的任务的处理。

3.报文的安全处理

上面谈到了对报文安全检查的处理。

实际上,安全检查指的是两个不同的阶段,一是

对报文的传送和接收的安全考虑,另一个是指对报文内容处理时的安全。

这两个阶段在S

NMPv3中由不同的模块所完成,前者是由常说的安全模块,即USM（user-basesecuritym

odel）模块所处理,后者是由LPM模块（Localprocessingmodel）所处理。

现在先谈谈基于

使用者模块的安全处理。

众所周知,在网络中存在着不同程度的安全威胁。

基于这些安全威胁问题和相对于v

2等版本的兼容性,SNMPv3对于安全所提出的目标是:

S保证每个接收的报文在网络的传送中不被修改,提供验证;

S提供接收报文用户的身份证明;

S防止泄密;

S保证所接收的SNMP报文的当前性。

对于这些目标的设计,一种缺省的安全处理模块是USEC模块,它能够提供验证和加密

功能,目前,SNMPv3所默认的验证协议是HMAC-MD5和HMAC-SHA,加密协议是CBC-DES。

为了

保证所传送的报文的有效性,常有三个过程,首先一个是由验证模块对报文进行的验证;由

时间模块对报文进行时戳处理;由保密模块进行报文加密。

一个接收的报文进行安全检查

示意图如图2所示:

@@0261702.JPG;图2接收报文的安全检查示意图@@

图2中,三个过程的选择依赖于其安全等级（LoS）,由图2可以看出,LoS有三个选择:

使用验证、时间同步和加密机制;

使用验证和时间同步机制;

不进行任何机制检查。

这三种情况的LoS由所处理的报文中msgFlags字段所定义选择。

msgFlags最低bit位

为1表示实行验证机制,次低bit位为1表示实行加密机制。

另外,这三个机制所实行的安全

服务功能着重点也不一样。

图3示出了三种不同的机制情况。

@@0261703.JPG;图3三种不同的机制情况@@

对于验证模块,它包含与验证有关的信息,否则为Null,利用算法计算出一个验证用的

密钥,在处理发送出去的报文时,指针移到报文中需要插入验证参数的地方,通过验证算法

查询到有关该用户姓名和引擎Id的密钥,填入该报文。

这个密钥长为128bit。

接收报文时

首先将这个密钥从报文中提出来,然后重新生成一个新密钥,比较两个密钥是否相同从而

达到验证的目的。

对于时间同步模块,为了保证报文不被重发,延迟和改发,SNMPv3中常把涉及通信的

一方引擎认为是授权的SNMP引擎.当一个报文包合一个期望得到回答的有效载荷时,报文

的接收者被认为是授权的引擎（如Get、Set）,否则把其发送者认为不是授权的（如Trap、

Response）。

在这种设定的基础上,每个SNMP引擎包含三个object:

SnmpEngineId,SnmpE

ngineBoots和SnmpEngineTime,每个引擎在它自已的实体中总是认为是授权的,而那些非

授权的引擎必须与那些授权的SNMP引擎同步。

SnmpEngineBoots和SnmpEngineTime结合

起来提供其引擎的时间指示,确保时间变量在其时间窗口中是当前时间。

对于加密模块,为了保证数据有效,需要加密算法,常常对其报文中的scoped-PDU进行

加密。

并且通过一个秘密的值和时间变量（即SnmpEngineBoots和SnmpEngineTime）结合起

来创建一个加密密钥和一个初始化向量。

这个秘密的值由那些授权的SNMP引擎所共享。

三个模块具体工作过程如图4所示:

@@0261704.JPG;图4三个模块具体工作过程@@

对于另外一个阶段,即LPM模块的安全处理,通过对contextname、groupname和LoS对

所管理的信息控制其访问权利。

经过这一系列的检查后,报文将返回调度模块,经过传输映射,将这报文形式映射到传

输层的格式。

SNMPv3的PDU处理（PDUHandling）

由SNMPv3框架所知,一个SNMPv3引擎由四个部分组成:

一个调度者（dispatcher）,报

文处理子系统,安全子系统和访问控制子系统。

SNMPv3利用他们提供的服务来完成PDU的

操作,其中访问控制子系统负责检查某一个访问对于一个特定管理对象是否被允许,出于

以上的考虑,IETF的SNMPv3工作组对于访问控制子系统,设计了一个特别定义的模块:

基

于视图的访问控制模块（view-basedAccesscontrolModel1）,该模块通常对一个SNMP管

理单元在处理SNMP的取回或修改请求报文申请时,进行访问控制,此外,当有一个证实报文

产生时（如InformRequest报文）和SNMPv2-Trap报文时,也必须进行访问控制。

访问控制

模块为SNMPv3的应用程序定义了一组服务调用接口和元素,用来检查访问权限。

（1）本地配置数据库（LCD）中

为了对一个管理实体（SNMPentity）进行访问控制,就必须将其访问权限和策略放在

一个数据库中,通常将其放在SNMP引擎的本地配置数据库（LCD）中;另外,为了对本地设备

数据库（LCD）进行设置,把LCD与一个管理对象同等看待,并可被访问。

（2）