Optional 'test' or benchmark cipher

[Chris Rapier]

Linda Walsh wrote:

> 	Sounds like it is unlikely to provide an "easy" way to remove
> the data encryption from the equation.

Why do you say that?

> 	I'm not clear if the HPN-SSH "patch" is a patch over Ossh or
> a different, but depending on how much change HPN-SSH adds, I might
> be benchmarking something that is unrepresentative of Ossh.

Its a patch against OpenSSH with support for all of the recent releases. 
It's primary goal is to open up the receive window limitation that 
imposed by the multiplexing. If the BDP of your path is greater than 64k 
in the case of 4.6 (or less) or around 1.25MB for 4.7 it can increase 
your throughput assuming the network and end hosts are well tuned.

This performance increase is often large enough to make CPU overhead the 
limiting bottleneck - which is why we incorporated the NONE cipher 
switching.

>> What are you typically seeing for your transfer rates? What cipher/MAC
>> combination are you using and what version of OpenSSL? Also, what
>> version of OpenSSH?
> ----
> 	Most are under 12MB/s (which, I know, sounds like very good
> 100Mbs performance -- cept that I'm expecting Gigabit  performance.
> 
> 	Interfaces are running at 1G verified w/"ethtool" and "lights on
> the switches involved".

I'm not sure if you mentioned this or not but are you pegging your CPU? 
As an aside, using a multicore machine won't help you much as SSH is 
limited to using one core.

Anyway, diagnosing network performance problems can be a complicated 
proceedure because any number of failures all manifest as the same 
problem - slow throughput. You should start by making sure that you your 
TCP receive buffers are large enough to accommodate the throughput you 
are trying to achieve. They need to be at least the same as the 
bandwidth delay product (bandwidth and the narrowest point multiplied by 
the round trip time). If they aren't then increase them using the 
appropriate methods. You can find out more about this from 
http://www.psc.edu/networking/projects/tcptune


> 	I want to test it both ways. How can I easily tell what is due to
> my network's speed, the SSH protocol, or even the implementation?

Start by doing baseline measurements of the network speed. If you 
haven't looked at it yet Iperf is your best solution for that. Since it 
doesn't rely on pipes, the filesystem, or anything like that its your 
lightest weight option. Since it can also run in UDP mode it can even 
give you information on any unexpected packet loss. Then rerun the tests 
using a sample file to see how much of a bottleneck disk I/O is. At that 
point you can determine how much of an impact the application is having.

> How is it a security hole?  I am proposing that it must be explicitly enabled in sshd_config (allowed on a per-host basis, as it is likely only
> something someone would use with certain "safe" (likely internal-private)
> networks. Also, in order to make certain it comes from a valid machine,
> session authentication should be done "as normal". Only after
> authentication would null be allowed.

And pretty much that's all been implemented in the HPN-SSH patch. You 
can't embed the NoneEnabled directive in a Match block at this time. It 
may or may not be possible but its a good idea and something I'll be 
looking into over the next few weeks.

> 	That should spell it out very clearly enough to prevent
> "accidents".  What security holes would I be missing?

If you enable NONE switching for interactive data you do actually open a 
security hole. People *should* have the expectation that anything they 
type into a secure shell should be, well, secure. I do not think that 
necessarily applies to bulk data transfer though - with proper 
safeguards in place.

But really, I'm not entirely sure what you want. If you *just* want to 
benchmark things with and without encryption its not that hard to hack 
the none cipher back into the cipher lists. If you want a more general 
solution that can be used in a production environment then you should 
probably just use the HPN-SSH patch.