Subject: [quicwg/base-drafts] Disable Migration field in SPA (#3898)

From: Mike Bishop <[email-masked]>
Date: Mon, 13 Jul 2020 14:03:22 -0700

Fixes #3765.

(Built on top of #3807 to align with that change.  Retarget PR before merging.)
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3898

-- Commit Summary --

  * Disable Migration field

-- File Changes --

    M draft-ietf-quic-transport.md (35)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3898.patch
https://github.com/quicwg/base-drafts/pull/3898.diff

-- 
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/3898

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 13 Jul 2020 14:52:06 -0700

@kazuho commented on this pull request.

Thank you for working on the PR. I like the idea of adding a field to the SPA transport parameter. Looks good modulo the point below.

> @@ -2178,12 +2180,16 @@ before the handshake is confirmed, as defined in section 4.1.2 of {{QUIC-TLS}}.
 
 If the peer sent the disable_active_migration transport parameter, an endpoint
 also MUST NOT send packets (including probing packets; see {{probing}}) from a
-different local address to the address the peer used during the handshake. An
-endpoint that has sent this transport parameter, but detects that a peer has
-nonetheless migrated to a different remote address MUST either drop the incoming
-packets on that path without generating a stateless reset or proceed with path
-validation and allow the peer to migrate. Generating a stateless reset or
-closing the connection would allow third parties in the network to cause
+different local address to the address the peer used during the handshake. If
+the server sets the Disable Migration field in the preferred_address transport
+parameter, the client MUST NOT send packets from a different local address to
+the server's preferred address.

I think it might make sense to drop this MUST NOT as a whole:
* What if SPA includes an address of a different address family than the original address? The client has to use a different local address.
* A QUIC stack might be letting the operating system select the outgoing address, by skipping the call to `bind`, and letting `connect` select the *source* address. I do not think we'd want to forbid such QUIC stacks not supporting SPA.

FWIW, I do not think there is a big problem in client switching to a different address when migrating the preferred address with migration disabled. If the path is established, then there's no problem. If the path fails to establish, endpoints can continue talking on the original path.

-- 
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/3898#pullrequestreview-447635683

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 13 Jul 2020 16:25:39 -0700

@igorlord commented on this pull request.

@kazuho, it is a good point about a different address family.

> * What if SPA includes an address of a different address family than the original address? The client has to use a different local address.

If a server does not want client to change addresses, which it must do, if changing IP families, it will just not supply the alternative IP family SPA, so the Disable Migration flag can apply only to the same family as the handshake address.  Or each family may get its own flag, which increases flexibility.

> * A QUIC stack might be letting the operating system select the source address, by skipping the call to bind, and letting connect select that address. I do not think we'd want to forbid such QUIC stacks not supporting SPA.

First, it is only SPAs with Disable Migration flag that are at issue here.  In any case, I am ok with all s/MUST/SHOULD/g in regard to disabling migration, since unintentional migration happens, which can lead to poor performance for the client.  In case of the client that does not bind, Disable Migration is a hint, and the client can always try harder to follow it, since it is in its interests.  That client can, for example, actually bind another socket to the address selected by the kernel and use that socket for the subsequent communication w/ the server.

> FWIW, I do not think there is a big problem in client switching to a different address when migrating the preferred address with migration disabled. If the path is established, then there's no prob…

It is a problem (big or small is for the client to decide), if the server is chosen based on the client's original network attachment, and the client decides to migrate to a network provider that is inappropriate for the chosen server (during SPA migrations or not).  If the client tries, and the path fails to establish, the client wasted an rtt or possibly some timeout.  Or the path may actually get established, but the performance will be poor.  The client is better off quickly re-establishing a new connection.

-- 
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/3898#discussion_r454002904

---

From: Igor Lubashev <[email-masked]>
Date: Mon, 13 Jul 2020 17:22:23 -0700

@igorlord requested changes on this pull request.

We need to clarify what to do about source addresses when changing protocol families.

You may want to specify that when Disable Migration is set, to migrate to an SPA of a different address family, the client MUST (SHOULD?) use a source address belonging to the same network attachment interface as the handshake address.

I think we could replace MUST with SHOULD in regard to `disable_active_migration` and `Disable Migration`.  Nothing here is enforceable, since unintended migrations can always happen.  The effect is likely similar.

> @@ -5078,6 +5086,7 @@ Preferred Address {
   IPv4 Port (16),
   IPv6 Address (128),
   IPv6 Port (16),
+  Disable Migration (8),

We've had a proposal to make this flag per-address.  Need to land this discussion.  If we adopt the suggestion above about Disable Migration means for switching to a different protocol family, this becomes easier to reason about a per-family flag.

-- 
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/3898#pullrequestreview-447699048

---

From: Martin Thomson <[email-masked]>
Date: Mon, 13 Jul 2020 18:58:28 -0700

@martinthomson commented on this pull request.

I'm going to ask that this go to the list first.

   IPv4 Port (16),
   IPv6 Address (128),
   IPv6 Port (16),
+  Disable Migration (8),

Let's phrase this positively, no matter which way we resolve the per-family question.

-- 
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/3898#pullrequestreview-447731434

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 13 Jul 2020 19:21:05 -0700

IPv4 Port (16),
   IPv6 Address (128),
   IPv6 Port (16),
+  Disable Migration (8),

I think my not-so-strong preference would be to call this value "disable_active_migration" so that it would be consistent with the Transport Parameter that we use to advertise the property of the original address.

-- 
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/3898#discussion_r454058155

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 13 Jul 2020 23:27:16 -0700

@janaiyengar commented on this pull request.

This is going to be a bit tricky.

Yeah, this is getting tricky. I think we can say "SHOULD use the same network interface" when changing to the server's SPA. The server will also have to do the validation dance with the client on the new client address from the SPA.

-- 
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/3898#pullrequestreview-447820847

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 13 Jul 2020 23:37:51 -0700

> First, it is only SPAs with Disable Migration flag that are at issue here.

Based on the discussion on the issue (e.g., https://github.com/quicwg/base-drafts/issues/3765#issuecomment-657903203), I think we tend to agree that the problem exists to the same extent, for servers disabling migration on SPA and those do not. This is essentially a server asking the client to migrate to a specific server address based on the address that the client is using, and therefore not wanting the client to move to a different client address.

Therefore, if we are going to have any requirement, I think we should recommend *one* behavior, regardless of the use of the disable-migration flag.

Having different behaviors might seem like a way of restoring the old behavior (I have reservations as stated in https://github.com/quicwg/base-drafts/issues/3765#issuecomment-657925719). But regardless, I would argue that having different behavior is an unnecessary complexity without technical merit.

-- 
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/3898#discussion_r454134660

---

From: Mike Bishop <[email-masked]>
Date: Tue, 14 Jul 2020 13:42:41 -0700

@MikeBishop commented on this pull request.

   IPv4 Port (16),
   IPv6 Address (128),
   IPv6 Port (16),
+  Disable Migration (8),

That was my intent.  I don't really care which way it's pointed, but pointing the TP and the TP-field in opposite directions is needlessly confusing.

-- 
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/3898#discussion_r454632176

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 14 Jul 2020 13:45:16 -0700

@ekinnear commented on this pull request.

   IPv4 Port (16),
   IPv6 Address (128),
   IPv6 Port (16),
+  Disable Migration (8),

Agreed, it would be nice to have them be in the same direction (and especially the name "Disable Active Migration" since they have the same meaning)

-- 
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/3898#discussion_r454633584

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 14 Jul 2020 13:46:11 -0700

That's a totally different discussion that we've had a few times already. Happy to have it again, but let's do that in the issue, or a different issue, but certainly not in this PR.

-- 
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/3898#discussion_r454634061

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 14 Jul 2020 13:47:03 -0700

I don't know that we want to tackle network interfaces here, that's a much larger thing. Let's keep that separate and cover the regular TP too if we decide to do that?

-- 
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/3898#discussion_r454634475