--- 1/draft-ietf-idr-bgp4-mib-02.txt 2006-02-04 23:30:41.000000000 +0100 +++ 2/draft-ietf-idr-bgp4-mib-03.txt 2006-02-04 23:30:41.000000000 +0100 @@ -1,144 +1,193 @@ -Network Working Group S. Willis -INTERNET DRAFT Bay Networks +Network Working Group S. Hares +INTERNET DRAFT Merit + J. Johnson + RedBack Networks + S. Willis + Argon Networks J. Burruss - Windata + WinData J. Chu IBM Corporation - J. Johnson - cisco Systems - March 1996 + February 1999 Definitions of Managed Objects + for the Fourth Version of Border Gateway Protocol (BGP-4) - + Status of this Memo -This document is an Internet-Draft. Internet-Drafts are working -documents of the Internet Engineering Task Force (IETF), its areas, and -its working groups. Note that other groups may also distribute working -documents as Internet-Drafts. + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any -time. It is inappropriate to use Internet- Drafts as reference material -or to cite them other than as ``work in progress.'' + time. It is inappropriate to use Internet- Drafts as reference + material or to cite them other than as "work in progress." -To learn the current status of any Internet-Draft, please check the -``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow -Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), -munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or -ftp.isi.edu (US West Coast). + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This memo is an extension to the SNMP MIB. It specifies an IAB standards track protocol for the Internet community, and requests -discussion and suggestions for improvements. The origin of this memo is -from RFC 1269 "Definitions of Managed Objects for the Board Gateway -Protocol (Version 3)" written by the first two authors of this memo, -which was updated to support BGP-4 in RFC 1657. This memo fixes errors -introduced when the MIB was converted to use the SNMPv2 SMI, as well as -updates references to the Draft Standard SNMPv2 SMI documents. + discussion and suggestions for improvements. The origin of this memo + is from RFC 1269 "Definitions of Managed Objects for the Border + Gateway Protocol (Version 3)", which was updated to support BGP-4 in + RFC 1657. This memo fixes errors introduced when the MIB was + converted to use the SNMPv2 SMI, as well as updates references to the + current SNMP framework documents. Distribution of this memo is unlimited. Please forward comments to -bgp@ans.net. + idr@merit.net. 1. Introduction -This memo defines an experimental portion of the Management Information -Base (MIB) for use with network management protocols in the Internet -community. In particular, it describes managed objects used for -managing the Border Gateway Protocol Version 4 or lower [1, 2]. + This memo defines a portion of the Management Information Base (MIB) + for use with network management protocols in the Internet community. + In particular, it describes managed objects used for managing the + Border Gateway Protocol Version 4 or lower [1, 2]. 2. The SNMP Network Management Framework -The SNMP Network Management Framework consists of several components. -For the purpose of this specification, the applicable components of the -Framework are the SMI and related documents [3, 4, 5], which define the -mechanisms used for describing and naming objects for the purpose of -management. + The SNMP Management Framework presently consists of five major + components: -The Framework permits new objects to be defined for the purpose of -experimentation and evaluation. + o An overall architecture, described in RFC 2271 [3]. + + o Mechanisms for describing and naming objects and events for + the purpose of management. The first version of this + Structure of Management Information (SMI) is called SMIv1 and + described in RFC 1155 [4], RFC 1212 [5] and RFC 1215 [6]. The + second version, called SMIv2, is described in RFC 1902 [7], + RFC 1903 [8] and RFC 1904 [9]. + + o Message protocols for transferring management information. + The first version of the SNMP message protocol is called + SNMPv1 and described in RFC 1157 [10]. A second version of + the SNMP message protocol, which is not an Internet standards + track protocol, is called SNMPv2c and described in RFC 1901 + [11] and RFC 1906 [12]. The third version of the message + protocol is called SNMPv3 and described in RFC 1906 [12], RFC + 2272 [13] and RFC 2274 [14]. + + o Protocol operations for accessing management information. The + first set of protocol operations and associated PDU formats + is described in RFC 1157 [10]. A second set of protocol + operations and associated PDU formats is described in RFC + 1905 [15]. + + o A set of fundamental applications described in RFC 2273 [16] + and the view-based access control mechanism described in RFC + 2275 [17]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. Objects in the MIB are + defined using the mechanisms defined in the SMI. + + This memo specifies a MIB module that is compliant to the SMIv2. A + MIB conforming to the SMIv1 can be produced through the appropriate + translations. The resulting translated MIB must be semantically + equivalent, except where objects or events are omitted because no + translation is possible (use of Counter64). Some machine readable + information in SMIv2 will be converted into textual descriptions in + SMIv1 during the translation process. However, this loss of machine + readable information is not considered to change the semantics of the + MIB. 3. Object Definitions -Managed objects are accessed via a virtual information store, termed the -Management Information Base or MIB. Objects in the MIB are defined -using the subset of Abstract Syntax Notation One (ASN.1) defined in the -SMI. In particular, each object type is named by an OBJECT IDENTIFIER, -an administratively assigned name. The object type together with an -object instance serves to uniquely identify a specific instantiation of -the object. For human convenience, we often use a textual string, -termed the descriptor, to refer to the object type. + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. Objects in the MIB are + defined using the subset of Abstract Syntax Notation One (ASN.1) + defined in the SMI. In particular, each object type is named by an + OBJECT IDENTIFIER, an administratively assigned name. The object + type together with an object instance serves to uniquely identify a + specific instantiation of the object. For human convenience, we + often use a textual string, termed the descriptor, to refer to the + object type. 4. Overview These objects are used to control and manage a BGP-4 implementation. Apart from a few system-wide scalar objects, this MIB is broken into -three tables: the BGP Peer Table, the BGP Received Path Attribute Table, -and the BGP-4 Received Path Attribute Table. The BGP Peer Table -contains information about state and current activity of connections - -with the BGP peers. The Received Path Attribute Table contains path -attributes received from all peers running BGP version 3 or less. The -BGP-4 Received Path Attribute Table contains path attributes received -from all BGP-4 peers. The actual attributes used in determining a route -are a subset of the received attribute tables after local routing policy -has been applied. + three tables: the BGP Peer Table, the BGP Received Path Attribute + Table, and the BGP-4 Received Path Attribute Table. The BGP Peer + Table contains information about state and current activity of + connections with the BGP peers. The Received Path Attribute Table + contains path attributes received from all peers running BGP version + 3 or less. The BGP-4 Received Path Attribute Table contains path + attributes received from all BGP-4 peers. The actual attributes used + in determining a route are a subset of the received attribute tables + after local routing policy has been applied. 5. Definitions BGP4-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, IpAddress, Integer32, Counter32, Gauge32, mib-2 FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF; bgp MODULE-IDENTITY - LAST-UPDATED "9601080000Z" - ORGANIZATION "IETF BGP Working Group" - CONTACT-INFO - " John Chu (Editor) - Postal: IBM Corp. - P.O.Box 704 - Yorktown Heights, NY 10598 - US + LAST-UPDATED "9902100000Z" + ORGANIZATION "IETF IDR Working Group" + CONTACT-INFO "E-mail: idr@merit.net - Tel: +1 914 784 7839 - Fax: +1 914 784 6205 - E-mail: jychu@watson.ibm.com + Susan Hares (Editor) + Merit Network + 4251 Plymouth Road + Suite C + Ann Arbor, MI 48105-2785 + Tel: +1 734 936 2095 + Fax: +1 734 647 3185 + E-mail: skh@merit.edu Jeff Johnson (Editor) - Postal: cisco Systems - 170 W. Tasman Drive - San Jose, CA 95134 - - Tel: +1 408 526 7789 - Fax: +1 408 526 4860 - E-mail: jjohnson@cisco.com" + RedBack Networks, Inc. + 1389 Moffett Park Drive + Sunnyvale, CA 94089-1134 + Tel: +1 408 548 3516 + Fax: +1 408 548 3599 + E-mail: jeff@redback.com" DESCRIPTION "The MIB module for BGP-4." REVISION "9601080000Z" DESCRIPTION "1) Fixed the definitions of the traps to make them equivalent to their initial definition in RFC 1269. 2) Added compliance and conformance info." + REVISION "9902100000Z" + DESCRIPTION + "Corrected duplicate OBJECT IDENTIFIER + assignment in the conformance information." ::= { mib-2 15 } bgpVersion OBJECT-TYPE SYNTAX OCTET STRING (SIZE (1..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "Vector of supported BGP protocol version numbers. Each peer negotiates the version from this vector. Versions are identified @@ -554,21 +599,21 @@ ::= { bgp 5 } bgpPathAttrEntry OBJECT-TYPE SYNTAX BgpPathAttrEntry MAX-ACCESS not-accessible STATUS obsolete DESCRIPTION "Information about a path to a network." INDEX { bgpPathAttrDestNetwork, bgpPathAttrPeer } - ::= { bgpRcvdPathAttrTable 1 } + ::= { bgpPathAttrTable 1 } BgpPathAttrEntry ::= SEQUENCE { bgpPathAttrPeer IpAddress, bgpPathAttrDestNetwork IpAddress, bgpPathAttrOrigin INTEGER, bgpPathAttrASPath OCTET STRING, @@ -1002,97 +1047,257 @@ BGP path entries." ::= { bgpMIBGroups 4 } bgp4MIBNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS { bgpEstablished, bgpBackwardTransition } STATUS current DESCRIPTION "A collection of notifications for signaling changes in BGP peer relationships." - ::= { bgpMIBGroups 4 } + ::= { bgpMIBGroups 5 } END -6. Acknowledgements +6. Intellectual Property + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + +7. Acknowledgements We would like to acknowledge the assistance of all the members of the Inter-Domain Routing Working Group, and particularly the following individuals: Yakov Rekhter, cisco Systems Rob Coltun, Fore Guy Almes, ANS Jeff Honig, Cornell Theory Center Marshall T. Rose, Dover Beach Consulting, Inc. - Dennis Ferguson, Ipsilon + Dennis Ferguson, Juniper Networks Mike Mathis, PSC John Krawczyk, Bay Networks Curtis Villamizar, ANS Dave LeRoy, Pencom Systems - Paul Traina, cisco Systems + Paul Traina, Juniper Networks Andrew Partan, UUNET Robert Snyder, cisco Systems Dimitry Haskin, Bay Networks Peder Chr Norgaard, Telebit Communications A/S Joel Halpern, NewBridge - Nick Thille, cisco Systems + Nick Thille, RedBack Networks + Bert Wijnen, IBM -7. References + The origin of this document is from RFC 1269 "Definitions of Managed + Objects for the Border Gateway Protocol (Version 3)" written by Steve + Willis and John Burruss, which was updated by John Chu to support + BGP-4 in RFC 1657. The editors wishes to acknowledge the fine work + of these original authors. - [1] Rekhter, Y., Li, T., "A Border Gateway Protocol 4 (BGP-4)", - RFC 1771, March 1995. +8. References - [2] Rekhter, Y., Gross, P., "Application of the Border - Gateway Protocol in the Internet", RFC 1772, March 1995. + [1] Rekhter, Y., Li, T., "A Border Gateway Protocol 4 (BGP-4)", RFC + 1771, March 1995. - [3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and - S. Waldbusser, "Structure of Management Information for Version 2 - of the Simple Network Management Protocol (SNMPv2)", RFC 1902, - January 1996. + [2] Rekhter, Y., Gross, P., "Application of the Border Gateway + Protocol in the Internet", RFC 1772, March 1995. - [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and - S. Waldbusser, "Textual Conventions for Version 2 of the Simple - Network Management Protocol (SNMPv2)", RFC 1903, January 1996. + [3] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for + Describing SNMP Management Frameworks", RFC 2271, Cabletron + Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, + January 1998 - [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and - S. Waldbusser, "Conformance Statements for Version 2 of the - Simple Network Management Protocol (SNMPv2)", RFC 1904, - January 1996. + [4] Rose, M., and K. McCloghrie, "Structure and Identification of + Management Information for TCP/IP-based Internets", RFC 1155, + Performance Systems International, Hughes LAN Systems, May 1990 -8. Security Considerations + [5] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC + 1212, Performance Systems International, Hughes LAN Systems, + March 1991 -Security issues are not discussed in this memo. + [6] M. Rose, "A Convention for Defining Traps for use with the + SNMP", RFC 1215, Performance Systems International, March 1991 -Authors' Address + [7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, + "Structure of Management Information for Version 2 of the Simple + Network Management Protocol (SNMPv2)", RFC 1902, SNMP + Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, + Inc., International Network Services, January 1996. - Steve Willis - Bay Networks, Inc. - 3 Federal St - Billerica, MA 01821 + [8] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual + Conventions for Version 2 of the Simple Network Management + Protocol (SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco + Systems, Inc., Dover Beach Consulting, Inc., International + Network Services, January 1996. - Phone: +1 508 436 3927 - Email: swillis@BayNetworks.com + [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, + "Conformance Statements for Version 2 of the Simple Network + Management Protocol (SNMPv2)", RFC 1904, SNMP Research, Inc., + Cisco Systems, Inc., Dover Beach Consulting, Inc., International + Network Services, January 1996. + + [10] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple + Network Management Protocol", RFC 1157, SNMP Research, + Performance Systems International, Performance Systems + International, MIT Laboratory for Computer Science, May 1990. + + [11] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, + "Introduction to Community-based SNMPv2", RFC 1901, SNMP + Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, + Inc., International Network Services, January 1996. + + [12] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, + "Transport Mappings for Version 2 of the Simple Network + Management Protocol (SNMPv2)", RFC 1906, SNMP Research, Inc., + Cisco Systems, Inc., Dover Beach Consulting, Inc., International + Network Services, January 1996. + + [13] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message + Processing and Dispatching for the Simple Network Management + Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron + Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, + January 1998. + + [14] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) + for version 3 of the Simple Network Management Protocol + (SNMPv3)", RFC 2274, IBM T. J. Watson Research, January 1998. + + [15] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol + Operations for Version 2 of the Simple Network Management + Protocol (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco + Systems, Inc., Dover Beach Consulting, Inc., International + Network Services, January 1996. + + [16] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC + 2273, SNMP Research, Inc., Secure Computing Corporation, Cisco + Systems, January 1998 + + [17] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access + Control Model (VACM) for the Simple Network Management Protocol + (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, + Inc., Cisco Systems, Inc., January 1998 + +9. Security Considerations + + There are a number of management objects defined in this MIB that + have a MAX-ACCESS clause of read-write: + bgpPeerAdminStatus + bgpPeerConnectRetryInterval + bgpPeerHoldTimeConfigured + bgpPeerKeepAliveConfigured + bgpPeerMinASOriginationInterval + bgpPeerMinRouteAdvertisementInterval + + These objects should be considered sensitive or vulnerable in most + network environments. The support for SET operations in a non-secure + environment without proper protection can have a negative effect on + network operations. Incorrect configuration of these parameters may + cause BGP peer connections to terminate early or to send more routes + under a flapping condition. + + There are a number of managed objects in this MIB that may be + considered to contain sensitive information in the operation of a + network. For example, a BGP peer's local and remote addresses may be + sensitive for ISPs who want to keep interface addresses on routers + confidential to prevent router addresses used for a denial of service + attack or spoofing. + + Therefore, it may be important in some environments to control read + access to these objects and possibly to even encrypt the values of + these object when sending them over the network via SNMP. Not all + versions of SNMP provide features for such a secure environment. + + SNMPv1 by itself is not a secure environment. Even if the network + itself is secure (for example by using IPSec), even then, there is no + control as to who on the secure network is allowed to access and + GET/SET (read/change/create/delete) the objects in this MIB. + + It is recommended that the implementers consider the security + features as provided by the SNMPv3 framework. Specifically, the use + of the User-based Security Model RFC 2274 [14] and the View-based + Access Control Model RFC 2275 [17] is recommended. + + It is then a customer/user responsibility to ensure that the SNMP + entity giving access to an instance of this MIB, is properly + configured to give access to the objects only to those principals + (users) that have legitimate rights to indeed GET or SET + (change/create/delete) them. + +10. Authors' Address + + Susan Hares + Merit Network, Inc. + 4251 Plymouth Road + Suite C + Ann Arbor, MI 48105-2785 + Phone: +1 734 936 2095 + Fax: +1 734 647 3185 + Email: skh@merit.edu + + Jeff Johnson + RedBack Networks, Inc. + 1389 Moffett Park Drive + Sunnyvale, CA 94089 + Phone: +1 408 548 3516 + Email: jeff@redback.com + + Steve Willis + Argon Networks + 25 Porter Road + Littleton, MA 01450 + Phone: +1 508 486 0665 + Fax: +1 508 486 9379 + Email: swills@argon.com John Burruss Windata Inc. 543 Great Road Littleton MA 01460 - Phone: +1 508 952 0170 Email: jburruss@windata.com John Chu IBM Corporation P.O.Box 704 Yorktown Heights, NY 10598 - Phone: +1 914 784 7839 Email: jychu@watson.ibm.com - Jeff Johnson - cisco Systems - 170 W. Tasman Drive - San Jose, CA 95134 +11. Full Copyright Statement - Phone: +1 408 526 7789 - Email: jjohnson@cisco.com + Copyright (C) The Internet Society (1999). 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 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. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.