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

[ianswett <[e-mail]>]

@ianswett commented on this pull request.

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

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

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

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

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

> +
+* 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
+* use a different Stateless Reset Token key than other servers, or

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