an address can be validated with a security protocol like DTLS, TLS, OSCORE,

[emanjon]

I think this is only true for TLS and DTLS without connection ID

• OSCORE just sends the response back to where the request came from. In the case of a new address Echo needs to be used. This could likely be missed by implementations.
• The connection ID draft states that some mechanism need to used when the addess change.

I will update the text and likely make a figure.

[boaks]

Let me add, that the "address validation" has different aspects.

Using (upcoming) RFC9146 the source identity of the peer (given by the cid) is verified by the MAC. What is not (longer) verified is the source ip-address. So the uncertainness here is not about the received data, it's about the source ip-address to send back data. If some data is sent back (encrypted), it's doesn't introduce a new leaking risk. What is added as risk is the possibility of being misused for an amplification attack. In difference to the more common proactive DDoS threats (attacker is able to initiate sending records with manipulated source addresses), this one is a passive one (attacker needs to wait for a valid record and then manipulates the source address). If such a passive attack is really reasonable for DDoS, may be discussed. That depends also on the usage of DTLS CID by a next layer. E.g. with CoAP / NSTART-1, I'm not sure, if enough records are send out to be manipulated and if the responses are large enough to offer amplification. And sometimes implementing protection as RRC or draft-ietf-core-echo-request-tag seems to have the smaller effort than such a discussion.

[emanjon]

Please continue discussion at https://github.com/t2trg/t2trg-amplification-attacks/issues/6

(Due to lack of owner rights I could not transfer this repository and instead had to make a new one, I will manually create new issues there for any open issues).