idnits 2.17.00 (12 Aug 2021)
/tmp/idnits30090/draft-mattsson-t2trg-amplification-attacks-00.txt:
-(2): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(5): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(499): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding
-(583): 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 8 instances of lines with non-ascii characters in the document.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords.
RFC 2119 keyword, line 338: '...at "the receiver MUST NOT replace the ...'
RFC 2119 keyword, line 344: '..."implementations MUST NOT update the a...'
RFC 2119 keyword, line 429: '... QUIC [RFC9000] mandates that "an endpoint MUST limit the amount of...'
Miscellaneous warnings:
----------------------------------------------------------------------------
-- The document date (11 February 2022) is 92 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'I-D.ietf-lake-edhoc' is defined on line 520, but no
explicit reference was found in the text
== Unused Reference: 'RFC6347' is defined on line 542, but no explicit
reference was found in the text
== Outdated reference: A later version (-04) exists of
draft-ietf-core-conditional-attributes-01
== Outdated reference: draft-ietf-core-echo-request-tag has been published
as RFC 9175
== Outdated reference: A later version (-06) exists of
draft-ietf-core-groupcomm-bis-05
== Outdated reference: A later version (-14) exists of
draft-ietf-core-oscore-groupcomm-13
== Outdated reference: A later version (-13) exists of
draft-ietf-lake-edhoc-12
== Outdated reference: draft-ietf-tls-dtls-connection-id has been published
as RFC 9146
== Outdated reference: draft-ietf-tls-dtls13 has been published as RFC 9147
-- Obsolete informational reference (is this intentional?): RFC 6347
(Obsoleted by RFC 9147)
Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group J. Preuß Mattsson
3 Internet-Draft G. Selander
4 Intended status: Informational Ericsson
5 Expires: 15 August 2022 C. Amsüss
6 Energy Harvesting Solutions
7 11 February 2022
9 Amplification Attacks Using the Constrained Application Protocol (CoAP)
10 draft-mattsson-t2trg-amplification-attacks-00
12 Abstract
14 Protecting Internet of Things (IoT) devices against attacks is not
15 enough. IoT deployments need to make sure that they are not used for
16 Distributed Denial-of-Service (DDoS) attacks. DDoS attacks are
17 typically done with compromised devices or with amplification attacks
18 using a spoofed source address. This document gives examples of
19 different theoretical amplification attacks using the Constrained
20 Application Protocol (CoAP). The goal with this document is to raise
21 awareness and to motivate generic and protocol-specific
22 recommendations on the usage of CoAP. Some of the discussed attacks
23 can be mitigated by not using NoSec or by using the Echo option.
25 Status of This Memo
27 This Internet-Draft is submitted in full conformance with the
28 provisions of BCP 78 and BCP 79.
30 Internet-Drafts are working documents of the Internet Engineering
31 Task Force (IETF). Note that other groups may also distribute
32 working documents as Internet-Drafts. The list of current Internet-
33 Drafts is at https://datatracker.ietf.org/drafts/current/.
35 Internet-Drafts are draft documents valid for a maximum of six months
36 and may be updated, replaced, or obsoleted by other documents at any
37 time. It is inappropriate to use Internet-Drafts as reference
38 material or to cite them other than as "work in progress."
40 This Internet-Draft will expire on 15 August 2022.
42 Copyright Notice
44 Copyright (c) 2022 IETF Trust and the persons identified as the
45 document authors. All rights reserved.
47 This document is subject to BCP 78 and the IETF Trust's Legal
48 Provisions Relating to IETF Documents (https://trustee.ietf.org/
49 license-info) in effect on the date of publication of this document.
50 Please review these documents carefully, as they describe your rights
51 and restrictions with respect to this document.
53 Table of Contents
55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
56 2. Amplification Attacks using CoAP . . . . . . . . . . . . . . 3
57 2.1. Simple Amplification Attacks . . . . . . . . . . . . . . 4
58 2.2. Amplification Attacks using Observe . . . . . . . . . . . 5
59 2.3. Amplification Attacks using Group Requests . . . . . . . 7
60 2.4. MITM Amplification Attacks . . . . . . . . . . . . . . . 8
61 3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
64 6. Informative References . . . . . . . . . . . . . . . . . . . 11
65 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
68 1. Introduction
70 One important protocol used to interact with Internet of Things (IoT)
71 sensors and actuators is the Constrained Application Protocol (CoAP)
72 [RFC7252]. CoAP can be used without security in the so called NoSec
73 mode but any Internet-of-Things (IoT) deployment valuing security and
74 privacy would use a security protocol such as DTLS
75 [I-D.ietf-tls-dtls13], TLS [RFC8446], or OSCORE [RFC8613] to protect
76 CoAP, where the choice of security protocol depends on the transport
77 protocol and the presence of intermediaries. The use of CoAP over
78 UDP and DTLS is specified in [RFC7252] and the use of CoAP over TCP
79 and TLS is specified in [RFC8323]. OSCORE protects CoAP end-to-end
80 with the use of COSE [RFC8152] and the CoAP Object-Security option
81 [RFC8613] and can therefore be used over any transport. Group OSCORE
82 [I-D.ietf-core-oscore-groupcomm] can be used to protect CoAP Group
83 Communication [I-D.ietf-core-groupcomm-bis].
85 Protecting Internet of Things (IoT) devices against attacks is not
86 enough. IoT deployments need to make sure that they are not used for
87 Distributed Denial-of-Service (DDoS) attacks. DDoS attacks are
88 typically done with compromised devices or with amplification attacks
89 using a spoofed source address. DDoS attacks is a huge and growing
90 problem for services and critical infrastucture [DDoS-Infra].
92 The document gives examples of different theoretical amplification
93 attacks using CoAP. When transported over UDP, the CoAP NoSec mode
94 is susceptible to source IP address spoofing and as a single request
95 can result in multiple responses from multiple servers, CoAP can have
96 very large amplification factors. The goal with this document is to
97 raise awareness and to motivate generic and protocol-specific
98 recommendations on the usage of CoAP.
100 Some of the discussed attacks can be mitigated by not using NoSec or
101 by using the Echo option [I-D.ietf-core-echo-request-tag].
103 2. Amplification Attacks using CoAP
105 In a Denial-of-Service (DoS) attack, an attacker sends a large number
106 of requests or responses to a target endpoint. The denial-of-service
107 might be caused by the target endpoint receiving a large amount of
108 data, sending a large amount of data, doing heavy processing, or
109 using too much memory, etc. In a Distributed Denial-of-Service
110 (DDoS) attack, the request or responses come from a large number of
111 sources.
113 In an amplification attack, the amplification factor is the ratio
114 between the total size of the data sent to the target and the total
115 size of the data sent by the attacker. In the attacks described in
116 this section, the attacker sends one or more requests, and the target
117 receives one or more responses. An amplification attack alone can be
118 a denial-of-service attack on a CoAP server by making it send a large
119 amount of data. But often amplification attacks are combined with
120 the attacker spoofing the source IP address of the targeted victim.
121 By requesting as much information as possible from several servers an
122 attacker can multiply the amount of traffic and create a distributed
123 denial-of-service attack on the target. When transported over UDP,
124 the CoAP NoSec mode is susceptible to source IP address spoofing.
126 Amplification attacks with CoAP are unfortunately not only theory.
127 Powerful CoAP amplification attacks made headlines in 2018, reaching
128 55 Gbps on average, and with the largest one clocking at 320 Gbps
129 [DDoS-ZDNET]. But in 2019, they were hardly seen anymore
130 [DDoS-2019]. In 2020, the FBI cyber division mentioned CoAP in a
131 public notification warning that cyber actors are increasingly likely
132 to abuse network protocols for DDoS attacks [DDoS-FBI]. CoAP
133 amplification attacks made a comeback in 2020 and CoAP was behind a
134 significant part of global DDoS attacks in Q4 2020 and Q1 2021, but
135 not at all in Q2 and Q3 of 2021 [DDoS-2021]. It seems unclear
136 exactly how the attacks were done, why they stopped, and how likely
137 CoAP amplifications attacks are to come back in the future.
139 The following sections give examples of different theoretical
140 amplification attacks using CoAP.
142 2.1. Simple Amplification Attacks
144 An amplification attack using a single response is illustrated in
145 Figure 1. If the response is c times larger than the request, the
146 amplification factor is c.
148 Client Foe Server
149 | | |
150 | +----->| Code: 0.01 (GET)
151 | | GET | Uri-Path: random quote
152 | | |
153 |<------------+ Code: 2.05 (Content)
154 | | 2.05 | Payload: "just because you own half the county
155 | | | doesn't mean that you have the power
156 | | | to run the rest of us. For twenty-
157 | | | three years, I've been dying to tell
158 | | | you what I thought of you! And now...
159 | | | well, being a Christian woman, I can't
160 | | | say it!"
162 Figure 1: Amplification attack using a single response
164 An attacker can increase the bandwidth by sending several GET
165 requests. An attacker can also increase or control the amplification
166 factor by creating or updating resources. By creating new resources,
167 an attacker can increase the size of /.well-known/core. An
168 amplification attack where the attacker influences the amplification
169 factor is illustrated in Figure 2.
171 Client Foe Server
172 | | |
173 | +----->| Code: 0.02 (POST)
174 | | POST | Uri-Path: /member/
175 | | | Payload: hampsterdance.hevc
176 | | |
177 .... ....
178 | +----->| Code: 0.02 (GET)
179 | | GET | Uri-Path: /member/
180 | | |
181 |<------------+ Code: 2.05 (Content)
182 | | 2.05 | Payload: hampsterdance.hevc
183 | | |
184 | +----->| Code: 0.02 (GET)
185 | | GET | Uri-Path: /member/
186 | | |
187 |<------------+ Code: 2.05 (Content)
188 | | 2.05 | Payload: hampsterdance.hevc
189 .... ....
191 Figure 2: Amplification attack using several requests and a chosen
192 amplification factor
194 2.2. Amplification Attacks using Observe
196 Amplification factors can be significantly worse when combined with
197 observe [RFC7641] and group requests [I-D.ietf-core-groupcomm-bis].
198 As a single request can result in multiple responses from multiple
199 servers, the amplification factors can be very large.
201 An amplification attack using observe is illustrated in Figure 3. If
202 each notification response is c times larger than the registration
203 request and each request results in n notifications, the
204 amplification factor is c * n. By registering the same client
205 several times using different Tokens or port numbers, the bandwidth
206 can be increased. By updating the observed resource, the attacker
207 may trigger notifications and increase the size of the notifications.
208 By using conditional attributes
209 [I-D.ietf-core-conditional-attributes] an attacker may increase the
210 frequency of notifications and therefore the amplification factor.
211 The maximum period attribute pmax indicates the maximum time, in
212 seconds, between two consecutive notifications (whether or not the
213 resource state has changed). If it is predictable when notifications
214 are sent as confirmable and which Message ID are used the
215 acknowledgements may be spoofed.
217 Client Foe Server
218 | | |
219 | +----->| Code: 0.01 (GET)
220 | | GET | Token: 0x83
221 | | | Observe: 0
222 | | | Uri-Path: temperature
223 | | | Uri-Query: pmax="0.1"
224 | | |
225 | +----->| Code: 0.01 (GET)
226 | | GET | Token: 0x84
227 | | | Observe: 0
228 | | | Uri-Path: temperature
229 | | | Uri-Query: pmax="0.1"
230 | | |
231 .... ....
232 |<------------+ Code: 2.05 (Content)
233 | | 2.05 | Token: 0x83
234 | | | Observe: 217362
235 | | | Payload: "299.7 K"
236 | | |
237 |<------------+ Code: 2.05 (Content)
238 | | 2.05 | Token: 0x84
239 | | | Observe: 217362
240 | | | Payload: "299.7 K"
241 | | |
242 .... ....
243 |<------------+ Code: 2.05 (Content)
244 | | 2.05 | Token: 0x83
245 | | | Observe: 217363
246 | | | Payload: "299.7 K"
247 | | |
248 |<------------+ Code: 2.05 (Content)
249 | | 2.05 | Token: 0x84
250 | | | Observe: 217363
251 | | | Payload: "299.7 K"
252 .... ....
254 Figure 3: Amplification attack using observe, registering the
255 same client several times, and requesting notifications at least
256 10 times every second
258 2.3. Amplification Attacks using Group Requests
260 An amplification attack using a group request is illustrated in
261 Figure 4. The group request is sent over multicast or broadcast and
262 in this case a single request results in m responses from m different
263 servers. If each response is c times larger than the request, the
264 amplification factor is c * m. Note that the servers usually do not
265 know the variable m.
267 Client Foe Server
268 | | |
269 | +----->| Code: 0.01 (GET)
270 | | GET | Token: 0x69
271 | | | Uri-Path:
272 | | |
273 |<------------+ Code: 2.05 (Content)
274 | | 2.05 | Token: 0x69
275 | | | Payload: { 1721 : { ...
276 | | |
277 |<------------+ Code: 2.05 (Content)
278 | | 2.05 | Token: 0x69
279 | | | Payload: { 1721 : { ...
280 | | |
281 .... ....
283 Figure 4: Amplification attack using multicast
285 An amplification attack using a multicast request and observe is
286 illustrated in Figure 5. In this case a single request results in n
287 responses each from m different servers giving a total of n * m
288 responses. If each response is c times larger than the request, the
289 amplification factor is c * n * m.
291 Client Foe Server
292 | | |
293 | +----->| Code: 0.01 (GET)
294 | | GET | Token: 0x44
295 | | | Observe: 0
296 | | | Uri-Path: temperature
297 | | | Uri-Query: pmax="0.1"
298 | | |
299 |<------------+ Code: 2.05 (Content)
300 | | 2.05 | Token: 0x44
301 | | | Observe: 217
302 | | | Payload: "301.2 K"
303 | | |
304 |<------------+ Code: 2.05 (Content)
305 | | 2.05 | Token: 0x44
306 | | | Observe: 363
307 | | | Payload: "293.4 K"
308 | | |
309 .... ....
310 |<------------+ Code: 2.05 (Content)
311 | | 2.05 | Token: 0x44
312 | | | Observe: 218
313 | | | Payload: "301.2 K"
314 | | |
315 |<------------+ Code: 2.05 (Content)
316 | | 2.05 | Token: 0x44
317 | | | Observe: 364
318 | | | Payload: "293.4 K"
319 | | |
320 .... ....
322 Figure 5: Amplification attack using multicast and observe
324 2.4. MITM Amplification Attacks
326 TLS and DTLS without Connection ID [I-D.ietf-tls-dtls-connection-id]
327 validate the IP address and port of the other peer, binds them to the
328 connection, and do not allow them to change. DTLS with Connection ID
329 allows the IP address and port to change at any time. As the source
330 address is not protected, an MITM attacker can change the address.
331 Note that an MITM attacker is a more capable attacker then an
332 attacker just spoofing the source address. It can be discussed if
333 and how much such an attack is reasonable for DDoS, but DTLS 1.3
334 states that "This attack is of concern when there is a large
335 asymmetry of request/response message sizes." [I-D.ietf-tls-dtls13].
337 DTLS 1.2 with Connection ID [I-D.ietf-tls-dtls-connection-id]
338 requires that "the receiver MUST NOT replace the address" unless
339 "there is a strategy for ensuring that the new peer address is able
340 to receive and process DTLS records" but does not give more details
341 than that. It seems like the receiver can start using the new peer
342 address and test that it is able to receive and process DTLS records
343 at some later point. DTLS 1.3 with Connection ID requires that
344 "implementations MUST NOT update the address" unless "they first
345 perform some reachability test" but does not give more details than
346 that. OSCORE [RFC8613] does not discuss address updates, but it can
347 be assumed that most servers send responses to the address it
348 received the request from without any reachability test. A
349 difference between (D)TLS and OSCORE is that in DTLS the updated
350 address is used for all future records, while in OSCORE a new address
351 is only used for responses to a specific request.
353 An MITM amplification attack updating the client's source address in
354 an observe registration is illustrated in Figure 6. This attack is
355 possible in OSCORE and DTLS with Connection ID. The server will send
356 notifications to the Victim until it at some unspecified point
357 requires an acknowledgement [RFC7641]. In DTLS 1.2 the reachability
358 test might be done at a later point. In OSCORE a reachability test
359 is likely not done.
361 Client Victim Foe Server
362 | | | |
363 +------------>S----->| Code: 0.01 (GET)
364 | GET | | | Observe: 0
365 | | | | Uri-Path: humidity
366 | | | |
367 |<------------D<-----+ Reachability test (DTLS)
368 +------------>S----->|
369 | | | |
370 .... .... ....
371 | |<------------+ Code: 2.05 (Content)
372 | | | 2.05 | Observe: 263712
373 | | | | Payload: "68 %"
374 | | | |
375 | |<------------+ Code: 2.05 (Content)
376 | | | 2.05 | Observe: 263713
377 | | | | Payload: "69 %"
378 .... .... ....
380 Figure 6: MITM Amplification attack by updating the client's
381 source address in a observe registration request
383 Where 'S' means the MITM attacker is changing the source address of
384 the message and 'D' means the MITM attacker is changing the
385 destination address of the message.
387 An MITM amplification attack updating the server's source address is
388 illustrated in Figure 7. This attack is possible in DTLS with
389 Connection ID. In DTLS 1.2 the reachability test might be done at a
390 later point.
392 Client Foe Victim Server
393 | | | |
394 +------------------->| Code: 0.01 (POST)
395 | POST | | | Uri-Path: video/
396 | | | |
397 |<-----S<------------| Code: 2.01 (Created)
398 | | | 2.01 |
399 | | | |
400 +----->D------------>| Reachability test (DTLS)
401 |<-----S<------------+
402 | | | |
403 .... .... ....
404 +------------>| | Code: 0.01 (POST)
405 | POST | | | Uri-Path: video/
406 | | | | Payload: survailance_1139.hevc
407 | | | |
408 +------------>| | Code: 0.01 (POST)
409 | POST | | | Uri-Path: video/
410 | | | | Payload: survailance_1140.hevc
411 .... .... ....
413 Figure 7: MITM Amplification attack by updating the server's
414 source address in a response
416 3. Summary
418 CoAP has always considered amplification attacks, but most of the
419 requirements in [RFC7252], [RFC7641],
420 [I-D.ietf-core-echo-request-tag], and [I-D.ietf-core-groupcomm-bis]
421 are "SHOULD" instead of "MUST", it is undefined what a "large
422 amplification factor" is, [RFC7641] does not specify how many
423 notifications that can be sent before a potentially spoofable
424 acknowledgement must be sent, and in several cases the "SHOULD" level
425 is further softened by "If possible" and "generally".
426 [I-D.ietf-core-conditional-attributes] does not have any
427 amplification attack considerations.
429 QUIC [RFC9000] mandates that "an endpoint MUST limit the amount of
430 data it sends to the unvalidated address to three times the amount of
431 data received from that address" without any exceptions. This
432 approach should be seen as current best practice.
434 While it is clear when a QUIC implementation violates the requirement
435 in [RFC9000], it is not clear when a CoAP implementation violates the
436 requirement in [RFC7252], [RFC7641],
437 [I-D.ietf-core-echo-request-tag], and [I-D.ietf-core-groupcomm-bis].
439 In CoAP, an address can be validated with a security protocol or by
440 using the Echo Option [I-D.ietf-core-echo-request-tag]. Restricting
441 the bandwidth per server is not enough as the number of servers the
442 attacker can use is typically unknown. For multicast requests, anti-
443 amplification limits and the Echo Option do not really work unless
444 the number of servers sending responses is known. Even if the
445 responses have the same size as the request, the amplification factor
446 from m servers is m, where m is typically unknown. While DoS attacks
447 from CoAP servers accessible over the Internet pose the largest
448 threat, an attacker on a local network (e.g, a compromised node)
449 might use local CoAP servers to attack targets on the Internet or on
450 the local network.
452 4. Security Considerations
454 The whole document can be seen as security considerations for CoAP.
456 5. IANA Considerations
458 This document has no actions for IANA.
460 6. Informative References
462 [DDoS-2019]
463 "DDoS Attacks 2019: A look back at the Developments over
464 the Year", Link11 , December 2019,
465 .
469 [DDoS-2021]
470 "Quarterly DDoS and Application Attack Report", Radware ,
471 October 2021,
472 .
474 [DDoS-FBI] "Private Industry Notification", FBI Cyber Division , July
475 2020, .
478 [DDoS-Infra]
479 "Critical Infrastructure Under Attack", Dark Reading ,
480 November 2021, .
484 [DDoS-ZDNET]
485 "The CoAP protocol is the next big thing for DDoS
486 attacks", ZDNet , December 2018,
487 .
490 [I-D.ietf-core-conditional-attributes]
491 Koster, M., Soloway, A., and B. Silverajan, "Conditional
492 Attributes for Constrained RESTful Environments", Work in
493 Progress, Internet-Draft, draft-ietf-core-conditional-
494 attributes-01, 13 January 2022,
495 .
498 [I-D.ietf-core-echo-request-tag]
499 Amsüss, C., Mattsson, J. P., and G. Selander, "CoAP: Echo,
500 Request-Tag, and Token Processing", Work in Progress,
501 Internet-Draft, draft-ietf-core-echo-request-tag-14, 4
502 October 2021, .
505 [I-D.ietf-core-groupcomm-bis]
506 Dijk, E., Wang, C., and M. Tiloca, "Group Communication
507 for the Constrained Application Protocol (CoAP)", Work in
508 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis-
509 05, 25 October 2021, .
512 [I-D.ietf-core-oscore-groupcomm]
513 Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P.,
514 and J. Park, "Group OSCORE - Secure Group Communication
515 for CoAP", Work in Progress, Internet-Draft, draft-ietf-
516 core-oscore-groupcomm-13, 25 October 2021,
517 .
520 [I-D.ietf-lake-edhoc]
521 Selander, G., Mattsson, J. P., and F. Palombini,
522 "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Work in
523 Progress, Internet-Draft, draft-ietf-lake-edhoc-12, 20
524 October 2021, .
527 [I-D.ietf-tls-dtls-connection-id]
528 Rescorla, E., Tschofenig, H., Fossati, T., and A. Kraus,
529 "Connection Identifiers for DTLS 1.2", Work in Progress,
530 Internet-Draft, draft-ietf-tls-dtls-connection-id-13, 22
531 June 2021, .
534 [I-D.ietf-tls-dtls13]
535 Rescorla, E., Tschofenig, H., and N. Modadugu, "The
536 Datagram Transport Layer Security (DTLS) Protocol Version
537 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
538 dtls13-43, 30 April 2021,
539 .
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 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
547 Application Protocol (CoAP)", RFC 7252,
548 DOI 10.17487/RFC7252, June 2014,
549 .
551 [RFC7641] Hartke, K., "Observing Resources in the Constrained
552 Application Protocol (CoAP)", RFC 7641,
553 DOI 10.17487/RFC7641, September 2015,
554 .
556 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
557 RFC 8152, DOI 10.17487/RFC8152, July 2017,
558 .
560 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
561 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
562 Application Protocol) over TCP, TLS, and WebSockets",
563 RFC 8323, DOI 10.17487/RFC8323, February 2018,
564 .
566 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
567 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
568 .
570 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
571 "Object Security for Constrained RESTful Environments
572 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
573 .
575 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
576 Multiplexed and Secure Transport", RFC 9000,
577 DOI 10.17487/RFC9000, May 2021,
578 .
580 Acknowledgements
582 The authors would like to thank Carsten Bormann, Klaus Hartke, Jaime
583 Jiménez, Ari Keränen, Matthias Kovatsch, Achim Kraus, Sandeep Kumar,
584 and András Méhes for their valuable comments and feedback.
586 Authors' Addresses
588 John Preuß Mattsson
589 Ericsson AB
590 SE-164 80 Stockholm
591 Sweden
593 Email: john.mattsson@ericsson.com
595 Göran Selander
596 Ericsson AB
597 SE-164 80 Stockholm
598 Sweden
600 Email: goran.selander@ericsson.com
602 Christian Amsüss
603 Energy Harvesting Solutions
605 Email: c.amsuess@energyharvesting.at