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.

VPN TERMINOLOGY KEYS

Symmetric and Asymmetric Key Algorithms:

Before these protocols can establish a secure communications tunnel (VPN) between two endpoints, they generate, exchange, and use keys as a means to authenticate/encrypt the information used to create a secure tunnel that is sent between both parties.

Symmetrical Encryption:

One key to encrypt as well as Decrypt

Symmetrical Encryption Algorithm:

DES     Digital Encryption Standard 56bit

3DES   Triple DES 168bit

AES     Advance Encryption Standard 128 , 192 , 256 bit

IDEA   International Data Encryption Algorithm

Asymmetric Encryption:

One key to encrypt and second key to decrypt, one key is called private key which is keep private and the second key is called as public key which is distributed. The data encrypted by the public key can only be decrypted by the private key and vice-versa. when we need to create session for any bank transaction we use Asymmetrical encryption as its heavy and secure whereas when we need to do file transfer or any data transfer we use symmetrical encryption.

Public/private key pairs commonly use digital certificates as a method of key distribution. Internet shopping and other sites often use SSL/TLS as a way to secure transactions on their websites. In this case, you usually receive a copy of the server’s digital certificate. Within the certificate is a copy of the server’s public key. By using this public key, the host and server can set up a secure communications path (because the server has a corresponding private key). Examples of asymmetric key algorithms include the following:

Rivest, Shamir, and Adleman (RSA)

Diffie-Hellman (DH)

VPN TERMINOLOGY IPSEC

IPsec

IPsec is composed of a collection of underlying protocols that together provide the overall operation of parameter negotiation, connection establishment, tunnel maintenance, data transmission, and connection teardown.

Three protocols are used in the IPsec architecture to provide key exchange in addition to the integrity, encryption, authentication, and antireplay features discussed earlier:

 IKEv1 or IKEv2 is used by IPsec for the exchange of parameters used for key negotiation, the exchange of the derived authentication/encryption keys, and overall establishment of security associations (SA) .

 Encapsulating Security Payload (ESP) provides a framework for the data integrity, encryption, authentication, and antireplay functions of an IPsec VPN.

 Authentication Header (AH) provides a framework for the data integrity, authentication, and antireplay functions. (No encryption is provided when using AH.)

FIRST BLOGG

I am started my blogg now by taking the blessings of my IDOL, my inspiration my lord.