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