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

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> +Prior to validating the new remote address, and endpoint MUST limit the amount
+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.
+
+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

Firstly, this isn't new, but it suggests some more work (more on this below).

I considered this, but didn't give it enough thought.  The reason I dismissed this was that the very next packet from the victim will come from a genuine address and it will appear to be yet another migration, correcting the problem.  As long as that happens, the attacker only causes a few packets to be sent to it.  But then the next packet might take too long to arrive to be relevant.

That suggests some changes:

1. Abandon any tests on a previous address if a packet from another new address is seen.  (Use packet numbers to ensure that you can detect the most recent packet.)
2. Require that the endpoint that observes the migration ping the old address as well.

The first ensures that that the raced packet can't cause a flip to stick.  Unless the attacker can reliably capture and win a race on every packet, thereby denying service.

The second ensures that if this attack happens and the old address remains valid, a packet will be seen on the old address, causing the migration to switch back.

Does that work?

Or, we could design multipath...

-- 
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#discussion_r134635373