Subject: [quicwg/base-drafts] Servers can't migrate. Period. (#2031)

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Nov 2018 20:48:40 -0800

This was a bit weak in the past, but it is part of our defense strategy for attacks on migration and rebinding.  Not that this totally prevents attack, but it means that an attacker looking to force a migration has to observe and race packets sent by both endpoints if this is true.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Servers can't migrate.  Period.

-- File Changes --

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

-- Patch Links --

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

---

From: Marten Seemann <[email-masked]>
Date: Tue, 20 Nov 2018 20:51:12 -0800

marten-seemann approved this pull request.

I'm not happy with the fact that servers can't migrate in general, but this change makes the current state clearer and more consistent.

-- 
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/2031#pullrequestreview-177076109

---

From: Martin Thomson <[email-masked]>
Date: Tue, 20 Nov 2018 20:52:55 -0800

Yes.  I am similarly unhappy, but the task to properly define migration for both clients and servers ultimately ends up with something as complex as ICE.  We don't want to repeat that mistake.  ICE started small, then turned into an RFC that was so large and complex people were scared of it.

-- 
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/2031#issuecomment-440530402

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 21 Nov 2018 00:50:20 -0800

kazuho approved this pull request.

-- 
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/2031#pullrequestreview-177128244

---

From: MikkelFJ <[email-masked]>
Date: Wed, 21 Nov 2018 02:12:43 -0800

I also dislike this asymmetry but the primary case for client server symmetry is in mostly static P2P server networks.

However, if two voice chat users connect via QUIC using NAT hole punching, this becomes difficult to manage without migration. But I see @martinthomson's point on ICE. How can QUIC realistically handle this use case, because I think it has to, in some version at least.

-- 
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/2031#issuecomment-440608670

---

From: Mike Bishop <[email-masked]>
Date: Wed, 21 Nov 2018 17:48:32 +0000 (UTC)

I think a general P2P use of QUIC uses ICE directly to find the peer addresses, then uses a broader definition of "address" when doing migration within QUIC.  A draft that described the interaction between the two of them would be welcome, but it doesn't need to be in the core transport spec.

-- 
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/2031#issuecomment-440754728

---

From: Mike Bishop <[email-masked]>
Date: Wed, 21 Nov 2018 09:48:56 -0800

MikeBishop approved this pull request.

-- 
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/2031#pullrequestreview-177363299

---

From: MikkelFJ <[email-masked]>
Date: Wed, 21 Nov 2018 10:11:06 -0800

@MikeBishop but even if punching via ICE, both endpoints could be travelling (like moving from train wifi to station wifi). I like the idea of fixing the server from an attack perspective, but I'm afraid it is too restrictive.

-- 
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/2031#issuecomment-440761717

---

From: Mike Bishop <[email-masked]>
Date: Wed, 21 Nov 2018 10:57:19 -0800

@mikkelfj, that's not a barrier.  IIUC, ICE should track those changes of IP address.  What I'm suggesting is that P2P would delegate all the address management to ICE, and consider the endpoints that ICE provides it as being the same "address".  From P2P QUIC's standpoint, no one ever changes 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/2031#issuecomment-440774771

---

From: MikkelFJ <[email-masked]>
Date: Wed, 21 Nov 2018 11:09:43 -0800

I'm not up to speed on all the punc techs, but my impression is that you often want to end up in a situation where there is no middle man involved after the initial connection is established. Any local NAT boxes would have been punched. I'm not sure this is possible with just QUIC, but some driver logic should be able to provide an IP/port combo to the other end. But this is for stationary NAT.

You can also imagine an intial rendezvous service that is not necessarily punching NAT but rather provides a location service. Once you connect using driver logic, the IP/port is handed to QUIC, and then migration becomes an issue because there is only the endpoints to track the migrations. This is the two traveller scenario as opposed to domestic Skype or Bittorrent.

-- 
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/2031#issuecomment-440778341

---

From: erickinnear <[email-masked]>
Date: Wed, 21 Nov 2018 13:07:14 -0800

I agree with @marten-seemann (and others above): I'd prefer if we could have more symmetry in this area and would be interested in exploring that later, but I also see why it's necessary to stick with this for v1. 

-- 
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/2031#issuecomment-440808346

---

From: janaiyengar <[email-masked]>
Date: Wed, 21 Nov 2018 15:52:37 -0800

What @MikeBishop said. I would expect ICE to be used alongside QUIC for P2P signaling, and ICE implementations expose  encapsulations  as interfaces to stacks, so QUIC will largely be out of the loop when it comes to migration and such. I think it is a larger project to figure out if ICE and QUIC can be combined in some interesting way to make P2P better.

-- 
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/2031#issuecomment-440852969

---

From: janaiyengar <[email-masked]>
Date: Wed, 21 Nov 2018 15:52:51 -0800

janaiyengar approved this pull request.

-- 
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/2031#pullrequestreview-177465230

---

From: janaiyengar <[email-masked]>
Date: Wed, 21 Nov 2018 15:53:09 -0800

Merged #2031 into master.

-- 
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/2031#event-1981326363