Should we mention that servers need to send ADDRESS_ASSIGN? about draft-ietf-masque-connect-ip HOT 13 CLOSED

For traditional proxy/VPN cases, I think this is required.

It's possible the client could not get an address assign, and but a blank/bogus source IP that it expects a proxy to overwrite, but I don't think that's a good idea (and would also change the checksum values of higher-level protocols).

Probably the best thing to say is that any peer that can send packets MUST first have received an ADDRESS_ASSIGN capsule.

from draft-ietf-masque-connect-ip.

I think we should keep the text on these capsules bidirectional. In the consumer VPN scenario, the client isn't going to send anything until it has received an ADDRESS_ASSIGN capsule. But in that same scenario, the same property isn't true of the server.

from draft-ietf-masque-connect-ip.

I agree that we should have the text be bidirectional—but I think just saying "an endpoint can only send packets after it receives an ADDRESS_ASSIGN capsule" meets that bill, right?

from draft-ietf-masque-connect-ip.

But in the consumer VPN scenario, the client isn't sending an ADDRESS_ASSIGN to the server. So if we apply your "an endpoint can only send packets after it receives an ADDRESS_ASSIGN capsule", then the server can't send any packets

from draft-ietf-masque-connect-ip.

How about we add some non-normative guidance text to resolve this? Like saying that in scenarios where addresses are not known before the request (e.g., the client doesn't know its address in the consumer VPN scenario) then the other endpoint would be well served to send ADDRESS_ASSIGN for things to work.

from draft-ietf-masque-connect-ip.

I think this would be easier to add text for if we had the high level usages named. Because clearly for the use cases where the masque proxy lends out an address to provide access from its point of presence it is clear that it does need to assign one. For the case of interconnecting networks it is instead fairly clear that some other level of configuration is necessary of both client and proxy to make this work in a secure fashion.

from draft-ietf-masque-connect-ip.

Since you used "clear" three times in your last comment, I think it's pretty clear to everyone when it makes sense to send ADDRESS_ASSIGN or not. Do we actually need to say anything in the draft?

from draft-ietf-masque-connect-ip.

Bad writing of me to use so much clear. I would argue that the text should make it clear that there are cases when it doesn't need to assign address. However, I would note that it actually becomes difficult for the server to judge this in the case of interconnecting networks. This due to that the defining behaviours for this usage comes first when the HTTP request has been accepted and the capsules with address assign request and route advertisements starts being sent. So I start to wonder if there isn't need for an parameter in the HTTP request if address is to be assigned, or does the equivalent of the address assigned capsule need to be moved to the HTTP request?

from draft-ietf-masque-connect-ip.

In practice, a CONNECT-IP server isn't going to be running in these multiple modes, and if it does, it'll know which mode it's in from the authentication that was carried in an HTTP header with the request. Do you have a use-case where the server could be confused here?

from draft-ietf-masque-connect-ip.

I think we have one case where it can become confusing. So an ATSSS enabled mobile (UE) uses MASQUE as part of its signalling for the traffic policies for flows. However a mobile is also often used to tether other devices. So it have both its own address and a local area network it like to tunnel over the same tunnel. So this confusion is something we can actually encounter when the UE has its own address and the tethered networks prefix. The existing solution when it comes to IPv6 has been the UE uses one or more of the addresses from the /64 for its own use, as well providing the LAN with addresses. However, that does create some issues, rather than having two /64s for IPv6. For IPv4 I think what one can assume here when it comes to address assignment is even more murky.

from draft-ietf-masque-connect-ip.

I wonder if we want something similar to SETTINGS to convey the types of CONNECT-IP a server is willing to participate in?

from draft-ietf-masque-connect-ip.

I really don't think the type of CONNECT-IP in use needs to be sent over the wire. The ATSSS server will know that it is an ATSSS server, and same for the client. I see Magnus' point that if the ATSSS server sends two prefixes to the client, the client doesn't know which /64 is for the UE and which one is for the tethered devices. However, since this problem is specific to ATSSS, I think that information can be conveyed in an ATSSS-specific extension capsule.

from draft-ietf-masque-connect-ip.

@DavidSchinazi I think I have to disagree here about that we should push this to usage specific extension. I think we need to resolve #54 for example as that is part of the request input that may make it easier to resolve the best way forward for the aspect of how and when servers need to send address_assign and how that impact the client.

from draft-ietf-masque-connect-ip.