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

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.

I'm not looking to improve connection migration here.  Just describe how I believe that is has to work within the current design.  If you want to add make-before-break connection migration, that's awesome, but it will definitely take more changes than this.  (It might build on this, even back out some of these changes.)  I'll split the PING/PONG change out though.

> @@ -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

That's entirely too woolly for me.  Can we decide to remove the stronger language once we decide that a less-than-hard cutover is necessary?  I appreciate that there might be some value in testing a path before switching to it, for example, but lowercase "should" leaves a lot up to implementations to work out.

Can we give more concrete advice?  Would it be OK to say that the old path can be used until the probe works or times out?  We're basically conceding that there will be periods of multipath there, which is probably a good thing long-term, but I wanted to avoid that.

> +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

That wasn't the conclusion of the discussion on #161.  FWIW, I would prefer that, but I am trying to capture the outcome of the discussion faithfully.

> +
+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

The logic here is such that if the old address continues to be used (and this is not just due to old packets being delayed, because it checks that the packet number increases) then the check on the new path is abandoned and the old path is OK.

> @@ -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.

Correct.  That's the default.

>  
-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 (*)                  ...

I removed all qualifiers on the names.

> +## Spurious Connection Migrations
+
+A connection migration could be triggered by an attacker that is able to capture
+and forward a packet such that it arrives before the legitimate copy of that
+packet.  Such a packet will appear to be a legitimate connection migration and
+the legitimate copy will be dropped as a duplicate.
+
+After a spurious migration, validation of the source address will fail because
+the entity at the source address does not have the necessary cryptographic keys
+to read or respond to the PING frame that is sent to it, even if it wanted to.
+Such a spurious connection migration could result in the connection being
+dropped when the source address validation fails.  This grants an attacker the
+ability to terminate the connection.
+
+Receipt of packets with higher packet numbers from the legitimate address will
+trigger another connection migration.  This will cause the validation of the

How far up?

> +of data and packets that it sends to its peer.  At a minimum, this needs to
+consider the possibility that packets are sent without congestion feedback.
+
+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.

ICE sends a new random number, we should too.

> +
+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.

It sounds like you have a design in mind.  Removing this paragraph breaks the guarantee from above.

I can't write about a design that I don't know about.  Are you describing a case where each endpoint is able to probe paths, but not cause the peer to use those paths until it decides that the path is OK?  (ICE does something similar in its make-before-break scenario, it's a reasonable model.)

If so, you need signals so that the poor peer isn't forced to guess which of these paths is the one that is preferred.  You also need some sort of system to ensure that both peers don't get different ideas about which path is "best".  Without that you get uncontrolled path oscillations.  We don't have either of those mechanisms right now, and the only signal we have is receipt of packets.  Unless we add the better design, this design at least works, even if it is suboptimal.  It's easy enough to back out or qualify a MUST or two once we have that better design complete.

-- 
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-69454094