Infinite Loops with Client Virtual Connection IDs #88
Comments
|
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. |
It sounds very expensive to globally share all of the VCIDs that clients have chosen!
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. |
|
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. |
|
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. |
|
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. |
As described in ietf-wg-masque#88, loop attacks are possible when clients pick the virtual connection ID. This change moves the responsibility of generating a Virtual Client Connection ID to the proxy and requires the proxy to generate unpredictable virtual connection IDs. Unfortunately, this change complicates the capsule exchange. Specifically, the proxy cannot send forwarded mode packets in the Target->Client direction until it knows that the client is ready to receive them. Previously, when the client chose the vcid, we could require that the client not share the vcid unless it's ready to receive with it. Now that the proxy chooses the client vcid, we need the client to signal it's ready to receive forwarded mode packets. To accomplish this, ACK_CLIENT_VCID is introduced. The ACK_CLIENT_VCID capsule solves the rule-readiness problem and maintains that the client can supply a Stateless Reset Token for resetting the client<->target tunnel.
As described in ietf-wg-masque#88, loop attacks are possible when clients pick the virtual connection ID. This change moves the responsibility of generating a Virtual Client Connection ID to the proxy and requires the proxy to generate unpredictable virtual connection IDs. Unfortunately, this change complicates the capsule exchange. Specifically, the proxy cannot send forwarded mode packets in the Target->Client direction until it knows that the client is ready to receive them. Previously, when the client chose the vcid, we could require that the client not share the vcid unless it's ready to receive with it. Now that the proxy chooses the client vcid, we need the client to signal it's ready to receive forwarded mode packets. To accomplish this, ACK_CLIENT_VCID is introduced. The ACK_CLIENT_VCID capsule solves the rule-readiness problem and maintains that the client can supply a Stateless Reset Token for resetting the client<->target tunnel.
|
Should be fixed with #104 |
As described in thread that begins in https://mailarchive.ietf.org/arch/msg/masque/y4M_VX7-dMvOqkhKoHCtKUgnomA/
I believe the possible mitigations are:
The text was updated successfully, but these errors were encountered: