Original text:
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).  The RECOMMENDED way to do this is to ask a client to Echo its request to verify 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. For this application, the Echo option can be used in messages that are not integrity protected, for example during discovery. </del>  In the presence of a proxy, a server will not be able to distinguish different origin client endpoints.  Following from deployment with hop-by-hop security and proxies, the server can only verify aliveness of the closest proxy.  3. 3.1.

Reviewer comments:
I think it make sense to make a subsection
This is only mentioned in Abstract and intro. I think it need there needs to be some text in the body as well. The other Update has it's own subsection. "4.2. Updated Token Processing Requirements for Clients"
I added text on server requirements in
updated with one more commit: Shorten amplification-mitigateion-recommendation paragraph, align text The "RECOMMENDED" wording is removed from the description of the mechanism (it was under-explained there, the new section does it right, and there's no need to make readers wonder about updating at this point) Reference updated simplified (we're already talking about server side in the paragraph) Comment about moving text here removed, and replaced with a more precise reference I've toyed with moved text, but it rips the use cases up to the point where we'd have to re-do all the items as subsections for consistency. ... and merging (comments still appreciated, but I need the branches consolidated for futher editing)
(... and that comment should have gone to ... anyway)
Some reformulations in febc426. I think this is ready to close.
Has long been ready, and recently gotten a more explicit cross-reference too.

Revised text:
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).  A new way to do this is to ask a client to Echo its request to verify 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.  For this application, the Echo option can be used in messages that are not integrity protected, for example during discovery. </ins> In the presence of a proxy, a server will not be able to distinguish different origin client endpoints.  Following from deployment with hop-by-hop security and proxies, the server can only verify aliveness of the closest proxy. <ins> 2.5. This section updates the amplification mitigation requirements for servers in RFC7252 to recommend use of the Echo option to mitigate amplification attacks.  The requirements for clients are not updated. Section 11.3 of RFC7252 is updated by adding the following text: A CoAP server SHOULD mitigate potential amplification attacks by responding to unauthenticated clients with 4.01 Unauthorized including an Echo option, as described in echo-app item 3 of [[this document]]. </ins> 3. 3.1.