draft-ietf-idr-bgp4-mib-08.txt   draft-ietf-idr-bgp4-mib-09.txt 
skipping to change at page 1, line 16 skipping to change at page 1, line 16
S. Hares S. Hares
NextHop NextHop
Authors of previous version: Authors of previous version:
S. Willis S. Willis
Argon Networks Argon Networks
J. Burruss J. Burruss
WinData WinData
Editor of previous version: Editor of previous version:
J. Chu J. Chu
Cosine Cosine
November 2001 March 2002
Definitions of Managed Objects Definitions of Managed Objects
for the Fourth Version of Border Gateway Protocol (BGP-4) for the Fourth Version of Border Gateway Protocol (BGP-4)
<draft-ietf-idr-bgp4-mib-08.txt> <draft-ietf-idr-bgp4-mib-09.txt>
1. Status of this Memo 1. Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 5, line 17 skipping to change at page 5, line 17
BGP4-MIB DEFINITIONS ::= BEGIN BGP4-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
IpAddress, Integer32, Counter32, Gauge32, mib-2 IpAddress, Integer32, Counter32, Gauge32, mib-2
FROM SNMPv2-SMI FROM SNMPv2-SMI
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF; FROM SNMPv2-CONF;
bgp MODULE-IDENTITY bgp MODULE-IDENTITY
LAST-UPDATED "200111030000Z" LAST-UPDATED "200203010000Z"
ORGANIZATION "IETF IDR Working Group" ORGANIZATION "IETF IDR Working Group"
CONTACT-INFO "E-mail: idr@merit.net CONTACT-INFO "E-mail: idr@merit.net
Jeff Haas, Sue Hares (Editor) Jeff Haas, Sue Hares (Editors)
517 W. William Street 825 Victors Way
Ann Arbor, MI 48103-4943 Suite 100
Tel: +1 734 973-2200 Ann Arbor, MI 48108-2738
Fax: +1 734 615-3241 Tel: +1 734 222-1600
Fax: +1 734 222-1602
E-mail: jhaas@nexthop.com E-mail: jhaas@nexthop.com
skh@nexthop.com" skh@nexthop.com"
DESCRIPTION DESCRIPTION
"The MIB module for the BGP-4 protocol. "The MIB module for the BGP-4 protocol.
Changes since RFC 1657: Changes since RFC 1657:
1) Fixed the definitions of the traps to 1) Fixed the definitions of the traps to
make them equivalent to their initial make them equivalent to their initial
definition in RFC 1269. definition in RFC 1269.
2) Added compliance and conformance info. 2) Added compliance and conformance info.
3) Updated for latest BGP information 3) Updated for latest BGP information
draft-ietf-idr-bgp4-15.txt for value of draft-ietf-idr-bgp4-17.txt for value of
bgpPeerNegotiatedVersion, bgp4PathAttrLocalPref, bgpPeerNegotiatedVersion, bgp4PathAttrLocalPref,
bgp4PathAttrCalcLocalPref,bgp4PathAttrMultiExitDisc, bgp4PathAttrCalcLocalPref,bgp4PathAttrMultiExitDisc,
bgp4PathAttrASPathSegement. bgp4PathAttrASPathSegement.
4) Added additional clarification commments where 4) Added additional clarification commments where
needed. needed.
5) Noted where objects do not fully reflect 5) Noted where objects do not fully reflect
the protocol as Known Issues." the protocol as Known Issues."
::= { mib-2 15 } ::= { mib-2 15 }
bgpVersion OBJECT-TYPE bgpVersion OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (1..255)) SYNTAX OCTET STRING (SIZE (1..255))
skipping to change at page 29, line 13 skipping to change at page 30, line 5
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances 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 licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
9. Acknowledgements 9. Security Considerations
This MIB relates to a system providing inter-domain routing. As
such, improper manipulation of the objects represented by this MIB
may result in denial of service to a large number of end-users.
There are several management objects defined in this MIB that have a
MAX-ACCESS clause of read-write and/or read-create. Such 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. These objects include:
+o bgpPeerAdminStatus
Improper change of bgpPeerAdminStatus from start to stop can
cause significant disruption of the connectivity to those
portions of the Internet reached via the applicable remote BGP
peer.
+o bgpPeerConnectRetryInterval
Improper change of this object can cause connections to be
disrupted for extremely long time periods when otherwise they
would be restored in a relatively short period of time.
+o bgpPeerHoldTimeConfigured, bgpPeerKeepAliveConfigured
Misconfiguration of thse objects can make BGP sessions more
fragile and less resilient to denial of service attacks on the
inter-domain routing system.
+o bgpPeerMinASOriginationInterval,
bgpPeerMinRouteAdvertisementInterval
Misconfiguration of these objects may adversely affect global
Internet convergence of the routes advertised by this BGP
speaker. This may result in long-lived routing loops and
blackholes for the portions of the Internet that utilize these
routes."
There are a number of managed objects in this MIB that
contain sensitive information regarding the operation of a network.
For example, a BGP peer's local and remote addresses might 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 is important in most 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.
SNMPv1 by itself is not a secure environment. Even if the network
itself is secure (for example by using IPSec), there is still 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.[REF] Specifically, the
implementation and use of the User-based Security Model [REF] and the
View-based Access Control Model [REF] is recommended to provide
appropriate security controls.
It is then an operator/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. Acknowledgements
We would like to acknowledge the assistance of all the members of the We would like to acknowledge the assistance of all the members of the
Inter-Domain Routing Working Group, and particularly the following Inter-Domain Routing Working Group, and particularly the following
individuals: individuals:
Yakov Rekhter, Juniper Networks Yakov Rekhter, Juniper Networks
Rob Coltun, Redback Rob Coltun, Redback
Guy Almes, Internet2 Guy Almes, Internet2
Jeff Honig, BSDi Jeff Honig, BSDi
Marshall T. Rose, Dover Beach Consulting, Inc. Marshall T. Rose, Dover Beach Consulting, Inc.
skipping to change at page 29, line 42 skipping to change at page 32, line 34
Dimitry Haskin, Nortel Dimitry Haskin, Nortel
Peder Chr Norgaard, Telebit Communications A/S Peder Chr Norgaard, Telebit Communications A/S
Joel Halpern, CTO Longitude Systems, Inc. Joel Halpern, CTO Longitude Systems, Inc.
Nick Thille, RedBack Networks Nick Thille, RedBack Networks
Bert Wijnen, Lucent Bert Wijnen, Lucent
Shane Wright, NextHop Shane Wright, NextHop
Mike McFadden, Riverstone Networks, Inc. Mike McFadden, Riverstone Networks, Inc.
Jon Saperia, JDS Consulting, Inc. Jon Saperia, JDS Consulting, Inc.
Wayne Tackabury, Gold Wire Technology, Inc. Wayne Tackabury, Gold Wire Technology, Inc.
Bill Fenner, AT&T Research Bill Fenner, AT&T Research
RJ Atkinson, Extreme Networks
The origin of this document is from RFC 1269 "Definitions of Managed The origin of this document is from RFC 1269 "Definitions of Managed
Objects for the Border Gateway Protocol (Version 3)" written by Steve Objects for the Border Gateway Protocol (Version 3)" written by Steve
Willis and John Burruss, which was updated by John Chu to support Willis and John Burruss, which was updated by John Chu to support
BGP-4 in RFC 1657. The editors wish to acknowledge the fine work of BGP-4 in RFC 1657. The editors wish to acknowledge the fine work of
these original authors. these original authors.
10. References 11. References
[BGP4] Rekhter, Y., Li, T., "A Border Gateway Protocol 4 (BGP-4)", RFC [BGP4] Rekhter, Y., Li, T., "A Border Gateway Protocol 4 (BGP-4)", RFC
1771, March 1995. 1771, March 1995.
[BGP4APP] Rekhter, Y., Gross, P., "Application of the Border Gateway [BGP4APP] Rekhter, Y., Gross, P., "Application of the Border Gateway
Protocol in the Internet", RFC 1772, March 1995. Protocol in the Internet", RFC 1772, March 1995.
[RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture
for Describing SNMP Management Frameworks", RFC 2571, April for Describing SNMP Management Frameworks", RFC 2571, April
1999. 1999.
skipping to change at page 32, line 5 skipping to change at page 35, line 5
RFC 2573, April 1999. RFC 2573, April 1999.
[RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", RFC 2575, April 1999. Management Protocol (SNMP)", RFC 2575, April 1999.
[RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction to Version 3 of the Internet-standard Network "Introduction to Version 3 of the Internet-standard Network
Management Framework", RFC 2570, April 1999. Management Framework", RFC 2570, April 1999.
11. 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.
12. Editors Address 12. Editors Address
Jeff Haas, Sue Hares Jeff Haas, Sue Hares
NextHop Technologies NextHop Technologies
825 Victor's Way, Suite 100 825 Victor's Way, Suite 100
Ann Arbor, MI 48103 Ann Arbor, MI 48103
Phone: +1 734 222-1600 Phone: +1 734 222-1600
Fax: +1 734 222-1602 Fax: +1 734 222-1602
Email: jhaas@nexthop.com Email: jhaas@nexthop.com
skh@nexthop.com skh@nexthop.com
skipping to change at line 1399 skipping to change at line 1426
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Table of Contents
1. Status of this Memo .............................................. 1
2. Copyright Notice ................................................. 2
3. Abstract ......................................................... 2
4. Introduction ..................................................... 2
5. The SNMP Management Framework .................................... 2
6. Overview ......................................................... 3
7. Definitions ...................................................... 5
8. Intellectual Property ........................................... 28
9. Acknowledgements ................................................ 29
10. References ...................................................... 30
11. Security Considerations ......................................... 32
12. Editors Address ................................................. 33
13. Full Copyright Statement ........................................ 33
i
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/