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]