Change:
populating DNS records; preferred addresses (preferred-address), where a server is able to <del> choose where a client sends datagrams; and </del> <ins> choose where a client sends datagrams; </ins> spoofed connection migrations (address-spoofing), where a client is able to use source address spoofing to select where a server <del> sends subsequent datagrams. </del> <ins> sends subsequent datagrams; and </ins> <del> In all three cases, the attacker can cause its peer to send datagrams to a victim that might not understand QUIC.  That is, these packets are sent by the peer prior to address validation; see address- validation. </del> <ins> spoofed packets that cause a server to send a Version Negotiation packet vn-spoofing. In all cases, the attacker can cause its peer to send datagrams to a victim that might not understand QUIC.  That is, these packets are sent by the peer prior to address validation; see address-validation. </ins> Outside of the encrypted portion of packets, QUIC offers an endpoint several options for controlling the content of UDP datagrams that its

Discussion:
It's pretty bad. Personally, I'm still comfortable with it. Server deployments are far less likely to made without due consideration to the environment into which they find themselves.
... unless you start considering p2p deployments.
Fair point; though I would suggest that p2p doesn't need version negotiation. Once you have to do NAT traversal, you can also ensure that you don't have to ever send Version Negotiation.
I don't think that works in the general case. A node won't know if it's behind a NAT when it's started (it will learn after a while of interacting with other nodes). And even if you solve that problem, you'll need to do some extra work to communicate QUIC versions during hole punching.
The version negotiation packet is described in the QUIC Invariant specification as: The two connection ID fields, of length up to 255 bytes, contain data directly copied from an incoming packet that is not authenticated or verified in any way. Aren't we worried that this is a great avenue for request forgery attacks? Should that be documented in the security section of the invariant draft?
NAME trying to move discussion here. You suggest that in a p2p deployment, the ability to control deployment of "server" instances is limited. My response is that in general you need some sort of signaling between peers to communicate addresses for p2p. NAT traversal generally requires it, and - if nothing else - you usually need to ship IP addresses for peers around. Given that, I think that it is reasonable to include - in that signaling - information about supported protocols such that you should never need to generate a QUIC Version Negotiation in that context. Maybe you don't care for that, but I think that it is probably better than accepting the exposure. If you have an idea for how we might avoid this particular sort of request forgery without that, then I'm open to suggestions. Right now, the proposal is that servers accept the risk and manage it. But if there is a protocol change that would improve the situation, that might be better. Assuming that it is minimally disruptive, of course.
This independent of NAT traversal then. You'd also need to advertise addresses in a world where NATs wouldn't exist, and you could include QUIC version information in those address advertisements.

This still leaves the Bootstrap nodes susceptible to this attack (assuming you only hard-code a list of IP:ports without QUIC version information), but maybe that's ok, since you typically control those nodes yourself, or at least you can ask people running those nodes to take precautionary steps.
I agree that documenting the issue is the best we can do at this stage of the process. Short of ditching version negotiation altogether, but that would mean a long delay in delivering QUIC V1, and I don't think we want to go there.Ugh. Yeah, this isn't great. I agree that we can lean on servers... but documenting this is super important. This is a pretty big hole... but I think it's ok to leave it as it is in this PR. Let's leave this open for a while longer to ensure that it gets more visibility, and to see if anyone can come up with any other ideas.