idnits 2.17.1 draft-nalluri-dhc-dhcpv6-mqtt-config-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 (October 20, 2017) is 2381 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 360, but no explicit reference was found in the text == Unused Reference: 'RFC2131' is defined on line 365, but no explicit reference was found in the text == Unused Reference: 'RFC4306' is defined on line 383, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 387, but no explicit reference was found in the text == Unused Reference: 'RFC7227' is defined on line 393, but no explicit reference was found in the text == Unused Reference: 'RFC7296' is defined on line 398, but no explicit reference was found in the text == Unused Reference: 'MQTT-SPEC' is defined on line 405, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) Summary: 2 errors (**), 0 flaws (~~), 9 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 October 20, 2017 5 Expires: April 23, 2018 7 DHCPv6 options for MQTT client configuration 8 draft-nalluri-dhc-dhcpv6-mqtt-config-options-00 10 Abstract 12 This document defines Dynamic Host Configuration Protocol and Dynamic 13 Host Configuration Protocol version 6 (DHCPv6) Options for MQTT 14 client configuration information, which are used to carry Uniform 15 Resource Locater of MQTT broker and MQTT topic prefix that should be 16 used as prefix for any topic published by MQTT client. 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 April 23, 2018. 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. MQTT client configuration through DHCP . . . . . . . . . . . 3 54 2.1. DHCPv6 option for MQTT broker URI . . . . . . . . . . . . 3 55 2.2. DHCPv6 option for MQTT topic prefix . . . . . . . . . . . 4 56 2.3. DHCPv4 option for MQTT broker URI . . . . . . . . . . . . 4 57 2.4. DHCPv4 option for MQTT topic prefix . . . . . . . . . . . 5 58 3. Appearance of Option . . . . . . . . . . . . . . . . . . . . 5 59 3.1. Appearance of options in DHCPv6 control messages . . . . 5 60 3.2. Appearance of options in DHCPv4 control messages . . . . 6 61 4. Configuration Guidelines for the Server . . . . . . . . . . . 6 62 5. DHCPv4/DHCPv6 Client Behavior . . . . . . . . . . . . . . . . 6 63 6. Relay agent Behavior . . . . . . . . . . . . . . . . . . . . 7 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 10.2. Informative References . . . . . . . . . . . . . . . . . 9 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 The Message Queue Telemetry Transport (MQTT) protocol is a light- 75 weight IoT protocol, based on the publish/subscribe communication 76 model. MQTT clients, that can be publishers or subscribers, 77 communicate with each other via a broker. The broker hosts a set of 78 "topics" and clients can publish and subscribe to these topics. All 79 data published to a topic is delivered to all clients who are 80 subscribed to the same topic. In communications network using MQTT 81 clients commonly use a preconfigured address information, such as 82 Uniform Resource Identifier (URI), to register with a MQTT broker. 83 The URI might be configured by a user or an operator through a local 84 device interface. Alternatively, the URI might be provided as a 85 hardcoded value by manufacturer of the MQTT client device. 87 Hard coding configuration by device manufacturer forces device 88 operator to use same configuration as hard coded. It is possible 89 that reachability information of MQTT broker that is hard coded may 90 be outdated and MQTT broker reachability might fail during first use 91 of device. In such cases connectivity with MQTT broker is possible 92 only through device software upgrade. 94 Subscribers who are interested in specific data of a specific topic 95 registers the topic with the MQTT broker. MQTT clients acting as 96 publishers register/create topics, and MQTT clients acting as 97 subscribers register for a specific existing topic. In general 98 terms, a topic can represented by a hierarchical string defined by 99 MQTT service or device operator. Before operation every MQTT client 100 that wishes to publish data on a specific topic should be aware of 101 the corresponding hierarchical strings that are supposed to be used 102 for the topics for the MQTT client to publish topic specific data. 104 However, uniqueness of topics in the MQTT network is not guaranteed 105 as there is no standard guideline that guarantees uniqueness. In the 106 same MQTT network, using the same MQTT broker, different MQTT clients 107 can accidentally use the same topic to publish data, which results in 108 invalid operation. In such scenarios, subscribers might receive 109 wrong data and publishers may change data they were not supposed to 110 change. Network or device operators therefore have to take care of 111 the topic name space across the MQTT network so that topic identities 112 are unique across the MQTT network. This manual operation is error- 113 prone and costly. 115 This draft propose DHCP and DHCPv6 options to dynamically configure 116 MQTT client with MQTT broker URI and one or more topic prefixs to 117 guarantee uniqueness of topic used across MQTT network. 119 2. MQTT client configuration through DHCP 121 MQTT broker URI and topic prefix can be collected during dynamic host 122 configuration phase. DHCPv4 and DHCPv6 options can be extended to 123 collect MQTT broker URI and MQTT topic prefix for IPv4 and IPv6 124 networks respectively. DHCPv4 or DHCPv6 client requests MQTT broker 125 URI and MQTT topic prefix using new options proposed in sections 126 below 128 2.1. DHCPv6 option for MQTT broker URI 130 DHCPv6 option OPTION_MQTT_BROKER_URI conveys URI through which MQTT 131 client can reach MQTT broker in IPv6 network. The format of MQTT 132 broker URI option is as shown below: 134 0 1 2 3 135 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 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | option-code | option-len | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | MQTT-broker-URI | 140 | (variable length data) | 141 | ... | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 option-code: OPTION_MQTT_BROKER_URI 145 option-len: Length of the 'MQTT-broker-URI' field in octets 147 MQTT-broker-URI: This string is URI of MQTT broker. The string is 148 not null-terminated. 150 2.2. DHCPv6 option for MQTT topic prefix 152 DHCPv6 option OPTION_MQTT_TOPIC_PREFIX conveys prefix string which 153 can be used by MQTT client as prefix of each topic used for 154 publishing data. The format of MQTT topic prefix option is as shown 155 below: 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | option-code | option-len | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | | 163 | MQTT-topic-prefix | 164 | (variable length data) | 165 | | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 option-code: OPTION_MQTT_TOPIC_PREFIX 170 option-len: Length of the 'MQTT-topic-prefix' field in octets 172 MQTT-topic-prefix: MQTT topic prefix string that can be used by MQTT 173 client as prefix to each topic used for publishing data 175 2.3. DHCPv4 option for MQTT broker URI 177 DHCPv4 option OPTION_MQTT_BROKER_URI conveys URI through which MQTT 178 client can reach MQTT broker that is reachable through IPv4 network. 179 The format of MQTT broker URI option is as shown below: 181 0 1 2 3 182 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 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | option-code | option-len | | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 186 | | 187 | MQTT-broker-URI(variable length data) | 188 | ... | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 option-code: OPTION_MQTT_BROKER_URI 192 option-len: Length of the 'MQTT-broker-URI' field in octets 194 MQTT-broker-URI: This string is URI of MQTT broker. The string is 195 not null-terminated. 197 2.4. DHCPv4 option for MQTT topic prefix 199 DHCPv4 option OPTION_MQTT_TOPIC_PREFIX conveys prefix string which 200 can be used by MQTT client as prefix of each topic used for 201 publishing data. The format of MQTT topic prefix option is as shown 202 below: 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | option-code | option-len | | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 209 | | 210 | MQTT-topic-prefix | 211 | (variable length data) | 212 | | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 option-code: OPTION_MQTT_TOPIC_PREFIX 217 option-len: Length of the 'MQTT-topic-prefix' field in octets 219 MQTT-topic-prefix: MQTT topic prefix string that can be used by MQTT 220 client as prefix to each topic used for publishing data 222 3. Appearance of Option 224 3.1. Appearance of options in DHCPv6 control messages 226 The OPTION_MQTT_BROKER_URI and OPTION_MQTT_TOPIC_PREFIX options MUST 227 NOT appear in messages other than the following: SOLICIT (1), 228 ADVERTISE (2), REQUEST (3),REPLY (4) RENEW (5), REBIND (6), 229 INFORMATION-REQUEST (11). If this option appears in messages other 230 than those specified above, the receiver MUST ignore it. 232 The option number for OPTION_MQTT_BROKER_URI and 233 OPTION_MQTT_TOPIC_PREFIX options MAY appear in the "Option Request" 234 option [RFC3315] in the following messages: SOLICIT (1), REQUEST (3), 235 RENEW (5), REBIND (6), INFORMATION-REQUEST (11) and RECONFIGURE (10). 236 If this option number appears in the "Option Request" option in 237 messages other than those specified above, the receiver SHOULD ignore 238 it. 240 3.2. Appearance of options in DHCPv4 control messages 242 The OPTION_MQTT_BROKER_URI and OPTION_MQTT_TOPIC_PREFIX options MUST 243 NOT appear in messages other than the following: DHCPDISCOVER (1), 244 DHCPOFFER (2), DHCPREQUEST (3), DHCPACK (5) and DHCPINFORM (8). If 245 this option appears in messages other than those specified above, the 246 receiver MUST ignore it. 248 The option number for OPTION_MQTT_BROKER_URI and 249 OPTION_MQTT_TOPIC_PREFIX options MAY appear in the "Parameter Request 250 List" option [RFC2132] in the following messages: DHCPDISCOVER (1), 251 DHCPOFFER (2), DHCPREQUEST (3), DHCPACK (5) and DHCPINFORM (8). If 252 this option number appears in the "Parameter Request List" option in 253 messages other than those specified above, the receiver SHOULD ignore 254 it. 256 Maximum possible value of DHCPv4 "option-len" is 255. MQTT-topic- 257 prefix MAY be of length more than 255. To accommodate larger 258 certificate, DHCP server SHOULD follow encoding as mentioned in 259 [RFC3396]. 261 4. Configuration Guidelines for the Server 263 DHCPv4 or DHCPv6 server that supports OPTION_MQTT_BROKER_URI and 264 OPTION_MQTT_TOPIC_PREFIX SHOULD be configured with one or more MQTT 265 broker URI, and one or moretopic prefix for each MQTT client. DHCP 266 server may use statically configured topic prefixes or algorithem 267 genrated topic prefixes. Algorithems to generate MQTT topic prefix 268 for an MQTT client might use client attributes like data link layer 269 address. Details of algorithems to generate topic prefix and 270 guidelines to manage topic prefixes are not included in the scope of 271 this draft 273 In the absence of MQTT broker URI configuration, DHCP server SHOULD 274 ignore option OPTION_MQTT_BROKER_URI, and SHOULD continue processing 275 of DHCP control message 277 In the absence of MQTT topic prefix configuration and topic prefix 278 generation algorithem, DHCP server SHOULD ignore option 279 OPTION_MQTT_TOPIC_PREFIX, and SHOULD continue processing of DHCP 280 control message 282 5. DHCPv4/DHCPv6 Client Behavior 284 DHCP or DHCPv6 client MAY decide need for inclusion of 285 OPTION_MQTT_BROKER_URI and OPTION_MQTT_TOPIC_PREFIX options in DHCPv4 286 or DHCPv6 control messages if device is capable of supporting MQTT 287 client functionality irrespective of state of MQTT client. It is 288 possible that MQTT client MAY not be active before DHCPv4 or DHCPv6 289 message exchanges happens. In such scenario, DHCPv4 or DHCPv6 client 290 MAY collect MQTT broker URI and MQTT topic prefix and keep ready for 291 MQTT client initialization 293 DHCPv4 or DHCPv6 client MAY prefer collecting MQTT broker URI and 294 MQTT topic prefix by including OPTION_MQTT_BROKER_URI and 295 OPTION_MQTT_TOPIC_PREFIX options in DHCPINFORM or INFORMATION-REQUEST 296 message which MAY be send during MQTT client initialization 298 MQTT client devices running with IPv6 stack MAY use stateless auto 299 address configuration to get IPv6 address. Such clients MAY use 300 DHCPv6 INFORMATION-REQUEST to get MQTT broker URI and MQTT topic 301 prefix through options OPTION_MQTT_BROKER_URI and 302 OPTION_MQTT_TOPIC_PREFIX 304 6. Relay agent Behavior 306 This draft does not impose any new requirements on DHCPv4 or DHCPv6 307 relay agent functionality 309 7. Security Considerations 311 OPTION_MQTT_BROKER_URI option could be used by an intruder to 312 advertise the URI of a malicious MQTT broker which results in data 313 reporting by MQTT clients to an unwanted MQTT broker. As an example, 314 an attacker could collect data from secure locations by deploying 315 malicious servers. 317 Intuders might use OPTION_MQTT_TOPIC_PREFIX option to advertise 318 unwanted topic prefixes which results in duplicate MQTT topics As an 319 example, an attacker could collect data from secure locations by 320 deploying malicious servers. 322 To prevent these attacks, it is strongly advisable to secure the use 323 of these options by either: 325 o Using authenticated DHCP as described in [RFC3315], Section 21. 327 o Using options OPTION_MQTT_BROKER_URI and OPTION_MQTT_TOPIC_PREFIX 328 only with trusted DHCP server 330 The security considerations documented in [RFC3315] are to be 331 considered. 333 8. Acknowledgement 335 Particular thanks to A. Keraenen and S. Krishnan for inputs and 336 review. 338 9. IANA Considerations 340 IANA is requested to assign new DHCPv6 option codes in the registry 341 maintained in http://www.iana.org/assignments/dhcpv6-parameters: 343 | Option Name | Value | 344 |---------------------------------+----------| 345 | OPTION_MQTT_BROKER_URI | TBA | 346 | OPTION_MQTT_TOPIC_PREFIX | TBA | 348 IANA is requested to assign new DHCPv4 option codes in the registry 349 maintained in http://www.iana.org/assignments/bootp-dhcp-parameters: 351 | Option Name | Value | 352 |--------------------------------+---------| 353 | OPTION_MQTT_BROKER_URI | TBA | 354 | OPTION_MQTT_TOPIC_PREFIX | TBA | 356 10. References 358 10.1. Normative References 360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 361 Requirement Levels", BCP 14, RFC 2119, 362 DOI 10.17487/RFC2119, March 1997, . 365 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 366 RFC 2131, DOI 10.17487/RFC2131, March 1997, 367 . 369 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 370 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 371 . 373 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 374 C., and M. Carney, "Dynamic Host Configuration Protocol 375 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 376 2003, . 378 [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the 379 Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, 380 DOI 10.17487/RFC3396, November 2002, . 383 [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) 384 Protocol", RFC 4306, DOI 10.17487/RFC4306, December 2005, 385 . 387 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 388 Housley, R., and W. Polk, "Internet X.509 Public Key 389 Infrastructure Certificate and Certificate Revocation List 390 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 391 . 393 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 394 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 395 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 396 . 398 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 399 Kivinen, "Internet Key Exchange Protocol Version 2 400 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 401 2014, . 403 10.2. Informative References 405 [MQTT-SPEC] 406 "MQTT Version 3.1.1, OASIS Standard", n.d., 407 . 410 Author's Address 412 Srinivas Rao Nalluri 413 Ericsson 414 Bangalore 415 India 417 Email: srinivasa.rao.nalluri@ericsson.com