Protection Policy and Enforcement Mechanisms

IPsec separates protection policy and enforcement mechanisms. You can enforce IPsec policies in the following places:

• On a system-wide level

• On a per-socket level

You use the ipsecconf(1M) command to configure system-wide policy.

IPsec applies system-wide policy to incoming and outgoing datagrams. You can apply some additional rules to outgoing datagrams, because of the additional data that is known by the system. Inbound datagrams can be either accepted or dropped. The decision to drop or accept an inbound datagram is based on several criteria, which sometimes overlap or conflict. Resolving a conflict depends on which rule is parsed first. Except when a policy entry states that traffic should bypass all other policy, the traffic is automatically accepted. Outbound datagrams are either sent with protection or without protection. If protection is applied, the algorithms are either specific or non-specific. If policy normally protects a datagram, it can be bypassed by either an exception in system-wide policy, or by requesting a bypass in per-socket policy.

For intra-system traffic, policies are enforced, but actual security mechanisms are not applied. Instead, the outbound policy on an intra-system packet translates into an inbound packet that has had those mechanisms applied.

Transport and Tunnel Modes

When you invoke ESP or AH after the IP header to protect a datagram, you are using transport mode. An example follows. A packet starts off as:

ESP, in transport mode, protects the data as follows:

AH, in transport mode, protects the data as follows:

AH actually covers the data before it appears in the datagram. Consequently, the protection that is provided by AH, even in transport mode, covers some of the IP header.

When an entire datagram is inside the protection of an IPsec header, IPsec is protecting the datagram in tunnel mode. Because AH covers most of its preceding IP header, tunnel mode is usually performed only on ESP. The previous example datagram would be protected in tunnel mode as follows:

Often, in tunnel mode, the outer (unprotected) IP header has different source and destination addresses from the inner (protected) IP header. The inner and outer IP headers can match if, for example, an IPsec-aware network program uses self-encapsulation with ESP. Self-encapsulation with ESP protects an IP header option.

The Solaris implementation of IPsec is primarily a transport mode IPsec implementation, which implements the tunnel mode as a special instance of the transport mode. The implementation treats IP-in-IP tunnels as a special transport provider. The ifconfig(1M) configuration options to set tunnels are nearly identical to the options available to socket programmers when enabling per-socket IPsec. Also, tunnel mode can be enabled in per-socket IPsec. In per-socket tunnel mode, the inner packet IP header has the same addresses as the outer IP header. See the ipsec(7P) man page for details on per-socket policy.

Trusted Tunnels

A configured tunnel is a point-to-point interface. It enables an IP packet to be encapsulated within an IP packet. Configuring a tunnel requires both a tunnel source and tunnel destination. See the tun(7M) man page and Solaris Tunneling Interfaces for IPv6 for more information.

A tunnel creates an apparent physical interface to IP. The physical link's integrity depends on the underlying security protocols. If you set up the security associations securely, then you can trust the tunnel. That is, packets that exit the tunnel originated from the peer that was specified in the tunnel destination. If this trust exists, you can use per-interface IP forwarding to create a virtual private network.

Virtual Private Networks

You can use IPsec to construct a Virtual Private Network (VPN). You do this by constructing an Intranet that uses the Internet infrastructure. For example, an organization that uses VPN technology to connect offices with separate networks, can deploy IPsec to secure traffic between the two offices.

The following figure illustrates how two offices use the Internet to form their VPN with IPsec deployed on their network systems.

Figure 19-3 Virtual Private Network

See How to Set Up a Virtual Private Network for a description of the setup procedure.

IPsec Utilities and Files

This section describes the IPsec initialization configuration file and various commands that enable you to manage IPsec within your network. For instructions about how to implement IPsec within your network, see Implementing IPsec Task Map.

Table 19-3 List of Selected IPsec Files and Commands

IPsec Policy Command

You use the ipsecconf(1M) command to configure the IPsec policy for a host. When you run the command to configure policy, the system creates a temporary file named ipsecpolicy.conf to hold the IPsec policy entries. The system immediately uses the file to check all outbound and inbound IP datagrams for policy. Forwarded datagrams are not subjected to policy checks that are added by using this command. See ifconfig(1M) and tun(7M) for information on how to protect forwarded packets.

You must become superuser to invoke the ipsecconf command. The command accepts entries that protect traffic in both directions, and entries that protect traffic in only one direction.

Policy entries that do not specify a direction and contain the patterns laddr host1 (local address) and raddr host2 (remote address) protect traffic in both directions for the named host. Thus, you need only one entry for each host. A policy entry of the pattern saddr host1 daddr host2 (source address to destination address) protects traffic in only one direction, that is, either outbound or inbound. Thus, to protect traffic in both directions, you need to pass the ipsecconf command another entry, as in saddr host2 daddr host1.

You can see the policies that are configured in the system when you issue the ipsecconf command without any arguments. The command displays each entry with an index followed by a number. You can use the -d option with the index to delete a particular policy in the system. The command displays the entries in the order that they were added, which is not necessarily the order in which the traffic match occurs. To view the order in which the traffic match occurs, use the -l option.

The ipsecpolicy.conf file is deleted when the system shuts down. To ensure that IPsec policy is active when the machine boots, you can create an IPsec policy file, /etc/inet/ipsecinit.conf, that the inetinit script reads during startup.

IPsec Policy File

To invoke IPsec security policies when you start the Solaris operating environment, you create an IPsec initialization configuration file with your specific IPsec policy entries. You should name the file /etc/inet/ipsecinit.conf. See the ipsecconf(1M) man page for details about policy entries and their format. After policies are configured, you can use the ipsecconf command to delete a policy temporarily, or to view the existing configuration.

Example--ipsecinit.conf File

The Solaris software includes a sample IPsec policy file that you can use as a template to create your own ipsecinit.conf file. This sample file is named ipsecinit.sample and it contains the following entries:

#
#ident	"@(#)ipsecinit.sample	1.6  01/10/18 SMI"
#
# Copyright (c) 1999,2001 by Sun Microsystems, Inc.
# All rights reserved.
#
# This file should be copied to /etc/inet/ipsecinit.conf to enable IPsec
# systemwide policy (and as a side-effect, load IPsec kernel modules).
# Even if this file has no entries, IPsec will be loaded if
# /etc/inet/ipsecinit.conf exists.
#
# Add entries to protect the traffic using IPsec. The entries in this
# file are currently configured using ipsecconf from inetinit script
# after /usr is mounted.
#
# For example,
#
#	 {rport 23} ipsec {encr_algs des encr_auth_algs md5}
#
# Or, in the older (but still usable) syntax
#
#    {dport 23} apply {encr_algs des encr_auth_algs md5 sa shared}
#    {sport 23} permit {encr_algs des encr_auth_algs md5}
#
# will protect the telnet traffic originating from the host with ESP using
# DES and MD5. Also:
#
#	 {raddr 10.5.5.0/24} ipsec {auth_algs any}
#
# Or, in the older (but still usable) syntax
#
#    {daddr 10.5.5.0/24} apply {auth_algs any sa shared}
#    {saddr 10.5.5.0/24} permit {auth_algs any}
#
# will protect traffic to or from the 10.5.5.0 subnet with AH 
# using any available algorithm.
#
#
# To do basic filtering, a drop rule may be used. For example:
#
#    {lport 23 dir in} drop {}
#    {lport 23 dir out} drop {}
#
# will disallow any remote system from telnetting in.
#
#
# WARNING:	This file is read before default routes are established, and
#		before any naming services have been started. The
#		ipsecconf(1M) command attempts to resolve names, but it will
#		fail unless the machine uses files, or DNS and the DNS server
#		is reachable via routing information before ipsecconf(1M)
#		invocation.  (that is, the DNS server is on-subnet, or DHCP
#		has loaded up the default router already.)
#
#		It is suggested that for this file, use hostnames only if
#		they are in /etc/hosts, or use numeric IP addresses.
#
#		If DNS gets used, the DNS server is implicitly trusted, which
#		could lead to compromise of this machine if the DNS server
#		has been compromised.
#