Subject: Re: [quicwg/base-drafts] Migration with zero-length CID is inadvisable (#3563)

From: Mike Bishop <[email-masked]>
Date: Wed, 01 Apr 2020 12:58:53 -0700

@DavidSchinazi, the issue is that, while the server might be confident it will work (and therefore not set the TP), the only way it works is by being highly linkable.  If we think linkability is a bad thing, advising clients not to do it isn't unreasonable.

Of course, servers have other ways of making a connection linkable by observers if they choose to do so, and clients can't detect all of them.  I'm not sure this warrants normative force; I'd simply mention that clients who intend to minimize linkability might want to consider that they're definitely linkable in this situation and could choose to avoid 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/3563#issuecomment-607460087

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 14 Apr 2020 15:24:19 -0700

@janaiyengar commented on this pull request.

> +An endpoint SHOULD NOT initiate migration when a peer requests the use of a
+zero-length connection ID. If the peer routes incoming packets using the source
+address, migration might not be successful. If the peer routes incoming packets
+by assigning a unique destination address to the connection, which might be
+achieved using using the preferred_address transport parameter (see
+{{preferred-address}}), packets sent on different paths are likely to be
+linkable.

```suggestion
An endpoint SHOULD NOT initiate migration with a peer that uses a zero-length
connection ID, for two reasons. First, if the peer routes incoming packets using
the packets' source address, migration might not be successful. Second, if 
such a  peer routes incoming packets by assigning a unique destination address
to the connection, which can be achieved using using the preferred_address
transport parameter (see {{preferred-address}}), packets sent by this
endpoint over multiple paths are trivially linkable.
```

-- 
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/3563#pullrequestreview-393337540

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Apr 2020 15:27:09 -0700

@martinthomson pushed 1 commit.

492c09329130b5524b5eaa2dfd409d2ca3070901  Two reasons

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3563/files/caf949d0d2c0f00f614205644b9895d2a63011cd..492c09329130b5524b5eaa2dfd409d2ca3070901

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 14 Apr 2020 15:27:37 -0700

@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/3563#pullrequestreview-393338980

---

From: David Schinazi <[email-masked]>
Date: Tue, 14 Apr 2020 17:13:03 -0700

@DavidSchinazi commented on this pull request.

> @@ -2246,6 +2246,14 @@ that packet numbers cannot be used to correlate activity.  This does not prevent
 other properties of packets, such as timing and size, from being used to
 correlate activity.
 
+An endpoint SHOULD NOT initiate migration with a peer that uses a zero-length
+connection ID, for two reasons. First, if the peer routes incoming packets using

I don't think the first reason makes sense here. If the server routes incoming packets using source addresses, then it should send the disable_migration transport parameter. That's true regardless of connection ID length. We shouldn't make clients worry about about how the server does its routing.

-- 
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/3563#pullrequestreview-393376946

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Apr 2020 17:45:24 -0700

@martinthomson commented on this pull request.

This is specifying the client reaction to the situation when disable_active_migration is not set, that's all.  Mostly the second reason applies here, as you are right that the server is responsible for that, but it doesn't mean that it is untrue.

-- 
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/3563#discussion_r408516738

---

From: David Schinazi <[email-masked]>
Date: Tue, 14 Apr 2020 17:54:23 -0700

I don't think the spec should encourage clients to build workarounds to broken servers that don't send the right transport parameters. If disable_migration isn't sent by the server, then the client needs to be able to safely assume that the server will try to make routing on this connection work across migrations.

-- 
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/3563#discussion_r408519183

---

From: Eric Kinnear <[email-masked]>
Date: Tue, 14 Apr 2020 18:05:16 -0700

@erickinnear commented on this pull request.

+An endpoint SHOULD NOT initiate migration with a peer that uses a zero-length
+connection ID, for two reasons. First, if the peer routes incoming packets using
+the packets' source address, migration might not be successful. Second, if
+such a  peer routes incoming packets by assigning a unique destination address

Tiny nit

```suggestion

These are both things that _might_ be the case in some situations, but also have situations where they might work. 

That said, it does seem like this first one is a bit different from the second one -- for the first one there's always going to be some risk that your packets don't get to the right place, hence the encouragement to probe the new path first. 

Yes, that could be a server that was supposed to set the TP, but even if it wasn't, having a zero length CID isn't really the thing that says "be careful here", and saying SHOULD NOT migrate in such a case seems a bit excessive. If we want to say "be careful, if someone screwed up their routing for whatever reason (which might correlate more with zero length CIDs) you might not hear anything back" then that's not unreasonable, but I think that's already kind of described in the whole path validation process -- you want to make sure the packets really got to the person with whom you've got a connection.

+An endpoint SHOULD NOT initiate migration with a peer that uses a zero-length
+connection ID, for two reasons. First, if the peer routes incoming packets using
+the packets' source address, migration might not be successful. Second, if
+such a  peer routes incoming packets by assigning a unique destination address
+to the connection, which can be achieved using using the preferred_address
+transport parameter (see {{preferred-address}}), packets sent by this
+endpoint over multiple paths are trivially linkable.

In contrast to my comment on the first part, saying SHOULD NOT do trivially linkable things seems reasonable -- by default, don't, and if you've got some reason to believe that you don't care or can avoid that likability, then that's on you.

-- 
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/3563#pullrequestreview-393391099

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 14 Apr 2020 18:07:11 -0700

@janaiyengar pushed 1 commit.

3722988b7c139c915092397bec3cdac81d7c12c9  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3563/files/492c09329130b5524b5eaa2dfd409d2ca3070901..3722988b7c139c915092397bec3cdac81d7c12c9

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Apr 2020 18:09:49 -0700

What Eric said.  This alone doesn't really motivate the SHOULD NOT; it is just a reason that you might come to regret ignoring it; what matters is the other point.

-- 
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/3563#discussion_r408523260

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 14 Apr 2020 18:20:02 -0700

@DavidSchinazi : I don't think the spec is encouraging building around broken behavior. The actions are the same at the client whether the rationale is #1 or #2. The rationale simply explains the SHOULD NOT, and is not a concern for the client. Can you perhaps suggest a text change to clarify what you would like to see instead?

-- 
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/3563#discussion_r408525839

---

From: David Schinazi <[email-masked]>
Date: Tue, 14 Apr 2020 20:16:50 -0700

Here is a text proposal that addresses my concerns:

```
An endpoint SHOULD NOT initiate migration with a peer that uses a zero-length
connection ID, because traffic over the new path might be trivially linkable to
traffic over the old one. If the server is able to route packets with a
zero-length connection ID to the right connection, it means that the server is
using other information to demultiplex packets (for example, the server can
assign a unique destination address to the connection, by using the
preferred_address transport parameter; see {{preferred-address}}), and this
other information is not encrypted and can be used to link paths.
```

This provides the same normative guidance, but makes it clear to client implementors that the only motivation for this recommendation is linkability.

-- 
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/3563#discussion_r408556637

---

From: Martin Thomson <[email-masked]>
Date: Sun, 19 Apr 2020 22:48:43 -0700

Thanks David.  I think that is clearer and have tweaked it.  I'm not sure that the last statement is entirely correct, because - at least in theory - there are systems with properties similar to connection IDs.  However, I'm OK with adding that on the assumption that an endpoint will need to be aware of the scheme so that they can participate in 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/3563#discussion_r411108809

---

From: Martin Thomson <[email-masked]>
Date: Sun, 19 Apr 2020 22:49:17 -0700

8ec6c3ab72ea75f5e2dc07abce7b0640076552f2  @DavidSchinazi's suggested text with tweaks

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3563/files/3722988b7c139c915092397bec3cdac81d7c12c9..8ec6c3ab72ea75f5e2dc07abce7b0640076552f2

---

From: Eric Kinnear <[email-masked]>
Date: Sun, 19 Apr 2020 23:17:23 -0700

@erickinnear approved this pull request.

Latest changes look good!

-- 
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/3563#pullrequestreview-396165319

---

From: David Schinazi <[email-masked]>
Date: Mon, 20 Apr 2020 09:50:45 -0700

@DavidSchinazi approved this pull request.

Thanks for incorporating my suggestions!

-- 
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/3563#pullrequestreview-396634794

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 20 Apr 2020 15:00:30 -0700

@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/3563#pullrequestreview-396843695

---

From: ianswett <[email-masked]>
Date: Mon, 20 Apr 2020 19:09:03 -0700

@ianswett 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/3563#pullrequestreview-396938839

---

From: Igor Lubashev <[email-masked]>
Date: Wed, 29 Apr 2020 09:18:57 -0700

@igorlord commented on this pull request.

> @@ -2246,6 +2246,16 @@ that packet numbers cannot be used to correlate activity.  This does not prevent
 
+An endpoint SHOULD NOT initiate migration with a peer that uses a zero-length
+connection ID, because traffic over the new path might be trivially linkable to
+traffic over the old one. If the server is able to route packets with a
+zero-length connection ID to the right connection, it means that the server is
+using other information to demultiplex packets. For example, the server can
+assign an address that is unique to the connection using the preferred_address
+transport parameter; see {{preferred-address}}.  Information that might allow

Issue #3565 is prohibiting the use of preferred_address with 0-length CID.  So this example is not possible and just confusing (since it is suggesting that the use of preferred_address with 0-length CID is possible).

-- 
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/3563#pullrequestreview-402828578

---

From: Martin Thomson <[email-masked]>
Date: Wed, 29 Apr 2020 17:57:08 -0700

7d5089a754a6cecce519d6c20325ec0adaf65f2e  Use a different example

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3563/files/8ec6c3ab72ea75f5e2dc07abce7b0640076552f2..7d5089a754a6cecce519d6c20325ec0adaf65f2e

---

From: Martin Thomson <[email-masked]>
Date: Wed, 29 Apr 2020 17:57:46 -0700

Good catch.  These were done in parallel without thinking much about their interactions.  I've switched to using a different example.

-- 
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/3563#discussion_r417696916