ipsec man page on DigitalUNIX

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

ip(7)									 ip(7)

NAME
       ipsec - Internet Protocol Security Architecture

DESCRIPTION
       Internet	 Protocol  Security  (IPsec)  is  a security framework that is
       designed to provide  interoperable,  high  quality,  cryptographically-
       based security for Internet Protocol Version 4 (IPv4) and Internet Pro‐
       tocol Version 6 (IPv6).	The set of security services offered  includes
       the  following:	Only  networks, systems, and applications you want are
       authorized to access your host, the data	 stored	 in  it,  the  network
       behind a security gateway, or the bandwidth on that network.  Any modi‐
       fication of an individual IP packet is automatically detected,  regard‐
       less of the ordering of the IP packet in a stream of traffic.  Messages
       from a given source are verified to come from that  source.   Duplicate
       datagrams that arrive within a given window are detected.  Application-
       level data is protected from unauthorized  disclosure  through  encryp‐
       tion.  Data is protected from unauthorized disclosure by encrypting the
       source and destination addresses, message length, and frequency of com‐
       munication.

       These services are provided at the Internet Protocol (IP) layer, offer‐
       ing protection for both IP and upper layer protocols or applications.

       For information on configuring IPsec, see the  Network  Administration:
       Connections manual.

   Secure Connections
       The  behavior  of IPsec is determined by the secure connections defined
       on the system.  Each secure connection describes a bi-directional  con‐
       nection	between	 two hosts or subnets.	You define a secure connection
       by providing a name and a rule for the connection.  Each rule  contains
       the  following: Identifies which IP packets match the rule.  The selec‐
       tor specifies values for the local IP address, remote IP address, upper
       layer  protocol,	 and upper layer ports of the matching packets, either
       all or a specific value.	 You can also use  subnets  or	ranges	of  IP
       addresses  for  the  local and remote values.  Describes how IP packets
       matching the selector are to be processed. The action may be to discard
       (drop)  the  packet, to bypass IPsec processing (allow the packet in or
       out with no security processing), or  to	 apply	IPsec  processing.   A
       packet  that  does  not match any policy rules is discarded.  Lists the
       set of IPsec protocols to be applied, the authentication and encryption
       algorithms to be used, and associated parameters (the keys).  With man‐
       ual keying, only one proposal (one set of protocols) is	allowed.   You
       use proposals for rules that apply IPsec processing only.

       You use the SysMan IPsec utility to define secure connections that com‐
       pose the overall IPsec configuration.  The IPsec daemon (ipsecd)	 reads
       the  configuration information when it starts and places the rules into
       the kernel.

       For each incoming and outgoing packet, the kernel  scans	 the  Security
       Policy Data base (SPD) sequentially to find a rule that matches.	 Thus,
       connection rules are usually ordered from most specific to  least  spe‐
       cific.

       You  can	 also  use the SysMan IPsec utility to enable or disable IPsec
       processing.

       On a system in which no secure connections are defined, each  transmit‐
       ted  packet is unprotected. Once transmitted, the IP header and payload
       could be intercepted, changed, and sent to the destination; the	desti‐
       nation would not know that the data had been altered.

   Security Protocols
       When a secure connection is defined, it can be protected by the follow‐
       ing traffic security protocols: Authentication Header (AH)

	      Provides data origin authentication,  connectionless  integrity,
	      and  anti-replay protection services to a datagram. This enables
	      a receiver to verify both the identity of the  sender  and  that
	      the  data	 has not been altered.	Encapsulating Security Payload
	      (ESP)

	      Provides all the protections of the AH  protocol	when  you  use
	      authentication,  but  also  provides confidentiality through the
	      use of encryption.

       The AH protocol can operate in either transport mode or tunnel mode.

       In transport mode, the original packet's IP header is the IP header for
       the  resulting  packet (AH header and payload).	This is typically used
       in in host-to-host communications.   In	tunnel	mode,  the  packet  is
       appended	 to  a	new  IP header (tunnel header) and AH header.  This is
       typically used in secure gateways and VPN configurations.

       The ESP protocol can also operate in either transport  mode  or	tunnel
       mode.

       In  transport  mode,  the  packet's  IP header is the IP header for the
       resulting encrypted packet (payload and ESP trailer).   This  is	 typi‐
       cally  used  in	in  host-to-host  communications.  In tunnel mode, the
       encrypted packet (original IP header,  payload,	and  ESP  trailer)  is
       appended to a new IP header (tunnel header).  This is typically used in
       secure gateways and VPN configurations.

       The AH and ESP protocols	 support  two  Hashed  Message	Authentication
       Codes  (HMACs):	Message	 Digest 5 (MD5-96) and Secure Hash Algorithm 1
       (SHA1-96) authentication algorithms. The	 ESP  protocol	supports  both
       Data  Encryption	 Standard (DES) and triple-DES (3DES) encryption algo‐
       rithms.

       Together with the use of cryptographic key  management  procedures  and
       protocols,  you	can  employ these protocols in any context and manner.
       How you employ them depends on the security and system requirements  of
       users, applications, and your particular organization or site.

   Security Associations
       When  you  define  a secure connection, you provide information that is
       used to create and establish an entity called  a	 Security  Association
       (SA).   An  SA is an instantiation of the security policy, and contains
       the following information: Security Parameter Index  (SPI)  Authentica‐
       tion  algorithm	(AH or ESP) Encryption algorithm (ESP only) Encryption
       and authentication keys Encryption context SA lifetime Exact  selectors
       that are being matched

       This  information  is  used to match and process packets that are to be
       protected.  A single secure connection that specifies one IPsec	proto‐
       col creates both an inbound and outbound SA.

       The  SPI, authentication algorithm, and destination IP address together
       identify the SA. If the secure connection specifies  both  AH  and  ESP
       protocols, an inbound and outbound SA is created for each protocol.

       You can use the netstat command to display the SAs.

   IPsec Daemon
       The  ipsecd  daemon controls the operation of the IP security protocols
       in the system.  It combines the function of an IPsec policy manager and
       Internet Key Exchange (IKE) daemon.

       When  started,  ipsecd  reads  and parses the specified Security Policy
       Database (SPD) file. The daemon transfers the  information  needed  for
       enforcing the policy into the IPsec kernel packet processing engine.

       The  daemon  manages all requests to create security associations (SAs)
       needed to communicate securely with other IPsec systems.	  It  receives
       Internet Key Exchange (IKE) requests from other systems, validates that
       they match local policy, and generates the  cryptographic  keys	needed
       for the the SAs.	 The daemon initiates IKE exchanges with other systems
       in response to requests from the kernel packet processing engine.   The
       kernel and the daemon communicate through the /dev/ipsec_engine pseudo-
       device.	By default, the daemon listens on UDP port 500 for IKE traffic
       with other systems.

       When  IPsec is enabled on the system, the default action is to drop all
       IP packets into and out of the system. The ipsecd daemon must  be  run‐
       ning  to instantiate a policy that allows packets to flow.  If the dae‐
       mon is not started or is killed, all network traffic will  be  blocked.
       The  daemon  is	started	 automatically at system boot time if IPsec is
       enabled.

       See ipsecd(8) for more information.

SEE ALSO
       Commands:   ipsec_certmake(8),	ipsec_certview(8),   ipsec_convert(8),
       ipsec_keypaircheck(8), ipsec_keytool(8), ipsec_mgr(8), ipsecd(8)

       Network Administration: Connections

       Security	 Architecture  for  the	 Internet Protocol, RFC 2401 (November
       1998)

       IP Authentication Header, RFC 2402 (November 1998)

       The Use of HMAC-MD5-96 within ESP and AH, RFC 2403 (November 1998)

       The Use of HMAC-SHA-1-96 within ESP and AH, RFC 2404 (November 1998)

       The ESP DES-CBC Cipher Algorithm With Explicit IV, RFC  2405  (November
       1998)

       IP Encapsulating Security Payload (ESP), RFC 2406 (November 1998)

       The  Internet IP Security Domain of Interpretation for ISAKMP, RFC 2407
       (November 1998)

       Internet Security Association and Key Management Protocol (ISAKMP), RFC
       2408 (November 1998)

       The Internet Key Exchange (IKE), RFC 2409 (November 1998)

       The  NULL Encryption Algorithm and Its Use With IPsec, RFC 2401RFC 2410
       (November 1998)

       IP Security Document Roadmap, RFC 2411 (November 1998)

       The OAKLEY Key Determination Protocol, RFC 2412 (November 1998)

									 ip(7)
[top]

List of man pages available for DigitalUNIX

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