IPsec VPN connection models: Site-to-site and client-to-site

Posted: by SamDobs in Labels:

Article from www.searchenterprisewan.com

In the first article in this series on implementing VPN gateways using Cisco routers, we reviewed the basic protocols and process involved with establishing an IPsec connection between two peers. Now let's take a look at the basic IPsec VPN connection models. While the IOS supports a variety of IPsec implementations, essentially all IPsec VPNs are implemented using one of two basic forms: site-to-site and client-to-site VPNs.

Site-to-site VPN
In the site-to-site VPN configuration above, each node is connected to a discrete network, separated by other unsecured or public networks. Depending on the security requirements for these network segments, it could be the case that end nodes on the networks are not able to exchange data unless the VPN is in place. This type of VPN configuration is known as a "closed" site-to-site network topology. Alternatively, the end nodes connected to the segments could have the ability to freely exchange data, utilizing other networks to relay the data back and forth. This data exchange, however, is unsecured. In this kind of network environment, IPsec can be employed to secure some or all of these data exchanges. This type of VPN configuration is known as an "open" site-to-site network design. The key point is that in either case, IPsec is implemented using gateways that secure the data exchanges. And, more importantly, the securing of the data exchanges is done without any knowledge of the end nodes connected to the networks being secured.

Client-to-site VPN
In the case of a client-to-site topology, the models "open" and "closed" still hold true. Connectivity between nodes separated by (or adjacent to) the IPsec gateway may or may not be restricted. In an open client-to-site topology, the network path between the end node and the IPsec gateway is secured. In a closed client-to-site topology, the path between the end node and gateway is secure. But data exchanges between the client node and nodes adjacent to (i.e., behind) the IPsec gateway is only possible if a connection to the IPsec gateway exists.

In both topologies, the relationship between the client node and the IPsec gateway is architecturally similar to a traditional PSTN remote-access dial network. The end node establishes a connection to the gateway and the two communicate as IPsec peers. Additionally, the gateway provides the end node an IP identity that gives the client node IP network access to other end nodes directly connected (via VPN) and adjacent to the IPsec gateway. The communications between the client end node and the gateway is secured with IPsec. Communications between the client end node and other end nodes adjacent to the IPsec gateway, however, are not secured.
When developing IPsec solutions, it is important to keep in mind that the IPsec protocol suite is geared to secure IP communications. The construct of the VPN is commonly perceived today as the connecting of private (secured) networks using public (unsecured) ones as the connectivity substrate. That is not solely what IPsec was developed to support. IPsec can also be used to enhance the security within private networks, using many of the same solution strategies used to secure data over public networks. That's a thought to keep in mind as we examine different IOS IPsec configurations, all of which start with the configuration of the router's ISAKMP policy using IKE.

IPSec Protocol Details

Posted: by SamDobs in Labels:

Article from www.searchenterprisewan.com

This article is first in a series on implementing VPN gateways using Cisco routers. The Cisco IOS implementation of the IPSec (Internet Protocol Security) suite is an open-standards based framework that provides network administrators with a variety of options to deliver secure IP network communications.
The IPSec framework is a suite of IETF standards that provides for secure transmission of data over unsecured networks, for example the Internet. IPSec provides protocols to secure communications at the Network Layer along with a mechanism for exchanging identity and security protocol management information. The IPSec suite was developed to address some of the fundamental security flaws of IPv4. IP version 4 was built to share information between computers running both like and dislike operating systems over a packet switched network. It could be said that in the 1970s, when TCP/IP was developed, security was not as much of an issue as actually getting the packets to where they belonged. However, when TCP/IP grew from supporting data exchange between a couple hundred systems to a global network of millions of computers, these vulnerabilities became of some concern.
IPSec protects against security vulnerabilities
There are three major IP security vulnerabilities. Two of this circle around the fact that IP data transmissions between hosts are dependent on each host having a universally unique IP address.
The first is IP spoofing. In order to trust received information, the origin of the information must also be trusted. IP packet delivery is handled on a hop-by-hop basis. An attacker with knowledge of the network topology can disable a system and assume or "spoof" its identity. Since most IP security paradigms revolve around a host's IP address, IP spoofing is problematic for network administrators who need to exchange data securely.
Session hijacking is IP spoofing taken to the next level. Here the attacker disables the spoofed host and assumes active network sessions. This is a far more sophisticated attack than assuming a host's IP identity, as it also depends on software vulnerabilities in order to be successfully executed.
The third vulnerability, traffic sniffing, is endemic to packet switched networks, where the packets are visible to all the network nodes that are connected to the transport medium. Routers, switches, and firewalls all have visibility into packets that pass through these gateways, regardless of the transmission medium. While this makes these devices great for passively filtering IP traffic, it also makes them great places to collect IP packets and extract the data contents.
IPSec protocol details
To address these vulnerabilities, the IETF has developed different protocol standard definitions. These standards provide four basic services:

  1. Data transmission encryption: The originating host can encrypt packets prior to transmission
  2. Data integrity validation: The receiving host can authenticate each packet sent to ensure the original data that was transmitted was received.
  3. Data source authentication: The originating host can mark packets, so the receiver can authenticate them.
  4. Data state integrity: The originating and receiving hosts can mark packets, so any re-transmission of the data stream can be detected and rejected (also known as anti-replay).
IPSec implementations use a number of different security protocols to provide these services. From a not so high level, these protocols can be broken down into two different camps: packet protocols and service protocols. The packet protocols are used to provide data security services. There are two IPSec packet protocols: Authentication Header (AH) and Encapsulating Security Payload (ESP). There are a number of service protocols, but the primary one is the Internet Key Exchange protocol (IKE). Below is a basic overview of the protocols in the IOS's IPSec implementation.
Authentication Header: AH, defined in IETF RFC 2402, supports IPSec data validation, authentication and integrity services. It does not support data encryption. AH is typically implemented by itself, but can be implemented alongside ESP. AH is used when we only need to ensure with whom we are exchanging data. You might ask why one would use AH, because it does not support data encryption. Look at it this way: If data encryption is supported by the application, there is no need for additional data encryption. AH is "lighter" in terms of processing overhead, compared to ESP, so it is easy to employ on lower end routers.
Additionally, in comparison to ESP, AH provides greater IP layer security. AH secures the IP packet by generating hash signature data for all of the IP packet information that is not modified in transit. The AH security data is stored in the 32-bit long AH header, which is installed between the IP datagram header and the Layer 4 header. Because AH works by "securing" the IP Packet, AH cannot be employed in network environments where Network Address Translation (NAT) is used. AH operates in either transport or tunnel mode. In most cases tunnel mode is employed and the original IP packet is encapsulated in a new AH secured IP packet. This new packet contains a new IP header (with the destination address of the remote IPSec peer gateway) and the AH header, followed by the original IP packet and Layer 4 datagram. IANA (Internet Assigned Numbers Authority) has assigned ESP the protocol ID of 51.
Encapsulating Security Payload: ESP, defined in IETF RFC 2406, supports IPSec data encryption, validation, authentication and integrity services. ESP can be implemented alone or with AH. While the AH header is pre-pended to the data payload portion of the IP packet, ESP encapsulates the entire data portion of the IP packet with a header and trailer. The ESP header contains the security and sequencing information. The ESP trailer contains variable padding and (if desired) authentication data. ESP's encapsulation of the original ULP data and its encryption requires more router processing resources than AH. Additionally, ESP processing also requires that 1500-byte Layer 4 datagrams be fragmented to support the additional security payload data. Like AH, ESP also supports transport and tunnel operational modes, but almost all vendor implementations implement ESP exclusively in tunnel mode. The ESP RFC does not define what protocols should be used to encrypt the data. Cisco IOS supports 56-DES, 3DES and AES. Other implementations have implemented Blowfish and IDEA as well. IANA has assigned ESP the protocol ID of 50.
Internet Security Association and Key Management Protocol (ISAKMP) and Internet Key Exchange: These provide the framework and processes for implementing IPSec VPN service negotiation. ISAKMP is defined in IETF RFC 2408. IKE is defined in IETF RFC 2409. ISAKMP defines the schemes, syntax and procedures for creating and deleting authentication keys and security associations (SAs). IPSec peers use SAs to keep track of the different aspects of the security services policies negotiated between different IPSec peers. This includes:

  • ESP encryption algorithm
  • Authentication protocol
  • Key information
  • Key lifetimes
  • SA lifetimes
  • AH authentication algorithm
SAs are negotiated between peers when the peer connection is first established. During the establishment (and subsequent re-establishment), each peer assigns the SA it has negotiated with the other its own security parameter index (SPI) number. SPIs are exchanged between peers and used to identify packets. When a peer receives an IPSec packet, it examines the SPI, looks it up in the SPI database, finds the corresponding SA, and then processes the packet according to the rules in the SA. A key point to remember about ISAKMP is that it is independent of the key management protocol, the encryption and authentication used to implement IPSec. It just defines the rules it does not execute them. That is what IKE is for.
IKE is a hybrid of the Oakley key determination protocol and SKEME key exchange protocol. The IKE protocol manages the IPSec security associations within the ISAKMP of IPsec peers. IKE is a protocol available to ISAKMP; they are not one and the same. IKE is the mechanism that establishes the IPSec "connection" between IPSec peers. This requires the negotiation of:

  • Authentication algorithms: IKE uses Diffie-Hellman to establish shared secret session keys over the unsecured network transport.
  • Confidentiality algorithms: IKE manages the negotiation of the security protocols the peers will use, be they AH, ESP, or AH and ESP in combination.
  • Hash algorithms: IKE uses hash algorithms to authenticate packet data.
  • Identification keys: IKE supports the use of pre-shared keys, RSA keys (or nonces), digital certificates and Extended Authentication (Xauth) to support identity management.
IKE operates in three modes: main, aggressive, and quick. The main and aggressive modes both achieve the same end, establishing the initial phase or phase 1 IKE SAs. The phase 1 SA bootstraps the IKE process. Once the phase 1 negotiation is completed, quick mode can be used for phase 2 IKE operations that allow for the full SA negotiation and refreshing of SA information when the SA has expired.
The differences between main, aggressive, and quick modes have to do with the degree of security needed and the number of messages exchanged. Main mode uses six (three from the initiator and three from the responder) message exchanges. Main mode commences with the connection initiator proposing a negotiation SA to secure the Diffie-Hellman key exchange. Once the negotiation SA has been established, the Diffie-Hellman keys for quick mode authentication, IKE authentication and SA encryption are generated and exchanged and identity management is completed.
Aggressive mode starts with the initiator generating a Diffie-Hellman key, purposing a phase 1 SA and the peer's identity. Then the responder replies with an SA and identity data, with the initiator completing the process with verification data. The entire aggressive mode exchange is done without a negotiation SA, leaving all data exchanged unencrypted. So although the same information is exchanged with both phase 1 modes, one is more secure and the other faster. And although quick mode utilizes the same number of message exchanges as aggressive mode, quick mode does rely on the identity and security integrity established during the phase 1 negotiation.
By now it should be clear that with IPSec everything is negotiated. The security services supported between IPSec peers are negotiated between the two peers when communication is initiated. Depending on the type of peer (i.e., gateway vs. host), there may be a number of IKE policies supported or only one. When a session is initiated, the connecting peer will send all of its supported IKE policies. The remote peer will then respond with a match by comparing the purposed policy with its highest priority policy and subsequent policies in descending order. Only the IPSec services that can be supported by both peers are utilized.
For example, peer Alpha can support data encryption and integrity validation services, but peer Zeta only supports data encryption services. Both Alpha and Zeta need to have a common IKE policy. In this case, Alpha would need to have two different IKE policies: a policy that supports data and integrity services and another policy that supports only data services. In order for Alpha and Zeta to communicate, only data encryption services will be utilized. If Alpha only has a single IKE policy that supports data and integrity, then IKE will terminate the negotiation and the peers will not establish an IPSec connection.

Definition : IPSec (Internet Protocol Security)

Posted: by SamDobs in Labels:

IPSec (Internet Protocol Security) is a framework for a set of protocols for security at the network or packet processing layer of network communication. Earlier security approaches have inserted security at the Application layer of the communications model. IPsec is said to be especially useful for implementing virtual private networks and for remote user access through dial-up connection to private networks. A big advantage of IPsec is that security arrangements can be handled without requiring changes to individual user computers. Cisco has been a leader in proposing IPsec as a standard (or combination of standards and technologies) and has included support for it in its network routers. IPsec provides two choices of security service: Authentication Header (AH), which essentially allows authentication of the sender of data, and Encapsulating Security Payload (ESP), which supports both authentication of the sender and encryption of data as well. The specific information associated with each of these services is inserted into the packet in a header that follows the IP packet header. Separate key protocols can be selected, such as the ISAKMP/Oakley protocol.

Are You a TAPaholic?

Posted: by SamDobs in

BGP Path Selection

Posted: by SamDobs in Labels:


Just while ago posted Flowchart which explains about how a Route is installed in RIB?
In this post I am sharing BGP Path Selection Chart.

PS: Image shared from http://rbcciequest.wordpress.com


How a Route is Installed in Routing Information Base (RIB)?

Posted: by SamDobs in Labels:


Ever wondered how a Route is installed in RIB?
Came upon a wonderful article by Ruhaan from http://routing-bits.com
Below is the flowchart:

PS: I am not taking any credit for the above chart. It has been prepared by Ruhaan. 

What do you think??



How to Detect Wrong AS & Mismatch K Values in EIGRP.

Posted: by SamDobs in Labels:

Well... Some time back a friend ask me whether we can detect an AS that has been configured on the Neighboring Router without actually looking at the Configuration?
I tried every "DEBUG" that is available on Cisco Routers to find about it but wasn't able to.
While surfing I came upon this wonderful article by fellow Blogger Deepak Arora which clearly explains the above mentioned Topic.
Below is the link to his Blog... Please visit his wonderful blog as there are many Interesting articles there..
Go have a look and tell me What you think??

:) Peace

Welcome to my Virtual Hangout..

Posted: by SamDobs in

I will be regularly updating my Blog with all the New Technology developments that are happening around the World.
Please do write me back if you have any Suggestions, Feedback or some exciting stuff to Share.
So as they say "Let's begin the Journey"