Re: [quicwg/base-drafts] Define requirements for handling packets (#724)

[Mike Bishop <[e-mail]>]

MikeBishop commented on this pull request.

I see a few corner cases on another read-through, but it's looking good.  Let's land this soon.

> +
+Buffering ensures that data is not lost, which improves performance; conversely,
+discarding these packets could create false loss signals for the congestion
+controllers.  However, limiting the number and size of buffered packets might be
+needed to prevent exposure to denial of service.
+
+For clients, any packet that cannot be associated with an existing connection
+SHOULD be discarded if it not buffered.  Discarded packets MAY be logged for
+diagnostic or security purposes.
+
+For servers, packets that aren't associated with a connection potentially create
+a new connection.  However, only packets that use the long packet header and
+that are at least the minimum size defined for the protocol version can be
+initial packets.  Unless the server is buffering 0-RTT packets, a server MUST
+discard packets that cannot be associated with a connection if they use the
+short header form, or they are smaller than the smallest minimum size for any

Doesn't this rule out the very case Stateless Reset is intended for?  Can't be associated with an active connection, short header, but includes the Connection ID.

> +diagnostic or security purposes.
+
+For servers, packets that aren't associated with a connection potentially create
+a new connection.  However, only packets that use the long packet header and
+that are at least the minimum size defined for the protocol version can be
+initial packets.  Unless the server is buffering 0-RTT packets, a server MUST
+discard packets that cannot be associated with a connection if they use the
+short header form, or they are smaller than the smallest minimum size for any
+version that the server supports.
+
+This version of QUIC defines a minimum size for initial packets of 1200 octets.
+Versions of QUIC that define smaller minimum initial packet sizes need to be
+aware that initial packets will be discarded without action by servers that only
+support versions with larger minimums.  Clients that support multiple QUIC
+versions can avoid this problem by ensuring that they increase the size of their
+initial packets to the largest minimum size across all of the QUIC versions they

Side-note which may not require a change:  If the server and client have any overlap between versions, this will work.  If they don't have any overlap between versions, however, this potentially leads to a connection time-out rather than a VN exchange and immediate conclusion that there's no overlap.

Consider the case where the minima of the versions supported by the client are (1040,680,256), and the minima of the version supported by the server are (1280,1280,1600).  Even following this advice, the server will always ignore the client's Client Initial packets, and the client will ultimately time out.

I'm not sure we need to fix this, given that otherwise we risk spewing VN packets in response to random noise.  However, we might want to be clear that this isn't guaranteed to avoid the problem.

>  
-When the client receives a Version Negotiation packet from the server, it should
-select an acceptable protocol version.  If the server lists an acceptable
-version, the client selects that version and reattempts to create a connection
-using that version.  Though the contents of a packet might not change in
+When the client receives a Version Negotiation packet, it first checks that the
+packet number and connection ID match the values it sent in a Client Initial
+packet.  If this check fails, the packet MUST be discarded.

Another potential timing issue:  Client sends Client Initial + 0-RTT data.  Client Initial is lost in transit.  Version Negotiation comes back responding to 0-RTT packets because the server only received those.  Per the current text, it MUST ignore the server's VN packets until it has retransmitted the CI and gotten *that* VN packet.  Hopefully rare, since if you're doing 0-RTT you're unlikely to use an unsupported version -- but not impossible.

Maybe we should simply say "match the values it sent in a packet on this connection"?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/724#pullrequestreview-68049232