对简单网络管理协议（SNMP）管理框架的体系结构的描述RFC3411外文翻译

《对简单网络管理协议（SNMP）管理框架的体系结构的描述RFC3411外文翻译》由会员分享，可在线阅读，更多相关《对简单网络管理协议（SNMP）管理框架的体系结构的描述RFC3411外文翻译（19页珍藏版）》请在装配图网上搜索。

1、毕业论文（设计）外文翻译题 目： 对简单网络管理协议（SNMP）管理框架的体系结构的描述 系部名称： 信息工程系 专业班级： 电气103 学生姓名： 冯东阳 学 号： 201007084328 指导教师： 方向前 教师职称： 高级工程师 2014 年 3 月 18 日中文翻译：请求描述3411-对简单网络管理协议（SNMP）管理框架的体系结构的描述网络工作组：D.哈灵顿 征求意见：3411 Enterasys网络 标准：62 R. Presuhn 废弃：2571 BMC软件公司 类别：标准跟踪 B. Wijnen 朗讯科技 2002年12月文本备忘：本文档描述了一个Internet标准跟踪协议

2、的互联网社区，需要进一步进行讨论和建议改进。请参考“互联网的 正式协议标准”（STD1）最新版本。本备忘录的发布不受任何限制。版权声明：版权所有（C）互联网协会（2002）。保留所有权利。摘要本文档介绍了简单的网络架构管理协议（SNMP）的管理框架。架构的设计是模块化以允许SNMP协议在标准的时间内演变。该体系结构的主要部分是SNMP引擎包含一个消息处理子系统，安全子系统和访问控制子系统，并提供具有对管理数据的处理的特定功能的应用程序。本文件rfc2571废弃。本文档定义的词汇用于描述SNMP管理框架，这个架构用于说明SNMP管理框架的主要部分。本文件并不提供SNMP的一般性介绍，其他的一些文

3、档和书籍可以提供一个更好的对SNMP的介绍,本文也不提供的SNMP的历史。这也是可以在书和其他文件中找到。第1章描述这个架构的目的，目标和设计决策第2节介绍了各类文档中对SNMP框架的定义（元素的），以及他们如何融入这个体系结构。它还给文件提供了一个最小的路线图，其中先前定义的SNMP框架。 第3节详细介绍这种架构及其作品的词汇。这部分对于理解其余部分很重要，以及这个文档怎么去编写以适应这个架构。第4节描述用于此体系结构内的各种子系统，模型和应用程序之间的抽象服务接口的原语。第5节定义这个架构中使用仪器的SNMP实体管理对象的集合。第6，7，8，9，10和11是行政性质。附录A包含了设计师的设

4、计的预期以适应到这个框架结构中的模型。关键词“必须”，“必须不”，“要求”，“应”，“不应”， “应该”，“不应该”，“建议”，“可以”，而在这个“可选”文件是在RFC2119中解释。1.2 SNMP SNMP管理系统包含：-在每一个SNMP实体种有几个（可能有多个）节点，每个节点包含访问管理规范（传统上称为代理）的命令应答器与通知的应用程序;-一个SNMP实体至少包含命令生成器和/或接收通知的应用程序（传统上被称为经理）；- 一个管理协议，用来传递在SNMP实体间的管理信息。SNMP实体执行命令发生器、通知接收的应用程序监视和控制管主要元件。主要元件是那些被SNMP监测和控制下访问他们的管理

5、信息的诸如主机，路由器，终端服务器等设备。本文件的目的是来定义一个可以改进的，以在各种配置和环境中实现有效的管理的体系结构。该体系结构被设计成满足实施以下的需要：- 最小的SNMP实体的命令响应和/或通知发生器（传统上被称为SNMP代理），- SNMP实体代理转发应用程序（传统上称为SNMP代理的代理），- 命令行驱动的SNMP实体命令生成器和/或接收通知的应用程序（传统上称为SNMP命令行管理者），-命令生成器和/或接收通知，加上命令应答器和/或通知发生器（传统上称为SNMP中层管理人员或双作用的实体）的SNMP实体，- 用命令生成器和/或通知接收器，甚至其他类型的用于管理一个潜在的非常大量

6、的管理节点（传统上被称为（网络）管理工作站）的应用程序的SNMP实体。1.3. 架构的目标这种体系结构是由以下的目标驱动：- 尽可能使用现有的材料。它在很大程度上基于以前的工作，非正式地称为SNMPv2u和SNMPv2*，基于开启SNMPv2p。- 地址需要进行安全设置的支持，这被认为是在SNMPv1和SNMPv2中最重要的缺陷- 使部分架构符合标准草案成为可能，即使这个草案的共识并未被所有的作品所采用。- 定义一个架构，以便允许已经被定义和即将被定义的架构长时间的符合SNMP框架。- 使SNMP尽可能的保持简单。- 使它相对方便的让大家一致履行该协议- 使人们有可能升级部分SNMP以让它作为

7、新的可用的方法，而无需中断整个SNMP框架。- 使其能够支持大型网络中功能的要求，使配套功能为代价，直接获得于特征的支持。1.4。架构的安全要求几个经典的对网络协议的威胁都适用于这个管理问题，因此将适用于在一个SNMP管理框架中使用的任何安全模型。其他威胁并不适用于这个管理问题。本节讨论主要威胁，次要威胁和哪些是不太重要的威胁。主要威胁抵消的这种架构中使用的任何安全模型应该提供的保护是：修改信息修改威胁的危险，一些未经授权的实体可以以改变代表授权委托人这样的方式授权本金产生的在途SNMP消息来实现未经授权的管理操作，包括伪造一个对象的值。伪装威胁伪装威胁的危险是不授权某些主体的管理操作不被授权

8、，但可以通过假设另一个具有相应权限的主体身份去尝试。二次威胁抵销的这种架构中使用的任何安全性模型应该提供的保护是：信息流被修改SNMP协议通常是基于一个可以服务工作在任何子网的无连接的传输服务。消息的重新排序，延迟或重放可以而且确实发生过很多这样的子网服务的自然运作。消息流改造的威胁是危险的消息可能会被恶意重新排序，延迟或重放到一个很危险的程度以至于可能发生通过子网服务的自然运作，以便实现未经授权的管理操作。泄露泄露威胁的危险是SNMP引擎之间的交流被窃听。防止这种威胁，可能需要依靠当地的一些政策和力量。针对该架构中的安全模型至少有两种威胁不需要保护，因为它们被认为在这方面是不太重要的。拒绝服

9、务安全模型不必试图解决范围广泛的代表授权用户的服务被拒绝的攻击。事实上，任何可行的管理协议在许多情况下都无法区分拒绝服务等攻击的网络故障的类型，所以被必须理所当然的处理掉。流量分析安全模型不必试图去解决流量分析的攻击，许多交通模式是可以预见的由相对少数的管理站可定期管理的实体，因此，没有显著的方式来防止流量分析。1.5。设计决策各种设计决策的制定要求支持体系结构的目标和安全要求：- 体系结构一个架构应该被定义用于标识文档之间的概念界限。子系统应该定义为它描述了一个SNMP框架的特定部分所提供的抽象服务。抽象服务接口，所描述的服务原语，定义文件之间的抽象的边界，是由一个SNMP框架的概念上的子系

10、统所提供的抽象服务。- 自包含的文件本身是程序的元素，加上这是需要处理的一个SNMP框架的特定部分内的MIB对象，所以应在同一文档中定义，并且尽可能的不在其他文档内被引用。而且这部分自包含文件被允许进行独立和自足的设计和记录，这与一般的SNMP MIB模块的方法一致。SNMP的部分随着时间的推移而变化，但描述SNMP的其他部分的文件都不会受到直接影响。这种模块化设计允许例如安全模型、认证和保密机制、消息格式在有需要时进行升级和补充。自包含的文档可以随着标准草案的不同的时间线而变化。这个规范本的模块并不意味着被作为强加实施任何具体要求的解释 - 威胁安全子系统中的安全模型应该防范的主要和次要威胁

11、：信息变更，伪装，消息流的修改和披露。他们不需要防范拒绝服务的攻击和流量分析。- 远程配置安全性和访问控制子系统添加了一整套新的SNMP配置参数。该安全子系统还需要在各种SNMP实体之间秘密的频繁变动。为了使这个安全子系统部署在大型作战环境中，这些SNMP参数必须是远程配置。- 控制的复杂性人们认识到，简单管理设备的生产商要通过SNMP保持使用最少的资源。同时，花费更多的资源来符合SNMP，并且提供更多的功能，需要更复杂的配置。他的设计试图使这种竞争在这两种环境中保持平衡，并允许更复杂的环境在逻辑上可以扩展简单的环境。编辑地址Bert Wijnen朗讯科技 Schagen 333461 GL林

12、斯霍滕 荷兰联系电话: +31 348-680-485电子邮件: 大卫哈林顿Enterasys网络 邮政信箱5005 工业路 35号 罗切斯特，新罕布什尔州03866-5005 美国联系电话: +1 603-337-2614电子邮件: 兰迪PresuhnBMC软件公司 北一街 2141号 San Jose，加利福尼亚95131 美国 联系电话：+1408-546-1006 传真：+1408-965-0359 电子邮件：版权声明版权所有（C）因特网协会（2002年）。保留所有权利。本文档及其译文可以拷贝和提供给他人，他有什么看法或解释或协助其实施的衍生作品可全部或部分编制，复制，出版和发行，没有

13、任何限制，前提是上述版权声明和本段内容包含在所有的拷贝和派生作品中。然而，本文档本身不得以任何方式修改，如删除版权声明或参考互联网协会或其他Internet组织，除了为制定互联网标准的目的需要，或需要把它翻译成英语以外的语言，在这种情况下，程序中定义的版权声明互联网标准过程中必须遵循。外文原文：RFC3411 - An Architecture for Describing Simple Network Management Protocol (SNMP) Management FrameworksNetwork Working Group D. HarringtonRequest for C

14、omments: 3411 Enterasys NetworksSTD: 62 R. PresuhnObsoletes: 2571 BMC Software, Inc.Category: Standards Track B. WijnenLucent TechnologiesDecember 2002An Architecture for Describing Simple Network Management Protocol (SNMP) Management FrameworksStatus of this MemoThis document specifies an Internet

15、standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.Cop

16、yright NoticeCopyright (C) The Internet Society (2002). All Rights Reserved.AbstractThis document describes an architecture for describing Simple Network Management Protocol (SNMP) Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards

17、 over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. This document obsoletes RFC2

18、571.This document defines a vocabulary for describing SNMP Management Frameworks, and an architecture for describing the major portions of SNMP Management Frameworks.This document does not provide a general introduction to SNMP. Other documents and books can provide a much better introduction to SNM

19、P. Nor does this document provide a history of SNMP. That also can be found in books and other documents.Section 1 describes the purpose, goals, and design decisions of this architecture.Section 2 describes various types of documents which define (elements of) SNMP Frameworks, and how they fit into

20、this architecture. It also provides a minimal road map to the documents which have previously defined SNMP frameworks.Section 3 details the vocabulary of this architecture and its pieces. This section is important for understanding the remaining sections, and for understanding documents which are wr

21、itten to fit within this architecture.Section 4 describes the primitives used for the abstract service interfaces between the various subsystems, models and applications within this architecture.Section 5 defines a collection of managed objects used to instrument SNMP entities within this architectu

22、re.Sections 6, 7, 8, 9, 10 and 11 are administrative in nature.Appendix A contains guidelines for designers of Models which are expected to fit within this architecture.The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT,SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to

23、 be interpreted as described in RFC2119.1.2. SNMPAn SNMP management system contains:- several (potentially many) nodes, each with an SNMP entity containing command responder and notification originator applications, which have access to management instrumentation (traditionally called agents);- at l

24、east one SNMP entity containing command generator and/or notification receiver applications (traditionally called a manager) and,- a management protocol, used to convey management information between the SNMP entities.SNMP entities executing command generator and notification receiver applications m

25、onitor and control managed elements. Managed elements are devices such as hosts, routers, terminal servers, etc., which are monitored and controlled via access to their management information.It is the purpose of this document to define an architecture which can evolve to realize effective managemen

26、t in a variety of configurations and environments. The architecture has been designed to meet the needs of implementations of:- minimal SNMP entities with command responder and/or notification originator applications (traditionally called SNMP agents),- SNMP entities with proxy forwarder application

27、s (traditionally called SNMP proxy agents),- command line driven SNMP entities with command generator and/or notification receiver applications (traditionally called SNMP command line managers),- SNMP entities with command generator and/or notification receiver, plus command responder and/or notific

28、ation originator applications (traditionally called SNMP mid-level managers or dual-role entities),- SNMP entities with command generator and/or notification receiver and possibly other types of applications for managing a potentially very large number of managed nodes (traditionally called (network

29、) management stations).1.3. Goals of this ArchitectureThis architecture was driven by the following goals:- Use existing materials as much as possible. It is heavily based on previous work, informally known as SNMPv2u and SNMPv2*, based in turn on SNMPv2p.- Address the need for secure SET support, w

30、hich is considered the most important deficiency in SNMPv1 and SNMPv2c.- Make it possible to move portions of the architecture forward in the standards track, even if consensus has not been reached on all pieces.- Define an architecture that allows for longevity of the SNMP Frameworks that have been

31、 and will be defined.- Keep SNMP as simple as possible.- Make it relatively inexpensive to deploy a minimal conforming implementation.- Make it possible to upgrade portions of SNMP as new approaches become available, without disrupting an entire SNMP framework.- Make it possible to support features

32、required in large networks, but make the expense of supporting a feature directly related to the support of the feature.1.4. Security Requirements of this ArchitectureSeveral of the classical threats to network protocols are applicable to the management problem and therefore would be applicable to a

33、ny Security Model used in an SNMP Management Framework. Other threats are not applicable to the management problem. This section discusses principal threats, secondary threats, and threats which are of lesser importance.The principal threats against which any Security Model used within this architec

34、ture SHOULD provide protection are:Modification of InformationThe modification threat is the danger that some unauthorized entity may alter in-transit SNMP messages generated on behalf of an authorized principal in such a way as to effect unauthorized management operations, including falsifying the

35、value of an object.MasqueradeThe masquerade threat is the danger that management operations not authorized for some principal may be attempted by assuming the identity of another principal that has the appropriate authorizations.Secondary threats against which any Security Model used within this arc

36、hitecture SHOULD provide protection are:Message Stream ModificationThe SNMP protocol is typically based upon a connectionless transport service which may operate over any subnetwork service. The re-ordering, delay or replay of messages can and does occur through the natural operation of many such su

37、bnetwork services. The message stream modification threat is the danger that messages may be maliciously re-ordered, delayed or replayed to an extent which is greater than can occur through the natural operation of a subnetwork service, in order to effect unauthorized management operations.Disclosur

38、eThe disclosure threat is the danger of eavesdropping on the exchanges between SNMP engines. Protecting against this threat may be required as a matter of local policy.There are at least two threats against which a Security Model within this architecture need not protect, since they are deemed to be

39、 of lesser importance in this context:Denial of ServiceA Security Model need not attempt to address the broad range of attacks by which service on behalf of authorized users is denied. Indeed, such denial-of-service attacks are in many cases indistinguishable from the type of network failures with w

40、hich any viable management protocol must cope as a matter of course.Traffic AnalysisA Security Model need not attempt to address traffic analysis attacks. Many traffic patterns are predictable - entities may be managed on a regular basis by a relatively small number of management stations - and ther

41、efore there is no significant advantage afforded by protecting against traffic analysis.1.5. Design DecisionsVarious design decisions were made in support of the goals of the architecture and the security requirements:- ArchitectureAn architecture should be defined which identifies the conceptual bo

42、undaries between the documents. Subsystems should be defined which describe the abstract services provided by specific portions of an SNMP framework. Abstract service interfaces, as described by service primitives, define the abstract boundaries between documents, and the abstract services that are

43、provided by the conceptual subsystems of an SNMP framework.- Self-contained DocumentsElements of procedure plus the MIB objects which are needed for processing for a specific portion of an SNMP framework should be defined in the same document, and as much as possible, should not be referenced in oth

44、er documents. This allows pieces to be designed and documented as independent and self-contained parts, which is consistent with the general SNMP MIB module approach. As portions of SNMP change over time, the documents describing other portions of SNMP are not directly impacted. This modularity allo

45、ws, for example, Security Models, authentication and privacy mechanisms, and message formats to be upgraded and supplemented as the need arises. The self-contained documents can move along the standards track on different time-lines.This modularity of specification is not meant to be interpreted as

46、imposing any specific requirements on implementation.- ThreatsThe Security Models in the Security Subsystem SHOULD protect against the principal and secondary threats: modification of information, masquerade, message stream modification and disclosure. They do not need to protect against denial of s

47、ervice and traffic analysis.- Remote ConfigurationThe Security and Access Control Subsystems add a whole new set of SNMP configuration parameters. The Security Subsystem also requires frequent changes of secrets at the various SNMP entities. To make this deployable in a large operational environment

48、, these SNMP parameters must be remotely configurable.- Controlled ComplexityIt is recognized that producers of simple managed devices want to keep the resources used by SNMP to a minimum. At the same time, there is a need for more complex configurations which can spend more resources for SNMP and t

49、hus provide more functionality. The design tries to keep the competing requirements of these two environments in balance and allows the more complex environments to logically extend the simple environment.Editors AddressesBert WijnenLucent TechnologiesSchagen 333461 GL LinschotenNetherlandsPhone: +3

50、1 348-680-485EMail: David HarringtonEnterasys NetworksPost Office Box 500535 Industrial WayRochester, New Hampshire 03866-5005USAPhone: +1 603-337-2614EMail: Randy PresuhnBMC Software, Inc.2141 North First StreetSan Jose, California 95131USAPhone: +1 408-546-1006Fax: +1 408-965-0359EMail: Full Copyr

51、ight StatementCopyright (C) The Internet Society (2002). All Rights Reserved.This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in

52、 whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.