From b9ca466b3f577689ce7a86131e541f7d4904d5f4 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 12 Jan 2021 14:11:36 +1100 Subject: [PATCH 1/3] A new IP ... is good for linkability. Closes #4531. --- draft-ietf-quic-transport.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index e39aa7c870..7c638c51b2 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2642,14 +2642,14 @@ alternative services {{?ALTSVC=RFC7838}}. Information that might allow correct routing of packets across multiple network paths will also allow activity on those paths to be linked by entities other than the peer. -A client might wish to reduce linkability by employing a new connection ID and -source UDP port when sending traffic after a period of inactivity. Changing the -UDP port from which it sends packets at the same time might cause the packet to -appear as a connection migration. This ensures that the mechanisms that support -migration are exercised even for clients that do not experience NAT rebindings -or genuine migrations. Changing port number can cause a peer to reset its -congestion control state (see {{migration-cc}}), so the port SHOULD only be -changed infrequently. +A client might wish to reduce linkability by switching to a new connection ID, +source UDP port, or IP address (see {{?RFC4941}}) when sending traffic after a +period of inactivity. Changing the UDP port from which it sends packets at the +same time might cause the packet to appear as a connection migration. This +ensures that the mechanisms that support migration are exercised even for +clients that do not experience NAT rebindings or genuine migrations. Changing +port number can cause a peer to reset its congestion control state (see +{{migration-cc}}), so the port SHOULD only be changed infrequently. An endpoint that exhausts available connection IDs cannot probe new paths or initiate migration, nor can it respond to probes or attempts by its peer to From 0d415bafc49e90f21c320b4470aa211d6536c769 Mon Sep 17 00:00:00 2001 From: Jana Iyengar Date: Tue, 12 Jan 2021 16:13:39 -0800 Subject: [PATCH 2/3] addresses, not just ports Co-authored-by: Martin Thomson --- draft-ietf-quic-transport.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 7c638c51b2..4fda47b1b0 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2644,12 +2644,12 @@ those paths to be linked by entities other than the peer. A client might wish to reduce linkability by switching to a new connection ID, source UDP port, or IP address (see {{?RFC4941}}) when sending traffic after a -period of inactivity. Changing the UDP port from which it sends packets at the +period of inactivity. Changing the address from which it sends packets at the same time might cause the packet to appear as a connection migration. This ensures that the mechanisms that support migration are exercised even for clients that do not experience NAT rebindings or genuine migrations. Changing -port number can cause a peer to reset its congestion control state (see -{{migration-cc}}), so the port SHOULD only be changed infrequently. +address can cause a peer to reset its congestion control state (see +{{migration-cc}}), so addresses SHOULD only be changed infrequently. An endpoint that exhausts available connection IDs cannot probe new paths or initiate migration, nor can it respond to probes or attempts by its peer to From 62f49dbc0d3ed90de95367f1ec323e534e2c257b Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Wed, 13 Jan 2021 11:15:34 +1100 Subject: [PATCH 3/3] migration Co-authored-by: Jana Iyengar --- draft-ietf-quic-transport.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-transport.md b/draft-ietf-quic-transport.md index 4fda47b1b0..b8bd696e51 100644 --- a/draft-ietf-quic-transport.md +++ b/draft-ietf-quic-transport.md @@ -2645,7 +2645,7 @@ those paths to be linked by entities other than the peer. A client might wish to reduce linkability by switching to a new connection ID, source UDP port, or IP address (see {{?RFC4941}}) when sending traffic after a period of inactivity. Changing the address from which it sends packets at the -same time might cause the packet to appear as a connection migration. This +same time might cause the server to detect a connection migration. This ensures that the mechanisms that support migration are exercised even for clients that do not experience NAT rebindings or genuine migrations. Changing address can cause a peer to reset its congestion control state (see