Subject: [quicwg/base-drafts] 5tuple routing (#3536)

From: martinduke <[email-masked]>
Date: Fri, 20 Mar 2020 13:07:18 -0700

Addresses #3500.

I&#39;m flexible on wording and where exactly it lives in the document. I put it in Security Considerations.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Added considerations for 5tuple routing
  * s/may/can

-- File Changes --

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

-- Patch Links --

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

---

From: martinduke <[email-masked]>
Date: Fri, 20 Mar 2020 13:09:50 -0700

@martinduke pushed 1 commit.

657b103281dcbdceb2b1309dcdd1b1aae96fd71c  typo

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3536/files/b3e5a0c51f2e392366846026bafb98a0e654b4df..657b103281dcbdceb2b1309dcdd1b1aae96fd71c

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 20 Mar 2020 17:24:25 -0700

kazuho commented on this pull request.

Generally looks good, though I think there is one issue.

> +
+* Servers can use an out-of-band mechanism to deliver packets to the correct
+destination or transfer state from the original destination. Properly designed,
+this completely solves the problem and no further measures are necessary.
+
+* Sending the disable_active_migration transport parameter informs the client
+that any address change is likely to terminate the connection, which can lead it
+to use more aggressive timeouts or terminate connections when its IP address
+changes.
+
+* The preferred_address transport parameter can provide a path that does not use
+the 5-tuple based routers.
+
+* Servers MUST either use different Stateless Reset Token keys, or encode the
+client IP address and port in the Stateless Reset token. Doing neither will
+create a Reset Oracle (see {{reset-oracle}}).

The last two advices contradict against each other (or are incomplete).

The discussion about the use of preferred_address TP suggests that there is a direct path to any of the servers behind the server cluster, that are reachable from any client address. An attacker might try to use that path to let one of the servers generate a valid stateless token, and send it to the client.

As an example, consider the case of a server cluster consisting of two servers A and B. Server A is handling a connection QUIC connection that goes to client address X. If an attacker might send a packet directly to server B with source address of X, server B would send a valid stateless reset token to X, causing the connection to be reset.

Regarding specification, I think it might be better to simply refer to {{reset-oracle}} regarding the discussion of Stateless Resets, rather than trying to provide an exhaustive list of how to prevent attacks.

-- 
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/3536#pullrequestreview-378872391

---

From: Marten Seemann <[email-masked]>
Date: Fri, 20 Mar 2020 20:33:06 -0700

marten-seemann commented on this pull request.

> @@ -6387,6 +6387,29 @@ following properties:
 Note that these guarantees are the same guarantees provided for any NAT, for the
 same reasons.
 
+## Considerations for 5-tuple routing architectures
+
+QUIC servers can be deployed behind a 5-tuple based routing architecture that
+delivers packets based on both the source and destination IP addresses and
+ports. In such an architecture, clients that change IP address or port are
+likely to be routed to a different server. There are several actions that can
+mitigate or resolve operational and security issues in this case.
+
+* Servers can use an out-of-band mechanism to deliver packets to the correct
+destination or transfer state from the original destination. Properly designed,
+this completely solves the problem and no further measures are necessary.

How would you do this without implementing a CID-based (re-) routing scheme?

-- 
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/3536#pullrequestreview-378888454

---

From: ianswett <[email-masked]>
Date: Sat, 21 Mar 2020 12:02:48 -0700

ianswett commented on this pull request.

+

The more aggressive timeouts idea is new to me.  I think if the server wants a shorter idle timeout, it should specify that in the handshake via transport params.

So can the original path?  I suspect you have something in mind here, but I'm not completely sure what that is, so it might need to be spelled out more.

I'm not a big fan of having a MUST in this section.  If we need a restriction like this, I think it should be in the section on stateless resets.

-- 
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/3536#pullrequestreview-378942766

---

From: martinduke <[email-masked]>
Date: Wed, 25 Mar 2020 11:49:01 -0700

@martinduke commented on this pull request.

An example might be servers that are using QUIC-LB for just such a mapping, but they don't have a load balancer up front that is routing that way.

-- 
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/3536#discussion_r398091034

---

From: martinduke <[email-masked]>
Date: Wed, 25 Mar 2020 11:50:40 -0700

+

I'm not specifically referring to idle timeouts.  A client might send a PING periodically, for instance, to avoid 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/3536#discussion_r398092130

---

From: martinduke <[email-masked]>
Date: Wed, 25 Mar 2020 12:00:38 -0700

I dunno, 21.9 (Stateless Reset Oracle) already breaks the seal on normative text in Security Considerations. That may or may not be bad, I'd rather that be addressed in a different 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/3536#discussion_r398098283

---

From: martinduke <[email-masked]>
Date: Wed, 25 Mar 2020 12:22:58 -0700

OK, I'm rewriting this to be clearer.

-- 
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/3536#discussion_r398111025

---

From: martinduke <[email-masked]>
Date: Wed, 25 Mar 2020 12:23:38 -0700

Yes, good catch. I've rewritten it to reflect your concerns, though I shy away from just referring to the other section.

-- 
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/3536#discussion_r398111436

---

From: martinduke <[email-masked]>
Date: Wed, 25 Mar 2020 12:27:17 -0700

1406b1db65cfbc237e455d081f162307573eb9b3  Responded to reviews

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3536/files/657b103281dcbdceb2b1309dcdd1b1aae96fd71c..1406b1db65cfbc237e455d081f162307573eb9b3

---

From: martinduke <[email-masked]>
Date: Wed, 25 Mar 2020 12:29:27 -0700

I just completely rearranged the new section based on your input. See how it reads now.

Editors, I don't seem to have permission to request review. Can someone add @RyanTheOptimist?

-- 
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/3536#issuecomment-604040343

---

From: ianswett <[email-masked]>
Date: Wed, 25 Mar 2020 12:58:30 -0700

@ianswett commented on this pull request.

> +destination or transfer state from the original destination.
+
+* If the server has another address where the 5-tuple based routers are not on-
+path, the preferred_address transport parameter can communicate that address and
+thus support changing client IP addresses without difficulty.
+
+If a server does not implement one of the solutions above, it SHOULD send the
+disable_active_migration transport parameter to inform the client that any
+address change is likely to terminate the connection, which can lead it to use
+strategies to avoid NAT rebinding or terminate connections when its IP address
+changes.
+
+Regardless of other mitigations, servers behind 5-tuple routing MUST do one of
+the following to avoid creating a Reset Oracle ({{reset-oracle}}):
+
+* not send Stateless Reset under any circumstances, or

Isn't it valid to make the reset token a function of the CID?

-- 
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/3536#pullrequestreview-381489598

---

From: martinduke <[email-masked]>
Date: Wed, 25 Mar 2020 21:10:16 -0700

+

No, if solely a function of the CID, an attacker can rewrite the client address to route to a different server and then obtain a valid stateless reset token for use on the client.

-- 
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/3536#discussion_r398307138

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 25 Mar 2020 21:46:25 -0700

@kazuho commented on this pull request.

+
+If a server does not implement one of the solutions above, it SHOULD send the
+disable_active_migration transport parameter to inform the client that any
+address change is likely to terminate the connection, which can lead it to use
+strategies to avoid NAT rebinding or terminate connections when its IP address
+changes.
+
+Regardless of other mitigations, servers behind 5-tuple routing MUST do one of
+the following to avoid creating a Reset Oracle ({{reset-oracle}}):
+
+* not send Stateless Reset under any circumstances, or
+* use a different Stateless Reset Token key than other servers, or
+* encode the client IP address and port in the Stateless Reset token. If using
+the preferred_address transport parameter, the token must also encode the
+preferred address.

@martinduke Thank you for the changes. This is better.

I would not argue against having a list, however I am still uncomfortable of this being a exhaustive list (i.e. "MUST do one of ..).

To give an example that is missing, it is safe for all the servers to share the key, assuming that they encode the server ID (that would be unique to each server) to the Stateless Reset Token.

Just giving an example of some feasible design would be much better, though by doing so, this paragraph might become a repetition of {{reset-oracle}}.

-- 
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/3536#pullrequestreview-381699564

---

From: ianswett <[email-masked]>
Date: Thu, 26 Mar 2020 07:55:55 -0700

I agree with @kazuho that I don't think we should have a MUST here.

I don't think you want to include port here, otherwise NAT rebinds could result in a silent blackhole.

+

Fair point, I think I was intending to generate them as a function of CID and server IP.

What's a server in this context?

-- 
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/3536#pullrequestreview-382089532

---

From: martinduke <[email-masked]>
Date: Thu, 26 Mar 2020 11:17:50 -0700

+

Yes, this is similar to Kazuho's point. I'll edit.

-- 
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/3536#discussion_r398791668

---

From: martinduke <[email-masked]>
Date: Thu, 26 Mar 2020 11:18:06 -0700

+

Agreed I'll edit.

-- 
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/3536#discussion_r398791820

---

From: martinduke <[email-masked]>
Date: Thu, 26 Mar 2020 11:18:49 -0700

Well if the attacker tweaks the port it could go to a different server.

-- 
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/3536#discussion_r398792224

---

From: martinduke <[email-masked]>
Date: Thu, 26 Mar 2020 11:20:15 -0700

Other members of the pool that can be routed to.

-- 
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/3536#discussion_r398793139

---

From: ianswett <[email-masked]>
Date: Thu, 26 Mar 2020 11:22:31 -0700

That could happen, but I expect most deployments will want to seamlessly handle NAT rebinds, so typically changing the port will not change the server.

-- 
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/3536#discussion_r398794593

---

From: martinduke <[email-masked]>
Date: Thu, 26 Mar 2020 12:08:16 -0700

6962e63f1744bb1b6a29ef892a1555b1969410fe  Fix latest reviews

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3536/files/1406b1db65cfbc237e455d081f162307573eb9b3..6962e63f1744bb1b6a29ef892a1555b1969410fe

---

From: martinduke <[email-masked]>
Date: Thu, 26 Mar 2020 13:01:46 -0700

That would be wise, but this whole section is probably most important for servers in the cloud whose providers are choosing not to support QUIC-LB.

-- 
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/3536#discussion_r398855474

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 26 Mar 2020 16:38:30 -0700

Thank you for the changes. Looks fine to me, with one editorial concern below.

> @@ -6387,6 +6387,36 @@ following properties:

The text sounds a bit too affirmative to me.

Not all clients would support the preferred_address TP, even those supporting the TP might have reasons not to migrate to the preferred address. All the server can do is *hope* that they would migrate.

-- 
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/3536#pullrequestreview-382491874

---

From: martinduke <[email-masked]>
Date: Thu, 26 Mar 2020 17:17:22 -0700

You're right. I forgot response to preferred_address is a SHOULD. I'll fix it tomorrow.

-- 
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/3536#discussion_r398966717

---

From: Martin Thomson <[email-masked]>
Date: Thu, 26 Mar 2020 22:14:23 -0700

@martinthomson commented on this pull request.

GitHub believes that I have unposted comments.  They might be worth something.

I think that the point here is that some endpoints might choose to use address details they don't control in their routing decisions.  It's not just servers, but this spec doesn't allow for server addresses to change.  In any case, if the peer address does change, packets might not arrive at the correct endpoint instance.

+

I agree with Ian.  If this is the concrete recommendation, then advise that the idle timeout is set accordingly.

I don't think that this should be on the client to recognize.

The problem with a recommendation like this is that it could lead to terrible battery performance on devices.  Client's now need to recognize that.

This is a really interesting idea.  The server uses anycast for load balancing, but offloads to unicast as soon as possible to an address that is unique to the connection.

As Ian says, this probably needs more explanation.

It's probably enough to cite the other section, as Kazuho points out.

Is the security considerations section the right place for text like this?  Maybe this can be a new Section 5.2.3, after [Server Packet Handling](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#name-server-packet-handling).

-- 
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/3536#pullrequestreview-379082220

---

From: martinduke <[email-masked]>
Date: Fri, 27 Mar 2020 09:23:09 -0700

Is there a suggested change to this 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/3536#discussion_r399385482

---

From: martinduke <[email-masked]>
Date: Fri, 27 Mar 2020 09:24:43 -0700

Good idea.

-- 
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/3536#discussion_r399386609

---

From: martinduke <[email-masked]>
Date: Fri, 27 Mar 2020 09:33:55 -0700

Unfortunately, some of the reviews are hidden as obsolete. I want to respond to this by @martinthomson about disable_migration

> The problem with a recommendation like this is that it could lead to terrible battery performance on devices. Client's now need to recognize that.

I tried to not recommend anything here except to send disable_migration. The client is going to decide what to do with regard to NAT rebinding. If wired, I probably send more PINGs or something. If wireless, maybe not. If I'm quite sure I'm not behind a NAT, I probably do nothing. There's nothing normative here but to send the TP, so if people hate this I can just delete the explanation.

-- 
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/3536#issuecomment-605097700

---

From: martinduke <[email-masked]>
Date: Fri, 27 Mar 2020 09:43:27 -0700

7ad84a2aa5dd28bc6ed38d18fb5935600d6f3b38  Addressed most of MT's comments

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3536/files/6962e63f1744bb1b6a29ef892a1555b1969410fe..7ad84a2aa5dd28bc6ed38d18fb5935600d6f3b38

---

From: martinduke <[email-masked]>
Date: Fri, 27 Mar 2020 09:45:08 -0700

I moved the whole thing to Section 5 as @martinthomson suggested.

I've taken most of the other suggestions, but am not sure if the intro needs to change, or what exactly people don't like about the disable_migration explanatory 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/3536#issuecomment-605103330

---

From: martinduke <[email-masked]>
Date: Fri, 27 Mar 2020 11:54:29 -0700

8ea8ed410a5340a7289e29ac57c2f6e5d4a52d18  whitespace

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

---

From: Martin Thomson <[email-masked]>
Date: Sun, 29 Mar 2020 18:03:14 -0700

The change here to the semantics of disable_active_migration makes me a little uncomfortable.  I would suggest that we discuss this on-list a little.

I don't think that the implied semantic is entirely accurate.  In previous discussions, @nibanks pointed out that they would handle NAT rebinding with special logic (and likely move to close connections shortly afterwards).  That suggests that keep-alive logic was not necessary for those connections that might be affected.  However, this text suggests that if you see the transport parameter you would want to use keep-alives, or just do explicit closes within your understanding of the NAT timeout window to avoid the possibility of migration. 

Thus, rather than a "please avoid X", this turns into a "take active steps to prevent X".

I've also tried to make some editorial suggestions, but those you can take or leave.

> @@ -1156,6 +1156,36 @@ SHOULD ignore any such packets.
 
 Servers MUST drop incoming packets under all other circumstances.
 
+### Considerations for 5-tuple routing architectures
+
+QUIC servers can be deployed behind a 5-tuple based routing architecture that

```suggestion
QUIC endpoints can be deployed behind a 5-tuple based routing architecture that
```

```suggestion
ports. When routing depends on addresses that the endpoint does not control,
changes to the IP address or port of peers could result in packets being routed
to a different server. The following actions could mitigate or resolve
operational and security issues in this case:
```

> @@ -1156,6 +1156,36 @@ SHOULD ignore any such packets.
 
 Servers MUST drop incoming packets under all other circumstances.
 
+### Considerations for 5-tuple routing architectures
+

```suggestion
* Endpoints can use an out-of-band mechanism to deliver packets to the correct
```

+path, the preferred_address transport parameter can communicate that address and
+thus support changing client IP addresses without difficulty. For example, the
+initial address may route to a 5-tuple based load balancer, and the preferred
+address could indicate a separate server address with routing robust to client
+address changes. However, if the client does not use the preferred address,
+other measures are necessary.

```suggestion
* A server can request that a connection be migrated to an address that is
unique using the preferred_address transport parameter. For example, the initial
address may route to a 5-tuple based load balancer, and the preferred address
could indicate a separate server address that does not require the use of the
client address for routing. Note that clients could choose not to use the
preferred address.

```

```suggestion
address change is likely to terminate the connection. Clients might infer from
this that they might need to avoid NAT rebinding or terminate connections when
its IP address changes.
```

This is problematic, but I don't know how else to rephrase this statement.  The problem here is that this ADDS SEMANTICS to disable_active_migration.  That's a pretty big deal.

+path, the preferred_address transport parameter can communicate that address and
+thus support changing client IP addresses without difficulty. For example, the
+initial address may route to a 5-tuple based load balancer, and the preferred
+address could indicate a separate server address with routing robust to client
+address changes. However, if the client does not use the preferred address,
+other measures are necessary.
+
+If a server does not implement one of the solutions above, it SHOULD send the
+disable_active_migration transport parameter to inform the client that any
+address change is likely to terminate the connection, which can lead it to use
+strategies to avoid NAT rebinding or terminate connections when its IP address
+changes.
+
+Regardless of other mitigations, 5-tuple routing introduces new possibilities
+to create a Reset Oracle. An attacker could tweak the source address or port of

```suggestion
to create a stateless reset oracle. An attacker could tweak the source address
or port of
```

I think that the full name is necessary, and capitalization isn't quite right.

-- 
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/3536#pullrequestreview-383478266

---

From: Nick Banks <[email-masked]>
Date: Sun, 29 Mar 2020 18:11:22 -0700

> Thus, rather than a "please avoid X", this turns into a "take active steps to prevent X".

I'm actually fine with this. We were considering keep alives on the server side when we can't support migration (or NAT rebinding) based on the current infrastructure. So having the spec suggest keep alives to the client would be better. It would allow the client to choose if it would prefer keep alives or just to close the 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/3536#issuecomment-605733269

---

From: martinduke <[email-masked]>
Date: Mon, 30 Mar 2020 10:02:11 -0700

dbc1c1db9cd94641b6faf82547a7028c25eaad60  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/3536/files/8ea8ed410a5340a7289e29ac57c2f6e5d4a52d18..dbc1c1db9cd94641b6faf82547a7028c25eaad60

---

From: martinduke <[email-masked]>
Date: Mon, 30 Mar 2020 10:02:37 -0700

62b34f688440efd8db422ab23c8b103944d1d5a1  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/3536/files/dbc1c1db9cd94641b6faf82547a7028c25eaad60..62b34f688440efd8db422ab23c8b103944d1d5a1

---

From: martinduke <[email-masked]>
Date: Mon, 30 Mar 2020 10:03:55 -0700

0abc1ed6f33ec1a6b62a320e12e4fa9a36a9972b  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/3536/files/62b34f688440efd8db422ab23c8b103944d1d5a1..0abc1ed6f33ec1a6b62a320e12e4fa9a36a9972b

---

From: martinduke <[email-masked]>
Date: Mon, 30 Mar 2020 10:04:27 -0700

4dfae9c5d7613a386e5ed598a28d54aa2947579e  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/3536/files/0abc1ed6f33ec1a6b62a320e12e4fa9a36a9972b..4dfae9c5d7613a386e5ed598a28d54aa2947579e

---

From: martinduke <[email-masked]>
Date: Mon, 30 Mar 2020 10:04:42 -0700

2c81e06af7c8d22384868e28da3467bb1df910a1  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/3536/files/4dfae9c5d7613a386e5ed598a28d54aa2947579e..2c81e06af7c8d22384868e28da3467bb1df910a1

---

From: martinduke <[email-masked]>
Date: Mon, 30 Mar 2020 10:05:18 -0700

784000eefce372964fd50d4f11dca4f908ef0773  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/3536/files/2c81e06af7c8d22384868e28da3467bb1df910a1..784000eefce372964fd50d4f11dca4f908ef0773

---

From: martinduke <[email-masked]>
Date: Mon, 30 Mar 2020 10:07:36 -0700

88a71208e9d4db9fcd6f4724bc1476e1f604a4bf  removed inferences about disable_migration

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3536/files/784000eefce372964fd50d4f11dca4f908ef0773..88a71208e9d4db9fcd6f4724bc1476e1f604a4bf

---

From: martinduke <[email-masked]>
Date: Mon, 30 Mar 2020 10:10:11 -0700

After taking all suggestions from @martinthomson I simply deleted the explanatory text about sending disable_migration. I didn't see the stuff about NAT rebinding as prescriptive or changing the semantics, but it's non-normative, clients are gonna do what they gonna do, and it's not worth holding up the rest of this over. If people want to add NAT rebinding considerations to disable_migration we can fight that out in another issue.

-- 
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/3536#issuecomment-606125466

---

From: ianswett <[email-masked]>
Date: Mon, 30 Mar 2020 11:20:08 -0700

@ianswett approved this pull request.

> @@ -1156,6 +1156,34 @@ SHOULD ignore any such packets.

+### Considerations for 5-tuple routing architectures
+
+QUIC endpoints can be deployed behind a 5-tuple based routing architecture that
+delivers packets based on both the source and destination IP addresses and
+ports. When routing depends on addresses that the endpoint does not control,
+changes to the IP address or port of peers could result in packets being routed
+to a different server. The following actions could mitigate or resolve
+operational and security issues in this case:
+
+* Endpoints can use an out-of-band mechanism to deliver packets to the correct
+destination or transfer state from the original destination.
+
+* A server can request that a connection be migrated to an address that is
+unique using the preferred_address transport parameter. For example, the initial

```suggestion
stable using the preferred_address transport parameter. For example, the initial
```

> @@ -1156,6 +1156,34 @@ SHOULD ignore any such packets.

+### Considerations for 5-tuple routing architectures
+
+QUIC endpoints can be deployed behind a 5-tuple based routing architecture that
+delivers packets based on both the source and destination IP addresses and
+ports. When routing depends on addresses that the endpoint does not control,
+changes to the IP address or port of peers could result in packets being routed
+to a different server. The following actions could mitigate or resolve
+operational and security issues in this case:
+
+* Endpoints can use an out-of-band mechanism to deliver packets to the correct
+destination or transfer state from the original destination.
+
+* A server can request that a connection be migrated to an address that is
+unique using the preferred_address transport parameter. For example, the initial

If it was unique, it would be linkable, which seems sub-optimal.

-- 
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/3536#pullrequestreview-384113557

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Mar 2020 15:44:28 -0700

Uniqueness is correct though.  The point is that the address is *in itself* sufficient for routing, for which uniqueness is necessary.  Stability is necessary for other reasons.  

That all said, it is true that linkability is a natural consequence of this.  We need to highlight that.  Servers that use this style of demultiplexing will create linkability between paths.  That's a big deal that needs to be highlighted.

-- 
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/3536#discussion_r400538898

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Mar 2020 15:46:49 -0700

@martinthomson requested changes on this pull request.

Ian makes a great point about linkability that I didn't notice the first few times around.

If you migrate to a preferred address that is unique, then you create linkability between network paths.  A client CAN migrate at that point, but in doing so will be linkable.  That's not great.

(To be clear, this is not a consequence of this change, so I will be creating a new issue to track this.  I'm OK if we decide not to fix this in this PR, but I wanted to just put a hold on this issue as it seems like the right place to address 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/3536#pullrequestreview-384285877

---

From: ianswett <[email-masked]>
Date: Mon, 30 Mar 2020 15:53:26 -0700

FWIW, we have a number of cases when the destination IP and port + CID would route correctly, but the original IP(being anycast) would not always route correctly.

It's likely there are millions of connections to the destination IP being migrated to, but yes it's a smaller number than the anycast IP.

-- 
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/3536#issuecomment-606293369

---

From: martinduke <[email-masked]>
Date: Mon, 30 Mar 2020 16:00:47 -0700

So is the consensus here that we want to leave it with "unique"?

-- 
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/3536#discussion_r400545197