On Fri, Jan 15, 2016 at 1:07 PM, Alex Bligh <alex at alex.org.uk> wrote:> On 15 Jan 2016, at 11:44, Thomas ? Habets <habets at google.com> wrote: >> On 15 January 2016 at 08:48, Alex Bligh <alex at alex.org.uk> wrote:[snip]> 3. Server compares supplied address/port pair with what it sees > (to detect DNAT like Amazon elastic IPs), and if they are the > same, it waits for the TCP ECHO reply, and if it gets it > says "Excellent, let's apply TCP-MD5SIG, here is a > random key", and from that point on TCP-MD5SIG is applied > both times, else proceeds as normal. > > I don't see the advantage in hashing a session key (which should > be kept private) over using a random key. The random key could > be hashed with the session key I suppose if the concern was > entropy. > > The idea would be for this to detect NAT (without revealing private > IP addresses) and avoid TCP-MD5SIG if it's in use, but for TCP-MD5SIG > to be off by default anyway. The reason for this is that it might not > detect middleboxen (e.g. firewalls) that effectively proxy the TCP > session or strip the packets. A couple of dummy ECHO/ECHO REPLY TCP > options are used in order to detect such stripping.Don't these extra roundtrips further increase the latency of ssh connection setup (e.g. imagine a high-bandwidth&&high-latency satelite link) ? ssh is already a *PAIN* in that area, killing it's usefullness for applications like "Distributed make" because the time to setup the connection can be much longer than the command executed on the remote side. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)
On 15 Jan 2016, at 16:27, Roland Mainz <roland.mainz at nrubsig.org> wrote:> Don't these extra roundtrips further increase the latency of ssh > connection setup (e.g. imagine a high-bandwidth&&high-latency satelite > link) ? ssh is already a *PAIN* in that area, killing it's usefullness > for applications like "Distributed make" because the time to setup the > connection can be much longer than the command executed on the remote > side.They would, but only when this non-default option was enabled. -- Alex Bligh
On Fri, Jan 15, 2016 at 6:09 PM, Alex Bligh <alex at alex.org.uk> wrote:> On 15 Jan 2016, at 16:27, Roland Mainz <roland.mainz at nrubsig.org> wrote: >> Don't these extra roundtrips further increase the latency of ssh >> connection setup (e.g. imagine a high-bandwidth&&high-latency satelite >> link) ? ssh is already a *PAIN* in that area, killing it's usefullness >> for applications like "Distributed make" because the time to setup the >> connection can be much longer than the command executed on the remote >> side. > > They would, but only when this non-default option was enabled.OK... are there any good ideas how to mitigate the latency effect ([1]) ? [1]=Long on my wishlist is something like a SSH3 protocol which somehow can rival Kerberised rsh (yes, yes, I know, it's comparing apples with pears) in connection setup latency and better handles socket/pipe buffer boundaries (sort of |SOCK_SEQPACKET|-style) ... (But this is now going waaaay off-topic from the original subject... so either drop or rename subject of the thread...) ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;)