idnits 2.17.1 draft-ietf-core-coap-tcp-tls-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 date (November 19, 2015) is 3074 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: '------' is mentioned on line 199, but not defined == Missing Reference: 'RFCthis' is mentioned on line 444, but not defined ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-04) exists of draft-bormann-core-cocoa-03 == Outdated reference: A later version (-21) exists of draft-ietf-core-block-18 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CORE C. Bormann, Ed. 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Standards Track S. Lemay 5 Expires: May 22, 2016 V. Solorzano Barboza 6 Zebra Technologies 7 H. Tschofenig 8 ARM Ltd. 9 November 19, 2015 11 A TCP and TLS Transport for the Constrained Application Protocol (CoAP) 12 draft-ietf-core-coap-tcp-tls-01 14 Abstract 16 The Hypertext Transfer Protocol (HTTP) was designed with TCP as the 17 underlying transport protocol. The Constrained Application Protocol 18 (CoAP), while inspired by HTTP, has been defined to make use of UDP 19 instead of TCP. Therefore, reliable delivery and a simple congestion 20 control and flow control mechanism are provided by the message layer 21 of the CoAP protocol. 23 A number of environments benefit from the use of CoAP directly over a 24 reliable byte stream such as TCP, which already provides these 25 services. This document defines the use of CoAP over TCP as well as 26 CoAP over TLS. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on May 22, 2016. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Constrained Application Protocol . . . . . . . . . . . . . . 3 65 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . 6 67 5. Message Transmission . . . . . . . . . . . . . . . . . . . . 7 68 6. CoAP URI . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 6.1. coap+tcp URI scheme . . . . . . . . . . . . . . . . . . . 7 70 6.2. coaps+tcp URI scheme . . . . . . . . . . . . . . . . . . 8 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 73 8.1. Service Name and Port Number Registration . . . . . . . . 8 74 8.2. URI Schemes . . . . . . . . . . . . . . . . . . . . . . . 9 75 8.3. ALPN Protocol ID . . . . . . . . . . . . . . . . . . . . 10 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 79 10.2. Informative References . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 The Constrained Application Protocol (CoAP) [RFC7252] was designed 85 for Internet of Things (IoT) deployments, assuming that UDP can be 86 used unimpeded -- UDP [RFC0768], or DTLS [RFC6347] over UDP; it is a 87 good choice for transferring small amounts of data across networks 88 that follow the IP architecture. Some CoAP deployments, however, may 89 have to integrate well with existing enterprise infrastructure, where 90 the use of UDP-based protocols may not be well-received or may even 91 be blocked by firewalls. Middleboxes that are unaware of CoAP usage 92 for IoT can make the use of UDP brittle, resulting in lost or 93 malformed packets. 95 Where NATs are still present, CoAP over TCP can also help with their 96 traversal. NATs often calculate expiration timers based on the 97 transport layer protocol being used by application protocols. Many 98 NATs are built around the assumption that a transport layer protocol 99 such as TCP gives them additional information about the session life 100 cycle and keep TCP-based NAT bindings around for a longer period. 101 UDP, on the other hand, does not provide such information to a NAT 102 and timeouts tend to be much shorter, as research confirms 103 [HomeGateway]. 105 Some environments may also benefit from the more sophisticated 106 congestion control capabilities provided by many TCP implementations. 107 (Note that there is ongoing work to add more elaborate congestion 108 control to CoAP as well, see [I-D.bormann-core-cocoa].) 110 Finally, CoAP may be integrated into a Web environment where the 111 front-end uses CoAP from IoT devices to a cloud infrastructure but 112 the CoAP messages are then transported in TCP between the back-end 113 services. A TCP-to-UDP gateway can be used at the cloud boundary to 114 talk to the UDP-based IoT. 116 To make IoT devices work smoothly in these demanding environments, 117 CoAP needs to make use of a different transport protocol, namely TCP 118 [RFC0793], in some situations secured by TLS [RFC5246]. 120 The present document describes a shim header that conveys length 121 information about each CoAP message. Modifications to CoAP beyond 122 the replacement of the message layer (e.g., to introduce further 123 optimizations) are intentionally avoided. 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in 130 [RFC2119]. 132 3. Constrained Application Protocol 134 The interaction model of CoAP over TCP is very similar to the one for 135 CoAP over UDP, with the key difference that using TCP voids the need 136 to provide certain transport layer protocol features, such as 137 reliable delivery, fragmentation and reassembly, as well as 138 congestion control, at the CoAP level. The protocol stack is 139 illustrated in Figure 1 (derived from [RFC7252], Figure 1). 141 +----------------------+ 142 | Application | 143 +----------------------+ 144 +----------------------+ 145 | Requests/Responses | CoAP (RFC7252) 146 |----------------------| 147 | Message adapter | This Document 148 +----------------------+ 149 +-----------+ ^ 150 | TLS | | 151 +-----------+ v 152 +----------------------+ 153 | TCP | 154 +----------------------+ 156 Figure 1: The CoAP over TLS/TCP Protocol Stack 158 Since TCP offers reliable delivery, there is no need to offer a 159 redundant acknowledgement at the CoAP messaging layer. 161 Since there is no need to carry around acknowledgement semantics, 162 messages do not require a message type; no message layer 163 acknowledgement is expected or even possible. Because something 164 needs to be put into the two bits indicating the message type, we put 165 the bits for a Non-Confirmable message (NON) into the header. By the 166 nature of TCP, messages are always transmitted reliably over TCP. 167 Figure 2 (derived from [RFC7252], Figure 3) shows this message 168 exchange graphically. A UDP-to-TCP gateway will therefore discard 169 all empty messages, such as empty ACKs (after operating on them at 170 the message layer), and re-pack the contents of all non-empty CON, 171 NON, or ACK messages (i.e., those ACK messages that have a piggy- 172 backed response) into untyped messages (that happen to look like NON 173 messages). 175 Similarly, there is no need to detect duplicate delivery of a 176 message. In UDP CoAP, the Message ID is used for relating 177 acknowledgements to Confirmable messages as well as for duplicate 178 detection. Since the Message ID thus is not meaningful over TCP, it 179 is elided (as indicated by the dashes in Figure 2). 181 Client Server 182 | | 183 | (no type) [------] | 184 +-------------------->| 185 | | 187 Figure 2: Untyped Message Transmission over TCP. 189 A response is sent back as defined in [RFC7252], as illustrated in 190 Figure 3 (derived from [RFC7252], Figure 6). 192 Client Server 193 | | 194 | (no type) [------] | 195 | GET /temperature | 196 | (Token 0x74) | 197 +------------------->| 198 | | 199 | (no type) [------] | 200 | 2.05 Content | 201 | (Token 0x74) | 202 | "22.5 C" | 203 |<-------------------+ 204 | | 206 Figure 3 208 4. Message Format 210 The CoAP message format defined in [RFC7252], as shown in Figure 4, 211 relies on the datagram transport (UDP, or DTLS over UDP) for keeping 212 the individual messages separate. 214 0 1 2 3 215 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 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 |Ver| T | TKL | Code | Message ID | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Token (if any, TKL bytes) ... 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Options (if any) ... 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 |1 1 1 1 1 1 1 1| Payload (if any) ... 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 Figure 4: RFC 7252 defined CoAP Message Format. 228 In a stream oriented transport protocol such as TCP, a form of 229 message delimitation is needed. For this purpose, CoAP over TCP 230 introduces a length field. Figure 5 shows a 2-byte shim header 231 carrying length information prepended to the CoAP message header. 233 0 1 2 3 234 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 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Message Length |Ver|0 1| TKL | Code | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Token (TKL bytes) ... | Options (if any) ... 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 |1 1 1 1 1 1 1 1| Payload (if any) ... 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 Figure 5: CoAP Header with prepended Shim Header. 245 The 'Message Length' field is a 16-bit unsigned integer in network 246 byte order. It provides the length of the subsequent CoAP message 247 (including the CoAP header but excluding this message length field) 248 in bytes (so its minimum value is 2). The Message ID and message 249 type are meaningless and thus elided (what would have been the 250 message type field is always filled with what would be the code for 251 NON (01)). 253 The semantics of the other CoAP header fields are left unchanged. 255 4.1. Discussion 257 One observation is that, over a reliable byte stream transport, the 258 message size limitations defined in Section 4.6 of [RFC7252] are no 259 longer strictly necessary. Consenting [[how: There is currently no 260 defined way to arrive at this consent. --cabo]] implementations may 261 want to interchange messages with payload sizes larger than 1024 262 bytes, potentially also obviating the need for the Block protocol 263 [I-D.ietf-core-block]. It must be noted that entirely getting rid of 264 the block protocol is not a generally applicable solution, as: 266 o a UDP-to-TCP gateway may simply not have the context to convert a 267 message with a Block option into the equivalent exchange without 268 any use of a Block option; 270 o large messages might also cause undesired head-of-line blocking; 272 o the 2-byte message length field causes another, larger upper bound 273 to the message length. 275 The general assumption is therefore that the block protocol will 276 continue to be used over TCP, even if TCP-based applications 277 occasionally do exchange messages with payload sizes larger than 278 desirable in UDP. 280 5. Message Transmission 282 As CoAP exchanges messages asynchronously over the TCP connection, 283 the client can send multiple requests without waiting for responses. 284 For this reason, and due to the nature of TCP, responses are returned 285 during the same TCP connection as the request. In the event that the 286 connection gets terminated, all requests that have not yet elicited a 287 response are implicitly canceled; clients may transmit the request 288 again once a connection is reestablished. 290 Furthermore, since TCP is bidirectional, requests can be sent from 291 both the connecting host and the endpoint that accepted the 292 connection. In other words, the question who initiated the TCP 293 connection has no bearing on the meaning of the CoAP terms client and 294 server. 296 6. CoAP URI 298 CoAP [RFC7252] defines the "coap" and "coaps" URI schemes for 299 identifying CoAP resources and providing a means of locating the 300 resource. RFC 7252 defines these resources for use with CoAP over 301 UDP. 303 The present specification introduces two new URI schemes, namely 304 "coap+tcp" and "coaps+tcp". The rules from Section 6 of [RFC7252] 305 apply to these two new URI schemes. 307 [RFC7252], Section 8 (Multicast CoAP), does not apply to the URI 308 schemes defined in the present specification. 310 Resources made available via one of the "coap+tcp" or "coaps+tcp" 311 schemes have no shared identity with the other scheme or with the 312 "coap" or "coaps" scheme, even if their resource identifiers indicate 313 the same authority (the same host listening to the same port). The 314 schemes constitute distinct namespaces and, in combination with the 315 authority, are considered to be distinct origin servers. 317 6.1. coap+tcp URI scheme 319 coap-tcp-URI = "coap+tcp:" "//" host [ ":" port ] path-abempty 320 [ "?" query ] 322 The semantics defined in [RFC7252], Section 6.1, apply to this URI 323 scheme, with the following changes: 325 o The port subcomponent indicates the TCP port at which the CoAP 326 server is located. (If it is empty or not given, then the default 327 port 5683 is assumed, as with UDP.) 329 6.2. coaps+tcp URI scheme 331 coaps-tcp-URI = "coaps+tcp:" "//" host [ ":" port ] path-abempty 332 [ "?" query ] 334 The semantics defined in [RFC7252], Section 6.2, apply to this URI 335 scheme, with the following changes: 337 o The port subcomponent indicates the TCP port at which the TLS 338 server for the CoAP server is located. If it is empty or not 339 given, then the default port 443 is assumed (this is different 340 from the default port for "coaps", i.e., CoAP over DTLS over UDP). 342 o When CoAP is exchanged over TLS port 443 then the "TLS Application 343 Layer Protocol Negotiation Extension" [RFC7301] MUST be used to 344 allow demultiplexing at the server-side unless out-of-band 345 information ensures that the client only interacts with a server 346 that is able to demultiplex CoAP messages over port 443. This 347 would, for example, be true for many IoT deployments where clients 348 are pre-configured to only ever talk with specific servers. 349 [[alwaysalpn: Shouldn't we simply always require ALPN? The 350 protocol should not be defined in such a way that it depends on 351 some undefined pre-configuration mechanism. --cabo]] 353 7. Security Considerations 355 This document defines how to convey CoAP over TCP and TLS. It does 356 not introduce new vulnerabilities beyond those described already in 357 the CoAP specification. CoAP [RFC7252] makes use of DTLS 1.2 and 358 this specification consequently uses TLS 1.2 [RFC5246]. CoAP MUST 359 NOT be used with older versions of TLS. Guidelines for use of cipher 360 suites and TLS extensions can be found in [I-D.ietf-dice-profile]. 362 8. IANA Considerations 364 8.1. Service Name and Port Number Registration 366 IANA is requested to assign the port number 5683 and the service name 367 "coap+tcp", in accordance with [RFC6335]. 369 Service Name. 370 coap+tcp 372 Transport Protocol. 373 tcp 375 Assignee. 376 IESG 378 Contact. 379 IETF Chair 381 Description. 382 Constrained Application Protocol (CoAP) 384 Reference. 385 [RFCthis] 387 Port Number. 388 5683 390 Similarly, IANA is requested to assign the service name "coaps+tcp", 391 in accordance with [RFC6335]. However, no separate port number is 392 used for "coaps" over TCP; instead, the ALPN protocol ID defined in 393 Section 8.3 is used over port 443. 395 Service Name. 396 coaps+tcp 398 Transport Protocol. 399 tcp 401 Assignee. 402 IESG 404 Contact. 405 IETF Chair 407 Description. 408 Constrained Application Protocol (CoAP) 410 Reference. 411 [RFC7301], [RFCthis] 413 Port Number. 414 443 (see also Section 8.3 of [RFCthis]}) 416 8.2. URI Schemes 418 This document registers two new URI schemes, namely "coap+tcp" and 419 "coaps+tcp", for the use of CoAP over TCP and for CoAP over TLS over 420 TCP, respectively. The "coap+tcp" and "coaps+tcp" URI schemes can 421 thus be compared to the "http" and "https" URI schemes. 423 The syntax of the "coap" and "coaps" URI schemes is specified in 424 Section 6 of [RFC7252] and the present document re-uses their 425 semantics for "coap+tcp" and "coaps+tcp", respectively, with the 426 exception that TCP, or TLS over TCP is used as a transport protocol. 428 IANA is requested to add these new URI schemes to the registry 429 established with [RFC7595]. 431 8.3. ALPN Protocol ID 433 IANA is requested to assign the following value in the registry 434 "Application Layer Protocol Negotiation (ALPN) Protocol IDs" created 435 by [RFC7301]: 437 Protocol: 438 CoAP 440 Identification Sequence: 441 0x63 0x6f 0x61 0x70 ("coap") 443 Reference: 444 [RFCthis] 446 9. Acknowledgements 448 We would like to thank Stephen Berard, Geoffrey Cristallo, Olivier 449 Delaby, Michael Koster, Matthias Kovatsch, Szymon Sasin, Andrew 450 Summers, and Zach Shelby for their feedback. 452 10. References 454 10.1. Normative References 456 [I-D.ietf-dice-profile] 457 Tschofenig, H. and T. Fossati, "TLS/DTLS Profiles for the 458 Internet of Things", draft-ietf-dice-profile-17 (work in 459 progress), October 2015. 461 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 462 793, DOI 10.17487/RFC0793, September 1981, 463 . 465 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 466 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 467 RFC2119, March 1997, 468 . 470 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 471 (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ 472 RFC5246, August 2008, 473 . 475 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 476 Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ 477 RFC7252, June 2014, 478 . 480 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 481 "Transport Layer Security (TLS) Application-Layer Protocol 482 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 483 July 2014, . 485 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 486 and Registration Procedures for URI Schemes", BCP 35, RFC 487 7595, DOI 10.17487/RFC7595, June 2015, 488 . 490 10.2. Informative References 492 [HomeGateway] 493 Eggert, L., "An experimental study of home gateway 494 characteristics", Proceedings of the 10th annual 495 conference on Internet measurement, 2010. 497 [I-D.bormann-core-cocoa] 498 Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, 499 "CoAP Simple Congestion Control/Advanced", draft-bormann- 500 core-cocoa-03 (work in progress), October 2015. 502 [I-D.ietf-core-block] 503 Bormann, C. and Z. Shelby, "Block-wise transfers in CoAP", 504 draft-ietf-core-block-18 (work in progress), September 505 2015. 507 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 508 10.17487/RFC0768, August 1980, 509 . 511 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 512 Cheshire, "Internet Assigned Numbers Authority (IANA) 513 Procedures for the Management of the Service Name and 514 Transport Protocol Port Number Registry", BCP 165, RFC 515 6335, DOI 10.17487/RFC6335, August 2011, 516 . 518 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 519 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 520 January 2012, . 522 Authors' Addresses 524 Carsten Bormann (editor) 525 Universitaet Bremen TZI 526 Postfach 330440 527 Bremen D-28359 528 Germany 530 Phone: +49-421-218-63921 531 Email: cabo@tzi.org 533 Simon Lemay 534 Zebra Technologies 535 820 W. Jackson Blvd. Suite 700 536 Chicago 60607 537 United States of America 539 Phone: +1-847-634-6700 540 Email: slemay@zebra.com 542 Valik Solorzano Barboza 543 Zebra Technologies 544 820 W. Jackson Blvd. suite 700 545 Chicago 60607 546 United States of America 548 Phone: +1-847-634-6700 549 Email: vsolorzanobarboza@zebra.com 551 Hannes Tschofenig 552 ARM Ltd. 553 110 Fulbourn Rd 554 Cambridge CB1 9NJ 555 Great Britain 557 Email: Hannes.tschofenig@gmx.net 558 URI: http://www.tschofenig.priv.at