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.