idnits 2.17.1 draft-ietf-opsawg-rfc5066bis-04.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 06, 2013) is 3824 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 06, 2013 5 Intended status: Standards Track 6 Expires: May 10, 2014 8 Ethernet in the First Mile Copper (EFMCu) Interfaces MIB 9 draft-ietf-opsawg-rfc5066bis-04.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 10, 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 [802.3] working group. The IEEE developed IEEE8023-EFM-CU-MIB 81 module, defined in IEEE Std 802.3.1-2011 [802.3.1] and based on the 82 EFM-CU-MIB, defined in RFC 5066. 84 The IEEE8023-EFM-CU-MIB and EFM-CU-MIB MIB modules can coexist. 86 Please note that IF-CAP-STACK-MIB module was not transfered to IEEE 87 and remains as defined in RFC 5066. This memo provides an updated 88 security considerations section for that module, since the original < 89 RFC did not list any security consideration for IF-CAP-STACK-MIB. 91 2. The Internet-Standard Management Framework 93 For a detailed overview of the documents that describe the current 94 Internet-Standard Management Framework, please refer to section 7 of 95 RFC 3410 [RFC3410]. 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in RFC 100 2119 [RFC2119]. 102 3. Mapping between EFM-CU-MIB and IEEE8023-EFM-CU-MIB 104 The initial version of IEEE8023-EFM-CU-MIB, defined in IEEE Std 105 802.3.1-2011, has MODULE-IDENTITY of ieee8023efmCuMIB with an object 106 identifier allocated under the { org ieee standards-association- 107 numbers-series-standards lan-man-stds ieee802dot3 ieee802dot3dot1mibs 108 } sub-tree. 110 The EFM-CU-MIB has MODULE-IDENTITY of efmCuMIB with an object 111 identifier allocated under the mib-2 sub-tree. 113 The names of the objects in the first version of the IEEE8023-EFM-CU- 114 MIB are identical to those in the EFM-CU-MIB. However, since both 115 MIB modules have different OID values, they can coexist, allowing the 116 management of the newer IEEE MIB-based devices, alongside the legacy 117 IETF MIB-based devices. 119 4. Updating the MIB Modules 121 With the transfer of the responsibility for maintenance and further 122 development of the EFM-CU-MIB module to the IEEE 802.3 working group, 123 the EFM-CU-MIB defined in RFC 5066 becomes the last version of that 124 MIB module. 126 All further development of the EFM Copper Interfaces MIB will be done 127 by the IEEE 802.3 working group in the IEEE8023-EFM-CU-MIB module. 128 Requests and comments pertaining to EFM Copper Interfaces MIB SHOULD 129 be sent to the IEEE 803.3 working group. Currently, the mailing list 130 of the IEEE 802.3.1 task force, chartered with MIB development, is 131 [stds-802-3-mib@listserv.ieee.org]. 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 203 in RFCs to Indicate Requirement 204 Levels", BCP 14, RFC 2119, 205 March 1997. 207 [RFC3414] Blumenthal, U. and B. Wijnen, 208 "User-based Security Model (USM) 209 for version 3 of the Simple 210 Network Management Protocol 211 (SNMPv3)", STD 62, RFC 3414, 212 December 2002. 214 [RFC3826] Blumenthal, U., Maino, F., and K. 215 McCloghrie, "The Advanced 216 Encryption Standard (AES) Cipher 217 Algorithm in the SNMP User-based 218 Security Model", RFC 3826, 219 June 2004. 221 [RFC5066] Beili, E., "Ethernet in the First 222 Mile Copper (EFMCu) Interfaces 223 MIB", RFC 5066, November 2007. 225 8.2. Informative References 227 [802.3] IEEE, "802.3 Ethernet Working 228 Group", 229 . 231 [802.3.1] IEEE, "IEEE Standard for 232 Management Information Base (MIB) 233 Definitions for Ethernet", IEEE 234 Std 802.3.1-2011, July 2011. 236 [HUBMIB] IETF, "Ethernet Interfaces and 237 Hub MIB (hubmib) Charter", . 241 [OPSAWG] IETF, "Operations and Management 242 Area Working Group (opsawg) 243 Charter", . 247 [RFC3410] Case, J., Mundy, R., Partain, D., 248 and B. Stewart, "Introduction and 249 Applicability Statements for 250 Internet-Standard Management 251 Framework", RFC 3410, 252 December 2002. 254 [RFC5591] Harrington, D. and W. Hardaker, 255 "Transport Security Model for the 256 Simple Network Management 257 Protocol (SNMP)", RFC 5591, 258 June 2009. 260 [RFC5592] Harrington, D., Salowey, J., and 261 W. Hardaker, "Secure Shell 262 Transport Model for the Simple 263 Network Management Protocol 264 (SNMP)", RFC 5592, June 2009. 266 [RFC6353] Hardaker, W., "Transport Layer 267 Security (TLS) Transport Model 268 for the Simple Network Management 269 Protocol (SNMP)", RFC 6353, 270 July 2011. 272 [stds-802-3-mib@listserv.ieee.org] IEEE, "802.3 MIB Email 273 Reflector", . 277 Author's Address 279 Edward Beili 280 Actelis Networks 281 Bazel 25 282 Petach-Tikva 283 Israel 285 Phone: +972-73-237-6852 286 EMail: edward.beili@actelis.com