*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->Tru64 Unix man pages -> ipsec (7)              



NAME    [Toc]    [Back]

       ipsec - Internet Protocol Security Architecture

DESCRIPTION    [Toc]    [Back]

       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 Protocol 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 modification of an individual IP packet
       is automatically detected, regardless 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 encryption.  Data is protected
       from unauthorized disclosure by encrypting the source  and
       destination  addresses,  message  length, and frequency of

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

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

   Secure Connections    [Toc]    [Back]
       The  behavior of IPsec is determined by the secure connections
 defined  on  the  system.   Each  secure  connection
       describes a bi-directional connection 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  selector  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 manual 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 compose 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 specific.

       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  transmitted packet is unprotected. Once transmitted,
       the IP header and payload could be  intercepted,  changed,
       and  sent  to  the  destination; the destination would not
       know that the data had been altered.

   Security Protocols    [Toc]    [Back]
       When a secure connection is defined, it can  be  protected
       by  the  following 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

              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 typically 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  algorithms.

       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    [Toc]    [Back]
       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) Authentication 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 protocol 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    [Toc]    [Back]
       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)

       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 running to instantiate a policy that
       allows  packets  to flow.  If the daemon 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    [Toc]    [Back]

       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

       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

       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

[ Back ]
 Similar pages
Name OS Title
sia_become_user Tru64 su routine for SIA (Security Integration Architecture)
sialog Tru64 SIA (Security Integration Architecture) log file
siainit Tru64 SIA (Security Integration Architecture) initialization command
sia_ses_suauthent Tru64 SIA session routines (Security Integration Architecture)
siad_ses_release Tru64 SIA session routines (Security Integration Architecture)
siad_endgrent Tru64 group routines for SIA (Security Integration Architecture)
siad_endpwent Tru64 password routines for SIA (Security Integration Architecture)
siad_getgrent Tru64 group routines for SIA (Security Integration Architecture)
siad_getgrgid Tru64 group routines for SIA (Security Integration Architecture)
sia_ses_release Tru64 SIA session routines (Security Integration Architecture)
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service