Move amplification and 0RTT topic in from issue tracker

This is a copy of core-wg#39 (comment)

draft-bormann-core-corr-clar.md

@@ -488,6 +488,39 @@ 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}
+
+Established security contexts and established return addresses can become obsolete.
+For example, this happens when a DTLS session is resumed 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 and amplification mitigation properties,
+which are generally independent but can be addressed using the same tools.
+
+A safe option is always to reject the initial request and request confirmation,
+either 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)
+or by using a more security mechanism specific tool such as RRC ({{?I-D.ietf-tls-dtls-rrc}}.
+
+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.
+
+If it is not certain that the request is not a replay,
+but the request handler is safe or long-term idempotent
+and there is no risk of metadata revealing data,
+the server can answer the request.
+Metadata that can reveal data are the size of the response
+(which, in a replay situation, can give an active attacker additional data)
+as well as any processing delays.
+(There should be no observable side effects for safe or previously processed idempotent requests).
+Assessing whether a resource is long-term idempotent is not always trivial, and it is prudent to err at the side of caution.
+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.
+
+Implementors of OSCORE beware answering potential replays is only safe from the CoAP application's point of view.
+As always, unless the sender sequence number of the request has just been removed from a correctly initialized replay window,
+the response can not reuse the request's nonce, but needs to take an own sequence number from the server's space.
 
 ## RFC 7252-12.3: Content-Format Registry {#ct}