ALERT

Hi viewers, I am working on  site to site IOS VPN carried out by legacy method. Its very innovative and by my style of studying. You  will get lot of it  by viewing that.

BASIC UNDERSTANDING FOR THE POINT

UNDERSTANDING AT POINT HOW ENGINE WORKS:

    1.     First we need to create ISAKMP policy which includes HAGLE.

    2.     Then tell who is the peer and key or identity to authenticate.     

    3.     Create a ACL for identifying interesting traffic.

    4.     Create a IPSEC TRANSFORM SET which says what is Encryption and Encapsulation.

    5.     Create MAP and include IPSEC TRANSFORM SET, PEER and ACL no.

    6.     Associate the MAP on the peer interface so that when traffic initiates the MAP comes in action.

VPN AH & ESP

Authentication Header and Encapsulating Security Payload

Both AH and ESP operate at the network layer of the OSI model and, as a result, have their own protocol numbers for protocol identification carried out by devices in the VPN path. (The protocol numbers assigned are 51 and 50, respectively.) As mentioned earlier, ESP can provide the optional encryption function for data traversing the VPN

connection. Therefore, ESP is the preferred choice for use with IPsec. The data encryption function provided by ESP is carried out by one of the following symmetric key algorithms:

 Digital Encryption Standard (DES)

 Triple DES (3DES)

 Advanced Encryption Standard (AES) (preferred)

The origin authentication, provided by both AH and ESP, can be carried out by one of the following hash algorithms:

 Message digest 5 algorithm (MD5)

 Secure Hash (SHA) (and only for IKEv2: SHA256, SHA384, SHA512)

AH is unavailable for use on the ASA because of the lack of an encryption option. Therefore, when configuring a VPN, only ESP is available to us. Because ESP and AH operate at the network layer, the original host and destination IP addresses remain in the packet throughout the network, exposing them to potential attackers of the VPN connection. However, which IPsec mode (either Transport or Tunnel) is chosen determines the amount of the original packet to be hidden.

Normal Frame:

Ethernet Header

IP Header

TCP/UDP Header

DATA

AH Transport mode frame

Ethernet Header

IP header Authenticated

AH Header Authenticated

TCP/UDP Header Authenticated

DATA Authenticated

AH Tunnel mode frame

Ethernet Header

New IP Header Authenticated

AH Header Authenticated

IP Header Authenticated

TCP/UDP Header Authenticated

DATA Authenticated

                                                                                                                                          

ESP Transport mode frame  

Ethernet Header

IP Header

ESP Header Authenticated

Encrypted TCP/UDP  Header Authenticated

Encrypted Data Authenticated

ESP Trailer Authenticated

ESP Authentication Authenticated

                                                               

ESP Tunnel mode frame                                                        

Ethernet Header

New IP Header

ESP Header Authenticated

Encrypted IP Header Authenticated

Encrypted TCP/UDP Header Authenticated

Encrypted Data Authenticated

ESP Trailer Authenticated

ESP Authentication Authenticated

                                                                              

In both AH and ESP Transport mode, the original IP addresses remain untouched and are visible to potential attackers. However, when operating within Tunnel mode, the AH and ESP headers are placed after the original IP header, and a new IP header is added. This header contains the IP addresses of the VPN endpoints (ASA, PIX, concentrator, or router), which are generally public IP addresses and contain no information, thus not allowing an attacker to determine any valuable information about the internal network. ASA, as a VPN tunnel endpoint, supports only Tunnel mode. Even if Transport mode is configured on the ASA, the resulting VPN tunnel negotiates and uses Tunnel mode. This is also the case for Cisco routers running IOS. However, this restriction applies only to native IPsec functionality, Transport mode is supported on IOS routers (for example, when generic routing encapsulation [GRE] tunneling is used along with IPsec, but not on the ASA, which does not support GRE termination).

VPN XAUTH

XAUTH

An optional Extended Authentication (XAUTH) phase can also take place after successful Phase 1 SA creation. XAUTH carries out the process of end host/device authentication before a user can use the VPN connection. Be careful not to confuse this optional step with the peer authentication carried out within IKEv1 Phase 1. The difference is IKEv1 Phase 1 carries out the authentication of the VPN peers used to terminate each end of the SA, whereas XAUTH is used for the authentication of users or devices that will be transmitting and receiving data across the established VPN tunnel. This phase can occur in remote-access or Easy VPN scenarios, but not in site-to-site VPNs.

XAUTH authentication can be achieved by using either of the following:

 Static username and passwords

 One-time passwords (OTP)

VPN IKEv1 PHASE II

IKEv1 Phase 2

This second mandatory phase uses the negotiated parameters in Phase 1 for secure IPsec SA creation. However, unlike the single bidirectional SA created within Phase 1, the IPsec SAs are unidirectional, meaning a different session key is used for each direction (one for inbound, or decrypted, traffic, and one for outbound, or encrypted, traffic). This is applicable for any administrator-configured source-destination network pair. Therefore, you might end up with four unidirectional IPsec SAs if you have two source-destination network pairs defined in a VPN policy.

During IKEv1 Quick mode (Phase 2), IKEv1 transform sets (a list of encryption and hashing protocols) used for IPsec policy negotiation and unidirectional SA creation are exchanged between peers. Regardless of the parameters/attributes selected within a transform set, the same five pieces of information are always sent:

 IPsec encryption algorithm (DES, 3DES, AES)

 IPsec authentication algorithm (MD5, SHA-1)

 IPsec protocol (AH or ESP)

 IPsec SA lifetime (seconds or kilobytes)

 IPsec mode (Tunnel, Transport)

VPN IKE PHASE I

IKEv1 Phase 1

During this phase, both peers negotiate parameters (integrity and encryption algorithms, authentication methods) to set up a secure and authenticated tunnel. This is also called a management channel because no user data is flowing through it (and it is actually a bidirectional IKE SA). It is called bidirectional because both peers use only one session key to secure both incoming and outgoing traffic. Peer authentication can be carried out by one of the following methods:

 Pre-shared keys

 Digital certificates

IKEv1 uses either IKEv1 Main mode or IKEv1 Aggressive mode in Phase 1 to carry out the actions required to build a bidirectional tunnel. It then uses IKEv1 Quick mode for phase 2 operations.

IKEv1 Main mode (Phase 1) uses three pairs of messages (making six in total) between peers:

 Pair 1 consists of the IKEv1 security policies configured on the device:

One peer (initiator) begins by sending one or more IKEv1 policies, and the receiving peer responds (responder) with its choice from the policies.

 Pair 2 includes DH public key exchange:

DH creates shared secret keys using the agreed upon DH group/algorithm exchanged in pair 1 and encrypts nonces (a randomly generated number) that begin life by first being exchanged between peers. They are then encrypted by the receiving peer and sent back to the sender and decrypted using the generated keys.

 Pair 3 is used for ISAKMP authentication:

Each peer is authenticated and their identity validated by the other using pre-shared keys or digital certificates. These

packets and all others exchanged from now on during the negotiations are encrypted and authenticated using the policies exchanged and agreed upon in pair

IKEv1 Aggressive mode (Phase 1) uses just three messages rather than the six used with Main mode. The same information is exchanged between peers. However, the process is abbreviated by carrying out the following actions:

 The initiator sends DH groups signed nonces (randomly generated numbers), identity information, IKEv1 policies, and so on.

 The responder authenticates the packet and sends back accepted IKEv1 policies, nonces, key material, and an identification hash that are required to complete the exchange.

 The initiator authenticates the responder’s packet and sends the authentication hash. 

VPN TERMINOLOGY IKE V1

IKEv1

IKEv1 provides a framework for the parameter negotiation and key exchange between VPN peers for the correct establishment of an SA. However, the actual processes of key exchange and parameter negotiation are carried

out by two protocols used by IKEv1:

 Internet Security Association and Key Management Protocol (ISAKMP)

 Oakley

ISAKMP takes care of parameter negotiation between peers (for example, DH groups, lifetimes, encryption [if required], and authentication). The process of negotiating these parameters between peers is required for the successful establishment of SAs. After an SA has been established, ISAKMP defines the procedures followed for correct maintenance and removal of the SA during connection termination.

Oakley provides the key-exchange function between peers using the DH protocol. DH is an asynchronous protocol, meaning each peer uses its own set of keys for communications establishment and operation between peers. However, the keys are never exchanged, providing a much higher level of security than synchronous protocols (DES, 3DES, and so on) that require both peers to use the same keys for operation. After both peers have established their shared communication path, they can proceed to exchange the keys used by the various synchronous protocols for authentication and encryption purposes.