Re: [quicwg/base-drafts] Fix for off-path migration attack (#2033)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.



> @@ -1753,10 +1753,12 @@ have failed, even if the data matches that sent in the PATH_CHALLENGE.
 Additionally, the PATH_RESPONSE frame MUST be received on the same local address
 from which the corresponding PATH_CHALLENGE was sent.  If a PATH_RESPONSE frame
 is received on a different local address than the one from which the
-PATH_CHALLENGE was sent, path validation is considered to have failed, even if
-the data matches that sent in the PATH_CHALLENGE.  Thus, the endpoint considers
-the path to be valid when a PATH_RESPONSE frame is received on the same path
-with the same payload as the PATH_CHALLENGE frame.
+PATH_CHALLENGE was sent, path validation is not considered to be successful,
+even if the data matches that sent in the PATH_CHALLENGE.  This doesn't result
+in path validation failure, as it might be a result of a forwarded packet (see
+{{off-path-forward}}) or misrouting.  Thus, the endpoint considers the path to
+be valid when a PATH_RESPONSE frame is received on the same path with the same

We always had that (this is just changing this text to be consistent with the text in other places).



> @@ -1766,7 +1768,8 @@ abandons its attempt to validate the path.
 
 Endpoints SHOULD abandon path validation based on a timer. When setting this
 timer, implementations are cautioned that the new path could have a longer
-round-trip time than the original.
+round-trip time than the original.  A value of three times the current
+Retransmittion Timeout (RTO) as defined in {{QUIC-RECOVERY}} is RECOMMENDED.

I considered that, but we still have a minimum on the RTO, which should cover this case well enough.

> @@ -1938,6 +1941,52 @@ Note that receipt of packets with higher packet numbers from the legitimate peer
 address will trigger another connection migration.  This will cause the
 validation of the address of the spurious migration to be abandoned.
 
+
+### Off-Path Packet Forwarding {#off-path-forward}
+
+An off-path attacker that can observe packets might forward copies of genuine
+packets to endpoints.  If the copied packet arrives before the genuine packet,
+this will appear as a NAT rebinding.  Any genuine packet will be discarded as a

I don't think that we need a precise description of the attack.  This is already far too many words.

> +relatively few packets are sent or if packet loss coincides with the attempted
+attack.
+
+A non-probing packet received on the original path that increases the maximum
+received packet number will cause the endpoint to move back to that path.
+Eliciting packets on this path increases the likelihood that the attack is
+unsuccessful.  Therefore, mitigation of this attack relies on triggering the
+exchange of packets.
+
+In response to an apparent migration, endpoints MUST validate the previously
+active path using a PATH_CHALLENGE frame.  This induces the sending of new
+packets on that path.  If the path is no longer viable, the validation attempt
+will time out and fail; if the path is viable, but no longer desired, the
+validation will succeed, but only result in a probing packet being sent on the
+path.
+

The point here is that this isn't heuristics-based decision-making.  It's currently arranged to be mechanical.  The only discretionary part is the rate at which probes are generated.  I think that the right thing to do is acknowledge that heuristics might be used to make this defense more robust and to mention some of the things you point to.

> +path.
+
+An endpoint that receives a PATH_CHALLENGE on an active path SHOULD send a
+non-probing packet in response.  If the non-probing packet arrives before any
+copy made by an attacker, this results in the connection being migrated back to
+the original path.  Any subsequent migration to another path resets this entire
+process.
+
+Abandoning this validation attempt before it either succeeds or times out
+increases exposure to the packet copying attack.
+
+This defense is imperfect, but this is not considered a serious problem. If the
+path via the attack is reliably faster than the original path despite multiple
+attempts to use that original path, it is not possible to distinguish between
+attack and an improvement in routing.
+

The risk is that the attacker can convince a peer that the connection is dead, meaning that no more packets are sent.  The interaction between validation timers and dead path detection probably need some work.

> -packets so that their loss detection is independent and does not unduly cause
-the congestion controller to reduce its sending rate.  An endpoint might set a
-separate timer when a PATH_CHALLENGE is sent, which is cancelled when the
-corresponding PATH_RESPONSE is received.  If the timer fires before the
-PATH_RESPONSE is received, the endpoint might send a new PATH_CHALLENGE, and
-restart the timer for a longer period of time.
+{{QUIC-RECOVERY}}) may be adequate.  For instance, an endpoint might delay
+switching to a new congestion control context until it is confirmed that an old
+path is no longer needed (for the case in {{off-path-forward}}).
+
+A sender can make exceptions for probe packets so that their loss detection is
+independent and does not unduly cause the congestion controller to reduce its
+sending rate.  An endpoint might set a separate timer when a PATH_CHALLENGE is
+sent, which is cancelled when the corresponding PATH_RESPONSE is received.  If
+the timer fires before the PATH_RESPONSE is received, the endpoint might send a
+new PATH_CHALLENGE, and restart the timer for a longer period of time.

This is just the old text, with the paragraph split to allow for the new text.  If you have a suggestion here, that would be great, but I can't figure out how to add that without doing a lot of damage to the existing 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/2033#discussion_r235828354