1.介紹



一個網絡治理系統包含：幾個（可能是許多的）節點，每個都有一個名為代理

的處理實體。代理有到治理工具的通路；至少一個治理站點和一個治理協議，該協

議用于在代理和治理站點間傳遞治理信息。協議的實施是在一個定義了鑒定和認證

策略的治理體系下進行的。



網絡治理站點上運行監視和控制網絡元素的治理應用程序。網絡元素是諸如主

機，路由器，終端服務器等的設備，通過對它們的治理信息的訪問來監視和控制網

絡元素。



本文檔--<<SNMPv2的治理模型>>--的目的就是定義：在不同的配置和環境下，

治理體系是怎樣被用來實現實際的網絡治理的。



這里描述的模型使后面的要求成為必要：交換SNMPv2消息的對等實體使用唯一

的表示。所以，這里表現出與先前的SNMP[1]的基于社區的治理模型的不同。通過

對每個SNMPv2消息來源和預期的接收者的明白無誤的標識，這個新的策略改善了過

去的社區方案，它不僅支持一個更加方便的訪問控制模型，而且答應在將來對非對

稱公匙安全協議的有效運用。



1.1.術語的注解



為了便于說明，原先的Internet標準網絡治理體系（在RFC1155,1157和1212中

有描述）被叫做SNMP版本1體系(SNMPv1)。當前的體系叫做SNMP版本2體系(SNMPv2)。



2.模型的元素

2.1.SNMPv2參與者

SNMPv2參與者是一個概念性的，虛擬的執行環境，它的操作被限制在（出于

對安全性的考慮）一個特定SNMPv2實體的所有可能的操作的子集中（參考2.2），

該子集被治理性地定義。不論一個SNMPv2實體什么時候處理一個SNMPv2消息，它

都是以一個SNMPv2參與者的身份進行操作，因而它的操作就被限制在為這個參與者

定義的操作集合中。對這個參與者，其特定的可能的操作可能與其他參與者的操作

集合重疊或者不相關，它也可能是那個SNMPv2實體的所有可能操作的一個合適或者

不合適的子集。從協議體系上講，每個SNMPv2參與者包含：



? 一個唯一的，與眾不同的參與者標識。



? 一個邏輯網絡位置，參與者執行時所在的邏輯網絡位置稱為一個傳送協議的域，

并且傳送尋址信息。

? 一個專門的鑒定協議和相關的參數，所有那個參與者產生的協議消息通過他們

被鑒定為初始的和完整的。



? 一個專門的私有協議和相關參數，用來保護所有參與者接收的協議消息，防止

泄漏。



從概念上講，每個SNMPv2參與者可以用一個ASN.1值表示，符合下面的語法：

SnmpParty::=SEQUENCE{

partyIdentity

OBJECTIDENTIFIER,

partyTDomain

OBJECTIDENTIFIER,

partyTAddress

OCTETSTRING,

partyMaxMessageSize

INTEGER,

partyAuthPRotocol

OBJECTIDENTIFIER,

partyAuthClock

INTEGER,

partyAuthPrivate

OCTETSTRING,

partyAuthPublic

OCTETSTRING,

partyAuthLifetime

INTEGER,

partyPrivProtocol

OBJECTIDENTIFIER,

partyPrivPrivate

OCTETSTRING,

partyPrivPublic

OCTETSTRING

}



對于每個代表一個SnmpParty參與者的SnmpParty值，下列敘述是成立的：

o它的partyIdentity組件是參與者的標識



o它的partyTDomain組件稱作傳送域，并指明參與者用來接收網絡

治理通信量的那種傳送設備。一個傳送域的例子是snmpUDPDomain(在UDP上的

SNMPv2，使用SNMPv2參與者).



o它的partyTAddress組件稱作傳送尋址信息，代表一個參與者用

來接收網絡治理通信量的傳送設備的地址。



o它的partyMaxMessageSize組件稱作最大消息的尺碼，代表這個

參與者將要接收的最大SNMPv2消息的八位組的長度。



o它的partyAuthProtocol組件稱作鑒定協議，指明了一個協議和

鑒定所有該參與者生成的消息是初始和完整的機制。在這種上下文下，值noAuth表

明該參與者產生的消息未被鑒定為初始和完整。



o它的partyAuthClock組件稱作鑒定時鐘，代表與該參與者關聯的

當前時間。本組件的重要性是在鑒定協議中體現的。



o它的partyAuthPrivate組件稱作私有鑒定密匙，代表支持鑒定協

議所需的任何保密的值。本組件的重要性是在鑒定協議中體現的。



o它的partyAuthPublic組件稱作公有鑒定密匙，代表任何支持鑒

定協議所需的公共值。本組件的重要性是在鑒定協議中體現的。



o它的partyAuthLifetime組件稱作生命周期，代表該參與者生成

的協議消息的可以接受的傳送延時的治理性的上界。本組件的重要性是在鑒定協議

中體現的。



o它的partyPrivProtocol組件稱作私有協議，指明了一個協議和

一個防止該參與者接收到的所有協議消息泄漏的機制。在這種情況下，值noPriv

表明該參與者接收到的消息未被保護以防止泄漏。



o它的partyPrivPrivate組件稱作私有密匙，代表支持私有協議所

需的保密值。本組件的重要性是在私有協議中體現的。



o它的partyPrivPublic組件稱作公有密匙，代表支持私有協議所

需的任何公共值。本組件的重要性是在私有協議中體現的。



對于所有的被某個SNMPv2實體實現的SNMPv2參與者，假如它的鑒定協議是

noAuth而且它的私有協議是noPriv，那么那個實體稱作不安全的。



2.2.SNMPv2實體



一個SNMPv2實體是一個實際的處理者，它通過用[2]中指明的方式產生消息

并且/或者對SNMPv2協議消息進行響應來完成網絡治理操作。當一個SNMPv2實體以

一個特定的SNMPv2參與者的身份進行操作時，這個實體的操作必須限制在治理性地

定義在那個參與者上的所有可能的操作的子集中。



通過定義，一個SNMPv2實體的操作在一個特定SNMPv2參與者生成的任何單個協

議消息的處理和一個潛在的不同的SNMPv2參與者生成的任何其他協議消息的處理之

間不需要同時發生。相應地，一個支持超過一個參與者的SNMPv2實體的實現不需要

是多線程的。當然，也存在著實現時選用多線程的情況。



從協議體系上說，每個SNMPv2實體維護一個保存了它所知的所有SNMPv2參與者

的邏輯數據庫，這些參與者的操作有的是邏輯地實現的，有的是通過代理與遠地實

體地交互來實現的，有的是遠地實體實現的。另外，每個SNMPv2實體維護一個存有

該實體所知的所有被治理對象資源（參照2.8）。最后，每個SNMPv2實體維護一個存

有定義了針對已知的SNMPv2參與者的訪問權限的訪問控制策略信息的邏輯數據庫。



2.3.SNMPv2治理站點



一個SNMPv2治理站點是一個SNMPv2參與者在通過生成相應的SNMPv2協議消息來

初始化SNMPv2治理操作時，或者在它接收和處理陷阱通告時假定的運作性的角色。

有時，術語SNMPv2治理站點也指專注于操作角色的SNMPv2的部分實現（例如圖形工

作站）。這種SNMPv2的部分實現可能用來提供方便或治理設備的本地革新，但是它

們可能對代表遠地協議用戶的SNMPv2治理操作提供很少甚至沒有支持。



2.4.SNMPv2代理



一個SNMPv2代理是一個SNMPv2參與者在為響應收到的諸如一個SNMPv2治理站點

（參照2.3）生成的SNMPv2協議消息而進行SNMPv2治理操作時假定的操作性角色。

有時，術語SNMPv2代理也指專注于這種操作角色的SNMPv2（例如在嵌入式系統中）

的部分實現。這種部分實現對代表治理設備的遠地用戶的SNMPv2治理操作的實現提

供了支持，但是它可能對這些設備的本地革新提供很少甚至沒有支持。



2.5.視圖子樹



一個視圖子樹是所有名字有公共的ASN.1實體標識符前綴的治理信息庫對象的

集合。一個視圖子樹由OBJECTIDENTIFIER的值來標識，該值是該子樹中所有（潛在）

的類似的治理信息庫對象實例中最大的OBJECTIDENTIFIER前綴。



當標識一個視圖子樹的OBJECTIDENTIFIER前綴比根據SMI[3]定義的OBJECT

IDENTIFIER長時，用這個視圖子樹來控制訪問就會在對象實例層有梯度。這種梯度

在超越作為代理角色的SNMPv2實體的范圍之上來考慮。



所以，一個作為代理角色的SNMPv2實體的實現不需要支持在標識一個特定葉子

對象類型時有多于必要數目的子標識符的視圖子樹的值。然而，在決定哪一個作為

治理者角色的SNMPv2實體應該接收陷阱通知時，也用到了訪問控制信息。（4.2.6of

[2]）所以，為了使一個治理站點能使用合適粒度的陷阱通知配置，代理實現者可

能希望提供實例級的梯度。



2.6.MIB視圖



一個MIB視圖是根據SMI[3]（那就是，所有MIB對象的所有實例的通用集合）定

義的所有對象類型的所有實例的集合的子集：

o一個MIB視圖的每個元素用一個ASN.1OBJECTIDENTIFIER值唯一地

標識。所以，一個特定對象類型的完全相同命名的實例（例如在不同的代理中）必

須包含在不同的MIB視圖中。也就是，在一個特定的MIB視圖中，一個特定的對象實

例名字解析為最多一個對象實例。



o每個MIB視圖被定義為視圖子樹的一個集合。



2.7.代理關系



一個代理關系在下面情況下存在：為了處理一個接收到的治理請求，一個SNMPv2

實體必須和其他邏輯上遠地的實體通訊。一個用代理關系來處理治理請求的SNMPv2

實體叫做一個SNMPv2代理機構。

當一個邏輯上遠地的參與者和一個SNMPv2實體間的通訊是通過SNMPv2時（通過

任何傳輸協議），那個代理參與者稱作一個SNMPv2本地代理關系。SNMPv2本地代理

關系的部署是一種有利的手段，用它可以分期償還或輪換構建一個大的治理系統時

的治理處理或帶寬的代價。



當一個邏輯上遠地的參與者和一個SNMPv2實體間的通訊不是通過SNMPv2時（通

過任何傳輸協議），那個代理參與者稱作一個SNMPv2遠地代理關系。遠地代理關系

的部署是一種使Internet上的從某種意義上講不可治理的設備或部門可以通過

SNMPv2來治理。



定義一個通常用于一個SNMPv2代理關系的SNMPv2實體的行為的透明原則如下：



一個SNMPv2實體處理從另一個SNMPv2實體接收而來的SNMPv2協議消息的方式對

于后者是完全透明的。



這種透明原則是從歷史上分離結構體系與實現的SNMP原則中繼續而來。這種

二分法給Internet標準網絡治理體系的信息和分配模型都帶來了好處，而且它是可

能建造的大型治理系統的建筑性基石。與這種原則一致，盡管在某些環境下SNMPv2

代理機構的實現可能與傳輸層的網橋的實現相似，這種特定的實現戰略（或其他任

何實現戰略）不值得在SNMPv2治理體系或代理治理的標準機制中得到認可。



很明顯，在透明原則里，在任何兩個SNMPv2對等體之間需要保持SNMPv2的治理

操作的語義。非凡地，假如一個操作集合的范圍延伸到去治理位于多個網絡位置的

信息，它的“似乎是同步”的語義將極難保證。正因為如此，答應治理位于多個位

置的信息的操作集合的代理配置是不提倡的，盡管這種操作并沒有被協議體系明確

的禁止，以防在很稀少的情況下，可能需要以一種相容的方法來支持它們。



在這種透明原則下，還很明顯的是：與一個代理機構的交互時，不提供給一個

治理站點實現它的請求的代理機制的特點和過程的信息。也就是，除了在底層傳輸

地址中的任何明顯的區別外，應該使治理站點看起來似乎是在通過SNMPv2與被代理

的設備直接通訊。所以，一個在代理機構和它被代理設備間的通訊超時信息應該表

現為在治理站點與代理機構間的超時。同樣的，一個來自于被代理設備的出錯響應

應該盡可能的以代理機構和治理站點間的對應出錯信息表示。





2.8.SNMPv2上下文



一個SNMPv2上下文是指一個可被一個SNMPv2實體訪問的被治理對象資源的

集合。被一個上下文標識的對象資源可能是本地的或遠地的。



一個涉及本地對象資源的SNMPv2上下文被標識為一個MIB視圖。在這種情況

下，一個SNMPv2實體用本地機制去訪問被SNMPv2上下文標識的治理信息。



一個涉及遠地對象資源的遠地SNMPv2上下文被標識為一個代理關系。在這種情

況下，一個SNMPv2實體作為一個代理機構去訪問被SNMPv2上下文標識的治理信息。





2.9.SNMPv2治理通訊

SNMPv2治理通訊是一個從一個特定的SNMPv2參與者到第二個特定的SNMPv2參

與者的，關于包含在相應的SNMPv2實體中可以被訪問的SNMPv2上下文中的治理信息

的通訊。非凡地，一個SNMPv2治理通訊可以是：



o一個發起通訊的參與者的關于被尋址的參與者可以訪問的信息的

查詢（例如getRequest,getNextRequest,或者getBulkRequest）。



o一個被尋址參與者的，關于發起方可訪問的信息的，指示性的斷言。

（例如Response,InformRequest,或者SNMPv2-Trap）



o一個發起方作出的，發給被尋址的參與者的，關于被尋址的參與者

可以訪問的信息的命令式的斷言（例如setRequest），或者



o一個發向被尋址的參與者的確認，它是關于發起方接收到的信息

的。（例如一個確認InformRequest的響應）



一個治理通訊用一個ASN.1值表示，符合下面的語法:



SnmpMgmtCom::=[2]IMPLICITSEQUENCE{

dstParty

OBJECTIDENTIFIER,

srcParty

OBJECTIDENTIFIER,

context

OBJECTIDENTIFIER,

pdu

PDUs

}



對于每個代表一個SNMPv2治理通訊的SnmpMgmtCom值,下列敘述成立:



o它的dstParty組件稱作目的點，標識了該通訊發往的SNMPv2參

與者。



o它的srcParty組件稱作源點，標識了發起通訊的SNMPv2參與者。



o它的context組件標識SNMPv2上下文，它含有通訊涉及的治理信

息



o它的pdu組件有在[2]中賦于的形式和含義。





2.10.SNMPv2鑒定過的治理通訊



SNMPv2鑒定過的治理通訊是這樣的SNMPv2治理通訊：它的發起方SNMPv2參與者

被可信地鑒定過，并且該通訊的傳輸的完整性受到保護。一個SNMPv2鑒定過的治理

通訊用一個ASN.1值表示，符合下面的語法:



SnmpAuthMsg::=[1]IMPLICITSEQUENCE{

authInfo

ANY,--由鑒定協議定義

authData

SnmpMgmtCom

}



對于每個代表一個SNMPv2鑒定過的治理通訊的SnmpAuthMsg值,下列敘述成

立:



o它的authInfo組件稱作鑒定信息，包含支持產生本消息的SNMPv2

參與者使用的鑒定協議的信息。鑒定信息的具體含義由使用的鑒定協議指定；除了

鑒定協議用它來判定該通訊是否被鑒定過以外，它對通訊的應用語義沒有影響。



o它的authData組件稱作鑒定數據，代表一個SNMPv2治理通訊。







2.11.SNMPv2私有治理通訊



SNMPv2私有治理通訊是一個SNMPv2鑒定過的治理通訊，它受到可能的保

護，防止泄漏。一個私有治理通訊用一個ASN.1值表示，符合下面的語法:



SnmpPrivMsg::=[1]IMPLICITSEQUENCE{

privDst

OBJECTIDENTIFIER,

privData

[1]IMPLICITOCTETSTRING

}



對每個代表一個SNMPv2私有治理通訊的SnmpPrivMsg值，下面的敘述成

立：



o它的privDst組件稱作私有目的地，表明該通訊發向的SNMPv2參

與者。



o它的privData組件稱作私有數據，包含一個SNMPv2鑒定過的治理

通訊的（可能已加密）數據序列（根據[5]的約定）。





2.12.SNMPv2治理通訊類



一個SNMPv2治理通訊類對應于一個在[2]中定義的特定的SNMPv2PDU

類型。SNMPv2治理通訊類用ASN.1INTEGER值表示，需要根據識別PDU的類型而定

（表1）







Get1

GetNext2

Response4

Set8

--unused16

GetBulk32

Inform64

SNMPv2-Trap128



表1:治理通訊類





一個表示通訊類的值被計算為2，增加到ASN.1上下文的值，對應SNMPv2

PDU的特定標簽。



一個治理通訊的類的集合用ASN.1INTEGER值來表示，該值是該集合類

表示通訊類的標識的和。空集用0值表示。



2.13.SNMPv2訪問控制策略



SNMPv2訪問控制策略是一個用SNMPv2上下文和在一對SNMPv2參與者間

被認證的治理通訊類描述的本地訪問策略的標準說明書。在協議體系中，該說明書

包含四部分：



oSNMPv2訪問控制的目標－接收其他參與者的治理請求，執行治理操

作的SNMPv2參與者。



oSNMPv2訪問控制的主體－通過發送治理通訊給其他參與者而請求

治理操作被執行的SNMPv2參與者。



oSNMPv2訪問控制的被治理的對象資源――標識治理信息的SNMPv2

上下文，被請求的治理操作在它之上被執行，



o指定SNMPv2治理通訊類的策略，它屬于一個特定的SNMPv2上下文，

該上下文由一個被認證的特定的目標從一個特定的主體獲得。



概念性地，一個SNMPv2訪問策略用ASN.1值表示，符合下面地語法：



AclEntry::=SEQUENCE{

aclTarget

OBJECTIDENTIFIER,

aclSubject

OBJECTIDENTIFIER,

aclResources

OBJECTIDENTIFIER,

aclPrivileges

INTEGER

}



對于表示一個SNMPv2訪問策略的每個值，下列陳述成立：



o它的aclTarget組件稱作目標，指明該部分策略答應訪問的

SNMPv2參與者。



o它的aclSubject組件稱作主體，指明被該部分策略賦予權限的

SNMPv2參與者。



o它的aclResources組件稱作被治理的對象資源，表明該部分策略

涉及的SNMPv2上下文。



o它的aclPrivileges組件稱作權限，代表一個SNMPv2治理通訊類

的集合，在指明特定的SNMPv2上下文時，該集合從特定的主體參與者接收，認證后

被目標參與者處理。



SNMPv2訪問控制策略的運用僅發生在治理通訊接收的時候；它不用在管

理通訊的傳輸中。注重：用AclEntry語法的ASN.1值，也被用于決定一個SNMPv2陷阱

[2]的目的地。



3.過程的元素



本小節描述一個SNMPv2實體在處理SNMPv2消息的程序。這些程序獨立

于可能用到的特定的鑒定和私有協議。





3.1.產生一個請求



本小節描述一個SNMPv2實體發送一個治理請求和者一個陷阱通知的程

序：



(1)創建一個SnmpMgmtCom值，其中的srcParty組件表明發起方的參與

者，dstParty表明接收的參與者，context標識期望的SNMPv2上下文，pdu指明期望

的治理操作。



(2)查詢存有參與者信息的本地數據庫，以決定發起方和接收方的

SNMPv2的鑒定協議和其他相關信息。



(3)創建一個SnmpAuthMsg值，含有下面的屬性：



根據發起方的鑒定協議創建它的authInfo組件。非凡地，假如發起方的鑒定協

議為noAuth，該屬性置為長度為0的OCTETSTRING值。



它的authData屬性是已經創建的SnmpMgmtCom的值



(4)查詢關于參與者信息的本地數據庫，以決定接收方的SNMPv2參與者

的私有協議和其他相關信息。



(5)創建一個SnmpPrivMsg值，屬性如下：



它的privDst屬性指明接收方的SNMPv2參與者。



它的privData屬性是序列化的SnmpAuthMsg值（可能被加密）。



非凡地，假如接收方SNMPv2參與者地私有協議是noPriv，那么privData屬性是

未被加密的。否則，privData根據私有協議來處理。



(6)根據[5]中的約定序列化SnmpPrivMsg的值。



(7)序列化后地SnmpPrivMsg值用接收方的SNMPv2參與者的傳輸地址和

傳輸域來傳送。



注重：上述地過程不包含任何SNMPv2訪問控制策略地應用。(參照2.13)



3.2.處理一個收到的通訊

本節描述一個SNMPv2實體收到一個治理通訊后的處理過程。



(1)增加snmpStatsPackets計數器[7].假如收到的信息不是一個

SnmpPrivMsg的序列化的（根據[5]地約定）值，該消息不作進一步地處理就被拋棄。

(假如該數據包的第一個八位組地值為16進制的30，有時在拋棄該消息前增加

snmpStats30Somethingcounter[7]的值；否則增加snmpStatsEncodingErrors

counter[7]的值)



(2)查詢關于參與者信息的本地數據庫，根據SnmpPrivMsg中的privDst

屬性得到接收方SNMPv2參與者的信息。





(3)假如本地數據庫中沒有關于接受方SNMPv2參與者的信息，或者表明

本地的SNMPv2實體沒有實現接收方參與者的操作，那么無需進一步的處理就丟棄接

收到的消息，之后增加snmpStatsUnknownDstPartiescounter[7]的值。



(4)根據SnmpPrivMsg中的privData屬性創建一個ASN.1OCTETSTRING

值（可能根據使用的私有協議解密）



非凡地，假如該參與者的私有協議是noPriv，那么OCTETSTRING

的值與SnmpPrivMsg中的privData的值完全對應。



(5)假如OCTETSTRING的值未被序列化，（根據[5]的約定），那么無需

進一步的處理就丟棄接收到的消息，之后增加snmpStatsEncodingErrors

counter[7]的值。



(6)假如authData中的dstParty屬性與SnmpPrivMsg中的privDst屬

性不同，那么無需進一步的處理就丟棄接收到的消息，之后增加

snmpStatsDstPartyMismatchescounter[7]的值。



(7)根據SnmpAuthMsg中authData中的srcParty屬性得出發起方SNMPv2

參與者，在關于參與者信息的本地數據庫中查詢它的信息。



(8)假如本地數據庫中沒有發起方參與者的信息，那么無需進一步的處

理就丟棄接收到的消息，之后增加snmpStatsUnknownSrcPartiescounter[7]

的值。



(9)根據關于參與者信息的本地數據庫中發起和接收方的SNMPv2參與者

的相關信息和鑒定協議，鑒定得到的SnmpAuthMsg值。



非凡地，假如鑒定協議指明為noAuth，那么總是鑒定SnmpAuthMsg

的值為真實的。



(10)假如鑒定SnmpAuthMsg的值為不真實的，那么無需進一步的處理就丟

棄接收到的消息，而且，假如snmpV2EnableAuthenTrapsobject[7]正在生效，那

么該SNMPv2實體根據它的配置（4.2.6of[2]）發送authorizationFailure陷阱[7]



(11)從SnmpAuthMsg中的authData屬性提取SnmpMgmtCom的值



(12)從SnmpMgmtCom的context屬性得到SNMPv2的上下文，查詢關于參

與者信息的本地數據庫以獲得它的信息。



(13)假如本地數據庫中沒有該SNMPv2上下文的信息，那么無需進一步的

處理就丟棄接收到的消息，之后增加snmpStatsUnknownContextscounter[7]的值。



(14)查詢關于訪問處理信息的本地數據庫，根據接收方參與者和指明的

SNMPv2上下文得到本地訪問策略許可給發起方SNMPv2參與者的訪問權限。



(15)根據與SnmpMgmtCom中的PDUs屬性值關聯的ASN.1tag值決定治理通

訊類。假如接收到的消息的治理信息類是32,8,2,或1(也就是GetBulk,Set,

GetNext或者Get)，并且本地SNMPv2實體沒有實現SNMPv2上下文，那么無需進

一步的處理就丟棄接收到的消息，之后增加snmpStatsUnknownContextscounter[7]

的值。



(16)假如接收到的消息的治理信息類是128,64或4(也就是

SNMPv2-Trap,Inform,或者Response)，并且該類無訪問權限，那么無需進一步的

處理就丟棄接收到的消息，之后增加snmpStatsBadOperationscounter[7]的值。



(17)假如接收到的消息的治理通訊類沒有訪問權限，那么在生成和傳送

一個響應消息后無需進一步的處理就丟棄接收到的消息，該響應消息代表接收方

SNMPv2參與者，被發往發起方SNMPv2參與者，它的context,var-bind-list和

request-id屬性與接收到的請求中的對應屬性完全一樣。它的error-

index屬性是zero并且它的error-status屬性是authorizationError[2].



(18)假如SNMPv2上下文涉及本地對象資源，那么根據在[2]中的程序，

用SNMPv2上下文識別MIB視圖，根據該視圖用接收方SNMPv2實體執行SnmpMgmtCom

值代表的治理操作。



(19)假如SNMPv2上下文涉及遠地對象資源，那么通過合適的代理

關系執行SnmpMgmtCom值代表的治理操作。





3.3.生成一個響應

生成一個針對SNMPv2治理請求的響應的過程和傳送一個請求的過程是

完全一樣的（參考3.1），除了下列的情況例外：



(1)在第一步，從初始的SnmpMgmtCom中的srcParty屬性得到響應

SnmpMgmtCom中的dstParty，從初始的SnmpMgmtCom中的dstParty屬性得到響應

SnmpMgmtCom中的srcParty屬性，從初始的SnmpMgmtCom中的context屬性得到響

應SnmpMgmtCom中的context屬性；而且，響應SnmpMgmtCom的pdu屬性的值是那個實

施初始SnmpMgmtCom值指定的操作執行后得到的結果。



(2) 在第七步，用生成自己的相應請求的傳送地址和傳送域來傳送序列

化的SnmpPrivMsg值，即使這與關于參與者信息的本地數據庫中記

錄的傳送信息不同。



4.模型應用

這一部分描寫如何設置治理模型，以達到在各種環境和配置中實現有效的網絡

治理.定義了幾種類型的治理配置，并用各自的幾個例子來加以描述.





4.1無安全的小代理配置

這段是關于與一個或多個SNMPv2治理站點相互作用的小的、無安全保證的

SNMPv2代理的配置的例子.表2是關于小代理和治理者都知道的SNMPv2參與者的信

息.表3介紹了關于本地訪問策略的相似的公共部分的信息.



在表2中，代理在ip地址為1.2.3.4、UDP的斷口161使用參與者身份gracie

來操作；治理者在IP地址為1.2.3.5、UDP的斷口的2001上用身份為george來操

作的.在小的、無安全保證的SNMPv2代理段執行必須提供關于兩個SNMPv2參與者的

身份和傳輸地址的治理配置（和穩定存儲）：自身和遠端的.嚴格的講，關于參與者

的其他信息（包括訪問策略信息）是不必要配置的.



身份gracie（代理者）george（治理者）

域snmpUDPDomainsnmpUDPDomain

地址1.2.3.4，1611.2.3.4.5，2001

認證段口noAuthnoAuth

（AuthPort）

認證的私有密鑰“”“”

（AuthPrivKey）

認證的公開密鑰“”“”

認證的時鐘00

認證的生命周期00

私有端口noPrivnoPriv

私有私人密鑰“”“”

私有的公開密鑰“”“”

表2：小代理的參與者信息



目標主題上下文權限

graciegeorgelocal35（獲取,獲取下一個獲取一批）

（GetGetNextGetBulk）

georgegracielocal132

(ResponseSNMPv2-Trap)

表3：關于小代理的訪問信息



假如治理端的參與者george希望通過叫代理者gracie發布一個SNMPv2的

GetNext請求消息來的詢問關于上下文為“local”的治理信息.該治理者參考他本

地的關于參與者的數據庫信息.因為對參與者george的鑒定認證協議是記錄為

“moAuth”的，這個通過治理者生成的GetNext請求消息是作為原始性和完整性是

不需要鑒別的.通過治理者的本地數據庫中關于參與者的信息，對參與者gracie的

私有協議是設置為“noPriv”的，GetNext請求消息是不會得到保護的，可能會暴

露.更準確的講，它是簡單的裝配的，排序和傳輸到目的地址的（IP地址為1.2.3.4，

UDP端口為161），這個目的地址就是參與者gracie在治理者的本地數據庫中的信息

所記錄的.



當GetNext請求消息在代理段被收到后，這個（gracie）參與者的身份信息從

消息中取得，并且接收的實體參考參與者信息的本地數據庫.因為gracie的私有協

議是“noPriv”，其接受消息是不會得到不被暴露的保護的.類似的，當原始參與者

（grorge）的身份被取得后，參與者的本地數據庫的信息也被取得了.因為對當時人

george的鑒別協議記錄為“noAuth”，這個接受信息是立即被認證接收.



這個接受消息完全被處理的情況，僅僅發生代理關于訪問策略信息的本地數據

庫對通過參與者george向參與者gracoe關于SNMPv2的上下文為“local”

的"GetNext"請求通訊的認證.訪問策略的數據庫信息在表3中的認證象通訊等

（Get和GetBulk等操作）.



當一個標準的請求被處理時，一個響應消息通過參考SNMPv2上下文“local”

和身份來生成，gracie作為源參與者，從請求端來的george作為目的參與者.因為

對gracie的本地數據庫中的關于認證協議記為“noAuth”，對原始和整體性而言，

一般性的響應消息是不用認證的.根據參與者信息的本地數據庫，對參與者george

的私有協議是“noPriv”，響應消息可能被暴露.響應消息從相應的的請求地址傳輸

到傳輸地址，而不關心和傳輸地址相關的george的本地數據庫的信息.



當生成響應是被治理者接受時，直接的參與者（george）的身份是從消息中提

取出來的，并且治理者參考參與者的本地數據庫信息.因為參與者george的私有協

議記錄為“noPriv”，該響應是得不到保護的.類似的，發起的參與者gracie的身份

被提取出來，并參考其本地數據庫，因為參與者gracie的認證協議記為“noAuth”，

響應立即作為認證被接受.



接受的信息能完全被處理，僅僅當治理者的本地數據庫的訪問策略認證來自于

參與者gracie到治理者george的響應信息，并且參考SNMPv2的上下文“local”.

訪問策略信息數據庫描述象表3中認證響應消息等（如snmpV2-陷阱信息）





4.2安全小代理配置

這段給出了一個例子來配置SNMPv2安全小代理，該代理僅僅和單一的SNMPv2

的治理站相互作用.表4說明了關于對小代理和治理者都知道的SNMPv2參與者的信

息.而表5類似地說明了本地訪問策略的公共信息.



治理者和代理之間的相互影響在這個配置中是和上面的非安全小代理非常相似

的，除了所有的協議消息要對原始性和完整性認證及對信息的隱蔽的保護.這個例子

要求加密技術，是為了支持通過SNMPv2本身來分發密碼密鑰.一個更精確的包含附

加的一對參與者例子支持在沒有加密技術認證消息中交換非加密信息來不花加密的

代價。



一個實際的安全代理的配置可能要求SNMPv2參與者的認證和私有協議均為不

認證noAuth（）和無私有（noPriv），其目的是為了支持時鐘同步（參考[6]）.更

具體的說，這些額外的參與者是不在這個例子中說明的.

身份olliestan

(代理)(治理者)

域snmpUDPDomainsnmpUDPDomain

地址1.2.3.4,1611.2.3.5,2001

認證端口v2md5AuthProtocolv2md5AuthProtocol

認證私有密鑰"0123456789ABCDEF""GHIJKL0123456789"

認證公開密鑰""""

認證時鐘00

認證的生命周期300300

私有端口desPrivProtocoldesPrivProtocol

私人私有密鑰"MNOPQR0123456789""STUVWX0123456789"

私人公開密鑰""""

表4:安全小代理的參與者信息



目標目標上下文權限

olliestanlocal35(Get,GetNext&GetBulk)

stanollielocal132(Response&SNMPv2-Trap)

表5:安全小代理的訪問信息



在表4中，這個例子的代理參與者在IP地址為1.2.3.4、UDP端口為161上使

用ollie的身份來操作；治理者在IP地址為1.2.3.5、UDP的端口為2001上使用身

份stan來操作.SNMPv2的安全小代理的執行必須提供關于SNMPv2的參與者的相關

信息治理配置（和穩定存儲）：包括它自身和遠端.Ollie和stan認證他們通過使用

SNMPv2認證協議v2md5AuthProtocol和他們的彼此不同的私有認證密鑰來產生的所

有的信息.盡管在這里他們的私有認證密鑰的值（"0123456789ABCDEF"和

"GHIJKL0123456789"）的出現是屬于解釋目的，關于私有認證密鑰的信息一般是不

會提供給人們的，并且是限制請求它的協議的部分操作.



當使用v2md5AuthProtocol時，對每個SNMPv2參與者的公開認證密鑰從不會在

SNMPv2的認證和校驗中使用的.（v2md5AuthProtocol在字符上是對稱的的），同時

每個參與者的私有認證密鑰必須對彼此要認證通訊的參與者是已經知道的.相反，不

對稱認證協議（公開密鑰）不能依靠他們操作的私有密鑰的共享.



傳輸給參與者stan的所有協議消息是使用desPrivProtocol私有協議和私有密

鑰“STUVWX0123456789”來加密的；它們加密是通過相同的協議和密鑰.類似地，傳

輸給參與者ollie的所有信息是用desPrivProtocol協議和私人私有密鑰

“MNOPQR0123456789”來加密的，他們相互加密.作為認證密鑰，私人私有密鑰是不

能提供給人們的，同時請求它的協議的執行也要限制部分功能.





4.3MIB視圖的配置

這段描述了一個關于MIB視圖定義的慣例和慣例的使用，并給出一個關于參考

本地目標資源的SNMPv2的上下文的MIB視圖的配置.



一個MIB視圖通過收集視圖子樹來定義（參考2.6段），并且任何一個MIB視

圖可以用這種方法來描述.因為MIB視圖的定義可以包含很多視圖子樹，關于一個簡

化的MIB視圖的定義也是合理的.



慣例中采納了關于支持用視圖子樹族（包括或者排除有關的MIB）來實現簡化

的MIB視圖的定義.該視圖子樹族包括或排除相關MIB視圖的定義。通過這個慣例，

每個SNMPv2實體根據相關的SNMPv2上下文（可參考本地的目標資源）來定義MIB

視圖，通過該MIB視圖來維持本地表.在表中的每個條目表示一個視圖子樹族，該視

圖子樹包括或者排除一些SNMPv2上下文的MIB視圖.每個表中實體描述了一個子樹

族用一對序偶：目標驗證人（OBJECTIDENTIFIER）值（又叫族名）和位串（bitstring）

值（又叫族標志）.族標志是指出了在一個相關族名的子驗證名在一個相關子樹族定

義中是非常重要的.對每個可能的MIB對象實例，假如下列條件成立，那么它是屬于

通過一個具體表條目來描述的的視圖子樹族的：



? 由MIB對象實例組成的目標標識符名至少和上述的表條目的族名一樣數目

的標識符.



在上述的MIB對象實例名中每個子標識符匹配相應族名相關的子標識符.而不

管其族標志是否為零



對一個非凡的SNMPv2上下文來講，在MIB視圖中出現的MIB對象實例是和子樹

族的實例的成員有關的，在SNMPv2的上下文中的本地表的條目：



● 假如一個MIB對象實例不屬于任何一個子樹族，則對相關的SNMPv2的上下文

而言，它就不在的MIB視圖中.



● 假如一個MIB對象實例屬于子樹族，該子樹族是通過一個相關的表條目具體

的描述的，則根據條目的類型來決定是包括還是排除相關的MIB視圖.



● 假如一個MIB對象實例屬于通過多個相關表條目描述的子樹族，則實例根據

單一的表條目來決定是包括還是排除相關的MIB視圖.這里表項目，首先，關

聯最大的子標識名數，其次，還關聯最大的族名.



子樹通過這樣的表條目來描述，其關聯的族標志是符合通過族名的條目來標識

的單一視圖子樹.因為慣例提供了內在族標志值和多個的擴展，帶有一個零長度的族

標志的表項代表一個子樹族，該子樹與一個單一的視圖子樹相對應。



上下文類型族名族標志

lUCyincludedinternet''H

表6：小代理的視圖定義



用這個慣例來簡化MIB視圖的定義，一些最通用的MIB定義可以方便的表示.

例如，表6就說明了小的SNMPv2實體需要的MIB視圖的定義，這個小的MIB具有單

一的SNMPv2的上下文，該上下文和MIB視圖相關，這樣MIB視圖包括了在SNMPv2

網絡治理結構中定義的所有MIB目標.這個說明表有單一的入口.在MIB視圖中定義

條目的SNMPv2上下文（lucy）的在第一列表明.條目的類型表明任何MIB對象實例

屬于子樹族，該子樹族是通過對在MIB視圖中SNMPv2上下文“lucy”的條目的出現

來描述的.這個條目的族名是internert，并且零長度的族標志表明了相關子樹族和

根和該節點的單一子視圖相適應.



另一個關于MIB視圖定義的例子（見表7）是一個有多個SNMPv2上下文的SNMPv2

實體，并且有截然不同的MIB視圖.關聯了SNMPv2上下文lucy的MIB視圖，組成了

所有在SNMPv2網絡環境結構中定義的MIB目標的實例，除了適合于SNMPv2參與者

治理的部分.相反地，屬于SNMPv2上下文ricky的MIB視圖僅僅包含在Internet-

標準MIB的系統組中的MIB對象實例，和SNMPv2參與者治理的這些對象實例.



上下文類型族名族標志

lucyincludedinternet''H

lucyexcludedsnmpParties''H

rickyincludedsystem''H

rickyincludedsnmpParties''H

表7:多上下文的視圖定義



一個更復雜的關于MIB視圖配置的例子說明了通過視圖子樹族（見表8）的視圖

子樹的簡化集合.在這個例子中，和SNMPv2上下文lucy相關的MIB視圖包括所有的對

象實例（這些實例在Internet標準MIB系統組中），和一些次要的網絡交互的設備相

關的信息.無論如何，相關信息交互是不包括交互的速度的.次要表條目族標志值

“FFAO”H表明一個MIB對象實例屬于相關的子樹族，假如它的名字的初始前綴包含

有在注冊層次上的ifEntry部分，它的名字的11層子樹的名字為2.

描述次要網絡交互的速度的MIB對象實例，是屬于通過次要的和第三個表的條目的來

描述的子樹族，但非凡的實例是排除SNMPv2上下文為lucy的MIB視圖的，因為更多的

相關族名在表條目上是排除類型.



對SNMOv2上下文為ricky的MIB視圖在這個例子中也被定義.這個SNMPv2上下文

為ricky的MIB視圖包括了在Internet標準MIBicmp組中所有的對象實例，和與治理設

備相關的15層的網絡交互所有相關的信息.另外，SNMPv2上下文為rickyMIB視圖包括

在14層上收到的和網絡交互的8位組的數目.

上下文類型族名族標志

lucyincludedsystem''H

lucyincluded{ifEntry02}'FFA0'H

lucyexcluded{ifSpeed2}''H

rickyincludedicmp''H

rickyincluded{ifEntry05}'FFA0'H

rickyincluded{ifInOctets4}''H



表8:更多的視圖定義的具體闡述



根據上面的例子的假設，一個MIB視圖配置的廣闊范圍可以通過[4]中的簡化描

述得到高效的支持，嚴格的MIB設計可能有時要更加簡化大多數MIB視圖定義的大小

和復雜度.一方面，MIB視圖配置的機構沒有強加一個絕對的約束在當地治理的訪問

策略上和MIB的名字空間的結構上；在另一方面，大多數的訪問策略是已知的，這些

策略的配置代價可以通過分配一些不同的部分在注冊層來降低，這里注冊層的MIB

目標是本地策略要求經常頻繁地處理的.





4.4代理配置

這節主要是用一個例子來解釋SNMPv2的代理配置.一方面，外部代理配置提供了

治理非SNMP設備的能力，另一方面，本地代理配置答應一個治理者減輕一個主要任

務不是治理的網絡設備的治理方面的負擔.從這個程度上來講，SNMPv2代理機構的功

能主要就是個治理信息的集合，代理配置也可減輕大規模治理活動的帶寬要求.



這個例子配置的一個說明：實際的配置可能要求附加的的部分，主要大為了支

持時鐘同步和保密的分發.





4.4.1外部代理配置

這段主要是介紹一個關于通過SNMPv2治理站治理網絡元素（這些網絡元素并不

支持SNMPv2）的配置的例子.這個在SNMPv2代理機構的配置中心通過使用一個叫所有

者協議（proprietaryprotocol）來和非SNMPv2設備進行交互來實現SNMPv2的治理

操作.



表9介紹了關于SNMPv2參與者的信息，這些信息記錄在SNMPv2代理機構的本地

數據庫中的參與者信息中.表10介紹了關于代理關系的信息，該信息記錄在SNMPv2

代理機構的本地數據庫的的上下文信息中.表11介紹了關于SNMPv2參與者的信息，

該信息記錄SNMPv2治理站的本地數據庫的參與者信息中.表12介紹了關于訪問策略

的數據庫信息，該信息是在本地的治理中指明.



身份grouchochicoharpo

(治理者)(代理人)(代理目的)

域snmpUDPDomainsnmpUDPDomainacmeMgmtPrtcl

地址1.2.3.4,20021.2.3.5,1610x98765432

認證端口v2md5AuthProtocolv2md5AuthProtocolnoAuth

認證私有密鑰"0123456789ABCDEF""GHIJKL0123456789"""

認證公開密鑰""""""

認證時鐘000

認證生命周期3003000

私有端口noPrivnoPrivnoPriv

私人私有密鑰""""""

私人公開密鑰""""""

表9:代理機構的參與者信息



上下文代理目的代理源代理上下文

ducksoupharpon/an/a

表10:代理機構的代理關系



身份grouchochico

(治理者)(代理人)

域snmpUDPDomainsnmpUDPDomain

地址1.2.3.4,20021.2.3.5,161

認證端口v2md5AuthProtocolv2md5AuthProtocol

認證私有密鑰"0123456789ABCDEF""GHIJKL0123456789"

認證公開密鑰""""

認證時鐘00

認證生命周期300300

私有端口noPrivnoPriv

私人私有密鑰""""

私人公開密鑰""""

表11:治理站的參與者信息



目標主題上下文權限

chicogrouchoducksoup35(Get,GetNext&GetBulk)

grouchochicoducksoup132(Response&SNMPv2-Trap)

表12:外部代理的訪問訪問信息



向在表9中的介紹，代理機構的參與者在IP地址為1.2.3.5、UDP端口為161上用

身份chico操作；同時，這個例子中的治理者在IP地址為1.2.3.5、UDP端口為2002

上用身份groucho操作.Groucho和chico認證所有的關于他們使用

v2md5AuthProtocol協議生成的信息和他們截然不同的、私有的認證密鑰.雖然他們

的私有認證密鑰值("0123456789ABCDEF"和"GHIJKL0123456789")在這里因為解釋

的目的而出現了.但私有密鑰的信息一般是不會告訴人們的，并且對請求它的協議的

執行也是有限制的.



參與者harpo不會發送或接收SNMPv2協議信息；進一步說，所有與參與者的通訊

信息是通過一個假設的私有協議來確認的，該私有協議是由acmeMgmtPrtcl的值來確

認的.由于參與者harpo不參與到SNMPv2中，許多為該參與者記錄在本地數據庫中的

諸屬性均被忽略.



表10表明了相互了解的代理的代理關系.更具體的說，SNMPv2上下文ducksoup

指一個這樣的關系：參與者harpo感到滿足的關系.（這個代理的目的地的參與者的

傳輸域決定了代理源的解釋和代理上下文的確認---在這種情況下，用

acmeMgmtPrtcl表明代理源和上下文是可以忽略的）



為了詢問與參與者harpo相關的私有設備，治理站的groucho構造了一個SNMPv2

的GetNext請求，其中包含一個SnmpMgmtCom的值，該值是參考SNMPv2的上下文

ducksoup，并且傳輸它給在IP地址為1.2.3.5、UDP端口為161的參與者chico.該請求

是用私有認證密鑰“0123456789ABCDEF”來認證的.



當該請求被參與者chico接收到后，消息的發起者作為參與者groucho通過使用

本地信息（見表9）的私有密鑰“0123456789ABCDEF”來效驗.由于參與者groucho

通過發布一個通過訪問控制策略（見表12）對參與者chico和SNMPv2的上下文

ducksoup的GetNext（也可以是Get、GetBulk）請求來獲得認證.從而該請求獲得認

可.由于上下文信息的本地數據庫指明了SNMPv2的上下文ducksoup是參考了一個代

理關系，這個請求可通過直接翻譯到參與者harpo的合適的操作acmeMgmtPrtcl上來

獲得確認.這些新的操作傳輸到參與者harpo的acmeMgmtPrtcl的域上的0x98765432

地址上.



代理和私有設備之間私有協議的交流要求：一個SNMPv2響應治理操作是通過參

與者chico轉發參與者grpucho的結果而不是參考SNMPv2的上下文ducksoup.這個響

應通訊是為了原始的和完整性的認證，可通過在參與者chico的傳輸中指明使用認證

協議“v2md5AuthProtocol”和私有認證密鑰“GHIJKL0123456789”來實現.它傳輸

給在治理站點的SNMPv2參與者groucho，其IP地址為1.2.3.4、UDP端口為2002（相應

請求的源地址）.



當參與者groucho接受到這個響應后，參與者chico通過使用本地私有認證密鑰

信息（見表11）“GHIJKL0123456789”來效驗發起者的信息.由于參與者chico可根

據相關訪問策略（見表12），再通過發布關于參與者groucho和SNMPv2上下文ducksoup

的響應通訊來認證，其響應獲得認可，同時結束對私有設備的詢問.



通過觀察記錄治理站在代理機構（表9）上既不是靜態的、也不是專有配置的

本地數據庫的參與者信息是很重要的.例如，在這個例子中，假設acmeMgmtPrtcl是

一個治理站連接到局域網上的私有的MAC-layer機構.在這樣的環境下，SNMPv2參與

者chico想駐留在連接到LAN的SNMPv2代理機構，通過局域網協議的參與，去發現附

件和未連接到局域網上的各類站點.在這中情況下，SNMPv2代理很輕易調整它的本地

參與者的數據庫信息，達到通過SNMPv2治理站點來支持不是直接受局域網治理的站

點.對每個新發現的局域網站點，SNMPv2代理可以把它作為一個類似于參與者harpo

（代表局域網本身的）的條目添加它到參與者信息的本地數據庫中，也可以添加它

到上下文信息的本地數據庫中，作為一個類似于SNMPv2的上下文ducksoup（代表在

SNMPv2域中新站點的代理關系）的條目來處理.



由SNMPv2代理機構通過使用SNMPv2來詢問參與者的本地數據庫信息，只要有新

站點連接到局域網上來.一個SNMPv2治理站能夠發現和影響它們，





4.4.2本地代理配置

該段介紹了一個關于配置支持SMPv2本地代理操作的例子.即在一個SNMPv2代理

和一個要通過次要SNMPv2代理仲裁的治理站之間進行非直接交互的操作.



該例子的配置和上面的外部代理的介紹是類似的.在這個例子中，無論如何，與

身份為harpo相關的參與者通過SNMPv2接收消息，并且和SNMPv2代理chico用認證的

SNMPv2通訊來進行交互.



表13介紹了關于SNMPv2參與者的信息，它記錄在SNMPv2代理的代理信息的本地

數據庫中.表14介紹了關于記錄在SNMPv2代理的上下文信息的本地數據庫中的代理

關系信息.表11介紹了關于記錄在SNMPv2治理站點的參與者信息的本地數據庫中

SNMPv2參與者信息.表15介紹了關于在本地治理中指明的訪問策略的數據庫信息.



身份grouchochico

(治理者)(代理)

域snmpUDPDomainsnmpUDPDomain

地址1.2.3.4,20021.2.3.5,161

認證端口v2md5AuthProtocolv2md5AuthProtocol

認證私有密鑰"0123456789ABCDEF""GHIJKL0123456789"

認證公開密鑰""""

認證時鐘00

AuthLifetime300300

PrivProtnoPrivnoPriv

PrivPrivKey""""

PrivPubKey""""



Identityharpozeppo

(代理目的)(代理源)

DomainsnmpUDPDomainsnmpUDPDomain

Address1.2.3.6,1611.2.3.5,161

AuthProtv2md5AuthProtocolv2md5AuthProtocol

AuthPrivKey"MNOPQR0123456789""STUVWX0123456789"

AuthPubKey""""

AuthClock00

AuthLifetime300300

PrivProtnoPrivnoPriv

PrivPrivKey""""

PrivPubKey""""

表13:代理的參與者信息



上下文代理目的代理源代理上下文

ducksoupharpozeppobigstore

bigstoregrouchochicoducksoup

表14:代理的代理關系



目標主體ContextPrivileges

chicogrouchoducksoup35(Get,GetNext&GetBulk)

grouchochicoducksoup132(Response&SNMPv2-Trap)

harpozeppobigstore35(Get,GetNext&GetBulk)

zeppoharpobigstore132(Response&SNMPv2-Trap)

表15:本地代理的訪問信息



在表13中介紹說，代理的參與者在IP地址為1.2.3.5、UDP端口為161上用身份

chico來操作的.該例子的治理者在IP地址為1.2.3.4、UDP端口為2002上用身份

groucho來操作的.；代理源參與者在IP地址為1.2.3.5、UDP端口為161上用身份zeppo

來操作的.；代理目的參與者在IP地址為1.2.3.6、UDP端口為161上用身份harpo來操

作的.4個SNMPv2參與者的認證產生的信息是為了保證原始性和完整性，他們使用了

認證協議v2md5AuthProtocol和不同的私有認證密鑰.雖然這些私有認證密鑰的值

("0123456789ABCDEF","GHIJKL0123456789","MNOPQR0123456789"和

"STUVWX0123456789")在這里描述出來了，但私有密鑰的信息一般是不能告訴人們

的，同時要限制一些請求它協議操作.



表14介紹了相互了解的代理機構間代理關系，更具體的講，SNMPv2上下文

ducksoup是參考這樣一個關系的：被SNMPv2參與者zeppo和SNMPv2參與者harpo的通

訊認可了，同時也參考了SNMPv2的上下文bigstore.



為了詢問與參與者harpo相關的代理設備，治理站點groucho構造一個SNMPv2的

GetNext請求，該請求中包含了參考SNMPv2的上下文ducksoup的SnmpMgmtCom值，并

且傳輸給在IP為1.2.3.5、UDP端口為161的（見表11）參與者chico，這個請求是用

私有認證密鑰“0123456789ABCDEF”來認證的.



當參與者chico收到請求時，消息的發起者是通過參與者grouhco使用本地信息

（見表13）關于私有認證密鑰“0123456789ABCDEF”來校驗的.由于參與者groucho

是通過發布GetNext（也可以是get和getbulk）請求來認證的，該發布是參考了參與

者chico和相關訪問控制策略（見表15）的SNMPv2上下文ducksoup，故該請求被接受.

由于上下文信息的本地數據庫指明了參考代理關系的SNMPv2上下文ducksoup，這個

通過翻譯為一個從參與者zeppo到參與者harpo的相應SNMPv2的GetNext請求，同時

也參考了SNMPv2的上下文bigstore的請求，是可以得到確認的.通過使用私有認證

“STUVWX0123456789”來認證新的通訊和傳輸到IP地址為1.2.3.6的參與者harpo.



當新的請求被參與者harpo收到時，消息的發起者是通過參與者zeppo使用本地

信息（見表13）關于私有認證密鑰“STUVWX0123456789”來校驗的.由于參與者zeppo

是通過發布GetNext（也可以是get和getbulk）請求來認證的，該發布參考了參與者

harpo和相關訪問控制策略（見表15）的SNMPv2上下文ducksoup，故該請求被接受.

描述了詢問結果的SNMPv2響應消息是通過參與者harpo到參與者zeppo來生成的.并

參考了SNMPv2的上下文bigstore.這個響應通訊也是使用私有認證密鑰

“MNOPQR0123456789”來認證的，并傳輸給IP地址為1.2.3.5的參與者zeppo（相應

的請求的源地址）



當這個響應被參與者zeppo收到時，信息的發起者是通過參與者harpo使用本地

信息（見表13）關于私有認證密鑰“MNOPQR0123456789”來校驗的.由于參與者harpo

是通過發布和響應通訊來認證的，該通訊參考了參與者zeppo和通過相關的訪問控制

策略（表15）SNMPv2的上下文bigstore，響應是可以接受的.并且它是對原始的

GetNext請求構造響應，表明為一個ducksoup的SNMPv2上下文.從參與者chico到參與

者groucho響應的原始性和完整性通過使用私有認證密鑰“GHIJKL0123456789”來認

證的，并傳輸給IP地址為1.2.3.5的參與者groucho（相應原始請求的源地址）.



當這個響應被參與者groucho收到時，消息的發起者是通過參與者chico使用本

地信息（見表13）關于私有認證密鑰“GHIJKL0123456789”來校驗的.由于參與者chico

是通過了發布和響應通訊來認證的，該通訊又參考了參與者groucho和通過相關的訪

問控制策略（表15）SNMPv2的上下文ducksoup，故響應是可以接受的.并且可完成詢

問.





4.5公共密鑰配置

這段介紹了一個關于假設的安全協議的配置的例子.這個假設協議將基于不對

稱（公開密鑰）的密碼技術，把它作為一個提供數據原始性的認證（不保證會保護

不被暴光）.這個例子說明了用公開密鑰技術的治理模型的一致性，并且在例子范圍

內支持保護不被暴光.

身份olliestan

(代理t)(治理者)

域snmpUDPDomainsnmpUDPDomain

地址1.2.3.4,1611.2.3.5,2004

AuthProtpkAuthProtocolpkAuthProtocol

AuthPrivKey"0123456789ABCDEF"""

AuthPubKey"0123456789abcdef""ghijkl0123456789"

AuthClock00

AuthLifetime300300

PrivProtnoPrivnoPriv

PrivPrivKey""""

PrivPubKey""""

表16:公開密鑰代理的參與者信息



這個例子的配置由單一的SNMPv2代理組成，它是和單一的SNMPv2治理站點相互

作用影響的.表16和17介紹了關于SNMPv2的參與者通過代理和治理者的信息，另外表

5介紹的關于對治理者和代理的本地訪問策略的信息.



身份olliestan

(agent)(manager)

域snmpUDPDomainsnmpUDPDomain

Address1.2.3.4,1611.2.3.5,2004

AuthProtpkAuthProtocolpkAuthProtocol

AuthPrivKey"""GHIJKL0123456789"

AuthPubKey"0123456789abcdef""ghijkl0123456789"

AuthClock00

AuthLifetime300300

PrivProtnoPrivnoPriv

PrivPrivKey""""

PrivPubKey""""

表17:公開密鑰治理站點的參與者信息



在表16中，使用身份為ollie的代理的參與者在IP為1.2.3.4、UDP的端口為161

上上操作；使用身份stan的治理者的參與者在IP為1.2.3.5、UDP的端口為2004上操

作；ollie和stan認證所有由他們生成的信息，通過用假設的SNMPv2認證協議與他們

截然不同的私有認證密鑰來保證其原始性和完整性.這些私有認證密鑰的值

（"0123456789ABCDEF"和"GHIJKL0123456789"）在這里說明僅僅是為了解釋的目

的，私有密鑰通常是不能告訴人們的，并且訪問它們協議的執行也有部分限制.



在更多的方面，在上述的這個小的安全SNMPv2代理中，治理和代理之間的相互

影響在它們的配置中總是同樣的.最主要的不同不是SNMPv2的參與者在公共密鑰的

配置中有這樣的信息：可以通過其他參與者來認證其通訊來了解關于私有密鑰的信

息，相反的，對每個收到的認證SNMPv2信息，發起者的身份是通過應用一個不對稱

加密技術算法對收到的信息和發起者的公開密鑰一起來確認的.因此，在配置中，代

理知道治理的公開密鑰（“ghijkl0123456789”）但不知道它的私有密鑰

("GHIJKL0123456789")；類似地，治理者知道代理的公開密鑰

（“0123456789abcdef”）而不知道自己的私有密鑰("0123456789ABCDEF").





5.安全考慮

為了參與在治理模型中說明這個備忘錄，SNMPv2的執行必須支持在參與者信息

的本地數據庫方面具有本地的、穩定存儲的能力.相應地，每次嘗試的操作必須小到

穩定存儲的數目之內.





6.感謝

該文檔是基本上基于RFC1351而來的.





7.參考

[1]Case,J.,Fedor,M.,Schoffstall,M.,Davin,J.,"Simple

NetworkManagementProtocol",STD15,RFC1157,SNMP

Research,PerformanceSystemsInternational,MIT

LaboratoryforComputerScience,May1990.



[2]Case,J.,McCloghrie,K.,Rose,M.,andWaldbusser,S.,

"ProtocolOperationsforversion2oftheSimpleNetwork

ManagementProtocol(SNMPv2)",RFC1448,SNMPResearch,

Inc.,HughesLANSystems,DoverBeachConsulting,Inc.,

CarnegieMellonUniversity,April1993.



[3]Case,J.,McCloghrie,K.,Rose,M.,andWaldbusser,S.,

"StructureofManagementInformationforversion2ofthe

SimpleNetworkManagementProtocol(SNMPv2)",RFC1442,

SNMPResearch,Inc.,HughesLANSystems,DoverBeach

Consulting,Inc.,CarnegieMellonUniversity,April1993.



[4]McCloghrie,K.,andGalvin,J.,"PartyMIBforversion2

oftheSimpleNetworkManagementProtocol(SNMPv2)",RFC

1447,HughesLANSystems,TrustedInformationSystems,

April1993.



[5]Case,J.,McCloghrie,K.,Rose,M.,andWaldbusser,S.,

"TransportMappingsforversion2oftheSimpleNetwork

ManagementProtocol(SNMPv2)",RFC1449,SNMPResearch,

Inc.,HughesLANSystems,DoverBeachConsulting,Inc.,

CarnegieMellonUniversity,April1993.



[6]Galvin,J.,andMcCloghrie,K.,"SecurityProtocolsfor

version2oftheSimpleNetworkManagementProtocol

(SNMPv2)",RFC1446,TrustedInformationSystems,Hughes

LANSystems,April1993.



[7]Case,J.,McCloghrie,K.,Rose,M.,andWaldbusser,S.,

"ManagementInformationBaseforversion2oftheSimple

NetworkManagementProtocol(SNMPv2)",RFC1450,SNMP

Research,Inc.,HughesLANSystems,DoverBeach

Consulting,Inc.,CarnegieMellonUniversity,April1993.



8.作者地址

JamesM.Galvin

TrustedInformationSystems,Inc.

3060WashingtonRoad,Route97

Glenwood,MD21738

Phone:+1301854-6889

EMail:galvin@tis.com



KeithMcCloghrie

HughesLANSystems

1225CharlestonRoad

MountainView,CA94043

US

Phone:+14159667934

Email:kzm@hls.com