Infinite Loops with Client Virtual Connection IDs

[martinduke]

As described in thread that begins in https://mailarchive.ietf.org/arch/msg/masque/y4M_VX7-dMvOqkhKoHCtKUgnomA/

I believe the possible mitigations are:

• Have the server pick the virtual client connection ID
• Require the proxy to open a new target-facing UDP socket for each connection request
• Not do virtual client connection IDs at all

[tfpauly]

Or require that if servers share a VIP, they need to coordinate on their VCID mappings? That seems to be a simple requirement.

I don't think removing VCIDs or allowing servers to select the CIDs that clients advertise to targets is feasible.

[martinduke]

Or require that if servers share a VIP, they need to coordinate on their VCID mappings? That seems to be a simple requirement.

It sounds very expensive to globally share all of the VCIDs that clients have chosen!

I don't think removing VCIDs or allowing servers to select the CIDs that clients advertise to targets is feasible.

Why? The client sends REGISTER_CLIENT_CID to the proxy, but without including a virtual. The client can't start sending packets with that CID because the proxy hasn't confirmed that there is no collision at its target-facing socket. The ACK_CLIENT_CID could contain the Virtual client CID the proxy wants the client to use.

This is, IIUC, exactly how target CIDs work.

[tfpauly]

I think it's OK if we wanted the VCID to be determined by the proxy — I was saying that it's not OK for the actual client CID to be determined by the proxy.

If we just have the VCID be determined by the proxy, does that sufficiently solve the issue? If so, that's probably the best outcome.

[martinduke]

I think the spec currently has the client picking the actual CID (subject to rejection by the proxy due to a collision)? I don't yet see an attack if the client picks with proxy approval.

I agree that the more CIDs the proxy picks, the less it's open to this sort of attack. On the other hand, I've been playing a bit with similar attacks in a forward direction, and haven't gotten them to work. It also would be nicely symmetric if the client picked both target-facing CIDs and the proxy picked both CIDs on the proxy-client hop (i.e. REGISTER_CID and ACK_CID had the same format for * = {CLIENT, TARGET}).

But to answer your question, yes, that would solve this particular attack.

[martinduke]

If the proxy picks the virtual CID, it also MUST NOT just reuse the client-provided one, because of this vulnerability.

The same goes for target connection IDs: I can easily recreate this attack in the forward direction if the proxy just reuses the target CID for the virtual. In fact, if the relationship between CID and Virtual CIDs is predictable, I can do a forward direction infinite loop with a colluding target.

But I guess that's already good advice if we're trying to prevent linkabilty between target-side and client-side.

[tfpauly]

Should be fixed with #104