Amplification and 0-RTT

draft-ietf-core-corr-clar.md

@@ -488,6 +488,64 @@ issue include:
 * <https://github.com/core-wg/corrclar/issues/9>\\
 ("Clarify/revise language around epochs in section 9.1.1 #9")
 
+## RFC 7252-9.1/11.3: Handling outdated addresses and security contexts {#amp-0rtt}
+
+INCOMPLETE:
+: Tools for mitigating these scenarios were unavailable when specified, and are now explained.
+
+PENDING.
+
+Established security contexts and established return addresses can become obsolete.
+For example, this happens when a DTLS session is continued via CIDs, when the client's IP address changes, or when the replay window of an OSCORE context is lost and recovered through the mechanism of [Appendix B.1.2 of RFC8613].
+In those situations, a server still needs to maintain its security and amplification mitigation properties,
+which are generally independent concerns but can be addressed using the same tools.
+
+A safe option is always to reject the initial request and request confirmation.
+The RECOMMENDED way to do that is using CoAP's mechanism of sending a 4.01 (Unauthorized) response with an Echo option
+(where a subsequent request with the same Echo value proves to the server that the destination was reachable);
+clients SHOULD act to the Echo option as specified in {{?RFC9175}}.
+Tools specific to a security protocol, such as RRC ({{?I-D.ietf-tls-dtls-rrc}}) in case of DTLS, may be used. However, their use may depend on successful negotiation.
+
+### Amplification mitigation and return routability
+
+If it is not certain that the client is reachable on the request's sender address,
+but the response does not exceed the request's size by a factor of 3 ({{Section 2.4 of RFC9175}}, item 3),
+the server can answer the request.
+It should still include an Echo value, whose presence in the next request serves to confirm the client's address.
+
+This situation can happen at any time, especially after a prolonged period of quiescence, regardless of the security protocol.
+
+Verifying the client's address is not only crucial for mitigating amplification attacks ({{?I-D.irtf-t2trg-amplification-attacks}}), but also to avoid traffic misdirection.
+{{Section 7 of ?I-D.ietf-tls-dtls-rrc}} describes options for how to use RRC messages to distinguish different cases.
+A 4.01 response with Echo can perform some of the same functions, with the Echo value replacing the RRC cookie. However, it does not offer a way to distinguish between non-preferred and preferred paths.
+
+Where that distinction matters,
+RRC provides the right tools to make it.
+
+### Replay protection
+
+If it is not certain that the request is not a replay,
+but the request handler is safe
+and there is no risk of metadata revealing data,
+the server can answer the request.
+Kinds of metadata to look out for are the size of the response
+(which, in a replay situation, can give an active attacker additional data)
+as well as any processing delays.
+(Side effects would also fall into that category, but there should not be any effects for safe requests).
+
+If nothing else, GET requests to constant resources,
+such as queries to /.well-known/core,
+can often be responded to safely on the CoAP layer even without any replay protection.
+
+There are resources for which more requests than those with safe codes may be handled without replay protection,
+but as that assessment is hard to make, it is prudent to err at the side of caution.
+
+Uncertainty about whether a request might be a replay can happen in OSCORE after a partial loss of context.
+Currently, this cannot happen in DTLS because 0-RTT Data is not allowed for CoAP (cf. {{Section 14 of ?I-D.ietf-uta-tls13-iot-profile-09}}). However, that may change if a future document defines a profile for using early data with CoAP.
+
+Implementers of OSCORE should be aware that answering potential replays is only safe from the CoAP application's point of view.
+As always, unless the sequence number in the request has just been removed from an initialized replay window,
+the response can not reuse the request's nonce, but needs to be sent with a new sequence number from the server's space.
 
 ## RFC 7252-12.3: Content-Format Registry {#ct}