Chapter 19

IP Security Architecture (Overview)

The IP Security Architecture (IPsec) provides cryptographic protection for IP datagrams in IPv4 and IPv6 network packets.

This chapter contains the following information:

• What's New in IPsec?

• Introduction to IPsec

• IPsec Packet Flow

• IPsec Security Associations

• IPsec Protection Mechanisms

• IPsec Protection Policies

• Transport and Tunnel Modes in IPsec

• Virtual Private Networks and IPsec

• IPsec and NAT Traversal

• IPsec and SCTP

• IPsec and Solaris Zones

• IPsec Utilities and Files

• Changes to IPsec for the Solaris 10 Release

To implement IPsec on your network, see Chapter 20, Configuring IPsec (Tasks). For reference information, see Chapter 21, IP Security Architecture (Reference).

What's New in IPsec?

Solaris Express, Developer Edition 2/07: In this release, IPsec fully implements tunnels in tunnel mode, and modifies the utilities that support tunnels.

• IPsec implements tunnels in tunnel mode for Virtual Private Networks (VPNs). In tunnel mode, IPsec supports multiple clients behind a single NAT. In tunnel mode, IPsec is interoperable with implementations of IP-in-IP tunnels by other vendors. IPsec continues to support tunnels in transport mode, so is compatible with earlier Solaris releases.

• The syntax to create a tunnel is simplified. To manage IPsec policy, the ipsecconf command has been expanded. The ifconfig command is deprecated for managing IPsec policy.

In this release, the /etc/ipnodes file is removed. Use the /etc/hosts file to configure network IPv6 addresses.

Solaris 10 1/06: In this release, IKE is fully compliant with NAT-Traversal support as described in RFC 3947 and RFC 3948. IKE operations use the PKCS #11 library from the cryptographic framework, which improves performance.

The cryptographic framework provides a softtoken keystore for applications that use the metaslot. When IKE uses the metaslot, you have the option of storing the keys on disk, on an attached board, or in the softtoken keystore.

• To use the softtoken keystore, see the cryptoadm(1M) man page.

• For a complete listing of new Solaris features and a description of Solaris releases, see Solaris Express, Developer Edition What's New.

Introduction to IPsec

IPsec protects IP packets by authenticating the packets, by encrypting the packets, or by doing both. IPsec is performed inside the IP module, well below the application layer. Therefore, an Internet application can take advantage of IPsec while not having to configure itself to use IPsec. When used properly, IPsec is an effective tool in securing network traffic.

IPsec protection involves five main components:

• Security protocols - The IP datagram protection mechanisms. The authentication header (AH) signs IP packets and ensures integrity. The content of the datagram is not encrypted, but the receiver is assured that the packet contents have not been altered. The receiver is also assured that the packets were sent by the sender. The encapsulating security payload (ESP) encrypts IP data, thus obscuring the content during packet transmission. ESP also can ensure data integrity through an authentication algorithm option.

• Security associations database (SADB) - The database that associates a security protocol with an IP destination address and an indexing number. The indexing number is called the security parameter index (SPI). These three elements (the security protocol, the destination address, and the SPI) uniquely identify a legitimate IPsec packet. The database ensures that a protected packet that arrives to the packet destination is recognized by the receiver. The receiver also uses information from the database to decrypt the communication, verify that the packets are unchanged, reassemble the packets, and deliver the packets to their ultimate destination.

• Key management - The generation and distribution of keys for the cryptographic algorithms and for the SPI.

• Security mechanisms - The authentication and encryption algorithms that protect the data in the IP datagrams.

• Security policy database (SPD) - The database that specifies the level of protection to apply to a packet. The SPD filters IP traffic to determine how the packets should be processed. A packet can be discarded. A packet can be passed in the clear. Or, a packet can be protected with IPsec. For outbound packets, the SPD and the SADB determine what level of protection to apply. For inbound packets, the SPD helps to determine if the level of protection on the packet is acceptable. If the packet is protected by IPsec, the SPD is consulted after the packet has been decrypted and has been verified.

When you invoke IPsec, IPsec applies the security mechanisms to IP datagrams that travel to the IP destination address. The receiver uses information in its SADB to verify that the arriving packets are legitimate, and to decrypt them. Applications can invoke IPsec to apply security mechanisms to IP datagrams on a per-socket level as well.

Note that sockets behave differently from ports:

• Per-socket SAs override their corresponding port entry in the SPD.

• Also, if a socket on a port is connected, and IPsec policy is later applied to that port, then traffic that uses that socket is not protected by IPsec.

  Of course, a socket that is opened on a port after IPsec policy is applied to the port is protected by IPsec policy.