High Performance Networking with the SSH Protocol

1
High Performance Networking with the SSH Protocol

• Chris Rapier
• rapier_at_psc.eduI2 Members Meeting
• May 4, 2005

2
Defining the Problem

• Transferring data over insecure networks requires
  cryptographically secure authentication
• Recent history has highlighted the need for this.
  RCP and FTP are no longer viable options
• It should be fast, easy to use, and cheap to
  install/maintain. Pick two. Sometimes only one.

3
First Solution GridFTP

• Pros
• Cryptographically secure authentication
• High transfer rates for bulk data
• Cons
• Difficult to install and maintain
• Key distribution requires additional
  infrastructure
• Often out of reach of smaller organizations
• Limited distribution

4
Next Solution Kerberos

• Pros
• Relatively widely used protocol
• Familiar interfaces (ftp, web, etc)
• Fast transfer rates
• Cons
• Maintenance and configuration beyond some
  organizations
• Insecure data transfers

5
Another Solution SCP/SSH

• Pros
• Strong cryptographic security of authentication
  and data
• Easy to install and maintain
• Ubiquitous
• Cons
• Astoundingly slow
• Somewhat less secure than kerberos or globus (no
  signed certs, expiring tokens)

6
Using SCP/SSH Anyway

• In spite of faults SCP/SHH ends up being the
  default for most people.
• This can be a bad thing
• Security depends on universal compliance.
• People will drift to using the easiest
  solution.
• SSH is the easiest security solution but the
  speed is frustrating. Some people will,
  eventually, resort to insecure but fast methods
  just this once
• Improve SSH performance and the security
  environment as a whole is enhanced and well have
  fast, cheap, secure - pick three.
• So why is SSH so slow?

7
The Real Problem With SSH

• It is NOT the encryption process!
• If it was
• Faster computers would give faster throughput.
  Which doesnt happen.
• Transfer rates would be constant in local and
  wide area network. Which they arent.
• In fact transfer rates seem dependent on RTT, the
  farther away the slower the transfer.
• Any time rates are strongly linked to RTT it
  implies a receive buffer problem

8
Why Buffers Matter

• Any network path has a carrying capacity
• The amount of data that can be in transit between
  the two hosts
• Equal to minimum bandwidth times round trip time
  (BDP BW RTT)
• A receive buffer (RWIN) is how much data can be
  unacknowledged at any one time.
• Therefore If RWIN lt BDP the throughput will be
  less than the theoretical maximum.

9
The Pretty Picture
Path 655Mbps, 45ms RTT, BDP 3.5MB
Host A
Host B
Goofus ignores our advice and leaves his RWIN at
64KB
Host C
Host D
Gallant listened and, computing the BDP, sets his
RWIN to 4MB
10
Network Utilization as a Function of TCP Receive
Window Size
11
SSH is RWIN Limited

• Analysis of the code reveals
• SSH Protocol V2 is multiplexed
• Multiple channels over one TCP connection
• Must implement a flow control mechanism per
  channel
• Essentially the same as the TCP receive window
• This application level RWIN is effectively set to
  64KB. So real connection RWIN is MIN(TCPrwin,
  SSHrwin)
• Thus TPUTmax 64KB/RTT

12
Solving the Problem

• Use getsockopt() to get TCPrwin and dynamically
  set SSHrwin
• Performed several times throughout transfer to
  handle autotuning kernels
• Results in 10x to 50x faster throughput depending
  on cipher used on well tuned system.

13
HPN-SSH v. SSH
14
Advantages

• Speed is comparable to GridFTP and Kerberized FTP
• No need for separate key infrastructure or realm
  administration
• Provides authentication and data security
• Can be used with other applications such as
  rsync, svn, SFTP, ssh port forwarding more

15
Whats involved?

• Get the source code from www.openssh.org
• Get the patch from www.psc.edu
• tar -zxf openssh-3.9p1.tgzcd openssh-3.9p1patch
  lt openssh-3.9p1-hpn.diffconfigure make install
  or make install-nokeys
• Time elapsed lt 5 minutes

16
Caveats

• TCP RWIN must be large enough
• RWIN Bandwidth RTT
• HPN-SSH must be installed on both hosts
• Cipher used will affect throughput
• RC4(arcfour) is fastest, 3DES is slowest
• CPU resources sensitive!

17
On the Horizon

• CLI argument to set TCPrwin
• This way admins dont need to be involved.
• Patch for OpenSSH 4.0
• Hopefully well be incorporated eventually
• Patch to disable HMAC generation and re-enable
  NONE cipher
• Obvious security issues but not much different
  than GridFTP or kFTP
• HPN-SSH library, PMVPN, Expiring Keys
• Library - Like SSL but easier.
• PMVPN - automatically creates SSH tunnels
• Expiring Keys - SSH session keys that are time
  limited

18
Big Picture Ideas

• Impact of hpn-ssh work will obscure packet
  contents
• Multiple apps using port 22, no way to determine
  which is doing what, payload inspection methods
  can be easily circumvented.
• Overall security of network environments will
  improve.
• People will invariably circumvent security if
  its inconvenient - especially in academic
  environments.
• Make the lowest acceptable level of security
  equivalent to insecure methods in terms of ease
  of use and performance.
• Remember, most people will not strictly follow
  security guidelines unless they are pressured to
  or its easy. So make it easy.

19
Availability

• Sourcehttp//www.openssh.org/
• Patchhttp//www.psc.edu/networking/projects/hpn-
  ssh/
• OtherFreeBSD ports security/hpn-ssh/

20
Thanks!

• Questions?
• Business cards with URL available