openssh unix dev - Jan 2016 - [Patch] TCP MD5SIG for OpenSSH

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;)