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

[ianswett <[e-mail]>]

ianswett commented on this pull request.

A few comments, but this looks good overall.

>  
-TODO: see issue #161
+An endpoint that see a new source IP address and port (or just a new source

see/sees

>  
-TODO: see issue #161
+An endpoint that see a new source IP address and port (or just a new source
+port) on packets from its peer is likely seeing a connection migration at the
+peer.
+
+However, it is also possible that the peer is spoofing its source address in
+order to cause the endpoint to send excessive amounts of data to an unwilling
+host.  If the endpoint sends significantly more data than the peer, connection
+migration might be used to amplify the volume of data that an attacker can
+generate toward a victim.
+
+Thus, when seeing a new remote transport address, an endpoint MUST verify that
+its peer can receive and respond to packets at that new address.  By providing
+copies of the frames that it receives, the peer proves that it is receiving

nit: Technically, they're not copies of the frames.

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

Should we be retransmitting the same PING frame or a different PING frame?

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

What if other packets continue to arrive from the old address?  Shouldn't the connection just stay on the old address? 

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

Thanks, this makes sense.  Possibly allude to it earlier in the text?

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