::= { mplsTeGroups 5 }
mplsTunnelIsNotIntfcGroup OBJECT-GROUP
OBJECTS { mplsTunnelIsIf }
STATUS current
DESCRIPTION
"Objects needed to implement tunnels that are not
interfaces."
::= { mplsTeGroups 6 }
mplsTunnelCRLDPResOptionalGroup OBJECT-GROUP
OBJECTS {
mplsTunnelCRLDPResMeanBurstSize,
mplsTunnelCRLDPResExBurstSize,
mplsTunnelCRLDPResFrequency,
mplsTunnelCRLDPResWeight,
mplsTunnelCRLDPResFlags,
mplsTunnelCRLDPResRowStatus,
mplsTunnelCRLDPResStorageType
}
STATUS current
DESCRIPTION
"Set of objects implemented for resources applicable
for tunnels signaled using CR-LDP."
::= { mplsTeGroups 7 }
mplsTeNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS {
mplsTunnelUp,
mplsTunnelDown,
mplsTunnelRerouted,
mplsTunnelReoptimized
}
STATUS current
DESCRIPTION
"Set of notifications implemented in this module.
None is mandatory."
::= { mplsTeGroups 8 }
END
12. Security Considerations
It is clear that this MIB module is potentially useful for the
monitoring of MPLS TE tunnels. This MIB module can also be used for
the configuration of certain objects, and anything that can be
configured can be incorrectly configured, with potentially disastrous
results.
There are a number of management objects defined in this MIB module
with a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on
network operations. These are the tables and objects and their
sensitivity/vulnerability:
- the mplsTunnelTable, mplsTunnelHopTable, mplsTunnelResourceTable,
and mplsTunnelCRLDPResTable collectively contain objects to
provision MPLS tunnels, tunnel hops, and tunnel resources.
Unauthorized access to objects in these tables, could result in
disruption of traffic on the network. This is especially true if
a tunnel has been established. The use of stronger mechanisms,
such as SNMPv3 security, should be considered where possible.
Specifically, SNMPv3 VACM and USM MUST be used with any v3 agent
which implements this MIB. Administrators should consider whether
read access to these objects should be allowed, since read access
may be undesirable under certain circumstances.
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:
- the mplsTunnelTable, mplsTunnelHopTable, mplsTunnelResourceTable,
mplsTunnelARHopTable, mplsTunnelCHopTable, mplsTunnelPerfTable,
and mplsTunnelCRLDPResTable collectively show the MPLS-TE tunnel
network topology and its performance characteristics. If an
Administrator does not want to reveal this information, then these
tables should be considered sensitive/vulnerable.
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], 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 that SNMPv3 be deployed and
cryptographic security enabled. 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
only those principals (users) that have legitimate rights to those
objects.
13. Acknowledgments
We wish to thank Adrian Farrel, Bert Wijnen, Eric Gray, Joan
Cucchiara, Patrick Kerharo, Paul Langille, Marcus Brunner, Mike
MacFaden, and Mike Piecuch for their comments on this document.
Comments should be made directly to the MPLS mailing list at
mpls@uu.net.
14. IANA Considerations
As described in [MPLSMGMT] and as requested in the MPLS-TC-STD-MIB
[RFC3811], MPLS related standards track MIB modules should be rooted
under the mplsStdMIB subtree. There are 4 MPLS MIB Modules contained
in this document, each of the following "IANA Considerations"
subsections requests IANA for a new assignment under the mplsStdMIB
subtree. New assignments can only be made via a Standards Action as
specified in [RFC2434].
14.1. IANA Considerations for MPLS-TE-STD-MIB
The IANA has assigned { mplsStdMIB 3 } to the MPLS-TE-STD-MIB module
specified in this document.
15. References
15.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., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"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.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O’Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999.
[RFC2863] McCloghrie, K. and F. Kastenholtz, "The Interfaces Group
MIB ", RFC 2863, June 2000.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3212] Jamoussi, B., Ed., Andersson, L., Callon, R, Dantu, R.,
Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette,
A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A.
Malis, "Constraint-Based LSP Setup using LDP", RFC 3212,
January 2002.
[RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information
Base for the Differentiated Services Architecture", RFC
3289, May 2002.
[RFC3291] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "TextualConventions for Internet Network
Addresses", RFC 3291, May 2002.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
[RFC3811] Nadeau, T. and J. Cucchiara, "Definition of Textual
Conventions and for Multiprotocol Label Switching (MPLS)
Management", RFC 3811, June 2004.
[RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Label Switching
(LSR) Router Management Information Base (MIB)", RFC 3813,
June 2004.
15.2. Informative References
[MPLSMGMT] Nadeau, T., Srinivasan, C., and A. Farrel, "Multiprotocol
Label Switching (MPLS) Management Overview", Work in
Progress, September 2003.
[RFC2434] Narten, T. and H. Alvestrand., "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statement for Internet
Standard Management Framework", RFC 3410, December 2002.
16. Authors’ Addresses
Cheenu Srinivasan
Bloomberg L.P.
499 Park Ave., New York, NY 10022
Phone: +1-212-893-3682
EMail: cheenu@bloomberg.net
Arun Viswanathan
Force10 Networks, Inc.
1440 McCarthy Blvd
Milpitas, CA 95035
Phone: +1-408-571-3516
EMail: arunv@force10networks.com
Thomas D. Nadeau
Cisco Systems, Inc.
300 Apollo Drive
Chelmsford, MA 01824
Phone: +1-978-244-3051
EMail: tnadeau@cisco.com
17. Full Copyright Statement
Copyright (C) The Internet Society (2004). 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 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 currently provided by the
Internet Society.