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 7, 2009.

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.

Table of Contents

1.  Introduction
2.  The Internet-Standard Management Framework
3.  Conventions
4.  Overview
5.  Structure of the MIB Module
    5.1.  Tables
6.  Relationship to Other MIB Modules
    6.1.  MIB modules required for IMPORTS
7.  Definitions
8.  Security Considerations
9.  IANA Considerations
10.  References
    10.1.  Normative References
    10.2.  Informative References

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] (Chandrasekeran, R., Traina, P., and T. Li, “BGP Communities Attribute,” August 1996.).

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] (Case, J., Mundy, R., Partain, D., and B. Stewart, “Introduction and Applicability Statements for Internet-Standard Management Framework,” December 2002.).

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] (McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., “Structure of Management Information Version 2 (SMIv2),” April 1999.), STD 58, RFC 2579 [RFC2579] (McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., “Textual Conventions for SMIv2,” April 1999.) and STD 58, RFC 2580 [RFC2580] (McCloghrie, K., Perkins, D., and J. Schoenwaelder, “Conformance Statements for SMIv2,” April 1999.).

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

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] (Chandrasekeran, R., Traina, P., and T. Li, “BGP Communities Attribute,” August 1996.).

5.  Structure of the MIB Module

5.1.  Tables

• 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.

6.  Relationship to Other MIB Modules

6.1.  MIB modules required for IMPORTS

The following MIB module IMPORTS objects from SNMPv2-SMI [RFC2578] (McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., “Structure of Management Information Version 2 (SMIv2),” April 1999.), SNMPv2-TC [RFC2579] (McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., “Textual Conventions for SMIv2,” April 1999.), SNMPv2-CONF [RFC2580] (McCloghrie, K., Perkins, D., and J. Schoenwaelder, “Conformance Statements for SMIv2,” April 1999.) 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
    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
            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
    --

    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:

• 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 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] (Case, J., Mundy, R., Partain, D., and B. Stewart, “Introduction and Applicability Statements for Internet-Standard Management Framework,” December 2002.), 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

10.2. Informative References

Author's Address

Full Copyright Statement

Copyright © 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.