idnits 2.17.1 draft-schoenw-opsawg-nm-dhc-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 -- The document date (June 05, 2013) is 3968 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Downref: Normative reference to an Experimental RFC: RFC 3430 Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Schoenwaelder 3 Internet-Draft Jacobs University Bremen 4 Intended status: Standards Track T. Tsou 5 Expires: December 07, 2013 C. Zhou 6 T. Taylor 7 Huawei Technologies 8 June 05, 2013 10 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for 11 Network Management Protocols 12 draft-schoenw-opsawg-nm-dhc-04 14 Abstract 16 This document defines new Dynamic Host Configuration Protocol (DHCPv4 17 and DHCPv6) options providing lists of IP addresses that can be used 18 to locate network management services, specifically for the 19 collection of logs and of Simple Network Management Protocol (SNMP) 20 notifications. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 07, 2013. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. DHC Options for SYSLOG . . . . . . . . . . . . . . . . . . . 3 58 2.1. SYSLOG Collector Address Option for DHCPv4 . . . . . . . 3 59 2.2. SYSLOG Collector Address Option for DHCPv6 . . . . . . . 4 60 3. DHC Options for SNMP . . . . . . . . . . . . . . . . . . . . 5 61 3.1. SNMP Notification Receiver Address Option for DHCPv4 . . 5 62 3.2. SNMP Notification Receiver Address Option for DHCPv6 . . 6 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 7.2. Informational References . . . . . . . . . . . . . . . . 9 69 Appendix A. Relationship to the SNMP Configuration MIB Modules . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 New networks such as 3GPP Long Term Evolution (LTE) are being 75 deployed today with tens of thousands of network nodes. All of these 76 nodes have to be configured and monitored for the network to operate 77 correctly. Any steps to automate this process will be helpful to 78 reduce the cost of deployment. 80 The Dynamic Host Configuration Protocol (DHCPv4 [RFC2131] and DHCPv6 81 [RFC3315]) is a relevant tool for this purpose. It provides a number 82 of existing options to allow a node to acquire its configuration file 83 and to locate key servers in the network. However, the existing 84 options have been defined more with end hosts than with network nodes 85 in mind. Network nodes require active management, and therefore need 86 to acquire the addresses of their management servers. 88 This document is specifically focussed on the requirement for event 89 reporting. To that end, it defines new DHCP options capable of 90 listing: 92 o one or more addresses of SYSLOG [RFC5424] collectors; 94 o one or more addresses of SNMP [RFC3410] entities hosting 95 Notification Receiver applications. 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 2. DHC Options for SYSLOG 103 The SYSLOG protocol [RFC5424] supports several transport mappings. 104 According to RFC 5424, implementations MUST support the TLS/TCP-based 105 transport defined in [RFC5425] and they SHOULD also support the UDP- 106 based transport defined in [RFC5426] for compatibility with 107 traditional SYSLOG. An optional transport of SYSLOG messages over 108 DTLS/DCCP and DTLS/UDP is defined in [RFC6012]. 110 The DHC options described below provide a list of IPv4 or IPv6 111 addresses of SYSLOG collectors in order of preference. The client 112 SHOULD use the addresses sequentially but may be configured to try 113 secure and/or congestion aware transports before falling back to 114 transports that are not congestion aware or insecure. As such, the 115 client may prefer to select an address providing a secure congestion 116 aware transport even if it is listed with lower preference. 118 2.1. SYSLOG Collector Address Option for DHCPv4 120 This section describes the SYSLOG IPv4 Address Option for DHCPv4. 121 The SYSLOG IPv4 Address Option begins with an option code followed by 122 a length octet. The value of the length octet does not include 123 itself or the option code. The option layout is depicted below: 125 Code Len IPv4 Address 1 IPv4 Address 2 126 +-----+-----+-----+-----+-----+-----+-----+-----+-- 127 | TBD1| n | a1 | a2 | a3 | a4 | a1 | a2 | ... 128 +-----+-----+-----+-----+-----+-----+-----+-----+-- 130 The code for the SYSLOG DHCPv4 option is [IANA: TBD1]. The minimum 131 length of the option is 4 octets, and the length MUST always be a 132 multiple of 4. 134 The option MUST NOT be specified by the DHCPv4 client, as it is 135 intended only to be returned from the DHCPv4 server. If the DHCPv4 136 client wants to receive this information from the server, it needs to 137 include the number [IANA: TBD1] in the "DHCP Parameter Request List" 138 option (55). 140 Server addresses SHOULD be listed in order of preference, and the 141 client SHOULD use the addresses sequentially but may be configured to 142 use addresses in a different order according to some local policy 143 (e.g., the client prefers secure and/or congestion aware transports 144 as described above). 146 Historical note: DHCPv4 option 7 was originally defined 147 (Section 3.9 of [RFC2132]) to provide the addresses of one or more 148 log servers. However, the logging technology concerned was 149 specified to be "MIT-LCS UDP log servers". It seems preferable to 150 define a new option for SYSLOG collectors. 152 2.2. SYSLOG Collector Address Option for DHCPv6 154 This section describes the SYSLOG IPv6 Address Option for DHCPv6. 155 The SYSLOG IPv6 Address Option begins with an option-code followed by 156 the option-len. The value of the option-len does not include itself 157 or the option-code. The option layout is depicted below: 159 1 2 3 160 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | option-code | option-len | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | | 165 | | 166 IPv6 address of SYSLOG collector | 167 | | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 : ... : 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 The option-code of the SYSLOG DHCPv6 option OPTION_SYSLOG_COLLECTOR 173 is [IANA: TBD2]. The minimum option-len is 16 octets, and the length 174 MUST always be a multiple of 16. 176 The option MUST NOT appear in other than the following messages: 177 Solicit, Advertise, Request, Renew, Rebind, Information-Request and 178 Reply. The option number for these options MAY appear in the Option 179 Request Option (6) in the following messages: Solicit, Request, 180 Renew, Rebind, Information-Request and Reconfigure. 182 The addresses SHOULD be listed in order of preference, and the client 183 SHOULD use the addresses sequentially but may be configured to use 184 addresses in a different order according to some local policy (e.g., 185 the client prefers secure and/or congestion aware transports as 186 described above). 188 3. DHC Options for SNMP 190 The SNMP protocol [RFC3410] supports several transport mappings. The 191 preferred IP-based transport is SNMP over UDP [RFC3417]. An 192 experimental transport of SNMP over TCP is defined in [RFC3430]. An 193 optional standards-track transport of SNMP over SSH is defined in 194 [RFC5592] while optional standards-track transports over TLS and DTLS 195 are defined in [RFC6353] 197 The DHC options described below provide a list of IPv4 or IPv6 198 addresses of SNMP entities hosting Notification Receiver applications 199 in order of preference. The client SHOULD use the addresses 200 sequentially but may be configured to try secure and/or congestion 201 aware transports before falling back to transports that are not 202 congestion aware or insecure. As such, the client may prefer to 203 select an address providing a secure congestion aware transport even 204 if it is listed with lower preference. 206 3.1. SNMP Notification Receiver Address Option for DHCPv4 208 This section describes the SNMP IPv4 Address Option for DHCPv4. The 209 SNMP IPv4 Address Option begins with an option code followed by a 210 length octet. The value of the length octet does not include itself 211 or the option code. The option layout is depicted below: 213 Code Len IPv4 Address 1 IPv4 Address 2 214 +-----+-----+-----+-----+-----+-----+-----+-----+-- 215 | TBD3| n | a1 | a2 | a3 | a4 | a1 | a2 | ... 216 +-----+-----+-----+-----+-----+-----+-----+-----+-- 218 The code for the SNMP notification receiver DHCPv4 option is [IANA: 219 TBD3]. The minimum length of the option is 4 octets, and the length 220 MUST always be a multiple of 4. 222 The option MUST NOT be specified by the DHCPv4 client, as it is 223 intended only to be returned from the DHCPv4 server. If the DHCPv4 224 client wants to receive this information from the server, it needs to 225 include the number [IANA: TBD3] in the "DHCP Parameter Request List" 226 option (55). 228 The addresses SHOULD be listed in order of preference, and the client 229 SHOULD use the addresses sequentially but may be configured to use 230 addresses in a different order according to some local policy (e.g., 231 the client prefers secure and/or congestion aware transports as 232 described above). 234 3.2. SNMP Notification Receiver Address Option for DHCPv6 236 This section describes the SNMP IPv6 Address Option for DHCPv6. The 237 SNMP IPv6 Address Option begins with an option-code followed by the 238 option-len. The value of the option-len does not include itself or 239 the option-code. The option layout is depicted below: 241 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | option-code | option-len | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | | 246 | | 247 | IPv6 address of SNMP notification receiver | 248 | | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 : ... : 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 The option-code of the SNMP notification receiver DHCPv6 option 254 OPTION_SNMP_NOT_RECEIVER is [IANA: TBD4]. The minimum option-len is 255 16 octets, and the length MUST always be a multiple of 16. 257 The option MUST NOT appear in other than the following messages: 258 Solicit, Advertise, Request, Renew, Rebind, Information-Request and 259 Reply. The option number for these options MAY appear in the Option 260 Request Option (6) in the following messages: Solicit, Request, 261 Renew, Rebind, Information-Request and Reconfigure. 263 Server addresses SHOULD be listed in order of preference, and the 264 client SHOULD use the addresses sequentially but may be configured to 265 use addresses in a different order according to some local policy 266 (e.g., the client prefers secure and/or congestion aware transports 267 as described above). 269 4. Security Considerations 271 The security considerations in [RFC2131] and [RFC3315]) apply. If an 272 adversary manages to modify the response from a DHCPv4 or DHCPv6 273 server or insert its own response, a node could be led to contact a 274 rogue network management server. 276 It is recommended to use the DHCPv4 authentication option described 277 in [RFC3118] where available. This will also protect against denial- 278 of-service attacks to DHCP servers. [RFC3118] provides mechanisms 279 for both entity authentication and message authentication. 281 In IPv6 networks using DHCPv6, it is recommended that clients use 282 authentication of DHCPv6 messages as described in Section 21 of 283 [RFC3315]. 285 In deployments where DHCPv4 or DHCPv6 authentication is not 286 available, lower-layer security services may be sufficient to protect 287 DHCPv4 and DHCPv6 messages. 289 5. IANA Considerations 291 IANA is requested to assign [IANA: TBD1] and [IANA: TBD3] as option 292 codes in the "DHCP Option Codes" registry. The desired entries are 293 shown in Table 1. 295 +------+------------------+----------+------------------+-----------+ 296 | Tag | Name | Data | Meaning | Reference | 297 | | | Length | | | 298 +------+------------------+----------+------------------+-----------+ 299 | TBD1 | SYSLOG Collector | N | N/4 SYSLOG | RFCxxxx | 300 | | Address | | collector | | 301 | | | | addresses | | 302 | TBD3 | SNMP | N | N/4 SNMP | RFCxxxx | 303 | | Notification | | Notification | | 304 | | Receiver Address | | Receiver | | 305 | | | | addresses | | 306 +------+------------------+----------+------------------+-----------+ 308 Table 1: DHCPv4 Option Codes For Network Management Servers 310 IANA is requested to assign [IANA: TBD2] as an option code from the 311 "DHCPv6 Options Codes" registry for OPTION_SYSLOG_COLLECTOR, with 312 reference RFCxxxx. 314 IANA is requested to assign [IANA: TBD4] as an option code from the 315 "DHCPv6 Options Codes" registry for OPTION_SNMP_NOT_RECEIVER, with 316 reference RFCxxxx. 318 RFC Editor's Note: RFCxxxx denotes the present document. 320 6. Acknowledgements 322 The authors like to thank Ralf Droms, Ted Lemon and Bernie Volz for 323 their helpful comments. 325 7. References 327 7.1. Normative References 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, March 1997. 332 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 333 2131, March 1997. 335 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 336 Extensions", RFC 2132, March 1997. 338 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 339 Messages", RFC 3118, June 2001. 341 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 342 and M. Carney, "Dynamic Host Configuration Protocol for 343 IPv6 (DHCPv6)", RFC 3315, July 2003. 345 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network 346 Management Protocol (SNMP) Applications", STD 62, RFC 347 3413, December 2002. 349 [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network 350 Management Protocol (SNMP)", STD 62, RFC 3417, December 351 2002. 353 [RFC3430] Schoenwaelder, J., "Simple Network Management Protocol 354 Over Transmission Control Protocol Transport Mapping", RFC 355 3430, December 2002. 357 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 359 [RFC5425] Miao, F., Ma, Y., and J. Salowey, "Transport Layer 360 Security (TLS) Transport Mapping for Syslog", RFC 5425, 361 March 2009. 363 [RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP", 364 RFC 5426, March 2009. 366 [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure 367 Shell Transport Model for the Simple Network Management 368 Protocol (SNMP)", RFC 5592, June 2009. 370 [RFC6012] Salowey, J., Petch, T., Gerhards, R., and H. Feng, 371 "Datagram Transport Layer Security (DTLS) Transport 372 Mapping for Syslog", RFC 6012, October 2010. 374 [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport 375 Model for the Simple Network Management Protocol (SNMP)", 376 RFC 6353, July 2011. 378 7.2. Informational References 380 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 381 "Introduction and Applicability Statements for Internet- 382 Standard Management Framework", RFC 3410, December 2002. 384 Appendix A. Relationship to the SNMP Configuration MIB Modules 386 The SNMP notification receiver address DHCPv4 and DHCPv6 options 387 defined in Section 3.1 and Section 3.2 provide the basic information 388 to setup a target in the SNMP-TARGET-MIB and the SNMP-NOTIFICATION- 389 MIB [RFC3413]. After selecting the transport (e.g., by probing the 390 availability of possible SNMP transport endpoints according to some 391 local policy, a volatile entry in the snmpTargetTable can be created 392 as follows (assuming xyz is some suitable unique handle for the 393 received DHCP option): 395 snmpTargetAddrName = "dhcp-xyz" (INDEX) 396 snmpTargetAddrTDomain = snmpUDPDomain 397 snmpTargetAddrTAddress = "a.b.c.d" 398 snmpTargetAddrTimeout = 1500 (DEFVAL) 399 snmpTargetAddrRetryCount = 3 (DEFVAL) 400 snmpTargetAddrTagList = "dhcp-xyz-tag" 401 snmpTargetAddrParams = "dhcp-xyz-param" 402 snmpTargetAddrStorageType = volatile(2) 403 snmpTargetAddrRowStatus = active(1) 405 A matching volatile entry in the snmpNotifyTable can also be easily 406 created: 408 snmpNotifyName = "dhcp-xyz" (INDEX) 409 snmpNotifyTag = "dhcp-xyz-tag" 410 snmpNotifyType = trap(1) (DEFVAL) 411 snmpNotifyStorageType = volatile(2) 412 snmpNotifyRowStatus = active(1) 414 In addition, an entry in the snmpTargetParamsTable is needed. Its 415 structure for SNMPv3/USM user "joe" is as follows: 417 snmpTargetParamsName = "dhcp-xyz-param" (INDEX) 418 snmpTargetParamsMPModel = 3 (SNMPv3) 419 snmpTargetParamsSecurityModel = 3 (USM) 420 snmpTargetParamsSecurityName = "joe" 421 snmpTargetParamsSecurityLevel = authNoPriv(2) 422 snmpTargetParamsStorageType = volatile(2) 423 snmpTargetParamsRowStatus = active(1) 425 Creation of a suitable entry in the snmpTargetParamsTable requires 426 local information. Depending on the security model, additional 427 information will be necessary. 429 The creation of a suitable snmpTargetParamsTable entry may either be 430 dynamic (i.e., the entry is created upon receipt of a DHC lease using 431 some local policy information and deleted when the DHC lease expires) 432 or suitable snmpTargetParamsTable entries may be pre-provisioned 433 based on the expected naming of the target entries that are created 434 dynamically. Implementations may also pre-provision 435 snmpTargetAddrTable entries and only dynamically create suitable 436 snmpNotifyTable entries. 438 Authors' Addresses 440 Juergen Schoenwaelder 441 Jacobs University Bremen 442 Campus Ring 1 443 Bremen 28759 444 Germany 446 Email: j.schoenwaelder@jacobs-university.de 448 Tina Tsou 449 Huawei Technologies 450 2330 Central Expressway 451 Santa Clara CA 95050 452 USA 454 Email: Tina.Tsou.Zouting@huawei.com 455 Cathy Zhou 456 Huawei Technologies 457 Bantian, Longgang District 458 Shenzhen 518129 459 P.R. China 461 Email: cathyzhou@huawei.com 463 Tom Taylor 464 Huawei Technologies 465 Ottawa 466 Canada 468 Email: tom.taylor.stds@gmail.com