[mosh-devel] Mosh and multi-path

[Matthieu Boutier]

>> |<-- nonce -->|
>> [ dir & seqno | flowID | flow seqno | flags | timestamps |
>> 
>> It will just take a few more bits, but I don't think that 64 bits more
>> is a big deal.
> 
> Adding extra fields to the outer packet header leaves them unprotected
> by the encryption/authentication, and is probably not a good idea.  (I
> think that's what you're suggesting here.)

Oh no, the current (pushed) packet format is:

|<--------- nonce --------->|
[ dir & flowID & flow seqno | 16 bits flags | 2 timestamps |

and as touching the nonce frighten people (with reason), I proposed
to keep the nonce as-is, using:

|<-- nonce -->|
[ dir & seqno | flowID | flow seqno | 16 bits flags | timestamps |

Of course, everything must be encrypted.

> I've thought a little more about this.  My original idea was to add new
> elements to transportinstruction.proto:

Yeah, but it breaks modularity: I am therefore strongly opposed to
that.  Now, I'm not opposed to have a networkheader.proto.  I'm fine
with having one time an incompatible change, and then an extensible
protocol.  (And as protobuf is already a dependance...)

> This authentication
> eliminates your concern in the paper about malicious address-request
> packets, I think.

Well, this paper is really bad written.  The whole point is just that we
must not answer to out-of-order address requests.

Otherwise, as addresses are asked at the very beginning of the program,
an attacker intercepting the firsts packets should know which one
contains an address request (just look at the size).  If you don't ignore
in-order packets, the attacker has just to send a lot of copy of these
packets (which are well authenticated and encrypted), and the receiver
will have to send its addresses (in bigger packets than the request).

Another solution would be to use a timer (don't answer if you just
receive a request).

> The existing Mosh code really
> expects every incoming packet to have a valid Instruction protobuf, and
> every incoming Instruction affects the protocol state.

Please, no cross layer, keep it safe!  Incompatibility is not worst
that ugly hacks!! ;-)

> The existing
> Mosh code throws exceptions on unexpected packet contents rather than
> discarding or ignoring them, making it difficult to vary from the
> existing packet format.

(Or even assertion!! -- when a transport payload is empty)

> The best idea I've come up with is for
> multipath-Mosh to inject a new flag or field into the Instruction
> protobuf, and for it to send packets otherwise exactly compatible with
> older versions of Mosh until it sees that flag/field from the other
> side.  That would require significant change to your code to handle that
> behavior.

And so there would be a short period for which we don't know which kind
of message we're parsing?

> I have to disagree here.  First, there are situations where the server
> does not and cannot know its NAT address

Ok, you're right.  Will be implemented in a few time.  I think that I
must use "getaddrinfo" to get the "sockaddr", then "getnameinfo" to
recover the hostname, and finally again getaddrinfo for actual IP
addresses.  Is there a simpler way?  (I tested some code for that.)

> Link-local addresses *are* a plausible use case, but
> there are difficulties

I have running code for that… in the not-yet-pushed patches. ;-)

> Running this loop is not currently useful in standard mosh, because the
> client is passed a numeric IPv4 or IPv6 address on the command line, and
> we will not get any more addresses.

So right… I figured out that getaddrinfo was doing tricky stuff for us.

> But I suspect you're not using the
> Perl script at all for mp-mosh, since you've not modified it at all.

eh! ;-)  Indeed, I rarely use the mosh script when testing, and no
hostname.

> For multipath mosh, I think the Perl script will have to pass both the
> IP address that was chosen for the SSH connection, and the hostname.

Did we want to support both external and internal hostnames?

> * Replication of packets will increase the bandwidth Mosh uses, obviously.
> 
> * If the replicated packets share some or all of their network paths,
> the replication is effectively a more-aggressive congestion-avoidance
> algorithm.  This doesn't matter much for mosh, which limits its
> bandwidth and doesn't really do congestion-avoidance, but it can be
> important with a TCP stack.

Interesting, isn't it ?

>> For the perl script...
> 
> * Mosh is a small project with linear development.  Maybe we can just
> detect extensions based on the Mosh version number, or a protocol
> version number.

Yes, but unmerged extensions will have to keep their version numbers
higher than the official repository, which may be painful on updates.

> * Your patch adds a way to describe extensions that have command line
> options, but new features may take other forms.  I also think that the
> extension types aren't necessary.

In fact, the "m" option is not (yet) pushed.  The original mutlipath
extension (and currently pushed) has no command-line options.

Matthieu