ipsec man page on SmartOS

Man page or keyword search:  
man Server   16655 pages
apropos Keyword Search (all sections)
Output format
SmartOS logo
[printable version]

IPSEC(7P)							     IPSEC(7P)

NAME
       ipsec - Internet Protocol Security Architecture

DESCRIPTION
       The  IP	Security Architecture (IPsec) provides protection for IP data‐
       grams. The protection can include confidentiality, strong integrity  of
       the  data,  partial  sequence  integrity	 (replay protection), and data
       authentication.	IPsec is performed inside the IP  processing,  and  it
       can  be	applied	 with or without the knowledge of an Internet applica‐
       tion.

       IPsec applies to both IPv4 and IPv6. See ip(7P) and ip6(7P).

   Protection Mechanisms
       IPsec provides two mechanisms for protecting data.  The	Authentication
       Header  (AH)  provides  strong  integrity,  replay protection, and data
       authentication. AH protects as much of the IP datagram as it  can.   AH
       cannot  protect	fields that change nondeterministically between sender
       and receiver.

       The Encapsulating Security Payload (ESP) provides confidentiality  over
       what  it	 encapsulates,	as  well as the services that AH provides, but
       only over that which it encapsulates. ESP's authentication services are
       optional,  which allow ESP and AH to be used together on the same data‐
       gram without redundancy.

       Authentication and encryption algorithms are used for IPsec.  Authenti‐
       cation  algorithms produce an integrity checksum value or "digest"based
       on the data and a key. Encryption algorithms operate on data  in	 units
       of a "block size".

   NAT Traversal
       IPsec's ESP can also encapsulate itself in UDP if IKE (see in.iked(1M))
       discovers a Network Address Translator (NAT) between two	 communicating
       endpoints.

       A  UDP socket can be specified as a NAT-Traversal endpoint. See udp(7P)
       for details.

   Security Associations
       AH and ESP use Security Associations (SA). SA's are entities that spec‐
       ify  security  properties  from	one host to another. Two communicating
       machines require two SAs (at a minimum) to communicate  securely.  How‐
       ever, communicating machines that use multicast can share the same mul‐
       ticast SA. SAs are managed through the pf_key(7P) interface. For	 IPv4,
       automatic  SA management is available through the Internet Key Exchange
       (IKE), as implemented  by  in.iked(1M).	A  command-line	 front-end  is
       available  by  means  of	 ipseckey(1M).	An IPsec SA is identified by a
       tuple of <AH or ESP, destination IP address,  and  SPI>.	 The  Security
       Parameters Index (SPI) is an arbitrary 32-bit value that is transmitted
       on the wire with an AH or ESP packet. See ipsecah(7P)  or  ipsecesp(7P)
       for an explanation about where the SPI falls in a protected packet.

   Protection Policy and Enforcement Mechanisms
       Mechanism  and  policy  are  separate. The policy for applying IPsec is
       enforced on a system-wide or per-socket level. Configuring  system-wide
       policy  and  per-tunnel policy (see Transport Mode and Tunnel Mode sec‐
       tions) is done via the ipsecconf(1M)  command.  Configuring  per-socket
       policy is discussed later in this section.

       System-wide IPsec policy is applied to incoming and outgoing datagrams.
       Some additional rules can be applied to outgoing datagrams  because  of
       the  additional	data  known  by	 the  system. Inbound datagrams can be
       accepted or dropped. The decision to drop or accept an inbound datagram
       is  based on several criteria which sometimes overlap or conflict. Con‐
       flict resolution is resolved by which rule is parsed  first,  with  one
       exception:  if  a  policy  entry	 states that traffic should bypass all
       other policy, it is automatically be accepted. Outbound	datagrams  are
       sent  with  or without protection. Protection may (or may not) indicate
       specific algorithms. If policy normally would protect  a	 datagram,  it
       can  be	bypassed  either  by  an exception in system-wide policy or by
       requesting a bypass in per-socket policy.

       Intra-machine traffic policies are enforced, but actual security mecha‐
       nisms are not applied. Instead, the outbound policy on an intra-machine
       packet translates into an inbound packet with those mechanisms applied.

       IPsec policy is enforced in the ip(7P) driver. Several ndd tunables for
       /dev/ip affect policy enforcement, including:

       icmp_accept_clear_messages
				     If	 equal	to 1 (the default), allow cer‐
				     tain cleartext icmp  messages  to	bypass
				     policy.	For    ICMP    echo   requests
				     ("ping"messages),	protect	 the  response
				     like  the	request.  If  zero, treat icmp
				     messages like other IP traffic.

       igmp_accept_clear_messages
				     If 1, allow inbound cleartext  IGMP  mes‐
				     sages to bypass IPsec policy.

       pim_accept_clear_messages
				     If	 1,  allow  inbound cleartext PIM mes‐
				     sages to bypass IPsec policy.

       ipsec_policy_log_interval
				     IPsec logs policy failures and errors  to
				     /var/adm/messages. To prevent syslog from
				     being overloaded, the IPsec  kernel  mod‐
				     ules  limit  the rate at which errors can
				     be logged. You can	 query/set  ipsec_pol‐
				     icy_log_interval using ndd(1M). The value
				     is in milliseconds. Only one message  can
				     be logged per interval.

   Transport Mode and Tunnel Mode
       If  IPsec is used on a tunnel, Tunnel Mode IPsec can be used to protect
       distinct flows within a tunnel or to cause packets that	do  not	 match
       per-tunnel policy to drop. System-wide policy is always Transport Mode.
       A tunnel can use Transport Mode IPsec or Tunnel Mode IPsec.

   Per-Socket Policy
       The IP_SEC_OPT or IPV6_SEC_OPT socket option is used to set  per-socket
       IPsec policy.  The structure used for an IP_SEC_OPT request is:

	 typedef struct ipsec_req {
	     uint_t	 ipsr_ah_req;		/* AH request */
	     uint_t	 ipsr_esp_req;		/* ESP request */
	     uint_t	 ipsr_self_encap_req;	/* Self-Encap request */
	     uint8_t	 ipsr_auth_alg;		/* Auth algs for AH */
	     uint8_t	 ipsr_esp_alg;		/* Encr algs for ESP */
	     uint8_t	 ipsr_esp_auth_alg;	/* Auth algs for ESP */
	 } ipsec_req_t;

       The IPsec request has fields for both AH and ESP. Algorithms may or may
       not be specified. The actual request for AH or ESP  services  can  take
       one of the following values:

       IPSEC_PREF_NEVER
			      Bypass   all  policy.  Only  the	superuser  may
			      request this service.

       IPSEC_PREF_REQUIRED
			      Regardless of other policy, require the  use  of
			      the  IPsec  service.

       The  following  value  can  be logically ORed to an IPSEC_PREF_REQUIRED
       value:

       IPSEC_PREF_UNIQUE
			    Regardless of other policy, enforce	 a  unique  SA
			    for traffic originating from this socket.

       In  the	event  IP options not normally encapsulated by ESP need to be,
       the ipsec_self_encap_req is used to add an additional IP header outside
       the original one. Algorithm values from <net/pfkeyv2.h> are as follows:

       SADB_AALG_MD5HMAC
			       Uses  the  MD5-HMAC  (RFC  2403)	 algorithm for
			       authentication.

       SADB_AALG_SHA1HMAC
			       Uses the SHA1-HMAC  (RFC	 2404)	algorithm  for
			       authentication.

       SADB_EALG_DESCBC
			       Uses  the  DES (RFC 2405) algorithm for encryp‐
			       tion.

       SADB_EALG_3DESCBC
			       Uses the Triple	DES   (RFC  2451)    algorithm
			       for encryption.

       SADB_EALG_BLOWFISH
			       Uses  the  Blowfish  (RFC  2451)	 algorithm for
			       encryption.

       SADB_EALG_AES
			       Uses  the  Advanced Encryption Standard	 algo‐
			       rithm for encryption.

       SADB_AALG_SHA256HMAC
       SADB_AALG_SHA384HMAC
       SADB_AALG_SHA512HMAC
			       Uses  the  SHA2	hash algorithms with HMAC (RFC
			       4868)for authentication.

       An application should use either the getsockopt(3SOCKET)	 or  the  set‐
       sockopt(3SOCKET) call to manipulate IPsec requests.  For example:

	 #include <sys/socket.h>
	 #include <netinet/in.h>
	 #include <net/pfkeyv2.h>   /* For SADB_*ALG_* */
	 /* .... socket setup skipped */
	 rc = setsockopt(s, IPPROTO_IP, IP_SEC_OPT,
	    (const char *)&ipsec_req, sizeof (ipsec_req_t));

SECURITY
       While  IPsec  is an effective tool in securing network traffic, it will
       not make security problems disappear. Security issues beyond the mecha‐
       nisms  that  IPsec  offers  may	be  discussed in similar "Security" or
       "Security Consideration" sections within	 individual  reference	manual
       pages.

       While a non-root user cannot bypass IPsec, a non-root user can set pol‐
       icy to be different from the system-wide policy. For  ways  to  prevent
       this, consult the ndd(1M) variables in /dev/ip.

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

       ┌────────────────────┬─────────────────┐
       │  ATTRIBUTE TYPE    │ ATTRIBUTE VALUE │
       ├────────────────────┼─────────────────┤
       │Interface Stability │ Committed	      │
       └────────────────────┴─────────────────┘

SEE ALSO
       in.iked(1M), ipsecconf(1M), ipseckey(1M), ndd(1M), getsockopt(3SOCKET),
       setsockopt(3SOCKET),   attributes(5),   inet(7P),   ip(7P),    ip6(7P),
       ipsecah(7P), ipsecesp(7P), pf_key(7P), udp(7P)

       Kent,  S.,  and	Atkinson,  R., RFC 2401, Security Architecture for the
       Internet Protocol, The Internet Society, 1998.

       Kent, S. and Atkinson, R., RFC 2406, IP Encapsulating Security  Payload
       (ESP), The Internet Society, 1998.

       Madson,	C.,  and Doraswamy, N., RFC 2405, The ESP DES-CBC Cipher Algo‐
       rithm with Explicit IV, The Internet Society, 1998.

       Madsen, C. and Glenn, R., RFC 2403, The Use of HMAC-MD5-96  within  ESP
       and AH, The Internet Society, 1998.

       Madsen, C. and Glenn, R., RFC 2404, The Use of HMAC-SHA-1-96 within ESP
       and AH, The Internet Society, 1998.

       Pereira, R. and Adams, R., RFC 2451,  The  ESP  CBC-Mode	 Cipher	 Algo‐
       rithms, The Internet Society, 1998.

       Kelly,  S. and Frankel, S., RFC 4868, Using HMAC-SHA-256, HMAC-SHA-384,
       and HMAC-SHA-512 with IPsec, 2007.

       Huttunen, A., Swander, B., Volpe, V., DiBurro, L.,  Stenberg,  M.,  RFC
       3948,  UDP  Encapsulation  of  IPsec ESP Packets, The Internet Society,
       2005.

				 Sep 25, 2009			     IPSEC(7P)
[top]

List of man pages available for SmartOS

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net