idnits 2.17.1 draft-tiloca-core-groupcomm-proxy-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 date (March 09, 2020) is 1502 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) == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-07 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-05 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-37 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-05 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group M. Tiloca 3 Internet-Draft RISE AB 4 Intended status: Standards Track E. Dijk 5 Expires: September 10, 2020 IoTconsultancy.nl 6 March 09, 2020 8 Proxy Operations for CoAP Group Communication 9 draft-tiloca-core-groupcomm-proxy-00 11 Abstract 13 This document specifies the operations performed by a forward-proxy, 14 when using the Constrained Application Protocol (CoAP) in group 15 communication scenarios. Proxy operations involve the processing of 16 individual responses from servers, as reply to a single request sent 17 by the client over unicast to the proxy, and then distributed by the 18 proxy over IP multicast to the servers. When receiving the different 19 responses via the proxy, the client is able to distinguish them and 20 their originator servers, by acquiring their addressing information. 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 https://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 September 10, 2020. 39 Copyright Notice 41 Copyright (c) 2020 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 (https://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 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. The Multicast-Signaling Option . . . . . . . . . . . . . . . 3 59 3. The Response-Forwarding Option . . . . . . . . . . . . . . . 4 60 4. Requirements and Objectives . . . . . . . . . . . . . . . . . 5 61 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 6 62 5.1. Request Sending . . . . . . . . . . . . . . . . . . . . . 6 63 5.2. Request Processing at the Proxy . . . . . . . . . . . . . 7 64 5.3. Request and Response Processing at the Server . . . . . . 8 65 5.4. Response Processing at the Proxy . . . . . . . . . . . . 8 66 5.5. Response Processing at the Client . . . . . . . . . . . . 9 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 7.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 10 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 72 8.2. Informative References . . . . . . . . . . . . . . . . . 12 73 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 The Constrained Application Protocol (CoAP) [RFC7252] allows the 79 presence of forward-proxies, as intermediary entities supporting 80 clients to perform requests on their behalf. 82 CoAP supports also group communication over IP multicast 83 [I-D.dijk-core-groupcomm-bis], where a group request can be addressed 84 to multiple recipient servers, each of which may reply with an 85 individual unicast response. As discussed in Section 2.3.3 of 86 [I-D.dijk-core-groupcomm-bis], this group communication scenario 87 poses a number of issues and limitations to proxy operations. 89 In particular, the client sends a single unicast request to the 90 proxy, which the proxy forwards to a group of servers over IP 91 multicast. Later on, the proxy delivers back to the client multiple 92 responses to the original unicast request. As defined by [RFC7252] 93 the multiple responses are delivered to the client inside separate 94 CoAP messages, all matching (by Token) to the client's original 95 unicast request. A possible alternative approach of performing 96 aggregation of responses into a single CoAP response would require a 97 specific aggregation content-format, which is not available yet. 98 Both these approaches have open issues. 100 This specification considers the former approach of how the proxy 101 forwards the individual responses to a CoAP group request back to the 102 client. The described method addresses all the related issues raised 103 in Section 2.3.3 of [I-D.dijk-core-groupcomm-bis]. 105 To this end, a dedicated signaling protocol is defined, using two new 106 CoAP options. In particular, the client can explicitly confirm its 107 support for receiving multiple responses to a proxied unicast 108 request, i.e. one per originator server, and for how long it is 109 willing to wait for responses. Also, each server originating a 110 response indicates to the client its own addressing information. 111 This enables the client to distinguish the multiple, diffent 112 responses by origin and to possibly contact one or more of the 113 individual servers by a unicast request, optionally bypassing the 114 forward-proxy. 116 1.1. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 120 "OPTIONAL" in this document are to be interpreted as described in BCP 121 14 [RFC2119] [RFC8174] when, and only when, they appear in all 122 capitals, as shown here. 124 Readers are expected to be familiar with terms and concepts defined 125 in CoAP [RFC7252], Group Communication for CoAP 126 [I-D.dijk-core-groupcomm-bis], OSCORE [RFC8613] and Group OSCORE 127 [I-D.ietf-core-oscore-groupcomm]. 129 2. The Multicast-Signaling Option 131 The Multicast-Signaling Option defined in this section has the 132 properties summarized in Figure 1, which extends Table 4 of 133 [RFC7252]. The option is intended only for CoAP requests. 135 Since the option is not Safe-to-Forward, the column "N" indicates a 136 dash for "not applicable". The Multicast-Signaling Option contains a 137 timeout value in seconds, encoded as a CBOR [RFC7049] unsigned 138 integer. 140 +------+---+---+---+---+------------+--------+--------+---------+ 141 | No. | C | U | N | R | Name | Format | Length | Default | 142 +------+---+---+---+---+------------+--------+--------+---------+ 143 | | | | | | | | | | 144 | TBD1 | X | x | - | | Multicast- | uint | 1-5 B | (none) | 145 | | | | | | Signaling | | | | 146 | | | | | | | | | | 147 +------+---+---+---+---+------------+--------+--------+---------+ 148 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable 149 (*) See below. 151 Figure 1: The Multicast-Signaling Option. 153 This document specifically defines how this option is used by a 154 client to indicate to a forward-proxy its support for and interest in 155 receiving multiple responses to a proxied CoAP group request, i.e. 156 one per originator server, and for how long it is willing to wait for 157 receiving responses via that proxy (see Section 5.1 and Section 5.2). 159 The client, when sending a CoAP group request to a proxy via IP 160 unicast, to be forwarded by the proxy to a targeted group of servers, 161 includes the Multicast-Signaling Option in the request. The option 162 value indicates after what time period in seconds the client will 163 stop accepting responses matching its original unicast request, with 164 the exception of notifications if CoAP Observe is used [RFC7641]. 165 This allows the intermediary proxy to stop forwarding responses back 166 to the client, if received from the servers later than a timeout 167 expiration. 169 The Multicast-Signaling Option is of class I for OSCORE 170 [RFC8613][I-D.ietf-core-oscore-groupcomm], in order to allow the 171 proxy to access its value as intended consumer. 173 3. The Response-Forwarding Option 175 The Response-Forwarding Option defined in this section has the 176 properties summarized in Figure 2, which extends Table 4 of 177 [RFC7252]. The option is intended only for CoAP responses, and 178 builds on the Base-Uri option from Section 3 of 179 [I-D.bormann-coap-misc]. 181 Since the option is not Safe-to-Forward and is intended only for 182 responses, the column "N" indicates a dash. 184 +------+---+---+---+---+------------+--------+--------+---------+ 185 | No. | C | U | N | R | Name | Format | Length | Default | 186 +------+---+---+---+---+------------+--------+--------+---------+ 187 | | | | | | | | | | 188 | TBD2 | X | x | - | | Response- | (*) | 8-20 B | (none) | 189 | | | | | | Forwarding | | | | 190 | | | | | | | | | | 191 +------+---+---+---+---+------------+--------+--------+---------+ 192 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable 193 (*) See below. 195 Figure 2: The Response-Forwarding Option. 197 This document specifically defines how this option is used by a 198 server, when it receives a request originated by a client and 199 forwarded by a proxy over IP multicast. The server uses the option 200 to indicate its own addressing information to the originator client, 201 when sending its own response to the proxy (see Section 5). 203 When replying to a multicast request received via a proxy, the server 204 includes the Response-Forwarding Option in the response sent to the 205 client via that proxy. The option value includes addressing 206 information of the server, that the client can use to identify the 207 response originator and possibly send later unicast requests to 208 directly, or via the proxy as CoAP unicast request. 210 The value of the option is the unicast IP address of the server, 211 encoded as a CBOR byte string. The byte string is in turn tagged and 212 identified by the CBOR tag 260 "Network Address (IPv4 or IPv6 or MAC 213 Address)". 215 The Response-Forwarding Option is of class E for OSCORE 216 [RFC8613][I-D.ietf-core-oscore-groupcomm]. 218 4. Requirements and Objectives 220 This specification assumes that the following requirements are 221 fulfilled. 223 o REQ1. The CoAP proxy is explicitly configured (white-list) to 224 allow proxied CoAP group requests from specific client(s). 226 o REQ2. The CoAP proxy MUST identify a client sending a CoAP group 227 request, in order to verify whether that the client is white- 228 listed to do so. This can rely for example on using a (D)TLS 229 channel [RFC6347][I-D.ietf-tls-dtls13] between the client and the 230 proxy, where the client has also been authenticated during the 231 secure channel establishment. 233 o REQ3. If secure, end-to-end communication is required between the 234 client and the servers in the CoAP group, exchanged messages MUST 235 be protected by using Group OSCORE 236 [I-D.ietf-core-oscore-groupcomm], as discussed in Section 5.2 of 237 [I-D.dijk-core-groupcomm-bis]. This requires the client and the 238 servers to have previously joined the correct OSCORE group, for 239 instance by using the approach described in 240 [I-D.ietf-ace-key-groupcomm-oscore]. The correct OSCORE group to 241 join can be pre-configured or alternatively discovered, for 242 instance by using the approach described in 243 [I-D.tiloca-core-oscore-discovery]. 245 This specification defines how to achieve the following objectives. 247 o OBJ1. The CoAP proxy gets an indication from the client that it 248 is in fact interested to and capable to receive multiple responses 249 to its unicast request containing a CoAP group URI. 251 o OBJ2. The CoAP proxy learns how long it should wait for responses 252 to a proxied request, before starting to ignore following 253 responses (except for notifications, if CoAP Observe is used 254 [RFC7641]). 256 o OBJ3. The CoAP proxy returns individual unicast responses to the 257 client, each of which matches the original unicast request to the 258 proxy. 260 o OBJ4. The CoAP client is able to distinguish the different 261 responses to the original unicast request, as well as their 262 corresponding originator servers. 264 o OBJ5. The CoAP client is enabled to optionally contact one or 265 more of the responding servers in the future, either directly or 266 via a CoAP proxy. 268 5. Protocol Description 270 5.1. Request Sending 272 In order to send a request addressed to a group of servers via the 273 proxy, the client proceeds as follows. 275 1. The client prepares a request addressed to the proxy. The 276 request specifies the group URI as a string in the Proxi-URI 277 option, or by using the Proxy-Scheme option with the group URI 278 constructed from the URI-* options (see Section 2.3.3 of 279 [I-D.dijk-core-groupcomm-bis]). 281 2. The client MUST retain the Token value used for this original 282 unicast request beyond the reception of a first response matching 283 it. To this end, the client follows the same rules for Token 284 retention defined for multicast requests in Section 2.3.1 of 285 [I-D.dijk-core-groupcomm-bis]. In particular, it picks an amount 286 of time T before freeing up the Token value, such that: 288 * T is smaller than the amount of time Tr it may pick for 289 potentially reusing the Token value. 291 * T includes the expected worst-case time taken by the request 292 and response processing on the forward-proxy plus the servers 293 in the addressed CoAP group. 295 * T includes the expected worst-case round-trip delay between 296 client and proxy, and between proxy and servers. 298 3. The client includes the Multicast-Signaling Option defined in 299 Section 2, in the unicast request sent to the proxy. The option 300 value specifies an amount of time T' < T. The difference (T - 301 T') should include the expected worst-case round-trip time 302 between the client and the forward-proxy. 304 4. The rest of the request processing occurs as defined in 305 [I-D.dijk-core-groupcomm-bis], and in 306 [I-D.ietf-core-oscore-groupcomm] when secure group communication 307 is used. 309 5. The client sends the request to the proxy as a unicast CoAP 310 message. 312 5.2. Request Processing at the Proxy 314 Upon receiving the request from the client, the proxy proceeds as 315 follows. 317 1. The proxy identifies the client and verifies that it is in fact 318 white-listed for proxy requests to CoAP group URIs. 320 2. The proxy verifies the presence of the Multicast-Signaling 321 Option, as a confirmation that the client is fine to receive 322 multiple responses matching the same original request. 324 3. The proxy forwards the client's request to the group of servers. 325 In particular, the proxy sends it as a CoAP group request over IP 326 multicast, addressed to the group URI specified by the client. 328 4. The proxy sets a timeout with the value T' retrieved from the 329 Multicast-Signaling Option of the original unicast request. The 330 proxy will ignore responses to the forwarded group request coming 331 from servers, if received after the timeout expiration, with the 332 exception of Observe notifications (see Section 5.4). 334 5.3. Request and Response Processing at the Server 336 Upon receiving the group request from the proxy, a server proceeds as 337 follows. 339 1. Thanks to the Multicast-Signaling Option, the server understands 340 that the original request originator is in fact a client behind a 341 proxy. 343 2. The rest of the request processing occurs as defined in 344 [I-D.dijk-core-groupcomm-bis], and in 345 [I-D.ietf-core-oscore-groupcomm] when secure group communication 346 is used. 348 3. When preparing its response to the proxy, to be forwarded back to 349 the client, the server includes the Response-Forwarding Option 350 defined in Section 3. The server specifies as option value its 351 own addressing information, i.e. its unicast IP address, encoded 352 as defined in Section 3. The server MUST include its IPv6 353 address if the multicast request was destined to an IPv6 354 multicast address and MUST include its IPv4 address if the 355 multicast request was destined to an IPv4 address. 357 4. When using Observe [RFC7641], the server includes the Response- 358 Forwarding Option also in every notification, including non-2.xx 359 notifications resulting in removing the proxy from the list of 360 observers. 362 5. The rest of the response processing occurs as defined in 363 [I-D.dijk-core-groupcomm-bis], and in 364 [I-D.ietf-core-oscore-groupcomm] when secure group communication 365 is used. 367 5.4. Response Processing at the Proxy 369 Upon receiving a response matching the group request before the 370 amount of time T' has elapsed, the proxy forwards the response back 371 to the client. 373 Upon timeout expiration, i.e. T' seconds after having sent the group 374 request over IP multicast, the proxy frees up its local Token value 375 associated to that request. Thus, following late responses to the 376 same group request will be discarded and not forwarded back to the 377 client. 379 When using CoAP Observe [RFC7641], the Token value is freed up only 380 if, after the timeout expiration, no 2.xx (Success) responses 381 matching the group request and also including an Observe option have 382 been received. Then, as long as observations are active with servers 383 in the group for the target resource of the group request, 384 notifications from those servers are forwarded back to the client. 386 5.5. Response Processing at the Client 388 Upon receiving from the proxy a response that matches the original 389 unicast request, i.e. before the amount of time T has elapsed, the 390 client is able to identify the originator server, whose addressing 391 information is specified as value of the Response-Forwarding Option. 393 In particular, the client is able to distinguish different responses 394 as originated by different servers. Optionally the client may 395 contact one or more of those servers individually, directly 396 (bypassing the proxy) or indirectly (via a proxied CoAP unicast 397 request). Note that the client already knows the destination port 398 number to use for sending unicast requests to the server, i.e. the 399 same port number specified in the group URI of the original unicast 400 CoAP group request sent to the proxy (see Section 5.1). 402 The rest of the response processing occurs as defined in 403 [I-D.dijk-core-groupcomm-bis], and in 404 [I-D.ietf-core-oscore-groupcomm] when secure group communication is 405 used. 407 Upon the timeout expiration, i.e. T seconds after having sent the 408 original unicast request to the proxy, the client frees up its local 409 Token value associated to that request. Note that, upon this timeout 410 expiration, the Token value is not eligible for possible reuse yet 411 (see Section 5.1). Thus, until the actual amount of time enabling 412 Token reusage expires, following late responses to the same request 413 forwarded by the proxy will be discarded, as not matching any active 414 request Token from the client. 416 When using CoAP Observe [RFC7641], the Token value is freed up only 417 if, after the timeout expiration, no 2.xx (Success) responses 418 matching the original unicast and also including an Observe option 419 have been received. If at least one such response has been received, 420 then for as long as the observation for the target resource of the 421 original unicast request is active, the client receives those 422 notifications as forwarded by the proxy. 424 6. Security Considerations 426 The security considerations from [RFC7252][I-D.dijk-core-groupcomm-bi 427 s][RFC8613][I-D.ietf-core-oscore-groupcomm] hold for this document. 429 The Multicast-Signaling Option is of class I for OSCORE 430 [RFC8613][I-D.ietf-core-oscore-groupcomm]. While this allows the 431 proxy to access the option value and retrieve the timeout value T', 432 the proxy is not able to remove the option altogether without this 433 being noted by the servers. This ensures that the servers include 434 their addressing information as value of the Response-Forwarding 435 Option. 437 Besides, this prevents further possible intermediaries as well as on- 438 path active adversaries to remove the option or alter its content. 439 However, intermediares as well as on-path passive adversaries are 440 able to access the option content, and thus learn for how long 441 clients are willing to receive responses from the servers in the 442 group via the proxy. 444 If no secure group communication is enforced end-to-end between the 445 client and the servers (see Section 5.1 of 446 [I-D.dijk-core-groupcomm-bis]), the proxy or any other on-path active 447 intermediary is able to undetectably remove the Multicast-Signaling 448 Option, i.e. to not include it in the group request sent to the 449 servers in the group over multicast. As a consequence, the servers 450 will not include the Response-Forwarding Option in their response, 451 thus preventing the clients to distinguish the different responses 452 and their corresponding originator server. The same result is 453 achievable by removing the Response-Forwarding Option in the 454 individual response of specific servers. 456 7. IANA Considerations 458 This document has the following actions for IANA. 460 7.1. CoAP Option Numbers Registry 462 IANA is asked to enter the following option numbers to the "CoAP 463 Option Numbers" registry defined in [RFC7252] within the "CoRE 464 Parameters" registry. 466 +--------+---------------------+-------------------+ 467 | Number | Name | Reference | 468 +--------+---------------------+-------------------+ 469 | TBD1 | Multicast-Signaling | [[this document]] | 470 +--------+---------------------+-------------------+ 471 | TBD2 | Response-Forwarding | [[this document]] | 472 +--------+---------------------+-------------------+ 474 8. References 476 8.1. Normative References 478 [I-D.dijk-core-groupcomm-bis] 479 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 480 for the Constrained Application Protocol (CoAP)", draft- 481 dijk-core-groupcomm-bis-03 (work in progress), March 482 2020. 484 [I-D.ietf-core-oscore-groupcomm] 485 Tiloca, M., Selander, G., Palombini, F., and J. Park, 486 "Group OSCORE - Secure Group Communication for CoAP", 487 draft-ietf-core-oscore-groupcomm-07 (work in progress), 488 March 2020. 490 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 491 Requirement Levels", BCP 14, RFC 2119, 492 DOI 10.17487/RFC2119, March 1997, 493 . 495 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 496 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 497 October 2013, . 499 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 500 Application Protocol (CoAP)", RFC 7252, 501 DOI 10.17487/RFC7252, June 2014, 502 . 504 [RFC7641] Hartke, K., "Observing Resources in the Constrained 505 Application Protocol (CoAP)", RFC 7641, 506 DOI 10.17487/RFC7641, September 2015, 507 . 509 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 510 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 511 May 2017, . 513 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 514 "Object Security for Constrained RESTful Environments 515 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 516 . 518 8.2. Informative References 520 [I-D.bormann-coap-misc] 521 Bormann, C. and K. Hartke, "Miscellaneous additions to 522 CoAP", draft-bormann-coap-misc-27 (work in progress), 523 November 2014. 525 [I-D.ietf-ace-key-groupcomm-oscore] 526 Tiloca, M., Park, J., and F. Palombini, "Key Management 527 for OSCORE Groups in ACE", draft-ietf-ace-key-groupcomm- 528 oscore-05 (work in progress), March 2020. 530 [I-D.ietf-tls-dtls13] 531 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 532 Datagram Transport Layer Security (DTLS) Protocol Version 533 1.3", draft-ietf-tls-dtls13-37 (work in progress), March 534 2020. 536 [I-D.tiloca-core-oscore-discovery] 537 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 538 Groups with the CoRE Resource Directory", draft-tiloca- 539 core-oscore-discovery-05 (work in progress), March 540 2020. 542 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 543 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 544 January 2012, . 546 Acknowledgments 548 The work on this document has been partly supported by VINNOVA and 549 the Celtic-Next project CRITISEC. 551 Authors' Addresses 553 Marco Tiloca 554 RISE AB 555 Isafjordsgatan 22 556 Kista SE-16440 Stockholm 557 Sweden 559 Email: marco.tiloca@ri.se 560 Esko Dijk 561 IoTconsultancy.nl 562 \________________\ 563 Utrecht 564 The Netherlands 566 Email: esko.dijk@iotconsultancy.nl