Draft: draft-ietf-quic-transport

Commentary: This adds a section for a QUIC threat model , filling in only the migration section ( for , some of the rest of the threat model will come in ) . Some wordsmithing can be applied here , and we may want additional issues to fill out detailed descriptions of some of the worst attacks and outline heuristics that might help , but for now I 'm focusing this purely on documenting what 's possible / not possible for an attacker to do today . Addresses . 
 Upcoming change to terminology here as well , just as a note . ( Edit : This is now done ) 
 As commented on the issue , this should as well . 
 Added a few paragraphs describing general active and passive attacks in the context of RFC 3552 and more clearly defined off - path and on - path attackers to follow the definition established by that document . This will likely still take some iteration , but it should be mostly ready for that , comments welcome ! 
 Please take a look , would love your feedback on this ! 
 I just had a quick read , and this looks fine ( maybe there is an option to remove some redundancy but not sure ) . However , I would have expected that this would also talk about likability . Or do we already cover hat somewhere else ? More generally I think it would be helpful to add some text at the beginning to not only define the attackers capabilities but also its intention , so the ( goal of ) the attack itself . 
 Thanks There 's a section , , that discusses linkability and sets out the requirements there . I was n't originally thinking that we wanted to duplicate that in security considerations , but it could be really good to write up some of the guarantees that we think are / n't provided there ( probably in a separate issue , though ) . 
 Anything else we want to do before this is ready to land ? 
 Thanks  , and to all who reviewed ! Definitely agree that further changes can be incremental editorial changes and that it 's much nicer to land the main change . 
 As per comment I 'll note that there is MITM protection in QUIC , but it is not immediate which is roughly why we have the concept of handshake confirmed . 
 The options for triage are close it , mark as editorial , or mark as design . This has a needs - discussion , and I 'm seeing a lack of any discussion . So you might see where my thought process is going ... this relates to your PR on the QUIC threat model . Are you willing to provide some comment that helps us triage the issue ? 
 I think that we can take this as editorial , as it merely requires that we capture already agreed principles ( we do n't protect against an adversary who can inject packets ) . assistance would be useful , but I can produce text if nothing is forthcoming . 
 I can always provide comments , no guarantees on how much they 'll help triage IIRC , this is an issue filed from a comment on the threat model PR that was several - months merged to potentially increase the scope of what that covered . I think that the original threat model that and I put together , covering the handshake and migration respectively , is intended to be the start of that section -- as additional items are discovered that could use coverage there to help clarify QUIC 's stance on whatever issue , they should totally be . I agree with that adding such items seem editorial , as they are n't introducing any new requirements and are only capturing current realities as specified elsewhere . ( Of course , as that text is written , it seems logical that putting it all in words next to each other may highlight issues , and if the WG decides that we do n't like how the current spec results in a particular security stance , we can open a design issue to change normative text elsewhere . ) So , I 'd probably consider this editorial , and ask to potentially contribute some text or clarify what he 's looking to have covered by the original comment -- once that 's clear , happy to help get a PR up if needed ( or text is always good too ! ) . 
 Since this concerns the handshake , I 'm not too confident in contributing text but I 'd be happy to review and discuss . I believe it is correct that the issue is covered in existing text elsewhere but as says , it makes sense to cover it in one place . The risk is that the reader is not aware how important it is to reach a certain point in the connection before trusting data , and especially to those seeking to create derived versions . From various discussions I 'm not sure the importance is broadly understood . Additionally , I 'm not entirely convinced that the current text fully captures the problem - not that we necessarily can - for example various stateless transmissions / redirects / token issues - might assume a level of privacy that does n't exist in all cases , thus requiring stronger integrity elsewhere such as in CIDs , tokens etc .. 
 Thanks folks . It seems we have a path forward , so I 'm removing the needs - discussion label . The editorial process will naturally generate some back and forth but that is the same for all editorial issues . 
 do you have a PR in progress ? 
 Discussed in Montreal , will be a add - on to 
 Editors believe that , which has been merged , addresses this issue . Can we close this issue alongwith ? 
 The proposal here is to do no more than we have already done in . 
 I 've been reading through the migration mechanism and it seems to me that assuming that a packet from a given IP address is evidence of migration creates a pretty easy DoS attack from an on - path attacker . Consider the case where we have a quiescent connection between A and B and an on - path attacker and then B sends a packet to A. In the diagram below , the notation [ A : B ] : Z -means a packet with a source addr of A , a dest addr of B , and a payload of Z As long as A does n't try to send a data packet , B will continue to think that A is at Z for the duration of the validation timer ( currently 3 RTO ? ) [ 0 ] . That 's not the worst thing in the world , but it 's a pretty good cost / benefit for an on - path attacker who only has to forge one packet ; I 'm not sure that that 's a great design tradeoff for a protocol where we 're otherwise trying to stop on - path attacker from interfering with the connection after the handshake completes . The reason this works is the receipt of a packet from addr X is a trigger for abandoning the previous path and trying migration . Another time this can happen is at the tail of a client transmission , though that will presumably recover faster . At a high level , it seems like there are two major types of migration : migration ( e.g. , NAT re - binding ) migration ( e.g. , transferring from WiFi to 3 G ) In the latter case , we can have the client give notice that it 's migrating , even if it does n't know it 's visible IP address , and have the server refuse to change peer addresses unless it sees that indication , so it 's just the former case we have to deal with , and as above . The present design does that but at the cost of creating the situation above . I wonder if we should be more conservative about initiating migration . I do n't have a fully worked out proposal , but here are some ideas : Send packets to both the original and new addresses during the validation period . If you receive an apparent migration that looks like a rebinding ( e.g. , same address , different port ) within X seconds of a previous packet , then probe first ( or in parallel as above ) . Have the client send some packet that indicates it thinks it 's migrating ( this seems tricky to get right ) [ 0 ] Note that if we were to allow migration on the client and the server , even worse attacks are possible . 
 When you say on - path , do you mean observer ? I.e. with the ability to race a packet , or to drop or replace a packet . I suppose a race will not be successful in this attack . So the effectiveness on the attack builds on it being cheaper to confuse the connection rather than to actively drop packets . I 'm not sure that is a strong case for additional complexity . However , a related attack might be used for amplification attacks by changing the IP to that of the indented victim . Attacks that can be instigated by observers are much more severe because they are far easier to achieve , especially undetected . 
 For the purposes of this discussion , I 'm talking about an attacker who can drop - and - replace , but I 'm not sure why you think a race wo n't work , as it depends quite a bit on the network topology 
 To prevent a race from being successful the probe needs to checksum the visible address and have that checksum be reflected back by the client rather than just ACK'ing the probe . Once the reflected checksum is seen the path must be valid . For true on path , the attacker can drop packets from client to server to maintain the illusion of a different client address , but then the probe will never be reflected correctly . It will eventually time out . BTW : the description on notation is confusing , mixing [ A : B ] with [ X : Y ] and sometimes having Z as payload and sometimes as an address . 
 No that is not sufficient . The attacker can just race the reflected probe checksum . 
 What we have in practice is this : Provided the attacker is n't on path ( where they could deny service anyway ) , the result is that the migration will revert as soon as the probe response arrives . That is , I think that we have all of what you suggest already , with the exception of the message saying " I think that I 'm migrating " . I do n't know how to do that . We do n't really create any signals that A might use to learn that it is migrating . 
 Why is it probing B - A ? 
 Because we : 
 If you see a new CID on a packet that is not Initial , you are probably migrating . You can win races by copying and spoofing source address without having the ability to drop packets . A spoofed packet will cause the real packet to be dropped by the endpoint if it arrives late . 
 OK . I missed that section . However , I 'm not sure how much it changes thing , though . The question is how much impact an on - path attacker can cheaply have ( and of course , this goes back to what we claim our security guarantees are ) . 
 The properties we want from migration are distinct from those during the handshake . I 'd like to resolve that discussion first . Then we can talk about what we might be willing to tolerate during migration . 
 Discussed in Tokyo : the working group believes right now that our existing defense is OK - ish .  noted that we 're not current as good as multipath TCP and suggested that we might want stronger confirmation . will take a first stab at documenting our principles with respect to what attacks we are prepared to spend effort to defend against . See . 
 Section 9 has a SHOULD regarding PATH_CHALLENGE ; change it to a MUST ? 
 Proposal from Tokyo : Endpoints MUST validate new paths before using them . In reaction to a migration they MUST continue using the old path until they receive new non - probing packets on the new path AND validation of that path is complete . Research question : Allow an exception in the case that the rebinding appears to be a NAT rebinding . Heuristics are necessary here : e.g. , a port - only change after a period of inactivity . If we adopt the strict requirement , but learn that we get a lot of hitches from apparent migration , then we can find a way to relax the requirement . If we allow this exception , then we have to address the problem of what to do when there are multiple such changes in a short period . = = Open this as an issue to track the research question . Otherwise , eliminate the distinction between IP and port changes and just say " address change " . Stricter rules would close off the ability for an attacker to force a connection into a non - functioning state , even if that state is temporary . The cost is that migration can result in a delay of a round trip or more . ( We might also want to know more about the severity of the attack . ) 
 I 'd add " appears to be intentional immediate migration " to the list of research questions . If a PATH_CHALLENGE is bundled with other frames and the path changes , then it seems very likely the peer knows the path has changed and it 's intentional . 
 Chatting with we may also want to add notes about potential signals of attacks in the off - path forwarding case : ( i ) large number of duplicates are being received from multiple addresses , ( ii ) PATH_RESPONSE is received from multiple addresses . These may not be actionable for everyone , but it helps implementers understand interesting signatures . 
 Q : Would n't the sender of a PATHCHALLENGE ignore a PATHRESPONSE that came back from a different peer address than what they send the PATHCHALLENGE to ? But yes , duplicate packets are insanely rare and receiving a duplicate from different addresses would almost never happen without interference , so it should be a strong signal that the immediate migration should be ignored . Of course that makes the state machine even more complex , but assuming that duplicate arrives while a PATHCHALLENGE is outstanding , maybe it 's not that much extra complexity ? 
 We 've gone through a bunch of different issues in this conversation , many of them have since been addressed . In general , we 've come up with some requirements , like having both old and new paths be validated , removing many of the concerns around quiescence . There 's also now a mention about heuristics , and it might be worth some editorial text describing possible heuristics to use ( happy to put some of that together , will pretty much align with and comments above ) . Much of comment above with the Tokyo proposal still applies , some of the last bits of the text outlined there are changing in . We can try to summarize the current state of things ( also happy to do that ) , but I 'm not sure that there 's a lot left to do in this issue specifically . 
 London discussion : to finalize 
 any progress here ? Thanks . 
 Yes , been blocked behind other things . 
 To your question above , we do n't validate the PATHRESPONSE 's address vs. the PATHCHALLENGE destination anymore since ( Stop requiring remote address to match during path validation ) . 
 Just to clarify what text I 'm adding here , this is documenting our security stance towards attacks against migration , which things we think should be possible and which things we think should not be possible . ( Which ekr can continue on into a section for QUIC in general . ) 
 The PR ( so far ) establishes the following definitions and guarantees : An on - path attacker can : Inspect packets Modify unencrypted packet headers Inject new packets  packets  packets An on - path attacker can not : Modify encrypted packet payloads An off - path attacker can : Inspect packets Inject new packets An off - path attacker can not : Modify any part of a packet  packets  packets A limited on - path attacker can : Inspect packets Inject new packets Modify unencrypted packet headers A limited on - path attacker can not : Delay packets beyond the original packet duration  packets  encrypted packet payloads on - path attacker can interrupt a QUIC connection , causing it to fail if it can not migrate to a new path that does not contain the attacker . This can be achieved by dropping all packets , modifying them so that they fail to decrypt , or other methods . on - path attacker can prevent migration to a new path for which the attacker is also on - path by causing path validation to fail on the new path . on - path attacker can not prevent a client from migrating to a path for which the attacker is not on - path . on - path attacker can reduce the throughput of a connection by delaying packets or dropping them . off - path attacker can race packets and attempt to become a “ limited ” on - path attacker . off - path attacker can cause path validation to succeed for forwarded packets with the source address listed as the off - path attacker as long as it can provide improved connectivity between the client and the server . off - path attacker can not cause a connection to close . off - path attacker can not cause migration to a new path to fail if it can not observe the new path . off - path attacker can become a limited on - path attacker during migration to a new path for which it is also an off - path attacker . off - path attacker can become a limited on - path attacker by affecting shared NAT state such that it sends packets to the server from the same IP address and port that the client originally used . limited on - path attacker can not cause an active connection to close . limited on - path attacker can not cause an idle connection to close if the client is first to resume activity . limited on - path attacker can cause an idle connection to be deemed lost if the server is the first to resume activity . There 's more descriptive text in the PR , as well , covering in a bit more detail our expectations about capabilities of the attackers , pathologically worst - case behaviors they may engage in , etc . 
 I think there needs to be a distinction between observing off - path attackers and blind off - path attackers . A blind attacker can inject packets and for example try to force close a connection even if the traffic flow is not visible . Such an attacker is probably the most common . 
 Can we be careful with how we sue " off path " - I think this uses the term assuming some visibility of the packets . In many transport documents , we assume that an off - path attacker does not have a way to see the packets . 
 Yes , sorry I 've got a reference to RFC 3552 in there but have n't updated to fully use the correct terminology yet . Will do , and I 'll ping you to take another look to make sure I get the right ones in the right places . :) 
 I 've now pushed some updates that try to make this clearer , another look and comments would be most welcome ! ( I expect this will take some iterating , but let 's start with what 's there and improve it . ) I 've a paragraph about blind active attackers ( which are probably off - path since it 's hard to not see the packets if you 're on - path ) . Overall , I 've kept the distinction of on - path vs. off - path , and referenced the definition for such in RFC 3552 which may help make things a bit clearer . 
 that makes sense . I just read the section on blind attacks . You mention it is not likely to successful which is probably true , but the reason is not limited to what you state . There is a lot of pain in path migration / discovery to avoid blind attacks being successful in hijacking or interrupting connections ( I do n't recall all the details ) . 
 Discussed in Cupertino . Contributors to review ASAP . 
 Happy to make changes , if you can recall some of the details here it would be great to be more explicit about them in the text . Otherwise , I think it does pretty much accurately reflect what we think is possible as an attack surface , so we should fold any concrete suggestions in ASAP . 
 I think some of issues I was thinking about relate to a non - blind attack where packets are mirrored , but that might well be covered in your text . I 'm just linking for reference Another issue that has been discussed is in early handshake where a powerful ( government ) adversary can race packets during handshake through a faster network . This is also not blind , and it is not something QUIC v1 attempts to solve AFAIR . 
 : This should have been except that this issue is marked as design and was marked as editorial . How do you want to proceed ? 
 Just so everyone is clear on what is happening here , I 've made a few changes and landed this . This is obviously a lot of text and it could benefit from more review , but the editors all agreed that it would better to make incremental changes rather than continue to maintain our oldest open PR further . Just to add to that , thanks very much to  ( and  ) for this text . It is really valuable work , and very fiddly . Comments from Hackathon - basically heading in correct direction . Looking great . Minor editorial nitpicks , and one which might turn into a separate issue . Some suggestions , but nothing concerning , so LG .
Paragraph (version B):
If the stream is in the "Recv" or "Size Known" states, the transport
SHOULD signal this by sending a STOP_SENDING frame to prompt closure
of the stream in the opposite direction.  This typically indicates
that the receiving application is no longer reading data it receives
from the stream, but it is not a guarantee that incoming data will be
ignored.
Paragraph (version A):
Connection IDs MUST NOT contain any information that can be used by
an external observer to correlate them with other connection IDs for
the same connection.  As a trivial example, this means the same
connection ID MUST NOT be issued more than once on the same
connection.
Paragraph (version B):
Connection IDs MUST NOT contain any information that can be used by
an external observer (that is, one that does not cooperate with the
issuer) to correlate them with other connection IDs for the same
connection.  As a trivial example, this means the same connection ID
MUST NOT be issued more than once on the same connection.
Paragraph (version A):
A zero-length connection ID MAY be used when the connection ID is not
needed for routing and the address/port tuple of packets is
sufficient to identify a connection.  An endpoint whose peer has
selected a zero-length connection ID MUST continue to use a zero-
length connection ID for the lifetime of the connection and MUST NOT
send packets from any other local address.
Paragraph (version A):
When an endpoint issues a connection ID, it MUST accept packets that
carry this connection ID for the duration of the connection or until
its peer invalidates the connection ID via a RETIRE_CONNECTION_ID
frame (frame-retire-connection-id).
Paragraph (version A):
Hosts try to associate a packet with an existing connection.  If the
packet has a Destination Connection ID corresponding to an existing
connection, QUIC processes that packet accordingly.  Note that more
than one connection ID can be associated with a connection; see
connection-id.
Paragraph (version A):
Valid packets sent to clients always include a Destination Connection
ID that matches a value the client selects.  Clients that choose to
receive zero-length connection IDs can use the address/port tuple to
identify a connection.  Packets that don't match an existing
connection are discarded.
Paragraph (version A):
Packets with a supported version, or no version field, are matched to
a connection using the connection ID or - for packets with zero-
length connection IDs - the address tuple.  If the packet doesn't
match an existing connection, the server continues below.
Paragraph (version A):
An endpoint can verify support for Explicit Congestion Notification
(ECN) in the first packets it sends, as described in ecn-
verification.
Paragraph (version A):
A client SHOULD NOT reuse a token in different connections.  Reusing
a token allows connections to be linked by entities on the network
path (see migration-linkability).  A client MUST NOT reuse a token if
it believes that its point of network attachment has changed since
the token was last used; that is, if there is a change in its local
IP address or network interface.  A client needs to start the
connection process over if it migrates prior to completing the
handshake.
Paragraph (version B):
Clients might receive multiple tokens on a single connection.  Aside
from preventing linkability, any token can be used in any connection
attempt.  Servers can send additional tokens to either enable address
validation for multiple connection attempts or to replace older
tokens that might become invalid.  For a client, this ambiguity means
that sending the most recent unused token is most likely to be
effective.  Though saving and using older tokens has no negative
consequences, clients can regard older tokens as being less likely be
useful to the server for address validation.
Paragraph (version B):
Using different connection IDs for packets sent in both directions on
each new network path eliminates the use of the connection ID for
linking packets from the same connection across different network
paths.  Header protection ensures that packet numbers cannot be used
to correlate activity.  This does not prevent other properties of
packets, such as timing and size, from being used to correlate
activity.
Paragraph (version B):
An endpoint that exhausts available connection IDs cannot probe new
paths or initiate migration, nor can it respond to probes or attempts
by its peer to migrate.  To ensure that migration is possible and
packets sent on different paths cannot be correlated, endpoints
SHOULD provide new connection IDs before peers migrate; see issue-
cid.  If a peer might have exhausted available connection IDs, a
migrating endpoint could include a NEW_CONNECTION_ID frame in all
packets sent on a new network path.
Paragraph (version A):
An endpoint SHOULD NOT send a stateless reset that is significantly
larger than the packet it receives.  Endpoints MUST discard packets
that are too small to be valid QUIC packets.  With the set of AEAD
functions defined in QUIC-TLS, packets that are smaller than 21 bytes
are never valid.
Paragraph (version B):
To entities other than its intended recipient, a stateless reset will
appear to be a packet with a short header.  For the stateless reset
to appear as a valid QUIC packet, the Unpredictable Bits field needs
to include at least 38 bits of data (or 5 bytes, less the two fixed
bits).
Paragraph (version B):
An endpoint MUST NOT send a stateless reset that is three times or
more larger than the packet it receives to avoid being used for
amplification.  reset-looping describes additional limits on
stateless reset size.
Paragraph (version A):
Finally, the last 16 bytes of the packet are set to the value of the
Stateless Reset Token.
Paragraph (version B):
Reducing the size of a Stateless Reset below 41 bytes means that the
packet could reveal to an observer that it is a Stateless Reset,
depending upon the length of the peer's connection IDs.  Conversely,
refusing to send a Stateless Reset in response to a small packet
might result in Stateless Reset not being useful in detecting cases
of broken connections where only very small packets are sent; such
failures might only be detected by other means, such as timers.
Paragraph (version B):
Retry packets (packet-retry), Version Negotiation packets (packet-
version), and packets with a short header (short-header) do not
contain a Length field and so cannot be followed by other packets in
the same UDP datagram.  Note also that there is no situation where a
Retry or Version Negotiation packet is coalesced with another packet.
Paragraph (version A):
The receiver's delayed acknowledgment timer SHOULD NOT exceed the
current RTT estimate or the value it indicates in the "max_ack_delay"
transport parameter.  This ensures an acknowledgment is sent at least
once per RTT when packets needing acknowledgement are received.  The
sender can use the receiver's "max_ack_delay" value in determining
timeouts for timer-based retransmission.
Paragraph (version A):
Strategies and implications of the frequency of generating
acknowledgments are discussed in more detail in QUIC-RECOVERY.
Paragraph (version B):
When sending a packet for any reason, an endpoint should attempt to
bundle an ACK frame if one has not been sent recently.  Doing so
helps with timely loss detection at the peer.
Paragraph (version B):
In general, frequent feedback from a receiver improves loss and
congestion response, but this has to be balanced against excessive
load generated by a receiver that sends an ACK frame in response to
every ack-eliciting packet.  The guidance offered below seeks to
strike this balance.
Paragraph (version B):
The algorithms in QUIC-RECOVERY are resilient to receivers that do
not follow guidance offered above.  However, an implementor should
only deviate from these requirements after careful consideration of
the performance implications of doing so.
Paragraph (version B):
ack-tracking and ack-limiting describe an exemplary approach for
determining what packets to acknowledge in each ACK frame.
Paragraph (version A):
The most recent set of acknowledgments are sent in ACK frames.  An
ACK frame SHOULD contain all unacknowledged acknowledgments, as
described in sending-ack-frames.
Paragraph (version B):
NEW_TOKEN frames are retransmitted if the packet containing them
is lost.  No special support is made for detecting reordered and
duplicated NEW_TOKEN frames other than a direct comparison of the
frame contents.
Paragraph (version A):
To use ECN, QUIC endpoints first determine whether a path supports
ECN marking and the peer is able to access the ECN codepoint in the
IP header.  A network path does not support ECN if ECN marked packets
get dropped or ECN markings are rewritten on the path.  An endpoint
verifies the path, both during connection establishment and when
migrating to a new path (see migration).
Paragraph (version B):
If an endpoint receives a QUIC packet without an ECT or CE codepoint
in the IP packet header, it responds per generating-acks with an ACK
frame without increasing any ECN counts.  If an endpoint does not
implement ECN support or does not have access to received ECN
codepoints, it does not increase ECN counts.
Paragraph (version A):
If an ECT codepoint set in the IP header is not corrupted by a
network device, then a received packet contains either the codepoint
sent by the peer or the Congestion Experienced (CE) codepoint set by
a network device that is experiencing congestion.
Paragraph (version A):
If a QUIC packet sent with an ECT codepoint is newly acknowledged by
the peer in an ACK frame without ECN feedback, the endpoint stops
setting ECT codepoints in subsequent IP packets, with the expectation
that either the network path or the peer no longer supports ECN.
Paragraph (version A):
Upon successful verification, an endpoint continues to set ECT
codepoints in subsequent packets with the expectation that the path
is ECN-capable.
Paragraph (version A):
If verification fails, then the endpoint ceases setting ECT
codepoints in subsequent IP packets with the expectation that either
the network path or the peer does not support ECN.
Paragraph (version A):
An opaque blob that the client may use with a future Initial
packet.
Paragraph (version B):
QUIC provides protection against various types of attacks, which are
described in more detail by RFC3552.
Paragraph (version B):
For this purpose, attacks are divided into passive and active
attacks.  Passive attackers have the capability to read packets from
the network, while active attackers also have the capability to write
packets into the network.  However, a passive attack may involve an
attacker with the ability to cause a routing change or other
modification in the path taken by packets that comprise a QUIC
connection.
Paragraph (version B):
Attackers are additionally categorized as either on-path attackers or
off-path attackers; see Section 3.5 of RFC3552.  An on-path attacker
can read, modify, or remove any packet it observes such that it no
longer reaches its destination, while an off-path attacker observes
the packets, but cannot prevent the original packet from reaching its
intended destination.  An off-path attacker can also transmit
arbitrary packets.
Paragraph (version B):
The QUIC handshake incorporates the TLS 1.3 handshake and enjoys the
cryptographic properties described in RFC8446; Appendix E.1.
Paragraph (version B):
In addition to those properties, the QUIC handshake is intended to
provide some defense against DoS attacks on the handshake, as
described below.
Paragraph (version B):
Because the QUIC handshake can occur without a transport-level round-
trip, the QUIC server's first flight may be sent to a client whose
address it cannot validate.  This flight may be long and therefore
potentially allows the server to be used as a DoS reflector/
amplifier.  The mechanisms described in validate-handshake restrict
the amplification to a factor of three.
Paragraph (version B):
Computing the server's first flight for a full handshake is
potentially expensive, requiring both a signature and a key exchange
computation.  In order to prevent computational DoS attacks, QUIC
incorporates a cheap token exchange mechanism which allows servers to
validate a client's IP address prior to doing any expensive
computations at the cost of a single round trip.  After a successful
handshake, servers can issue new tokens to a client which will allow
new connection establishment without incurring this cost.
Paragraph (version B):
An on-path attacker can force the QUIC handshake to fail by replacing
either the client or server Initial messages with invalid messages.
An off-path attacker can also mount this attack by racing the
Initials.  Once valid Initial messages have been exchanged, the
remaining handshake messages are protected with the handshake keys
and an on-path attacker cannot force handshake failure, though they
can produce a handshake timeout by dropping packets.
Paragraph (version B):
The entire handshake is cryptographically protected, with the Initial
packets being encrypted with per-version keys and the Handshake and
later packets being encrypted with keys derived from the TLS key
exchange.  Further, parameter negotiation is folded into the TLS
transcript and thus provides the same security guarantees as ordinary
TLS negotiation.  Thus, an attacker can observe the client's
transport parameters (as long as it knows the QUIC version-specific
salt) but cannot observe the server's transport parameters and cannot
influence parameter negotiation.
Paragraph (version B):
Connection IDs are unencrypted but integrity protected in all
messages.  They are not incorporated in the TLS handshake transcript.
Paragraph (version B):
This version of QUIC does not incorporate a version negotiation
mechanism; implementations of QUIC with incompatible versions will
simply fail to negotiate.
Paragraph (version B):
Packet protection (packet-protected) provides authentication and
encryption of all QUIC packets except Version Negotiation and Retry
packets, see QUIC-TLS for more details.  This section considers
passive and active attacks against protected packets.
Paragraph (version B):
Both on-path and off-path attackers can mount a passive attack in
which they save observed QUIC packets for an offline attack against
QUIC packet protection at a future time; this is true for any
observer of any packet on any network.
Paragraph (version B):
A blind attacker, one who injects packets without being able to
observe valid packets for a QUIC connection, is unlikely to be
successful, since packet protection ensures that valid packets are
only generated by endpoints which possess the key material
established during the handshake; see handshake and handshake-
properties.  Similarly, any active attacker that observes QUIC
packets and attempts to insert new data or modify existing data in
those packets should not be able to generate packets deemed valid by
the receiving endpoint.
Paragraph (version B):
A spoofing attack, in which an active attacker rewrites unprotected
parts of a QUIC packet that it forwards or injects, such as the
source or destination address, is only effective if the attacker can
forward packets to the original endpoint.  Packet protection ensures
that the packet payloads can only be processed by the endpoints that
completed the handshake, and invalid QUIC packets are ignored by
those endpoints.
Paragraph (version B):
An attacker can also modify the boundaries between QUIC packets and
UDP datagrams, causing multiple packets to be coalesced into a single
datagram, or splitting coalesced packets into multiple datagrams.
Such modification has no functional effect on a QUIC connection,
although it might change the performance characteristics exhibited by
the receiving endpoint.
Paragraph (version B):
An attacker that can cause a packet it observes to no longer reach
its intended destination is considered an on-path attacker.  Such an
attacker generally is present between the QUIC client and server, and
a QUIC endpoint is required to send packets through this attacker to
establish connectivity on a given path.
Paragraph (version B):
An on-path attacker has the opportunity to modify the packets that it
observes, however any modifications to an authenticated portion of a
packet will cause it to be dropped by the receiving endpoint as
invalid, as QUIC payloads are both authenticated and encrypted.
Paragraph (version B):
An on-path attacker can prevent use of a path for a QUIC
connection, causing it to fail if it cannot migrate to a new path
that does not contain the attacker.  This can be achieved by
dropping all packets, modifying them so that they fail to decrypt,
or other methods.
Paragraph (version B):
An off-path attacker is not directly on the path between the QUIC
client and server, but may be able to obtain copies of some or all
packets sent between the client and the server.  It is also able to
send copies of those packets to either endpoint.
Paragraph (version B):
An off-path attacker can, however, modify packets that it has
observed and inject them back into the network, potentially with
spoofed source and destination addresses.
Paragraph (version B):
An off-path attacker cannot cause a connection to close.
Paragraph (version B):
A limited on-path attacker cannot cause an active connection to
close.