Re: [quicwg/base-drafts] Address validation for connection migration (#732)

[janaiyengar <[e-mail]>]

janaiyengar requested changes on this pull request.

This PR conflates a few things, which will make it harder to land the simpler things. I would simply add the frame type and rules around using PING/PONG in one PR, and then discuss address validation in a separate PR, since that will need quite a bit of discussion. I don't mind having that discussion on an issue. I don't think this PR is ready to be submitted.

> @@ -1351,6 +1355,14 @@ connection when they move networks.  This includes state that can be hard to
 recover such as outstanding requests, which might otherwise be lost with no easy
 way to retry them.
 
+An endpoint that receives packets that contain a source IP address and port that

We're definitely learning that having the ability to probe is quite useful even for connection migration. I've been working on redesigning connection migration, and our experience has shown that there needs to be more nuance around connection migration than simply switching away on the first packet. I don't want normative language here yet. I would suggest, for the sake of getting this PR in, to rephrase the MUST below to be non-normative ("should start sending", not capitalized.) We can then do an issue about what to do around connection migration separately, and figure out what should be normative.

> +
+Once a connection is established, address validation is relatively simple (see
+{{address-validation}} for the process that is used during the handshake).  An
+endpoint validates a remote address by sending a PING frame containing a payload
+that is hard to guess.  This frame MUST be sent in a packet that is sent to the
+new address.  Once a PONG frame containing the same payload is received, the
+address is considered to be valid.  The PONG frame can use any path on its
+return.  A PING frame containing 12 randomly generated {{?RFC4086}} octets is
+sufficient to ensure that it is easier to receive the packet than it is to guess
+the value correctly.
+
+Note:
+
+: Retransmissions of the PING frame MUST also use the same remote address.
+
+If validation of the new remote address fails, after allowing enough time for

Yes, agreed. We don't want to terminate the connection because a new path that we want to switch to doesn't work.

> +the value correctly.
+
+Note:
+
+: Retransmissions of the PING frame MUST also use the same remote address.
+
+If validation of the new remote address fails, after allowing enough time for
+possible loss and recovery of packets carrying PING and PONG frames, the
+endpoint MUST terminate the connection.  When setting this timer,
+implementations are cautioned that the new path could have a longer round trip
+time than the original.  The endpoint MUST NOT send a CONNECTION_CLOSE frame in
+this case; it has to assume that the remote peer does not want to receive any
+more packets.
+
+If the remote address is validated successfully, the endpoint MAY increase the
+rate that it sends on the new path using the state from the previous path.  The

I would remove the entire paragraph here and simply replace with "If the remote address is validated successfully, the endpoint SHOULD reset the congestion controller to its initial state."

> +
+After verifying an address, the endpoint SHOULD update any address validation
+tokens ({{address-validation}}) that it has issued to its peer if those are no
+longer valid based on the changed address.
+
+Address validation using the PING frame MAY be used at any time by either peer.
+For instance, an endpoint might check that a peer is still in possession of its
+address after a period of quiescence.
+
+Upon seeing a connection migration, an endpoint that sees a new address MUST
+abandon any address validation it is performing with other addresses on the
+expectation that the validation is likely to fail.  Abandoning address
+validation primarily means not closing the connection when a PONG frame is not
+received, but it could also mean ceasing retransmissions of the PING frame.  An
+endpoint that doesn't retransmit a PING frame might receive a PONG frame, which
+it MUST ignore.

This paragraph is unnecessary. Using PINGs on alt paths is fine, you don't want to start sending data on all of them. 

>  
-The PING frame can be used to keep a connection alive when an application or
-application protocol wishes to prevent the connection from timing out.  An
+~~~
+ 0                   1                   2                   3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+| Pong Length(8)|              Pong Data (*)                  ...

Calling this data length and PING data avoids confusion.

> ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+~~~
+
+Pong Length:
+
+: This 8-bit value describes the length of the Pong Data field.
+
+Pong Data:
+
+: This variable-length field contains arbitrary data.
+
+The receiver of a PING frame with a Pong Data field that is empty simply needs
+to acknowledge the packet containing this frame.
+
+If the Pong Data is not empty, the recipient of this frame MUST generate a PONG
+frame ({{frame-pong}}) containing the same Pong Data.

It's easiest if the PING also generates an ack. Separately, the PONG packet will require an ack.

> @@ -1984,6 +2122,18 @@ Stream ID:
 Error Code:
 : The application-specified reason the sender is ignoring the stream.
 
+
+## PONG Frame {#frame-pong}
+
+The PONG frame (type=0x0d) is sent in response to a PING frame that contains
+data.  Its format is identical to the PING frame ({{frame-ping}}).
+
+An endpoint that receives an unsolicited PONG frame - that is, a PONG frame
+containing a payload that is either empty or not identical to the content of a
+PING frame that the endpoint previously sent - MUST generate a connection error
+of type UNSOLICITED_PONG.

A PONG frame needs to be acked.

-- 
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/732#pullrequestreview-69323047