Re: [quicwg/base-drafts] Disable Migration field in SPA (#3898)

[Kazuho Oku <[e-mail]>]

@kazuho commented on this pull request.



> @@ -2178,12 +2180,16 @@ before the handshake is confirmed, as defined in section 4.1.2 of {{QUIC-TLS}}.
 
 If the peer sent the disable_active_migration transport parameter, an endpoint
 also MUST NOT send packets (including probing packets; see {{probing}}) from a
-different local address to the address the peer used during the handshake. An
-endpoint that has sent this transport parameter, but detects that a peer has
-nonetheless migrated to a different remote address MUST either drop the incoming
-packets on that path without generating a stateless reset or proceed with path
-validation and allow the peer to migrate. Generating a stateless reset or
-closing the connection would allow third parties in the network to cause
+different local address to the address the peer used during the handshake. If
+the server sets the Disable Migration field in the preferred_address transport
+parameter, the client MUST NOT send packets from a different local address to
+the server's preferred address.

> First, it is only SPAs with Disable Migration flag that are at issue here.

Based on the discussion on the issue (e.g., https://github.com/quicwg/base-drafts/issues/3765#issuecomment-657903203), I think we tend to agree that the problem exists to the same extent, for servers disabling migration on SPA and those do not. This is essentially a server asking the client to migrate to a specific server address based on the address that the client is using, and therefore not wanting the client to move to a different client address.

Therefore, if we are going to have any requirement, I think we should recommend *one* behavior, regardless of the use of the disable-migration flag.

Having different behaviors might seem like a way of restoring the old behavior (I have reservations as stated in https://github.com/quicwg/base-drafts/issues/3765#issuecomment-657925719). But regardless, I would argue that having different behavior is an unnecessary complexity without technical merit.

-- 
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/3898#discussion_r454134660