Another consideration for using SSH--either version--is actually a concern for any software
that uses encryption. Many countries, most notably France, Russia, and Pakistan, require special
permits to use the levels of encryption provided by either version of SSH. These considerations
might make it inadvisable to utilize SSH in network operations in some countries.
Frankly, the most basic consideration for using SSH is the complexity--or at least the perceived
complexity--of setting it up. As I've demonstrated, implementing SSH on a network device
doesn't need to be complicated. Any level of data encryption is preferable to none.
It's Your Internal Network--Why Encrypt?
There is sort of a feeling among network administrators that most of their network devices are behind a
firewall and that their office has locks or card keys or some other access control, so why bother
encrypting traffic in this "safe" environment? The security concept of
defense in depth
than just one level of protection.
For example, consider the almost ridiculous infection rates of recent Trojan-carrying viruses such as
Bagel, NetSky, and MyDoom. Among their other capabilities, these viruses provide a means for an
external attacker to use computers on your internal network for their own purposes. This capability can
give an attacker an instant "in" to your supposedly "safe" network traffic, where they can capture and
analyze traffic to determine the structure of your network, capture passwords, and so forth.
Defense in depth suggests that you shouldn't trust your firewalls or door locks--instead, assume that
every level of security will be penetrated by a determined attacker. Using SSH to encrypt network device
management makes sense, then, as a last line of defense when the physical network is compromised.
The Internet's File Transfer Protocol (FTP) is perhaps one of the top two application protocols
used (the Web's HTTP is number one). Trivial FTP (TFTP) is less well-known but plays an
important role in network device management, particularly in network configuration
TFTP is formally defined in RFC 1350 (and certain aspects of using uniform resource identifiers with
TFTP are defined in RFC 3617). RFC 1350 actually defines TFTPv2; the protocol was originally
defined in RFC 783. RFCs 2347-2349 define a set of extensions to TFTP; RFC 2090 defines
multicast options for TFTP.
TFTP Theory of Operation
Perhaps the biggest difference between FTP and TFTP is the underlying transport protocol. FTP
uses the connection-oriented TCP, and TFTP relies on the connectionless UDP. TFTP is
considerably less feature-rich than FTP to keep both TFTP client and server software
uncomplicated and easy to use. TFTP is pretty much limited to reading and writing files; it
cannot list directories, and the core protocol does not have any mechanism for encryption or user
authentication (although some implementations, and proposed extensions to the protocol, do
provide these features).