Subject: [quicwg/base-drafts] TP to disable migration (#1447)

From: Mike Bishop <[email-masked]>
Date: Thu, 14 Jun 2018 17:06:51 -0700

Fixes #1271.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * TP to disable migration

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1447.patch
https://github.com/quicwg/base-drafts/pull/1447.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/1447

---

From: Praveen Balasubramanian <[email-masked]>
Date: Thu, 14 Jun 2018 17:32:11 -0700

Looks good to me but I wonder if we should make this transport parameter agnostic of client / server (i.e. who initiates the connection first) and just refer to a peer disabling migration. If we want to address server migration and peer-to-peer, then we may need to make it apply in both directions. @MikeBishop you may want to add @ianswett as a reviewer as he also requested this TP.

-- 
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/1447#issuecomment-397478506

---

From: Nick Banks <[email-masked]>
Date: Thu, 14 Jun 2018 17:37:27 -0700

nibanks requested changes on this pull request.

I agree with @pravb here. I don't think we should make this server specific.

-- 
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/1447#pullrequestreview-129014332

---

From: erickinnear <[email-masked]>
Date: Thu, 14 Jun 2018 18:50:06 -0700

erickinnear commented on this pull request.

> @@ -1289,6 +1290,13 @@ preferred_address (0x0004):
 : The server's Preferred Address is used to effect a change in server address at
   the end of the handshake, as described in {{preferred-address}}.
 
+disable_migration (0x0009):
+
+: The server does not support migration of connections to a different IP
+  address. Clients MUST NOT send any packets, including probing packets, from an
+  IP address other than that used to perform the handshake.  This parameter

This seems mildly ambiguous -- isn't there a scenario where the client doesn't necessarily have control over that IP? I'm not saying that that's the common case, but it could happen that the client doesn't just have a different port after a NAT rebinding, but that it actually shows up as coming from a different address entirely depending on how things are routed between NATs, especially after inactivity. 

-- 
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/1447#pullrequestreview-129022900

---

From: erickinnear <[email-masked]>
Date: Thu, 14 Jun 2018 22:35:29 -0700

I think most of my objection here relates to terminology. Perhaps: 
```
The server does not support connection migration ({{migration}}). 
Clients MUST NOT send any packets, including those intended for 
path validation ({{migrate-validate}}), from a local endpoint other
than that used to perform the handshake. ...
```

-- 
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/1447#discussion_r195636668

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 14 Jun 2018 22:52:41 -0700

kazuho commented on this pull request.

My understanding is that one of the motives of having this option is to allow running QUIC servers behind a load balancer that distributes the load based on the 5-tuple.

Assuming that is true, it is necessary to minimize the chance of client rebinding to not only a different IP address but to a different port as well.

-- 
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/1447#discussion_r195638485

---

From: Praveen Balasubramanian <[email-masked]>
Date: Fri, 15 Jun 2018 08:27:01 -0700

pravb commented on this pull request.

@kazuho yes 5-tuple or 3-tuple i.e. only IP addresses. Load balancers can operate in both modes for UDP (the latter for handling IP fragmented UDP flows). In the latter case port changes will not cause an issue. Regardless as I said if the server indicates no support for migration then automatically turning on keep-alives should be recommended to deal with NAT rebinding. 

-- 
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/1447#discussion_r195776760

---

From: Martin Thomson <[email-masked]>
Date: Fri, 15 Jun 2018 09:21:49 -0700

I really don't understand this PR.  If you don't want someone to use a new connection ID, then don't give them one.  I'd be happier saying that endpoints MUST NOT knowingly use a new IP address without a new connection ID.

-- 
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/1447#issuecomment-397672427

---

From: Praveen Balasubramanian <[email-masked]>
Date: Fri, 15 Jun 2018 09:24:46 -0700

@martinthomson are we ruling out use of multiple connection IDs on the same address? That seems too restrictive. I always prefer explicit mechanisms compared to inferred behavior for most flexibility. I also like this PR because it allows the client to automatically turn on keep-alives to protect against NAT rebinding when the server states that it is not capable of supporting migration. 

-- 
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/1447#issuecomment-397673268

---

From: Nick Banks <[email-masked]>
Date: Fri, 15 Jun 2018 09:25:16 -0700

@martinthomson if you go the route of depending on CID availability, it doesn't necessarily give you the indication that even NAT rebinding won't work and that the client should use a more aggressive keep alive timer for long standing connections. I personally prefer the explicit design of 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/1447#issuecomment-397673439

---

From: Martin Thomson <[email-masked]>
Date: Fri, 15 Jun 2018 09:37:00 -0700

@pravb, I didn't say anything about multiple connection IDs on the same address.  I'm not sure how it has any bearing on this, other than to say that if you don't provide connection IDs, this won't happen.  But here's the thing I don't get: if you are routing based solely on 5-tuple, why use connection IDs at all?

If we want a keep-alive function, then we should explicitly build one.

-- 
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/1447#issuecomment-397676602

---

From: Mike Bishop <[email-masked]>
Date: Fri, 15 Jun 2018 09:50:05 -0700

Without connection IDs, you're limited to a single session per server per client IP, which aligns poorly with multiple clients behind a NAT. So simply omitting CIDs isn't the best choice. 

Not supplying additional CIDs is certainly an option - pick one and use it for the lifetime of the connection. But that goes against our existing advice to rotate CIDs after a period of quiescence.

Keeping the mechanics of CID choice and the client's ability to change its source address separate feels cleanest 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/1447#issuecomment-397680274

---

From: Mike Bishop <[email-masked]>
Date: Fri, 15 Jun 2018 10:18:59 -0700

As to polarity - in this version of QUIC, at least, clients initiate all migrations.  The most a server can do is suggest a different IP address to which the client should migrate, which the client can opt not to do.  If a client doesn't support migration, it need not tell the server -- it just doesn't migrate.

Should a future / different version of QUIC enable spontaneous server migration or provide a mechanism to *force* peer migration, it would make sense for this parameter to be bilateral in that version.

-- 
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/1447#issuecomment-397687470

---

From: Mike Bishop <[email-masked]>
Date: Fri, 15 Jun 2018 10:26:32 -0700

@MikeBishop pushed 1 commit.

b789dd8  local address

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

---

From: Nick Banks <[email-masked]>
Date: Fri, 15 Jun 2018 10:50:08 -0700

nibanks approved this pull request.

LGTM

-- 
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/1447#pullrequestreview-129263031

---

From: ianswett <[email-masked]>
Date: Sun, 17 Jun 2018 23:46:53 -0700

ianswett approved this pull request.

Looks good.  Not giving out connection Ids seems clever, but if that's the only mechanism for disabling migration, then it would seem to discourage people for giving them out for other reasons.

-- 
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/1447#pullrequestreview-129441251

---

From: Praveen Balasubramanian <[email-masked]>
Date: Mon, 18 Jun 2018 09:04:20 -0700

pravb approved this pull request.

Looks good since we don't need to handle polarity in this QUIC  version.

-- 
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/1447#pullrequestreview-129630848

---

From: janaiyengar <[email-masked]>
Date: Mon, 18 Jun 2018 17:25:01 -0700

janaiyengar commented on this pull request.

One comment inline. Also, I would suggest (as I did in my comment on the issue) that: (i) a server should be allowed to detect a client violation of this TP and close the connection with PROTOCOL_VIOLATION (or a new error if this doesn't sit well with folks), (ii) the text should make it clear that a NAT rebinding may still result in path validation.

+disable_migration (0x0009):
+
+: The server does not support connection migration ({{migration}}). Clients MUST

It's true that we only support client-driven migrations, but I think there's value in keeping most of the text agnostic to polarity. Is there a reason to disallow this TP in the opposite direction? It'll be a NO-OP, but we don't need to disallow it, I think.

-- 
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/1447#pullrequestreview-129782442

---

From: erickinnear <[email-masked]>
Date: Mon, 18 Jun 2018 22:44:21 -0700

@janaiyengar Minor clarification of (ii) above: NAT rebinding may result in a full migration, not just path validation, right? (With the current text indicating that servers are free to recognize that it's just a NAT rebinding and behave accordingly.)

In other words, I think the operative intent here is that the client not initiate migration, with a note that just because the client isn't sending from a different endpoint that the server may still see NAT rebinding. 

-- 
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/1447#issuecomment-398281005

---

From: janaiyengar <[email-masked]>
Date: Tue, 19 Jun 2018 18:58:50 +0000 (UTC)

@erickinnear Yes, though I wouldn't call it a "full migration", because all you have is a server potentially responding to what seems like a migration. Basically [Section 6.8.3](http://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.6.8.3) applies.

-- 
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/1447#issuecomment-398508475

---

From: Mike Bishop <[email-masked]>
Date: Wed, 20 Jun 2018 10:03:38 -0700

f94df3a  Bilateral, error

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

---

From: Rui Paulo <[email-masked]>
Date: Fri, 22 Jun 2018 10:26:56 -0700

rpaulo commented on this pull request.

> @@ -1656,7 +1664,12 @@ 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.
+finished and the endpoint has 1-RTT keys.  An endpoint also MUST NOT initiate
+connection migration if the peer sent the `disable_migration` transport
+parameter during the handshake.  An endpoint which has sent this transport
+parameter, but detects that a peer has nonetheless migrated to a different
+network MAY treat this as a connection error of type INVALID_MIGRATION.
+However, note that not all changes of peer address are intentional migrations.

I really think we should mention NAT rebinding here and how `disable_migration` doesn't mean the endpoint doesn't need to handle NAT rebinding.

-- 
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/1447#pullrequestreview-131279954

---

From: erickinnear <[email-masked]>
Date: Fri, 22 Jun 2018 10:44:48 -0700

new address.

Good point! If you send the parameter, you still need to implement a response to path challenge frames, for example. I'll comment on the issue with more thoughts, but the text should at least mention that you still need to be prepared for that to happen. 

-- 
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/1447#discussion_r197520017

---

From: Mike Bishop <[email-masked]>
Date: Fri, 22 Jun 2018 11:39:10 -0700

9cb1000  Discuss rebinding briefly

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1447/files/f94df3aed2d9ebe2a41dfd7d0f1fe354be103b5b..9cb100067a0c892b68a8ca5156fadc22f5365932

---

From: Rui Paulo <[email-masked]>
Date: Fri, 22 Jun 2018 18:30:17 -0700

The latest addition looks good to me, thanks!

-- 
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/1447#issuecomment-399620647

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Jun 2018 15:55:40 -0700

Merged #1447.

-- 
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/1447#event-1702649372