Automatic Retry heuristics

[Ralith]

QUIC's Retry mechanism is (primarily) a defense against resource exhaustion attacks by forcing peers to prove that they can receive packets sent to their address before allocating connection state. It is not the default mode because it costs an additional round-trip of latency. Quinn currently requires Retry only at the application's explicit request, but applications are unlikely to make effective use of this in practice. To provide more robustness by default, we should automatically enable Retry whenever the number of incoming connections whose address has not yet been validated is above some (proportionate?) threshold.

[Ralith]

Luke Curley of quicdev argues that enabling Retry is only useful if some mechanism exists to block malicious IPs, because an attacker can just as well use their real IP(s). A more general solution might therefore be to provide an API that allows the application to accept/reject/require retry on a connection before the handshake begins. This might not be of much use outside of the most advanced users, but at least it will be effective for them. Maybe we could plug in a simple fail2ban-style mechanism by default.

[djc]

A more general solution might therefore be to provide an API that allows the application to accept/reject/require retry on a connection before the handshake begins. This might not be of much use outside of the most advanced users, but at least it will be effective for them.

Sounds good to me!

[gretchenfrage]

I am working on this :) once I have more of a working prototype made I will ask for feedback on API design in the Matrix server.