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/