ipsecalgs

ipsecalgs -l

ipsecalgs -s

ipsecalgs -a [-P protocol-number | -p protocol-name] -k keylen-list
 [-i inc] [-K default-keylen] -b blocklen-list -n alg-names
 -N alg-number -m mech-name [-f] [-s]

ipsecalgs -P protocol-number -p protocol-name
 [-e exec-mode] [-f] [-s]

ipsecalgs -r -p protocol-name [] -n alg-name [-s]

ipsecalgs -r -p protocol-name [] -N alg-number [-s]

ipsecalgs -R -P protocol-number [-s]

ipsecalgs -R -p protocol-name [-s]

ipsecalgs -e exec-mode -P protocol-number [-s]

ipsecalgs -e exec-mode -p protocol-name [-s]

Use the ipsecalgs command to query and modify the IPsec protocol and algorithms stored in /etc/inet/ipsecalgs. You can use the ipsecalgs command to do the following:

Never edit the /etc/inet/ipsecalgs file manually. The valid IPsec protocols and algorithms are described by the ISAKMP DOI. See RFC 2407. In the general sense, a Domain of Interpretation (DOI) defines data formats, network traffic exchange types, and conventions for naming security-relevant information such as security policies or cryptographic algorithms and modes. For ipsecalgs, the DOI defines naming and numbering conventions for algorithms and the protocols they belong to. These numbers are defined by the Internet Assigned Numbers Authority (IANA). Each algorithm belongs to a protocol. Algorithm information includes supported key lengths, block or MAC length, and the name of the cryptographic mechanism corresponding to that algorithm. This information is used by the IPsec modules, ipsecesp(7P) and ipsecah(7P), to determine the authentication and encryption algorithms that can be applied to IPsec traffic.

The following protocols are predefined: IPSEC_PROTO_ESP

The mechanism name specified by an algorithm entry must correspond to a valid Solaris Cryptographic Framework mechanism. You can obtain the list of available mechanisms by using the cryptoadm(1M) command.

Applications can retrieve the supported algorithms and their associated protocols by using the functions getipsecalgbyname(3NSL), getipsecalgbynum(3NSL), getipsecprotobyname(3NSL) and getipsecprotobynum(3NSL).

Modifications to the protocols and algorithm by default update only the contents of the /etc/inet/ipsecalgs configuration file. In order for the new definitions to be used for IPsec processing, the changes must be communicated to the kernel using the -s option. See NOTES for a description of how the ipsecalgs configuration is synchronized with the kernel at system restart.

When invoked without arguments, ipsecalgs displays the list of mappings that are currently defined in /etc/inet/ipsecalgs. You can obtain the corresponding kernel table of protocols and algorithms by using the -l option.

ipsecalgs supports the following options: -a

128,192,256

32-448

des-cbs,des

Example 1 Adding a Protocol for IPsec Encryption

The following example shows how to add a protocol for IPsec encryption:

example# ipsecalgs -P 3 -p "IPSEC_PROTO_ESP"

Example 2 Adding the Blowfish Algorithm

The following example shows how to add the Blowfish algorithm:

example# ipsecalgs -a -P 3 -k 32-488 -K 128 -i 8 -n "blowfish" \e
 -b 8 -N 7 -m CKM_BF_CBC

Example 3 Updating the Kernel Algorithm Table

The following example updates the kernel algorithm table with the currently defined protocol and algorithm definitions:

example# svcadm refresh ipsecalgs

See attributes(5) for descriptions of the following attributes:

cryptoadm(1M), ipsecconf(1M), ipseckey(1M), svcadm(1M), getipsecalgbyname(3NSL), getipsecprotobyname(3NSL), ike.config(4), attributes(5), smf(5), ipsecah(7P), ipsecesp(7P)

Piper, Derrell, RFC 2407, The Internet IP Security Domain of Interpretation for ISAKMP. Network Working Group. November 1998.

When protocols or algorithm definitions that are removed or altered, services that rely upon these definitions can become unavailable. For example, if the IPSEC_PROTO_ESP protocol is removed, then IPsec cannot encrypt and decrypt packets.

Synchronization of the ipsecalgs configuration with the kernel at system startup is provided by the following smf(5) service:

svc:/network/ipsec/ipsecalgs:default

The IPsec services are delivered as follows:

svc:/network/ipsec/policy:default (enabled)
svc:/network/ipsec/ipsecalgs:default (enabled)
svc:/network/ipsec/manual-key:default (disabled)
svc:/network/ipsec/ike:default (disabled)

Services that are delivered disabled are delivered that way because the system administrator must create configuration files for those services before enabling them. See ipseckey(1M) and ike.config(4). The default policy for the policy service is to allow all traffic to pass without IPsec protection. See ipsecconf(1M).

The correct administrative procedure is to create the configuration file for each service, then enable each service using svcadm(1M), as shown in the following example:

example# svcadm enable ipsecalgs

The service's status can be queried using the svcs(1) command.

If the ipsecalgs configuration is modified, the new configuration should be resynchronized as follows:

example# svcadm refresh ipsecalgs

Administrative actions on this service, such as enabling, disabling, refreshing, and requesting restart can be performed using svcadm(1M). A user who has been assigned the authorization shown below can perform these actions:

solaris.smf.manage.ipsec

See auths(1), user_attr(4), rbac(5).

The ipsecalgs smf(5) service does not have any user-configurable properties.

The smf(5) framework records any errors in the service-specific log file. Use any of the following commands to examine the logfile property:

example# svcs -l ipsecalgs
example# svcprop ipsecalgs
example# svccfg -s ipsecalgs listprop

This command requires sys_ip_config privilege to operate and thus can run in the global zone and in exclusive-IP zones. All shared-IP zones share the same available set of algorithms; however, you can use ipsecconf(1M) to set up system policy that uses differing algorithms for various shared-IP zones. All exclusive-IP zones have their own set of algorithms.