Hi Martin,
Nothing here depends on using a CID, except perhaps to the extent that the endpoint that observes the "migration" needs to be able to match incoming records with connection state. If they need a CID for that, then this needs a CID.
If the threat is only weakly related to the use of a CID, would then the discussion of that more general threats not require also a more general scope than that of this DTLS CID RFC?
5. Victim believes that the connection has migrated and stops sending on the old path. If the new address is attacker controlled, the attacker is now on-path. The attacker can stop forwarding and deny service at its discretion.
For a "service deny" no attacker is needed :-), UDP traffic may be lost, DTLS traffic may be ignored, and overloaded peers may response out of the expected time-frame. Most of that is in my opinion the general risk using something as the "public internet" with its grants and no-grants. In all cases of a "service-deny", the peer was, and with CID, is still, intended to try a reconnect strategy (what ever that means according the destination ip-address.) In my sum: - without CID, much more (resumption) handshakes are needed in order to communicate using DTLS. - with CID, such (resumption) handshakes are still required, but much less. Your attack adds some more handshakes, but it doesn't introduce something new, nor do I see, that this will exceed the number of handshakes without CID. best regards Achim Kraus _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
