Subject: Re: [quicwg/base-drafts] A more complete connection migration (#1249)

From: ekr <[email-masked]>
Date: Mon, 02 Apr 2018 16:53:22 -0700

ekr commented on this pull request.

> +mechanism described here might be effective for the creation of NAT bindings
+that support NAT traversal, the expectation is that one or other peer is able to
+receive packets without first having sent a packet on that path. Effective NAT
+traversal needs additional synchronization mechanisms that are not provided
+here.
+
+An endpoint MAY bundle PATH_CHALLENGE and PATH_RESPONSE frames that are used for
+path validation with other frames.  For instance, an endpoint may pad a packet
+carrying a PATH_CHALLENGE for PMTU discovery, or an endpoint may bundle a
+PATH_RESPONSE with its own PATH_CHALLENGE.
+
+
+### Initiation
+
+To initiate path validation, an endpoint sends a PATH_CHALLENGE frame containing
+a random payload on the path to be validated.

The requirement is not that the payload be *random* but rather that it be *unpredictable*. For instance, it would be fine to have the payload be generated as:
```
retransmission # || HMAC(key, remote IP || retransmission #)
```

> +endpoint SHOULD NOT send a PATH_CHALLENGE more frequently than it would an
+Initial packet, ensuring that connection migration is no more load on a new path
+than establishing a new connection.
+
+The endpoint MUST use fresh random data in every PATH_CHALLENGE frame so that it
+can associate the peer's response with the causative PATH_CHALLENGE.
+
+
+### Response
+
+On receiving a PATH_CHALLENGE frame, an endpoint MUST respond immediately by
+echoing the data contained in the PATH_CHALLENGE frame in a PATH_RESPONSE frame,
+with the following stipulation.  Since a PATH_CHALLENGE might be sent from a
+spoofed address, an endpoint MAY limit the rate at which it sends PATH_RESPONSE
+frames and MAY silently discard PATH_CHALLENGE frames that would cause it to
+respond at a higher rate.

I actually don't think that this is necessary. Here is my reasoning. PATH_CHALLENGES are cryptographically protected, and therefore if you are doing duplicate suppression on incoming messages, any spoofed PATH_CHALLENGE will be responded to only once, so as long as the other side is reasonable about how many PATH_CHALLENGEs it generates, then an attacker cannot cause you to send to quickly.

> +from the same local address on which the PATH_CHALLENGE was received, to the
+same remote address from which the PATH_CHALLENGE was received.
+
+
+### Completion
+
+A new address is considered valid when a PATH_RESPONSE frame is received
+containing data that was sent in a previous PATH_CHALLENGE. Receipt of an
+acknowledgment for a packet containing a PATH_CHALLENGE frame is not adequate
+validation, since the acknowledgment can be spoofed by a malicious peer.
+
+For path validation to be successful, a PATH_RESPONSE frame MUST be received
+from the same remote address to which the corresponding PATH_CHALLENGE was
+sent. If a PATH_RESPONSE frame is received from a different remote address than
+the one to which the PATH_CHALLENGE was sent, path validation is considered to
+have failed, even if the data matches that sent in the PATH_CHALLENGE.

What does "have failed" mean? That you abort the entire challenge operation? That gives an attacker a trivial way to stop migration. Or does it mean something else.

> +acknowledgment for a packet containing a PATH_CHALLENGE frame is not adequate
+validation, since the acknowledgment can be spoofed by a malicious peer.
+
+For path validation to be successful, a PATH_RESPONSE frame MUST be received
+from the same remote address to which the corresponding PATH_CHALLENGE was
+sent. If a PATH_RESPONSE frame is received from a different remote address than
+the one to which the PATH_CHALLENGE was sent, path validation is considered to
+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.

Same question here as above.

> +This document limits migration of connections to new client addresses.
+Migrating a connection to a new server address is left for future work. If a
+client receives packets from a new server address, the client MAY discard these
+packets.
+
+
+### Probing a New Path
+
+An endpoint MAY probe for peer reachability from a new local address using path
+validation {{migrate-validate}} prior to migrating the connection to the new
+local address.  Failure of path validation simply means that the new path is not
+usable for this connection.  Failure to validate a path does not cause the
+connection to end unless there are no valid alternative paths available.
+
+An endpoint uses a new connection ID for probes sent from a new local address,
+see {{migration-linkability}} for further discussion.

Does this mean that if the other side hasn't provided enough connection IDs you are just stalled?

> +As described in {{migration-response}}, an endpoint is required to validate a
+peer's new address to confirm the peer's possession of the new address.  Until a
+peer's address is deemed valid, an endpoint MUST limit the rate at which it
+sends data to this address.  The endpoint MUST NOT send more than a minimum
+congestion window's worth of data per estimated round-trip time (kMinimumWindow,
+as defined in {{QUIC-RECOVERY}}).  In the absence of this limit, an endpoint
+risks being used for a denial of service attack against an unsuspecting victim.
+Note that since the endpoint will not have any round-trip time measurements to
+this address, the estimate SHOULD be the default initial value (see
+{{QUIC-RECOVERY}}).
+
+If an endpoint skips validation of a peer address as described in
+{{migration-response}}, it does not need to limit its sending rate.
+
+
+#### Handling Address Spoofing by an On-path Attacker {#on-path-spoofing}

The procedure here doesn't seem like it works very well, as the attacker can force you onto a new path for quite some time by spoofing a single packet. you recover when one of two things happen:

1. You receive a higher-numbered packet.
2. Validation fails.

But both of these could take a really long time if one side is kind of quiet.

I have a nice attack that works if you allow server migration as well, but even this seems like it's not great.

> -migrating to a new network.  Connection migration allows a client to retain any
-shared state with a 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.
+QUIC allows connections to survive changes to endpoint addresses (that is, IP
+address and/or port), such as those caused by a endpoint migrating to a new
+network.  This section describes the process by which an endpoint migrates to a
+new address.
+
+An endpoint MUST NOT initiate connection migration before the handshake is
+finished and the endpoint has 1-RTT keys.
+
+This document limits migration of connections to new client addresses.
+Migrating a connection to a new server address is left for future work. If a
+client receives packets from a new server address, the client MAY discard these
+packets.

Isn't the answer that it MUST NOT follow the other procedures.

-- 
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/1249#pullrequestreview-108774337

---

From: ekr <[email-masked]>
Date: Mon, 02 Apr 2018 16:55:58 -0700

To add to my previous comment about attacks, in cases where one side has totally migrated (i.e., only one path is valid), then an attacker can also mess things up pretty severely by just spoofing a *response* to a PATH_CHALLENGE. I.e.,

- I am receiving packets from A
- A migrates and so sends me a packet from A'
- I send a PATH_CHALLENGE to A'
- If the attacker forwards the next packet from A' (likely a PATH_RESPONSE) but rewrites the source address to B, then I will consider the validation failed.

-- 
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/1249#issuecomment-378084457