A Networker Blog.-

RFC 2401 defines the architecture for IPSec, including the framework and the services provided. RFC 2401 also defines how the services work together and how and where to use them.

IPSec uses three main protocols to create a security framework:

• Internet Key Exchange (IKE)
• Encapsulating Security Payload (ESP)
• Authentication Header (AH)

Internet Key Exchange (IKE)  is the protocol for exchanging keys. It provides a framework for the negotiation of security parameters and establishes authenticated keys.

IPSec uses symmetrical encryption algorithms for data protection, which are more efficient and easier to implement in hardware than other types of algorithms.

These algorithms need a secure method of key exchange to ensure data protection. The IKE protocols provide the capability for secure key exchange.

Internet Key Exchange (IKE) solves the problems of manual and unscalable implementation of IPSec by automating the entire key exchange process, including

• negotiation of security association (SA) characteristics
• automatic key generation
• automatic key refresh
• manageable manual configuration

To implement a VPN solution with encryption, the periodic changing of encryption keys is necessary. Failure to change these keys makes the network susceptible to brute force attacks.

IPSec solves this problem with the IKE protocol, which uses two other protocols to authenticate a peer and generate keys. The IKE protocol uses a mathematical routine called a Diffie-Hellman exchange to generate symmetrical keys to be used by two IPSec peers.

IKE also manages the negotiation of other security parameters, such as data to be protected, strength of the keys, hash methods used, and whether packets are protected from replay. IKE uses UDP port 500.

IKE negotiates an SA, which is an agreement between two peers engaging in an IPSec exchange. To establish successful communication, the SA comprises three required parameters:

• Oakley
• ISAKMP
• Skeme

Resume of the IKE Phases

IKE Phase 1:

* Authenticate the peers

Optionally, phase 1 can also include an authentication in which each peer is able to verify the identity of the other. This conversation between two IPSec peers can be subject to eavesdropping with no significant vulnerability of the keys being recovered.

* Negotiate a bidirectional SA

Phase 1 SAs are bidirectional – data may be sent and received using the same key material generated. Two modes are available for phase 1 SA negotiations: main mode or aggressive mode.

* Main mode (6 messages) or aggressive mode (3 messages)

in – Main mode

In the main mode, an IKE session begins with the initiator sending a proposal or proposals to the responder. These proposals define which encryption and authentication protocols are acceptable, how long keys should remain active, and whether perfect forward secrecy should be enforced. Multiple proposals can be sent in one offering.

The first exchange between nodes establishes the basic security policy. The responder chooses the appropriate proposal and sends it to the initiator. The next exchange passes Diffie-Hellman public keys and other data. All further negotiation is encrypted within the IKE SA. The third exchange authenticates the ISAKMP session. Once the IKE SA is established, IPSec negotiation (quick mode) begins.

in – Aggressive mode

The aggressive mode squeezes the IKE SA negotiation into three packets, with all data required for the SA passed by the initiator. The responder sends the proposal, key material, and identification, and authenticates the session in the next packet. The initiator replies by authenticating the session. Negotiation is quicker, and the initiator and responder ID pass in plaintext.

IKE Phase 1 is the initial negotiation of SAs between two IPSec peers.

IKE Phase 1.5 (Optional):

* Xauth (User Authentication)

IKE Phase 1.5 is optional. To further authenticate VPN participants (clients), you can use a protocol called Extended Authentication (Xauth), which provides user authentication of IPSec tunnels within the IKE protocol. Additionally, you can exchange other parameters between the peers.

* Mode config (Push Config)

Mode configuration is used to deliver parameters such as IP address and DNS address to the client.

IKE Phase 2:

* IPsec SAs/SPIs

IKE Phase 2 SAs are negotiated by the IKE process (ISAKMP) on behalf of other services such as IPSec, which need key material for operation.

Because the SAs used by IPSec are unidirectional, separate key exchanges are needed for data flowing in the forward direction and the reverse direction. The two peers have already agreed upon the transform sets, hash methods, and other parameters during the phase 1 negotiation.

* Quick mode

Quick mode is the method used for the phase 2 SA negotiations. - The quick mode IPSec negotiation is similar to an aggressive mode IKE negotiation, except negotiation must be protected within an IKE SA. Quick mode negotiates the SA for the data encryption and manages the key exchange for that IPSec SA.

** show crypto ipsec sa

Main mode:

has three two-way exchanges between the initiator and receiver:

— First exchange—The algorithms and hashes used to secure the IKE communications are negotiated and agreed upon between peers.

— Second exchange—This exchange uses a DH exchange to generate shared secret keys and pass nonces, which are random numbers sent to the other party, signed, and returned to prove their identity. The shared secret key is used to generate all the  other encryption and authentication keys.

— Third exchange—This exchange verifies the other side’s identity. It is used to authenticate the remote peer. The main outcome of main mode is a secure communication path for subsequent exchanges between the peers. Without proper authentication, you might establish a secure communication channel with a hacker who could be stealing all your sensitive material.

– Takes longer time to negotiate

– Hides party identities performing DH exchange

            Initiator                    Responder
               HDR, SA             -->
                                  <--    HDR, SA
              HDR, KE, Ni, GSSi   -->
                                  <--    HDR, KE, Nr, GSSr
              HDR*, IDii, HASH_I  -->
                                  <--    HDR*, IDir, HASH_R

in this log you can find the different states of   the Main Mode

• IKE_READY New State = IKE_I_MM1
• IKE_I_MM1 New State = IKE_I_MM2
• IKE_I_MM2 New State = IKE_I_MM3
• IKE_I_MM3 New State = IKE_I_MM4
• IKE_I_MM4 New State = IKE_I_MM5
• IKE_I_MM5 New State = IKE_I_MM6

crypto isakmp key cisco123 address 2.2.2.2
!
!
crypto ipsec transform-set R3R2 esp-aes 192 esp-md5-hmac
!
crypto map NAME local-address Loopback0
crypto map NAME 10 ipsec-isakmp
 set peer 2.2.2.2
 set transform-set R3R2
 match address 100
!
!
!
AKMP: Created a peer struct for 2.2.2.2, peer port 500
ISAKMP: New peer created peer = 0x66F2A5F4 peer_handle = 0x80000004
ISAKMP: Locking peer struct 0x66F2A5F4, refcount 1 for isakmp_initiator
ISAKMP: local port 500, remote port 500
ISAKMP: set new node 0 to QM_IDLE
ISAKMP: Find a dup sa in the avl tree during calling isadb_insert sa = 66F1F9DC
ISAKMP:(0):Can not start Aggressive mode, trying Main mode.
ISAKMP:(0):found peer pre-shared key matching 2.2.2.2
ISAKMP:(0): constructed NAT-T vendor-07 ID
ISAKMP:(0): constructed NAT-T vendor-03 ID
ISAKMP:(0): constructed NAT-T vendor-02 ID
ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM
ISAKMP:(0):Old State = IKE_READY  New State = IKE_I_MM1
ISAKMP:(0): beginning Main Mode exchange
ISAKMP:(0): sending packet to 2.2.2.2 my_port 500 peer_port 500 (I) MM_NO_STATE
ISAKMP (0:0): received packet from 2.2.2.2 dport 500 sport 500 Global (I) MM_NO_STATE
ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
ISAKMP:(0):Old State = IKE_I_MM1  New State = IKE_I_MM2
ISAKMP:(0): processing SA payload. message ID = 0
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID seems Unity/DPD but major 245 mismatch
ISAKMP (0:0): vendor ID is NAT-T v7
ISAKMP:(0):found peer pre-shared key matching 2.2.2.2
ISAKMP:(0): local preshared key found
ISAKMP : Scanning profiles for xauth ...
ISAKMP:(0):Checking ISAKMP transform 1 against priority 10 policy
ISAKMP:      encryption DES-CBC
ISAKMP:      hash SHA
ISAKMP:      default group 1
ISAKMP:      auth pre-share
ISAKMP:      life type in seconds
ISAKMP:      life duration (VPI) of  0x0 0x1 0x51 0x80
ISAKMP:(0):atts are acceptable. Next payload is 0
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID seems Unity/DPD but major 245 mismatch
ISAKMP (0:0): vendor ID is NAT-T v7
ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
ISAKMP:(0):Old State = IKE_I_MM2  New State = IKE_I_MM2
ISAKMP:(0): sending packet to 2.2.2.2 my_port 500 peer_port 500 (I) MM_SA_SETUP
ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
ISAKMP:(0):Old State = IKE_I_MM2  New State = IKE_I_MM3
ISAKMP (0:0): received packet from 2.2.2.2 dport 500 sport 500 Global (I) MM_SA_SETUP
ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
ISAKMP:(0):Old State = IKE_I_MM3  New State = IKE_I_MM4
ISAKMP:(0): processing KE payload. message ID = 0
ISAKMP:(0): processing NONCE payload. message ID = 0
ISAKMP:(0):found peer pre-shared key matching 2.2.2.2
ISAKMP:(1002): processing vendor id payload
ISAKMP:(1002): vendor ID is Unity
ISAKMP:(1002): processing vendor id payload
ISAKMP:(1002): vendor ID is DPD
ISAKMP:(1002): processing vendor id payload
ISAKMP:(1002): speaking to another IOS box!
ISAKMP:(1002):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
ISAKMP:(1002):Old State = IKE_I_MM4  New State = IKE_I_MM4
ISAKMP:(1002):Send initial contact
ISAKMP:(1002):SA is doing pre-shared key authentication using id type ID_IPV4_ADDR
ISAKMP (0:1002): ID payload
        next-payload : 8
        type         : 1
        address      : 3.3.3.3
        protocol     : 17
        port         : 500
        length       : 12
ISAKMP:(1002):Total payload length: 12
ISAKMP:(1002): sending packet to 2.2.2.2 my_port 500 peer_port 500 (I) MM_KEY_EXCH
ISAKMP:(1002):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
ISAKMP:(1002):Old State = IKE_I_MM4  New State = IKE_I_MM5
ISAKMP (0:1002): received packet from 2.2.2.2 dport 500 sport 500 Global (I) MM_KEY_EXCH
ISAKMP:(1002): processing ID payload. message ID = 0
ISAKMP (0:1002): ID payload
        next-payload : 8
        type         : 1
        address      : 2.2.2.2
        protocol     : 17
        port         : 500
        length       : 12
ISAKMP:(1002):: peer matches *none* of the profiles
ISAKMP:(1002): processing HASH payload. message ID = 0
ISAKMP:(1002):SA authentication status:
        authenticated
ISAKMP:(1002):SA has been authenticated with 2.2.2.2
ISAKMP: Trying to insert a peer 3.3.3.3/2.2.2.2/500/,  and inserted successfully 66F2A5F4.
ISAKMP:(1002):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
ISAKMP:(1002):Old State = IKE_I_MM5  New State = IKE_I_MM6
ISAKMP (0:1002): received packet from 2.2.2.2 dport 500 sport 500 Global (I) MM_KEY_EXCH
ISAKMP: set new node 383677917 to QM_IDLE
ISAKMP:(1002): processing HASH payload. message ID = 383677917
ISAKMP:(1002): processing DELETE payload. message ID = 383677917
ISAKMP:(1002):peer does not do paranoid keepalives.
ISAKMP:(1002):deleting node 383677917 error FALSE reason "Informational (in) state 1"
IPSEC(key_engine): got a queue event with 1 KMI message(s)
IPSEC(key_engine_delete_sas): rec'd delete notify from ISAKMP
ISAKMP:(1002):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
ISAKMP:(1002):Old State = IKE_I_MM6  New State = IKE_I_MM6
ISAKMP:(1002):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
ISAKMP:(1002):Old State = IKE_I_MM6  New State = IKE_P1_COMPLETE
ISAKMP:(1002):beginning Quick Mode exchange, M-ID of 446518647
ISAKMP:(1002): sending packet to 2.2.2.2 my_port 500 peer_port 500 (I) QM_IDLE
ISAKMP:(1002):Node 446518647, Input = IKE_MESG_INTERNAL, IKE_INIT_QM
ISAKMP:(1002):Old State = IKE_QM_READY  New State = IKE_QM_I_QM1
ISAKMP:(1002):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
ISAKMP:(1002):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE
ISAKMP (0:1002): received packet from 2.2.2.2 dport 500 sport 500 Global (I) QM_IDLE
ISAKMP:(1002): processing HASH payload. message ID = 446518647
ISAKMP:(1002): processing SA payload. message ID = 446518647
ISAKMP:(1002):Checking IPSec proposal 1
ISAKMP: transform 1, ESP_AES
ISAKMP:   attributes in transform:
ISAKMP:      encaps is 1 (Tunnel)
ISAKMP:      SA life type in secondsISAKMP:
SA life duration (basic) of 3600
ISAKMP:      SA life type in kilobytes
ISAKMP:      SA life duration (VPI) of  0x0 0x46 0x50 0x0
ISAKMP:      authenticator is HMAC-MD5
ISAKMP:      key length is 192
ISAKMP:(1002):atts are acceptable.
IPSEC(validate_proposal_request): proposal part #1
IPSEC(validate_proposal_request): proposal part #1,
  (key eng. msg.) INBOUND local= 3.3.3.3, remote= 2.2.2.2,
    local_proxy= 3.3.3.3/255.255.255.255/0/0 (type=1),
    remote_proxy= 2.2.2.2/255.255.255.255/0/0 (type=1),
    protocol= ESP, transform= esp-aes 192 esp-md5-hmac  (Tunnel),
    lifedur= 0s and 0kb,
    spi= 0x0(0), conn_id= 0, keysize= 192, flags= 0x0
Crypto mapdb : proxy_match
        src addr     : 3.3.3.3
        dst addr     : 2.2.2.2
        protocol     : 0
        src port     : 0
        dst port     : 0
ISAKMP:(1002): processing NONCE payload. message ID = 446518647
ISAKMP:(1002): processing ID payload. message ID = 446518647
ISAKMP:(1002): processing ID payload. message ID = 446518647
ISAKMP:(1002): Creating IPSec SAs
        inbound SA from 2.2.2.2 to 3.3.3.3 (f/i)  0/ 0
        (proxy 2.2.2.2 to 3.3.3.3)
        has spi 0x8B6DC3A5 and conn_id 0
        lifetime of 3600 seconds
        lifetime of 4608000 kilobytes
        outbound SA from 3.3.3.3 to 2.2.2.2 (f/i) 0/0
        (proxy 3.3.3.3 to 2.2.2.2)
        has spi  0x83BD1925 and conn_id 0
        lifetime of 3600 seconds
        lifetime of 4608000 kilobytes
ISAKMP:(1002): sending packet to 2.2.2.2 my_port 500 peer_port 500 (I) QM_IDLE
ISAKMP:(1002):deleting node 446518647 error FALSE reason "No Error"
ISAKMP:(1002):Node 446518647, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
ISAKMP:(1002):Old State = IKE_QM_I_QM1  New State = IKE_QM_PHASE2_COMPLETE
IPSEC(key_engine): got a queue event with 1 KMI message(s)
Crypto mapdb : proxy_match
        src addr     : 3.3.3.3
        dst addr     : 2.2.2.2
        protocol     : 0
        src port     : 0
        dst port     : 0
IPSEC(crypto_ipsec_sa_find_ident_head): reconnecting with the same proxies and peer 2.2.2.2
IPSec: Flow_switching Allocated flow for sibling 80000003
IPSEC(policy_db_add_ident): src 3.3.3.3, dest 2.2.2.2, dest_port 0
IPSEC(create_sa): sa created,
  (sa) sa_dest= 3.3.3.3, sa_proto= 50,
    sa_spi= 0x8B6DC3A5(2339226533),
    sa_trans= esp-aes 192 esp-md5-hmac , sa_conn_id= 3
IPSEC(create_sa): sa created,
  (sa) sa_dest= 2.2.2.2, sa_proto= 50,
    sa_spi= 0x83BD1925(2210208037),
    sa_trans= esp-aes 192 esp-md5-hmac , sa_conn_id= 4
IPSEC(update_current_outbound_sa): updated peer 2.2.2.2 current outbound sa to SPI 83BD1925

Aggressive mode:

fewer exchanges are done and with fewer packets. The first exchange covers almost all of the steps:

the IKE policy set negotiation; the DH public key generation; a nonce, which the other party signs; and an identity packet,  which can be used to verify the identity of the other party via a third party. The receiver sends everything back that is needed to complete the exchange. The only thing left is for the initiator to confirm the exchange.

– Takes less time to negotiate

– Does not hide party identities

             Initiator                    Responder

              HDR, SA, KE, Ni,
                IDii, GSSi        -->
                                  <--    HDR, SA, KE, Nr,
                                         IDir, GSSr, HASH_R
              HDR, HASH_I         -->

crypto isakmp policy 10
 authentication pre-share
!
crypto isakmp peer address 2.2.2.2
 set aggressive-mode password cisco123
 set aggressive-mode client-endpoint ipv4-address 3.3.3.3
!
!
crypto ipsec transform-set R3R2 esp-aes 192 esp-md5-hmac
!
crypto map NAME local-address Loopback0
crypto map NAME 10 ipsec-isakmp
 set peer 2.2.2.2
 set transform-set R3R2
 match address 100
!
!
!
!
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface FastEthernet0/0
 no ip address
 shutdown
 duplex half
!
interface FastEthernet1/0
 ip address 10.1.13.3 255.255.255.0
 duplex auto
 speed auto
 crypto map NAME
!
access-list 100 permit ip host 3.3.3.3 host 2.2.2.2
!
!
IPSEC(sa_request): ,
  (key eng. msg.) OUTBOUND local= 3.3.3.3, remote= 2.2.2.2,
    local_proxy= 3.3.3.3/255.255.255.255/0/0 (type=1),
    remote_proxy= 2.2.2.2/255.255.255.255/0/0 (type=1),
    protocol= ESP, transform= NONE  (Tunnel),
    lifedur= 3600s and 4608000kb,
    spi= 0x38875DE9(948395497), conn_id= 0, keysize= 192, flags= 0x0
ISAKMP:(0): SA request profile is (NULL)
ISAKMP: Created a peer struct for 2.2.2.2, peer port 500
ISAKMP: New peer created peer = 0x6678E794 peer_handle = 0x80000007
ISAKMP: Locking peer struct 0x6678E794, refcount 1 for isakmp_initiator
ISAKMP: local port 500, remote port 500
ISAKMP: set new node 0 to QM_IDLE
ISAKMP: Find a dup sa in the avl tree during calling isadb_insert sa = 670BE478
ISAKMP:(0):SA has tunnel attributes set.
ISAKMP:(0): constructed NAT-T vendor-07 ID
ISAKMP:(0): constructed NAT-T vendor-03 ID
ISAKMP:(0): constructed NAT-T vendor-02 ID
ISAKMP:(0):SA is doing pre-shared key authentication using id type ID_IPV4_ADDR
ISAKMP (0:0): ID payload
        next-payload : 13
        type         : 1
        address      : 3.3.3.3
        protocol     : 17
        port         : 0
        length       : 12
ISAKMP:(0):Total payload length: 12
ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_AM
ISAKMP:(0):Old State = IKE_READY  New State = IKE_I_AM1

ISAKMP:(0): beginning Aggressive Mode exchange
ISAKMP:(0): sending packet to 2.2.2.2 my_port 500 peer_port 500 (I) AG_INIT_EXCH
ISAKMP (0:0): received packet from 2.2.2.2 dport 500 sport 500 Global (I) AG_INIT_EXCH
ISAKMP:(0): processing SA payload. message ID = 0
ISAKMP:(0): processing ID payload. message ID = 0
ISAKMP (0:0): ID payload
        next-payload : 10
        type         : 1
        address      : 2.2.2.2
        protocol     : 17
        port         : 0
        length       : 12
ISAKMP:(0):: peer matches *none* of the profiles
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID is Unity
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID is DPD
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): speaking to another IOS box!
ISAKMP:(0):SA using tunnel password as pre-shared key.
ISAKMP:(0): local preshared key found
ISAKMP : Scanning profiles for xauth ...
ISAKMP:(0):Checking ISAKMP transform 1 against priority 10 policy
ISAKMP:      encryption DES-CBC
ISAKMP:      hash SHA
ISAKMP:      default group 1
ISAKMP:      auth pre-share
ISAKMP:      life type in seconds
ISAKMP:      life duration (VPI) of  0x0 0x1 0x51 0x80
ISAKMP:(0):atts are acceptable. Next payload is 0
ISAKMP (0:0): vendor ID is NAT-T v7
ISAKMP:(0): processing KE payload. message ID = 0
ISAKMP:(0): processing NONCE payload. message ID = 0
ISAKMP:(0):SA using tunnel password as pre-shared key.
ISAKMP:(1003): processing HASH payload. message ID = 0
ISAKMP:(1003):SA authentication status:
        authenticated
ISAKMP:(1003):SA has been authenticated with 2.2.2.2
ISAKMP: Trying to insert a peer 3.3.3.3/2.2.2.2/500/,  and inserted successfully 6678E794.
ISAKMP:(1003):Send initial contact
ISAKMP:(1003): sending packet to 2.2.2.2 my_port 500 peer_port 500 (I) AG_INIT_EXCH
ISAKMP:(1003):Input = IKE_MESG_FROM_PEER, IKE_AM_EXCH
ISAKMP:(1003):Old State = IKE_I_AM1  New State = IKE_P1_COMPLETE

ISAKMP:(1003):beginning Quick Mode exchange, M-ID of -243305607
ISAKMP:(1003): sending packet to 2.2.2.2 my_port 500 peer_port 500 (I) QM_IDLE
ISAKMP:(1003):Node -243305607, Input = IKE_MESG_INTERNAL, IKE_INIT_QM
ISAKMP:(1003):Old State = IKE_QM_READY  New State = IKE_QM_I_QM1
ISAKMP:(1003):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
ISAKMP:(1003):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE

ISAKMP (0:1003): received packet from 2.2.2.2 dport 500 sport 500 Global (I) QM_IDLE
ISAKMP: set new node -689131644 to QM_IDLE
ISAKMP:(1003): processing HASH payload. message ID = -689131644
ISAKMP:(1003): processing DELETE payload. message ID = -689131644
ISAKMP:(1003):peer does not do paranoid keepalives.

ISAKMP:(1003):deleting node -689131644 error FALSE reason "Informational (in) state 1"
IPSEC(key_engine): got a queue event with 1 KMI message(s)
IPSEC(key_engine_delete_sas): rec'd delete notify from ISAKMP
ISAKMP (0:1003): received packet from 2.2.2.2 dport 500 sport 500 Global (I) QM_IDLE
ISAKMP:(1003): processing HASH payload. message ID = -243305607
ISAKMP:(1003): processing SA payload. message ID = -243305607
ISAKMP:(1003):Checking IPSec proposal 1
ISAKMP: transform 1, ESP_AES
ISAKMP:   attributes in transform:
ISAKMP:      encaps is 1 (Tunnel)
ISAKMP:      SA life type in seconds
ISAKMP:      SA life duration (basic) of 3600
ISAKMP:      SA life type in kilobytes
ISAKMP:      SA life duration (VPI) of  0x0 0x46 0x50 0x0
ISAKMP:      authenticator is HMAC-MD5
ISAKMP:      key length is 192
ISAKMP:(1003):atts are acceptable.
IPSEC(validate_proposal_request): proposal part #1
IPSEC(validate_proposal_request): proposal part #1,
  (key eng. msg.) INBOUND local= 3.3.3.3, remote= 2.2.2.2,
    local_proxy= 3.3.3.3/255.255.255.255/0/0 (type=1),
    remote_proxy= 2.2.2.2/255.255.255.255/0/0 (type=1),
    protocol= ESP, transform= esp-aes 192 esp-md5-hmac  (Tunnel),
    lifedur= 0s and 0kb,
    spi= 0x0(0), conn_id= 0, keysize= 192, flags= 0x0
Crypto mapdb : proxy_match
        src addr     : 3.3.3.3
        dst addr     : 2.2.2.2
        protocol     : 0
        src port     : 0
        dst port     : 0
ISAKMP:(1003): processing NONCE payload. message ID = -243305607
ISAKMP:(1003): processing ID payload. message ID = -243305607
ISAKMP:(1003): processing ID payload. message ID = -243305607
ISAKMP:(1003): Creating IPSec SAs
        inbound SA from 2.2.2.2 to 3.3.3.3 (f/i)  0/ 0
        (proxy 2.2.2.2 to 3.3.3.3)
        has spi 0x38875DE9 and conn_id 0
        lifetime of 3600 seconds
        lifetime of 4608000 kilobytes
        outbound SA from 3.3.3.3 to 2.2.2.2 (f/i) 0/0
        (proxy 3.3.3.3 to 2.2.2.2)
        has spi  0x77695521 and conn_id 0
        lifetime of 3600 seconds
        lifetime of 4608000 kilobytes
ISAKMP:(1003): sending packet to 2.2.2.2 my_port 500 peer_port 500 (I) QM_IDLE
ISAKMP:(1003):deleting node -243305607 error FALSE reason "No Error"
ISAKMP:(1003):Node -243305607, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH
ISAKMP:(1003):Old State = IKE_QM_I_QM1  New State = IKE_QM_PHASE2_COMPLETE
IPSEC(key_engine): got a queue event with 1 KMI message(s)
Crypto mapdb : proxy_match
        src addr     : 3.3.3.3
        dst addr     : 2.2.2.2
        protocol     : 0
        src port     : 0
        dst port     : 0
IPSEC(crypto_ipsec_sa_find_ident_head): reconnecting with the same proxies and peer 2.2.2.2
IPSec: Flow_switching Allocated flow for sibling 80000004
IPSEC(policy_db_add_ident): src 3.3.3.3, dest 2.2.2.2, dest_port 0

IPSEC(create_sa): sa created,
  (sa) sa_dest= 3.3.3.3, sa_proto= 50,
    sa_spi= 0x38875DE9(948395497),
    sa_trans= esp-aes 192 esp-md5-hmac , sa_conn_id= 5
IPSEC(create_sa): sa created,
  (sa) sa_dest= 2.2.2.2, sa_proto= 50,
    sa_spi= 0x77695521(2003391777),
    sa_trans= esp-aes 192 esp-md5-hmac , sa_conn_id= 6
IPSEC(update_current_outbound_sa): updated peer 2.2.2.2 current outbound sa to SPI 77695521

list of current RFCs concerning IPSec

RFC 1829: The ESP DES-CBC transform

RFC 1851: The ESP triple DES transform

RFC 2085: HMAC-MD5 IP authentication with replay prevention

RFC 2207: RSVP extensions for IPSec data flows

RFC 2401: Security architecture for the Internet Protocol

RFC 2402: IP Authentication Header

RFC 2403: The use of HMAC-MD5-96 within ESP and AH

RFC 2404: The use of HMAC-SHA-1-96 within ESP and AH

RFC 2405: The ESP DES-CBC Cipher Algorithm with Explicit IV

RFC 2406: IP Encapsulating Security Payload (ESP)

RFC 2407: The Internet IP security domain of interpretation for ISAKMP

RFC 2408: Internet Security Association and Key Management Protocol (ISAKMP)

RFC 2409: The Internet Key Exchange (IKE)

RFC 2410: The NULL Encryption and its use with IPSec

RFC 2451: The ESP CBC-Mode Cipher Algorithm

RFC 2539: Storage of Diffie-Hellman Keys in the Domain Name Space (DNS)

RFC 2631: Diffie-Hellman Key Agreement Method

RFC 2857: The use of HMAC-RIPEMD-160-96 within ESP and AH

RFC 2875: Diffie-Hellman Proof-of-Possession Algorithms

RFC 3070: Layer Two Tunneling Protocol (L2TP) over Frame Relay

RFC 3104: RSIP Support for End-of-End IPSec

RFC 3145: L2LTP disconnect cause information

RFC 3193: Securing L2LTP using IP

RFC 3301: Layer Two Tunneling Protocol (L2LTP): ATM access network extensions

In Summary

IPSec is a way to secure data transmissions over unprotected networks. IPSec provides data confidentiality, data integrity, data origin authentication, and anti-replay, which verify the uniqueness of each data packet. IPSec uses the Encapsulating Security Payload (ESP) and Authentication Header (AH) IP protocols, as well as the Internet Key Exchange (IKE) protocol. IPSec also handles peer authentication.

IPSec solves the encryption problem of a VPN solution by using the IKE protocol, which uses UDP port 500. IKE is executed in two phases. Phase 1 initializes the SAs between two peers, and phase 2 manages the bidirectional flow of information between the two peers. Phase 1 can be split into two, so that you can do an extended authentication (Xauth) on VPN clients. IKE can be used in a combination of three modes – main mode, aggressive mode, and quick mode.