To configure IP Security, tunnels and filters must be configured. When a simple tunnel is defined for all traffic to use, the filter rules can be automatically generated. If more complex filtering is desired, filter rules can be configured separately.
You can configure IP Security using the Web-based System Manager Network plug-in or the System Management Interface Tool (SMIT). If using SMIT, the following fast paths take you directly to the configuration panels you need:
Before configuring IP Security for your site, you must decide several what you intend to use; for example, whether you prefer to use tunnels or filters (or both), which type of tunnel best suits your needs, etc. The following sections provide information you must understand before making these decisions:
There are two related but distinct parts of IP Security: tunnels and filters. Tunnels require filters, but filters do not require tunnels.
Filtering is a basic function in which incoming and outgoing packets can be accepted or denied based on a variety of characteristics called rules. This allows a system administrator to configure the host to control the traffic between this host and other hosts. Filtering is done on a variety of packet properties, such as source and destination addresses, IP Version (4 or 6), subnet masks, protocol, port, routing characteristics, fragmentation, interface, and tunnel definition. This filtering is done at the IP layer, so no changes are required to the applications.
Tunnels define a security association between two hosts. These security associations involve specific security parameters that are shared between end points of the tunnel.
The following illustration indicates how a packet comes in the network adapter to the IP stack. From there, the filter module is called to determine if the packet is permitted or denied. If a tunnel ID is specified, the packet is checked against the existing tunnel definitions. If the decapsulation from the tunnel is successful, the packet ispassed to the upper layer protocol. This function occurs in reverse order for outgoing packets. The tunnel relies on a filter rule to associate the packet with a particular tunnel, but the filtering function can occur without passing the packet to the tunnel.
Figure 4-2. Network Packet Routing. This illustration shows the route a network packet takes. Inbound fron the network, the packet enters the network adapter. from there it goes to the IP stack where it is sent to the filter module. From the filter module, the packet is either sent to tunnel definitions or it is returned to the IP stack where it is forwarded to the upper layer protocols.
|
Tunnels are used whenever it is desired to have data authenticated or authenticated and encrypted. Tunnels are defined by specifying a security association between two hosts. The security association defines the parameters for the encryption and authentication algorithms and characteristics of the tunnel.
Figure 4-3. Establishment of a Secure Tunnel Between Hosts A and B. This illustration shows a vurtual tunnel running between Host A and Host B. Security Association (SA) A is an arrow directed from Host A to Host B. SA B is an arrow directed from Host B to Host A. A Security Association consists of the Destination Address, SPI, Key, Crypto Algorithm and Format, Authentication Algorithm, and Key Lifetime.
 |
The Security Parameter Index (SPI) and the destination address identify a unique security association. These two parameters are required for uniquely specifying a tunnel. Other parameters such as cryptographic algorithm, authentication algorithm, keys, and lifetime can be specified or defaults can be used.
The decision to use manual tunnels or IKE tunnels depends on the tunnel support of the remote end and the type of key management desired. IKE tunnels are recommended (when available) because they offer secure key negotiation and key refreshment in an industry-standard way. They also take advantage of the IETF ESP and AH header types and support anti-replay protection. You can optionally configure signature mode to allow digital certificates.
If the remote end uses one of the algorithms requiring manual tunnels, manual tunnels should be used. Manual tunnels ensure interoperability with a large number of hosts. Because the keys are static and difficult to change and might be cumbersome to update, they are not as secure. Manual tunnels can be used between a host running this operating system and any other machine running IP Security and having a common set of cryptographic and authentication algorithms. Most vendors offer Keyed MD5 with DES, or HMAC MD5 with DES. This subset works with almost all implementations of IP Security.
When setting up manual tunnels, the procedure depends on whether you are setting up the first host of the tunnel or setting up the second host, which must have parameters matching the first host setup. When setting up the first host, the keys can be autogenerated, and the algorithms can be defaulted. When setting up the second host, it is best to import the tunnel information from the remote end, if possible.
Another important consideration is determining whether the remote system is behind a firewall. If it is, the setup must include information about the intervening firewall.
One common scenario for using IP Security with an operating system is when remote systems are initiating IKE sessions with a server and their identity cannot be tied to a particular IP address. This case can occur in a Local Area Network (LAN) environment such as using IP Security to connect to a server on a LAN and wanting to encrypt the data. Other common uses involve remote clients dialing into a server, and using either a fully qualified domain name (FQDN) or email address (user@FQDN)to identify the remote ID.
In order to make a policy decision based on explicit information about the remote identity, aggressive mode must be used. In this case, the identity is sent in the first message of the negotiation and can be used to do a policy lookup on the security policy database. This will ensure that only specifically named remote identities will be able to negotiate using the IKE protocol.
For phase 2, when the IP Security associations are being created to encrypt TCP or UDP traffic, a default tunnel can be configured. Therefore, any request that was authenticated during phase 1, will use the default tunnel for defined phase 2 if the IP address is not explicitly configured in the database. This allows any address to match the default tunnel and be used as long as the rigorous public key-based security validation was successful in phase 1.
To define a default phase 2 tunnel, select a Key Management tunnel in the IKE Tunnels container, and select the action to Define a Default Tunnel. The configuration panels are the same as the panels used to define a Data Management tunnel. However, the choices for the ID types are different and the ID fields themselves are disabled. This is because explicit IDs do not need to be specified. The ID types, which are IP v4 or v6 Address Only, IP v4 or v6 Subnet Only, and IP v4 or v6 Address or Subnet, cover all allowable cases of IDs. Set the rest of the information the same way as in a Data Management Tunnel and click OK. Each Key Management tunnel can only have one associated Default Tunnel.