Add initial threat model to security considerations

draft-ietf-quic-transport.md

@@ -5980,6 +5980,289 @@ decisions are made independently of client-selected values; a Source Connection
 ID can be selected to route later packets to the same server.
 
 
+## Overview of Security Properties {#security-properties}
+
+A complete security analysis of QUIC is outside the scope of this document.
+This section provides an informal description of the desired security properties
+as an aid to implementors and to help guide protocol analysis.
+
+QUIC provides protection against various types of attacks, which are described
+in more detail by {{?RFC3552}}.
+
+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.
+
+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.
+
+Properties of the handshake, protected packets, and connection migration are
+considered separately.
+
+
+### Handshake {#handshake-properties}
+
+The QUIC handshake incorporates the TLS 1.3 handshake and enjoys the
+cryptographic properties described in {{?RFC8446}}; Appendix E.1.
+
+In addition to those properties, the QUIC handshake is intended to provide some
+defense against DoS attacks on the handshake, as described below.
+
+#### Anti-Amplification
+
+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.
+
+#### Server-Side DoS
+
+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.
+
+#### On-Path Handshake Termination
+
+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.
+
+An on-path attacker can also replace the addresses of packets on either side and
+therefore cause the client or server to have an incorrect view of the remote
+addresses. Such an attack is indistinguishable from the functions performed by a
+NAT.
+
+#### Parameter Negotiation
+
+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.
+
+Connection IDs are unencrypted but integrity protected in all messages.  They
+are not incorporated in the TLS handshake transcript.
+
+This version of QUIC does not incorporate a version negotiation mechanism;
+implementations of QUIC with incompatible versions will simply fail to
+negotiate.
+
+
+### Protected Packets {#protected-packet-properties}
+
+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.
+
+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.
+
+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.
+
+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.
+
+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.
+
+
+### Connection Migration {#migration-properties}
+
+Connection Migration ({{migration}}) provides endpoints with the ability to
+transition between IP addresses and ports on multiple paths, using one path at a
+time for transmission and receipt of non-probing frames.  Path validation
+({{migrate-validate}}) establishes that a peer is both willing and able
+to receive packets sent on a particular path.  This helps reduce the effects of
+address spoofing by limiting the number of packets sent to a spoofed address.
+
+This section describes the intended security properties of connection migration
+when under various types of DoS attacks.
+
+#### On-Path Active Attacks
+
+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.
+
+An on-path attacker can:
+
+- Inspect packets
+- Modify IP and UDP packet headers
+- Inject new packets
+- Delay packets
+- Reorder packets
+- Drop packets
+- Split and merge datagrams along packet boundaries
+
+An on-path attacker cannot:
+
+- Modify an authenticated portion of a packet and cause the
+ recipient to accept that packet
+
+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.
+
+In the presence of an on-path attacker, QUIC aims to provide the following
+properties:
+
+1. 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.
+
+2. An 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.
+
+3. An on-path attacker cannot prevent a client from migrating to a path for
+which the attacker is not on-path.
+
+4. An on-path attacker can reduce the throughput of a connection by delaying
+packets or dropping them.
+
+5. An on-path attacker cannot cause an endpoint to accept a packet for which it
+has modified an authenticated portion of that packet.
+
+#### Off-Path Active Attacks
+
+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.
+
+An off-path attacker can:
+
+- Inspect packets
+- Inject new packets
+- Reorder injected packets
+
+An off-path attacker cannot:
+
+- Modify any part of a packet
+- Delay packets
+- Drop packets
+- Reorder original packets
+
+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.
+
+For the purposes of this discussion, it is assumed that an off-path attacker has
+the ability to observe, modify, and re-inject a packet into the network that
+will reach the destination endpoint prior to the arrival of the original packet
+observed by the attacker.  In other words, an attacker has the ability to
+consistently "win" a race with the legitimate packets between the endpoints,
+potentially causing the original packet to be ignored by the recipient.
+
+It is also assumed that an attacker has the resources necessary to affect NAT
+state, potentially both causing an endpoint to lose its NAT binding, and an
+attacker to obtain the same port for use with its traffic.
+
+In the presence of an off-path attacker, QUIC aims to provide the following
+properties:
+
+1. An off-path attacker can race packets and attempt to become a "limited"
+on-path attacker.
+
+2. An 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.
+
+3. An off-path attacker cannot cause a connection to close.
+
+4. An off-path attacker cannot cause migration to a new path to fail if it
+cannot observe the new path.
+
+5. An 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.
+
+6. An 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 Active Attacks
+
+A limited on-path attacker is an off-path attacker that has offered improved
+routing of packets by duplicating and forwarding original packets between the
+server and the client, causing those packets to arrive before the original
+copies such that the original packets are dropped by the destination endpoint.
+
+A limited on-path attacker differs from an on-path attacker in that it is not on
+the original path between endpoints, and therefore the original packets sent by
+an endpoint are still reaching their destination.  This means that a future
+failure to route copied packets to the destination faster than their original
+path will not prevent the original packets from reaching the destination.
+
+A limited on-path attacker can:
+
+- Inspect packets
+- Inject new packets
+- Modify unencrypted packet headers
+- Reorder packets
+
+A limited on-path attacker cannot:
+
+- Delay packets so that they arrive later than packets sent on the original path
+- Drop packets
+- Modify the authenticated and encrypted portion of a packet and cause the
+ recipient to accept that packet
+
+A limited on-path attacker can only delay packets up to the point that the
+original packets arrive before the duplicate packets, meaning that it cannot
+offer routing with worse latency than the original path.  If a limited on-path
+attacker drops packets, the original copy will still arrive at the destination
+endpoint.
+
+In the presence of a limited on-path attacker, QUIC aims to provide the
+following properties:
+
+1. A limited on-path attacker cannot cause an active connection to close.
+
+2. A limited on-path attacker cannot cause an idle connection to close if the
+client is first to resume activity.
+
+3. A limited on-path attacker can cause an idle connection to be deemed lost if
+the server is the first to resume activity.
+
+Note that these guarantees are the same guarantees provided for any NAT, for the
+same reasons.
+
+
 # IANA Considerations {#iana}
 
 This document establishes several registries for the management of codepoints in
@@ -6263,13 +6546,18 @@ DecodePacketNumber(largest_pn, truncated_pn, pn_nbits):
    return candidate_pn
 ~~~
 
+
 # Change Log
 
 > **RFC Editor's Note:** Please remove this section prior to publication of a
 > final version of this document.
 
 Issue and pull request numbers are listed with a leading octothorp.
 
+## Since draft-ietf-quic-transport-24
+
+- Added migration threat model to security considerations (#2143)
+
 ## Since draft-ietf-quic-transport-23
 
 - Allow ClientHello to span multiple packets (#2928, #3045)