Multiplexing more sessions into same UDP port

[lasseleegaard]

Currently mosh uses a port range to support multiple sessions to the same host. In the corporate world with many firewalls and many restrictions, opening ranges a thousand ports wide is always a hassle if not impossible. Looking at it with a security mindset it does not look much better.

So - the feature request is:
Create option/change default behavior to allow mosh to use one single UDP port on the server side to multiplex more sessions into - just like we are used to with SSH and many other protocols.

The use of UDP/22 could be considered and/or the registration of an new low port number at IANA.
Alternatively - just make it configurable.
One of the advantages of using port 22 is that it is already used for SSH and interactice shells and convincing the Mordacs of this world to allow UDP in addition to TCP would be easier.

[keithw]

I think we could probably do this. The best idea I've had for how it would work is:

1. New clients pass a "-p" flag to the server to indicate they are multiplex-capable.

2. The server continues to open a local port (like 60001). But it also reads a config file (like /etc/mosh.conf) telling it to instruct incoming clients to send on, e.g., UDP port 22. It prints a MOSH CONNECT line like "MOSH CONNECT 60001 22 [key]".

2b) If there is a /etc/mosh.conf specifying use of a multiplexing daemon but no "-p" flag, the server prints an error message telling the user to upgrade their client.

3. The client uses 22 as its real port number. But it also prepends a 16-bit network-order integer containing the 60001 to every datagram.

4. "moshd" receives these datagrams on port 22 and resends them to the indicated local port ("indicated" at the beginning of each client->server datagram).

Characteristics of the design:

1. Clients and servers both have to be upgraded to use multiplex, but existing clients will still work with new servers that don't require a multiplex.

2. When an existing client tries to connect to a multiplex-requiring server, it will get a clear error message.

3. The server doesn't have to communicate with "moshd", doesn't have to reserve any resources with it, and doesn't have to worry about something lingering when it shuts down.

4. Remote hosts will gain the ability to send UDP packets to ANY port on the local machine.

5. The "multiplex" port number field becomes an added header on client->server datagrams, but we don't otherwise modify the SSP protocol.

[keithw]

If you can think of any idea for how this could work with existing clients (by only modifying the server), I would love that. You could imagine a moshd that would take incoming packets (with no port number prepended) and somehow infer which subset of mosh-servers to send them to (maybe by tracking the sequence numbers, or maybe by letting the mosh-server request all incoming packets from a particular IP address that it's "attached" to?). It's ok to send the packets to multiple mosh-servers because the ones where it doesn't decrypt will just ignore it.

But this seems like it may be a flakier design overall than explicitly indicating the port number.

[nicowilliams]

@keithw:

I assume the port 22 UDP proxy would add client source address/port info to the datagram before forwarding to the requested protocol.

The thing about clients getting to send UDP to any port on the server is... not cool. Options include: a) the server tells the proxy what port it has open then the proxy allows datagrams only to those ports, b) define a UDP port range for this? but this gets us back to session number limits, c) ?? I prefer (a). You'll want the server to tell the proxy what port it will use in a way that other unprivileged local processes can't.

[nicowilliams]

Also (though you already knew this, it's worth restating): this is probably the single most important feature w.r.t. getting enterprises that have SSH gateways to setup Mosh gateways. Godspeed.

[keithw]

Yeah, we may also want to wrap the whole thing in another encryption key (which the moshd would have), to satisfy the people who hate that we send sequence numbers and port numbers in the clear. (Even though SSH, TLS and DTLS send sequence numbers in the clear too.)

[nicowilliams]

Seems like a waste to add that additional encryption when the ciphertext will be going only over IPC to... processes spawned by the sender. What does matter is that users not be able to extract that info out of mosh servers, and that there not be a DoS as a result of re-writing the port number in the datagram sent by the client (but the latter was already a requirement).

The protocol by which a server gets spawned and it then tells the proxy what UDP port it opened, that is critical.

[calmh]

While this would be lovely and is for sure necessary, this:

4) Remote hosts will gain the ability to send UDP packets to ANY port on the local machine.

is not a desirable feature...

[keithw]

Sorry, I should be clear that this "additional encryption" would be going from the client to moshd, and would encrypt the "real" port number and sequence number. This is to satisfy the people who want there to be some ambiguity between different Mosh sessions to the same server.

We probably will need to find a way to stop (4) as well (remote hosts gain the ability to send UDP packets to ANY port).

[calmh]

@keithw How would there be any ambiguity, given there'll be a different remote IP and port number for each session?

(Not that I have anything against encrypting the port and/or sequence numbers if someone really wants to, I just don't see what extra security it buys anyone... However point number four above would be a very serious flaw if implemented.)

[nicowilliams]

@keithw: well, you're already not getting privacy protection for the target port number (you're not using ESP). Sure, you could get a slight measure of traffic analysis protection from encrypting this in the packets to the proxy, but it's not much when you consider that the replies will come back from an identifiable port number on the server. To me this would be unnecessary complexity since now you'd have to have two sets of session keys: one for the client<->proxy and one for the client<->server.

[keithw]

You don't have to tell me! Participate in the discussion on mosh-devel if you want to have an impact. People like Jacob Appelbaum and Seth Schoen want this, despite the fact that the privacy improvements will be only statistical (and will depend on the presence or absence of credible chaff).

[nicowilliams]

Guys, you reject crypto agility, and generic composition of unencumbered AEAD cipher modes on complexity grounds but would accept a dubious traffic analysis protection feature? Come now, be consistent :)

[nvx]

Rather than relaying the packets to another UDP port on the local machine, why not open a UNIX socket in a specific directory (specified by the mosh.conf file) such as /var/run/moshd/60001.sock, then 60001 refers to the UNIX socket's filename, not a udp port.

Would potentially break when servers are running on non-*NIX-like platforms, but you could easily allow falling back to local udp sockets in such an instance (and it's not likely to be a major use case of mosh having the server run on such platforms anyway). Another option is to have mosh.conf specify a whitelisted udp port range and only those ports can be used, the mosh-client respecting the port range too.

Additional encryption seems rather silly, I'd compare the security to what ssh currently offers, if ssh doesn't offer it, there's no real gain to offering it with mosh unless it can be done for free. Encrypting already encrypted data doubles your encryption overhead, and is hardly free, not to mention any possible key negotiations required...

[grawity]

A mosh.conf sounds good, actually, but it would have to be per-user (residing in ~/.config/mosh/ ideally) since I've seen at least two cases where different users were assigned different ports.

[nicowilliams]

@nvx: +1