idnits 2.17.1 draft-lenders-dns-over-coaps-00.txt: -(4): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(6): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(9): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(519): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 9 instances of lines with non-ascii characters in the document. 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 (10 August 2021) is 990 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) == Missing Reference: 'TBD-this-spec' is mentioned on line 455, but not defined ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-06) exists of draft-ietf-core-coral-03 == Outdated reference: A later version (-15) exists of draft-ietf-core-href-06 -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) 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 M.S. Lenders 3 Internet-Draft FU Berlin 4 Intended status: Standards Track C. Amsüss 5 Expires: 11 February 2022 6 C. Gündoğan 7 T.C. Schmidt 8 HAW Hamburg 9 M. Wählisch 10 FU Berlin 11 10 August 2021 13 DNS Queries over CoAPS (DoC) 14 draft-lenders-dns-over-coaps-00 16 Abstract 18 This document defines a protocol for sending DNS messages over the 19 DTLS-Secured Constrained Application Protocol (CoAPS). Using the 20 REST architecture specified in CoAP and the security features of 21 DTLS, DNS over CoAPS provides encrypted DNS messages for constrained 22 devices in the Internet of Things (IoT) based on common interfaces. 24 Discussion Venues 26 This note is to be removed before publishing as an RFC. 28 Discussion of this document takes place on TODO 30 Source for this draft and an issue tracker can be found at 31 https://github.com/anr-bmbf-pivot/draft-dns-over-coaps. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 11 February 2022. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Selection of a DoC Server . . . . . . . . . . . . . . . . . . 4 69 3.1. URI Template Alternatives . . . . . . . . . . . . . . . . 4 70 4. Basic Message Exchange . . . . . . . . . . . . . . . . . . . 4 71 4.1. DNS Queries in CoAP Requests . . . . . . . . . . . . . . 4 72 4.1.1. Examples . . . . . . . . . . . . . . . . . . . . . . 5 73 4.2. DNS Responses in CoAP Responses . . . . . . . . . . . . . 6 74 4.2.1. Response Codes and Handling DNS and CoAP errors . . . 6 75 4.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . 7 76 5. CoAP/CoRE Integration . . . . . . . . . . . . . . . . . . . . 8 77 5.1. Proxies and caching . . . . . . . . . . . . . . . . . . . 8 78 5.2. OBSERVE (modifications)? . . . . . . . . . . . . . . . . 9 79 5.3. OSCORE . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 6. URI template configuration . . . . . . . . . . . . . . . . . 9 81 7. Considerations for Unencrypted Use . . . . . . . . . . . . . 10 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 86 10.2. Informative References . . . . . . . . . . . . . . . . . 11 87 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 88 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 91 1. Introduction 93 This document defines DNS over CoAPS (DoC), a protocol to send DNS 94 [RFC1035] queries and get DNS responses over the Constrained 95 Application Protocol (CoAP) [RFC7252]. Each DNS query-response pair 96 is mapped into a CoAP message exchange and secured by DTLS [RFC6347] 97 to ensure message integrity and confidentiality. 99 The application use case of DoC is inspired by DNS over HTTPS 100 [RFC8484] (DoH). DoC, however, aims for the deployment in the 101 constrained Internet of Things (IoT), which usually conflicts with 102 the requirements introduced by HTTPS. 104 To prevent TCP and HTTPS resource requirements, constrained IoT 105 devices could use DNS over DTLS [RFC8094]. In contrast to DNS over 106 DTLS, DoC utilizes CoAP features to mitigate drawbacks of datagram- 107 based communication. These features include: block-wise transfer, 108 which solves the Path MTU problem of DNS over DTLS (see [RFC8094], 109 section 5); CoAP proxies, which provide an additional level of 110 caching; re-use of data structures for application traffic and DNS 111 information, which saves memory on constrained devices. 113 - GET coaps://[2001::db8::1]/?dns=example.org 114 /- POST/FETCH coaps://[2001::db8::1]/ 115 / 116 CoAP request 117 +--------+ [DNS query] +--------+ DNS query +--------+ 118 | DoC |---------------->| DoC |.............>| DNS | 119 | Client |<----------------| Server |<.............| Server | 120 +--------+ CoAP response +--------+ DNS response +--------+ 121 [DNS response] 123 Figure 1: Basic DoC architecture 125 The most important components of DoC can be seen in Figure 1: A DoC 126 client tries to resolve DNS information by sending DNS queries 127 carried within CoAP requests to a DoC server. That DoC server may or 128 may not resolve that DNS information itself by using other DNS 129 transports with an upstream DNS server. The DoC server then replies 130 to the DNS queries with DNS responses carried within CoAP responses. 132 TBD: additional feature sets of CoAP/CoRE 134 * resource directory for DoC service discovery, 136 * ... 138 2. Terminology 140 A server that provides the service specified in this document is 141 called a "DoC server" to differentiate it from a classic "DNS 142 server". Correspondingly, a client using this protocol to retrieve 143 the DNS information is called a "DoC client". 145 The term "constrained nodes" is used as defined in [RFC7228]. 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 149 "OPTIONAL" in this document are to be interpreted as described in 150 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 151 capitals, as shown here. 153 3. Selection of a DoC Server 155 A DoC client is configured with a URI Template [RFC6570]. This 156 allows us to reuse configuration mechanisms provided for DoH. 158 The URI Template SHOULD provide a variable "dns" so that GET requests 159 can be used to retrieve the DNS information. If the "dns" variable 160 is not provided in the URI Template, GET requests can not be used for 161 DoC exchanges. 163 TBD: 165 * Support for more than one URI Template by DoC server. 167 * DoC server identity, key exchange, ... 169 3.1. URI Template Alternatives 171 TBD: 173 * CRI [I-D.ietf-core-href] or CoRAL [I-D.ietf-core-coral] 175 4. Basic Message Exchange 177 4.1. DNS Queries in CoAP Requests 179 A DoC client encodes a single DNS query in one or more CoAP request 180 messages using either the CoAP GET, FETCH [RFC8132], or POST method. 181 More than one CoAP request message MAY be used if the FETCH or POST 182 method are used and block-wise transfer [RFC7959] is supported by the 183 client. If more than one CoAP request message is used to encode the 184 DNS query, it must be chained together using the Block1 option in 185 those CoAP requests. To make use of the recovery mechanism of CoAP, 186 the CoAP request SHOULD be carried in a Confirmable (CON) messages. 188 For a POST or FETCH request the URI Template specified in Section 3 189 is processed without any variables set. For a GET request the URI 190 Template is extended with the "dns" variable set to the content of 191 the DNS query, encoded with "base64url" [RFC4648]. 193 If new Content Formats are specified in the future, the specification 194 MUST define the variable used in the URI Template with that new 195 format. 197 For POST and FETCH methods, the DNS query is included in the payloads 198 of the CoAP request messages in the binary format as specified in 199 [RFC1035]. The Content Format option MUST be included to indicate 200 the message type as "application/dns-message". Due to the lack of 201 encoding requirements, both FETCH and POST methods are generally 202 smaller than GET requests. 204 A DoH server MUST implement both the GET and POST method and MAY 205 implement the FETCH method. 207 Using GET enables CoAP proxies en-route to the DoC server to cache a 208 successful response. However, as the DNS query is carried in the URI 209 and thus in one of the URI-* options within a GET request, block-wise 210 transfer can not be used with that method. As a cache-friendly 211 alternative, the FETCH method can be used, which is an extension to 212 legacy CoAP, specified in [RFC8132]. 214 Requests of either method type SHOULD include an Accept option to 215 indicate what type of content can be parsed in the response. A 216 client MUST be able to parse messages of Content Format "application/ 217 dns-message" regardless of the provided Accept option. Messages of 218 that Content Format are DNS responses in binary format as specified 219 in [RFC1035]. 221 To simplify cache-key calculations at the CoAP proxies en-route, DoC 222 clients using Content Formats that include the ID field from the DNS 223 message, such as "application/dns-message", SHOULD use DNS ID 0 in 224 every DNS query. The CoAP message ID takes the same function on the 225 CoAP layer. Dedicated identification of DNS message exchanges on the 226 wire is thus not necessary. 228 4.1.1. Examples 230 The following examples illustrate the usage of different CoAP 231 messages to resolve "example.org. IN AAAA" based on the URI template 232 "coaps://[2001:db8::1]/{?dns}". The CoAP body is encoded in 233 "application/dns-message" Content Format. 235 GET request: 237 GET coaps://[2001::db8::1]/ 238 URI-Query: dns=AAABIAABAAAAAAAAB2V4YW1wbGUDb3JnAAAcAAE 239 Accept: application/dns-message 240 POST request: 242 POST coaps://[2001::db8::1]/ 243 Content-Format: application/dns-message 244 Accept: application/dns-message 245 Payload: 00 00 01 20 00 02 00 00 00 00 00 00 07 65 78 61 [binary] 246 6d 70 6c 65 03 6f 72 67 00 00 1c 00 01 c0 0c 00 [binary] 247 01 00 01 [binary] 249 FETCH request: 251 FETCH coaps://[2001::db8::1]/ 252 Content-Format: application/dns-message 253 Accept: application/dns-message 254 Payload: 00 00 01 20 00 02 00 00 00 00 00 00 07 65 78 61 [binary] 255 6d 70 6c 65 03 6f 72 67 00 00 1c 00 01 c0 0c 00 [binary] 256 01 00 01 [binary] 258 4.2. DNS Responses in CoAP Responses 260 This document specifies responses of Content Format "application/dns- 261 message" which encodes the DNS response in the binary format, 262 specified in [RFC1035]. For this type of responses, the Content 263 Format option indicating the "application/dns-message" format MUST be 264 included. A DoC server MUST be able to parse requests of Content 265 Format "application/dns-message". 267 Each DNS query-response pair is mapped to a train of one or more of 268 CoAP request-response pairs. If supported, a DoC server MAY transfer 269 the DNS response in more than one CoAP response using the Block2 270 option [RFC7959]. 272 4.2.1. Response Codes and Handling DNS and CoAP errors 274 A DNS response indicates either success or failure for the DNS query. 275 As such, it is RECOMMENDED that CoAP responses that carry any valid 276 DNS response, use a 2.xx Success response code. GET and FETCH 277 requests SHOULD be responded to with a 2.05 Content response. POST 278 requests SHOULD be responded to with a 2.01 Created response. 280 CoAP responses with non-successful response codes MUST NOT contain 281 any payload and may only be used on errors in the CoAP layer or when 282 a request does not fulfill the requirements of the DoC protocol. 284 For consistency, communications errors with an upstream DNS server 285 such as timeouts SHOULD be indicated with a SERVFAIL DNS response in 286 a successful CoAP response. 288 A DoC client might try to repeat a non-successful exchange unless 289 otherwise prohibited. For instance, a FETCH request MUST NOT be 290 repeated with a URI Template for which the DoC server already 291 responded with a 4.05 Method Not Allowed, as the server might only 292 implement legacy CoAP and does not support the FETCH method. The DoC 293 client might also elect to repeat a non-successful exchange with a 294 different URI Template, for instance, when the response indicates an 295 unsupported content format. 297 4.2.2. Examples 299 The following examples illustrate the replies to the query 300 "example.org. IN AAAA record", recursion turned on. Successful 301 responses carry one answer record including address 302 2001:db8:1::1:2:3:4 and TTL 58719. 304 A successful response to a GET or FETCH request: 306 2.05 Content 307 Content-Format: application/dns-message 308 Max-Age: 58719 309 Payload: 00 00 81 a0 00 01 00 01 00 00 00 00 07 65 78 61 [binary] 310 6d 70 6c 65 03 6f 72 67 00 00 1c 00 01 c0 0c 00 [binary] 311 1c 00 01 00 01 37 49 00 10 20 01 0d b8 00 01 00 [binary] 312 00 00 01 00 02 00 03 00 04 314 A successful response to a POST request uses a different response 315 code: 317 2.03 Created 318 Content-Format: application/dns-message 319 Max-Age: 58719 320 Payload: 00 00 81 a0 00 01 00 01 00 00 00 00 07 65 78 61 [binary] 321 6d 70 6c 65 03 6f 72 67 00 00 1c 00 01 c0 0c 00 [binary] 322 1c 00 01 00 01 37 49 00 10 20 01 0d b8 00 01 00 [binary] 323 00 00 01 00 02 00 03 00 04 325 When a DNS error (SERVFAIL in this case) is noted in the DNS 326 response, the CoAP request still indicates success: 328 2.05 Content 329 Content-Format: application/dns-message 330 Payload: 00 00 81 a2 00 01 00 00 00 00 00 00 07 65 78 61 [binary] 331 6d 70 6c 65 03 6f 72 67 00 00 1c 00 01 [binary] 333 When an error occurs on the CoAP layer, the DoC server SHOULD respond 334 with an appropriate CoAP error, for instance "4.15 Unsupported 335 Content-Format" if the Content Format option in the request was not 336 set to "application/dns-message". 338 5. CoAP/CoRE Integration 340 5.1. Proxies and caching 342 DoC exchanges may be cached by CoAP proxies and DNS caches en-route. 343 It is desirable that DoC exchanges follow the same paradigm as all 344 CoAP exchanges so they do not need any special handling by a CoAP 345 cache implementation. 347 Two requirements to a DoC exchange are necessary to that goal: First, 348 the ID field of the DNS header SHOULD always be 0, when using the 349 "application/dns-message" Content Format. This allows for both GET 350 URIs and FETCH payload to always have the same value for the same DNS 351 query, and thus they do not interfere with cache key generation. 352 Second, it is RECOMMENDED to set the Max-Age option of a response to 353 the minimum TTL in the Answer section of a DNS response. This 354 prevents expired records unintentionally being served from a CoAP 355 cache. 357 DoC client DoC proxy DNS server 358 | CoAP req [rt 1] | | 359 |------------------>| DNS query [rt 1] | 360 | |------------------->| 361 | CoAP req [rt 2] | | 362 |------------------>| DNS resp | 363 | CoAP resp |<-------------------| 364 |<------------------| | 365 | | | 367 Figure 2: CoAP retransmission (rt) is received before DNS query 368 could have been fulfilled. 370 TBD: 372 * Responses that are not globally valid 374 * General CoAP proxy problem, but what to do when DoC server is a 375 DNS proxy, response came not yet in but retransmission by DoC 376 client was received (see Figure 2) 378 - send empty ACK (maybe move to best practices appendix 379 (https://github.com/anr-bmbf-pivot/draft-dns-over-coaps/ 380 issues/6#issuecomment-895880206)) 382 It is RECOMMENDED that servers set an ETag option on large responses 383 (TBD: more concrete guidance) that have a short Max-Age relative to 384 the expected clients' caching time. Thus, clients that need to 385 revalidate a response can do so using the established ETag mechanism. 386 With responses large enough to be fragmented, it's best practice for 387 servers to set an ETag anyway. 389 5.2. OBSERVE (modifications)? 391 * TBD 393 * DoH has considerations on Server Push to deliver additional, 394 potentially outstanding requests + response to the DoC client for 395 caching 397 * OBSERVE does not include the request it would have been generated 398 from ==> cannot be cached without corresponding request having 399 been send over the wire. 401 * If use case exists: extend OBSERVE with option that contains 402 "promised" request (see [RFC7540], section 8.2)? 404 * Other caveat: clients can't cache, only proxys so value needs to 405 be evaluated 407 * Potential use case: [RFC8490] Section 4.1.2 409 5.3. OSCORE 411 * TBD 413 * With OSCORE DTLS might not be required 415 6. URI template configuration 417 * TBD 419 * Maybe out-of-scope? 421 * DHCP and RA options to deliver? [I-D.peterson-doh-dhcp] 423 * CoRE-RD [I-D.ietf-core-resource-directory] (...; can not express 424 URI templates) 426 * When no actual templating is involved: regular resource discovery 427 ("rt=core.dns"?) through .well-known/core 429 7. Considerations for Unencrypted Use 431 * TBD 433 * DTLS-transport should be used 435 * Non-DTLS can have benefits: Blockwise-transfer for IEEE 802.15.4, 436 additional layer of caching, ... 438 8. Security Considerations 440 TODO Security 442 9. IANA Considerations 444 IANA is requested to assign CoAP Content-Format ID for the DNS 445 message media type in the "CoAP Content-Formats" sub-registry, within 446 the "CoRE Parameters" registry [RFC7252], corresponding the 447 "application/dns-message" media type from the "Media Types" registry: 449 Media-Type: application/dns-message 451 Encoding: - 453 Id: TBD 455 Reference: [TBD-this-spec] 457 10. References 459 10.1. Normative References 461 [RFC1035] Mockapetris, P., "Domain names - implementation and 462 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 463 November 1987, . 465 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 466 Requirement Levels", BCP 14, RFC 2119, 467 DOI 10.17487/RFC2119, March 1997, 468 . 470 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 471 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 472 . 474 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 475 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 476 January 2012, . 478 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 479 and D. Orchard, "URI Template", RFC 6570, 480 DOI 10.17487/RFC6570, March 2012, 481 . 483 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 484 Application Protocol (CoAP)", RFC 7252, 485 DOI 10.17487/RFC7252, June 2014, 486 . 488 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 489 the Constrained Application Protocol (CoAP)", RFC 7959, 490 DOI 10.17487/RFC7959, August 2016, 491 . 493 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 494 FETCH Methods for the Constrained Application Protocol 495 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 496 . 498 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 499 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 500 May 2017, . 502 10.2. Informative References 504 [I-D.ietf-core-coral] 505 Hartke, K., "The Constrained RESTful Application Language 506 (CoRAL)", Work in Progress, Internet-Draft, draft-ietf- 507 core-coral-03, 9 March 2020, 508 . 511 [I-D.ietf-core-href] 512 Bormann, C. and H. Birkholz, "Constrained Resource 513 Identifiers", Work in Progress, Internet-Draft, draft- 514 ietf-core-href-06, 25 July 2021, 515 . 518 [I-D.ietf-core-resource-directory] 519 Amsüss, C., Shelby, Z., Koster, M., Bormann, C., and P. V. 520 D. Stok, "CoRE Resource Directory", Work in Progress, 521 Internet-Draft, draft-ietf-core-resource-directory-28, 7 522 March 2021, . 525 [I-D.peterson-doh-dhcp] 526 Peterson, T., "DNS over HTTP resolver announcement Using 527 DHCP or Router Advertisements", Work in Progress, 528 Internet-Draft, draft-peterson-doh-dhcp-01, 21 October 529 2019, . 532 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 533 Constrained-Node Networks", RFC 7228, 534 DOI 10.17487/RFC7228, May 2014, 535 . 537 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 538 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 539 DOI 10.17487/RFC7540, May 2015, 540 . 542 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 543 Transport Layer Security (DTLS)", RFC 8094, 544 DOI 10.17487/RFC8094, February 2017, 545 . 547 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 548 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 549 . 551 [RFC8490] Bellis, R., Cheshire, S., Dickinson, J., Dickinson, S., 552 Lemon, T., and T. Pusateri, "DNS Stateful Operations", 553 RFC 8490, DOI 10.17487/RFC8490, March 2019, 554 . 556 Appendix A. Change Log 558 TBD: 560 * Reconsider usage of GET/POST (https://github.com/anr-bmbf-pivot/ 561 draft-dns-over-coaps/issues/2)? 563 * Request text duplication (https://github.com/anr-bmbf-pivot/draft- 564 dns-over-coaps/issues/4) 566 * TTL vs. Max-Age (https://github.com/anr-bmbf-pivot/draft-dns-over- 567 coaps/issues/5) 569 Acknowledgments 571 TODO acknowledge. 573 Authors' Addresses 575 Martine Sophie Lenders 576 Freie Universität Berlin 578 Email: m.lenders@fu-berlin.de 580 Christian Amsüss 582 Email: christian@amsuess.com 584 Cenk Gündoğan 585 HAW Hamburg 587 Email: cenk.guendogan@haw-hamburg.de 589 Thomas C. Schmidt 590 HAW Hamburg 592 Email: t.schmidt@haw-hamburg.de 594 Matthias Wählisch 595 Freie Universität Berlin 597 Email: m.waehlisch@fu-berlin.de