Change:
Rewrote the text to talk about amplification factor instead of a single large packet. This also captures the cases where: A single request results in several responses from a single server. A single request results in several responses from a different servers. It also removes the case where both the request and the response are large (which is not an attack).
The current text only talks about large responses, not many responses. "A server that sends large responses to unauthenticated peers SHOULD mitigate amplification attacks"
Any document that allows multiple responses in the first place (Observe, Q-Block, groupcomm-proxy) emphasizes the dangers of unchecked operation -- but it doesn't hurt to do that here too. (We do already say that a single response needs to be piggy-backed or NON, for the same reason).
What should the consideration be - that the freshness of an Observe request MUST be verified with Echo, updating RFC7641? Why is Observe allowed without client authentication? And if so, should not the amplification factor be more precisely limited?
PR addresses this issue

Discussion:
option includes the Echo value in a subsequent unicast request to the responding server. <del> A server that sends a large response to an unauthenticated peer SHOULD mitigate amplification attacks such as described in Section 11.3 of RFC7252 to address, for example, the case where an attacker puts a victim's address in the source address of a CoAP request.  One way to do this is that the server responds to the alleged source address of the request with an Echo option in short response message (e.g. 4.01 Unauthorized), thereby requesting the client to verify its source address.  This needs to be done only once per endpoint 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.  (This is formally recommended in ampl- mit). </del> <ins> An attacker can perform a denial-of-service attack by putting a victim's address in the source address of a CoAP request and sending the request to a resource with a large amplification factor.  The amplification factor is the ratio between the size of the request and the total size of the reponse(s) to that request. A server that provides a large amplification factor to an unauthenticated peer SHOULD mitigate amplification attacks as described in Section 11.3 of RFC7252.  One way to mitigate such attacks is that the server responds to the alleged source address of the request with an Echo option in short response message (e.g. 4.01 Unauthorized), thereby requesting the client to verify its source address.  This needs to be done only once per endpoint 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.  (This is formally recommended in ampl-mit). </ins> In the presence of a proxy, a server will not be able to distinguish different origin client endpoints.  Following from <del> the recommendation above, a proxy that sends large responses to unauthenticated peers SHOULD mitigate amplification attacks. The proxy SHOULD use Echo to verify origin reachability as described in echo-proc.  The proxy MAY forward safe requests immediately to have a cached result available when the client's repeated request arrives. </del> <ins> the recommendation above, a proxy that provides a large amplification factor to unauthenticated peers SHOULD mitigate amplification attacks.  The proxy SHOULD use Echo to verify origin reachability as described in echo-proc.  The proxy MAY forward safe requests immediately to have a cached result available when the client's repeated request arrives. </ins> Amplification mitigation is a trade-off between giving leverage to an attacker and causing overhead.  An amplification factor