Re: [quicwg/base-drafts] Connection ID DT output (#1742)

[Christian Huitema <[e-mail]>]

huitema commented on this pull request.

I think we will have an interesting conversation. My main concern is whether to introduce a concept of paths, i.e. pairs o connection IDs. It would simplify my code significantly, rather than trying to implement paths using low level components like NEW CONNECTION ID, PATH CHALLENGE and PATH RESPONSE.

> +({{frame-connection-id-finished}}).
+
+Implementations SHOULD ensure that peers have sufficient connection IDs
+available to reduce the possibility of peers exhausting their supply of
+available connection IDs.  An implementation could do this by always supplying a
+new connection ID for each connection ID retired with a CONNECTION_ID_FINISHED
+frame. When a receiver of a packet notices that its peer is now using a
+previously unused connection ID, it can choose to supply its peer with a new
+connection ID using a NEW_CONNECTION_ID frame to reduce the possibility of its
+peer running out of available connection IDs.
+
+An endpoint that receives a packet with a different remote address than
+previously used SHOULD also switch to sending with a different connection ID.
+This can help to ensure that different connection IDs will be used in both
+directions when an endpoint migrates to a new path or changes connection ID on
+an existing path.

In practice, that recommendation amounts to the server initiating a migration upon receiving packets from a new client address, so that a given pair of CID is tied to a single pair of addresses. That can work, but we have to consider security issues. Addresses are outside the cryptographic envelope, attackers can take good packets and just replace the address by something else. That mean attackers can easily trick servers into starting migrations.

I am not sure of the balance between aggravated DOD risk and moderate privacy gain. The beans are already spilled in the packet from the client with the changed address and the constant CID. If we do nothing, the client will notice that its own address changed upon receiving the first reply from the server. It can then chose to start a migration. That seems more robust.

> +
+### Consuming Connection IDs
+
+If an endpoint's peer has selected a non-zero-length connection ID, the endpoint
+maintains a set of connection IDs received from the peer that it can use when
+sending packets.  All connection IDs issued by the peer are considered valid for
+use by the endpoint when sending packets until the connection ID is retired by
+the endpoint.  Endpoints can choose to stop using a given connection ID to send
+packets at any time and signal this to the issuing endpoint via a
+CONNECTION_ID_FINISHED frame.  This frame indicates the connection ID that is no
+longer in use and serves as a request for the peer to issue additional
+connection IDs via a NEW_CONNECTION_ID frame.
+
+An endpoint that retires a connection ID should retain knowledge of that
+connection ID for a reasonable time after sending the CONNECTION_ID_FINISHED
+frame, or until that frame is acknowledged.  A recommended time is three times

@martinthomson do we still have a reset risk if the client retires the stateless reset value that it received with the retired connection ID?

> @@ -3257,6 +3287,49 @@ the Source Connection ID used by the peer during the initial
 handshake, it MUST treat that receipt as a connection error of type
 PROTOCOL_VIOLATION.
 
+## CONNECTION_ID_FINISHED Frame {#frame-connection-id-finished}
+
+An endpoint sends a CONNECTION_ID_FINISHED frame (type=0x1b) to indicate that it
+will no longer use a connection ID that was issued by its peer.  This also
+serves as a request to the peer to send additional connection IDs for future use
+(see {{connection-id}}).  New connection IDs can be delivered via the
+NEW_CONNECTION_ID frame ({{frame-new-connection-id}}).
+
+Retiring a connection ID using the CONNECTION_ID_FINISHED frame invalidates any
+stateless reset tokens associated with that connection ID.

I would actually disable the reset token asap. The only down side of doing that is to fall back to timer based termination if the connection breaks. But we probably need more text on the behavior of the reset token. Assume that a path is defined by a pair of CID. At any given point, a node will have a "main path" on which it is sending data, and a set of paths in various alternate paths in different stages of validation. Let's look at the following scenarios:

1) Node sends a normal packet, on the main path, and receives back a reset.
2) Node sends a probe with a fresh CID and new addresses and receives back a reset
3) Node sends a probe response with a fresh CID in response to a probe and receives back a reset
4) Node has parked an old path that it does not actively use and receives a reset on that path.

Do we want to treat all these scenarios the same, as in tear down the connection? Or do we want to just accept resets on the path that is actively used?



> +Connection ID:
+
+: A connection ID of the specified length.
+
+Receipt of a CONNECTION_ID_FINISHED frame containing a connection ID that was
+not previously sent to the peer MAY be treated as a connection error of type
+PROTOCOL_VIOLATION.
+
+An endpoint MUST NOT send this frame if it is currently sending packets with a
+zero-length Destination Connection ID.  Changing the length of a connection ID
+to or from zero-length makes it difficult to identify when the value of the
+connection ID changed.  An endpoint that is receiving packets with a zero-length
+Destination Connection ID MUST treat receipt of a CONNECTION_ID_FINISHED frame
+as a connection error of type PROTOCOL_VIOLATION.
+
+

We want to say whether it can or cannot...

-- 
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/1742#pullrequestreview-155728483