test

SunScreen 3.1 Reference Manual

Chapter 6 Encryption, Tunneling, and Virtual Private Networks

This chapter contains information on:

Encryption and Decryption

Encryption is the process by which a readable message is converted to an unreadable form to prevent unauthorized parties from reading it. Decryption is the process of converting an encrypted message back to its original (readable) format. The original message is called the plaintext message. The encrypted message is called the ciphertext message.

Digital encryption algorithms work by manipulating the content of a plaintext message mathematically, using an encryption algorithm and a digital key to produce a ciphertext version of the message. The sender and recipient can communicate securely if the sender and recipient are the only ones who know the key.

Encryption is important to SunScreen because it provides a mechanism for protecting the privacy of communications and authenticating the identities of the sender and receiver. Without encryption, you would have to define packet screen rules broadly; for example, "all the machines on the Internet" and "all the machines on the inside." Encryption technology lets you authenticate machines and users. As a result, you can define rules that control access by specific cryptographic identities rather than by general IP addresses.

SunScreen use SKIP (SunScreen Simple Key Management for Internet Protocols) as the basis for its encryption technology. SKIP provides secure, encrypted communication between a remote Administration Station and the Screen and between a Screen and a remote SKIP host.

For detailed information on how SKIP encryption works, refer to the SunScreen SKIP 1.5.1 User's Guide.

Note -

SunScreen incorporates cryptography at the network (IP) layer to provide privacy and authentication over insecure public networks, such as the Internet. See the SunScreen SKIP 1.5.1 User's Guide for full descriptions of these and the Certification Authority (CA) issued keys and certificates.

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 machines or other SKIP devices can be encrypted. All 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 new packet is first checked to see if it is too large to send on. Encrypted packets can be larger than the original packet for the following reasons:

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 (DES, RC2, or RC4) specified and a randomly generated traffic key. The traffic key is then encrypted using the encryption mechanism (DES or RC2) specified 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.

Note -

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, it 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).

Remote Administration

Remote Administration from an Administration Station to the Screen installs the software packages, including SunScreen SKIP, on separate machines, as shown in FIGURE 6-1. SKIP is required for remote administration because administration commands travel from the Administration Station to the Screen over a potentially insecure network.

Figure 6-1 Remote Administration From an Administration Station to a Screen in Routing Mode

Graphic

In FIGURE 6-1, a remote Administration Station on the internal network administers the Screen located between the internal network and the Internet. This Screen is the router between the internal network and the Internet. A second remote Administration Station for this Screen is located on the external network. Each Administration Station can be configured to communicate with the Screen using encryption.

Tunneling

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

Organizations typically have offices in more than one location. The tunneling feature provides a way to let the different offices 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.

FIGURE 6-2 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.

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

Graphic

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 to 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-3.

Figure 6-3 Geographically Dispersed Network

Graphic

Defining a VPN

A VPN is a group of Screens that transfer encrypted data among themselves. A VPN simulates a private network using a public network, with IP level encryption providing privacy.

After a VPN has been defined, you can refer to this VPN when adding rules to your security policy. VPNs make it possible for you to define your security policy with fewer rules. The system automatically generates the multiple rules that the VPN defines.

In defining a VPN:

When defining a VPN gateway object, specify the following information:

Consider a site, similar to that shown in Figure 6-4, that has ten Screens. One of the systems protected by each Screen is a mail server. Assume that your security policy allows the exchange of encrypted mail between all these mail servers and you want to define rules to allow SMTP between all of the mail servers.

Figure 6-4 A Site of Ten Networks, Each with a Mail Server, Protected by Ten Screens

Graphic

Without a VPN, you must define nine rules for each mail server to send mail encrypted to the other nine mail servers. Because you have ten mail servers, you must define a total of 90 rules. If, instead you defined a VPN, you only need a single rule: one that allows the mail servers to send mail to the other mail servers using the VPN. Because you have ten Screens in the VPN, you must define ten VPN gateway entries.

Looking at this example in detail, FIGURE 6-4 shows the configuration. The Screens are labeled Screen1 through Screen10. The mail servers behind them are labeled mail1 through mail10 and are part of network1 through network10.

The first step is defining the VPN itself. Choose a name for the VPN. In this example, that name is "ourVPN." Next, for each Screen that is a member of that VPN, define a VPN gateway object. For each VPN gateway object, specify the VPN name (ourVPN), the addresses of the systems that the Screen protects, the Screen's certificate, the tunnel address, and the encryption parameters that will be used for the VPN. All VPN gateway objects in a particular VPN must have identical encryption parameters, and the certificates must refer to keys of the same strength (512-, 1024-, 1124-, 1280-,2048-, 2176-, 3072-, or 4096-bit Diffie-Hellman keys).

Once you have defined the VPN objects, as shown in FIGURE 6-5, you can use the VPN in any rule. Select SECURE as the action for the data between the sender and the SMTP server, and specify the name of the VPN.

Figure 6-5 Policy Rules Panel Showing the VPN Tab with VPN Entries

Graphic

Adding a VPN Rule

Assuming an address group MailServers containing all the mail servers exchanging encrypted mail, define the rule in the Rule Definition dialog box shown in FIGURE 6-6.

Figure 6-6 Completed Rule Definition Dialog Box for the VPN Rule

Graphic

The VPN rule appears on the Packet Filtering tab of the Policy Rules page. The more restrictive a rule is, the earlier it should be ordered in the list of rules because the rules take effect in order. The more restrictive VPN rule comes before the more general rule and so will take effect earlier.

Figure 6-7 VPN Rule

Graphic

There is no limit to the number of VPNs to which a Screen can belong. For example, you can to define two VPNs--one for encryption at 1024 bits, and one for encryption at 4096 bits. A single Screen can belong to both of those VPNs: one entry specifying the 1024-bit certificate, and the other specifying the 4096-bit certificate.

VPN Limitations

Currently, the VPN object has the following limitations: