This section lists the IPsec services, selected IPsec RFCs, and the files and commands that are relevant to IPsec.
The Service Management Facility (SMF) provides the following services for IPsec:
svc:/network/ipsec/policy service – Manages IPsec policy. By default, this service is enabled. The value of the config_file property determines the location of the ipsecinit.conf file. The initial value on a system that is running the DefaultFixed network configuration profile is /etc/inet/ipsecinit.conf. On systems that are not running this profile, the property value is empty.
svc:/network/ipsec/ipsecalgs service – Manages the algorithms that are available to IPsec. By default, this service is enabled.
svc:/network/ipsec/manual-key service – Activates manual key management. By default, this service is disabled. The value of the config_file property determines the location of the ipseckeys configuration file. The initial value is /etc/inet/secret/ipseckeys.
svc:/network/ipsec/ike service – Manages IKE. By default, this service is disabled. For the configurable properties, see IKEv2 Service and IKEv1 Service.
For information about SMF, see Chapter 1, Introduction to the Service Management Facility, in Managing System Services in Oracle Solaris 11.2 . Also see the smf (5) , svcadm (1M) , and svccfg (1M) man pages.
You use the ipsecconf command to configure the IPsec policy for a host. When you run the command to configure the policy, the system creates the IPsec policy entries in the kernel. The system uses these entries to check the policy on all inbound and outbound IP packets. Packets that are not tunneled and forwarded are not subjected to policy checks that are added by using this command. The ipsecconf command also manages the IPsec entries in the security policy database (SPD). For IPsec policy options, see the ipsecconf (1M) man page.
You must assume the root role to invoke the ipsecconf command. The command can configure entries that protect traffic in both directions. The command also can configure entries that protect traffic in only one direction.
Policy entries with a format of local address and remote address can protect traffic in both directions with a single policy entry. For example, entries that contain the patterns laddr host1 and raddr host2 protect traffic in both directions if no direction is specified for the named host. Thus, you need only one policy entry for each host.
Policy entries that are added by the ipsecconf command are not persistent over a system reboot. To ensure that the IPsec policy is active when the system boots, add the policy entries to the /etc/inet/ipsecinit.conf file, then refresh or enable the policy service. For examples, see Protecting Network Traffic With IPsec.
To enable the IPsec security policy when you start Oracle Solaris, you create a configuration file to initialize IPsec with your specific IPsec policy entries. The default name for this file is /etc/inet/ipsecinit.conf. See the ipsecconf (1M) man page for details about policy entries and their format. After the policy is configured, you can refresh the policy with the svcadm refresh ipsec/policy command.
The Oracle Solaris software includes a sample IPsec policy file, ipsecinit.sample. You can use the file as a template to create your own ipsecinit.conf file. The ipsecinit.sample file contains the following examples:
...
# In the following simple example, outbound network traffic between the local
# host and a remote host will be encrypted. Inbound network traffic between
# these addresses is required to be encrypted as well.
#
# This example assumes that 10.0.0.1 is the IPv4 address of this host (laddr)
# and 10.0.0.2 is the IPv4 address of the remote host (raddr).
#
{laddr 10.0.0.1 raddr 10.0.0.2} ipsec
{encr_algs aes encr_auth_algs sha256 sa shared}
# The policy syntax supports IPv4 and IPv6 addresses as well as symbolic names.
# Refer to the ipsecconf(1M) man page for warnings on using symbolic names and
# many more examples, configuration options and supported algorithms.
#
# This example assumes that 10.0.0.1 is the IPv4 address of this host (laddr)
# and 10.0.0.2 is the IPv4 address of the remote host (raddr).
#
# The remote host will also need an IPsec (and IKE) configuration that mirrors
# this one.
#
# The following line will allow ssh(1) traffic to pass without IPsec protection:
{lport 22 dir both} bypass {}
#
# {laddr 10.0.0.1 dir in} drop {}
#
# Uncommenting the above line will drop all network traffic to this host unless
# it matches the rules above. Leaving this rule commented out will allow
# network packets that do not match the above rules to pass up the IP
# network stack. ,,,
IPsec policy cannot be changed for established connections. A socket whose policy cannot be changed is called a latched socket. New policy entries do not protect sockets that are already latched. For more information, see the connect (3SOCKET) and accept (3SOCKET) man pages. If you are in doubt, restart the connection. For more information, see the SECURITY section of the ipsecconf (1M) man page.
The Cryptographic Framework provides authentication and encryption algorithms to IPsec. The ipsecalgs command can list the algorithms that each IPsec protocol supports. The ipsecalgs configuration is stored in the /etc/inet/ipsecalgs file. Typically, this file does not need to be modified and must never be edited directly. However, if you need to modify the file, use the ipsecalgs command. The supported algorithms are synchronized with the kernel at system boot by the svc:/network/ipsec/ipsecalgs:default service.
The valid IPsec protocols and algorithms are described by the ISAKMP domain of interpretation (DOI), which is covered by RFC 2407. Specifically, the ISAKMP DOI defines the naming and numbering conventions for the valid IPsec algorithms and for their protocols, PROTO_IPSEC_AH and PROTO_IPSEC_ESP. Each algorithm is associated with exactly one protocol. These ISAKMP DOI definitions are in the /etc/inet/ipsecalgs file. The algorithm and protocol numbers are defined by the Internet Assigned Numbers Authority (IANA). The ipsecalgs command makes the list of algorithms for IPsec extensible.
For more information about the algorithms, refer to the ipsecalgs (1M) man page. For more information about the Cryptographic Framework, see Chapter 1, Cryptographic Framework, in Managing Encryption and Certificates in Oracle Solaris 11.2 .
The ipseckey command with various options manages keys for IPsec manually. For a description of the ipseckey command, see the ipseckey (1M) man page.
The ipseckey command enables a role with the Network Security or Network IPsec Management rights profile to enter sensitive cryptographic keying information. If an adversary gains access to this information, the adversary can compromise the security of IPsec traffic.
For more information, see the SECURITY section of the ipseckey (1M) man page.
The kstat command can display statistics about ESP, AH, and other IPsec data. The IPsec-related options are listed in Troubleshooting IPsec and IKE Semantic Errors. See also the kstat(1M) man page.
The snoop command can parse AH and ESP headers. Because ESP encrypts its data, the snoop command cannot see encrypted headers that are protected by ESP. AH does not encrypt data, so traffic that is protected by AH can be inspected with the snoop command. The –V option to the command shows when AH is in use on a packet. For more details, see the snoop (1M) man page.
For a sample of verbose snoop output on a protected packet, see How to Verify That Packets Are Protected With IPsec.
Third-party network analyzers are also available, such as the free open-source software Wireshark, which is bundled with this release.
The Internet Engineering Task Force (IETF) has published a number of Requests for Comment (RFCs) that describe the security architecture for the IP layer. For a link to the RFCs, see http://www.ietf.org/http://www.ietf.org/. The following list of RFCs covers the more general IP security references:
RFC 2411, “IP Security Document Roadmap,” November 1998
RFC 2401, “Security Architecture for the Internet Protocol,” November 1998
RFC 2402, “IP Authentication Header,” November 1998
RFC 2406, “IP Encapsulating Security Payload (ESP),” November 1998
RFC 2408, “Internet Security Association and Key Management Protocol (ISAKMP),” November 1998
RFC 2407, “The Internet IP Security Domain of Interpretation for ISAKMP,” November 1998
RFC 2409, “The Internet Key Exchange (IKEv1),” November 1998
RFC 5996, “Internet Key Exchange Protocol Version 2 (IKEv2),” September 2010
RFC 3554, “On the Use of Stream Control Transmission Protocol (SCTP) with IPsec,” July 2003