Reuse possibilities in address-assignment capsules about draft-ietf-masque-connect-ip HOT 11 CLOSED

from draft-ietf-masque-connect-ip.

This is a matter of policy that the CONNECT-IP spec cannot tackle without breaking reasonable use-cases. Overlap between addresses is not a problem here because different CONNECT-IP streams have different namespaces. For example, as a VPN server I could decide to ADDRESS_ASSIGN 10.0.0.1 to every single client that connects to me and then have a NAT outside of CONNECT-IP such that the NAT knows which CONNECT-IP stream to send which response packet on.

So lets assume a client would do the following two HTTP Masque requests:

Stream 4: Connect-IP: Iproto=TCP Stream 8: Connect-IP:ipproto=UDP

Can the server now send the same IP address in Address-assign capsules on both streams? I would think this works as they are not requesting overlapping spaces.

Agreed, this should just work.

Can a client send yet another request: Stream 12: Connect-IP I no limitations but it is on the same QUIC connection. I guess the answer is no as there are no hard binding that guarantees that this request is from the same underlying client, and there might be HTTP intermediaries combining requests into one QUIC connection. What happens if it request the same address using the Address-request capsule that was assigned in the first streams?

That's a matter of server policy. The server is allowed to use overlapping address pools and demultiplex on the stream ID if it wants to.

I think this issue contains two questions, first what is the authority model here. Are we assuming a single client so that assigning a resource multiple times with overlapping space on different tunnel streams are not an issue from a security perspective?

I don't see any security issue with overlapping IP address space.

Secondly, even if we know it is a single client can we ensure that it works and have text that makes it so. I think more specific filter has its points as it enables future extensions like header compression to be applied to a subset of traffic for a larger assignment where it functions. However, I think some rules about precedence here will be required.

Having the clients scope their requests tightly is a good idea, and does enable future extensions like compression. But overlap isn't a problem.

from draft-ietf-masque-connect-ip.

@gloinul any further thoughts on this issue?

from draft-ietf-masque-connect-ip.

So I think the core of the issue was really if a client can attempt to superset or sub-set a previous request. Thus expecting to receive data over the narrower scope. I would note that have partial overlapping requests would be bad, but that is not obvious that it can occur here.

from draft-ietf-masque-connect-ip.

@gloinul can you clarify what the actual problem is? Overlap is not a problem at all. If there is overlap, the server just assigns a different address.

from draft-ietf-masque-connect-ip.

The server shouldn't give out a subset of an address assignment to a different client if one client already owns the entire address. Perhaps this just needs a clarification that the server needs to be sensible?

from draft-ietf-masque-connect-ip.

So what I am asking about is the possibility for a single client to keep on using the same address for a number of Connect-IP requests. I can see this working in either of two ways.

A) Client starts with a Connect-IP address and becomes granted an external IP address without limitations. Thereafter it makes a new Connect-IP request for example a specific destination IP address. This would be a sub-set of the first request and if that includes Request-Add for the external address it was given in the first request. Is this allowed?

B) The client ask for specific target and get an external address for this specific target. Then it asks for another target and include a request-addr then unless its was assigned to another client I assume the server should grant this.

So the reasons for doing A would be to avoid the issue that can occur in B) that server has handed out the address for a specific target to another client when client later asks for it.

The reasons for wanting to do this smaller specific Connect-IP requests is to enable context specific additional communication. Header compression could be one such case, but other usage also exists. These would clearly be extensions but, the possibility to define these extensions in this fashion is dependent on what is allowed.

from draft-ietf-masque-connect-ip.

possibility for a single client to keep on using the same address for a number of Connect-IP requests

Concurrently? Or serially? Concurrently, this is not possible (assuming there are no restrictions), because if you have 2 simultaneous sessions using the same IP, the target server cannot tell which session a particular packet should go onto. If you mean serially, then the existing ADDRESS_REQUEST allows a client to indicate which address it would like. It is up to the server to determine if it can or cannot fulfill that request.

Going over your scenarios:

external IP address without limitations [...] Is this allowed?

This cannot be allowed per my understanding of what you mean by "limitations". Once an IP is given to a client, no other connection can use that IP since all protocols have been delegated to the earlier session.

The client ask for specific target and get an external address for this specific target

Here, the limitation is for a particular tuple. This should be allowed assuming there is no conflict that would make packet routing ambiguous.

Header compression could be one such case, but other usage also exists

(B) is already supported today with the ADDRESS_REQUEST capsule and the existing request scoping.

from draft-ietf-masque-connect-ip.

I do mean concurrently, and I think it is actually fairly easy to determine compared to more restricted scope and a full IP request as long as all further restricted requests do not overlap with each other.

I guess B) isn't to problematic assuming that the server implementation is co-operating and avoids giving the address to other clients.

from draft-ietf-masque-connect-ip.

Yes, although we should probably add some text that a server SHOULD ensure it's the same client before enabling some sort of sharing like this, per some authentication/authorization mechanism if it's promising IP exclusivity.

from draft-ietf-masque-connect-ip.

Discussed this amongst editors at lunch today. Our plan is for Magnus to write an extension for this, so we are closing this issue with no action.

from draft-ietf-masque-connect-ip.