1、介紹
本文是網絡標準管理框架第三版本的介紹,條款取自SNMPv3,具有多種用途。
首先,它描述了SNMP第三版本(SNMPv3)規范與SNMP第一版本(SNMPv2)及
SNMP第二版本(SNMPv1)之間的關系。
第二,它提供了包含相關規范的多種文檔的路徑。
第三,本文提供了相關詳細說明文檔的簡單易讀的內容摘要。
本文有意從本質上指導,也許有時過于簡化。如果本文檔與本文標記的細節文檔之間發
生矛盾,以細節文檔為主。
進一步來講,細節文檔為了詳細說明與各種構成模塊之間精確定義的接口,而與這些構
成模塊保持分離。這個路徑文檔為了可讀性而采取不同的途徑提供一個包括多種構成模塊的
完整的看法。
2、網絡標準管理框架
第三版網絡標準管理框架起源并構建于原來的第一版網絡管理框架(SNMPv1)和第
二版網絡管理框架(SNMPv2)的基礎上。
所有的版本(SNMPv1,SNMPv2,SNMPv3)的網絡管理框架具有相同的基本的框架和成
分。而且,所有版本的網絡標準框架規范具有相同的體系結構。
2.1基本框架和成分
企業配置的網絡標準管理框架包括四項基本的成分:
? 一些(通常是許多)被管理結點,每個都包括SNMP實體可提供管理設備的遠程訪問
(一般叫做代理);
? 至少一個SNMP實體和相關的管理應用(一般叫做管理器)
? 管理協議被用來在SNMP實體間傳送管理信息
? 管理信息
管理協議用來在SNMP實體,如管理器、代理,之間傳送管理信息。
網絡標準框架的基本結構在SNMP的各種版本,如SNMPv1,SNMPv2,SNMPv3,是一
致的。
2.2網絡標準管理框架的體系結構
網絡標準框架的詳細說明是基于模塊的體系結構。這種框架不僅僅是為動態數據提供的
一種協議。它包括:
? 數據定義語言,
? 管理信息定義(管理信息庫,MIB),
? 協議定義,
? 安全性和管理
框架逐漸由SNMPv1,發展成SNMPv2,直到SNMPv3,每一個體系結構的成分的定義演
變得日益豐富、清晰,但是基礎的體系結構保持一致。
這種模塊性設計的最初動機是為了適應在RFC1052[14]中定義的框架結構的發展。最初
的設想是用這種性能來減輕基于SNMP管理的網絡到基于OSI協議的網絡的傳輸的負擔。
結果,這種框架結構卻在獨立于協議的數據定義語言和獨立于MIB協議的管理信息庫方面
取得成功,這種分開設計允許替換基于SNMP的協議而不需要重新定義或重新建立管理信
息。歷史證明這種體系結構是出于錯誤動機的正確選擇,事實證明,這種結構體系更加靈活
地完成了從SNMPv1到SNMPv2以及從SNMPv2到SNMPv3版本的轉換,遠勝于基于簡單
網絡管理協議的管理網絡的轉換。
SNMPv3的框架的構造和拓展的構建原則:
? 參考SNMPv2版本,構建四項基本結構成分
? 運用相同的分層原則定義安全性和管理部分的新性能
熟悉SNMPv1和SNMPv2管理框架結構的讀者會發現SNMPv3管理框架中有相似的
概念。但請注意,在一些情況下,術語的含義略有不同。
3、SNMPv1管理框架
最初的網絡標準管理框架(SNMPv1)定義下列文檔:
? STD16,RFC1155[1]定義了管理信息結構(SMI),是為方便管理而制定的描述和命
名對象的機制。
? STD16,RFC1212[2]定義了更加簡潔的描述機制來描述和命名管理信息的對象,但完
全與SMI保持一直。
? STD15,RFC1157[3]定義了簡單網絡管理協議,該協議用來網絡訪問被管理設備和產
生事件通知。注意,此文檔首次定義了一系列事件通知。
另外,下面兩個文檔一般和這三個文檔聯系在一起:
? STD17,RFC1213[13]定義了基本的管理信息。
? RFC1215[25]定義了簡潔描述機制來定義事件通知,也就是在SNMPv1版本中定義
的陷阱。該文檔在簡單通知也詳細說明了RFC1157中的一般陷阱。
這些文檔描述了第一版SNMP框架的四個部分。
3.1SNMPv1數據定義語言
前兩個和最后一個文檔描述了SNMPv1的數據定義語言。注意,這是因為最初要求SMI
必須獨立于協議,前兩個SMI文檔沒有提供定義事件通知(陷阱)的定義方式。而SNMP
協議文檔定義了一些事件通知(一般陷阱)和定義其他的事件告警的方法。最后一個文檔詳
細說明運用SNMPv1協議直接定義事件通知的方法。與此同時,陷阱在標準網絡管理結構
的應用引起爭議。例如,RFC1215以建議的身份提出而一直沒有進一步修改,因為大家堅
信第二版SNMP的框架將代替第一版。注意SNMPv1的數據定義語言部分參照SMIv1.
3.2、管理信息
前兩個文檔描述的數據定義語言第一次被用來定義現在不再使用的MIB-1(在RFC
1066[12]中詳細闡述),隨后用來定義MIB-II(在RFC1213[13]中詳細闡述)。
而后的,當MIB-II公布后,一種由多個工作組制定定義網絡標準管理信息庫的一個文
件不同的定義方式,代替了最初由單獨一個委員會制定的方式。然而,許多并行和分布式的
小型MIB文檔隨授權組應運而生,詳細說明網絡標準MIB的焦點部分,由那些從事特殊領
域包括網絡管理,系統管理,應用管理的諸多方面問題的專家們制定。
3.3協議操作
第三個文檔,STD15,描述SNMPv1協議操作由協議數據單元(PDUs)的綁定變量完
成,描述了SNMPv1的信息格式。SNMPv1定義的操作有:get,get-next,get-response,
set-request,和trap。也定義了面向無連接傳輸SNMP的典型分層。
3.4SNMPv1的安全性與管理
STD15也描述了安全性與管理的方法。許多概念,特別是關于安全性的,在SNMPv3
框架中繼續應用并得以擴展延伸。
SNMPv1框架描述了SNMPv1PDUs在SNMP實體和不同的應用實體和協議實體的
SNMP的消息封裝。在SNMPv3中各自重新命名了應用與實體。
SNMPv1框架也引入了支持一個或多個授權配置的授權服務。另外SNMPv3還定義了
其他的安全參數:私有。(注意:一些關于安全性共同體的文獻將SNMPv3的安全性能描述
為具有數據完整性鑒別,數據源鑒別,和機密性鑒別)。這種模型的性能改變和增加了
SNMPv3框架的安全性。
最后,SNMPv1引入了基于SNMPMIB視圖概念的訪問控制。SNMPv3框架中闡述了
基本一致的基于視圖的訪問控制的概念。由此,SNMPv3提供了控制被管理設備上的信息
的方法。
然而,當SNMPv1框架期望定義多種授權方案時,它僅僅在共同體字符串的基礎上定
義了一些瑣碎的授權。這是SNMPv1框架廣為人知的基本缺陷,但那時商用級的安全性設
計很有爭議,無法統一,因為對于不同的用戶來說“安全性”意味著許多不同的含義。歸根
結底,因為許多用戶并不需要強大的安全機制。SNMPv1設計了一個將在今后實現的獨立
的提供授權服務的模塊。SNMPv3框架應用了該模塊,并定義為其的子系統。
4SNMPv2管理框架
SNMPv2管理框架在[4-9]中全面描述了共存和SNMPv1與SNMPv2轉換的問題[10]。
SNMPv2較SNMPv1有如下優點:
? 擴展數據類型(例如,64位計數器)
? 改善效率和性能(取塊操作)
? 事件通知確認(消息操作)
? 豐富的錯誤控制(差錯與例外)
? 改進設置,尤其是行的創建與刪除
? 精密調整的數據定義語言
然而,如上描述的SNMPv2框架因為沒有達到原來的設計目標而一直沒有完成。這些
沒有完成的目標包括預期的所謂的商業級的安全性與管理傳輸,包括:
? 授權:數據源鑒別,消息完整性和一些方面的重發保護;
? 私有:機密性;
? 授權與訪問控制;
? 匹配的遠程配置和這些方面的管理性能。
SNMPv3管理框架,如本文還有一些相關的文檔,闡述了這些重要的不足。
5. SNMPv3工作組
本文和相關文檔由Inte.net工程任務組(IETF)的SNMPv3工作組提出。SNMPv3工
作組授權準備下一代SNMP建議。工作組的目標是為下一代SNMP核心功能的標準提出一
系列必要的文檔。這個在下一代SNMP中最關鍵的需求是:安全性與管理,使得在基于SNMP
管理事物的安全性能可用于希望使用SNMPv3管理網絡的用戶。這些組成網絡的系統和這
些系統中的應用包括管理器對代理,代理對管理器,管理器對管理器之間的傳輸。
在工作組得到授權許多年以前,有許多旨在安全性一體化和改進SNMP的活動。它們
包括:
? “SNMP安全性”約1991-1992[RFC1351-RFC1353]
? “SMP”約1992-1993
? “基于用戶的SNMPv2”約1993-1995[RFC1441-RFC1452]
每一項改進集合了商業等級,產業力度的安全性能包括授權,私有,授權,基于視圖
的訪問控制和管理,包括遠程配置。
這些改進最終促進了SNMPv2管理框架的發展,在RFC1902-1908中詳細記錄。然而,
RFC文檔中記述的框架結構沒有基于其本身的安全性和管理的參考標準;然而,它與多種
安全性與管理框架相聯系,它們包括:
? “基于共同體的SNMPv2”(SNMPv2)[RFC1901],
? “SNMPv2”[RFC1909-1910]
? “SNMPv2*”
IETF認可SNMPv2c,但并不認可SNMPv2u和SNMPv2的安全性與管理。
顧問組提出專用SNMP的發展建議,集中SNMPv2u和SNMPv2*的概念與技巧的基
礎上,SNMPv3工作組具有提出下一代SNMP專有系列規范的授權。
為此,工作組憲章包括如下目標:
? 適應廣泛的需要不同管理需要的操作環境;
? 實現SNMPv3以前多種版本間方便的轉換;
? 實現方便的設置與維護;
SNMPv3工作組的最初工作集中在安全性和管理,包括:
? 授權和私有,
? 授權和基于視圖的訪問控制,
? 上述基于標準的遠程配置。
SNMPv3工作組不想重蹈覆轍,但卻重新使用SNMPv2起草的標準文檔,例如,使
用RFCs1902到1908的部分設計除上述關注的問題。
然而,SNMPv3工作組的主要貢獻在于傾盡全力闡述了在整個過程中安全性的缺少與
管理不足,并在此過程中創造了藝術級的管理。他們提供了基于模塊體系結構的設計,強
調分層結構的進化性能。最終使SNMPv3比SNMPv2具有額外的安全性與管理性能。因此,
工作組成功的完成了其特定的目標,不但得到IETF的承認,而且完善了其安全性和原理
功能。
6 SNMPv3框架結構的詳細描述
SNMPv3的管理結構的規范在不同的文檔里以標準組建的形式各自獨立。這正是IETF
的目的所在,適當的保護,任何一個或所有的文檔個體在需求改變是可以被修改、升級或
替換,借此容納新的認知,和新的技術。
SNMPv3管理體系結構的定義與實現切實可行參考并結合SNMPv2管理體系結構,并
且在商業性方面優于SNMPv2。
SNMPv3體系結構增加了在安全性和管理方面的規范。
本文在繼承以前各版本的基礎上詳細說明了SNMPv3的管理體系結構,按照以下四項
主要原因組織說明:
? 數據定義語言,
? 管理信息庫模型,
? 協議操作,和
? 安全性和管理
前三種文檔系列結合SNMPv2定義,第四種文檔系列是SNMPv3中全新的部分,但是
也是建立于以前相關著作的基礎上的。
6.1數據定義語言
數據定義語言在STD58,RFC2578的“管理信息結構第二版(SMIv2)”及相關規范
中詳細說明。這些文檔由其他結構各自獨立發展來的RFC1902-1904[4-6]修正而來,并由草
案標準晉升為STD58,RFC2578-2580[26-28]發表。
管理信息結構(SMIv2)定義了基本數據類型,對象模型,和編寫、修改MIB模塊的
規則。相關的說明文檔包括:STD58,RFC2579,2580。修正的數據定義語言部分參考
SMIv2.
STD58,RFC2579,"SMIv2的正文約定"[27],定義了最初的有利于人們讀寫的MIB模
塊的縮寫速記詞。
STD58,RFC2580,“SMIv2的一致性聲明”[28],定義了用于描述代理執行和某些特
別執行的容量一致性聲明的格式。
6.2MIB模型
MIB模型一般包括對象定義,可能包括事件通知定義,有時也包括根據適當的對象和
事件通知組進行一致性闡述。同樣的,MIB模塊定義了被管理結點設備的管理信息,使其
可供管理代理進行遠程訪問,傳送由管理應用產生的管理協議。
MIB模塊根據定義數據定義語言文檔的規則定義,主要是附帶相關規范的SMI。
基于標準的龐大的,逐步完善的MIB模塊,根據標準協議[STD1,RFC2400]定時進行
更新。根據該著述,共有近100中基于標準的MIB模塊,共定義了總數近10,000種的對
象。另外,MIB模塊還包括一個更加巨大,而且日益壯大的由各種制造商、科研團體、銀
行、以及未知的和不計其數的被定義對象的企業私有MIB。一般而言,無論用那一版數據
定義語言定義的MIB模塊定義的管理信息,都可以被任何版本的協議使用。例如,按照
SNMPv1SMI定義的MIB模塊和SNMPv3管理體系結構是兼容的,可被傳送到指定的地點。
而且,根據SNMPv2定義的SNMPv2SMI(SMIv2)的MIB模塊與SNMPv1協議操作也是兼
容的,可被傳送的。然而,也存在顯著的例外:按照SMIv2格式定義的64位計數器不能由
SNMPv1的引擎傳送。
6.3協議操作和傳輸映射
SNMPv3框架的協議操作和傳輸影射的規范參考SNMPv2框架的兩個文件。
RFC1905,“簡單網絡管理協議第二版的協議操作”[7]詳細闡述了協議操作的規范。
SNMPv3框架的設計允許各部分的體系結構獨立的進化。例如,可以在框架中定義新的協議
操作規范用以增加新的協議操作。
RFC1906“簡單網絡管理協議第二版的傳輸映射”[8]詳細闡述了傳輸映射的規范。
6.4 SNMPv3的安全性和管理
SNMPv3工作組定義了SNMPv3系列文檔,包括現在的七個文檔:
RFC2570“國際標準網絡管理框架第三版的介紹”,即本文。
RFC2571“描述SNMP管理框架的體系結構”[15],全面描述其體系結構,重點強調
安全性和管理的體系結構。
RFC2572“簡單網絡管理協議的消息處理和分配”[16],描述了SNMP協議引擎中的
多信息處理模型和消息分配部分。
RFC2573“SNMP的應用”[17],描述了與SNMPv3引擎相關的五種應用和應用進程
的原理。
RFC2574“簡單網絡管理協議的基于用戶的安全模塊”[18],描述了提供SNMP消息
級的安全性的安全威脅、安全機制、草案和支持數據。
RFC2575“簡單網絡管理協議的基于視圖的訪問控制模型”[19],描述了基于用戶的
訪問控制在命令應答器與通知發生器中的應用。
發展的著述“國際標準網絡管理框架的第一,第二與第三版本的共存”[20],描述了
SNMPv3管理框架,SNMPv2管理框架,和SNMPv1管理框架的共存。
7文檔摘要
下面的部分將對各文檔提供比前面更詳細一點的概要介紹。
7.1管理信息結構
由被管理設備收集的管理信息并不實際存儲,條款取自管理信息庫(MIB)。MIB模塊
定義了收集相關信息的對象。這些模塊使用SNMPMIB模塊語言編寫,包括OSI的抽象
注釋語言第一版(ASN.1)[11]。STD58,RFC2578,2579,2580,共同定義了MIB模塊語
言,詳細說明定義對象的基本數據類型,也詳細說明了正文約定的簡要說明數據類型的核
心系列,也詳細說明了對象標識符(OID)的管理分配。
SMI可以分為三部分:模型定義,對象定義,和通知定義。
(1)模型定義用來描述信息模型。ASN.1宏,模塊定義用來簡明的傳達信息模型語義。
(2)對象定義用來描述被管理設備,ASN.1宏,對象類型用來簡明的傳達被管理對象的語
法和語義。
(3)通知定義運用在管理信息的主動傳輸。ASN.1宏,通知類型用來簡單的傳達通知的語
法和語義。
7.1.1SMI的基本規范
STD58,RFC2578詳細說明了MIB模塊語言的基本數據類型,包括:Integer32,
enumeratedintegers,Unsigned32,Gauge32,Counter32,Counter64,TimeTicks,INTEGER,
OCTETSTRING,OBJECTIDENTIFIER,IpAddress,Opaque,andBITS.也包括一些對象標識符
的賦值。STD58,RFC2578進一步定義了MIB模塊語言的如下構造:
? IMPORTS允許詳細解釋應用于MIB模塊的各條款,但在其他的MIB模塊中定義。
? MODULE-IDENTITY指派MIB模塊的描述和管理信息,例如聯系和修正歷史。
? OBJECT-IDENTITY和OID的值分配給指定的OID。
? OBJECT-TYPE用來指派被管理設備的數據類型,狀態和語義。
? SEQUENCE類型分配給表格中的分縱覽列出的對象。
? NOTIFICATION-TYPE創立用來指定事件通知。
7.1.2正文約定
當描述MIB摸塊時,經常利用縮寫的語義來表述一系列具有相似特性的對象。這樣利用
基本數據類型定義一種新的數據類型。每種數據類型另起一個新名,指定一個更加嚴格的基
本類別。這些新定義的類別就是正文約定,更有利于人們閱讀MIB模塊和更利于潛在的智能
管理。這就是STD58,RFC2579,SMIv2的正文約定[27],的目的所在,定義一種MIB模塊語
言的結構,TEXT-CONVENYION,用來定義新的類型,并且用來指定對所有MIB都適用的正文
約定。
7.1.3一致性聲明
也許,結合目前達到的水平的低端執行,定義合適的低端執行是很有用的。這正是
STD58,RFC2580,SMIv2的一致性闡述[28],定義了MIB模塊語言的目的所在。有兩種構造:
(1) 當描述向代理發出關于對象、事件通知定義的請求時使用一致性聲明。
MODULE-COMPLIANCE結構就是用來簡明的傳送這種請求。
(2) 當描述向代理發出關于對象、事件通知定義的性能時使用性能聲明。
AGENT-CAPABILITIES結構就是被用來簡明傳送這種性能的。
最后,收集關于對象和相關的事件通知共同組成具有一致性的整體。OBJECT-GROUP結
構就是用來簡明傳送這些對象和對象組語義的。NOTIFICATON-GROUP結構就是用來簡明傳送
這些事件通知和事件通知組語義的。
7.2協議操作
管理協議提供了在代理站和管理站之間傳送管理信息的消息交換。這種消息格式是被封
裝為協議數據單元的消息包(PDU)。
RFC1905,SNMPv2的協議操作,的目的在于定義發送和接收協議數據單元的協議的操
作。
7.3傳輸映射
SNMP消息廣泛適用于各種協議族,RFC1906,SNMPv2的傳輸映射,的目的在于定義
SNMP消息在初始化設置的傳輸區域是如何映射的。其他的映射將在今后定義。
雖然,已經定義了多種映射,UDP的映射方式是首選的映射方式。同樣的,為了提供
最大限度的互操作性,配置其他影射的系統也提供UDP映射的代理服務。
7.4協議使用設備
RFC1907,SNMPv2的管理信息庫[9],的目的在于定義可用于SNMPv2實體的被管理
設備。
7.5體系結構/安全性和管理
RFC2571,描述SNMP管理框架的體系結構[15],的目的在于定義詳細說明SNMP管
理框架的體系結構。在闡述一般的體系結構的同時強調與安全性和管理相關的方面。它定義
了貫穿SNMPv3管理框架始終的一些術語,因此,在這里闡明并展開其命名:
? 引擎和應用
? 實體(服務供應商例如包含引擎的代理和管理器)
? 認證(服務用戶),和
? 管理信息,包括對多種邏輯上下文的支持。
本文包括一個小型的MIB模塊,該模塊可以被所有的授權SNMPv3協議引擎執行。
7.6消息處理和分配(MPD)
RFC2572,“簡單網絡管理的消息處理和分配”[16],描述了在SNMP結構體系中消息
的處理和分配。它定義了存在多種版本的SNMP消息的分配到真確的SNMP消息處理模塊
的進程,然后分配協議數據單元到SNMP的應用程序。本文件也描述了一個消息處理模型,
即SNMPv3的消息處理模塊。
SNMPV3協議引擎必須支持至少一個消息處理模塊。一個SNMPv3引擎可以支持一個
以上的消息處理模塊,例如在一個多協議混雜系統可以同時支持SNMPv3,SNMPv1和/或
SNMPv2c。
7.7SNMP的應用
RFC2573,“SNMP的應用”,的目的在于描述五種類型的與SNMP引擎相關的應用。
它們是:命令發生器、命令響應器、通知產生器、通知接收器、和代理轉發器。
本文也定義了為詳細描述管理操作(包括通知),通知過濾,和代理轉發對象的
MIB模塊。
7.8基于用戶的安全模塊(USM)
RFC2574,“簡單網絡管理協議第三版(SNMPv3)的基于用戶的安全模塊(USM)”,
描述了SNMPv3的基于用戶的安全模塊。它定義了提供SNMP消息級安全性的程序原理。
本文描述了兩種主要的和兩種次要的基于用戶的安全模塊所要防范的威脅。它們是:信
息的修改、偽裝、信息流的修改和泄露。
USM使用MD5[21]與安全擾碼運算法則[22]作為主要的散列算法[23]來確保數據的完整
性。
? 直接確保數據不遭到修改的攻擊
? 間接確保數據源授權
? 防止偽裝攻擊
USM使用松散的同步時鐘計時器來防止信息流被修改。自動同步時鐘機制遵循協議
中不依賴第三方時間源和相關的安全考慮制定。
USM在密碼塊序列模式(CBC)中使用數據加密標準(DES)[24]來防止泄露。USM
中的DES功能為可選項,主要是因為許多國家的出口和使用限制使其包括加密技術再內難
以出口和使用。
本文也包括適合遠程控制與管理USM的配置參數的MIB,包括密鑰分配方式和密鑰
管理方式。
如同可以提供多種授權與私有協議,實體可以同時提供多種安全模式。USM使用的所
有協議都建立在預先設置密鑰的基礎上,例如,私有密鑰機制。SNMPv3體系結構允許不
對稱機制和協議(通常被叫做“公用密鑰加密算法”)然而盡管如此,還沒有公布的可供
SNMPv3安全模型使用的公用密鑰加密算法。
7.9基于視圖的訪問控制(VACM)
RFC2575,“簡單網絡管理協議(SNMP)的基于視圖的訪問控制”,的目的在于描述應
用于SNMP體系結構的訪問控制模型。VACM可以同時應用于含帶多消息處理模塊和多安
全模塊的單一引擎的執行。
在一個引擎的執行中,體系結構可能存在多種,不同的,同時出現并處于激活狀態的訪
問控制模塊,然而在實踐中卻很少有“真正的”和“幾乎”難以實現的同時支持多消息處
理模塊和多安全模塊。
7.10SNMPv3的共存與轉換
“國際網絡管理框架的第一,第二和第三版本的共存”的目的在于描述SNMPv3管理框
架,SNMPv2的框架和最初的SNMPv1的管理框架的共存。本文特別描述了如下四方面的
共存:
? 從SMIv1到SMIv2格式的MIB文檔的共存
? 通知參數的映射
? 支持多種版本的SNMP的多協議網絡的共存方式,特別是多協議執行協議操作的處理,
例如代理的執行
? SNMPv1消息處理模型和基于共同體的安全模型,提供使SNMPv1、SNMPv2適應基
于視圖的訪問控制模型的轉化機制。
8安全性考慮
本文作為路標文檔,沒有提供新的安全考慮。讀者可以參考相關的參考文獻汲取安全考
慮的信息。
9作者地址
JeffreyCase
SNMPResearch,Inc.
3001KimberlinHeightsRoad
Knoxville,TN37920-9716
USA
Phone:+14235731434
EMail:case@snmp.com
RussMundy
TISLabsatNetworkAssociates
3060WashingtonRd
Glenwood,MD21738
USA
Phone:+13018546889
EMail:mundy@tislabs.com
DavidPartain
EricssonRadioSystems
ResearchandInnovation
P.O.Box1248
SE-58112Linkoping
Sweden
Phone:+4613284144
EMail:David.Partain@ericsson.com
BobStewart
CiscoSystems,Inc.
170WestTasmanDrive
SanJose,CA95134-1706
U.S.A.
Phone:+16036546923
EMail:bstewart@cisco.com
10參考書目
[1]Rose,M.andK.McCloghrie,"StructureandIdentificationof
ManagementInformationforTCP/IP-basedinternets",STD16,RFC
1155,May1990.
[2]Rose,M.andK.McCloghrie,"ConciseMIBDefinitions",STD16,
RFC1212,March1991.
[3]Case,J.,Fedor,M.,Schoffstall,M.andJ.Davin,"Simple
NetworkManagementProtocol",STD15,RFC1157,May1990.
[4]SNMPv2WorkingGroup,Case,J.,McCloghrie,K.,Rose,M.,andS.
Waldbusser,"StructureofManagementInformationforVersion2
oftheSimpleNetworkManagementProtocol(SNMPv2)",RFC1902,
January1996.
[5]SNMPv2WorkingGroup,Case,J.,McCloghrie,K.,Rose,M.,andS.
Waldbusser,"TextualConventionsforVersion2oftheSimple
NetworkManagementProtocol(SNMPv2)",RFC1903,January1996.
[6]SNMPv2WorkingGroup,Case,J.,McCloghrie,K.,Rose,M.,andS.
Waldbusser,"ConformanceStatementsforVersion2oftheSimple
NetworkManagementProtocol(SNMPv2)",RFC1904,January1996.
[7]SNMPv2WorkingGroup,Case,J.,McCloghrie,K.,Rose,M.andS.
Waldbusser,"ProtocolOperationsforVersion2oftheSimple
NetworkManagementProtocol(SNMPv2)",RFC1905,January1996.
[8]SNMPv2WorkingGroup,Case,J.,McCloghrie,K.,Rose,M.andS.
Waldbusser,"TransportMappingsforVersion2oftheSimple
NetworkManagementProtocol(SNMPv2)",RFC1906,January1996.
[9]SNMPv2WorkingGroup,Case,J.,McCloghrie,K.,Rose,M.andS.
Waldbusser,"ManagementInformationBaseforVersion2ofthe
SimpleNetworkManagementProtocol(SNMPv2)",RFC1907,January
1996.
[10]SNMPv2WorkingGroup,Case,J.,McCloghrie,K.,Rose,M.andS.
Waldbusser,"CoexistencebetweenVersion1andVersion2ofthe
Internet-standardNetworkManagementFramework",RFC1908,
January1996.
[11]Informationprocessingsystems-OpenSystemsInterconnection-
SpecificationofAbstractSyntaxNotationOne(ASN.1),
InternationalOrganizationforStandardization.International
Standard8824,(December,1987).
[12]McCloghrie,K.andM.Rose,"ManagementInformationBasefor
NetworkManagementofTCP/IP-basedInternets",RFC1066,August
1988.
[13]McCloghrie,K.andM.Rose,"ManagementInformationBasefor
NetworkManagementofTCP/IP-basedinternets:MIB-II,STD17,
RFC1213,March1991.
[14]Cerf,V.,"IABRecommendationsfortheDevelopmentofInternet
NetworkManagementStandards",RFC1052,April1988.
[15]Harrington,D.,Presuhn,R.andB.Wijnen,"AnArchitecturefor
DescribingSNMPManagementFrameworks",RFC2571,April1999.
[16]Case,J.,Harrington,D.,Presuhn,R.andB.Wijnen,"Message
ProcessingandDispatchingfortheSimpleNetworkManagement
Protocol(SNMP)",RFC2572,April1999.
[17]Levi,D.,Meyer,P.andB.Stewart,"SNMPApplications",RFC
2573,April1999.
[18]Blumenthal,U.andB.Wijnen,"TheUser-BasedSecurityModelfor
Version3oftheSimpleNetworkManagementProtocol(SNMPv3)",
RFC2574,April1999.
[19]Wijnen,B.,Presuhn,R.andK.McCloghrie,"View-basedAclearcase/" target="_blank" >ccess
ControlModelfortheSimpleNetworkManagementProtocol
(SNMP)",RFC2575,April1999.
[20]Frye,R.,Levi,D.,Routhier,S.,andB.Wijnen,"Coexistence
betweenVersion1,Version2,andVersion3oftheInternet-
standardNetworkManagementFramework",WorkinProgress.
[21]Rivest,R.,"MessageDigestAlgorithmMD5",RFC1321,April
1992.
[22]SecureHashAlgorithm.NISTFIPS180-1,(April,1995)
http://csrc.nist.gov/fips/fip180-1.txt(ASCII)
http://csrc.nist.gov/fips/fip180-1.ps(Postscript)
[23]Krawczyk,H.,Bellare,M.andR.Canetti,"HMAC:Keyed-Hashing
forMessageAuthentication",RFC2104,February1997.
[24]DataEncryptionStandard,NationalInstituteofStandardsand
Technology.FederalInformationProcessingStandard(FIPS)
Publication46-1.SupersedesFIPSPublication46,(January,
1977;reaffirmedJanuary,1988).
[25]Rose,M.,"AConventionforDefiningTrapsforusewiththe
SNMP",RFC1215,March1991.
[26]McCloghrie,K.,Perkins,D.,Schoenwaelder,J.,Case,J.,Rose,
M.andS.Waldbusser,"StructureofManagementInformation
Version2(SMIv2)",STD58,RFC2578,April1999.
[27]McCloghrie,K.,Perkins,D.,Schoenwaelder,J.,Case,J.,Rose,
M.andS.Waldbusser,"TextualConventionsforSMIv2",STD58,
RFC2579,April1999.
[28]McCloghrie,K.,Perkins,D.,Schoenwaelder,J.,Case,J.,Rose,
M.andS.Waldbusser,"ConformanceStatementsforSMIv2",STD
58,RFC2580,April1999.
11版權聲明
Copyright(C)TheInternetSociety(1998).AllRightsReserved.
Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.
Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.
Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE."
12.鳴謝
感謝互聯網協會提供的RFC編者基金。