ipsec by ashrafp

VIEWS: 36 PAGES: 21

									                          Available at www.mindstien.net



                          IP SECURITY

INTRODUCTION
      The need for Internet Protocol (IP)-based network security is already
evident. In today's massively interconnected business world of the Internet,
intranets, branch offices, and remote access, sensitive information
constantly crosses the networks. The challenge for network administrators
and other information service professionals is to ensure that this traffic is:

•    Safe from data modification while en route.
•    Safe from interception, viewing, or copying.
•    Safe from being accessed by unauthenticated parties.
These issues are known as data integrity, confidentiality, and
authentication. In addition, replay protection prevents acceptance of a
packet that has been captured and later resent.

For these reasons, Internet Protocol security, or IPSec, was designed by
the Internet Engineering Task Force (IETF). IPSec supports network-level
authentication, data integrity and encryption. IPSec integrates with the
inherent security of the Windows operating system to provide the ideal
platform for safeguarding intranet and Internet communications.

IP security uses industry-standard encryption algorithms and a
comprehensive security management approach to provide security for all
TCP/IP communications on both sides of an organization's firewall. The
result is a Windows , end-to-end security strategy that defends against both
external and internal attacks.

IP security is deployed below the transport layer, sparing network
managers (and software vendors) the difficulty and expense of trying to
deploy and coordinate security one application at a time. By simply
deploying Windows IP security, network managers provide a strong layer
                                                      Available at www.mindstien.net


of protection for the entire network, with applications automatically
inheriting from IPSec-enabled servers and clients.

How IP Security Prevents Network Attacks
Without security measures the data or the network itself. Table presents
some common security risks found in today's networks.

Table :- Types of Network Attacks




Attack type                         Description                                        How IPSec prevents



Eavesdropping (also                 Monitoring of cleartext or unencrypted packets.    Data is encrypted before transmission, preventing
called sniffing,                    Encapsulated packets can also be monitored if      access even if the packet is monitored or intercepted.
snooping)                           attacker has access to key and packets are         Only the intended receiving party can decrypt the
                                    unencrypted.                                       data.



Data modification                   Alteration and transmission of modified packets.   Data hashing attaches a digital signature to each
                                                                                       packet, which is checked by the receiving computer to
                                                                                       detect modification.



Identity spoofing                   Use of constructed or captured packets to          Kerberos v5, MS-CHAP, and other authentication
                                    falsely assume the identity of a valid address.    methods secure Windows 2000 – based computers.



Denial-of-service                   Preventing access of network by valid users. An    Authentication methods limit access from
                                    example is to flood the network with packet        unauthorized users.
                                    traffic.



Man-in-the-middle                   Diversion of IP packets to an unintended third     Anti-replay mechanisms, data hashing.
                                    party, to be monitored and possibly altered.



Known-key                           Access or construction of a security key, used     Under Windows 2000, public keys are periodically
                                    to decrypt or modify data. A compromised key       refreshed, reducing the possibility that a captured key
                                    might be used to create additional keys.           can be used to gain access to secure information.



Application layer                   Mainly directed at application servers, this       Since IPSec is implemented at the network layer,
attack                              attack is used to cause a fault in a network's     packets that do not meet the security filters at this
                                    operating system or applications or to introduce   level are never filtered upwards, protecting
                                    viruses into the network.                          applications and operating systems.
                          Available at www.mindstien.net




Figure. Overview: the IPSec Process




     An application on Computer A generates outbound packets to send
to Computer B across the network.

1.      IPSec checks IP Security Group Policy settings on Computer A to
     determine the computer's active IP Security policy. The default policies
     allow a computer to demand secure communication, to request secure
                           Available at www.mindstien.net


     communication but proceed unsecurely if necessary, or to never
     request IP security.
2.     Computer A begins security negotiations with Computer B. The two
     computers exchange public keys and establish a shared, secret key
     that is created independently at both ends without being transmitted
     across the network.
3.      The IPSec driver on Computer A signs the outgoing packets for
     integrity, and optionally encrypts them for confidentially. It transmits the
     packets to Computer B.
4.      Routers and servers along the network path from Computer A to
     Computer B do not require IPSec. They simply pass along the packets
     in the usual manner.
5.     The IPSec driver on Computer B checks the packets for integrity and
     decrypts their content if necessary. It then transfers the packets to the
     receiving application.

2.GOALS/OBJECTIVES/REQURMENTS
         IPsec is designed to provide interoperable, high quality,
cryptographically-based security for IPv4 and IPv6. The set of security
services offered includes access control, connectionless integrity, data
origin authentication, protection against replays form of partial sequence
integrity), confidentiality (encryption), and limited traffic flow confidentiality.
These services are provided at the IP layer, offering protection for IP and/or
upper
 layer protocols.

         These objectives are met through the use of two traffic security
protocols, the Authentication Header (AH) and the Encapsulating Security
Payload (ESP), and through the use of cryptographic key management
procedures and protocols. The set of IPsec protocols employed in any
context, and the ways in which they are employed, will be determined by
the security and system requirements of users, applications, and/or
sites/organizations.

          When these mechanisms are correctly implemented and
deployed, they   ought not to adversely affect users, hosts, and other
Internet components that do not employ these security mechanisms for
                         Available at www.mindstien.net


protection of their traffic. These mechanisms also are designed to be
algorithm-independent. This modularity permits selection of different sets
of algorithms without affecting the other parts of the implementation. For
example, different user communities may select different sets of algorithms
(creating cliques) if required.

         A standard set of default algorithms is specified to facilitate
interoperability in the global Internet. The use of these algorithms, in
conjunction with IPsec traffic protection and key management protocols, is
intended to permit system and application developers to deploy high
quality, Internet layer, cryptographic security technology.

What IPsec Does
        IPsec provides security services at the IP layer by enabling a
system to select required security protocols, determine the algorithm(s) to
use for the service(s), and put in place any cryptographic keys required to
provide the requested services. IPsec can be used to protect one or more
"paths" between a pair of hosts, between a pair of security gateways, or
between a security gateway and a host. (The term "security gateway" is
used throughout the IPsec documents to refer to an intermediate system
that implements IPsec protocols. For example, a router or a firewall
implementing IPsec is a security gateway.)

        The set of security services that IPsec can provide includes access
control,connectionless integrity, data origin authentication, rejection of
replayed packets (a form of partial sequence integrity), confidentiality
(encryption), and limited traffic flow confidentiality. Because these
services are provided at the IP layer, they can be used by any higher layer
protocol, e.g., TCP, UDP, ICMP, BGP, etc.

Where IPsec May Be Implemented
       There are several ways in which IPsec may be implemented in a
host or in conjunction with a router or firewall (to create a security
gateway). Several common examples are provided below:

     a. Integration of IPsec into the native IP implementation.       This
requires access to the IP source code and is applicable to
both hosts and security gateways.
                                                      Available at www.mindstien.net


     b. "Bump-in-the-stack" (BITS) implementations, where IPsec is
implemented "underneath" an existing implementation of an IP protocol
stack, between the native IP and the local network drivers. Source code
access for the IP stack is not required in this context, making this
implementation approach appropriate for use with legacy systems. This
approach, when it is adopted, is usually employed in hosts.

     c. The use of an outboard crypto processor is a common design
feature of network security systems used by the military, and of some
commercial systems as well. It is sometimes referred to as a "Bump-in-the-
wire" (BITW) implementation. Such implementations may be designed to
serve either a host or a gateway (or both). Usually the BITW device is IP
addressable. When supporting a single host, it may be quite analogous to
a BITS implementation, but in supporting a router or firewall, it must
operate like a security gateway.


3.AUTHENTICATION HEADER
         The IP Authentication Header (AH) is used to provide
connectionless integrity and data origin authentication for IP datagrams
(hereafter referred to as just "authentication"), and to provide protection
against replays. This latter, optional service may be selected, by the
receiver, when Security Association is established. (Although the default
calls for the sender to increment the Sequence Number used for anti-
replay, the service is effective only if the receiver checks the Sequence
Number.) AH provides authentication for as much of the IP header as
possible, as well as for upper level protocol data. However, some IP
header fields may change in transit and the value of these fields, when the
packet arrives at the receiver, may not be predictable by the sender. The
values of such fields cannot
be protected by AH. Thus the protection provided to the IP header by AH
is somewhat piecemeal.

3.1 Authentication Header Format
       The protocol header (IPv4, IPv6, or Extension)immediately
preceding the AH header will contain the value 51 in its Protocol (IPv4) or
Next Header (IPv6, Extension) field [STD-2].
 0           1            2            3
 01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Payload Len |        RESERVED            |
                                                         Available at www.mindstien.net

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Security Parameters Index (SPI)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Sequence Number Field               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                       |
+          Authentication Data (variable)         |
|                                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The following subsections define the fields that comprise the A format.


3.1.1 Next Header
        The Next Header is an 8-bit field that identifies the type of the next
payload after the Authentication Header. The value of this field is chosen
from the set of IP Protocol Numbers defined the most recent "Assigned
Numbers" [STD-2] RFC from theInternet Assigned Numbers Authority
(IANA).

3.1.2 Payload Length
       This 8-bit field specifies the length of AH in 32-bit words (4-byte
units), minus "2". (All IPv6 extension headers, as per RFC 1883, encode
the "Hdr Ext Len" field by first subtracting 1 (64-bit word) from the header
length (measured in 64-bit words). AH is an IPv6 extension header.
However, since its length is measured in 32-bit words, the "Payload
Length" is calculated by subtracting 2 (32 bit words).) In the "standard"
case of a 96-bit authentication value plus the 3 32-bit word fixed portion,
this length field will be "4".
  A "null" authentication algorithm may be used only for debugging
purposes. Its use would result in a "1" value for this field for IPv4 or a "2"
for IPv6, as there would be no corresponding

3.1.3 Reserved
       This 16-bit field is reserved for future use. It MUST be set to "zero."
(Note that the value is included in the Authentication Data calculation, but is
otherwise ignored by the recipient.)

3.1.4 Security Parameters Index (SPI)
            The SPI is an arbitrary 32-bit value that, in combination with the
destination IP address and security protocol (AH), uniquely
identifies the Security Association for this datagram. The set of
SPI values in the range 1 through 255 are reserved by the internet
Assigned Numbers Authority (IANA) for future use; a reserved SPI value
will not normally be assigned by IANA unless the use of the assigned SPI
                          Available at www.mindstien.net


value is specified in an RFC. It is ordinarily selected by the destination
system upon establishment of an SA

        The SPI value of zero (0) is reserved for local, implementation
specific use and MUST NOT be sent on the wire. For example, a key
management implementation MAY use the zero SPI value to mean "No
Security Association Exists" during the period when the IPsec
implementation has requested that its key management entity establish a
new SA, but the SA has not yet been established.

3.1.5 Sequence Number
        This unsigned 32-bit field contains a monotonically increasing
counter value (sequence number). It is mandatory and is always present
even if the receiver does not elect to enable the anti-replay service for a
specific SA. Processing of the Sequence Number field is at the discretion
of the receiver, i.e., the sender MUST always transmit this field, but the
receiver need not act upon it

         The sender's counter and the receiver's counter are initialized to 0
when an SA is established. (The first packet sent using a given SA will
have a Sequence Number of 1; see Section 3.3.2 for more details on how
the Sequence Number is generated.) If anti-replay is enabled (the
default), the transmitted Sequence Number must never be allowed to cycle.
Thus, the sender's counter and the receiver's counter MUST be reset (by
establishing a new SA and thus a new key) prior to the transmission of the
2^32nd packet on an SA.

3.1.6 Authentication Data
        This is a variable-length field that contains the Integrity Check Value
(ICV) for this packet. The field must be an integral multiple of 32 bits in
length. This field may include explicit padding. This padding is included to
ensure that the length of the
AH header is an integral multiple of 32 bits (IPv4) or 64 bits (IPv6). All
implementations MUST support such padding. Details of how to compute
the required padding length are provided below. The authentication
algorithm specification MUST specify the length of the ICV and the
comparison rules and processing steps for validation.
                                             Available at www.mindstien.net


3.2 Authentication Header Processing
        AH may be employed in two ways: transport mode or tunnelmode.
The former mode is applicable only to host implementations and provides
protection for upper layer protocols, in addition to selected IP header fields.
(In this mode, note that for "bump-in-the-stack" or "bump-in-the-wire"
implementations, as defined in the Security Architecture document,
inbound      and    outbound      IP      fragments      may     require    an
IPreassembly/fragmentation in order to both conform to this specification
and provide transparent IPsec support. Special care is required to perform
such operations within these implementations when multiple interfaces are
in use.)

        In transport mode, AH is inserted after the IP header and before an
upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other IPsec
headers that have already been inserted. In the context of IPv4, this calls
for placing AH after the IP header (and any options that it contains), but
before the upper layer protocol. (Note that the term "transport" mode
should not be misconstrued as restricting its use to TCP and UDP. For
example, an ICMP message MAY be sent using either "transport" mode or
"tunnel" mode.) The following diagram illustrates AH transport mode
positioning for a typical IPv4 packet, on a "before and after" basis.
          BEFORE APPLYING AH
     ----------------------------
  IPv4 |orig IP hdr | |           |
     |(any options)| TCP | Data |
     ----------------------------

          AFTER APPLYING AH
     ---------------------------------
  IPv4 |orig IP hdr | | |              |
     |(any options)| AH | TCP | Data |
     ---------------------------------
     |<------- authenticated ------->|


        In the IPv6 context, AH is viewed as an end-to-end payload, and
thus should appear after hop-by-hop, routing, and fragmentation extension
headers. The destination options extension header(s) could appear either
before or after the AH header depending on the semantics desired. The
following diagram illustrates AH transport mode positioning for a typical
IPv6 packet.
            BEFORE APPLYING AH
   ---------------------------------------
                                                              Available at www.mindstien.net

  IPv6 |           | ext hdrs | |          |
     | orig IP hdr |if present| TCP | Data |
     ---------------------------------------

             AFTER APPLYING AH
     ------------------------------------------------------------
  IPv6 |           |hop-by-hop, dest*, | | dest | |               |
     |orig IP hdr |routing, fragment. | AH | opt* | TCP | Data |
     ------------------------------------------------------------
     |<---- authenticated except for mutable fields ----------->|

         * = if present, could be before AH, after AH, or both


         Tunnel mode AH may be employed in either hosts or security
gateways (or in so-called "bump-in-the-stack" or "bump-in-the-wire"
implementations, as defined in the Security Architecture document). When
AH is implemented in a security gateway (to protect transit traffic), tunnel
mode must be used. In tunnel mode, the "inner" IP header carries the
ultimate source and destination addresses, while an "outer" IP header may
contain distinct IP addresses, e.g., addresses of security gateways. In
tunnel mode, AH protects the entire inner IP packet, including the entire
inner IP header. The position of AH in tunnel mode, relative to the outer IP
header, is the same as for AH in transport mode. The following diagram
illustrates AH tunnel mode positioning for typical IPv4 and IPv6 packets.
    ------------------------------------------------
 IPv4 | new IP hdr* | | orig IP hdr* | |              |
    |(any options)| AH | (any options) |TCP | Data |
    ------------------------------------------------
    |<- authenticated except for mutable fields -->|
    |         in the new IP hdr                     |

    --------------------------------------------------------------
 IPv6 |          | ext hdrs*| |              | ext hdrs*| | |
    |new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data|
    --------------------------------------------------------------
    |<-- authenticated except for mutable fields in new IP hdr ->|

     * = construction of outer IP hdr/extensions and modification
        of inner IP hdr/extensions is discussed below.


3.3 Authentication Algorithms

        The authentication algorithm employed for the ICV computation is
specified by the SA.         For point-to-point communication, suitable
authentication algorithms include keyed Message Authentication Codes
(MACs) based on symmetric encryption algorithms (e.g., DES) or on one-
way hash functions (e.g., MD5 or SHA-1). For multicast communication,
one-way hash algorithms combined with asymmetric signature algorithms
are appropriate, though performance and space considerations currently
preclude use of such algorithms.

4. ENCAPSULATING HEADER PAYLOAD (ESP)

       The Encapsulating Security Payload (ESP) header is designed to
provide a mix of security services in IPv4 and IPv6. ESP may be applied
                               Available at www.mindstien.net


alone, in combination with the IP Authentication Header (AH) [KA97b], or in
a nested fashion, e.g., through the use of tunnel mode.
  Security services can be provided between a pair of communicating
hosts, between a pair of communicating security gateways, or between a
security gateway and a host. For more details on how to use ESP and AH
in various network environments.

  The ESP header is inserted after the IP header and before the upper
layer protocol header (transport mode) or before an encapsulated IP
header (tunnel mode).




4.1 Encapsulating Security Payload Packet Format

       The protocol header (IPv4, IPv6, or Extension) immediately
preceding the ESP header will contain the value 50 in its Protocol (IPv4) or
Next Header (IPv6, Extension) field [STD-2].




  0           1            2           3
  01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
|         Security Parameters Index (SPI)             | ^Auth.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
|             Sequence Number                    | |erage
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ----
|            Payload Data* (variable)            || ^
~                                       ~| |
|                                      | |Conf.
+          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov-
|         | Padding (0-255 bytes)               | |erage*
+-+-+-+-+-+-+-+-+          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
|                   | Pad Length | Next Header | v v
                               Available at www.mindstien.net

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------
|          Authentication Data (variable)        |
~                                         ~
|                                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



4.1.1 Security Parameters Index

        The SPI is an arbitrary 32-bit value that, in combination with the
destination IP address and security protocol (ESP), uniquely identifies the
Security Association for this datagram. The set of SPI values in the range
1 through 255 are reserved by the Internet Assigned Numbers Authority
(IANA) for future use; a reserved SPI value will not normally be assigned by
IANA unless the use of the assigned SPI value is specified in an RFC. It is
ordinarily selected by the destination system upon establishment of an SA.
The SPI field is mandatory.

        The SPI value of zero (0) is reserved for local, implementation-
specific use and MUST NOT be sent on the wire. For example, a key
management implementation MAY use the zero SPI value to mean "No
Security Association Exists" during the period when the IPsec
implementation has requested that its key management entity establish a
new SA, but the SA has not yet been established.

4.1.2 Sequence Number

        This unsigned 32-bit field contains a monotonically increasing
counter value (sequence number). It is mandatory and is always present
even if the receiver does not elect to enable the anti-replay service for a
specific SA. Processing of the Sequence Number field is at the discretion
of the receiver, i.e., the sender MUST always transmit this field, but the
receiver need not act upon it.

        The sender's counter and the receiver's counter are initialized to 0
when an SA is established. (The first packet sent using a given SA will
have a Sequence Number of 1; see Section 3.3.3 for more details on how
the Sequence Number is generated.) If anti-replay is enabled (the default),
the transmitted Sequence Number must never be allowed to cycle. Thus,
the sender's counter and the receiver's counter MUST be reset (by
                          Available at www.mindstien.net


establishing a new SA and thus a new key) prior to the transmission of the
2^32nd packet on an SA.

4.1.3 Payload Data

        Payload Data is a variable-length field containing data described by
the Next Header field. The Payload Data field is mandatory and is an
integral number of bytes in length. If the algorithm used to encrypt the
payload requires cryptographic synchronization data, e.g., an Initialization
Vector (IV), then this data MAY be carried explicitly in the Payload field.
Any encryption algorithm that requires such explicit, per-packet
synchronization data MUST indicate the length, any structure for such data,
and the location of this data as part of an RFC specifying how the algorithm
is used with ESP. If such
synchronization data is implicit, the algorithm for deriving the data MUST
be part of the RFC.

Note that with regard to ensuring the alignment of the (real)
ciphertext in the presence of an IV:

           1. For some IV-based modes of operation, the receiver
           treats the IV as the start of the ciphertext, feeding it into the
           algorithm directly. In these modes, alignment of the start of the
           (real) ciphertext is not an issue at the receiver.
           2. In some cases, the receiver reads the IV in separately from
           the ciphertext. In these cases, the algorithm specification
           MUST address how alignment of the (real) ciphertext is to be
           achieved.

4.1.4 Padding (for Encryption)

 Several factors require or motivate use of the Padding field.

       o If an encryption algorithm is employed that requires the
        plaintext to be a multiple of some number of bytes, e.g.,
        the block size of a block cipher, the Padding field is used
        to fill the plaintext (consisting of the Payload Data, Pad
        Length and Next Header fields, as well as the Padding)to
        the size required by the algorithm.
                          Available at www.mindstien.net



       o Padding also may be required, irrespective of encryption
           algorithm requirements, to ensure that the resulting ciphertext
           terminates on a 4-byte boundary. Specifically,the Pad Length
           and Next Header fields must be right aligned within a 4-byte
           word, as illustrated in the ESP packet format figure above, to
           ensure that the
          Authentication Data field (if present) is aligned on a 4-
          byte boundary.

4.1.5 Pad Length

        The Pad Length field indicates the number of pad bytes
immediately preceding it. The range of valid values is 0-255, where a value
of zero indicates that no Padding bytes are present. The Pad Length field
is mandatory.

4.1.6 Next Header

       The Next Header is an 8-bit field that identifies the type of data
contained in the Payload Data field, e.g., an extension header in IPv6 or an
upper layer protocol identifier. The value of this field is chosen from the set
of IP Protocol Numbers defined in the mostrecent "Assigned Numbers"
[STD-2] RFC from the Internet Assigned Numbers Authority (IANA). The
Next Header field is mandatory.

4.1.7 Authentication Data

         The Authentication Data is a variable-length field containing an
Integrity Check Value (ICV) computed over the ESP packet minus the
Authentication Data.      The length of the field is specified by the
authentication function selected. The Authentication Data field is optional,
and is included only if the authentication service has been selected for the
SA in question. The authentication algorithm specification MUST specify
the length of the ICV and the comparison rules and processing steps for
validation.

4.2. Encapsulating Security Protocol Processing
                         Available at www.mindstien.net


          Like AH, ESP may be employed in two ways: transport mode or
tunnel mode. The former mode is applicable only to host implementations
and provides protection for upper layer protocols, but not the IP header.(In
this mode, note that for "bump-in-the-stack" or "bump-in-the-wire"
implementations, as defined in the Security Architecture document,
inbound and outbound IP fragments may require an IPsec implementation
to perform extra IP reassembly/fragmentation in order to both conform to
this specification and provide transparent IPsec support. Special care is
required to perform such operations within these implementations when
multiple interfaces are in use.)

          In transport mode, ESP is inserted after the IP header and before
an upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other
IPsec headers that have already been inserted. In the context of IPv4, this
translates to placing ESP after the IP header (and options that it contains),
but before the upper layer protocol.(Note that the term "transport" mode
should not be misconstrued as restricting its use to TCP and UDP. For
example, an ICMP message MAY be sent using either "transport" mode or
"tunnel" mode.) The following diagram illustrates ESP transport mode
positioning for a typical IPv4 packet, on a "before and after" basis. (The
"ESP trailer" encompasses any Padding, plus the Pad Length, and Next
Header fields.)

          BEFORE APPLYING ESP
      ----------------------------
   IPv4 |orig IP hdr | |           |
      |(any options)| TCP | Data |
      ----------------------------

          AFTER APPLYING ESP
      -------------------------------------------------
   IPv4 |orig IP hdr | ESP | |              | ESP | ESP|
      |(any options)| Hdr | TCP | Data | Trailer |Auth|
      -------------------------------------------------
                       |<----- encrypted ---->|
                  |<------ authenticated ----->|

       In the IPv6 context, ESP is viewed as an end-to-end payload, and
thus should appear after hop-by-hop, routing, and fragmentation extension
headers. The destination options extension header(s) could appear either
                         Available at www.mindstien.net


before or after the ESP header depending on the semantics desired.
However, since ESP protects only fields after the ESP header, it generally
may be desirable to place the destination options header(s) after the ESP
header. The following diagram illustrates ESP transport mode positioning
for a typical IPv6 packet.




              BEFORE APPLYING ESP
      ---------------------------------------
   IPv6 |           | ext hdrs | |          |
      | orig IP hdr |if present| TCP | Data |
      ---------------------------------------

              AFTER APPLYING ESP
      ---------------------------------------------------------
   IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP|
      |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer|Auth|
      ---------------------------------------------------------
                              |<---- encrypted ---->|
                           |<---- authenticated ---->|

          * = if present, could be before ESP, after ESP, or both


        Tunnel mode ESP may be employed in either hosts or security
gateways. When ESP is implemented in a security gateway (to protect
subscriber transit traffic), tunnel mode must be used. In tunnel mode, the
"inner" IP header carries the ultimate source and destination addresses,
while an "outer" IP header may contain distinct IP addresses, e.g.,
addresses of security gateways. In tunnel mode, ESP protects the entire
inner IP packet, including the entire inner IP header. The position of ESP in
tunnel mode, relative to the outer IP header, is the same as for ESP in
transport mode. The following diagram illustrates ESP tunnel mode
positioning for typical IPv4 and IPv6 packets.

      -----------------------------------------------------------
   IPv4 | new IP hdr* | | orig IP hdr* | | | ESP | ESP|
      |(any options)| ESP | (any options) |TCP|Data|Trailer|Auth|
                              Available at www.mindstien.net


       -----------------------------------------------------------
                        |<--------- encrypted ---------->|
                   |<----------- authenticated ---------->|

      ------------------------------------------------------------
   IPv6 | new* |new ext | | orig*|orig ext | | | ESP | ESP|
      |IP hdr| hdrs* |ESP|IP hdr| hdrs * |TCP|Data|Trailer|Auth|
      ------------------------------------------------------------
                       |<--------- encrypted ----------->|
                   |<---------- authenticated ---------->|

         * = if present, construction of outer IP hdr/extensions
            and modification of inner IP hdr/extensions is
           discussed below.




4.3 Algorithms

4.3.1 Encryption Algorithms

       The encryption algorithm employed is specified by the SA. ESP is
designed for use with symmetric encryption algorithms. Because IP
packets may arrive out of order, each packet must carry any data required
to allow the receiver to establish cryptographic synchronization for
decryption. This data may be carried explicitly in the payload field, e.g., as
an IV (as described above), or the data may be derived from the packet
header.     Since ESP makes provision for padding of the plaintext,
encryption algorithms employed with ESP may exhibit either block or
stream mode characteristics. Note that since encryption (confidentiality) is
optional, this algorithm may be "NULL".

4.3.2 Authentication Algorithms

        The authentication algorithm employed for the ICV computation is
specified by the SA.        For point-to-point communication, suitable
authentication algorithms include keyed Message Authentication Codes
(MACs) based on symmetric encryption algorithms (e.g., DES) or on one-
                          Available at www.mindstien.net


way hash functions (e.g., MD5 or SHA-1). For multicast communication,
one-way hash algorithms combined with asymmetric signature algorithms
are appropriate, though performance and space considerations currently
preclude use of such algorithms. Note that since authentication is optional,
this algorithm may be "NULL".

5. INTERNET SECURITY ASSOCIATION &
KEYMANAGEMENTPROTOCOL (ISAKMP).

       ISAKMP combines the security concepts of authentication, key
management, and security associations to establish the required security
for government, commercial, and private communications on the Internet.

          The Internet Security Association and Key Management Protocol
(ISAKMP) defines procedures and packet formats to establish, negotiate,
modify and delete Security Associations (SA). SAs contain all the
information required for execution of various network security services,
such as the IP layer services (such as header authentication and payload
encapsulation), transport or application layer services, or self-protection of
negotiation traffic.   ISAKMP defines payloads for exchanging key
generation and authentication data. These formats provide a consistent
framework for transferring key and authentication data which is
independent of the key generation technique, encryption algorithm and
authentication mechanism.

         ISAKMP is distinct from key exchange protocols in order to cleanly
separate the details of security association management (and key
management) from the details of key exchange. There may be many
different key exchange protocols, each with different security properties.
However, a common framework is required for agreeing to the format of SA
attributes, and for negotiating, modifying, and deleting SAs. ISAKMP
serves as this common framework.

         Separating the functionality into three parts adds complexity to the
security analysis of a complete ISAKMP implementation. However, the
separation is critical for interoperability between systems with differing
security requirements, and should also simplify the analysis of further
evolution of a ISAKMP server.
                         Available at www.mindstien.net


         ISAKMP is intended to support the negotiation of SAs for security
protocols at all layers of the network stack (e.g., IPSEC, TLS, TLSP, OSPF,
etc.). By centralizing the management of the security associations,
ISAKMP reduces the amount of duplicated functionality within each security
protocol. ISAKMP can also reduce connection setup time, by negotiating a
whole stack of services at once.




                               CONTENTS

           1. INTRODUCTION
                  How IP Security Prevents Network Attacks
                  An Example of IPSec
           2. .GOALS/OBJECTIVES/REQURMENTS
                What IPsec Does
                 Where IPsec May Be Implemented
           3.AUTHENTICATION HEADER
                3.1 Authentication Header Format
                       3.1.1 Next Header
                       3.1.2 Payload Length
                       3.1.3 Reserved
                       3.1.4 Security Parameters Index (SPI)
                       3.1.5 Sequence Number
                       3.1.6 Authentication Data
               3.2 Authentication Header Processing
               3.3 Authentication Algorithms
           4. ENCAPSULATING HEADER PAYLOAD (ESP)
               4.1 Encapsulating Security Payload Packet Format
                         Available at www.mindstien.net


                        4.1.1 Security Parameters Index
                        4.1.2 Sequence Number
                        4.1.3 Payload Data
                        4.1.4 Padding (for Encryption)
                        4.1.5 Pad Length
                        4.1.6 Next Header
                        4.1.7 Authentication Data
               4.2. Encapsulating Security Protocol Processing
               4.3 Algorithms
                       4.3.1 Encryption Algorithms
                        4.3.2 Authentication Algorithms
          5. INTERNET SECURITY ASSOCIATION & KEY
              MANAGEMENT PROTOCOL (ISAKMP).
CONCLUSION

      From analysis conclusion maybe obtain that the major security over
the internet is the IPsec, that is the protocol used for secure communication
which provides granular security which must be used by each network/ISPs
to give the secure access to their users.
Available at www.mindstien.net

								
To top