idnits 2.17.1 draft-jhaas-idr-bgp4-mibv2-community-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 378. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 385. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 391. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (November 2, 2008) is 5653 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing Working Group J. Haas 3 Internet-Draft Arbor Networks 4 Intended status: Standards Track November 2, 2008 5 Expires: May 6, 2009 7 Definitions of Managed Objects for the Fourth Version of Border Gateway 8 Protocol (BGP-4), BGP Community Extension 9 draft-jhaas-idr-bgp4-mibv2-community-02 11 Status of This Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 6, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This memo defines a portion of the Management Information Base (MIB) 43 for use with network management protocols. In particular it defines 44 objects for managing the Border Gateway Protocol's Community 45 extension. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. The Internet-Standard Management Framework . . . . . . . . . . 3 51 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 5. Structure of the MIB Module . . . . . . . . . . . . . . . . . . 3 54 5.1. Tables . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 6. Relationship to Other MIB Modules . . . . . . . . . . . . . . . 4 56 6.1. MIB modules required for IMPORTS . . . . . . . . . . . . . 4 57 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 59 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 60 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 62 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 64 1. Introduction 66 This memo defines a portion of the Management Information Base (MIB) 67 for use with network management protocols. In particular it defines 68 objects for managing the Border Gateway Protocol's Community 69 extension. [RFC1997]. 71 2. The Internet-Standard Management Framework 73 For a detailed overview of the documents that describe the current 74 Internet-Standard Management Framework, please refer to section 7 of 75 RFC 3410 [RFC3410]. 77 Managed objects are accessed via a virtual information store, termed 78 the Management Information Base or MIB. MIB objects are generally 79 accessed through the Simple Network Management Protocol (SNMP). 80 Objects in the MIB are defined using the mechanisms defined in the 81 Structure of Management Information (SMI). This memo specifies a MIB 82 module that is compliant to the SMIv2, which is described in STD 58, 83 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 84 [RFC2580]. 86 3. Conventions 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 [RFC2119]. 92 4. Overview 94 The BGP-4 MIB, Version 2, provides for an extension mechanism by 95 which BGP extensions can have MIBs created under the BGP-4 MIB 96 subtree. This MIB documents the objects for managing the BGP-4 97 Community extension as documented in [RFC1997]. 99 5. Structure of the MIB Module 101 5.1. Tables 103 o bgp4V2CommunityTable - This table provides access to a human- 104 readable version of the community associated with BGP reachability 105 and also access to the encoded version of the communities attached 106 to the reachability. 108 6. Relationship to Other MIB Modules 110 6.1. MIB modules required for IMPORTS 112 The following MIB module IMPORTS objects from SNMPv2-SMI [RFC2578], 113 SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580] and the BGP-4 MIB, Version 114 2. 116 7. Definitions 118 BGP4V2-COMMUNITY-MIB DEFINITIONS ::= BEGIN 120 IMPORTS 121 mib-2, MODULE-IDENTITY, OBJECT-TYPE 122 FROM SNMPv2-SMI 123 MODULE-COMPLIANCE, OBJECT-GROUP 124 FROM SNMPv2-CONF 125 SnmpAdminString 126 FROM SNMP-FRAMEWORK-MIB 127 Bgp4V2AddressFamilyIdentifierTC, 128 Bgp4V2SubsequentAddressFamilyIdentifierTC 129 FROM BGP4V2-TC-MIB 130 bgp4V2PeerInstance, bgp4V2NlriAfi, bgp4V2NlriSafi, 131 bgp4V2NlriPrefix, bgp4V2NlriPrefixLen, 132 bgp4V2PeerLocalAddrType, bgp4V2PeerLocalAddr, 133 bgp4V2PeerRemoteAddrType, bgp4V2PeerRemoteAddr, 134 bgp4V2NlriIndex 135 FROM BGP4V2-MIB; 137 bgp4V2Community MODULE-IDENTITY 138 LAST-UPDATED "200811020000Z" 139 ORGANIZATION "IETF IDR Working Group" 140 CONTACT-INFO "E-mail: idr@ietf.org" 141 DESCRIPTION 142 "This MIB module defines additional management objects 143 for the Border Gateway Protocol, Version 4. 144 Specifically, it adds objects for the management of the 145 BGP Community PATH_ATTRIBUTE as documented in RFC 1997." 146 REVISION "200811020000Z" 147 DESCRIPTION 148 "Initial revision." 149 ::= { mib-2 XXX } 151 -- Top level components of this MIB module 153 -- Ojbects 154 bgp4V2CommunityObjects 155 OBJECT IDENTIFIER ::= { bgp4V2Community 1 } 157 -- Conformance 158 bgp4V2CommunityConformance 159 OBJECT IDENTIFIER ::= { bgp4V2Community 2 } 161 -- 162 -- BGP Communities per-NLRI entry. 163 -- 165 bgp4V2CommunityTable OBJECT-TYPE 166 SYNTAX SEQUENCE OF Bgp4V2CommunityEntry 167 MAX-ACCESS not-accessible 168 STATUS current 169 DESCRIPTION 170 "The BGP-4 Path Attribute Community Table contains the 171 per network path (NLRI) data on the community membership 172 advertised with a route." 173 ::= { bgp4V2CommunityObjects 1 } 175 bgp4V2CommunityEntry OBJECT-TYPE 176 SYNTAX Bgp4V2CommunityEntry 177 MAX-ACCESS not-accessible 178 STATUS current 179 DESCRIPTION 180 "Information about a community association provided with a 181 path to a network. Note that although this table shares 182 the indices of bgp4V2NlriTable that not all reachability 183 may have communities." 184 INDEX { 185 bgp4V2PeerInstance, 186 bgp4V2NlriAfi, 187 bgp4V2NlriSafi, 188 bgp4V2NlriPrefix, 189 bgp4V2NlriPrefixLen, 190 bgp4V2PeerLocalAddrType, 191 bgp4V2PeerLocalAddr, 192 bgp4V2PeerRemoteAddrType, 193 bgp4V2PeerRemoteAddr, 194 bgp4V2NlriIndex 195 } 196 ::= { bgp4V2CommunityTable 1 } 198 Bgp4V2CommunityEntry ::= SEQUENCE { 199 bgp4V2CommunityString 200 SnmpAdminString, 201 bgp4V2Communities 202 OCTET STRING 203 } 205 bgp4V2CommunityString OBJECT-TYPE 206 SYNTAX SnmpAdminString 207 MAX-ACCESS read-only 208 STATUS current 209 DESCRIPTION 210 "This is a string depicting the set of communities 211 associated with a given NLRI. The format of this string is 212 implementation-dependent and should be designed for 213 operator readability. 215 Note that SnmpAdminString is only capable of representing a 216 maximum of 255 characters. This may lead to the string 217 being truncated in the presence of a large AS Path. It is 218 RECOMMENDED that when this object's contents will be 219 truncated that the final 3 octets be reserved for the 220 ellipses string, '...'. bgp4V2Communities may give access 221 to the full set of communities." 222 ::= { bgp4V2CommunityEntry 1 } 224 bgp4V2Communities OBJECT-TYPE 225 SYNTAX OCTET STRING (SIZE(0..4072)) 226 MAX-ACCESS read-only 227 STATUS current 228 DESCRIPTION 229 "This object contains the list of BGP Communities associated 230 with the reachability. Each community consists of four 231 octets and is interpreted according to the syntax 232 documented in RFC 1997. Briefly, the first two octets of 233 each community is a 2-octet Autonomous System number in 234 network byte order and the lower two octets is a 2-octet 235 number with semantics specific to that AS. 237 Note also that certain well-known values will have 238 additional semantics. 240 In the circumstance where this object must be truncated by 241 the implementation, the implementation SHOULD truncate the 242 object on a 4-octet divisible boundary in order to provide 243 all communities in-tact." 244 ::= { bgp4V2CommunityEntry 2 } 246 -- 247 -- Conformance Information 248 -- 249 bgp4V2CommunityMIBCompliances OBJECT IDENTIFIER ::= 250 { bgp4V2CommunityConformance 1 } 252 bgp4V2CommunityMIBGroups OBJECT IDENTIFIER ::= 253 { bgp4V2CommunityConformance 2 } 255 bgp4V2CommunityMIBCompliance MODULE-COMPLIANCE 256 STATUS current 257 DESCRIPTION 258 "The compliance statement for entities which 259 implement the BGP4 mib." 260 MODULE -- this module 261 MANDATORY-GROUPS { 262 bgp4V2CommunityRequiredGroup 263 } 264 ::= { bgp4V2CommunityMIBCompliances 1 } 266 bgp4V2CommunityRequiredGroup OBJECT-GROUP 267 OBJECTS { 268 bgp4V2CommunityString, 269 bgp4V2Communities 270 } 271 STATUS current 272 DESCRIPTION 273 "Objects associated with BGP communities that are 274 required to be implemented in this MIB." 275 ::= { bgp4V2CommunityMIBGroups 1 } 276 END 278 8. Security Considerations 280 Some of the readable objects in this MIB module (i.e., objects with a 281 MAX-ACCESS other than not-accessible) may be considered sensitive or 282 vulnerable in some network environments. It is thus important to 283 control even GET and/or NOTIFY access to these objects and possibly 284 to even encrypt the values of these objects when sending them over 285 the network via SNMP. These are the tables and objects and their 286 sensitivity/vulnerability: 288 o bgp4V2CommunityString, bgp4V2Communities - BGP Communities may be 289 used to implement routing policy for ISPs and that routing policy 290 may reflect business relationships. Inadvertent disclosure of 291 this information inadvertently expose sensitive information about 292 those business relationships. 294 SNMP versions prior to SNMPv3 did not include adequate security. 295 Even if the network itself is secure (for example by using IPSec), 296 even then, there is no control as to who on the secure network is 297 allowed to access and GET/SET (read/change/create/delete) the objects 298 in this MIB module. 300 It is RECOMMENDED that implementers consider the security features as 301 provided by the SNMPv3 framework (see [RFC3410], section 8), 302 including full support for the SNMPv3 cryptographic mechanisms (for 303 authentication and privacy). 305 Further, deployment of SNMP versions prior to SNMPv3 is NOT 306 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 307 enable cryptographic security. It is then a customer/operator 308 responsibility to ensure that the SNMP entity giving access to an 309 instance of this MIB module is properly configured to give access to 310 the objects only to those principals (users) that have legitimate 311 rights to indeed GET or SET (change/create/delete) them. 313 9. IANA Considerations 315 This memo includes no request to IANA. 317 10. References 319 10.1. Normative References 321 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 322 Requirement Levels", BCP 14, RFC 2119, March 1997. 324 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 325 Schoenwaelder, Ed., "Structure of Management Information 326 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 328 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 329 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 330 STD 58, RFC 2579, April 1999. 332 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 333 "Conformance Statements for SMIv2", STD 58, RFC 2580, 334 April 1999. 336 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 337 Communities Attribute", RFC 1997, August 1996. 339 10.2. Informative References 341 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 342 "Introduction and Applicability Statements for Internet- 343 Standard Management Framework", RFC 3410, December 2002. 345 Author's Address 347 Jeffrey Haas 348 Arbor Networks 350 Phone: 351 EMail: jhaas@arbor.net 353 Full Copyright Statement 355 Copyright (C) The IETF Trust (2008). 357 This document is subject to the rights, licenses and restrictions 358 contained in BCP 78, and except as set forth therein, the authors 359 retain all their rights. 361 This document and the information contained herein are provided on an 362 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 363 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 364 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 365 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 366 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 367 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 369 Intellectual Property 371 The IETF takes no position regarding the validity or scope of any 372 Intellectual Property Rights or other rights that might be claimed to 373 pertain to the implementation or use of the technology described in 374 this document or the extent to which any license under such rights 375 might or might not be available; nor does it represent that it has 376 made any independent effort to identify any such rights. Information 377 on the procedures with respect to rights in RFC documents can be 378 found in BCP 78 and BCP 79. 380 Copies of IPR disclosures made to the IETF Secretariat and any 381 assurances of licenses to be made available, or the result of an 382 attempt made to obtain a general license or permission for the use of 383 such proprietary rights by implementers or users of this 384 specification can be obtained from the IETF on-line IPR repository at 385 http://www.ietf.org/ipr. 387 The IETF invites any interested party to bring to its attention any 388 copyrights, patents or patent applications, or other proprietary 389 rights that may cover technology that may be required to implement 390 this standard. Please address the information to the IETF at 391 ietf-ipr@ietf.org. 393 Acknowledgement 395 Funding for the RFC Editor function is provided by the IETF 396 Administrative Support Activity (IASA).