idnits 2.17.1 draft-nalluri-dhc-dhcpv6-lwm2m-bootstrap-options-01.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 (January 09, 2017) is 2661 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 351, but no explicit reference was found in the text == Unused Reference: 'RFC2131' is defined on line 356, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 369, but no explicit reference was found in the text == Unused Reference: 'RFC7227' is defined on line 375, 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 January 09, 2017 5 Expires: July 13, 2017 7 DHCPv6 Options for LWM2M bootstrap information 8 draft-nalluri-dhc-dhcpv6-lwm2m-bootstrap-options-01 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 July 13, 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. DHCP option for LWM2M bootstrap server URI . . . . . . . 4 58 3.4. DHCP 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 DHCP control messages . . . . . 5 62 5. Configuration Guidelines for the Server . . . . . . . . . . . 6 63 6. DHCP/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. DHCP and 109 DHCPv6 options can be extended to collect LWM2M bootstrap server 110 information for IPv4 and IPv6 networks respectively. DHCP or DHCPv6 111 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. DHCP option for LWM2M bootstrap server URI 163 DHCP 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. DHCP option for LWM2M server certificate 187 DHCP 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 | Sequence Number | 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 Sequence Number: Sequence number of OPTION_LWM2M_SERVER_CERTIFICATE 208 in the scope of DHCP packet. Sequence number starts with zero and 209 incremented by 1 for every new OPTION_LWM2M_SERVER_CERTIFICATE 210 option added to DHCP packet 212 LWM2M-server-certificate: Digital certificate of LWM2M server as 213 defined in Section 3.6 of [RFC7296] 215 4. Appearance of Option 217 4.1. Appearance of options in DHCPv6 control messages 219 The OPTION_LWM2M_BOOTSTRAP_URI and OPTION_LWM2M_SERVER_CERTIFICATE 220 options MUST NOT appear in messages other than the following: SOLICIT 221 (1), ADVERTISE (2), REQUEST (3),REPLY (4) RENEW (5), REBIND (6), 222 INFORMATION-REQUEST (11). If this option appears in messages other 223 than those specified above, the receiver MUST ignore it. 225 The option number for OPTION_LWM2M_BOOTSTRAP_URI and 226 OPTION_LWM2M_SERVER_CERTIFICATE options MAY appear in the "Option 227 Request" option [RFC3315] in the following messages: SOLICIT (1), 228 REQUEST (3), RENEW (5), REBIND (6), INFORMATION-REQUEST (11) and 229 RECONFIGURE (10). If this option number appears in the "Option 230 Request" option in messages other than those specified above, the 231 receiver SHOULD ignore it. 233 4.2. Appearance of options in DHCP control messages 235 The OPTION_LWM2M_BOOTSTRAP_URI and OPTION_LWM2M_SERVER_CERTIFICATE 236 options MUST NOT appear in messages other than the following: 237 DHCPDISCOVER (1), DHCPOFFER (2), DHCPREQUEST (3), DHCPACK (5) and 238 DHCPINFORM (8). If this option appears in messages other than those 239 specified above, the receiver MUST ignore it. 241 The option number for OPTION_LWM2M_BOOTSTRAP_URI and 242 OPTION_LWM2M_SERVER_CERTIFICATE options MAY appear in the "Parameter 243 Request List" option [RFC2132] in the following messages: 244 DHCPDISCOVER (1), DHCPOFFER (2), DHCPREQUEST (3), DHCPACK (5) and 245 DHCPINFORM (8). If this option number appears in the "Parameter 246 Request List" option in messages other than those specified above, 247 the receiver SHOULD ignore it. 249 Maximum possible value of DHCP "option-len" is 255. LWM2M-server- 250 certificate MAY be of length more than 255. To accommodate larger 251 certificate, it SHOULD be possible to include multiple 252 OPTION_LWM2M_SERVER_CERTIFICATE options in same DHCP message. DHCP 253 server SHOULD be capable of including multiple 254 OPTION_LWM2M_SERVER_CERTIFICATE options in same message. 255 Certificates larger than 255 byte SHOULD be fragmented and adjusted 256 in minimum possible number of OPTION_LWM2M_SERVER_CERTIFICATE 257 options. Each OPTION_LWM2M_SERVER_CERTIFICATE option is tagged with 258 a sequence number which can be used by DHCP client to reassemble 259 received certificate 261 5. Configuration Guidelines for the Server 263 DHCP or DHCPv6 server that supports OPTION_LWM2M_BOOTSTRAP_URI and 264 OPTION_LWM2M_SERVER_CERTIFICATE SHOULD be configured with one and 265 only one LWM2M bootstrap server URI, and one and only one certificate 266 that validates bootstrap server's public key. 268 In the absence of URI configuration, DHCP server SHOULD ignore option 269 OPTION_LWM2M_BOOTSTRAP_URI, and SHOULD continue processing of DHCP 270 control message 272 In the absence of certificate configuration, DHCP server SHOULD 273 ignore option OPTION_LWM2M_SERVER_CERTIFICATE, and SHOULD continue 274 processing of DHCP control message 276 6. DHCP/DHCPv6 Client Behavior 278 DHCP or DHCPv6 client MAY decide need for inclusion of 279 OPTION_LWM2M_BOOTSTRAP_URI and OPTION_LWM2M_SERVER_CERTIFICATE 280 options in DHCP or DHCPv6 control messages if device is capable of 281 supporting LWM2M client functionality irrespective of state of LWM2M 282 client. It is possible that LWM2M client MAY not be active before 283 DHCP or DHCPv6 message exchanges happens. In such scenario, DHCP or 284 DHCPv6 client MAY collect LWM2M bootstrap server URI and LWM2M server 285 certificate and keep ready for LWM2M client initialization 287 DHCP or DHCPv6 client MAY prefer collecting LWM2M bootstrap server 288 URI and LWM2M server certificate by including 289 OPTION_LWM2M_BOOTSTRAP_URI and OPTION_LWM2M_SERVER_CERTIFICATE 290 options in DHCPINFORM or INFORMATION-REQUEST message which MAY be 291 send during LWM2M client initialization 293 LWM2M client devices running with IPv6 stack MAY use stateless auto 294 address configuration to get IPv6 address. Such clients MAY use 295 DHCPv6 INFORMATION-REQUEST to get LWM2M bootstrap URI and LWM2M 296 server server certificate through options OPTION_LWM2M_BOOTSTRAP_URI 297 and OPTION_LWM2M_SERVER_CERTIFICATE 299 7. Relay agent Behavior 301 This draft does not impose any new requirements on DHCP or DHCPv6 302 relay agent functionality 304 8. Security Considerations 306 OPTION_LWM2M_BOOTSTRAP_URI and OPTION_LWM2M_SERVER_CERTIFICAT options 307 could be used by an intruder to advertise the URI of a malicious 308 LWM2M bootstrap server and certificate and can alter the LWM2M 309 management server details provided to LWM2M client. The consequences 310 of such an attack can be critical, because any data that is reported 311 by LWM2M client MAY reach unwanted LWM2M management server. As an 312 example, an attacker could collect data from secure locations by 313 deploying malicious servers. 315 To prevent these attacks, it is strongly advisable to secure the use 316 of this option by either: 318 o Using authenticated DHCP as described in [RFC3315], Section 21. 320 o Using options OPTION_LWM2M_BOOTSTRAP_URI and 321 OPTION_LWM2M_SERVER_CERTIFICATE only with trusted DHCP server 323 The security considerations documented in [RFC3315] are to be 324 considered. 326 9. Acknowledgement 328 Particular thanks to A. Keraenen, J. Jimenez, J. Melen and S. 329 Krishnan for the concept, inputs and review. 331 10. IANA Considerations 333 IANA is requested to assign new DHCPv6 option codes in the registry 334 maintained in http://www.iana.org/assignments/dhcpv6-parameters: 336 | Option Name | Value | 337 |---------------------------------+----------| 338 | OPTION_LWM2M_BOOTSTRAP_URI | TBA | 339 | OPTION_LWM2M_SERVER_CERTIFICATE | TBA | 341 IANA is requested to assign new DHCP option codes in the registry 342 maintained in http://www.iana.org/assignments/bootp-dhcp-parameters: 344 | Option Name | Value | 345 |--------------------------------+---------| 346 | OPTION_LWM2M_BOOTSTRAP_URI | TBA | 347 | OPTION_LWM2M_SERVER_CERTIFICATE| TBA | 349 11. Normative References 351 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 352 Requirement Levels", BCP 14, RFC 2119, 353 DOI 10.17487/RFC2119, March 1997, 354 . 356 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 357 RFC 2131, DOI 10.17487/RFC2131, March 1997, 358 . 360 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 361 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 362 . 364 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 365 C., and M. Carney, "Dynamic Host Configuration Protocol 366 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 367 2003, . 369 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 370 Housley, R., and W. Polk, "Internet X.509 Public Key 371 Infrastructure Certificate and Certificate Revocation List 372 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 373 . 375 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 376 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 377 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 378 . 380 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 381 Kivinen, "Internet Key Exchange Protocol Version 2 382 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 383 2014, . 385 Author's Address 387 Srinivas Rao Nalluri 388 Ericsson 389 Bangalore 390 India 392 Email: srinivasa.rao.nalluri@ericsson.com