JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
System Administration Guide: IP Services     Oracle Solaris 11 Express 11/10
search filter icon
search icon

Document Information


Part I TCP/IP Administration

1.  Planning an IPv4 Addressing Scheme (Tasks)

2.  Planning an IPv6 Addressing Scheme (Overview)

3.  Planning an IPv6 Network (Tasks)

4.  Configuring TCP/IP Network Services and IPv4 Addressing (Tasks)

5.  Enabling IPv6 on a Network (Tasks)

6.  Administering a TCP/IP Network (Tasks)

7.  Configuring IP Tunnels

8.  Troubleshooting Network Problems (Tasks)

9.  TCP/IP and IPv4 in Depth (Reference)

10.  IPv6 in Depth (Reference)


11.  About DHCP (Overview)

12.  Planning for DHCP Service (Tasks)

13.  Configuring the DHCP Service (Tasks)

14.  Administering DHCP (Tasks)

15.  Configuring and Administering the DHCP Client

16.  Troubleshooting DHCP (Reference)

17.  DHCP Commands and Files (Reference)

Part III IP Security

18.  IP Security Architecture (Overview)

19.  Configuring IPsec (Tasks)

20.  IP Security Architecture (Reference)

21.  Internet Key Exchange (Overview)

Key Management With IKE

IKE Key Negotiation

IKE Key Terminology

IKE Phase 1 Exchange

IKE Phase 2 Exchange

IKE Configuration Choices

IKE With Preshared Keys

IKE With Public Key Certificates

IKE and Hardware Acceleration

IKE and Hardware Storage

IKE Utilities and Files

22.  Configuring IKE (Tasks)

23.  Internet Key Exchange (Reference)

24.  IP Filter in Oracle Solaris (Overview)

25.   IP Filter (Tasks)

Part IV Networking Performance

26.  Integrated Load Balancer Overview

27.  Configuration of Integrated Load Balancer Tasks

28.  Virtual Router Redundancy Protocol (Overview)

29.  VRRP Configuration (Tasks)

30.  Implementing Congestion Control

Part V IP Quality of Service (IPQoS)

31.  Introducing IPQoS (Overview)

32.  Planning for an IPQoS-Enabled Network (Tasks)

33.  Creating the IPQoS Configuration File (Tasks)

34.  Starting and Maintaining IPQoS (Tasks)

35.  Using Flow Accounting and Statistics Gathering (Tasks)

36.  IPQoS in Detail (Reference)



IKE Configuration Choices

The /etc/inet/ike/config configuration file contains IKE policy entries. For two IKE daemons to authenticate each other, the entries must be valid. Also, keying material must be available. The entries in the configuration file determine the method for using the keying material to authenticate the Phase 1 exchange. The choices are preshared keys or public key certificates.

The entry auth_method preshared indicates that preshared keys are used. Values for auth_method other than preshared indicate that public key certificates are to be used. Public key certificates can be self-signed, or the certificates can be installed from a PKI organization. For more information, see the ike.config(4) man page.

IKE With Preshared Keys

Preshared keys are created by an administrator on one system. The keys are then shared out of band with administrators of remote systems. You should take care to create large random keys and to protect the file and the out-of-band transmission. The keys are placed in the /etc/inet/secret/ike.preshared file on each system. The ike.preshared file is for IKE as the ipseckeys file is for IPsec. Any compromise of the keys in the ike.preshared file compromises all keys that are derived from the keys in the file.

One system's preshared key must be identical to its remote system's key. The keys are tied to a particular IP address or range of addresses. Keys are most secure when one administrator controls the communicating systems or subnets. For more information, see the ike.preshared(4) man page.

IKE With Public Key Certificates

Public key certificates eliminate the need for communicating systems to share secret keying material out of band. Public keys use the Diffie-Hellman protocol (DH) for authenticating and negotiating keys. Public key certificates come in two flavors. The certificates can be self-signed, or the certificates can be certified by a certificate authority (CA).

Self-signed public key certificates are created by you, the administrator. The ikecert certlocal -ks command creates the private part of the public-private key pair for the system. You then get the self-signed certificate output in X.509 format from the remote system. The remote system's certificate is input to the ikecert certdb command for the public part of the key pair. The self-signed certificates reside in the /etc/inet/ike/publickeys directory on the communicating systems. When you use the -T option, the certificates reside on attached hardware.

Self-signed certificates are a halfway point between preshared keys and CAs. Unlike preshared keys, a self-signed certificate can be used on a mobile machine or on a system that might be renumbered. To self-sign a certificate for a system without a fixed number, use a DNS ( or email ( alternative name.

Public keys can be delivered by a PKI or a CA organization. You install the public keys and their accompanying CAs in the /etc/inet/ike/publickeys directory. When you use the -T option, the certificates reside on attached hardware. Vendors also issue certificate revocation lists (CRLs). Along with installing the keys and CAs, you are responsible for installing the CRL in the /etc/inet/ike/crls directory.

CAs have the advantage of being certified by an outside organization, rather than by the site administrator. In a sense, CAs are notarized certificates. As with self-signed certificates, CAs can be used on a mobile machine or on a system that might be renumbered. Unlike self-signed certificates, CAs can very easily scale to protect a large number of communicating systems.