1.1.Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2.1.The Block Attack

An on-path attacker can block the delivery of any number of requests or responses.The attack can also be performed by an attacker jamming the lower layer radioprotocol. This is true even if a security protocol like DTLS, TLS, or OSCOREis used. Encryption makes selective blocking of messages harder, but notimpossible or even infeasible. With DTLS and TLS, proxies have access tothe complete CoAP message, and with OSCORE, the CoAP header and several CoAPoptions are not encrypted. In both security protocols, the IP-addresses,ports, and CoAP message lengths are available to all on-path attackers, whichmay be enough to determine the server, resource, and command. The blockattack is illustrated in Figures1 and2.¶

Client   Foe   Server   |      |      |   +----->X      |      Code: 0.03 (PUT)   | PUT  |      |     Token: 0x47   |      |      |  Uri-Path: lock   |      |      |   Payload: 1 (Lock)   |      |      |

Where 'X' means the attacker is blocking delivery of the message.¶

Client   Foe   Server   |      |      |   +------------>|      Code: 0.03 (PUT)   |      | PUT  |     Token: 0x47   |      |      |  Uri-Path: lock   |      |      |   Payload: 1 (Lock)   |      |      |   |      X<-----+      Code: 2.04 (Changed)   |      | 2.04 |     Token: 0x47   |      |      |

While blocking requests to, or responses from, a sensor is just a denialof service attack, blocking a request to, or a response from, an actuatorresults in the client losing information about the server's status. If theactuator e.g. is a lock (door, car, etc.), the attack results in the clientnot knowing (except by using out-of-band information) whether the lock isunlocked or locked, just like the observer in the famous Schrodinger's catthought experiment. Due to the nature of the attack, the client cannot distinguishthe attack from connectivity problems, offline servers, or unexpected behaviorfrom middle boxes such as NATs and firewalls.¶

Remedy: Any IoT deployment of actuators where confirmation is important MUSTnotify the user upon reception of the response, or warn the user when a responseis not received.¶

2.2.The Request Delay Attack

An on-path attacker may not only block packets, but can also delay the deliveryof any packet (request or response) by a chosen amount of time. If CoAP isused over a reliable and ordered transport such as TCP with TLS or OSCORE,no messages can be delivered before the delayed message. If CoAP is usedover an unreliable and unordered transport such as UDP with DTLS, or OSCORE,other messages can be delivered before the delayed message as long as thedelayed packet is delivered inside the replay window. When CoAP is used overUDP, both DTLS and OSCORE allow out-of-order delivery and uses sequence numberstogether with a replay window to protect against replay attacks. The replaywindow has a default length of 64 in DTLS and 32 in OSCORE. The attackercan control the replay window by blocking some or all other packets. By firstdelaying a request, and then later, after delivery, blocking the responseto the request, the client is not made aware of the delayed delivery exceptby the missing response. The server has in general, no way of knowing thatthe request was delayed and will therefore happily process the request.Note that delays can also happen for other reasons than a malicious attacker.¶

If some wireless low-level protocol is used, the attack can also be performedby the attacker simultaneously recording what the client transmits whileat the same time jamming the server. The request delay attack is illustratedinFigure 3.¶

Client   Foe   Server   |      |      |   +----->@      |      Code: 0.03 (PUT)   | PUT  |      |     Token: 0x9c   |      |      |  Uri-Path: lock   |      |      |   Payload: 0 (Unlock)   |      |      |     ....   ....   |      |      |   |      @----->|      Code: 0.03 (PUT)   |      | PUT  |     Token: 0x9c   |      |      |  Uri-Path: lock   |      |      |   Payload: 0 (Unlock)   |      |      |   |      X<-----+      Code: 2.04 (Changed)   |      | 2.04 |     Token: 0x9c   |      |      |

Where '@' means the attacker is storing and later forwarding the message(@ may alternatively be seen as a wormhole connecting two points in time).¶

While an attacker delaying a request to a sensor is often not a securityproblem, an attacker delaying a request to an actuator performing an actionis often a serious problem. A request to an actuator (for example a requestto unlock a lock) is often only meant to be valid for a short time frame,and if the request does not reach the actuator during this short timeframe,the request should not be fulfilled. In the unlock example, if the clientdoes not get any response and does not physically see the lock opening, theuser is likely to walk away, calling the locksmith (or the IT-support).¶

If a non-zero replay window is used (the default when CoAP is usedover UDP), the attacker can let the client interact with the actuatorbefore delivering the delayed request to the server (illustrated inFigure 4). In the lock example, the attacker may store thefirst "unlock" request for later use. The client will likely resendthe request with the same token. If DTLS is used, the resent packetwill have a different sequence number and the attacker can forwardit. If OSCORE is used, resent packets will have the same sequencenumber and the attacker must block them all until the client sends anew message with a new sequence number (not shown inFigure 4). After a while when the client has locked thedoor again, the attacker can deliver the delayed "unlock" message tothe door, a very serious attack.¶

Client   Foe   Server   |      |      |   +----->@      |      Code: 0.03 (PUT)   | PUT  |      |     Token: 0x9c   |      |      |  Uri-Path: lock   |      |      |   Payload: 0 (Unlock)   |      |      |   +------------>|      Code: 0.03 (PUT)   | PUT  |      |     Token: 0x9c   |      |      |  Uri-Path: lock   |      |      |   Payload: 0 (Unlock)   |      |      |   <-------------+      Code: 2.04 (Changed)   |      | 2.04 |     Token: 0x9c   |      |      |     ....   ....   |      |      |   +------------>|      Code: 0.03 (PUT)   | PUT  |      |     Token: 0x7a   |      |      |  Uri-Path: lock   |      |      |   Payload: 1 (Lock)   |      |      |   <-------------+      Code: 2.04 (Changed)   |      | 2.04 |     Token: 0x7a   |      |      |   |      @----->|      Code: 0.03 (PUT)   |      | PUT  |     Token: 0x9c   |      |      |  Uri-Path: lock   |      |      |   Payload: 0 (Unlock)   |      |      |   |      X<-----+      Code: 2.04 (Changed)   |      | 2.04 |     Token: 0x9c   |      |      |

While the second attack (Figure 4) can be mitigated byusing a replay window of length zero, the first attack (Figure 3)cannot. A solution must enable the server to verify that the requestwas received within a certain time frame after it was sent or enablethe server to securely determine an absolute point in time when therequest is to be executed. This can be accomplished with either achallenge-response pattern, by exchanging timestamps between clientand server, or by only allowing requests a short period after clientauthentication.¶

Requiring a fresh client authentication (such as a new TLS/DTLS handshakeor an EDHOC key exchange[I-D.ietf-lake-edhoc]) mitigates theproblem, but requires larger messages and more processingthan a dedicated solution. Security solutions based on exchanging timestampsrequire exactly synchronized time between client and server, and this maybe hard to control with complications such as time zones and daylight saving.Wall clock time SHOULD NOT be used as it is not monotonic, may reveal thatthe endpoints will accept expired certificates, or reveal the endpoint'slocation. Use of non-monotonic clocks is not secure as the server will acceptrequests if the clock is moved backward and reject requests if the clockis moved forward. Even if the clocks are synchronized at one point in time,they may easily get out-of-sync and an attacker may even be able to affectthe client or the server time in various ways such as setting up a fake NTPserver, broadcasting false time signals to radio controlled clocks, or exposeone of them to a strong gravity field. As soon as client falsely believesit is time synchronized with the server, delay attacks are possible. A challengeresponse mechanism where the server does not need to synchronize its timewith the client is easier to analyze but require more roundtrips. The challenges,responses, and timestamps may be sent in a CoAP option or in the CoAP payload.¶

Remedy: The mechanisms specified in[I-D.ietf-core-echo-request-tag]or[I-D.liu-core-coap-delay-attacks] SHALL be used for controllingactuators unless another application specificchallenge-response or timestamp mechanism is used.¶

2.3.The Response Delay and Mismatch Attack

The following attack can be performed if CoAP is protected by a securityprotocol where the response is not bound to the request in any way exceptby the CoAP token. This would include most general security protocols, suchas DTLS, TLS, and IPsec, but not OSCORE. CoAP[RFC7252] uses aclient generated token that the server echoes to match responses torequest, but does not give any guidelines for the use of token with DTLSand TLS, except that the tokens currently "in use" SHOULD (not SHALL) beunique. The attacker performs the attack by delaying delivery of a responseuntil the client sends a request with the same token, the response will beaccepted by the client as a valid response to the later request. If CoAPis used over a reliable and ordered transport such as TCP with TLS, no messagescan be delivered before the delayed message. If CoAP is used over an unreliableand unordered transport such as UDP with DTLS, other messages can be deliveredbefore the delayed message as long as the delayed packet is delivered insidethe replay window. Note that mismatches can also happen for other reasonsthan a malicious attacker, e.g. delayed delivery or a server sending notificationsto an uninterested client.¶

The attack can be performed by an attacker on the wire, or an attacker simultaneouslyrecording what the server transmits while at the same time jamming the client.The response delay and mismatch attack is illustrated inFigure 5.¶

Client   Foe   Server   |      |      |   +------------>|      Code: 0.03 (PUT)   | PUT  |      |     Token: 0x77   |      |      |  Uri-Path: lock   |      |      |   Payload: 0 (Unlock)   |      |      |   |      @<-----+      Code: 2.04 (Changed)   |      | 2.04 |     Token: 0x77   |      |      |     ....   ....   |      |      |   +----->X      |      Code: 0.03 (PUT)   | PUT  |      |     Token: 0x77   |      |      |  Uri-Path: lock   |      |      |   Payload: 0 (Lock)   |      |      |   <------@      |      Code: 2.04 (Changed)   | 2.04 |      |     Token: 0x77   |      |      |

If we once again take a lock as an example, the security consequences maybe severe as the client receives a response message likely to be interpretedas confirmation of a locked door, while the received response message isin fact confirming an earlier unlock of the door. As the client is likelyto leave the (believed to be locked) door unattended, the attacker may enterthe home, enterprise, or car protected by the lock.¶

The same attack may be performed on sensors, also this with serious consequences.As illustrated inFigure 6, an attacker may convince the clientthat the lock is locked, when it in fact is not. The "Unlock" requestmay be also be sent by another client authorized to control the lock.¶

Client   Foe   Server   |      |      |   +------------>|      Code: 0.01 (GET)   | GET  |      |     Token: 0x77   |      |      |  Uri-Path: lock   |      |      |   |      @<-----+      Code: 2.05 (Content)   |      | 2.05 |     Token: 0x77   |      |      |   Payload: 1 (Locked)   |      |      |   +------------>|      Code: 0.03 (PUT)   | PUT  |      |     Token: 0x34   |      |      |  Uri-Path: lock   |      |      |   Payload: 1 (Unlock)   |      |      |   |      X<-----+      Code: 2.04 (Changed)   |      | 2.04 |     Token: 0x34   |      |      |   +----->X      |      Code: 0.01 (GET)   | GET  |      |     Token: 0x77   |      |      |  Uri-Path: lock   |      |      |   <------@      |      Code: 2.05 (Content)   | 2.05 |      |     Token: 0x77   |      |      |   Payload: 1 (Locked)   |      |      |

As illustrated inFigure 7, an attacker may even mixresponses from different resources as long as the two resources sharethe same (D)TLS connection on some part of the path towards theclient. This can happen if the resources are located behind a commongateway, or are served by the same CoAP proxy. An on-path attacker(not necessarily a (D)TLS endpoint such as a proxy) may e.g. deceive aclient that the living room is on fire by responding with an earlierdelayed response from the oven (temperatures in degree Celsius).¶

Client   Foe   Server   |      |      |   +------------>|      Code: 0.01 (GET)   | GET  |      |     Token: 0x77   |      |      |  Uri-Path: oven/temperature   |      |      |   |      @<-----+      Code: 2.05 (Content)   |      | 2.05 |     Token: 0x77   |      |      |   Payload: 225   |      |      |     ....   ....   |      |      |   +----->X      |      Code: 0.01 (GET)   | GET  |      |     Token: 0x77   |      |      |  Uri-Path: livingroom/temperature   |      |      |   <------@      |      Code: 2.05 (Content)   | 2.05 |      |     Token: 0x77   |      |      |   Payload: 225   |      |      |

Remedy: If CoAP is protected with a security protocol not providing bindingsbetween requests and responses (e.g. DTLS and TLS) the client MUST NOT reuseany tokens until the traffic keys have been replaced. The easiest way toaccomplish this is to implement the Token as a counter, this approach SHOULDbe followed.¶

2.4.The Relay Attack

Yet another type of attack can be performed in deployments where actuatoractions are triggered automatically based on proximity and without any userinteraction, e.g. a car (the client) constantly polling for the car key (theserver) and unlocking both doors and engine as soon as the car key responds.An attacker (or pair of attackers) may simply relay the CoAP messages out-of-band,using for examples some other radio technology. By doing this, the actuator(i.e. the car) believes that the client is close by and performs actionsbased on that false assumption. The attack is illustrated inFigure 8. In this example the car is using an application specificchallenge-response mechanism transferred as CoAP payloads.¶

Client   Foe         Foe   Server   |      |           |      |   +----->| ......... +----->|      Code: 0.02 (POST)   | POST |           | POST |     Token: 0x3a   |      |           |      |  Uri-Path: lock   |      |           |      |   Payload: JwePR2iCe8b0ux (Challenge)   |      |           |      |   |<-----+ ......... |<-----+      Code: 2.04 (Changed)   | 2.04 |           | 2.04 |     Token: 0x3a   |      |           |      |   Payload: RM8i13G8D5vfXK (Response)   |      |           |      |

The consequences may be severe, and in the case of a car, lead to the attackerunlocking and driving away with the car, an attack that unfortunately ishappening in practice.¶

Remedy: Getting a response over a short-range radio MUST NOT be taken asproof of proximity and therefore MUST NOT be used to take actions based onsuch proximity. Any automatically triggered mechanisms relying on proximityMUST use other stronger mechanisms to guarantee proximity. Mechanisms thatMAY be used are: measuring the round-trip time and calculate the maximumpossible distance based on the speed of light, or using radio with an extremelyshort range like NFC (centimeters instead of meters) that cannot be relayedthrough e.g. clothes. Another option is to including geographical coordinates(from e.g. GPS) in the messages and calculate proximity based on these, butin this case the location measurements MUST be very precise and the systemMUST make sure that an attacker cannot influence the location estimation,something that is very hard in practice.¶

2.5.The Request Fragment Rearrangement Attack

These attack scenarios show that the Request Delay and Block Attacks canbeused against blockwise transfers to cause unauthorized operations to beperformed on the server, and responses to unauthorized operations to bemistaken for responses to authorized operations.The combination of these attacks is described as a separate attack becauseit makes the Request Delay Attackrelevant to systems that are otherwise not time-dependent, which means thatthey could disregard the Request Delay Attack.¶

This attack works even if the individual request/response pairs are encrypted,authenticated and protected against the Response Delay and Mismatch Attack,provided the attacker is on the network path and can correctly guess whichoperations the respective packages belong to.¶

Client   Foe   Server   |      |      |   +------------->    POST "incarcerate" (Block1: 0, more to come)   |      |      |   <-------------+    2.31 Continue (Block1: 0 received, send more)   |      |      |   +----->@      |    POST "valjean" (Block1: 1, last block)   |      |      |   +----->X      |    All retransmissions dropped   |      |      |(Client: Odd, but let's go on and promote Javert)   |      |      |   +------------->    POST "promote" (Block1: 0, more to come)   |      |      |   |      X<-----+    2.31 Continue (Block1: 0 received, send more)   |      |      |   |      @------>    POST "valjean" (Block1: 1, last block)   |      |      |   |      X<-----+    2.04 Valjean Promoted   |      |      |

Client   Foe   Server   |      |      |   +----->@      |    POST "Homeless stole apples. Wh"   |      |      |        (Block1: 0, more to come)(Client: We'll try that one later again; for now, we have somethingmore urgent:)   |      |      |   +------------->    POST "Hitman killed someone. Wh"   |      |      |        (Block1: 0, more to come)   |      |      |   |      @<-----+    2.31 Continue (Block1: 0 received, send more)   |      |      |   |      @------>    POST "Homeless stole apples. Wh"   |      |      |        (Block1: 0, more to come)   |      |      |   |      X<-----+    2.31 Continue (Block1: 0 received, send more)   |      |      |   <------@      |    2.31 Continue (Block1: 0 received, send more)   |      |      |   +------------->    POST "at shall we do with him?"   |      |      |        (Block1: 1, last block)   |      |      |   <-------------+    2.05 "Set him free."   |      |      |        (Block1: 1 received and this is the result)

3.1.Denial-of-Service Attacks

In a Denial-of-Service (DoS) attack, an attacker sends a large number of requestsor responses to a target endpoint. The denial-of-service might be caused bythe target endpoint receiving a large amount of data, sending a large amountof data, doing heavy processing, or using too much memory, etc. In a DistributedDenial-of-Service (DDoS) attack, the request or responses come from a largenumber of sources.¶

In an amplification attack, the amplification factor is the ratio between thetotal size of the data sent to the target and the total size of the datasent by the attacker. In the attacks described in this section, theattacker sends one or more requests, and the target receives one or moreresponses. An amplification attack alone can be a denial-of-service attack on a server,but often amplification attacks are combined with the attacker spoofing thesource IP address of the targeted victim. By requesting as much informationas possible from several servers an attacker can multiply the amount oftraffic and create a distributed denial-of-service attack on the target.When transported over UDP, the CoAP NoSecmode is susceptible to source IP address spoofing.¶

Amplification attacks with CoAP is unfortunately not only theory, amplificationfactors of 10-100 are commonly reported from NoSec deployments.[CoAP-Report] and[CoAP-Wild] report average amplification factors of 27 and 34 respectivelyfrom a single response to a GET request for /.well-known/core to the default UDP port 5683.NoSec CoAP servers accessible over the Internet are mostly concentrated to a few countriesand a few implementations, which do not follow the recommendations in Section11.3 of[RFC7252] (but the requirements are a bit soft).¶

An amplification attack using a single response is illustrated inFigure 11.If the response is c times larger than the request, the amplification factor is c.¶

Client   Foe   Server   |      |      |   |      +----->|      Code: 0.01 (GET)   |      | GET  |  Uri-Path: random quote   |      |      |   |<------------+      Code: 2.05 (Content)   |      | 2.05 |   Payload: "just because you own half the county   |      |      |             doesn't mean that you have the power   |      |      |             to run the rest of us. For twenty-   |      |      |             three years, I've been dying to tell   |      |      |             you what I thought of you! And now...   |      |      |             well, being a Christian woman, I can't   |      |      |             say it!"

An attacker can increase the bandwidth by sending several GET requests. An attacker canalso increase or control the amplification factor by creating or updating resources.By creating new resources, an attacker can increase the size of /.well-known/core. An amplification attack where the attacker influences the amplification factoris illustrated inFigure 12.¶

Client   Foe   Server   |      |      |   |      +----->|      Code: 0.02 (POST)   |      | POST |  Uri-Path: /member/   |      |      |   Payload: hampsterdance.hevc   |      |      |     ....   ....   |      +----->|      Code: 0.02 (GET)   |      | GET  |  Uri-Path: /member/   |      |      |   |<------------+      Code: 2.05 (Content)   |      | 2.05 |   Payload: hampsterdance.hevc   |      |      |   |      +----->|      Code: 0.02 (GET)   |      | GET  |  Uri-Path: /member/   |      |      |   |<------------+      Code: 2.05 (Content)   |      | 2.05 |   Payload: hampsterdance.hevc     ....   ....

Amplification factors can be significantly worse when combined withobserve[RFC7641] and group requests[I-D.ietf-core-groupcomm-bis]. As a singlerequest can result in multiple responses from multiple servers, the amplificationfactors can be very large.¶

An amplification attack using observe is illustrated inFigure 13. If each notification response is c times larger than the registrationrequest and each request results in n notifications, the amplification factor is c * n. By registering the same client several times using different Tokens or port numbers,the bandwidth can be increased. By updating the observed resource, the attackermay trigger notifications and increase the size of the notifications. By usingconditional attributes[I-D.ietf-core-conditional-attributes] an attacker may increase the frequency ofnotifications and therefore the amplification factor. The maximum period attribute pmaxindicates the maximum time, in seconds, between two consecutive notifications (whether or not theresource state has changed). If it is predictable when notificationsare sent as confirmable and which Message ID are used the acknowledgements may be spoofed.¶

Client   Foe   Server   |      |      |   |      +----->|      Code: 0.01 (GET)   |      | GET  |     Token: 0x83   |      |      |   Observe: 0   |      |      |  Uri-Path: temperature   |      |      |  Uri-Query: pmax="0.1"   |      |      |   |      +----->|      Code: 0.01 (GET)   |      | GET  |     Token: 0x84   |      |      |   Observe: 0   |      |      |  Uri-Path: temperature   |      |      |  Uri-Query: pmax="0.1"   |      |      |     ....   ....   |<------------+      Code: 2.05 (Content)   |      | 2.05 |     Token: 0x83   |      |      |   Observe: 217362   |      |      |   Payload: "299.7 K"   |      |      |   |<------------+      Code: 2.05 (Content)   |      | 2.05 |     Token: 0x84   |      |      |   Observe: 217362   |      |      |   Payload: "299.7 K"   |      |      |     ....   ....   |<------------+      Code: 2.05 (Content)   |      | 2.05 |     Token: 0x83   |      |      |   Observe: 217363   |      |      |   Payload: "299.7 K"   |      |      |   |<------------+      Code: 2.05 (Content)   |      | 2.05 |     Token: 0x84   |      |      |   Observe: 217363   |      |      |   Payload: "299.7 K"     ....   ....

An amplification attack using a group request is illustrated inFigure 14. The group request is sent over multicast or broadcastand in this case a single request results in m responsesfrom m different servers. If each response is c times larger than the request,the amplification factor is c * m. Note that the servers usually do not knowthe variable m.¶

Client   Foe   Server   |      |      |   |      +----->|      Code: 0.01 (GET)   |      | GET  |     Token: 0x69   |      |      |  Uri-Path: </c>   |      |      |   |<------------+      Code: 2.05 (Content)   |      | 2.05 |     Token: 0x69   |      |      |   Payload: { 1721 : { ...   |      |      |   |<------------+      Code: 2.05 (Content)   |      | 2.05 |     Token: 0x69   |      |      |   Payload: { 1721 : { ...   |      |      |     ....   ....

An amplification attack using a multicast request and observe isillustrated inFigure 15. In this case a single request resultsin n responses each from m different servers giving a total of n * mresponses. If each response is c times larger than the request,the amplification factor is c * n * m.¶

Client   Foe   Server   |      |      |   |      +----->|      Code: 0.01 (GET)   |      | GET  |     Token: 0x44   |      |      |   Observe: 0   |      |      |  Uri-Path: temperature   |      |      |  Uri-Query: pmax="0.1"   |      |      |   |<------------+      Code: 2.05 (Content)   |      | 2.05 |     Token: 0x44   |      |      |   Observe: 217   |      |      |   Payload: "301.2 K"   |      |      |   |<------------+      Code: 2.05 (Content)   |      | 2.05 |     Token: 0x44   |      |      |   Observe: 363   |      |      |   Payload: "293.4 K"   |      |      |     ....   ....   |<------------+      Code: 2.05 (Content)   |      | 2.05 |     Token: 0x44   |      |      |   Observe: 218   |      |      |   Payload: "301.2 K"   |      |      |   |<------------+      Code: 2.05 (Content)   |      | 2.05 |     Token: 0x44   |      |      |   Observe: 364   |      |      |   Payload: "293.4 K"   |      |      |     ....   ....

While CoAP has always considered amplification attacks, the recommendationsin[RFC7252],[RFC7641], and[I-D.ietf-core-groupcomm-bis] are a bit soft.Most of the requirements are "SHOULD" instead of "MUST", it is undefined what a"large amplification factor" is,[RFC7641] does not specify how many notificationsthat can be sent before a potentially spoofable acknowledgement must be sent, andin several cases the "SHOULD" level is further softened by "If possible" and "generally".[I-D.ietf-core-conditional-attributes] does not have any amplification attack considerations.¶

QUIC[RFC9000] mandates that "an endpoint MUST limit the amount of data it sends to the unvalidated address to three times the amount of data received from that address" without any exceptions. This approach should be seen as current best practice.¶

In CoAP, an address can be validated with a security protocol like DTLS, TLS, OSCORE, or by using the Echo Option[I-D.ietf-core-echo-request-tag]. Restricting the bandwidth per server is not enough as the number of servers the attacker can use is typically unknown. For multicast requests, anti-amplification limits and the Echo Option do not really work unless the number of servers sending responses is known. Even if the responses have the same size as the request, the amplification factor from m servers is m, where m is typically unknown. While DoS attacks from CoAP servers accessible over the Internet pose the largest threat, an attacker on a local network might use local CoAP servers to attack targets on the Internet or on the local network.¶

Remedy:[RFC7252] should be updated with a strict normative requirement (MUST) on implementations similar to QUIC with a specified anti-amplification limit and no exceptions. It should be clear that any devices used in DDoS attacks are violating IETF requirements.¶