Migration with zero-length CID is inadvisable

[martinthomson]

Not making a design/editorial call here. There is new normative language, so maybe it is design. But this is really just documenting an emergent property of the existing system. There are no concrete changes other than a stronger recommendation against migration in cases where it either doesn't work or would not provide the privacy properties we have attempted to guarantee.

Closes #3559.

[ianswett]

I think we already knew this, but it's also not that relevant to most migration scenarios when the client is migrating and has a 0-len CID, so I think it's fine.

[ianswett]

Suggested change

	{{preferred-address}}), packets sent on different paths will be linkable.
	{{preferred-address}}), packets sent on different paths are likely to be linkable.

[DavidSchinazi]

I'm not sure this guidance is correct. If the server has reason to believe migration won't work (due to source-IP routing or otherwise) it should send the disable_migration TP. It's perfectly reasonable to migrate when zero-length CIDs are in use if the server only has one connection on this port. Therefore I think we should stay away from the implicit signal "CID is zero-length" and instead use the explicit signal disable_migration.

[DavidSchinazi]

I'm failing to parse this first sentence.

[MikeBishop]

@DavidSchinazi, the issue is that, while the server might be confident it will work (and therefore not set the TP), the only way it works is by being highly linkable. If we think linkability is a bad thing, advising clients not to do it isn't unreasonable.

Of course, servers have other ways of making a connection linkable by observers if they choose to do so, and clients can't detect all of them. I'm not sure this warrants normative force; I'd simply mention that clients who intend to minimize linkability might want to consider that they're definitely linkable in this situation and could choose to avoid it.

[DavidSchinazi]

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.

[martinthomson]

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.

[DavidSchinazi]

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.

[erickinnear]

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.

[martinthomson]

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.

[janaiyengar]

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

[DavidSchinazi]

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.

[martinthomson]

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.

[erickinnear]

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.

[erickinnear]

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.

[erickinnear]

Latest changes look good!

[DavidSchinazi]

Thanks for incorporating my suggestions!

[igorlord]

Issue #3565 is prohibiting the use of preferred_address with 0-length CID. So this example is not possible and just confusing (since it is suggesting that the use of preferred_address with 0-length CID is possible).

[martinthomson]

Good catch. These were done in parallel without thinking much about their interactions. I've switched to using a different example.