Subject: Re: [quicwg/base-drafts] Server's preferred address (#1251)

From: Mike Bishop <[email-masked]>
Date: Mon, 02 Apr 2018 17:01:42 +0000 (UTC)

MikeBishop commented on this pull request.

> @@ -1791,6 +1811,64 @@ number. "packet_number_secret" is derived from the TLS key exchange,
 as described in Section 5.6 of {{QUIC-TLS}}.

+## Server Connection Migration {#migration-server}

I think the necessary assumption is that the server maintains the ability to send/receive from both addresses through the whole process.  So if the client's attempt to hand off fails, it can still continue with the original address.  In the more general P2P case, the server might not actually continue to have access to the original address, because it is actually changed network connections.

-- 
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/1251#discussion_r178590063

---

From: Mike Bishop <[email-masked]>
Date: Mon, 02 Apr 2018 17:06:48 +0000 (UTC)

> +time during the connection after the handshake is completed.  If this packet
+contains a PATH_CHALLENGE frame, the server sends a PATH_RESPONSE frame as per
+{{migrate-validate}}, but the server MUST continue sending all other packets
+from its original IP address.
+
+Once the server has received a non-probing packet on its preferred address which
+is the largest packet number seen so far, the server begins sending to the
+client exclusively from its preferred IP address.
+
+
+## Interaction of Client and Server Migration
+
+A client might need to perform a connection migration before the server's
+connection migration has completed.  In this case, the client SHOULD perform
+path validation to both the original and preferred server address from the
+client's new address concurrently.

Well, there are two pieces.  NAT rebinding means that, even if the client doesn't change its local address, the server will see a simultaneous migration.  So forbidding it seems problematic, since the server can't enforce it.  If it can't be totally forbidden, we could say that you SHOULD NOT attempt to perform a local migration until the handoff has completed.

I'm not convinced that abandoning one probe (because that local address is gone) and starting two in parallel is a combinatorial explosion -- it's two paths to probe, with an embedded preference between them if they both work.

-- 
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/1251#discussion_r178591287

---

From: Mike Bishop <[email-masked]>
Date: Mon, 02 Apr 2018 17:30:38 +0000 (UTC)

> +QUIC allows servers to accept connections on one IP address and attempt to
+transfer these connections to a more preferred address shortly after the
+handshake.  This section describes the protocol for migrating a connection to a
+new server address.
+
+Migrating a connection to a new server address mid-connection is left for future
+work. If a client receives packets from a new server address not indicated by
+the preferred_address transport parameter, the client SHOULD discard these
+packets.
+
+### Initiating Connection Migration
+
+A server initiates connection migration by including the preferred_address
+transport parameter in the TLS handshake.
+
+Once the handshake is finished, the client MUST initiate path validation (see

The server can't actually know if the client's probe fails to reach it for some reason, so it's going to have to tolerate clients failing to switch anyway.  This could probably become a SHOULD without changing logic on anyone's side.

-- 
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/1251#discussion_r178597389

---

From: Mike Bishop <[email-masked]>
Date: Mon, 02 Apr 2018 10:36:18 -0700

> @@ -1485,6 +1505,11 @@ 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.
 
+Differences in routing on the Internet might cause the same destination address
+and connection ID to reach a different server instance which does not posses the
+necessary connection state. Receiving a Stateless Reset in response to a probing
+packet SHOULD NOT terminate the connection, but MUST cause the endpoint to
+consider path validation to have failed.

Yes, it's something I realized when discussing the simultaneous migration case.  If the client probes both the original (anycast) and preferred (unicast) address from the new interface, the result is a race between a Stateless Reset from the anycast peer and a PATH_RESPONSE from the unicast peer.  Since the anycast endpoint is likely to be closer, the Stateless Reset will likely win.

However, it's not specific to this PR, so it's now #1259.

-- 
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/1251#discussion_r178598839

---

From: Mike Bishop <[email-masked]>
Date: Mon, 02 Apr 2018 17:55:07 +0000 (UTC)

For simplicity, I'm inclined to say it's the server's job to send a single working IP address to the client.  When we have a more complete server migration story, the server can just try multiple times / send multiple addresses.

Yes, just like in path validation, the server responds on the same address to the same address.

I don't see this as an attack, primarily because it's under the server's control.  The server could use a dedicated IP per cert to do handshakes, then hand off to a shared IP for existing connections.  No certs involved there.

-- 
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/1251#issuecomment-377993550

---

From: Martin Thomson <[email-masked]>
Date: Mon, 02 Apr 2018 17:38:58 -0700

martinthomson commented on this pull request.

It increases the complexity of implementations.  Right now, you probe one path, and if a new path presents itself, you abandon any previous path.  Having to move from 1 to N (even if N == 2), is more complex than we need.  The odds of needing to move just after the handshake are low enough that I would prefer to just say that the client can hold off on migration until after the server completes.  I guess that your response is that this only affects discretionary migrations.  But we can at least write that consideration down.

-- 
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/1251#discussion_r178687105

---

From: Mike Bishop <[email-masked]>
Date: Tue, 03 Apr 2018 10:39:52 -0700

@MikeBishop pushed 2 commits.

3066973  Don't call it server migration
f0cda65  Other review feedback

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1251/files/d06d132b95e2a36ad190d73c7166fdf2b8507e3e..f0cda65d0519c8e58130f93d5f9efb73a0bc3869

---

From: Martin Thomson <[email-masked]>
Date: Tue, 03 Apr 2018 15:20:37 -0700

> @@ -1864,7 +1945,7 @@ draining.  A key update might prevent the endpoint from moving from the closing
 state to draining, but it otherwise has no impact.
 
 An endpoint could receive packets from a new source address, indicating a client
-connection migration ({{migration}}), while in the closing period. An endpoint
+connection migration ({{migration}}}), while in the closing period. An endpoint

{{{{

-- 
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/1251#pullrequestreview-109136866

---

From: Mike Bishop <[email-masked]>
Date: Tue, 03 Apr 2018 23:01:37 +0000 (UTC)

@MikeBishop pushed 1 commit.

3f61dd9  }}}}

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1251/files/f0cda65d0519c8e58130f93d5f9efb73a0bc3869..3f61dd9e420707dde7321b421a1b73ff473c7e1d

---

From: Mike Bishop <[email-masked]>
Date: Thu, 05 Apr 2018 10:07:32 -0700

905eea3  {{[^{}]+}}}

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1251/files/3f61dd9e420707dde7321b421a1b73ff473c7e1d..905eea3660f484a310c8b533383f7dfe679c98a5

---

From: Mike Bishop <[email-masked]>
Date: Tue, 17 Apr 2018 23:32:18 +0000 (UTC)

Removed the dependency on #1259.

-- 
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/1251#issuecomment-382190841

---

From: Mike Bishop <[email-masked]>
Date: Tue, 17 Apr 2018 16:33:32 -0700

1cde293  Fix ref

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1251/files/0b2ded76cb862d3fd9261af46ed31e2809da09a9..1cde293397c7ea98d1b4e433d0fbbaa08b79a86b

---

From: janaiyengar <[email-masked]>
Date: Wed, 18 Apr 2018 02:31:53 +0000 (UTC)

janaiyengar commented on this pull request.

Thanks, Mike, just a few comments, mostly minor.

> @@ -1150,6 +1151,14 @@ language from Section 3 of {{!I-D.ietf-tls-tls13}}.
       };
       TransportParameter parameters<22..2^16-1>;
    } TransportParameters;
+
+   struct {
+     enum { IPv4(4), IPv6(6), (15)} ipVersion;
+     opaque ipAddress<4..2^8-1>;

Why does this need to be as long as 255 bytes? Or am I misreading again?

> @@ -1249,9 +1258,14 @@ stateless_reset_token (0x0006):
 : The Stateless Reset Token is used in verifying a stateless reset, see
   {{stateless-reset}}.  This parameter is a sequence of 16 octets.
 
-A client MUST NOT include a stateless reset token.  A server MUST treat receipt
-of a stateless_reset_token transport parameter as a connection error of type
-TRANSPORT_PARAMETER_ERROR.
+preferred_address (0x0004):
+
+: The server's Preferred Address is used to effect a server address migration at

s/a server address migration/change of a server address/

> +MUST continue sending all future packets to the server's original IP address.
+
+
+### Responding to Connection Migration
+
+A server might receive a packet addressed to its preferred IP address at any
+time after the handshake is completed.  If this packet contains a PATH_CHALLENGE
+frame, the server sends a PATH_RESPONSE frame as per {{migrate-validate}}, but
+the server MUST continue sending all other packets from its original IP address.
+
+The server SHOULD also initiate path validation of the client using its
+preferred address and the address from which it received the client probe.  This
+helps to guard against spurious migration initiated by an attacker.
+
+Once the server has completed its path validation and has received a non-probing
+packet on its preferred address which is the largest packet number seen so far,

How about: s/has received a non-probing packet on its preferred address which is the largest packet number seen so far/has received a non-probing packet with a new largest packet number  on its preferred address/

+connection migration has completed.  In this case, the client SHOULD perform
+path validation to both the original and preferred server address from the
+client's new address concurrently.
+
+If path validation of the server's preferred address succeeds, the client MUST
+abandon validation of the original address and migrate to using the server's
+preferred address.  If path validation of the server's preferred address fails,
+but validation of the server's original address succeeds, the client MAY migrate
+to using the original address from the client's new address.
+
+If the connection to the server's preferred address is not from the same client
+address, the server MUST protect against potential attacks as described in
+{{address-spoofing}} and {{on-path-spoofing}}.  In addition to intentional
+simultaneous migration, this might also occur because the client's access
+network used a different NAT binding for the server's preferred address.

Agree with Martin -- I think this needs more 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/1251#pullrequestreview-113055203

---

From: Mike Bishop <[email-masked]>
Date: Wed, 18 Apr 2018 20:51:30 +0000 (UTC)

};

The length prefix has to be at least one byte to accommodate any IP addresses; since it's a byte, it can represent a length up to 255 bytes.  Obviously, it wouldn't actually be 255 for IPv4 or IPv6.

-- 
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/1251#discussion_r182565424

---

From: Mike Bishop <[email-masked]>
Date: Wed, 18 Apr 2018 20:59:39 +0000 (UTC)

I've added some text, but it feels duplicative of {{address-spoofing}}.  Concrete suggestions of "more text" would be welcome.

-- 
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/1251#discussion_r182567661

---

From: Mike Bishop <[email-masked]>
Date: Wed, 18 Apr 2018 21:00:39 +0000 (UTC)

a82687c  Jana's feedback

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1251/files/1cde293397c7ea98d1b4e433d0fbbaa08b79a86b..a82687c35bc6b9d87540245bae44aefbdd298161

---

From: Mike Bishop <[email-masked]>
Date: Tue, 24 Apr 2018 16:05:17 -0700

a7ddd20  Changelog

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1251/files/a82687c35bc6b9d87540245bae44aefbdd298161..a7ddd20181b306a014cac2dbca7a4f8801f49538

---

From: Mike Bishop <[email-masked]>
Date: Wed, 25 Apr 2018 11:37:20 -0700

1f6c5a7  Change changelog

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1251/files/313489dd4e0a84184b215eb9620ee24f761457c6..1f6c5a7a45dfeefc273e5eac35f1ff05d9e7cdda

---

From: Rui Paulo <[email-masked]>
Date: Fri, 27 Apr 2018 17:37:26 +0000 (UTC)

This looks good to me!

-- 
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/1251#issuecomment-385041803