Fixed-length fields place all the interpretative elements in the protocol specification outside the communications channel.
Because of this, fixed-length encoding often uses network resources efficiently; the network does not need to carry any additional information to describe transmitted data.
There are, however, two situations where fixed-length encoding is suboptimal:
• Carrying a field of rarely used information in every packet to make fixed-length encoding work can be wasteful. For instance, the IPv6 header has several rarely used extension headers. If they were included in the base header, the network would carry around a lot of 0s for no reason.
• Carrying variable-length information in a fixed-length field is nearly impossible. For instance, a protocol may support either a 32-bit IPv4 address or a 128-bit IPv6 address, but not both simultaneously.
Figure 15-4 illustrates three ways to encode either an IPv4 or IPv6 address.
Figure 15-4 Variable-Length Field Encoding Options The top of Figure 15-4 illustrates encoding IPv4 and IPv6 addresses in separate fields. If the protocol can support only one or the other, the space for the alternate address will be filled with 0s, being carried through the network and consuming space in the maximum transmission unit (MTU) for no reason.
The center of Figure 15-4 illustrates the same information but using a type field. The protocol’s specification can use this field to carry either an IPv4 or IPv6 address in the single address field:
• If type is set to 4, the field is 32 bits long and contains an IPv4 address.
• If type is set to 6, the field is 128 bits long and contains an IPv6 address.
Including just a type, making the field a type-value, is useful when the field can contain one of several possible values, each of which has a specific length.
The bottom of Figure 15-4 illustrates including both type and length fields. The protocol’s specification can use these two fields to carry either an IPv4 or IPv6 address in the single address field:
• If type is set to 4, the field’s length is set to 32 bits, and the address field carries an IPv4 address.
• If type is set to 6, the field’s length is set to 128 bits, and the address field carries an IPv6 address.
TLVs contain both a type and length. TLVs are often used when the data type does not imply or specify its length. For instance, imagine carrying a digital music file—the kind of data is “music,” but the length will depend on the individual song, so you need to specify both.
TLVs are also useful when you want to carry one or more items.
For instance, suppose you want to be able to encode anywhere from 1 to 30 IPv4 addresses in a single packet. In this case, you could have a type indicating the field carries IPv4 addresses and a length indicating how many IPv4 addresses are included.
TLVs are used in virtually every protocol, including routing protocols like BGP and application layer transport protocols like HTTPs.
Secure Shell
Network engineers rely on the command-line interface (CLI), accessed via a command prompt. The most reliable way to access the command prompt is by physically connecting a computer to the device’s console port.
But in large-scale networks, routers, switches, and other network devices can be scattered all over the world. Even if you are in the same building with a network device, why would you want to get up from your desk and go into a particular (and perhaps cramped) room so you can plug your computer into a physical device?
Network engineers rely on remote access to the command prompt through a terminal application.
Secure Shell (SSH), designed as a secure replacement for Telnet, is one of the most widely used terminal applications, so it is worth knowing.
Because SSH is an application, it must be installed on both the client—the host you will be accessing the server from—and the server. Most devices you connect to, including routers, switches, and Linux hosts, will already have an SSH application installed.
Linux and macOS hosts also already have SSH installed.
Windows does not come with SSH installed, but many different SSH programs are available. The most widely used Windows
SSH program is called PuTTY. Because PuTTY is an open-source application developed and maintained by volunteers, it is free to download and use.
application developed and maintained by volunteers, it is free to download and use.
Figure 15-5 illustrates SSH’s connection setup.
Figure 15-5 SSH Connection Setup
Host A begins the connection by starting a Transmission Control Protocol (TCP) session on port 22 with server B. Once the TCP three-way handshake is complete, A and B negotiate a seed (1) and the session encryption method (2). Once A and B have agreed on these parameters, they use the seed value to generate a secret key, or key exchange secret (3), and a private/public key pair (4).
Note
Chapter 20, “Security Tools, ” describes asymmetric encryption using private/public key pairs and symmetric encryption using secret keys.
Server B sends its newly generated public key to host A (5) and host A sends it to server B (6).
Host A and server B calculate a secret key to encrypt the data using the encryption method negotiated at (2). This key is used to encrypt transmitted data and unencrypt received data.
This process might seem overly complex, but it results from engineers, developers, and cryptographers working together to build a very secure system SSH is designed so attackers will find breaking into, or listening in on, an SSH session challenging.
Each point where a key might be compromised is protected using the results of a prior step.
Connecting to a host or network device using SSH is simple:
• On Apple macOS or Linux computers, open a terminal window. At the prompt, type ssh, followed by the IP address or hostname of the device you would like to connect to.
• On Windows computers, install and run the PuTTY terminal emulator. Type in the name or IP address of the host you would like to connect to and instruct PuTTY to connect.
• Type in your username when requested. Use your username on the remote system, not the one you use to access your local computer, for this prompt.
• Type in your password when requested. Use your password on the remote system, not the one you use to access your local computer, for this prompt.
Note
If you want to connect using a hostname, there must be some way to map the server’s name to an IP address. Organizations can create DNS name entries for this purpose, or you can use a local hosts file to map from names to IP addresses.
Once the session is created, the user is presented with a terminal screen like the one shown in Figure 15-6.
Figure 15-6 SSH Terminal Window
Some systems allow you to create a public and private key pair called an SSH key pair to log in to the system without using a password; for instance, there are no username or password prompts in Figure 15-6. To create and use an SSH key pair:
1. From a terminal, enter the command ssh-keygen -t rsa.
2. SSH will ask you for a filename. You can press Enter here unless you have a specific reason to name the SSH key something other than the default.
3. SSH will ask you for a passphrase. This passphrase protects the SSH key, not the connection between the local host and the SSH server. If you enter a passphrase here, the SSH key itself will be encrypted, and programs must ask you for the passphrase to unencrypt the key before using it. If you do not enter a passphrase here, SSH (and other programs) can access and use this SSH key without asking for permission.
4. SSH will print a fingerprint to the screen, create a file containing a public key, or create a private one. Once you have the public and private keys, you need to copy the public key to the server. You can do this using the command ssh-copy-id username@ip_address, replacing the username with your username on the server and ip_address with the server’s IP address.
You can copy the public SSH key to multiple servers or network devices, allowing you to connect to all these devices using a single passphrase (to unlock the key).
Figure 15-7 illustrates the relationship between an SSH connection’s private key, public key, and passphrase.
Figure 15-7 Keys, Passphrases, and User Authentication in SSH
1. The host’s SSH program asks for the user’s passphrase to unencrypt their private key.
2. The host’s SSH program encrypts the user’s stored login credentials with the user’s private key.
3. The host’s SSH sends the user’s encrypted login credentials over the network to the server.
4. The server’s SSH program unencrypts the user’s login credentials using the user’s public key.
5. The server’s SSH program checks a user database to determine if this user can access the server’s resources.