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

[Martin Thomson <[e-mail]>]

@martinthomson commented on this pull request.

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
```

> +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.

```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
+
+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

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

> +* 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. 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.

```

> +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.

```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.

> +* 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. 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