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

[Martin Thomson <[e-mail]>]

@martinthomson commented on this pull request.

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

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

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.

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

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.

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

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.

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

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

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

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