Draft: draft-ietf-quic-transport

Commentary: 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 does n't need version negotiation . Once you have to do NAT traversal , you can also ensure that you do n't have to ever send Version Negotiation . 
 I do n't think that works in the general case . A node wo n'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 . Are n'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 ? 
 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 do n'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 would n'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 do n't think we want to go there . Ugh . Yeah , this is n'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 .
Paragraph (version A):
spoofed connection migrations (address-spoofing), where a client
is able to use source address spoofing to select where a server
sends subsequent datagrams.
Paragraph (version A):
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.
Paragraph (version B):
spoofed packets that cause a server to send a Version Negotiation
packet vn-spoofing.
Paragraph (version B):
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.
Paragraph (version B):
Clients that are able to present a spoofed source address on a packet
can cause a server to send a Version Negotiation packet packet-
version to that address.
Paragraph (version B):
The absence of size restrictions on the connection ID fields for
packets of an unknown version increases the amount of data that the
client controls from the resulting datagram.  The first byte of this
packet is not under client control and the next four bytes are zero,
but the client is able to control up to 512 bytes starting from the
fifth byte.
Paragraph (version B):
No specific countermeasures are provided for this attack, though
generic protections forgery-generic could apply.  In this case,
ingress filtering BCP38 is also effective.