svcadm(1M)을 검색하려면 섹션에서 1M 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
ipsecconf(8)
System Administration Commands ipsecconf(8)
NAME
ipsecconf - configure system wide IPsec policy
SYNOPSIS
/usr/sbin/ipsecconf
/usr/sbin/ipsecconf -a file [-q]
/usr/sbin/ipsecconf -c file
/usr/sbin/ipsecconf -d [-i tunnel-name] {index, tunnel-name, index}
/usr/sbin/ipsecconf -f [-i tunnel-name]
/usr/sbin/ipsecconf -F
/usr/sbin/ipsecconf -Fa file [-q]
/usr/sbin/ipsecconf -l [-i tunnel-name] [-n]
/usr/sbin/ipsecconf -L [-n]
/usr/sbin/ipsecconf -r file [-q]
DESCRIPTION
The ipsecconf utility configures the IPsec policy for a host or for one
of its tunnels. Once the policy is configured, all outbound and inbound
datagrams are subject to policy checks as they exit and enter the host
or tunnel. For the host policy, if no entry is found, no policy checks
will be completed, and all the traffic will pass through. For a tunnel,
if no entry is found and there is at least one entry for the tunnel,
the traffic will automatically drop. The difference in behavior is
because of the assumptions about IPsec tunnels made in many implementa‐
tions. Datagrams that are being forwarded will not be subjected to pol‐
icy checks that are added using this command. See dladm(8) for informa‐
tion on how to protect forwarded packets. Depending upon the match of
the policy entry, a specific action will be taken.
Users with the Network IPSec Management rights profile can run this
command.
Each entry can protect traffic in either one direction (requiring a
pair of entries) or by a single policy entry which installs the needed
symmetric sadb rules.
When the command is issued without any arguments, the list of file pol‐
icy entries loaded are shown. To display the SPD policy entries use the
-l option. Both will display the index number for the entry. To specify
a single tunnel's SPD, use the -i option in combination with -l. To
specify all SPDs, both host and for all tunnels, use -L.
Note, since one file policy entry (FPE) can generate multiple SPD pol
entries (SPEs), the list of FPEs may not show all the actual entries.
However, it is still useful in determining what what rules have been
added to get the spd into its current state.
You can use the -d option with the index to delete a given policy in
the system. If the -d option removes an FPE entry that produces multi‐
ple SPEs, only then SPD with the same policy index as the FPE will be
removed. This can produce a situation where there may be SPEs when
there are no FPEs.
As with -l, -d can use the -i flag to indicate a tunnel. An alternate
syntax is to specify a tunnel name, followed by a comma (,), followed
by an index. For example, ip.tun0,1.
With no options, the entries are displayed in the order that they were
added, which is not necessarily the order in which the traffic match
takes place.
To view the order in which the traffic match will take place, use the
-l option. The rules are ordered such that all bypass rules are checked
first, then ESP rules, then AH rules. After that, they are checked in
the order entered.
Policy entries are not preserved across system restarts. Permanent pol‐
icy entries should be added to /etc/inet/ipsecinit.conf. This file is
read by the following smf(7) service:
svc:/network/ipsec/policy
See NOTES for more information on managing IPsec security policy and
SECURITY for issues in securing /etc/inet/ipsecinit.conf.
OPTIONS
ipsecconf supports the following options:
-a file
Add the IPsec policy to the system as specified by each entry in
the file. An IPsec configuration file contains one or more entries
that specify the configuration. Once the policy is added, all out‐
bound and inbound datagrams are subject to policy checks.
Policy is latched for TCP/UDP sockets on which a connect(3C) or
accept(3C) is issued. So, the addition of new policy entries may
not affect such endpoints or sockets. However, the policy will be
latched for a socket with an existing non-null policy. Thus, make
sure that there are no preexisting connections that will be subject
to checks by the new policy entries.
The feature of policy latching explained above may change in the
future. It is not advisable to depend upon this feature.
The default behavior is to append new rules to the existing policy.
If a new rule conflicts with an existing rule, an error is
reported, the new rule will not be added.
To add a new rule that conflicts with an existing rule, the exist‐
ing rule must be removed (see below) or the existing policy
flushed. If the policy is flushed, IPsec will not protect any net‐
work traffic until a new policy is added.
The -F (flush) flag can be combined with -a to perform an atomic
policy replacement; the existing policy will be replaced by the new
policy described in the config file. By combining these two flags,
there is not even a small window when the system is without a pol‐
icy, which is the case when the flush and add commands are run
sequentially.
-c file
Check the syntax of the configuration file and report any errors
without making any changes to the policy. This option is useful
when debugging configurations and when smf(7) reports a configura‐
tion error. See SECURITY.
-d index
Delete the host policy denoted by the index. The index is obtained
by invoking ipsecconf without any arguments, or with the -l option.
See DESCRIPTION for more information. Once the entry is deleted,
all outbound and inbound datagrams affected by this policy entry
will not be subjected to policy checks. Be advised that with con‐
nections for which the policy has been latched, packets will con‐
tinue to go out with the same policy, even if it has been deleted.
It is advisable to use the -l option to find the correct policy
index.
-d name,index
Delete the policy entry denoted by index on a tunnel denoted by
name. Since tunnels affect traffic that might originate off-node,
latching does not apply as it does in the host policy case. Equiva‐
lent to: -d index -i name.
-f
Flush all the policies in the system. Constraints are similar to
the -d option with respect to latching and host versus per-tunnel
behavior.
-F
Flush all policies on all tunnels and also flush all host policies.
See discussion of combining the -F and -a options, under -a, above.
-i name
Specify a tunnel interface name for use with the -d, -f, or -l
flags.
-l
Listing of a single policy table, defaulting to the host policy.
When ipsecconf is invoked without any arguments, a complete list of
policy entries with indexes added by the user since boot is dis‐
played. The current table can differ from the previous one if, for
example, a multi-homed entry was added or policy reordering
occurred, or if a single rule entry generates two spd rules. In the
case of a multi-homed entry, all the addresses are listed explic‐
itly. If a mask was not specified earlier but was instead inferred
from the address, it will be explicitly listed here. This option is
used to view policy entries in the correct order. The outbound and
inbound policy entries are listed separately.
-L
Lists all policy tables, including host policy and all tunnel
instances (including configured but unplumbed).
If -i is specified, -L lists the policy table for a specific tunnel
interface.
-n
Show network addresses, ports, protocols in numbers. The -n option
may only be used with the -l option.
-q
Quiet mode. Suppresses the warning message generated when adding
policies.
-r file
Remove IPsec policy rules from the system as specified by each
entry in file. The format of the file contents is the same as is
specified with the -a option. The file could be created with ipsec‐
conf -l and then modified with an editor.
OPERANDS
Each policy entry contains three parts specified as follows:
{pattern} action {properties}
or
{pattern} action {properties} ["or" action {properties}]*
Every policy entry begins on a new line and can span multiple lines. If
an entry exceeds the length of a line, you should split it only within
a "braced" section or immediately before the first (left-hand) brace of
a braced section. Avoid using the backslash character (\). See EXAM‐
PLES.
The pattern section, as shown in the syntax above, specifies the traf‐
fic pattern that should be matched against the outbound and inbound
datagrams. If there is a match, a specific action determined by the
second argument will be taken, depending upon the properties of the
policy entry.
If there is an or in the rule (multiple action-properties for a given
pattern), a transmitter will use the first action-property pair that
works, while a receiver will use any that are acceptable.
pattern and properties are name-value pairs where name and value are
separated by a <space>, <tab> or <newline>. Multiple name-value pairs
should be separated by <space>, <tab> or <newline>. The beginning and
end of the pattern and properties are marked by { and } respectively.
Files can contain multiple policy entries. An unspecified name-value
pair in the pattern will be considered as a wildcard. Wildcard entries
match any corresponding entry in the datagram.
One thing to remember is that UDP port 500 is always bypassed for the
key management daemons themselves regardless of any policy entries.
This is a requirement for in.iked(8) to work.
File can be commented by using a # as the first character. Comments may
be inserted either at the beginning or the end of a line.
The complete syntax of a policy entry is:
policy ::= { <pattern1> } <action1> { <properties1> } |
{ <pattern2> } <action2> { <properties2> }
[ 'or' <action2> { <properties2>} ]*
pattern1 ::= <pattern_name_value_pair1>*
pattern2 ::= <pattern_name_value_pair2>*
action1 ::= apply | permit | bypass | pass
action2 ::= bypass | pass | drop | ipsec
properties1 ::= {<prop_name_value_pair1>}
properties2 ::= {<prop_name_value_pair2>}
pattern_name_value_pair1 ::=
saddr <address>/<prefix> |
src <address>/<prefix> |
srcaddr <address>/<prefix> |
smask <mask> |
sport <port> |
daddr <address>/<prefix> |
dst <address>/<prefix> |
dstaddr <address>/<prefix> |
dmask <mask> |
dport <port> |
ulp <protocol> |
proto <protocol> |
type <icmp-type> |
type <number>-<number> |
code <icmp-code>
code <number>-<number>
tunnel <interface-name> |
negotiate <tunnel,transport> |
dir <dir_val2>
pattern_name_value_pair2 ::=
raddr <address>/<prefix> |
remote <address>/<prefix> |
rport <port> |
laddr <address>/<prefix> |
local <address>/<prefix> |
lport <port> |
ulp <protocol> |
type <icmp-type> |
type <number>-<number> |
code <icmp-code> |
code <number>-<number>
proto <protocol> |
tunnel <interface-name> |
negotiate <tunnel,transport> |
dir <dir_val2>
address ::= <IPv4 dot notation> | <IPv6 colon notation> |
<String recognized by gethostbyname>|
<String recognized by getnetbyname>
prefix ::= <number>
mask ::= <0xhexdigit[hexdigit]> | <0Xhexdigit[hexdigit]> |
<IPv4 dot notation>
port ::= <number>| <String recognized by getservbyname>
protocol ::= <number>| <String recognized by getprotobyname>
prop_name_value_pair1 ::=
auth_algs <auth_alg> |
encr_algs <encr_alg> |
encr_auth_algs <auth_alg> |
sa <sa_val> |
dir <dir_val1> |
ike_version <version> |
tfc mtu
prop_name_value_pair2 ::=
auth_algs <auth_alg> |
encr_algs <encr_alg> |
encr_auth_algs <auth_alg> |
sa <sa_val>
auth_alg ::= <auth_algname>
auth_algname ::= <auth_algname>
encr_alg ::= <encr_algname> ['(' <keylen> ')']
encr_algname ::= <encr_algname> ['(' <keylen> ')']
keylen ::= <number> | <number>'..' | '..'<number> | <number>'..' \
<number>
sa_val ::= shared | unique
dir_val1 ::= out | in
dir_val2 ::= out | in | both
version ::= 1 | 2
number ::= < 0 | 1 | 2 ... 9> <number>
icmp-type ::= <number> | unreach | echo | echorep | squench |
redir | timex | paramprob | timest | timestrep |
inforeq | inforep | maskreq | maskrep | unreach6 |
pkttoobig6 | timex6 | paramprob6 | echo6 | echorep6 |
router-sol6 | router-ad6 | neigh-sol6 | neigh-ad6 |
redir6
icmp-code ::= <number> | net-unr | host-unr | proto-unr | port-unr |
needfrag | srcfail | net-unk | host-unk | isolate |
net-prohib | host-prohib | net-tos | host-tos |
filter-prohib | host-preced | cutoff-preced |
no-route6 | adm-prohib6 | addr-unr6 | port-unr6 |
hop-limex6 | frag-re-timex6 | err-head6 | unrec-head6 |
unreq-opt6
Policy entries may contain the following (name value) pairs in the pat‐
tern field. Each (name value) pair may appear only once in given policy
entry.
laddr/plen
local/plen
The value that follows is the local address of the datagram with
the prefix length. Only plen leading bits of the source address of
the packet will be matched. plen is optional. Local means destina‐
tion on incoming and source on outgoing packets. The source address
value can be a hostname as described in getaddrinfo(3SOCKET) or a
network name as described in getnetbyname(3C) or a host address or
network address in the Internet standard dot notation. See
inet_addr(3C). If a hostname is given and getaddrinfo(3C) returns
multiple addresses for the host, then policy will be added for each
of the addresses with other entries remaining the same.
raddr/plen
remote/plen
The value that follows is the remote address of the datagram with
the prefix length. Only plen leading bits of the remote address of
the packet will be matched. plen is optional. Remote means source
on incoming packets and destination on outgoing packets. The remote
address value can be a hostname as described in getaddrinfo(3C) or
a network name as described in getnetbyname(3C) or a host address
or network address in the Internet standard dot notation. See
inet_addr(3C). If a hostname is given and getaddrinfo(3C) returns
multiple addresses for the host, then policy will be added for each
of the addresses with other entries remaining the same.
src/plen
srcaddr/plen
saddr/plen
The value that follows is the source address of the datagram with
the prefix length. Only plen leading bits of the source address of
the packet will be matched. plen is optional.
The source address value can be a hostname as described in getad‐
drinfo(3C) or a network name as described in getnetbyname(3C) or a
host address or network address in the Internet standard dot nota‐
tion. See inet_addr(3C).
If a hostname is given and getaddrinfo(3C) returns multiple
addresses for the host, then policy will be added for each of the
addresses with other entries remaining the same.
daddr/plen
dest/plen
dstaddr/plen
The value that follows is the destination address of the datagram
with the prefix length. Only plen leading bits of the destination
address of the packet will be matched. plen is optional.
See saddr for valid values that can be given. If multiple source
and destination addresses are found, then a policy entry that cov‐
ers each source address-destination address pair will be added to
the system.
smask
For IPv4 only. The value that follows is the source mask. If prefix
length is given with saddr, this should not be given. This can be
represented either in hexadecimal number with a leading 0x or 0X,
for example, 0xffff0000, 0Xffff0000 or in the Internet decimal dot
notation, for example, 255.255.0.0 and 255.255.255.0. The mask
should be contiguous and the behavior is not defined for non-con‐
tiguous masks.
smask is considered only when saddr is given.
For both IPv4 and IPv6 addresses, the same information can be spec‐
ified as a slen value attached to the saddr parameter.
dmask
Analogous to smask.
lport
The value that follows is the local port of the datagram. This can
be either a port number or a string searched with a NULL proto
argument, as described in getservbyname(3C).
rport
The value that follows is the remote port of the datagram. This can
be either a port number or a string searched with a NULL proto
argument, as described in getservbyname(3C).
sport
The value that follows is the source port of the datagram. This can
be either a port number or a string searched with a NULL proto
argument, as described in getservbyname(3C).
dport
The value that follows is the destination port of the datagram.
This can be either a port number or a string as described in get‐
servbyname(3C) searched with NULL proto argument.
proto ulp
The value that follows is the Upper Layer Protocol that this entry
should be matched against. It could be a number or a string as
described in getprotobyname(3C). If no smask or plen is specified,
a plen of 32 for IPv4 or 128 for IPv6 will be used, meaning a host.
If the ulp is icmp or ipv6-icmp, any action applying IPsec must be
the same for all icmp rules.
type num or num-num
The value that follows is the ICMP type that this entry should be
matched against. type must be a number from 0 to 255, or one of the
appropriate icmp-type keywords. Also, ulp must be present and must
specify either icmp or ipv6-icmp. A range of types can be specified
with a hyphen separating numbers.
Note -
If icmp-code is to be specified, it must be done in conjunction
with icmp-type. The icmp-code should be specified after icmp-
type, otherwise an error will occur.
code num or num-num
The value that follows is the ICMP code that this entry should be
matched against. The value following the keyword code must be a
number from 0 to 254 or one of the appropriate icmp-code keywords.
Also, type must be present. A range of codes can be specified with
a hyphen separating numbers.
tunnel name
Specifies a tunnel network interface, as configured with ifcon‐
fig(8). If a tunnel of name does not yet exist, the policy entries
are added anyway, and joined with the tunnel state when it is cre‐
ated. If a tunnel is unplumbed, its policy entries disappear.
negotiate tunnel
negotiate transport
For per-tunnel security, specify whether the IPsec SAs protecting
the traffic should be tunnel-mode SAs or transport-mode SAs. If
transport-mode SAs are specified, no addresses can appear in the
policy entry. Transport-mode is backward compatible with Solaris 9,
and tunnel IPsec policies configured with ifconfig(8) will show up
as transport mode entries here.
Policy entries may contain the following (name-value) pairs in the
properties field. Each (name-value) pair may appear only once in a
given policy entry.
auth_algs
An acceptable value following this implies that IPsec AH header
will be present in the outbound datagram, after the outer IP
header. The algorithm specified after the auth_algs keyword will be
used to generate an Integrity Check Value (ICV) based on the con‐
tents of the original packet. The following algorithms do not
encrypt the contents of the packet, just provide a mechanism to
verify the packets contents have not been modified in transit. See
RFC 2402.
If auth_algs is used in conjunction with encr_algs, the original
payload will be encrypted using the algorithm specified after
encr_algs. The ICV generated by AH in this case will be of the
encrypted packet and the ESP header that was inserted after the
encryption.
Different authentication algorithms produce different length ICV's.
Generally, the longer the ICV, the stronger the authentication. The
stronger algorithms usually come with a performance penalty.
This entry should contain a string.
string
Can be one of the following:
string value: Algorithm Used: See RFC:
------------------------------------------------------
sha256 or hmac-sha256 HMAC-SHA256 4868
sha384 or hmac-sha384 HMAC-SHA384 4868
sha512 or hmac-sha512 HMAC-SHA512 4868
aes-xcbc AES-XCBC-MAC-96 3566
aes-gmac128 AES-GMAC 4543
aes-gmac192 AES-GMAC 4543
aes-gmac256 AES-GMAC 4543
Note -
The values of auth_algs that use the AES-GMAC algorithm all
generate the same length ICV, but take different length keys,
128, 192 or 256 bits respectively.
For backward compatibility reasons, the following deprecated
authentication algorithms are also allowed. However, adminis‐
trators are encouraged to migrate away from these obsolete
algorithms as soon as feasible.
string value: Algorithm Used: See RFC:
------------------------------------------------------------
sha1 or hmac-sha1 or sha HMAC-SHA1 2404
You can use the ipsecalgs(8) command to obtain the complete
list of authentication algorithms.
Strings are not case-sensitive.
If auth_algs is not present, the AH header will not be present in
the outbound datagram, and the same will be verified for the
inbound datagram.
encr_algs
An acceptable value following this keyword implies that IPsec ESP
header will be present in the outbound datagram. The value
describes the encryption algorithm that will be used to encrypt
original payload of the outbound datagram. Some of the algorithms
listed below also generate an Integrity Check Value (ICV) based on
the contents of the encrypted packet and the ESP header. The ICV
generated is added to the end of the datagram, after the encrypted
payload and can be used by the receiving system to verify the
packet has not been modified in transit. See RFC 2406.
Algorithms that do not generate an ICV as part of the encryption
operation should be used in conjunction with an authentication
algorithm specified with the encr_auth_algs keyword.
The following tables list supported encryption only algorithms and
combined mode encryption algorithms.
This entry should contain a string. Strings are not case-sensitive.
string
The following encryption algorithms provide encryption only and
require an authentication algorithm to generate an ICV. They
should be used in conjunction with the encr_auth_algs keyword.
Each of the following algorithms support key lengths of 128,
192, or 256 bits.
string value: Algorithm Used: See RFC:
----------------------------------------------------------
aes or aes-cbc AES-CBC 2451
camellia or camellia-cbc Camellia-CBC 4312
The following combined modes algorithms combine encryption and
ICV generation into a single operation. They should not be used
in conjunction with the encr_auth_algs keyword.
Each of the following algorithms support key lengths of 128,
192, or 256 bits.
string value: Algorithm Used: ICV Length See RFC:
---------------------------------------------------------------
aes-ccm or aes-ccm16 AES-CCM 16 bytes 4309
aes-ccm8 AES-CCM 8 bytes 4309
aes-ccm12 AES-CCM 12 bytes 4309
aes-gcm or aes-gcm16 AES-GCM 16 bytes 4106
aes-gcm8 AES-GCM 8 bytes 4106
aes-gcm12 AES-GCM 12 bytes 4106
aes-none-gmac [*] AES-GMAC 16 bytes 4543
[*] Generates ICV for authentication only, without encryption.
See the example on using AES GMAC, in the Examples section
below.
For backward compatibility reasons, the following deprecated
encryption only algorithms are also allowed. However, adminis‐
trators are encouraged to migrate away from these obsolete
algorithms as soon as feasible.
tab(); lw(1.83i) lw(1.83i) lw(1.83i) lw(1.83i) lw(1.83i)
lw(1.83i) string value:Algorithm Used:See RFC: _ 3des or 3des-
cbc3DES-CBC2451
You can use the ipsecalgs(8) command to obtain the complete
list of authentication algorithms.
The value can be NULL, which implies a NULL encryption, pur‐
suant to RFC 2410. This means that the payload will not be
encrypted. The string can also be ANY, which indicates no-pref‐
erence for the algorithm. Default algorithms will be chosen
depending upon the SAs available at the time for manual SAs and
upon the key negotiating daemon for automatic SAs. Strings are
not case-sensitive.
encr_auth_algs
An acceptable value following encr_auth_algs implies that the IPsec
ESP header will be present in the outbound datagram. The values
following encr_auth_algs describe the authentication algorithms
that will be used while applying the IPsec ESP protocol on outbound
datagrams and verified to be present on inbound datagrams. See RFC
2406. This entry can must contain a string. Strings are case-insen‐
sitive.
string
Can be one of the following:
string value: Algorithm Used: See RFC:
------------------------------------------------------
sha256 or hmac-sha256 HMAC-SHA256 4868
sha384 or hmac-sha384 HMAC-SHA384 4868
sha512 or hmac-sha512 HMAC-SHA512 4868
aes-xcbc AES-XCBC-MAC-96 3566
For backward compatibility reasons, the following deprecated
authentication algorithms are also allowed. However, adminis‐
trators are encouraged to migrate away from these obsolete
algorithms as soon as feasible.
string value: Algorithm Used: See RFC:
-----------------------------------------------------------
sha1 or hmac-sha1 or sha HMAC-SHA1 2404
You can use the ipsecalgs(8) command to obtain the complete
list of authentication algorithms. Strings are not case-sensi‐
tive.
If encr_algs is present and encr_auth_algs is not present in a pol‐
icy entry, the system will use an ESP SA regardless of whether the
SA has an authentication algorithm or not.
If encr_algs is not present and encr_auth_algs is present in a pol‐
icy entry, null encryption will be provided, which is equivalent to
encr_algs with NULL, for outbound and inbound datagrams.
If both encr_algs and encr_auth_algs are not present in a policy
entry, ESP header will not be present for outbound datagrams and
the same will be verified for inbound datagrams.
If both encr_algs and encr_auth_algs are present in a policy entry,
ESP header with integrity checksum will be present on outbound
datagrams and the same will be verified for inbound datagrams.
For encr_algs, encr_auth_algs, and auth_algs a key length specifi‐
cation may be present. This is either a single value specifying the
only valid key length for the algorithm or a range specifying the
valid minimum and/or maximum key lengths. Minimum or maximum
lengths may be omitted.
dir
Values following this decides whether this policy entry is applied
to outbound and/or inbound datagrams. Generally this value should
not be specified, because for typical network traffic an IPsec pol‐
icy should apply to both inbound and outbound traffic. Most common
network protocols are bidirectional.
This entry is not needed when the action is "apply" or "permit"
because it is implied with those actions. It is not valid when the
action is "ipsec" because this implies both directions.
The exception is the "bypass" action, when this is mandatory.
If a direction is specified, great care should be taken to ensure
the peer has a matching reverse policy, otherwise IKE negotiation
may fail.
Valid values are strings that should be one of the following:
out
This means that this policy entry should be considered only for
outbound datagrams. This is equivalent to not specifying any‐
thing.
in
This means that this policy entry should be considered only for
inbound datagrams.
both
This means that this policy entry should be considered for both
inbound and outbound datagrams
sa
Values following this decide the attribute of the security associa‐
tion. Value indicates whether a unique security association should
be used or any existing SA can be used. If there is a policy
requirement, SAs are created dynamically on the first outbound
datagram using the key management daemon. Static SAs can be created
using ipseckey(8). The values used here determine whether a new SA
will be used/obtained. Valid values are strings that could be one
of the following:
unique
Unique Association. A new/unused association will be
obtained/used for packets matching this policy entry. If an SA
that was previously used by the same 5 tuples, that is, {Source
address, Destination address, Source port, Destination Port,
Protocol (for example, TCP/UDP)} exists, it will be reused.
Thus uniqueness is expressed by the 5 tuples given above. The
security association used by the above 5 tuples will not be
used by any other socket. For inbound datagrams, uniqueness
will not be verified.
For tunnel-mode tunnels, unique is ignored. SAs are assigned
per-rule in tunnel-mode tunnels. For transport-mode tunnels,
unique is implicit, because the enforcement happens only on the
outer-packet addresses and protocol value of either IPv4-in-IP
or IPv6-in-IP.
shared
Shared association. If an SA exists already for this source-
destination pair, it will be used. Otherwise a new SA will be
obtained. This is the default.
This is mandatory only for outbound policy entries and should not
be given for entries whose action is "bypass". If this entry is not
given for inbound entries, for example, when "dir" is in or
"action" is permit, it will be assumed to be shared.
ike_version
Constrain this policy so that requests for IPsec SAs are only pro‐
cessed by a specific version of IKE daemon. Specify ike_version 1
for in.iked(8) and ike_version 2 for in.ikev2d(8). Lack of this
action shall be interpreted as a wild card, that is, any suitably
configured daemon can respond.
tfc
Enable Traffic Flow Confidentiality (TFC) on this rule. When TFC is
enabled, ESP protected packets are padded with dummy data before
being encrypted. This helps disguise traffic patterns. The packets
are padded to the MTU. The generation, encryption and processing of
dummy data requires resources so there is a performance impact. TFC
is only supported in tunnel mode.
mtu
The only supported value of tfc is padding of the packet to the
path MTU of that connection. The value of MTU is calculated by IP.
This property is optional. If it is not set, in.ikev2d will send
the following notification to its peer when negotiating child SAs:
IKEV2_ESP_TFC_PADDING_NOT_SUPPORTED
Action follows the pattern and should be given before properties. It
should be one of the following and this field is mandatory.
ipsec
Use IPsec for the datagram as described by the properties, if the
pattern matches the datagram. If ipsec is given without a dir spec,
the pattern is matched to incoming and outgoing datagrams.
apply
Apply IPsec to the datagram as described by the properties, if the
pattern matches the datagram. If apply is given, the pattern is
matched only on the outbound datagram.
permit
Permit the datagram if the pattern matches the incoming datagram
and satisfies the constraints described by the properties. If it
does not satisfy the properties, discard the datagram. If permit is
given, the pattern is matched only for inbound datagrams.
bypass
pass
Bypass any policy checks if the pattern matches the datagram. dir
in the properties decides whether the check is done on outbound or
inbound datagrams. All the bypass entries are checked before check‐
ing with any other policy entry in the system. This has the highest
precedence over any other entries. dir is the only field that
should be present when action is bypass.
drop
Drop any packets that match the pattern.
If the file contains multiple policy entries, for example, they are
assumed to be listed in the order in which they are to be applied. In
cases of multiple entries matching the outbound and inbound datagram,
the first match will be taken.
If the new entry has bypass as action, bypass has the highest prece‐
dence. It can be added in any order, and the system will still match
all the bypass entries before matching any other entries. This is use‐
ful for key management daemons which can use this feature to bypass
IPsec as it protects its own traffic.
Entries with both AH (auth_algs present in the policy entry) and ESP
(encr_auth_algs or encr_auth_algs present in the policy entry) protec‐
tion are ordered after all the entries with AH and ESP and before any
AH-only and ESP-only entries. In all other cases the order specified by
the user is not modified, that is, newer entries are added at the end
of all the old entries.
A new entry is considered duplicate of the old entry if an old entry
matches the same traffic pattern as the new entry.
SECURITY
If, for example, the policy file comes over the wire from an NFS
mounted file system, an adversary can modify the data contained in the
file, thus changing the policy configured on the machine to suit their
needs. Administrators should be cautious about transmitting a copy of
the policy file over a network.
To prevent non-privileged users from modifying the security policy,
ensure that the configuration file is writable only by trusted users.
The configuration file is defined by a property of the policy smf(7)
service. The default configuration file, is /etc/inet/ipsecinit.conf.
This can be changed using the svcprop(1) command. See NOTES for more
details.
The policy description language supports the use of tokens that can be
resolved by means of a name service, using functions such as gethostby‐
name(3C). While convenient, these functions are only secure as the name
service the system is configured to use. Great care should be taken to
secure the name service if it is used to resolve elements of the secu‐
rity policy.
If your source address is a host that can be looked up over the network
and your naming system itself is compromised, then any names used will
no longer be trustworthy.
If the name switch is configured to use a name service that is not
local to the system, bypass policy entries might be required to prevent
the policy from preventing communication to the name service. See nss‐
witch.conf(5).
Policy is latched for TCP/UDP sockets on which a connect(3C) or
accept(3C) has been issued. Adding new policy entries will not have any
effect on them. This feature of latching may change in the future. It
is not advisable to depend upon this feature.
The ipsecconf command can only be run by a user who has sufficient
privilege to open the pf_key(4P) socket. The appropriate privilege can
be assigned to a user with the Network IPsec Management profile. See
profiles(1), rbac(7), prof_attr(5).
Make sure to set up the policies before starting any communications, as
existing connections may be affected by the addition of new policy
entries. Similarly, do not change policies in the middle of a communi‐
cation.
Note that certain ndd tunables affect how policies configured with this
tool are enforced; see ipsecesp(4P) for more details.
EXAMPLES
Example 1 Protecting all Traffic Between Two Hosts by Using ESP
The following example specifies that the traffic is protected by using
the AES encryption algorithm and authenticated by using SHA256.
{ laddr spiderweb raddr arachnid } ipsec
{ encr_algs aes encr_auth_algs sha256 }
Example 2 Authenticating all Inbound Traffic to the Telnet Port by
Using AH
This entry specifies that any inbound datagram to telnet port should be
protected by AH and authenticated with the SHA1 algorithm. Otherwise,
the datagram will be discarded. Without this entry, traffic destined to
port number 23 would be permitted without any protection. Traffic that
does not use port 23 will not match this rule, if this is the only
rule, all other traffic will not need IPsec protection.
#
# All the inbound traffic to the telnet port should be
# authenticated.
#
{ lport telnet dir in } ipsec { auth_algs sha1 }
Example 3 Verifying Inbound Traffic by Using ESP Null-Encrypted
The first entry permits any packets from address host-B to enter the
system without IPsec protection. The second entry requires packets from
an address machine, the network-B specification to be protected with
ESP, NULL encrypted but use sha512 for authentication.
Null-Encrypted ESP gives a similar level of protection as AH.
#
# Make sure that all inbound traffic from network-B is NULL
# encrypted, but bypass for host-B alone from that network.
# Add the bypass first.
{ raddr host-B dir in } bypass {}
# Now add for network-B.
{ raddr network-B/16 dir in } ipsec
{ encr_algs NULL encr_auth_algs sha512 }
Example 4 Entries to Allow DNS Traffic to Bypass IPsec
The first two entries permit any datagram leaving the machine with
source port 53 or coming into port number 53 to pass without IPsec pro‐
tection, irrespective of any other policy entry in the system. Thus the
latter two entries will be considered only for ports other than port
number 53.
#
# Bypass traffic for port number 53
#
{lport 53 dir out} bypass {}
{rport 53 dir in} bypass {}
{raddr spiderweb } ipsec {encr_algs aes-ccm sa unique}
Example 5 Protecting Outbound Traffic
#
# Protect the outbound traffic from all interfaces.
#
{raddr spiderweb dir out} ipsec {auth_algs any sa unique}
{ laddr arachnid raddr spiderweb dir in } ipsec
{auth_algs sha256 sa unique}
If the gethostbyname(3C) call for spiderweb yields multiple addresses,
multiple policy entries will be added for all the source address with
the same properties.
{
laddr arachnid
raddr spiderweb
dir in
} ipsec {auth_algs any sa unique}
If the gethostbyname(3C) call for spiderweb and the gethostbyname(3C)
call for arachnid yield multiple addresses, multiple policy entries
will be added for each (saddr daddr) pair with the same properties.
Use ipsecconf -l to view all the policy entries added.
Example 6 Bypassing Unauthenticated Traffic
#
# Protect all the outbound traffic with ESP except any traffic
# to network-b which should be authenticated and bypass anything
# to network-c
#
{raddr network-b/16 dir out} ipsec {auth_algs sha256 }
{dir out} ipsec {encr_algs aes-ccm}
{raddr network-c/16 dir out} bypass {}
Note that bypass can be given anywhere and it will take precedence over
all other entries. NULL pattern in the second rule matches all the
traffic.
Example 7 Encrypting IPv6 Traffic With Camellia and sha256
Requires packets between the host with the address
fe80::a00:20ff:fe21:4483 and the host with the address
fe80::a00:20ff:felf:e346 to use ESP, encrypted with Camellia and sha256
for authentication.
{
laddr fe80::a00:20ff:fe21:4483
raddr fe80::a00:20ff:felf:e346
} ipsec {
encr_algs camellia
encr_auth_algs sha256
}
Example 8 Verifying IPv6 Traffic uses AH, Authenticated with sha384
The following two entries require that all IPv6 traffic to and from the
IPv6 site-local network fec0:abcd::0/32 be authenticated with sha384.
{raddr fec0:abcd::0/32} ipsec { auth_algs sha384 }
Example 9 Key Lengths
# use aes at any key length defined my ipsecalgs(8)
{raddr spiderweb} ipsec {encr_algs aes encr_auth_algs sha256}
# This has the same effect
{raddr spiderweb} ipsec {encr_algs aes(128..256) encr_auth_algs sha256}
# Only use aes with a 192 bit key
{raddr spiderweb} ipsec {encr_algs aes(192) encr_auth_algs sha256}
# use aes with any key length up to 192 bits
# i.e. 192 bits or less
{raddr spiderweb} ipsec {encr_algs aes(..192) encr_auth_algs sha256}
# use aes with any key length of 192 or more
# i.e. 192 bits or more
{raddr spiderweb} ipsec {encr_algs aes(192..) encr_auth_algs sha256}
#use aes with any key from 192 to 256 bits
{raddr spiderweb} ipsec {encr_algs aes(192..256) encr_auth_algs sha256}
#use any algorithm with a key of 192 bits or longer
{raddr spiderweb} ipsec {encr_algs any(192..) encr_auth_algs sha256}
Note that when using IKE, a policy entry that specifies more than a
single key length will generate multiple proposals to its peer. It is
up to the peer to select the proposal that most closely matches its
local IPsec policy.
Example 10 Correct and Incorrect Policy Entries
The following are examples of correctly formed policy entries:
{ raddr that_system rport telnet } ipsec { encr_algs aes
encr_auth_algs sha256 sa shared}
{
raddr that_system
rport telnet
} ipsec {
encr_algs aes
encr_auth_algs sha256
sa shared
}
{ raddr that_system rport telnet } ipsec
{ encr_algs aes encr_auth_algs sha1 sa shared}
{ raddr that_system rport telnet } ipsec
{ encr_algs 3des encr_auth_algs sha256 sa shared} or ipsec
{ encr_algs aes encr_auth_algs sha256 sa shared}
...and the following is an incorrectly formed entry:
{ raddr that_system rport telnet } ipsec
{ encr_algs 3des encr_auth_algs sha1 sa shared}
or ipsec { encr_algs aes encr_auth_algs sha1 sa shared}
In the preceding, incorrect entry, note that the third line begins with
"or ipsec". Such an entry causes ipsecconf to return an error.
Example 11 Allowing Neighbor Discovery to Bypass IPsec
The following two entries require that all IPv6 traffic to and from the
IPv6 site-local network fec0:abcd::0/32 be authenticated with sha256.
The second entry allows neighbor discovery to operate correctly.
{raddr fec0:abcd::0/32} ipsec { auth_algs sha256 }
{raddr fec0:abcd::0/32 ulp ipv6-icmp type 133-137
dir both } pass { }
Example 12 Using "or"
The following entry allows IPsec traffic using the AES or Camellia
algorithms from the remote machine spiderweb. It will also allow unen‐
crypted traffic from spiderweb under certain circumstances:
{raddr spiderweb} ipsec {encr_auth_algs sha256 encr_algs aes}
or ipsec {encr_algs camellia} or pass {}
For outgoing traffic initiated from this system, the first packet will
trigger an ACQUIRE message to be sent from the kernel to the key man‐
agement daemon (in.iked(8) or in.ikev2d(8)).
The ACQUIRE will contain both algorithm combinations and the peer sys‐
tem will pick one that its acceptable to it and IPsec SAs will be
added. The traffic will use those SAs.
For inbound traffic, IPsec protected packets will require an SA on the
receiving system to decrypt the packet. For protocols that support
latching (for example, TCP) the first packet to use an SA will be
checked against the policy after it was decrypted, then the policy will
be latched. For protocols that do not latch (for example, UDP) packets
will always be checked against the inbound policy.
The example above has a third action "pass". For inbound traffic, this
system will accept IPsec packets or unprotected packets from spiderweb.
When this system responds, it will need to make a decision about what
IPsec algorithm it uses, if any. The response will use any matching SA
that's already in the SADB. If the inbound packet was IPsec protected,
there must have been an IKE exchange to generate the SAs. As IPsec SAs
are added in pairs, one inbound and one outbound, there should already
be an SA in place. The outbound packet will be IPsec protected.
Conversely, if there is no SA in place the packet will be sent unpro‐
tected. Its important to understand that packet latching plays an
important role here.
Policy entries that use "pass" as an action are a useful migration tool
to allow systems to make use of IPsec if its available. Rules using
"pass" as an action should be written with care.
Example 13 Configuring a Tunnel to be Backward-Compatible with Solaris
9
The following example is equivalent to "encr_algs aes encr_auth_algs
sha1" in ifconfig(8):
{tunnel ip.tun0 negotiate transport} ipsec
{encr_algs aes encr_auth_algs sha1}
Example 14 Configuring a Tunnel to a VPN client with an Assigned
Address
The following example assumes a distinct "inside" network with its own
topology, such that a client's default route goes "inside".
# Unlike route(8), the default route has to be spelled-out.
{tunnel ip.tun0 negotiate tunnel raddr client-inside/32
laddr 0.0.0.0/0} ipsec {encr_algs aes encr_auth_algs sha256}
Example 15 Transit VPN router between Two Tunnelled Subnets and a Third
The following example specifies a configuration for a VPN router that
routes between two tunnelled subnets and a third subnet that is on-
link. Consider remote-site A, remote-site B, and local site C, each
with a /24 address allocation.
# ip.tun0 between me (C) and remote-site A.
# Cover remote-site A to remote-side B.
{tunnel ip.tun0 negotiate tunnel
raddr A-prefix/24 laddr B-prefix/24} ipsec
{encr_algs aes encr_auth_algs sha256}
# Cover remote-site A traffic to my subnet.
{tunnel ip.tun0 negotiate tunnel
raddr A-prefix/24 laddr C-prefix/24}
ipsec {encr_algs aes encr_auth_algs sha256}
# ip.tun1 between me (C) and remote-site B.
# Cover remote-site B to remote-site A.
{tunnel ip.tun1 negotiate tunnel
raddr B-prefix/24 laddr A-prefix/24} ipsec
{encr_algs camellia encr_auth_algs sha256}
# Cover remote-site B traffic to my subnet.
{tunnel ip.tun1 negotiate tunnel
raddr B-prefix/24 laddr C-prefix/24} ipsec
{encr_algs camellia encr_auth_algs sha256}
Example 16 Using Combined Mode Ciphers
The parameters used are the same as any other encr_algs value. In both
examples, the number in the algorithm token indicates the length of the
Integrity Check Value (ICV). See ipsecalgs(8).
# simple example using GCM in transport mode
{laddr 192.168.99.2 raddr 192.168.99.3} ipsec
{encr_algs aes-gcm sa shared}
# simple example using CCM mode and 128 bit keys
{laddr 192.168.99.100 raddr 192.168.99.200} ipsec
{encr_algs aes-ccm(128) sa shared}
Example 17 Using AES GMAC
The AES GMAC algorithm is a hash algorithm that provides message
authentication. An Integrity Check Vector (ICV) is calculated and
transmitted as part of the authenticated packet.
The AES GMAC algorithm can be used in ESP mode, in which case the
packet data and the ESP header are authenticated. When used with IPsec
ESP, AES GMAC can only be specified as an encryption algorithm, even
though it does not provide any encryption.
# simple example using AES GMAC and 128 bit keys for ESP
{laddr 192.168.99.100 raddr 192.168.99.200} ipsec
{encr_algs aes-none-gmac(128) sa shared}
The above example is analogous to the following invalid example:
{laddr 192.168.99.100 raddr 192.168.99.200} ipsec
{encr_algs null encr_auth_algs aes-gmac(128) sa shared}
When used with ESP, the aes-none-gmac algorithm takes the key length as
an optional argument, the supported key lengths can be displayed using
the ipsecalgs(8) command.
The AES GMAC algorithm can be used in AH mode, in which case the whole
packet, including the IP header, is authenticated. When used with IPsec
AH, AES GMAC can only be specified as an authentication algorithm.
# simple example using AES GMAC and 128 bit keys for AH
{laddr 192.168.99.100 raddr 192.168.99.200} ipsec
{auth_algs aes-gmac128 sa shared}
When used with AH, each key length has its own DOI number, the key
length does not need to be specified as an argument.
Example 18 Specifying Only IKEv2 to be Used for Keying Material
The following example shows policy that specifies that IKEv2 will be
used to negotiate keying material for IPsec SAs and any IKEv1 requests
for IPsec SAs will be ignored.
# Only allow in.ikev2d(8) to respond
{raddr A laddr B} ipsec {encr_algs aes-ccm ike_version 2}
FILES
/var/run/ipsecpolicy.conf
Cache of IPsec policies currently configured for the system, main‐
tained by ipsecconf command. Do not edit this file.
/etc/inet/ipsecinit.conf
File containing IPsec policies to be installed at system restart by
the policy smf(7) service. See NOTES for more information.
/etc/inet/ipsecinit.sample
Sample input file for ipsecconf.
ATTRIBUTES
See attributes(7) for descriptions of the following attributes:
tab() box; cw(2.75i) |cw(2.75i) lw(2.75i) |lw(2.75i) ATTRIBUTE TYPEAT‐
TRIBUTE VALUE _ Availabilitysystem/network _ Interface StabilityCommit‐
ted
SEE ALSO
auths(1), profiles(1), svcprop(1), svcs(1), gethostbyname(3C),
accept(3C), connect(3C), getaddrinfo(3C), socket(3C), gethostby‐
name(3C), getnetbyname(3C), getprotobyname(3C), getservbyname(3C),
ipsecah(4P), ipsecesp(4P), pf_key(4P), ike.config(5), nsswitch.conf(5),
prof_attr(5), user_attr(5), attributes(7), rbac(7), smf(7), ifcon‐
fig(8), in.iked(8), init(8), ipsecalgs(8), ipseckey(8), netcfg(8),
svcadm(8), svccfg(8)
Glenn, R. and Kent, S. RFC 2410, The NULL Encryption Algorithm and Its
Use With IPsec. The Internet Society. 1998.
https://tools.ietf.org/html/rfc2410
Kent, S. and Atkinson, R. RFC 2402, IP Authentication Header. The
Internet Society. 1998.
https://tools.ietf.org/html/rfc2402
Kent, S. and Atkinson, R. RFC 2406, IP Encapsulating Security Payload
(ESP). The Internet Society. 1998.
https://tools.ietf.org/html/rfc2406
Madsen, C. and Glenn, R. RFC 2404, The Use of HMAC-SHA-1-96 within ESP
and AH. The Internet Society. 1998.
https://tools.ietf.org/html/rfc2404
Madsen, C. and Doraswamy, N. RFC 2405, The ESP DES-CBC Cipher Algorithm
With Explicit IV. The Internet Society. 1998.
https://tools.ietf.org/html/rfc2405
Pereira, R. and Adams, R. RFC 2451, The ESP CBC-Mode Cipher Algorithms.
The Internet Society. 1998.
https://tools.ietf.org/html/rfc2451
Frankel, S. and Kelly, R. Glenn, RFC 3602, The AES Cipher Algorithm and
Its Use With IPsec. The Internet Society. 2003.
https://tools.ietf.org/html/rfc3602
Kelly, S. and Frankel, S. RFC 4868, Using HMAC-SHA-256, HMAC-SHA-384,
and HMAC-SHA-512 with IPsec. The Internet Society. 2007.
https://tools.ietf.org/html/rfc4868
Kato, A., Moriai, S., and Kanda, M. RFC 4312, The Camellia Cipher Algo‐
rithm and Its Use With IPsec. The Internet Society. 2005.
https://tools.ietf.org/html/rfc4312
McGrew, D., and Viega, J. RFC 4543, The Use of Galois Message Authenti‐
cation Code (GMAC) in IPsec ESP and AH. The Internet Society. 2006.
https://tools.ietf.org/html/rfc4543
Frankel, S. and Herbert, H. RFC 3566, The AES-XCBC-MAC-96 Algorithm and
Its Use With IPsec. The Internet Society. 2003.
https://tools.ietf.org/html/rfc3566
DIAGNOSTICS
Bad "string" on line N.
Duplicate "string" on line N.
string refers to one of the names in pattern or properties. A Bad
string indicates that an argument is malformed; a Duplicate string
indicates that there are multiple arguments of a similar type, for
example, multiple Source Address arguments.
Interface name already selected
Dual use of -i name and name,index for an interface.
Error before or at line N.
Indicates parsing error before or at line N.
Non-existent index
Reported when the index for delete is not a valid one.
spd_msg return: File exists
Reported when there is already a policy entry that matches the
traffic of this new entry.
NOTES
IPsec manual keys are managed by the service management facility,
smf(7). The services listed below manage the components of IPsec. These
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)
The manual-key service is delivered disabled. The system administrator
must create manual IPsec Security Associations (SAs), as described in
ipseckey(8), before enabling that service.
The policy service is delivered enabled, but without a configuration
file, so that, as a starting condition, packets are not protected by
IPsec. After you create the configuration file
/etc/inet/ipsecinit.conf, as described in this man page, and refresh
the service (svcadm refresh, see below), the policy contained in the
configuration file is applied. If there is an error in this file, the
service enters maintenance mode.
Services that are delivered disabled are delivered that way because the
system administrator must create configuration files for those services
before enabling them. See ike.config(5) for the ike service.
See ipsecalgs(8) for the ipsecalgs service.
The correct administrative procedure is to create the configuration
file for each service, then enable each service using svcadm(8).
If the configuration needs to be changed, edit the configuration file
then refresh the service, as follows:
example# svcadm refresh policy
The smf(7) framework will record any errors in the service-specific log
file. Use any of the following commands to examine the logfile prop‐
erty:
example# svcs -l policy
example# svcprop policy
example# svccfg -s policy listprop
The following property is defined for the policy service:
config/config_file
This property can be modified using svccfg(8) by users who have been
assigned the following authorization:
solaris.smf.value.ipsec
See auths(1), user_attr(5), rbac(7).
The service needs to be refreshed using svcadm(8) before the new prop‐
erty is effective. General non-modifiable properties can be viewed with
the svcprop(1) command.
# svccfg -s ipsec/policy setprop config/config_file = /new/config_file
# svcadm refresh policy
Administrative actions on this service, such as enabling, disabling,
refreshing, and requesting restart can be performed using svcadm(8). A
user who has been assigned the authorization shown below can perform
these actions:
solaris.smf.manage.ipsec
The service's status can be queried using the svcs(1) command.
The ipsecconf command is designed to be managed by the policy smf(7)
service. While the ipsecconf command can be run from the command line,
this is discouraged. If the ipsecconf command is to be run from the
command line, the policy smf(7) service should be disabled first. See
svcadm(8).
Oracle Solaris 11.4 3 Nov 2021 ipsecconf(8)