Inter-Domain Routing Working Group J. Haas Internet-Draft Arbor Networks Intended status: Standards Track November 2, 2008 Expires: May 6, 2009 Definitions of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4), BGP Community Extension draft-jhaas-idr-bgp4-mibv2-community-02 Status of This Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 6, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the Border Gateway Protocol's Community extension. Haas Expires May 6, 2009 [Page 1] Internet-Draft BGP-4 Community MIB November 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Internet-Standard Management Framework . . . . . . . . . . 3 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. Structure of the MIB Module . . . . . . . . . . . . . . . . . . 3 5.1. Tables . . . . . . . . . . . . . . . . . . . . . . . . . . 3 6. Relationship to Other MIB Modules . . . . . . . . . . . . . . . 4 6.1. MIB modules required for IMPORTS . . . . . . . . . . . . . 4 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 Haas Expires May 6, 2009 [Page 2] Internet-Draft BGP-4 Community MIB November 2008 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols. In particular it defines objects for managing the Border Gateway Protocol's Community extension. [RFC1997]. 2. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 4. Overview The BGP-4 MIB, Version 2, provides for an extension mechanism by which BGP extensions can have MIBs created under the BGP-4 MIB subtree. This MIB documents the objects for managing the BGP-4 Community extension as documented in [RFC1997]. 5. Structure of the MIB Module 5.1. Tables o bgp4V2CommunityTable - This table provides access to a human- readable version of the community associated with BGP reachability and also access to the encoded version of the communities attached to the reachability. Haas Expires May 6, 2009 [Page 3] Internet-Draft BGP-4 Community MIB November 2008 6. Relationship to Other MIB Modules 6.1. MIB modules required for IMPORTS The following MIB module IMPORTS objects from SNMPv2-SMI [RFC2578], SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580] and the BGP-4 MIB, Version 2. 7. Definitions BGP4V2-COMMUNITY-MIB DEFINITIONS ::= BEGIN IMPORTS mib-2, MODULE-IDENTITY, OBJECT-TYPE FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB Bgp4V2AddressFamilyIdentifierTC, Bgp4V2SubsequentAddressFamilyIdentifierTC FROM BGP4V2-TC-MIB bgp4V2PeerInstance, bgp4V2NlriAfi, bgp4V2NlriSafi, bgp4V2NlriPrefix, bgp4V2NlriPrefixLen, bgp4V2PeerLocalAddrType, bgp4V2PeerLocalAddr, bgp4V2PeerRemoteAddrType, bgp4V2PeerRemoteAddr, bgp4V2NlriIndex FROM BGP4V2-MIB; bgp4V2Community MODULE-IDENTITY LAST-UPDATED "200811020000Z" ORGANIZATION "IETF IDR Working Group" CONTACT-INFO "E-mail: idr@ietf.org" DESCRIPTION "This MIB module defines additional management objects for the Border Gateway Protocol, Version 4. Specifically, it adds objects for the management of the BGP Community PATH_ATTRIBUTE as documented in RFC 1997." REVISION "200811020000Z" DESCRIPTION "Initial revision." ::= { mib-2 XXX } -- Top level components of this MIB module -- Ojbects Haas Expires May 6, 2009 [Page 4] Internet-Draft BGP-4 Community MIB November 2008 bgp4V2CommunityObjects OBJECT IDENTIFIER ::= { bgp4V2Community 1 } -- Conformance bgp4V2CommunityConformance OBJECT IDENTIFIER ::= { bgp4V2Community 2 } -- -- BGP Communities per-NLRI entry. -- bgp4V2CommunityTable OBJECT-TYPE SYNTAX SEQUENCE OF Bgp4V2CommunityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The BGP-4 Path Attribute Community Table contains the per network path (NLRI) data on the community membership advertised with a route." ::= { bgp4V2CommunityObjects 1 } bgp4V2CommunityEntry OBJECT-TYPE SYNTAX Bgp4V2CommunityEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a community association provided with a path to a network. Note that although this table shares the indices of bgp4V2NlriTable that not all reachability may have communities." INDEX { bgp4V2PeerInstance, bgp4V2NlriAfi, bgp4V2NlriSafi, bgp4V2NlriPrefix, bgp4V2NlriPrefixLen, bgp4V2PeerLocalAddrType, bgp4V2PeerLocalAddr, bgp4V2PeerRemoteAddrType, bgp4V2PeerRemoteAddr, bgp4V2NlriIndex } ::= { bgp4V2CommunityTable 1 } Bgp4V2CommunityEntry ::= SEQUENCE { bgp4V2CommunityString SnmpAdminString, bgp4V2Communities Haas Expires May 6, 2009 [Page 5] Internet-Draft BGP-4 Community MIB November 2008 OCTET STRING } bgp4V2CommunityString OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "This is a string depicting the set of communities associated with a given NLRI. The format of this string is implementation-dependent and should be designed for operator readability. Note that SnmpAdminString is only capable of representing a maximum of 255 characters. This may lead to the string being truncated in the presence of a large AS Path. It is RECOMMENDED that when this object's contents will be truncated that the final 3 octets be reserved for the ellipses string, '...'. bgp4V2Communities may give access to the full set of communities." ::= { bgp4V2CommunityEntry 1 } bgp4V2Communities OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..4072)) MAX-ACCESS read-only STATUS current DESCRIPTION "This object contains the list of BGP Communities associated with the reachability. Each community consists of four octets and is interpreted according to the syntax documented in RFC 1997. Briefly, the first two octets of each community is a 2-octet Autonomous System number in network byte order and the lower two octets is a 2-octet number with semantics specific to that AS. Note also that certain well-known values will have additional semantics. In the circumstance where this object must be truncated by the implementation, the implementation SHOULD truncate the object on a 4-octet divisible boundary in order to provide all communities in-tact." ::= { bgp4V2CommunityEntry 2 } -- -- Conformance Information -- Haas Expires May 6, 2009 [Page 6] Internet-Draft BGP-4 Community MIB November 2008 bgp4V2CommunityMIBCompliances OBJECT IDENTIFIER ::= { bgp4V2CommunityConformance 1 } bgp4V2CommunityMIBGroups OBJECT IDENTIFIER ::= { bgp4V2CommunityConformance 2 } bgp4V2CommunityMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for entities which implement the BGP4 mib." MODULE -- this module MANDATORY-GROUPS { bgp4V2CommunityRequiredGroup } ::= { bgp4V2CommunityMIBCompliances 1 } bgp4V2CommunityRequiredGroup OBJECT-GROUP OBJECTS { bgp4V2CommunityString, bgp4V2Communities } STATUS current DESCRIPTION "Objects associated with BGP communities that are required to be implemented in this MIB." ::= { bgp4V2CommunityMIBGroups 1 } END 8. Security Considerations Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. These are the tables and objects and their sensitivity/vulnerability: o bgp4V2CommunityString, bgp4V2Communities - BGP Communities may be used to implement routing policy for ISPs and that routing policy may reflect business relationships. Inadvertent disclosure of this information inadvertently expose sensitive information about those business relationships. SNMP versions prior to SNMPv3 did not include adequate security. 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 Haas Expires May 6, 2009 [Page 7] Internet-Draft BGP-4 Community MIB November 2008 allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module 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. 9. IANA Considerations This memo includes no request to IANA. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996. 10.2. Informative References [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. Haas Expires May 6, 2009 [Page 8] Internet-Draft BGP-4 Community MIB November 2008 Author's Address Jeffrey Haas Arbor Networks Phone: EMail: jhaas@arbor.net Haas Expires May 6, 2009 [Page 9] Internet-Draft BGP-4 Community MIB November 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Haas Expires May 6, 2009 [Page 10]