Unix/Linux Go Back    

OpenSolaris 2009.06 - man page for ipsec (opensolaris section 7p)

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:   man
Select Man Page Set:       apropos Keyword Search (sections above)

ipsec(7P)				    Protocols					ipsec(7P)

       ipsec - Internet Protocol Security Architecture

       The  IP Security Architecture (IPsec) provides protection for IP datagrams. 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 application.

       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 encapsu-
       lates, 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 datagram without redundancy.

       Authentication and encryption algorithms are used  for  IPsec.  Authentication  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  Net-
       work 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 specify security proper-
       ties from one host to another. Two communicating machines require two SAs (at  a  minimum)
       to  communicate securely. However, communicating machines that use multicast can share the
       same multicast 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 Trans-
       port Mode and Tunnel Mode sections) 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 pol-
       icy 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  mechanisms  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 certain 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 messages to bypass  IPsec

       pim_accept_clear_messages     If  1,  allow inbound cleartext PIM messages to bypass IPsec

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

   Transport Mode and Tunnel Mode
       If  IPsec  is used on a tunnel (see tun(7M)) Tunnel Mode IPsec can be used to protect dis-
       tinct 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 originat-
			    ing 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 encryption.

       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  algorithm for encryption.

       An  application	should use either the getsockopt(3SOCKET) or the setsockopt(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));

       While IPsec is an effective tool in securing network traffic, it will  not  make  security
       problems  disappear.  Security  issues beyond the mechanisms that IPsec offers may be dis-
       cussed in similar "Security" or "Security Consideration" sections within individual refer-
       ence manual pages.

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

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

       |      ATTRIBUTE TYPE	     |	    ATTRIBUTE VALUE	   |
       |Interface Stability	     |Evolving			   |

       in.iked(1M),   ipsecconf(1M),   ipseckey(1M),   ndd(1M),   getsockopt(3SOCKET),	 setsock-
       opt(3SOCKET),  attributes(5),  tun(7M),	inet(7P),  ip(7P),  ip6(7P),  ipsecah(7P),  ipse-
       cesp(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 Algorithm 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 Inter-
       net Society, 1998.

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

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

SunOS 5.11				   28 Aug 2007					ipsec(7P)
Unix & Linux Commands & Man Pages : 2000 - 2015 Unix and Linux Forums

All times are GMT -4. The time now is 12:02 PM.