Retry service handling of non-Initial about load-balancers HOT 4 CLOSED

I don't know. Do you have a case where Retry services should not forward those packets? I don't want this to be a source of ossification because of a possibly incorrect assumption about placement of the retry service in the pipeline.

from load-balancers.

Well, the reason to not forward them is to block DDoS vectors. A garbage Handshake or 1-RTT packets is at least easily discarded by the server without much in the way of processing. I would actually appreciate some input from your Azure contacts about this; is filtering non-SYN packets important today?

from load-balancers.

Here's the data I can provide: As I understand it, the DDoS would be in front of the LB. It's all in hardware so it's update cycle could be very long, so any logic added there could effectively be written in stone for many years. So, I really want to be careful about any assumptions here. If we get it wrong for a future version, either all of Azure might end up breaking/preventing future versions/features or we'd have to completely disable and lose the protection.

On the topic of dropping garbage/invalid packets, I'd be Ok with that. Perhaps we could change the text to the following?

Retry services MUST forward all valid QUIC packets that are not of type Initial or 0-RTT. Other packet types might involve changed IP addresses or connection IDs, so it is not practical for Retry Services to identify such packets as valid or invalid.

This adds some wiggle room for what is considered "valid" or not. Obviously if the header is garbage it can be tossed. If a device knows a particular CID is invalid, then it could drop it. I'd just strongly caution any "smarts" here because of the possibility of changes in the future.

from load-balancers.

If "in front of the LB" is cancnical use case, I can shade the language towards that.

However, this makes me wonder about the shared-state case. My perception is that combining a NAT with an LB is quite common; will shared token verification work if the server and retry service are seeing different client IP addresses? This calls into question the entire shared-state concept.

from load-balancers.