Draft: draft-ietf-core-echo-request-tag

Commentary: 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 does n'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
Paragraph (version A):
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).
Paragraph (version A):
In the presence of a proxy, a server will not be able to
distinguish different origin client endpoints.  Following from
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.
Paragraph (version B):
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.
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).
Paragraph (version B):
In the presence of a proxy, a server will not be able to
distinguish different origin client endpoints.  Following from
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.