idnits 2.17.1 draft-ietf-core-stateless-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 1, 2019) is 1873 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 (-14) exists of draft-ietf-core-echo-request-tag-03 == Outdated reference: A later version (-15) exists of draft-ietf-6tisch-minimal-security-09 == Outdated reference: A later version (-16) exists of draft-ietf-core-object-security-15 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group K. Hartke 3 Internet-Draft Ericsson 4 Updates: 7252, 8323 (if approved) March 1, 2019 5 Intended status: Standards Track 6 Expires: September 2, 2019 8 Extended Tokens and Stateless Clients 9 in the Constrained Application Protocol (CoAP) 10 draft-ietf-core-stateless-00 12 Abstract 14 This document provides considerations for alleviating CoAP clients 15 and intermediaries of maintaining per-request state. Additionally, 16 it introduces a new, optional CoAP protocol extension for extended 17 token lengths. 19 This document updates RFCs 7252 and 8323. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 2, 2019. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Extended Tokens . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Extended Token Length (TKL) Field . . . . . . . . . . . . 4 59 2.2. Discovering Support . . . . . . . . . . . . . . . . . . . 5 60 2.2.1. Extended-Token-Lengths Capability Option . . . . . . 5 61 2.2.2. Trial and Error . . . . . . . . . . . . . . . . . . . 5 62 2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . 6 63 3. Stateless Clients . . . . . . . . . . . . . . . . . . . . . . 6 64 3.1. Intermediaries . . . . . . . . . . . . . . . . . . . . . 7 65 3.2. Extended Tokens . . . . . . . . . . . . . . . . . . . . . 7 66 3.3. Message Transmission . . . . . . . . . . . . . . . . . . 9 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 4.1. Extended Tokens . . . . . . . . . . . . . . . . . . . . . 9 69 4.2. Stateless Clients . . . . . . . . . . . . . . . . . . . . 10 70 4.2.1. Recommended Algorithms . . . . . . . . . . . . . . . 10 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 5.1. CoAP Signaling Option Number . . . . . . . . . . . . . . 11 73 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 6.1. Normative References . . . . . . . . . . . . . . . . . . 11 75 6.2. Informative References . . . . . . . . . . . . . . . . . 12 76 Appendix A. Updated Message Formats . . . . . . . . . . . . . . 12 77 A.1. CoAP over UDP . . . . . . . . . . . . . . . . . . . . . . 13 78 A.2. CoAP over TCP . . . . . . . . . . . . . . . . . . . . . . 14 79 A.3. CoAP over WebSockets . . . . . . . . . . . . . . . . . . 15 80 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 83 1. Introduction 85 The Constrained Application Protocol (CoAP) [RFC7252] is a RESTful 86 application-layer protocol for constrained environments [RFC7228]. 87 In CoAP, clients (or intermediaries in the client role) make requests 88 to servers (or intermediaries in the server role), which serve the 89 requests by returning responses. 91 While a request is ongoing, a client typically maintains some state 92 that it requires for processing the response when it arrives. 93 Identification of this state is done by means of a _token_ in CoAP, 94 an opaque sequence of bytes chosen by the client and included in the 95 CoAP request. The server returns the token verbatim in any resulting 96 CoAP response (Figure 1). 98 +-----------------+ request with +------------+ 99 | | | state identifier | | 100 | | | as token | | 101 | .-<-+->------|--------------------->|------. | 102 | _|_ | | | | 103 | / \ stored | | | | 104 | \___/ state | | | | 105 | | | | | | 106 | '->-+-<------|<---------------------|------' | 107 | | | response with | | 108 | v | token echoed back | | 109 +-----------------+ +------------+ 110 Client Server 112 Figure 1: Token as an Identifier for Request State 114 In some scenarios, it can be beneficial to reduce the amount of state 115 stored at the client at the cost of increased message sizes. Clients 116 can implement this by serializing (parts of) their state into the 117 token itself and recovering the state from the token in the response 118 (Figure 2). 120 +-----------------+ request with +------------+ 121 | | | serialized state | | 122 | | | as token | | 123 | +--------|=====================>|------. | 124 | | | | | 125 | look ma, | | | | 126 | no state! | | | | 127 | | | | | 128 | +--------|<=====================|------' | 129 | | | response with | | 130 | v | token echoed back | | 131 +-----------------+ +------------+ 132 Client Server 134 Figure 2: Token as Serialization of Request State 136 Section 3 of this document provides considerations for making clients 137 "stateless" in this way, i.e., avoiding per-request state. (They'll 138 still need to maintain per-server state and other kinds of state, so 139 they're not entirely stateless.) 141 Serializing state into tokens is complicated by the fact that both 142 CoAP over UDP [RFC7252] and CoAP over reliable transports [RFC8323] 143 limit the maximum token length to 8 bytes. To overcome this 144 limitation, Section 2 of this document first introduces a CoAP 145 protocol extension for extended token lengths. 147 While the mechanism (extended token lengths) and the use case 148 (stateless clients) presented in this document are closely related, 149 both can be used independently of the other: Some implementations may 150 fit their state in 8 bytes; some implementations may have other use 151 cases for extended token lengths. 153 1.1. Terminology 155 Stateless 156 In this document, "stateless" refers to an implementation strategy 157 for a client (or intermediary in the client role) that doesn't 158 keep state for the individual requests it sends to a server (or 159 intermediary in the server role). The client still needs to keep 160 state for each server it communicates with (such as state for 161 generating tokens and congestion control), so it's not free of any 162 state. 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 166 "OPTIONAL" in this document are to be interpreted as described in BCP 167 14 [RFC2119] [RFC8174] when, and only when, they appear in all 168 capitals, as shown here. 170 2. Extended Tokens 172 2.1. Extended Token Length (TKL) Field 174 This document updates the message formats defined for CoAP over UDP 175 [RFC7252] and CoAP over TCP, TLS, and WebSockets [RFC8323] with the 176 following new definition of the TKL field, increasing the maximum 177 token length to 65804 bytes. 179 Token Length (TKL): 4-bit unsigned integer. A value between 0 and 180 12 inclusive indicates the length of the variable-length Token 181 field in bytes. Three values are reserved for special constructs: 183 13: An 8-bit unsigned integer precedes the Token field and 184 indicates the length of the Token field minus 13. 186 14: A 16-bit unsigned integer in network byte order precedes the 187 Token field and indicates the length of the Token field minus 188 269. 190 15: Reserved. This value MUST NOT be sent and MUST be processed 191 as a message format error. 193 All other fields retain their definition. 195 The updated message formats are illustrated in Appendix A. 197 2.2. Discovering Support 199 Extended token lengths require support from the server or, if there 200 are one or more intermediaries between the client and the server, the 201 intermediary in the server role that the client is interacting with. 203 Support can be discovered by a client (or intermediary in the client 204 role) in one of two ways: In case Capabilities and Settings Messages 205 (CSMs) are available, such as in CoAP over TCP, support can be 206 discovered using the Extended-Token-Lengths Capability Option defined 207 in Section 2.2.1. Otherwise, such as in CoAP over UDP, support can 208 only be discovered by trial and error, as described in Section 2.2.2. 210 2.2.1. Extended-Token-Lengths Capability Option 212 A sender can use the elective Extended-Token-Lengths Capability 213 Option to indicate its support for the new TKL field definition 214 specified in Section 2.1. 216 +----+---+---+-------+--------------------+-------+--------+--------+ 217 | # | C | R | Appli | Name | Forma | Length | Base | 218 | | | | es to | | t | | Value | 219 +----+---+---+-------+--------------------+-------+--------+--------+ 220 | TB | | | CSM | Extended-Token- | empty | 0 | (none) | 221 | D | | | | Lengths | | | | 222 +----+---+---+-------+--------------------+-------+--------+--------+ 224 C=Critical, R=Repeatable 226 Table 1: The Extended-Token-Lengths Capability Option 228 2.2.2. Trial and Error 230 A request with a TKL field value outside the range from 0 to 8 will 231 be considered a message format error (Section 3 of RFC 7252) and be 232 rejected by a recipient that does not support the updated TKL field 233 definition. A client thus can determine support by sending a request 234 with an extended token length and checking whether it's rejected by 235 the recipient or not. 237 In CoAP over UDP, a recipient rejects a malformed confirmable message 238 by sending a Reset message (Section 4.2 of RFC 7252). In case of a 239 non-confirmable message, sending a Reset message is permitted but not 240 required (Section 4.3 of RFC 7252). It is therefore RECOMMENDED that 241 clients use a confirmable message. 243 As per RFC 7252, Reset messages are empty and don't contain a token; 244 they only return the Message ID (Figure 3). They also don't contain 245 any indication of what caused a message format error. It is 246 therefore RECOMMENDED that clients use a request that contains no 247 potential message format error other than the extended token length. 249 In CoAP over TCP, TLS, and WebSockets, a recipient rejects a 250 malformed message by sending an Abort message and shutting down the 251 connection (Section 5.6 of RFC 8323). 253 +-----------------+ request message +------------+ 254 | | | with extended | | 255 | | | token length | | 256 | .-<-+->------|--------------------->|------. | 257 | _|_ | | | | 258 | / \ stored | | | | 259 | \___/ state | | | | 260 | | | | | | 261 | '->-+-<------|<---------------------|------' | 262 | | | reset message | | 263 | v | with only message | | 264 +-----------------+ ID echoed back +------------+ 265 Client Server 267 Figure 3: A Confirmable Request With an Extended Token is Rejected 268 With a Reset Message if the Next Hop Does Not Support It 270 2.3. Intermediaries 272 Tokens are a hop-by-hop feature: When an intermediary receives a 273 request, the only requirement is that it echoes the token back in any 274 resulting response. There is no requirement or expectation that an 275 intermediary passes a client's token on to a server or that an 276 intermediary uses extended token lengths itself when receiving a 277 request with an extended token length. 279 3. Stateless Clients 281 A client can be alleviated of keeping request state by serializing 282 the state into a sequence of bytes and sending the result as the 283 token of the request. The server will return the token to the client 284 in the response, so that the client can recover the state and process 285 the response as if it had kept the state locally. 287 The format of the serialized state is an implementation detail of the 288 client and opaque to any server implementation. Using tokens to 289 serialize state has significant and non-obvious security and privacy 290 implications that need to be mitigated; see Section 4. 292 3.1. Intermediaries 294 Tokens are a hop-by-hop feature: If a client makes a request to an 295 intermediary, that intermediary needs to store the client's token 296 (along with the client's transport address) while it makes its own 297 request to the next hop towards the origin server and waits for the 298 response. 300 An intermediary might want to be "stateless" as well, i.e., be 301 alleviated of storing the client's token and transport address for 302 ongoing requests. This can be implemented by serializing this 303 information along the request state into the token to the next hop. 304 When the next hop returns the response, the intermediary can recover 305 the information from the token and use it to satisfy the client's 306 request. 308 The downside of this approach is that an intermediary, without 309 keeping request state, is unable to aggregate requests, which reduces 310 efficiency. In particular, when multiple clients observe [RFC7641] 311 the same resource, aggregating requests is REQUIRED for efficiency 312 (Section 3.1 of RFC 7641). This implies that an intermediary MUST 313 NOT include an Observe Option in requests it sends without keeping 314 request state. 316 When using blockwise transfers [RFC7959], a server might not be able 317 to distinguish blocks originating from different clients once they 318 have been forwarded by an intermediary. To ensure that this does not 319 lead to inconsistent resource state, a stateless intermediary MUST 320 include the Request-Tag Option [I-D.ietf-core-echo-request-tag] in 321 blockwise transfers with a value that uniquely identifies the next 322 hop towards the client in the intermediary's namespace. 324 3.2. Extended Tokens 326 A client (or intermediary in the role of a client) that depends on 327 support for extended token lengths (Section 2) from the next hop to 328 avoid keeping request state MUST perform a discovery of support 329 (Section 2.2) before it can be stateless. This discovery MUST be 330 performed in a stateful way, i.e., keeping state for the request 331 (Figure 4): If the client was stateless from the start and the next 332 hop doesn't support extended tokens, then any error message couldn't 333 be processed since the state would neither be present at the client 334 nor returned in the Reset message (Figure 5). 336 +-----------------+ dummy request +------------+ 337 | | | with extended | | 338 | | | token | | 339 | .-<-+->------|=====================>|------. | 340 | _|_ | | | | 341 | / \ stored | | | | 342 | \___/ state | | | | 343 | | | | | | 344 | '->-+-<------|<=====================|------' | 345 | | | response with | | 346 | | | extended token | | 347 | | | echoed back | | 348 | | | | | 349 | | | | | 350 | | | request with | | 351 | | | serialized state | | 352 | | | as token | | 353 | +--------|=====================>|------. | 354 | | | | | 355 | look ma, | | | | 356 | no state! | | | | 357 | | | | | 358 | +--------|<=====================|------' | 359 | | | response with | | 360 | v | token echoed back | | 361 +-----------------+ +------------+ 362 Client Server 364 Figure 4: Depending on Extended Tokens for Being Stateless First 365 Requires a Successful Stateful Discovery of Support 367 +-----------------+ dummy request +------------+ 368 | | | with extended | | 369 | | | token | | 370 | +--------|=====================>|------. | 371 | | | | | 372 | | | | | 373 | | | | | 374 | | | | | 375 | ???|<---------------------|------' | 376 | | reset message | | 377 | | with only message | | 378 +-----------------+ ID echoed back +------------+ 379 Client Server 381 Figure 5: Stateless Discovery of Support Does Not Work 383 3.3. Message Transmission 385 As a further step in the case of CoAP over UDP [RFC7252], a client 386 (or intermediary in the client role) might want to also avoid keeping 387 message transmission state. 389 Generally, a client can use confirmable or non-confirmable messages 390 for requests. When using confirmable messages, it needs to keep 391 message exchange state for performing retransmissions and handling 392 Acknowledgement and Reset messages. When using non-confirmable 393 messages, it can keep no message exchange state. However, in either 394 case the client needs to keep congestion control state. That is, it 395 needs to maintain state for each node it communicates with and, e.g., 396 enforce NSTART. 398 As per RFC 7252, a client must be prepared to receive a response as a 399 piggybacked response, a separate response or non-confirmable response 400 (Section 5.2 of RFC 7252), regardless of the message type used for 401 the request. A stateless client needs to handle these response types 402 as follows: 404 o If a piggybacked response contains a valid authentication tag and 405 freshness indicator in the token, the client MUST process the 406 message as specified in RFC 7252; otherwise, it MUST silently 407 ignore the message. 409 o If a separate response contains a valid authentication tag and 410 freshness indicator in the token, the client MUST process the 411 message as specified in RFC 7252; otherwise, it MUST reject the 412 message as specified in Section 4.2 of RFC 7252. 414 o If a non-confirmable response contains a valid authentication tag 415 and freshness indicator in the token, the client MUST process the 416 message as specified in RFC 7252; otherwise, it MUST reject the 417 message as specified in Section 4.3 of RFC 7252. 419 4. Security Considerations 421 4.1. Extended Tokens 423 Tokens significantly larger than the 8 bytes specified in RFC 7252 424 have implications for nodes in particular with constrained memory 425 size that need to be mitigated. 427 A node in the server role supporting extended token lengths may be 428 vulnerable to a denial-of-service when an attacker (either on-path or 429 a malicious client) sends large tokens to fill up the memory of the 430 node. Implementations MUST be prepared for this and mitigate it. 432 4.2. Stateless Clients 434 Transporting the state needed by a client to process a response as 435 serialized state information in the token has several significant and 436 non-obvious security and privacy implications that need to be 437 mitigated. 439 Serialized state information is an attractive target for both 440 unwanted nodes (attackers between the node in client role and the 441 next hop) and wanted nodes (the next hop itself) on the path. 442 Therefore, a node in the client role MUST integrity protect the state 443 information, unless processing a response does not modify state or 444 cause other significant side effects. 446 Even when the serialized state is integrity protected, an attacker 447 may still replay a response, making the client believe it sent the 448 same request twice. Therefore, the node in client role MUST 449 implement replay protection (e.g., by using sequence numbers and a 450 replay window), unless processing a response does not modify state or 451 cause other significant side effects. Integrity protection is 452 REQUIRED for replay protection. 454 If processing a response without keeping request state is sensitive 455 to the time elapsed to sending the request, then the serialized state 456 MUST include freshness information (e.g., a timestamp). 458 Information in the serialized state may be privacy sensitive. A node 459 in client role MUST encrypt the serialized state if it contains 460 privacy sensitive information that an attacker would not get 461 otherwise. For example, an intermediary that serializes the client's 462 token and transport address into its token leaks that information to 463 the next hop, which may be undesirable. In wireless mesh networks, 464 where all traffic is visible to a passive attacker, encryption may 465 not be needed as the attacker can get the same information from 466 analyzing the traffic flows. 468 A node in client role using OSCORE [I-D.ietf-core-object-security] 469 always MUST encrypt the serialized state. 471 4.2.1. Recommended Algorithms 473 The use of encryption, integrity protection, and replay protection of 474 serialized state is recommended in general, unless a careful analysis 475 of any potential attacks to security and privacy is performed. 476 AES_CCM with a 64 bit tag is recommended, combined with a sequence 477 number and a replay window. Where encryption is not needed, HMAC- 478 SHA-256, combined with a sequence number and a replay window, may be 479 used. 481 5. IANA Considerations 483 5.1. CoAP Signaling Option Number 485 The following entries are added to the "CoAP Signaling Option 486 Numbers" registry within the "CoRE Parameters" registry. 488 +------------+--------+------------------------+-------------------+ 489 | Applies to | Number | Name | Reference | 490 +------------+--------+------------------------+-------------------+ 491 | 7.01 | TBD | Extended-Token-Lengths | [[this document]] | 492 +------------+--------+------------------------+-------------------+ 494 6. References 496 6.1. Normative References 498 [I-D.ietf-core-echo-request-tag] 499 Amsuess, C., Mattsson, J., and G. Selander, "Echo and 500 Request-Tag", draft-ietf-core-echo-request-tag-03 (work in 501 progress), October 2018. 503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 504 Requirement Levels", BCP 14, RFC 2119, 505 DOI 10.17487/RFC2119, March 1997, 506 . 508 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 509 Application Protocol (CoAP)", RFC 7252, 510 DOI 10.17487/RFC7252, June 2014, 511 . 513 [RFC7641] Hartke, K., "Observing Resources in the Constrained 514 Application Protocol (CoAP)", RFC 7641, 515 DOI 10.17487/RFC7641, September 2015, 516 . 518 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 519 the Constrained Application Protocol (CoAP)", RFC 7959, 520 DOI 10.17487/RFC7959, August 2016, 521 . 523 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 524 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 525 May 2017, . 527 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 528 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 529 Application Protocol) over TCP, TLS, and WebSockets", 530 RFC 8323, DOI 10.17487/RFC8323, February 2018, 531 . 533 6.2. Informative References 535 [I-D.ietf-6tisch-minimal-security] 536 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 537 "Minimal Security Framework for 6TiSCH", draft-ietf- 538 6tisch-minimal-security-09 (work in progress), November 539 2018. 541 [I-D.ietf-core-object-security] 542 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 543 "Object Security for Constrained RESTful Environments 544 (OSCORE)", draft-ietf-core-object-security-15 (work in 545 progress), August 2018. 547 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 548 Constrained-Node Networks", RFC 7228, 549 DOI 10.17487/RFC7228, May 2014, 550 . 552 Appendix A. Updated Message Formats 554 This appendix illustrates the CoAP message formats updated with the 555 new definition of the TKL field (Section 2). 557 A.1. CoAP over UDP 559 0 1 2 3 4 5 6 7 560 +-------+-------+---------------+ 561 | | | | 562 | Ver | T | TKL | 1 byte 563 | | | | 564 +-------+-------+---------------+ 565 | | 566 | Code | 1 byte 567 | | 568 +-------------------------------+ 569 | | 570 | | 571 | | 572 +- Message ID -+ 2 bytes 573 | | 574 | | 575 | | 576 +-------------------------------+ 577 \ \ 578 / TKL / 0-2 bytes 579 \ (extended) \ 580 +-------------------------------+ 581 \ \ 582 / Token / 0 or more bytes 583 \ \ 584 +-------------------------------+ 585 \ \ 586 / / 587 \ \ 588 / Options / 0 or more bytes 589 \ \ 590 / / 591 \ \ 592 +---------------+---------------+ 593 | | | 594 | 15 | 15 | 1 byte (if payload) 595 | | | 596 +---------------+---------------+ 597 \ \ 598 / / 599 \ \ 600 / Payload / 0 or more bytes 601 \ \ 602 / / 603 \ \ 604 +-------------------------------+ 606 A.2. CoAP over TCP 608 0 1 2 3 4 5 6 7 609 +---------------+---------------+ 610 | | | 611 | Len | TKL | 1 byte 612 | | | 613 +---------------+---------------+ 614 \ \ 615 / Len / 0-2 bytes 616 \ (extended) \ 617 +-------------------------------+ 618 | | 619 | Code | 1 byte 620 | | 621 +-------------------------------+ 622 \ \ 623 / TKL / 0-2 bytes 624 \ (extended) \ 625 +-------------------------------+ 626 \ \ 627 / Token / 0 or more bytes 628 \ \ 629 +-------------------------------+ 630 \ \ 631 / / 632 \ \ 633 / Options / 0 or more bytes 634 \ \ 635 / / 636 \ \ 637 +---------------+---------------+ 638 | | | 639 | 15 | 15 | 1 byte (if payload) 640 | | | 641 +---------------+---------------+ 642 \ \ 643 / / 644 \ \ 645 / Payload / 0 or more bytes 646 \ \ 647 / / 648 \ \ 649 +-------------------------------+ 651 A.3. CoAP over WebSockets 653 0 1 2 3 4 5 6 7 654 +---------------+---------------+ 655 | | | 656 | 0 | TKL | 1 byte 657 | | | 658 +---------------+---------------+ 659 | | 660 | Code | 1 byte 661 | | 662 +-------------------------------+ 663 \ \ 664 / TKL / 0-2 bytes 665 \ (extended) \ 666 +-------------------------------+ 667 \ \ 668 / Token / 0 or more bytes 669 \ \ 670 +-------------------------------+ 671 \ \ 672 / / 673 \ \ 674 / Options / 0 or more bytes 675 \ \ 676 / / 677 \ \ 678 +---------------+---------------+ 679 | | | 680 | 15 | 15 | 1 byte (if payload) 681 | | | 682 +---------------+---------------+ 683 \ \ 684 / / 685 \ \ 686 / Payload / 0 or more bytes 687 \ \ 688 / / 689 \ \ 690 +-------------------------------+ 692 Acknowledgements 694 This document is based on the requirements of and work on the Minimal 695 Security Framework for 6TiSCH [I-D.ietf-6tisch-minimal-security] by 696 Malisa Vucinic, Jonathan Simon, Kris Pister, and Michael Richardson. 698 Thanks to Carsten Bormann, Ari Keranen, John Mattsson, Jim Schaad, 699 Goeran Selander, and Malisa Vucinic for helpful comments and 700 discussions that have shaped the document. 702 Author's Address 704 Klaus Hartke 705 Ericsson 706 Torshamnsgatan 23 707 Stockholm SE-16483 708 Sweden 710 Email: klaus.hartke@ericsson.com