Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Migration with zero-length CID is inadvisable #3563

Merged
merged 8 commits into from
May 14, 2020
Merged

Migration with zero-length CID is inadvisable #3563

Changes from 1 commit
Commits
Show all changes
8 commits
Select commit Hold shift + click to select a range
455fb97
Migration with zero-length CID is inadvisable
martinthomson Mar 31, 2020
caf949d
Wordz is harrd
martinthomson Apr 1, 2020
492c093
Two reasons
martinthomson Apr 14, 2020
3722988
Update draft-ietf-quic-transport.md
janaiyengar Apr 15, 2020
8ec6c3a
@DavidSchinazi's suggested text with tweaks
martinthomson Apr 20, 2020
7d5089a
Use a different example
martinthomson Apr 29, 2020
d29840a
CIDs are requested in this context
martinthomson May 10, 2020
b400f09
reflow
martinthomson May 10, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 7 additions & 7 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2246,13 +2246,13 @@ that packet numbers cannot be used to correlate activity. This does not prevent
other properties of packets, such as timing and size, from being used to
correlate activity.

An endpoint SHOULD NOT initiate migration when a peer requests the use of a
zero-length connection ID. If the peer routes incoming packets using the source
address, migration might not be successful. If the peer routes incoming packets
by assigning a unique destination address to the connection, which might be
achieved using using the preferred_address transport parameter (see
{{preferred-address}}), packets sent on different paths are likely to be
linkable.
An endpoint SHOULD NOT initiate migration with a peer that uses a zero-length
martinthomson marked this conversation as resolved.
Show resolved Hide resolved
connection ID, for two reasons. First, if the peer routes incoming packets using
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the first reason makes sense here. If the server routes incoming packets using source addresses, then it should send the disable_migration transport parameter. That's true regardless of connection ID length. We shouldn't make clients worry about about how the server does its routing.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is specifying the client reaction to the situation when disable_active_migration is not set, that's all. Mostly the second reason applies here, as you are right that the server is responsible for that, but it doesn't mean that it is untrue.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the spec should encourage clients to build workarounds to broken servers that don't send the right transport parameters. If disable_migration isn't sent by the server, then the client needs to be able to safely assume that the server will try to make routing on this connection work across migrations.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are both things that might be the case in some situations, but also have situations where they might work.

That said, it does seem like this first one is a bit different from the second one -- for the first one there's always going to be some risk that your packets don't get to the right place, hence the encouragement to probe the new path first.

Yes, that could be a server that was supposed to set the TP, but even if it wasn't, having a zero length CID isn't really the thing that says "be careful here", and saying SHOULD NOT migrate in such a case seems a bit excessive. If we want to say "be careful, if someone screwed up their routing for whatever reason (which might correlate more with zero length CIDs) you might not hear anything back" then that's not unreasonable, but I think that's already kind of described in the whole path validation process -- you want to make sure the packets really got to the person with whom you've got a connection.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What Eric said. This alone doesn't really motivate the SHOULD NOT; it is just a reason that you might come to regret ignoring it; what matters is the other point.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@DavidSchinazi : I don't think the spec is encouraging building around broken behavior. The actions are the same at the client whether the rationale is #1 or #2. The rationale simply explains the SHOULD NOT, and is not a concern for the client. Can you perhaps suggest a text change to clarify what you would like to see instead?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here is a text proposal that addresses my concerns:

An endpoint SHOULD NOT initiate migration with a peer that uses a zero-length
connection ID, because traffic over the new path might be trivially linkable to
traffic over the old one. If the server is able to route packets with a
zero-length connection ID to the right connection, it means that the server is
using other information to demultiplex packets (for example, the server can
assign a unique destination address to the connection, by using the
preferred_address transport parameter; see {{preferred-address}}), and this
other information is not encrypted and can be used to link paths.

This provides the same normative guidance, but makes it clear to client implementors that the only motivation for this recommendation is linkability.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks David. I think that is clearer and have tweaked it. I'm not sure that the last statement is entirely correct, because - at least in theory - there are systems with properties similar to connection IDs. However, I'm OK with adding that on the assumption that an endpoint will need to be aware of the scheme so that they can participate in it.

the packets' source address, migration might not be successful. Second, if
such a peer routes incoming packets by assigning a unique destination address
janaiyengar marked this conversation as resolved.
Show resolved Hide resolved
to the connection, which can be achieved using using the preferred_address
transport parameter (see {{preferred-address}}), packets sent by this
endpoint over multiple paths are trivially linkable.
Copy link
Contributor

@erickinnear erickinnear Apr 15, 2020 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In contrast to my comment on the first part, saying SHOULD NOT do trivially linkable things seems reasonable -- by default, don't, and if you've got some reason to believe that you don't care or can avoid that linkability, then that's on you.


Unintentional changes in path without a change in connection ID are possible.
For example, after a period of network inactivity, NAT rebinding might cause
Expand Down