Content deleted Content added
WikiEditor50 (talk | contribs) clean up, typo(s) fixed: between 0 to → between 0 and (2) |
WikiEditor50 (talk | contribs) Undid revision 1276808029 by WikiEditor50 (talk) |
||
Line 151:
Every request carries a token (but it may be zero length) whose value was generated by the client. The server must echo every token value without any modification back to the client in the corresponding response. It is intended for use as a client-local identifier to match requests and responses, especially for concurrent requests.
Matching requests and responses is not done with the message ID because a response may be sent in a different message than the acknowledgement (which uses the message ID for matching). For example, this could be done to prevent retransmissions if obtaining the result takes some time. Such a detached response is called "separate response". In contrast, transmitting the response directly in the acknowledgement is called "piggybacked response" which is expected to be preferred for efficiency reasons.
=== Option ===
Line 178:
Option delta:
* 0 to 12: For delta between 0
* 13: For delta from 13 to 268: Option delta extended is an 8-bit value that represents the option delta value minus 13
* 14: For delta from 269 to 65,804: Option delta extended is a 16-bit value that represents the option delta value minus 269
Line 185:
Option length:
* 0 to 12: For option length between 0
* 13: For option length from 13 to 268: Option length extended is an 8-bit value that represents the option length value minus 13
* 14: For option length from 269 to 65,804: Option length extended is a 16-bit value that represents the option length value minus 269
* 15: Reserved for future use. It is an error for the option length field to be set to 0xFF.
Option value:
Line 297:
== Security ==
CoAP defines four security modes:<ref> [https://tools.ietf.org/html/rfc7252 RFC 7252, Constrained Application Protocol (CoAP)]</ref>
* NoSec, where [[DTLS]] is disabled
* PreSharedKey, where DTLS is enabled, there is a list of pre-shared keys, and each key includes a list of which nodes it can be used to communicate with. Devices must support the AES cipher suite.
Line 303:
* Certificate, where DTLS is enabled and the device uses [[X.509]] certificates for validation.
Research has been conducted on optimizing DTLS by implementing security associates as CoAP resources rather than using DTLS as a security wrapper for CoAP traffic. This research has indicated that improvements of up to 6.5 times none optimized implementations. <ref name="Security as a CoAP resource: An optimized DTLS implementation for the IoT">{{cite book |last1=Capossele |first1=Angelo |last2=Cervo |first2=Valerio |last3=De Cicco |first3=Gianluca |last4=Petrioli |first4=Chiara|title=2015 IEEE International Conference on Communications (ICC) |chapter=Security as a CoAP resource: An optimized DTLS implementation for the IoT |author4-link= Chiara Petrioli |date=June 2015 |journal=IEEE |pages=529–554 |doi= 10.1109/ICC.2015.7248379|isbn=978-1-4673-6432-4 |s2cid=12568959 }}</ref>
In addition to DTLS, RFC8613<ref>{{Cite journal|last1=Palombini|first1=Francesca|last2=Seitz|first2=Ludwig|last3=Selander|first3=Goeran|last4=Mattsson|first4=John|title=Object Security for Constrained RESTful Environments (OSCORE)|url=https://tools.ietf.org/html/rfc8613.html|access-date=2021-05-07|website=tools.ietf.org|year=2019 |doi=10.17487/RFC8613 |s2cid=58380874 |language=en}}</ref> defines the Object Security for Constrained RESTful Environments ([[OSCORE]]) protocol which provides security for CoAP at the application layer.
| |||