idnits 2.17.00 (12 Aug 2021) /tmp/idnits44435/draft-jhaas-bgp4-mib-opt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Overview' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 4 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [3], [4], [RFC2842], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (22 February 2001) is 7751 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2842' on line 44 looks like a reference -- Missing reference section? '1' on line 401 looks like a reference -- Missing reference section? '2' on line 404 looks like a reference -- Missing reference section? '3' on line 462 looks like a reference -- Missing reference section? '4' on line 463 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft draft-jhaas-bgp4-mib-opt-00.txt Februrary 2001 4 Network Working Group J. Haas 5 Internet Draft NextHop 6 Expiration Date: August 2001 S. Hares 7 NextHop 8 22 February 2001 10 Definitions of Managed Objects 11 for the Fourth Version of Border Gateway Protocol (BGP-4) 12 - Extensions for Optional parameters 14 draft-jhaas-bgp4-mib-opt-00.txt 16 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC 2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright Notice 38 Copyright (C) The Internet Society (1999). All Rights Reserved. 40 Abstract 42 This memo is an extention to the BGP-4 MIB to support the Optional 43 Parameters attributes for Authentication [RFC1771 4.2a] and BGP-4 44 Capabilities Advertisement [RFC2842]. Additionally, this MIB 45 provides a registration point for BGP-4 Capabilities defined 46 protocols. 48 This BGP MIB provides management information relating to these 49 optional functions in BGP-4. 51 Distribution of this memo is unlimited. Please forward comments to 52 idr@merit.net. 54 1. Introduction 56 This memo defines a portion of the Management Information Base 57 (MIB) for use with network management protocols in the Internet 58 community. In particular, it describes the optional managed 59 objects used for managing Authentication and Optional Capabilities 60 for the Border Gateway Protocol Version 4. 62 The BGP-4 Authentication Optional Parameter attribute is defined 63 in RFC 1771, section 4.2a. 65 The BGP-4 Capabilities Advertisement extension is defined in RFC 66 2842. 68 Please refer to the RFCs for the definition of these protcols. 70 2. Overview 72 These objects are used to control and manage a optional functions 73 in the BGP-4 protocol. This optional MIB is considered an 74 extension to the current BGP-4 MIB. The OID numbering begins at 75 the end of the Current BGP-4 MIB. 77 This optional MIB is made up of the following objects: 79 i. bgpAuthenticationTable { bgp 9 1 } 81 Specifies the Authentication data exchanged between BGP-4 82 peers. 84 ii. bgpCapabilitySupportAvailable { bgp 9 2 } 86 Specifies whether or not the BGP-4 Capabilities 87 Advertisement RFC is supported. 89 iii. bgpSupportedCapabilities { bgp 9 3 } 91 Specifies a bit vector of what BGP-4 Capabilities are 92 supported by this implementation. 94 iv. bgpPeerCapabilitiesTable { bgp 9 4 } 96 A table of capabilities advertised to and received from a 97 BGP-4 peer. 99 v. bgpProtocolExtensions { bgp 9 5 } 101 Provides a registration point for additional MIBs for BGP-4 102 protocol extensions which use BGP-4 Capabilities 103 Advertisement. 105 3. Definitions 107 BGP4-OPT-PARAMETERS-MIB DEFINITIONS ::= BEGIN 109 IMPORTS 110 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, 111 Integer32, Counter32, Gauge32, mib-2 112 FROM SNMPv2-SMI 114 bgpPeerRemoteAddr FROM BGP-MIB 116 TruthValue, AutonomousType FROM SNMPv2-TC 118 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 119 FROM SNMPv2-CONF; 121 bgp4OptParametersMIB MODULE-IDENTITY 122 LAST-UPDATED "200102230000Z" 123 ORGANIZATION "IETF IDR Working Group" 124 CONTACT-INFO 125 "E-Mail: idr@merit.net 127 Editor: Susan Hares 128 517 W. William Street 129 Ann Arbor, MI 48103-4943 130 Tel: +1 734 936 2095 131 Fax: +1 734 615-3241 132 E-mail: skh@nexthop.com 134 Authors: Jeffrey Haas 135 NextHop Technologies 136 517 W. William Street 137 Ann Arbor, MI 48103-4943 138 Tel: +1 734 936 2095 139 Fax: +1 734 615-3241 140 E-mail: jhaas@nexthop.com" 142 DESCRIPTION 143 "The extension of the MIB module for BGP-4 for 144 optional parameters." 145 REVISION "200102230000Z" 146 DESCRIPTION 147 "Initial proposal. 148 Definition of MIB extension for the following 149 optional exetnsions to BGP-4" 151 REFERENCE 152 "RFC 1771 - Border Gateway Protocol, Version 4 153 RFC 2385 - TCP MD5 Authentication 154 RFC 2842 - Capabilities Advertisement with BGP-4" 155 ::= { bgp 9 } 157 -- bgpAuthenticationTable { bgp4OptParametersMIB 1 } 158 -- bgpCapabilitySupportAvailable { bgp4OptParametersMIB 2 } 159 -- bgpSupportedCapabilities { bgp4OptParametersMIB 3 } 160 -- bgpPeerCapabilitiesTable { bgp4OptParametersMIB 4 } 161 -- bgpProtocolExtensions { bgp4OptParametersMIB 5 } 163 bgpAuthenticationTable OBJECT-TYPE 164 SYNTAX SEQUENCE OF BgpAuthenticationPeerEntry 165 MAX-ACCESS not-accessible 166 STATUS current 167 DESCRIPTION 168 "The BGP-4 Authentication Table contains information 169 about BGP Authentication Options on a per-peer basis." 170 REFERENCE 171 "RFC 1771 - Border Gateway Protocol, Version 4" 172 ::= { bgp4OptParametersMIB 1 } 174 bgpAuthenticationPeerEntry OBJECT-TYPE 175 SYNTAX BgpAuthenticationPeerEntry 176 MAX-ACCESS not-accessible 177 STATUS current 178 DESCRIPTION 179 "Information about Authentication on a per-peer basis." 180 INDEX { 181 bgpPeerRemoteAddr, 182 bgpAuthenticationDirection 183 } 184 ::= { bgpAuthenticationTable 1 } 186 bgpAuthenticationEntry OBJECT-TYPE 187 SYNTAX BgpAuthenticationEntry 188 MAX-ACCESS not-accessible 189 STATUS current 190 DESCRIPTION 191 "Information about BGP-4 Authentication." 192 ::= { bgpAuthenticationPeerEntry 2 } 194 BgpAuthenticationEntry ::= SEQUENCE { 195 bgpAuthenticationDirection Integer32 196 bgpAuthenticationCode Integer32 197 bgpAuthenticationDataLength Integer32 198 bgpAuthenticationDataContents OCTET STRING 199 } 201 bgpAuthenticationDirection OBJECT-TYPE 202 SYNTAX Integer32 { 203 sent (1) -- Authorization is being sent 204 received (2) -- Authorization is being received 205 } 206 MAX-ACCESS not-accessible 207 STATUS current 208 DESCRIPTION 209 "This variable indicates whether authentication 210 information is either being sent by the BGP 211 speaker or has been been received by the BGP 212 speaker. It also serves as the index into the 213 table of authentication information for the 214 direction of authentication." 215 ::= { bgpAuthenticationEntry 1 } 217 bgpAuthenticationCode OBJECT-TYPE 218 SYNTAX Integer32 (-1 | 0..255) 219 MAX-ACCESS read-write 220 STATUS current 221 DESCRIPTION 222 "This is the AuthenticationCode used. 223 This value is set to -1 if Authentication is 224 not present." 225 REFERENCE 226 "RFC 1771, sec. 4.2.a" 227 ::= { bgpAuthenticationEntry 2 } 229 bgpAuthenticationDataLength OBJECT-TYPE 230 SYNTAX Integer32 (-1 | 0..252) 231 MAX-ACCESS read-write 232 STATUS current 233 DESCRIPTION 234 "This value is derived from the optional 235 parameter length minus one (the size of 236 bgpAuthenticationCode). This value may be no 237 larger than 252 due to overhead. This value 238 is set to -1 if Authentication is not present." 239 ::= { bgpAuthenticationEntry 3 } 241 bgpAuthenticationDataContents OBJECT-TYPE 242 SYNTAX OCTET STRING (SIZE (1..252)) 243 MAX-ACCESS read-write 244 STATUS current 245 DESCRIPTION 246 "This is the Authentication payload. The 247 semantics of this variable are interpreted 248 according to the authentication code." 249 ::= { bgpAuthenticationEntry 4 } 251 bgpCapabilitySupportAvailable OBJECT-TYPE 252 SYNTAX TruthValue 253 MAX-ACCESS read-write 254 STATUS current 255 DESCRIPTION 256 "This variable determines whether BGP-4 257 capabilities are supported in this 258 implementation. This variable may be set to 259 false to disable capability support." 260 ::= { bgp4OptParametersMIB 2 } 262 bgpSupportedCapabilities OBJECT-TYPE 263 SYNTAX OCTET STRING (SIZE(0..32)) -- 256 bit vector 264 MAX-ACCESS read-only 265 STATUS current 266 DESCRIPTION 267 "Vector of BGP-4 capabilities that are 268 supported in this implementation. Capabilities 269 are identified via the string of bits within 270 this object. The first octet contains bits 271 0 to 7, the second octet contains bits 8 to 15 272 and so on. If a bit, i, is present and set, 273 then the capability (i+1) is supported. 275 When capabilities are not supported, all bits 276 must be zero." 277 ::= { bgp4OptParametersMIB 3 } 279 bgpPeerCapabilitiesTable OBJECT-TYPE 280 SYNTAX SEQUENCE OF BgpPeerCapabilitiesEntry 281 MAX-ACCESS not-accessible 282 STATUS current 283 DESCRIPTION 284 "This table contains contains the capabilities 285 that are supported for a given peer." 286 ::= { bgp4OptParametersMIB 4 } 288 BgpPeerCapabilitiesEntry ::= SEQUENCE { 289 bgpPeerCapabilitiesAnnounced 290 OCTET STRING, 291 bgpPeerCapabilitiesReceived 292 OCTET STRING 293 } 295 bgpPeerCapabilitiesEntry OBJECT-TYPE 296 SYNTAX BgpPeerCapabilitiesEntry 297 MAX-ACCESS not-accessible 298 STATUS current 299 DESCRIPTION 300 "These entries are keyed by a BGP-4 peer's remote 301 address and port combination over which the 302 peering session has been established." 303 AUGMENTS { bgpPeerTable } 304 ::= { bgpPeerCapabilitiesTable 2 } 306 bgpPeerCapabilitiesAnnounced OBJECT-TYPE 307 SYNTAX OCTET STRING (SIZE (0..32)) 308 MAX-ACCESS read-only 309 STATUS current 310 DESCRIPTION 311 "This bit vector identifies which capabilities 312 have been announced to a BGP-4 speaker. 314 Capabilities are identified via the string of 315 bits within this object. The first octet 316 contains bits 0 to 7, the second octet contains 317 bits 8 to 15 and so on. If a bit, i, is present 318 and set, then the capability (i+1) is supported. 320 When capabilities are not supported, all bits 321 must be zero." 322 ::= { bgpPeerCapabilitiesEntry 1 } 324 bgpPeerCapabilitiesReceived OBJECT-TYPE 325 SYNTAX OCTET STRING (SIZE (0..32)) 326 MAX-ACCESS read-only 327 STATUS current 328 DESCRIPTION 329 "This bit vector identifies which capabilities have 330 been announced by the remote BGP-4 speaker. 332 Capabilities are identified via the string of bits 333 within this object. The first octet contains bits 0 334 to 7, the second octet contains bits 8 to 15 and so 335 on. If a bit, i, is present and set, then the 336 capability (i+1) is supported. 338 When capabilities are not supported, all bits must 339 be zero." 340 ::= { bgpPeerCapabilitiesEntry 2 } 342 bgpProtocolExtensions OBJECT-TYPE 343 SYNTAX AutonomousType 344 MAX-ACCESS read-only 345 STATUS current 346 DESCRIPTION 347 "Registration point for MIB Modules for BGP 348 Protocol Extensions. 350 The Capabilities Advertisement RFC delineates 351 IANA registered capability code numbers, 0-127 352 and private use capability code numbers, 128-255. 354 The first sub-identifier will be the enterprise 355 number of the registering entity. This is used 356 to remove the ambiguity of the private use 357 portion of the capability code assignments. For 358 IANA registered capability codes 0-127, the first 359 sub-identifier will be 0. 361 The second sub-identifier will be the capability 362 code for the advertised capability. 364 For example, the MPBGP-MIB would be assigned as 365 { bgpProtocolStandardExtensions 0 1 } since it 366 has been assigned capability code number 1 and 367 is an IETF assigned (IANA registered) capability 368 extension." 369 REFERENCE 370 "RFC 2842 - Capabilities Advertisement with BGP-4" 371 ::= { bgp4OptParametersMIB 5 } 373 END 375 4. Intellectual Property 377 The IETF takes no position regarding the validity or scope of any 378 intellectual property or other rights that might be claimed to 379 pertain to the implementation or use of the technology described 380 in this document or the extent to which any license under such 381 rights might or might not be available; neither does it represent 382 that it has made any effort to identify any such rights. 383 Information on the IETF's procedures with respect to rights in 384 standards-track and standards-related documentation can be found 385 in BCP-11. Copies of claims of rights made available for 386 publication and any assurances of licenses to be made available, 387 or the result of an attempt made to obtain a general license or 388 permission for the use of such proprietary rights by implementors 389 or users of this specification can be obtained from the IETF 390 Secretariat. 392 5. Acknowledgements 394 The authors wish to thank Matt Richardson and Shane Wright of 395 NextHop for helpful feedback during the design of this document. 396 The authors wish to particularly thank Bert Wijnen of Lucent for 397 all the help in the MIB layout. 399 6. References 401 [1] Rekhter, Y., Li, T., "A Border Gateway Protocol 4 (BGP-4)", 402 RFC 1771, March 1995. 404 [2] Chandra, R., Scudder, T., "Capabilities Advertisement with 405 BGP-4", RFC 2842, May 2000. 407 [3] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 408 "Textual Conventions for Version 2 of the Simple Network 409 Management Protocol (SNMPv2)", RFC 1903, SNMP Research, Inc., 410 Cisco Systems, Inc., Dover Beach Consulting, Inc., 411 International Network Services, January 1996. 413 [3] Blumenthal, U., and B. Wijnen, "User-based Security Model 414 (USM) for version 3 of the Simple Network Management 415 Protocol (SNMPv3)", RFC 2274, IBM T. J. Watson Research, 416 January 1998. 418 [4] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 419 Access Control Model (VACM) for the Simple Network Management 420 Protocol (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC 421 Software, Inc., Cisco Systems, Inc., January 1998 423 7. Security Considerations 425 There are a number of management objects defined in this MIB that 426 have a MAX-ACCESS clause of read-write: 428 +o bgpAuthenticationCode 430 +o bgpAuthenticationDataType 432 +o bgpAuthenticationDataContents 434 +o bgpCapabilitySupportAvailable 436 These objects should be considered sensitive or vulnerable in most 437 network environments. The support for SET operations in a non- 438 secure environment without proper protection can have a negative 439 effect on network operations. Incorrect configuration of these 440 parameters may cause BGP peer connections to terminate early or to 441 send more routes under a flapping condition. 443 There are a number of managed objects in this MIB that may be 444 considered to contain sensitive information in the operation of a 445 network. For example, a BGP peer's local and remote addresses may 446 be sensitive for ISPs who want to keep interface addresses on 447 routers confidential to prevent router addresses used for a denial 448 of service attack or spoofing. 450 Therefore, it may be important in some environments to control 451 read access to these objects and possibly to even encrypt the 452 values of these object when sending them over the network via 453 SNMP. Not all versions of SNMP provide features for such a secure 454 environment. SNMPv1 by itself is not a secure environment. Even 455 if the network itself is secure (for example by using IPSec), even 456 then, there is no control as to who on the secure network is 457 allowed to access and GET/SET (read/change/create/delete) the 458 objects in this MIB. 460 It is recommended that the implementers consider the security 461 features as provided by the SNMPv3 framework. Specifically, the 462 use of the User-based Security Model RFC 2274 [3] and the View- 463 based Access Control Model RFC 2275 [4] is recommended. 465 It is then a customer/user responsibility to ensure that the SNMP 466 entity giving access to an instance of this MIB, is properly 467 configured to give access to the objects only to those principals 468 (users) that have legitimate rights to indeed GET or SET 469 (change/create/delete) them. 471 8. Authors Address 473 Jeffrey Haas 474 NextHop Technologies 475 517 Williams 476 Ann Arbor, MI 48103-4943 477 Phone: +1 734 936 2095 478 Fax: +1 734 615-3241 479 Email: jhaas@nexthop.com 481 Susan Hares 482 NextHop Technologies 483 517 Williams 484 Ann Arbor, MI 48103-4943 485 Phone: +1 734 936 2095 486 Fax: +1 734 615-3241 487 Email: skh@nexthop.com