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

Commentary: I take as a mandate to make Echo mitigation of amplification issues a more prominent point in ERT . ( It was n'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 ) .
Mailing list commentary: In draft - ietf - core - echo - request - tag- , 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 , 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 do n’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 . ,
Paragraph (version A):
This document specifies enhancements to the Constrained Application
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
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.
Paragraph (version B):
This document specifies enhancements to the Constrained Application
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
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.
Paragraph (version B):
This document updates RFC7252 with a recommendation that servers use
the Echo option to mitigate amplification attacks.
Paragraph (version A):
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
address in the source address of a CoAP request).  For this
purpose, a server MAY 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.
Paragraph (version B):
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
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.
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 MAY use Echo to verify origin reachability as
described in echo-proc.  The proxy MAY forward idempotent
requests immediately to have a cached result available when the
client's Echoed request arrives.
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 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 idempotent
requests immediately to have a cached result available when the
client's Echoed request arrives.
Paragraph (version B):
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.
Paragraph (version B):
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).