idnits 2.17.1
draft-ietf-opsawg-rfc5066bis-06.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
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 and authors Copyright Line does not
match the current year
(Using the creation date from RFC5066, updated by this document, for
RFC5378 checks: 2004-01-14)
-- 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 26, 2013) is 3803 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: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group E. Beili
3 Internet-Draft Actelis Networks
4 Updates: 5066 (if approved) November 26, 2013
5 Intended status: Standards Track
6 Expires: May 30, 2014
8 Ethernet in the First Mile Copper (EFMCu) Interfaces MIB
9 draft-ietf-opsawg-rfc5066bis-06.txt
11 Abstract
13 This document updates RFC 5066. It amends that specification by
14 informing the internet community about the transition of the EFM-CU-
15 MIB module from the concluded IETF Ethernet Interfaces and Hub MIB
16 Working Group to the Institute of Electrical and Electronics
17 Engineers (IEEE) 802.3 working group.
19 Status of This Memo
21 This Internet-Draft is submitted in full conformance with the
22 provisions of BCP 78 and BCP 79.
24 Internet-Drafts are working documents of the Internet Engineering
25 Task Force (IETF). Note that other groups may also distribute
26 working documents as Internet-Drafts. The list of current Internet-
27 Drafts is at http://datatracker.ietf.org/drafts/current/.
29 Internet-Drafts are draft documents valid for a maximum of six months
30 and may be updated, replaced, or obsoleted by other documents at any
31 time. It is inappropriate to use Internet-Drafts as reference
32 material or to cite them other than as "work in progress."
34 This Internet-Draft will expire on May 30, 2014.
36 Copyright Notice
38 Copyright (c) 2013 IETF Trust and the persons identified as the
39 document authors. All rights reserved.
41 This document is subject to BCP 78 and the IETF Trust's Legal
42 Provisions Relating to IETF Documents
43 (http://trustee.ietf.org/license-info) in effect on the date of
44 publication of this document. Please review these documents
45 carefully, as they describe your rights and restrictions with respect
46 to this document. Code Components extracted from this document must
47 include Simplified BSD License text as described in Section 4.e of
48 the Trust Legal Provisions and are provided without warranty as
49 described in the Simplified BSD License.
51 Table of Contents
53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
54 2. The Internet-Standard Management Framework . . . . . . . . . . 3
55 3. Mapping between EFM-CU-MIB and IEEE8023-EFM-CU-MIB . . . . . . 3
56 4. Updating the MIB Modules . . . . . . . . . . . . . . . . . . . 4
57 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
59 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
61 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
62 8.2. Informative References . . . . . . . . . . . . . . . . . . 6
64 1. Introduction
66 RFC 5066 [RFC5066] defines two MIB modules:
68 EFM-CU-MIB, with a set of objects for managing 10PASS-TS and
69 2BASE-TL Ethernet in the First Mile Copper (EFMCu) interfaces;
71 IF-CAP-STACK-MIB, with a set of objects describing cross-connect
72 capability of a managed device with multi-layer (stacked)
73 interfaces, extending the stack management objects in the
74 Interfaces Group MIB and the Inverted Stack Table MIB modules.
76 With the conclusion of the [HUBMIB] working group, the responsibility
77 for the maintenance and further development of a MIB module for
78 managing 2BASE-TL and 10PASS-TS interfaces, has been transfered to
79 the Institute of Electrical and Electronics Engineers (IEEE) 802.3
80 [IEEE802.3] working group. In 2011, the IEEE developed IEEE8023-EFM-
81 CU-MIB module, based on the original EFM-CU-MIB module [RFC5066].
82 The current revision of IEEE8023-EFM-CU-MIB is defined in IEEE Std
83 802.3.1-2013 [IEEE802.3.1].
85 The IEEE8023-EFM-CU-MIB and EFM-CU-MIB MIB modules can coexist.
87 Please note that IF-CAP-STACK-MIB module was not transfered to IEEE
88 and remains as defined in RFC 5066. This memo provides an updated
89 security considerations section for that module, since the original
90 RFC did not list any security consideration for IF-CAP-STACK-MIB.
92 2. The Internet-Standard Management Framework
94 For a detailed overview of the documents that describe the current
95 Internet-Standard Management Framework, please refer to section 7 of
96 RFC 3410 [RFC3410].
98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
100 "OPTIONAL" in this document are to be interpreted as described in RFC
101 2119 [RFC2119].
103 3. Mapping between EFM-CU-MIB and IEEE8023-EFM-CU-MIB
105 The current version of IEEE8023-EFM-CU-MIB, defined in IEEE Std
106 802.3.1-2013, has MODULE-IDENTITY of ieee8023efmCuMIB with an object
107 identifier allocated under the { org ieee standards-association-
108 numbers-series-standards lan-man-stds ieee802dot3 ieee802dot3dot1mibs
109 } sub-tree.
111 The EFM-CU-MIB has MODULE-IDENTITY of efmCuMIB with an object
112 identifier allocated under the mib-2 sub-tree.
114 The names of the objects in the first version of the IEEE8023-EFM-CU-
115 MIB are identical to those in the EFM-CU-MIB. However, since both
116 MIB modules have different OID values, they can coexist, allowing the
117 management of the newer IEEE MIB-based devices, alongside the legacy
118 IETF MIB-based devices.
120 4. Updating the MIB Modules
122 With the transfer of the responsibility for maintenance and further
123 development of the EFM-CU-MIB module to the IEEE 802.3 working group,
124 the EFM-CU-MIB defined in RFC 5066 becomes the last version of that
125 MIB module.
127 All further development of the EFM Copper Interfaces MIB will be done
128 by the IEEE 802.3 working group in the IEEE8023-EFM-CU-MIB module.
129 Requests and comments pertaining to EFM Copper Interfaces MIB should
130 be sent to the IEEE 802.3.1 task force, currently chartered with MIB
131 development, via its mailing list [LIST802.3.1].
133 The IF-CAP-STACK-MIB remains under IETF control and is currently
134 maintained by the [OPSAWG] working group.
136 5. Security Considerations
138 There are no managed objects defined in IF-CAP-STACK-MIB module with
139 a MAX-ACCESS clause of read-write and/or read-create.
141 Some of the readable objects in this MIB module (i.e., those with
142 MAX-ACCESS other than not-accessible) may be considered sensitive or
143 vulnerable in some network environments since they can reveal some
144 configuration aspects of the network interfaces.
146 In particular, ifCapStackStatus and ifInvCapStackStatus can identify
147 cross-connect capability of multi-layer (stacked) network interfaces,
148 potentially revealing the underlying hardware architecture of the
149 managed device.
151 It is thus important to control even GET access to these objects and
152 possibly even encrypt the values of these objects when sending them
153 over the network via SNMP.
155 SNMP versions prior to SNMPv3 did not include adequate security.
156 Even if the network itself is secure (for example by using IPSec),
157 there is no control as to who on the secure network is allowed to
158 access and GET/SET (read/change/create/delete) the objects in this
159 MIB module.
161 Implementations MUST provide the security features described by the
162 SNMPv3 framework (see [RFC3410]), including full support for
163 authentication and privacy via the User-based Security Model (USM)
164 [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations
165 MAY also provide support for the Transport Security Model (TSM)
166 [RFC5591] in combination with a secure transport such as SSH
167 [RFC5592] or TLS/DTLS [RFC6353].
169 Further, deployment of SNMP versions prior to SNMPv3 is NOT
170 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
171 enable cryptographic security. It is then a customer/operator
172 responsibility to ensure that the SNMP entity giving access to an
173 instance of this MIB module is properly configured to give access to
174 the objects only to those principals (users) that have legitimate
175 rights to indeed GET or SET (change/create/delete) them.
177 6. IANA Considerations
179 No action is required from IANA.
181 7. Acknowledgments
183 This document was produced by the OPSAWG working group, whose efforts
184 were advanced by the contributions of the following people (in
185 alphabetical order):
187 Dan Romascanu
189 David Harrington
191 Michael MacFaden
193 Tom Petch
195 This document updates RFC 5066, authored by Edward Beili of Actelis
196 Networks, and produced by the, now concluded, HUBMIB working group.
198 8. References
200 8.1. Normative References
202 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
203 Requirement Levels", BCP 14, RFC 2119, March 1997.
205 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security
206 Model (USM) for version 3 of the Simple Network
207 Management Protocol (SNMPv3)", STD 62, RFC 3414,
208 December 2002.
210 [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The
211 Advanced Encryption Standard (AES) Cipher Algorithm in
212 the SNMP User-based Security Model", RFC 3826,
213 June 2004.
215 [RFC5066] Beili, E., "Ethernet in the First Mile Copper (EFMCu)
216 Interfaces MIB", RFC 5066, November 2007.
218 8.2. Informative References
220 [HUBMIB] IETF, "Ethernet Interfaces and Hub MIB (hubmib)
221 Charter",
222 .
224 [IEEE802.3] IEEE, "802.3 Ethernet Working Group",
225 .
227 [IEEE802.3.1] IEEE, "IEEE Standard for Management Information Base
228 (MIB) Definitions for Ethernet", IEEE Std 802.3.1-
229 2013, June 2013.
231 [LIST802.3.1] IEEE, "802.3 MIB Email Reflector",
232 .
234 [OPSAWG] IETF, "Operations and Management Area Working Group
235 (opsawg) Charter",
236 .
238 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
239 "Introduction and Applicability Statements for
240 Internet-Standard Management Framework", RFC 3410,
241 December 2002.
243 [RFC5591] Harrington, D. and W. Hardaker, "Transport Security
244 Model for the Simple Network Management Protocol
245 (SNMP)", RFC 5591, June 2009.
247 [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure
248 Shell Transport Model for the Simple Network
249 Management Protocol (SNMP)", RFC 5592, June 2009.
251 [RFC6353] Hardaker, W., "Transport Layer Security (TLS)
252 Transport Model for the Simple Network Management
253 Protocol (SNMP)", RFC 6353, July 2011.
255 Author's Address
257 Edward Beili
258 Actelis Networks
259 Bazel 25
260 Petach-Tikva
261 Israel
263 Phone: +972-73-237-6852
264 EMail: edward.beili@actelis.com