idnits 2.17.1 draft-nalluri-dhc-dhcpv6-lwm2m-bootstrap-options-02.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 11, 2017) is 2629 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) == Unused Reference: 'RFC2119' is defined on line 339, but no explicit reference was found in the text == Unused Reference: 'RFC2131' is defined on line 344, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 362, but no explicit reference was found in the text == Unused Reference: 'RFC7227' is defined on line 368, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC working group S. Nalluri 3 Internet-Draft Ericsson 4 Intended status: Standards Track February 11, 2017 5 Expires: August 15, 2017 7 DHCPv6 Options for LWM2M bootstrap information 8 draft-nalluri-dhc-dhcpv6-lwm2m-bootstrap-options-02 10 Abstract 12 This document defines Dynamic Host Configuration Protocol and Dynamic 13 Host Configuration Protocol version 6 (DHCPv6) Options for LWM2M 14 client bootstrap information, which are used to carry Uniform 15 Resource Locater of LWM2M bootstrap server and certificate that 16 validates the public key presented by server. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 15, 2017. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. LWM2M bootstrap server information through DHC . . . . . . . 3 55 3.1. DHCPv6 option for LWM2M bootstrap server URI . . . . . . 3 56 3.2. DHCPv6 option for LWM2M server certificate . . . . . . . 3 57 3.3. DHCPv4 option for LWM2M bootstrap server URI . . . . . . 4 58 3.4. DHCPv4 option for LWM2M server certificate . . . . . . . 4 59 4. Appearance of Option . . . . . . . . . . . . . . . . . . . . 5 60 4.1. Appearance of options in DHCPv6 control messages . . . . 5 61 4.2. Appearance of options in DHCPv4 control messages . . . . 5 62 5. Configuration Guidelines for the Server . . . . . . . . . . . 6 63 6. DHCPv4/DHCPv6 Client Behavior . . . . . . . . . . . . . . . . 6 64 7. Relay agent Behavior . . . . . . . . . . . . . . . . . . . . 7 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 67 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 11. Normative References . . . . . . . . . . . . . . . . . . . . 8 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 Light weight machine to machine (LWM2M) protocol is used to manage 74 end device life cycle in machine to machine communication scenarios. 75 LWM2M device bootstrap is an optional life cycle phase for devices to 76 get needed information when starting up for first time. Information 77 gathered during bootstrapping might include management server details 78 and security certificates required to establish connectivity with 79 management server. Information required to connect with bootstrap 80 server might be hard coded during device manufacturing phase. 82 Hard coding configuration by device manufacturer forces device 83 operator to use same configuration as hard coded. It is possible 84 that reachability information of bootstrap server that is hard coded 85 may be outdated and boot strap server reachability might fail during 86 first use of device. In such cases connectivity with bootstrap 87 server is possible only through device software upgrade. 89 2. Terminology 91 This document makes use of the following terms: 93 LWM2M: Lightweight Machine to Machine is a protocol from Open Mobile 94 alliance for device management in M2M or Internet of Things 95 scenarios 97 LWM2M bootstrap server: The server that provides LWM2M bootstrap 98 interface which is used to optionally configure a LWM2M Client so 99 that it can successfully register with a LWM2M management Server 101 LWM2M management server: The server that provides registration, 102 device management and service enablement interface to manage a 103 LWM2M client. 105 3. LWM2M bootstrap server information through DHC 107 LWM2M bootstrap server details like URI and security certificate can 108 be collected during dynamic host configuration phase. DHCPv4 and 109 DHCPv6 options can be extended to collect LWM2M bootstrap server 110 information for IPv4 and IPv6 networks respectively. DHCPv4 or 111 DHCPv6 client requests LWM2M bootstrap server URI and LWM2M server 112 certificate using new options proposed in sections below 114 3.1. DHCPv6 option for LWM2M bootstrap server URI 116 DHCPv6 option OPTION_LWM2M_BOOTSTRAP_URI conveys URI through which 117 LWM2M client can reach LWM2M bootstrap server reachable through IPv6 118 network. The format of LWM2M bootstrap server URI option is as shown 119 below: 121 0 1 2 3 122 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 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | option-code | option-len | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | LWM2M-bootstrap-URI | 127 | ... | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 option-code: OPTION_LWM2M_BOOTSTRAP_URI 132 option-len: Length of the 'LWM2M-bootstrap-URI' field in octets 134 LWM2M-bootstrap-URI: This string is URI of LWM2M bootstrap server. 135 The string is not null-terminated. 137 3.2. DHCPv6 option for LWM2M server certificate 139 DHCPv6 option OPTION_LWM2M_SERVER_CERTIFICATE conveys security 140 certificate which can be used by LWM2M client to establish secure 141 connection with LWM2M server reachable through IPv6 network. The 142 format of LWM2M server certificate option is as shown below: 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | option-code | option-len | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | LWM2M-server-certificate | 150 | (variable length data) | 151 | | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 option-code: OPTION_LWM2M_SERVER_CERTIFICATE 156 option-len: Length of the 'LWM2M-server-certificate' field in octets 158 LWM2M-server-certificate: Digital certificate of LWM2M server as 159 defined in Section 3.6 of [RFC7296] 161 3.3. DHCPv4 option for LWM2M bootstrap server URI 163 DHCPv4 option OPTION_LWM2M_BOOTSTRAP_URI conveys URI through which 164 LWM2M client can reach LWM2M bootstrap server reachable through IPv4 165 network. The format of LWM2M bootstrap server URI option is as shown 166 below: 168 0 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | option-code | option-len | LWM2M-bootstrap-URI | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | | 174 | LWM2M-bootstrap-URI | 175 | ... | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 option-code: OPTION_LWM2M_BOOTSTRAP_URI 180 option-len: Length of the 'LWM2M-bootstrap-URI' field in octets 182 LWM2M-bootstrap-URI: This string is URI of LWM2M bootstrap server. 183 The string is not null-terminated. 185 3.4. DHCPv4 option for LWM2M server certificate 187 DHCPv4 option OPTION_LWM2M_SERVER_CERTIFICATE conveys security 188 certificate which can be used by LWM2M client to establish secure 189 connection with LWM2M server reachable through IPv4 network. The 190 format of LWM2M server certificate option is as shown below: 192 0 1 2 3 193 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 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | option-code | option-len | LWM2M-server-certificate | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | | 198 | LWM2M-server-certificate | 199 | (variable length data) | 200 | | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 option-code: OPTION_LWM2M_SERVER_CERTIFICATE 205 option-len: Length of the 'LWM2M-server-certificate' field in octets 207 LWM2M-server-certificate: Digital certificate of LWM2M server as 208 defined in Section 3.6 of [RFC7296] 210 4. Appearance of Option 212 4.1. Appearance of options in DHCPv6 control messages 214 The OPTION_LWM2M_BOOTSTRAP_URI and OPTION_LWM2M_SERVER_CERTIFICATE 215 options MUST NOT appear in messages other than the following: SOLICIT 216 (1), ADVERTISE (2), REQUEST (3),REPLY (4) RENEW (5), REBIND (6), 217 INFORMATION-REQUEST (11). If this option appears in messages other 218 than those specified above, the receiver MUST ignore it. 220 The option number for OPTION_LWM2M_BOOTSTRAP_URI and 221 OPTION_LWM2M_SERVER_CERTIFICATE options MAY appear in the "Option 222 Request" option [RFC3315] in the following messages: SOLICIT (1), 223 REQUEST (3), RENEW (5), REBIND (6), INFORMATION-REQUEST (11) and 224 RECONFIGURE (10). If this option number appears in the "Option 225 Request" option in messages other than those specified above, the 226 receiver SHOULD ignore it. 228 4.2. Appearance of options in DHCPv4 control messages 230 The OPTION_LWM2M_BOOTSTRAP_URI and OPTION_LWM2M_SERVER_CERTIFICATE 231 options MUST NOT appear in messages other than the following: 232 DHCPDISCOVER (1), DHCPOFFER (2), DHCPREQUEST (3), DHCPACK (5) and 233 DHCPINFORM (8). If this option appears in messages other than those 234 specified above, the receiver MUST ignore it. 236 The option number for OPTION_LWM2M_BOOTSTRAP_URI and 237 OPTION_LWM2M_SERVER_CERTIFICATE options MAY appear in the "Parameter 238 Request List" option [RFC2132] in the following messages: 239 DHCPDISCOVER (1), DHCPOFFER (2), DHCPREQUEST (3), DHCPACK (5) and 240 DHCPINFORM (8). If this option number appears in the "Parameter 241 Request List" option in messages other than those specified above, 242 the receiver SHOULD ignore it. 244 Maximum possible value of DHCPv4 "option-len" is 255. LWM2M-server- 245 certificate MAY be of length more than 255. To accommodate larger 246 certificate, DHCP server SHOULD follow encoding as mentioned in 247 [RFC3396]. 249 5. Configuration Guidelines for the Server 251 DHCPv4 or DHCPv6 server that supports OPTION_LWM2M_BOOTSTRAP_URI and 252 OPTION_LWM2M_SERVER_CERTIFICATE SHOULD be configured with one and 253 only one LWM2M bootstrap server URI, and one and only one certificate 254 that validates bootstrap server's public key. 256 In the absence of URI configuration, DHCP server SHOULD ignore option 257 OPTION_LWM2M_BOOTSTRAP_URI, and SHOULD continue processing of DHCP 258 control message 260 In the absence of certificate configuration, DHCP server SHOULD 261 ignore option OPTION_LWM2M_SERVER_CERTIFICATE, and SHOULD continue 262 processing of DHCP control message 264 6. DHCPv4/DHCPv6 Client Behavior 266 DHCP or DHCPv6 client MAY decide need for inclusion of 267 OPTION_LWM2M_BOOTSTRAP_URI and OPTION_LWM2M_SERVER_CERTIFICATE 268 options in DHCPv4 or DHCPv6 control messages if device is capable of 269 supporting LWM2M client functionality irrespective of state of LWM2M 270 client. It is possible that LWM2M client MAY not be active before 271 DHCPv4 or DHCPv6 message exchanges happens. In such scenario, DHCPv4 272 or DHCPv6 client MAY collect LWM2M bootstrap server URI and LWM2M 273 server certificate and keep ready for LWM2M client initialization 275 DHCPv4 or DHCPv6 client MAY prefer collecting LWM2M bootstrap server 276 URI and LWM2M server certificate by including 277 OPTION_LWM2M_BOOTSTRAP_URI and OPTION_LWM2M_SERVER_CERTIFICATE 278 options in DHCPINFORM or INFORMATION-REQUEST message which MAY be 279 send during LWM2M client initialization 281 LWM2M client devices running with IPv6 stack MAY use stateless auto 282 address configuration to get IPv6 address. Such clients MAY use 283 DHCPv6 INFORMATION-REQUEST to get LWM2M bootstrap URI and LWM2M 284 server server certificate through options OPTION_LWM2M_BOOTSTRAP_URI 285 and OPTION_LWM2M_SERVER_CERTIFICATE 287 7. Relay agent Behavior 289 This draft does not impose any new requirements on DHCPv4 or DHCPv6 290 relay agent functionality 292 8. Security Considerations 294 OPTION_LWM2M_BOOTSTRAP_URI and OPTION_LWM2M_SERVER_CERTIFICAT options 295 could be used by an intruder to advertise the URI of a malicious 296 LWM2M bootstrap server and certificate and can alter the LWM2M 297 management server details provided to LWM2M client. The consequences 298 of such an attack can be critical, because any data that is reported 299 by LWM2M client MAY reach unwanted LWM2M management server. As an 300 example, an attacker could collect data from secure locations by 301 deploying malicious servers. 303 To prevent these attacks, it is strongly advisable to secure the use 304 of this option by either: 306 o Using authenticated DHCP as described in [RFC3315], Section 21. 308 o Using options OPTION_LWM2M_BOOTSTRAP_URI and 309 OPTION_LWM2M_SERVER_CERTIFICATE only with trusted DHCP server 311 The security considerations documented in [RFC3315] are to be 312 considered. 314 9. Acknowledgement 316 Particular thanks to A. Keraenen, J. Jimenez, J. Melen and S. 317 Krishnan for the concept, inputs and review. 319 10. IANA Considerations 321 IANA is requested to assign new DHCPv6 option codes in the registry 322 maintained in http://www.iana.org/assignments/dhcpv6-parameters: 324 | Option Name | Value | 325 |---------------------------------+----------| 326 | OPTION_LWM2M_BOOTSTRAP_URI | TBA | 327 | OPTION_LWM2M_SERVER_CERTIFICATE | TBA | 329 IANA is requested to assign new DHCPv4 option codes in the registry 330 maintained in http://www.iana.org/assignments/bootp-dhcp-parameters: 332 | Option Name | Value | 333 |--------------------------------+---------| 334 | OPTION_LWM2M_BOOTSTRAP_URI | TBA | 335 | OPTION_LWM2M_SERVER_CERTIFICATE| TBA | 337 11. Normative References 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", BCP 14, RFC 2119, 341 DOI 10.17487/RFC2119, March 1997, 342 . 344 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 345 RFC 2131, DOI 10.17487/RFC2131, March 1997, 346 . 348 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 349 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 350 . 352 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 353 C., and M. Carney, "Dynamic Host Configuration Protocol 354 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 355 2003, . 357 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 358 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 359 DOI 10.17487/RFC3396, November 2002, 360 . 362 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 363 Housley, R., and W. Polk, "Internet X.509 Public Key 364 Infrastructure Certificate and Certificate Revocation List 365 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 366 . 368 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 369 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 370 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 371 . 373 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 374 Kivinen, "Internet Key Exchange Protocol Version 2 375 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 376 2014, . 378 Author's Address 380 Srinivas Rao Nalluri 381 Ericsson 382 Bangalore 383 India 385 Email: srinivasa.rao.nalluri@ericsson.com