How SunScreen Uses Encryption

SunScreen uses a combination of public-key and shared-key cryptography to encrypt and decrypt packets. Any traffic that passes between any two systems or other SKIP devices can be encrypted. All administrative traffic between a Screen and a remote Administration Station is encrypted.

Packet Examination

When the rules and policies determine that a specific packet should be encrypted, the encrypted packet is first checked to see if it is too large to forward. Encrypted packets can be larger than the original packet for the following reasons:

• The original packet is encapsulated in a new IP packet for transmission over the Internet.

• A SKIP or IPsec header is added so that the receiver can decrypt the packet.

• The encryption process requires some padding of the original data.

If the new packet is too large to send on and the original packet carries the "Don't Fragment" bit, then a message is sent back to the sender with a request for a smaller packet: "ICMP Fragmentation needed, but Don't-Fragment bit set." If the new packet is too large and fragmentation is allowed, the original packet is first fragmented and then encrypted. The other end of the encryption tunnel can then decrypt each fragment independently.

The encryption routine builds a new IP packet to carry the original data. It uses the original source and destination addresses, or if tunneling is specified, the tunnel source and destination addresses.

After a new packet is created, the original packet is encrypted using the encryption mechanism specified (such as DES, RC2, or RC4) and a randomly generated traffic key. The traffic key is then encrypted using the encryption mechanism specified (DES or RC2) and a key-encrypting key from the SKIP key manager. The new IP header, SKIP header, and encrypted data are concatenated to form the new IP packet that is sent on to the destination addresses.

Because of a limitation in SunScreen SKIP 1.5.1 for Solaris, the RC2 encryption algorithm is not available when running Solaris 7 and Solaris 8 in 64-bit mode.

When an encrypted packet is received, it is passed to the decryptor. By examining the SKIP header, the decryptor determines the correct decryption mechanisms for both the encrypted traffic key (DES or RC2) and the encrypted data (DES, RC2, or RC4). It retrieves the traffic-encrypting key from the key manager and decrypts the traffic key that in turn decrypts the original IP packet.

Finally, the decrypted packet is sent through the rules or policies to determine the action for the packet (for example, whether the decrypted packet should be passed or dropped).

See "Using IKE With SunScreen" for the IKE case.

Tunneling

SunScreen can use encryption in a feature called tunneling that is used to hide actual source and destination addresses. With tunneling you can substitute other addresses for the addresses on the packet header. When the Screen tunnels a packet, it replaces the packet's source address with the tunnel address of the From Encryptor and replaces the packet's destination address with the (optional) tunnel address of the To Encryptor. When the Screen decrypts a packet, the original addresses are restored.

Organizations typically have offices in more than one location. The tunneling feature enables the different offices to use public networks as a secure private network without needing dedicated lines and with no changes to user applications.

When a tunnel, or virtual private network (VPN), is set up between two locations, all data packets traveling from one location to the other are encrypted and encapsulated inside other packets before they are sent over the public internetwork. Encrypting the packets guarantees that their contents remain private; anyone capturing packets to snoop on network traffic between the two locations will be unable to read them. When the packets arrive at the remote location, they are extracted, decrypted, and forwarded to their intended destination.

In addition to protecting the privacy of network traffic, tunneling also lets a site conceal the details of its network topology from intruders or eavesdroppers. Because the original packets are encrypted, the source and destination addresses in their IP headers cannot be read. When the encrypted packets are encapsulated in other packets, the new IP headers identify the addresses of the Screens that protect the locations, not the hosts that originated the packets. Consequently, the network topology behind the Screens is never exposed.

The figure below illustrates how tunneling affects the outside IP header of a packet traveling from Host A to Host B. Note that the encrypted packet containing the original data Host A sent to Host B is the same whether or not tunneling is used. Note also that the addresses in the figure are not meant to be valid IP addresses; they have been simplified for illustrative purposes.

Figure 6-1 Effect of Tunneling on Contents of IP Headers

If you do not use a VPN (a tunnel) to transfer data between the two locations, the source and destination addresses on the outer IP header are the same as the source and destination addresses on the inner (encrypted) IP header: 1.1.1.10 and 2.2.2.10, respectively. Someone intercepting this packet cannot read its contents, but can determine that hosts with IP addresses 1.1.1.10 and 2.2.2.10 reside behind the Screens protecting the two locations.

If you use a VPN to transfer data between the two locations, the Screen protecting Host A substitutes the IP address of its external interface (1.1.1.1) for the IP address of host A (1.1.1.10) in the Source Address field of the external IP header. Similarly, it substitutes the external IP address of the Screen at the other end of the tunnel (2.2.2.1) for the IP address of Host B in the Destination field. The local Screen then sends the packet through the insecure public network to the remote Screen.

When the remote Screen receives the packet, it strips off the encapsulation and decrypts the original packet from Host A. The remote Screen then reads the destination address from the original IP header of the decrypted packet and forwards the packet to Host B.

Because the IP addresses behind the Screen are never exposed to hosts on the external Internet, the two locations do not need to assign externally valid IP addresses to hosts behind the Screens. As long as hosts behind the Screens do not need to communicate with hosts on the Internet, the two locations can use a shared IP address space, as shown in Figure 6-2.

Figure 6-2 Geographically Dispersed Network