Internet Draft draft-jhaas-bgp4-mib-opt-00.txt Februrary 2001
Network Working Group J. Haas
Internet Draft NextHop
Expiration Date: August 2001 S. Hares
NextHop
22 February 2001
Definitions of Managed Objects
for the Fourth Version of Border Gateway Protocol (BGP-4)
- Extensions for Optional parameters
draft-jhaas-bgp4-mib-opt-00.txt
Status of this Memo
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.
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 extention to the BGP-4 MIB to support the Optional
Parameters attributes for Authentication [RFC1771 4.2a] and BGP-4
Capabilities Advertisement [RFC2842]. Additionally, this MIB
provides a registration point for BGP-4 Capabilities defined
protocols.
Haas [Page 1]
Internet Draft draft-jhaas-bgp4-mib-opt-00.txt Februrary 2001
This BGP MIB provides management information relating to these
optional functions in BGP-4.
Distribution of this memo is unlimited. Please forward comments to
idr@merit.net.
1. Introduction
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 the optional managed
objects used for managing Authentication and Optional Capabilities
for the Border Gateway Protocol Version 4.
The BGP-4 Authentication Optional Parameter attribute is defined
in RFC 1771, section 4.2a.
The BGP-4 Capabilities Advertisement extension is defined in RFC
2842.
Please refer to the RFCs for the definition of these protcols.
2. Overview
These objects are used to control and manage a optional functions
in the BGP-4 protocol. This optional MIB is considered an
extension to the current BGP-4 MIB. The OID numbering begins at
the end of the Current BGP-4 MIB.
This optional MIB is made up of the following objects:
i. bgpAuthenticationTable { bgp 9 1 }
Specifies the Authentication data exchanged between BGP-4
peers.
ii. bgpCapabilitySupportAvailable { bgp 9 2 }
Specifies whether or not the BGP-4 Capabilities
Advertisement RFC is supported.
iii. bgpSupportedCapabilities { bgp 9 3 }
Specifies a bit vector of what BGP-4 Capabilities are
supported by this implementation.
Haas [Page 2]
Internet Draft draft-jhaas-bgp4-mib-opt-00.txt Februrary 2001
iv. bgpPeerCapabilitiesTable { bgp 9 4 }
A table of capabilities advertised to and received from a
BGP-4 peer.
v. bgpProtocolExtensions { bgp 9 5 }
Provides a registration point for additional MIBs for BGP-4
protocol extensions which use BGP-4 Capabilities
Advertisement.
3. Definitions
BGP4-OPT-PARAMETERS-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE,
Integer32, Counter32, Gauge32, mib-2
FROM SNMPv2-SMI
bgpPeerRemoteAddr FROM BGP-MIB
TruthValue, AutonomousType FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF;
bgp4OptParametersMIB MODULE-IDENTITY
LAST-UPDATED "200102230000Z"
ORGANIZATION "IETF IDR Working Group"
CONTACT-INFO
"E-Mail: idr@merit.net
Editor: Susan Hares
517 W. William Street
Ann Arbor, MI 48103-4943
Tel: +1 734 936 2095
Fax: +1 734 615-3241
E-mail: skh@nexthop.com
Authors: Jeffrey Haas
NextHop Technologies
517 W. William Street
Ann Arbor, MI 48103-4943
Tel: +1 734 936 2095
Fax: +1 734 615-3241
E-mail: jhaas@nexthop.com"
Haas [Page 3]
Internet Draft draft-jhaas-bgp4-mib-opt-00.txt Februrary 2001
DESCRIPTION
"The extension of the MIB module for BGP-4 for
optional parameters."
REVISION "200102230000Z"
DESCRIPTION
"Initial proposal.
Definition of MIB extension for the following
optional exetnsions to BGP-4"
REFERENCE
"RFC 1771 - Border Gateway Protocol, Version 4
RFC 2385 - TCP MD5 Authentication
RFC 2842 - Capabilities Advertisement with BGP-4"
::= { bgp 9 }
-- bgpAuthenticationTable { bgp4OptParametersMIB 1 }
-- bgpCapabilitySupportAvailable { bgp4OptParametersMIB 2 }
-- bgpSupportedCapabilities { bgp4OptParametersMIB 3 }
-- bgpPeerCapabilitiesTable { bgp4OptParametersMIB 4 }
-- bgpProtocolExtensions { bgp4OptParametersMIB 5 }
bgpAuthenticationTable OBJECT-TYPE
SYNTAX SEQUENCE OF BgpAuthenticationPeerEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The BGP-4 Authentication Table contains information
about BGP Authentication Options on a per-peer basis."
REFERENCE
"RFC 1771 - Border Gateway Protocol, Version 4"
::= { bgp4OptParametersMIB 1 }
bgpAuthenticationPeerEntry OBJECT-TYPE
SYNTAX BgpAuthenticationPeerEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information about Authentication on a per-peer basis."
INDEX {
bgpPeerRemoteAddr,
bgpAuthenticationDirection
}
::= { bgpAuthenticationTable 1 }
bgpAuthenticationEntry OBJECT-TYPE
SYNTAX BgpAuthenticationEntry
MAX-ACCESS not-accessible
Haas [Page 4]
Internet Draft draft-jhaas-bgp4-mib-opt-00.txt Februrary 2001
STATUS current
DESCRIPTION
"Information about BGP-4 Authentication."
::= { bgpAuthenticationPeerEntry 2 }
BgpAuthenticationEntry ::= SEQUENCE {
bgpAuthenticationDirection Integer32
bgpAuthenticationCode Integer32
bgpAuthenticationDataLength Integer32
bgpAuthenticationDataContents OCTET STRING
}
bgpAuthenticationDirection OBJECT-TYPE
SYNTAX Integer32 {
sent (1) -- Authorization is being sent
received (2) -- Authorization is being received
}
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This variable indicates whether authentication
information is either being sent by the BGP
speaker or has been been received by the BGP
speaker. It also serves as the index into the
table of authentication information for the
direction of authentication."
::= { bgpAuthenticationEntry 1 }
bgpAuthenticationCode OBJECT-TYPE
SYNTAX Integer32 (-1 | 0..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is the AuthenticationCode used.
This value is set to -1 if Authentication is
not present."
REFERENCE
"RFC 1771, sec. 4.2.a"
::= { bgpAuthenticationEntry 2 }
bgpAuthenticationDataLength OBJECT-TYPE
SYNTAX Integer32 (-1 | 0..252)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This value is derived from the optional
parameter length minus one (the size of
bgpAuthenticationCode). This value may be no
Haas [Page 5]
Internet Draft draft-jhaas-bgp4-mib-opt-00.txt Februrary 2001
larger than 252 due to overhead. This value
is set to -1 if Authentication is not present."
::= { bgpAuthenticationEntry 3 }
bgpAuthenticationDataContents OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (1..252))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This is the Authentication payload. The
semantics of this variable are interpreted
according to the authentication code."
::= { bgpAuthenticationEntry 4 }
bgpCapabilitySupportAvailable OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This variable determines whether BGP-4
capabilities are supported in this
implementation. This variable may be set to
false to disable capability support."
::= { bgp4OptParametersMIB 2 }
bgpSupportedCapabilities OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..32)) -- 256 bit vector
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Vector of BGP-4 capabilities that are
supported in this implementation. Capabilities
are identified via the string of bits within
this object. The first octet contains bits
0 to 7, the second octet contains bits 8 to 15
and so on. If a bit, i, is present and set,
then the capability (i+1) is supported.
When capabilities are not supported, all bits
must be zero."
::= { bgp4OptParametersMIB 3 }
bgpPeerCapabilitiesTable OBJECT-TYPE
SYNTAX SEQUENCE OF BgpPeerCapabilitiesEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table contains contains the capabilities
Haas [Page 6]
Internet Draft draft-jhaas-bgp4-mib-opt-00.txt Februrary 2001
that are supported for a given peer."
::= { bgp4OptParametersMIB 4 }
BgpPeerCapabilitiesEntry ::= SEQUENCE {
bgpPeerCapabilitiesAnnounced
OCTET STRING,
bgpPeerCapabilitiesReceived
OCTET STRING
}
bgpPeerCapabilitiesEntry OBJECT-TYPE
SYNTAX BgpPeerCapabilitiesEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"These entries are keyed by a BGP-4 peer's remote
address and port combination over which the
peering session has been established."
AUGMENTS { bgpPeerTable }
::= { bgpPeerCapabilitiesTable 2 }
bgpPeerCapabilitiesAnnounced OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..32))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This bit vector identifies which capabilities
have been announced to a BGP-4 speaker.
Capabilities are identified via the string of
bits within this object. The first octet
contains bits 0 to 7, the second octet contains
bits 8 to 15 and so on. If a bit, i, is present
and set, then the capability (i+1) is supported.
When capabilities are not supported, all bits
must be zero."
::= { bgpPeerCapabilitiesEntry 1 }
bgpPeerCapabilitiesReceived OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..32))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This bit vector identifies which capabilities have
been announced by the remote BGP-4 speaker.
Haas [Page 7]
Internet Draft draft-jhaas-bgp4-mib-opt-00.txt Februrary 2001
Capabilities are identified via the string of bits
within this object. The first octet contains bits 0
to 7, the second octet contains bits 8 to 15 and so
on. If a bit, i, is present and set, then the
capability (i+1) is supported.
When capabilities are not supported, all bits must
be zero."
::= { bgpPeerCapabilitiesEntry 2 }
bgpProtocolExtensions OBJECT-TYPE
SYNTAX AutonomousType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Registration point for MIB Modules for BGP
Protocol Extensions.
The Capabilities Advertisement RFC delineates
IANA registered capability code numbers, 0-127
and private use capability code numbers, 128-255.
The first sub-identifier will be the enterprise
number of the registering entity. This is used
to remove the ambiguity of the private use
portion of the capability code assignments. For
IANA registered capability codes 0-127, the first
sub-identifier will be 0.
The second sub-identifier will be the capability
code for the advertised capability.
For example, the MPBGP-MIB would be assigned as
{ bgpProtocolStandardExtensions 0 1 } since it
has been assigned capability code number 1 and
is an IETF assigned (IANA registered) capability
extension."
REFERENCE
"RFC 2842 - Capabilities Advertisement with BGP-4"
::= { bgp4OptParametersMIB 5 }
END
4. Intellectual Property
The IETF takes no position regarding the validity or scope of any
Haas [Page 8]
Internet Draft draft-jhaas-bgp4-mib-opt-00.txt Februrary 2001
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.
5. Acknowledgements
The authors wish to thank Matt Richardson and Shane Wright of
NextHop for helpful feedback during the design of this document.
The authors wish to particularly thank Bert Wijnen of Lucent for
all the help in the MIB layout.
6. References
[1] Rekhter, Y., Li, T., "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995.
[2] Chandra, R., Scudder, T., "Capabilities Advertisement with
BGP-4", RFC 2842, May 2000.
[3] 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.
[3] 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.
[4] 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
Haas [Page 9]
Internet Draft draft-jhaas-bgp4-mib-opt-00.txt Februrary 2001
7. Security Considerations
There are a number of management objects defined in this MIB that
have a MAX-ACCESS clause of read-write:
+o bgpAuthenticationCode
+o bgpAuthenticationDataType
+o bgpAuthenticationDataContents
+o bgpCapabilitySupportAvailable
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 [3] and the View-
based Access Control Model RFC 2275 [4] 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.
Haas [Page 10]
Internet Draft draft-jhaas-bgp4-mib-opt-00.txt Februrary 2001
8. Authors Address
Jeffrey Haas
NextHop Technologies
517 Williams
Ann Arbor, MI 48103-4943
Phone: +1 734 936 2095
Fax: +1 734 615-3241
Email: jhaas@nexthop.com
Susan Hares
NextHop Technologies
517 Williams
Ann Arbor, MI 48103-4943
Phone: +1 734 936 2095
Fax: +1 734 615-3241
Email: skh@nexthop.com
Haas [Page 11]