Original text:
Protocol (CoAP) that mitigate security issues in particular use cases.  The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its <del> claimed network address.  The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request.  The update to the client Token processing requirements of RFC 7252 forbids non-secure reuse of Tokens to ensure binding of responses to requests when CoAP is used with security. </del>  1. (RFC6347), TLS (RFC8446), or OSCORE (RFC8613), provide the additional security features.  The document also updates the Token processing requirements for clients specified in RFC7252.  The updated processing forbids non- secure reuse of Tokens to ensure binding of responses to requests A server that sends large responses to unauthenticated peers SHOULD mitigate amplification attacks such as described in Section 11.3 of RFC7252 (where an attacker would put a victim's <del> address in the source address of a CoAP request).  For this purpose, a server MAY ask a client to Echo its request to verify </del>  its source address.  This needs to be done only once per peer and limits the range of potential victims from the general Internet to endpoints that have been previously in contact with the server. distinguish different origin client endpoints.  Following from the recommendation above, a proxy that sends large responses to unauthenticated peers SHOULD mitigate amplification attacks. <del> The proxy MAY use Echo to verify origin reachability as </del>  described in echo-proc.  The proxy MAY forward idempotent requests immediately to have a cached result available when the client's Echoed request arrives.  A server may want to use the request freshness provided by the Echo to verify the aliveness of a client.  Note that in a deployment with hop-by-hop security and proxies, the server can

Reviewer comments:
I take URL as a mandate to make Echo mitigation of amplification issues a more prominent point in ERT. (It wasn't intended as an update, as the SHOULD mentioned there is just a copy of the original 7252 SHOULD and we "provide one way", but no objections from me either). Along that I'd offer concrete size numbers, and a note that this really needs piggy-backed responses. Unless objected to, I'd take this into the next version of ERT (as soon as I have processed any other pending comments if there still are any). In draft-ietf-core-echo-request-tag-URL, Section 2.4 item 3 places a SHOULD on a "server that sends large responses to unauthenticated peers” to mitigate the amplification threat using the Echo Option procedure. draft-ietf-core-echo-request-tag already is flagged to update RFC7252, but this is called out in the abstract and introduction only for Token processing. The SHOULD in Section 2.4 item 3 is a bit hidden for my taste. My esteemed co-chair pointed out to me that we don’t really advertise a mitigation for the substantial amplification opportunities posed by those installations that do not translate the discussion in Section 11.3 of RFC 7252 into active behavior. There are now people out there that believe CoAP ranks with DNS and NTP in the DDoS threat generated. Would the CoRE WG be fine with expanding the “updates 7252” text in draft-ietf-core-echo-request-tag to also include recommending this mitigation? If you have a position on this, please reply to the list (or to the chairs) by March 2nd. Grüße, Carsten

Revised text:
Protocol (CoAP) that mitigate security issues in particular use cases.  The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its  <ins> claimed network address; it is now the recommeded way to mitigate amplification attacks.  The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. The update to the client Token processing requirements of RFC 7252 forbids non-secure reuse of Tokens to ensure binding of responses to requests when CoAP is used with security. </ins> 1. (RFC6347), TLS (RFC8446), or OSCORE (RFC8613), provide the additional security features. <ins> This document updates RFC7252 with a recommendation that servers use the Echo option to mitigate amplification attacks. </ins> The document also updates the Token processing requirements for clients specified in RFC7252.  The updated processing forbids non- secure reuse of Tokens to ensure binding of responses to requests A server that sends large responses to unauthenticated peers SHOULD mitigate amplification attacks such as described in Section 11.3 of RFC7252 (where an attacker would put a victim's  <ins> address in the source address of a CoAP request).  The RECOMMENDED way to do this is to ask a client to Echo its request to verify </ins> its source address.  This needs to be done only once per peer and limits the range of potential victims from the general Internet to endpoints that have been previously in contact with the server. distinguish different origin client endpoints.  Following from the recommendation above, a proxy that sends large responses to unauthenticated peers SHOULD mitigate amplification attacks.  <ins> The proxy SHOULD use Echo to verify origin reachability as </ins> described in echo-proc.  The proxy MAY forward idempotent requests immediately to have a cached result available when the client's Echoed request arrives. <ins> Amplification mitigation should be used when the the response would be more than three times the size of the request, considering the complete frame on the wire as it is typically sent across the Internet.  In practice, this allows UDP data of at least 152 Bytes without further checks. When an Echo response is sent to mitigate amplification, it MUST be sent as a piggybacked or non-confirmable response, never as a separate one (which would cause amplification due to retransmission). </ins> A server may want to use the request freshness provided by the Echo to verify the aliveness of a client.  Note that in a deployment with hop-by-hop security and proxies, the server can