Securing Generic Routing Encapsulation With Internet Protocol Security (IPSec) For Institutional Wide Area Networks

International Journal of Advance Foundation and Research in Computer (IJAFRC)

Volume 2, Issue 11, November - 2015. ISSN 2348 4853, Impact Factor 1.317

1 | 2015, IJAFRC All Rights Reserved www.ijafrc.org

Securing Generic Routing Encapsulation With Internet

Protocol Security (IPSec) For Institutional Wide Area

Networks Seth Alornyo1, Michael Asante2

I.C.T Directorate, Koforidua Polytechnic1

Dept. Of Computer Science,KNUST, Kumasi-Ghana2

[email protected], [email protected]

A B S T R A C T

The Internet is a worldwide, publicly accessible IP network. Due to its vast global proliferation, it

has become a viable method of interconnecting remote sites. However, the fact that it is a public

infrastructure has deterred most enterprises from adopting it as a viable remote access method

for branch and SOHO (Small Office Home Office) sites. The paper discusses Generic Routing

Encapsulation (GRE) over Internet Protocol security (IPSec) Virtual Private Network (VPN) as a

concept that describes how to create a private network over a public network infrastructure

while maintaining confidentiality and security. A simulation of two network nodes over an ISP

network was used to allow packet flow from one network node through the Internet Service

Provider (ISP) to a destination network. This operation allowed packets sent from a source host

through the ISPs network to a destination network to be critically examined. Packet loss, packet

length, Input/output (I/O) graph, service response time and flow graph are some parameters

used to examine packet flow from a source host to a destination host over the ISP network. Open

source Network Protocol Analyzer was used to capture traffic traversing over the Service

Provider network for analysis and interpretation. Analyzed data revealed that all Transmission

Control Protocol (TCP) packet session were encapsulated with Encapsulated Security Payload

(ESP)Protocol. The encapsulation makes it impossible for the service provider to detect multicast

traffic over the service providers network and also crackers inability to decrypt the encapsulated

data over the internet.

Keywords: GRE, ISP, TCP PACKETS, ESP, VPN.IPSEC

I. INTRODUCTION

GRE tunnels are stateless. Each tunnel endpoint keeps no information about the state or availability of

the remote tunnel endpoint. This feature helps Internet Service Providers (ISPs) provide IP tunnels to

customers who are not concerned about the internal tunneling architecture at the ISP end. Customers

then have the flexibility to configure or reconfigure their Internet Protocol (IP ) architecture but still

maintain connectivity. It creates a virtual point-to-point link to routers at remote points over an IP inter-

network. Generic Routing encapsulation (GRE) over Internet Protocol Security- Virtual Private Network

(IPSEC-VPN) and IP-based physical security are best practice to overcome the mentioned problems. GRE




over IPSEC-VPN is a scalable technology, so it is a good solution for wide area network communications.

It also reduces the routing lookups in which case communication between different nodes becomes

faster. Virtual private network technology is used in order to provide simple management, low cost and

more flexibility for establishing Wide Area Networks.

GRE is a tunneling protocol defined in [1] and [2]. It was originally developed by Cisco Systems for

creating a virtual point-to-point link to Cisco routers at remote points over an IP internetwork, [3].

GRE supports multiprotocol tunneling. It can encapsulate multiple protocol packet types inside an IP

tunnel. Adding an additional GRE header between the payload and the tunneling IP header provides the

multiprotocol functionality. IP tunneling using GRE enables network expansion by connecting

multiprotocol sub-networks across a single-protocol backbone environment. GRE also supports IP

multicast tunneling. Routing protocols that are used across the tunnel enable dynamic exchange of

routing information in the virtual network [3].

II. SECURING GENERIC ROUTING ENCAPSULATION (GRE)

The main function of GRE is to provide powerful yet simple tunneling. GRE supports any Open System

Interconnection (OSI) Layer 3 protocol as payload, for which it provides virtual point-to-point

connectivity. GRE also allows the use of routing protocols across the tunnel,[4].

The main limitation of GRE is that it lacks any security functionality as it only provides basic plaintext

authentication using the tunnel key, which is not secure, and tunnel source and destination addresses.

However a secure VPN requires characteristics such as;

Cryptographically strong confidentiality (encryption)

Data source authentication that is not vulnerable to man-in-the-middle attacks

Data integrity assurance that is not vulnerable to man-in-the-middle attacks and spoofing.

IPSec will provide the tunneling characteristics that GRE lacks:

Confidentiality through encryption using symmetric algorithms (for example, 3DES or AES)

Data source authentication using keyed-hash message authentication code (HMAC)(for example,

message-digest algorithm(MD5) or Secure Hash Algorithm(SHA-1)

Data integrity verification using HMACs

IPSec, however, was primarily intended to provide the above services to IP traffic only. Development of

Cisco IOS software is focused on removing the limitations, but multiprotocol support will always require

an additional tunneling protocol. Using crypto maps does not provide a virtual interface that you can

configure an address on, and a routing protocol can be run to dynamically exchange routing

information,[4] .




II. INTERNET PROTOCOL SECURITY (IPSEC)

III. Internet Protocol Security (IPSec) is an Internet Engineering Task force (IETF) standard[5],[6], explained

how a VPN can be configured using the IP addressing protocol. IPSec is not bound to any specific

encryption, authentication, security algorithms, or keying technology. IPSec is a framework of open

standards that spells out the rules for secure communications. IPSec relies on existing algorithms to

implement the encryption, authentication, and key exchange.

IPSec works at the Network Layer, protecting and authenticating IP packets between participating IPSec

devices (peers). As a result, IPSec can protect virtually all application traffic because the protection can

be implemented from Layer 4 through Layer 7. All implementations of IPSec have a plaintext Layer 3

header, so there are no issues with routing. IPSec functions over all Layer 2 protocols, such as Ethernet,

ATM, Frame Relay, Synchronous Data Link Control (SDLC), and High-Level Data Link Control (HDLC).

The IPSec framework consists of five building blocks.

The first represents the IPSec protocol. Choices include ESP or AH.

The second represents the type of confidentiality implemented using an encryption algorithm

such as Data Encryption Standard (DES), Tripple Data Encryption Standard (3DES), Advance

Encryption Standard (AES), or Software-Optimized Encryption Algorithm (SEAL). The choice

depends on the level of security required.

The third represents integrity that can be implemented using either MD5 or SHA [7].

The fourth represents how the shared secret key is established. The two methods are pre-shared or

digitally signed using Rivest-Shamir-Adleman(RSA).

The last represents the Diffie-Hellman (DH) algorithm group. There are four separate DH key

exchange algorithms to choose from including DH Group 1 (DH1), DH Group 2 (DH2), DH Group 5

(DH5), and DH Group 7 (DH7). The type of group selected depends on the specific needs.

IPSec provides the framework, and the administrator chooses the algorithms that are used to implement

the security services within that framework. By not binding IPSec to specific algorithms, it allows newer

and better algorithms to be implemented without patching the existing IPSec standards [8].

IV. RIVEST-SHAMIR-ADLEMAN (RSA)

Signatures - The exchange of digital certificates authenticates the peers. The local device derives a hash

and encrypts it with its private key. The encrypted hash is attached to the message and is forwarded to

the remote end and acts like a signature. At the remote end, the encrypted hash is decrypted using the

public key of the local end. If the decrypted hash matches the recomputed hash, the signature is genuine.




Each peer must authenticate its opposite peer before the tunnel is considered secure. Figure 3 depicts a

pictorial view of RSA signature exchange between a local host and a remote host [9].

V. IPSEC SECURE KEY EXCHANGE

Encryption algorithms such as Data encryption Standard (DES) , 3DES, and Advanced Encryption

Standard (AES) as well as the Message-Digest Algorithm(MD5) and Secure Hash Algorithm (SHA-1)

hashing algorithms require a symmetric, shared secret key to perform encryption and decryption. The

shared secret keys between the routers are shared through Internet Key Exchange (IKE) protocol or

Internet Security Association (SA) and Key Management Protocol (ISAKMP).Email, courier. or overnight

express can be used to send the shared secret keys to the administrators of the devices. But the easiest

key exchange method is a public key exchange method between the encrypting and decrypting devices.

The Diffie-Hellman (DH) key agreement is a public key exchange method that provides a way for two

peers to establish a shared secret key that only they know, even though they are communicating over an

insecure channel [5].

Variations of the DH key exchange algorithm are known as DH groups. There are four DH groups: 1, 2, 5,

and 7.

DH groups 1, 2, and 5 support exponentiation over a prime modulus with a key size of 768 bits,

1024 bits, and 1536 bits, respectively.

Cisco 3000 clients support DH groups 1, 2, and 5. DES and 3DES encryption support DH groups 1

and 2.

AES encryption supports DH groups 2 and 5.

The CerticommovianVPN client supports group 7.

Group 7 supports Elliptical Curve Cryptography (ECC), which reduces the time needed to generate

keys[10].

VI. IPSEC SECURITY PROTOCOLS

IPSec is a framework of open standards. IPSec spells out the messaging to secure the communications but

relies on existing algorithms. The two main IPSec framework protocols are AH and ESP. The IPSec

protocol is the first building block of the framework. The choice of AH or ESP establishes which other

building blocks are available:

Authentication Header (AH) - AH, which is IP protocol 51, is the appropriate protocol to use when

confidentiality is not required or permitted. It ensures that the origin of the data is either R1 or R2 and

verifies that the data has not been modified during transit. AH does not provide data confidentiality

(encryption) of packets. All text is transported unencrypted. If the AH protocol is used alone, it provides

weak protection [11].




Encapsulating Security Payload (ESP) - ESP, which is IP protocol 50, can provide confidentiality and

authentication. It provides confidentiality by performing encryption on the IP packet. IP packet

encryption conceals the data payload and the identities of the ultimate source and destination. ESP

provides authentication for the inner IP packet and ESP header. Authentication provides data origin

authentication and data integrity. Although both encryption and authentication are optional in ESP, at a

minimum, one of them must be selected [11]. Figure 1 illustrates the recommended security protocol

process. Figure 4 shows how IPSec protocol header is encapsulated in an IP header for communication

between two peers. The encryption header (IP HDR) and authentication protocol all encapsulates the

packet (data) before been transmitted over the internet to the remote router. This ensures a high level of

security payload for a packet to be transmitted over the internet.

Figure 1: ESP Header [12]

VII. INTERNET KEY EXCHANGE (IKE)

IKE is defined in It is a hybrid protocol, combining the Internet Security Association (SA) and Key

Management Protocol (ISAKMP) and the Oakley and Secure Key exchange Mechanism (SKEME) key

exchange methods. ISAKMP defines the message format, the mechanics of a key-exchange protocol, and

the negotiation process to build an SA for IPSEC. ISAKMP does not define how keys are managed or

shared between the two IPsec peers. Oakley and SKEME have five defined key groups. Of these groups,

Cisco routers support Group 1 (768-bit key), Group 2 (1024-bit key), and Group 5 (1536-bit key) [12].

To implement a VPN solution with encryption, it is necessary to periodically change the encryption keys.

Failure to change these keys makes the network susceptible to brute-force attacks. IPsec solves the

problem of susceptibility with the Internet Key Exchange (IKE) protocol, which uses two other protocols

to authenticate a peer and generate keys. The IKE protocol uses the DH key 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 [13].

IKE negotiates a security association (SA), which is an agreement between two peers engaging in an IPsec

exchange, and consists of all the parameters that are required to establish successful communication,

[14]

IPsec uses the IKE protocol to provide these functions:

Negotiation of SA characteristics

Automatic key generation

Automatic key refresh

Manageable manual configuration

A security association (SA) requires the following:

Internet Security Association and Key Management Protocol (ISAKMP): ISAKMP is a

protocol framework that defines the mechanics of implementing a key exchange protocol and

negotiating a security policy. ISAKMP can be implemented over any transport protoco [15] .

SKEME: A key exchange protocol that defines how to derive authenticated keying material with

rapid key refreshment.

OAKLEY: A key exchange protocol that defines how to acquire authenticated keying material. The

basic mechanism for OAKLEY is the DH key exchange algorithm[17]. IKE automatically negotiates

IPSec SAs and enables IPSec secure communications without costly manual pre-configuration. An

alternative to using IKE is to manually configure all parameters required to establish a secure

IPSec connection. This process is impractical because it does not scale, [16].

IKE includes these features:

Eliminates the need to manually specify all of the IPSEC security parameters at both peers.

Allows specification for a lifetime for the IPSEC Security Association (SA)

Allows encryption keys to change during IPSEC sessions

Allows IPSEC to provide anti-replay services

Permits certification authority (CA) support for a manageable, scalable IPSEC implementation

Allows dynamic authentication of peers [17].

VIII. INTERNET KEY EXCHANGE (IKE) PROCESS

To establish a secure communication channel between two peers, the IKE protocol executes two phases:

Phase 1 - Two IPSec peers perform the initial negotiation of SAs. The basic purpose of Phase 1 is

to negotiate IKE policy sets, authenticate the peers, and set up a secure channel between the

peers. It can be implemented in main mode (longer, initial contact) or aggressive mode (after

initial contact).

Phase 2 - SAs are negotiated by the IKE process ISAKMP on behalf of IPSEC. The second exchange

creates and exchanges the DH public keys between the two endpoints. DH allows two parties that




have no prior knowledge of each other to establish a shared secret key over an insecure

communications channel. The two peers run the DH key exchange protocol to acquire the keying

material that is needed by the various encryption and hashing algorithms upon which IKE and

IPSec will ultimately agree.

The purpose of IKE Phase 2 is to negotiate the IPSec security parameters that will be used to secure the

IPSec tunnel. IKE Phase 2 is called quick mode and can only occur after IKE has established the secure

tunnel in Phase 1. SAs are negotiated by the IKE process ISAKMP on behalf of IPSec, which needs

encryption keys for operation. Quick mode negotiates the IKE Phase 2 SAs. In this phase, the SAs that

IPSec uses are unidirectional; therefore, a separate key exchange is required for each data flow [14].

IX. METHODOLOGY

The method adopted in this paper is the structural design and the simulation of GRE tunnel network.

Graphical Network Simulator (GNS3) software was used to simulate the network with Cisco routers

running original Internetwork Operating System (IOS). GNS3 is software used to simulate complex

advances network. Network device configuration and penetration testing can be established when using

GNS3. Routers used in the simulation are Cisco routers. Comparative analysis and penetration testing

was done to check the security level of a GRE tunnels. Network Protocol Analyzer (wireshark) was used

to capture traffic traversing over the Service Providers network for further analysis and interpretation.

The following is the description of methods used to simulate the tunnel.

X. SIMULATED VIRTUAL LAB

In the simulated virtual lab, a site-to-site GRE tunnel VPN was configured. Once configured, the VPN

traffic between Router 1 on interfaces Router 1 and Router 2will be captured using wireshark for further

processing and analysis. Each of the simulated networks connects to an Internet Service Provider

(ISP).The Internet Service Provider only provides internet subscription to the client (institution).The

simulated network will provide institutional connectivity to remote sites over the internet. A study into

Service Providers network architectural design outline certain configuration parameters which allows

internet subscription from client and other IP services hosted by the Service Provider. In the process

architectural designs of Service Providers to were simulated to allow connectivity to client. Figure 7

illustrates the topological simulated design used to simulate the network architecture. The ISP has two

routers (ISP1 and ISP 2).ISP 1 connects router 1 and ISP 2 connects router 2. Router 1 and 2 are

considered as the edge routers and a client to the ISP. The ISP has a serial connection from ISP 1 to

ISP2.ISP 1 connects its edge router through a fast ethernet 0/0 interface and ISP2 connects its edge

router through a fast ethernet 0/0 interface. The ISP provides only internet access to router 1 and 2(edge

devices). A virtual cloud adaptor from figure 2 was used to virtualized the physical interface of a laptop




network adaptor to a Loopback adaptor interface. This virtualization enabled a laptop adaptor to be part

of the simulated network.

Figure 2: Simulated GRE over IPSec VPN tunnel Laboratory (authors)

XI. TYPE-STYLE AND FONTS

Configuration of Network Interface Addresses

A loopback and a tunnel interface was configured on router 1 and router 2 fast ethernet and the serial

interfaces. Fast ethernet 0/0 on router 1 was configured with the IP address 200.1.1.1 and a subnet

mask 255.255.255.0.The IP address configured on fast ethernet 0/0 is the out bound interface connected

to the service provider (ISP1) for internet access. Loopback interface 0 was configured with the IP

address 1.1.1.1 and a subnet mask 255.255.255.0.The loopback interface represent all internal hosts

connected to router 1.

Router 2 was also configured with the same parameters. The loopback interface was assigned the IP

2.2.2.2 and a subnet mask 255.255.255.0.Fastethernet 0/0 connects to Internet Service Provider (ISP2)

for internet access. Fastethernet 0/0 was assigned the IP 200.1.2.2 and a subnet mask 255.255.255.0.A

no shutdown command was issued on each of the configured interface to activate the interfaces.

A tunnel interface (tunnel 0) on router 1 and router 2 which will be used to transport GRE packets from

router 1 and router 2 was configured with the IP 12.12.12.1 and 12.12.12.2 respectively. Tunnel 0 was

virtualized with the physical interface fast ethernet 0/0 to transport packets flow through the physical

interface connected to the Internet Service Provider (ISP). The command tunnel source 20.1.1.1 and a

tunnel destination 200.1.2.2 was issued on both routers to connect the tunnel (tunnel 0) interface to the

physical interface to transport packets to the ISP. Configured tunnel 0 on router 1 and router 2 will be

the transport medium to forward all VPN traffic through the ISPs network.

ISP (Internet Service Provider) network as shown in figure 14was simulated with two routers, ISP1 and

ISP2. ISP 1 has two interfaces, interface fastethernet 0/0 and interface serial 1/0.Interface fastethernet




0/0 connects router 1 and interface serial 1/0 connects ISP 2. Fastethernet 0/0 was configured on ISP 1

router with the IP address 200.1.1.2 and a subnet mask 255.255.255.0,interface serial 0/0 also

configured with the IP address 200.11.22.1 with subnet mask 255.255.255.25.Each configured interfaces

were issued with the command no shut down to activate the interfaces.

ISP2 router has two interfaces,interface fastethernet 0/0 and interface serial 1/0.Interface fast ethernet

0/0 connects router 1 and serial 1/0 connects ISP2 serial interface 1/0. Interface fast ethernet 0/0 was

configured with the IP address 200.1.1.1 with a subnet mask 255.255.255.0 and interface serial 1/0 with

an IP address 200.11.22.2 subnet 255.255.252.A no shut down command was issued on each interfaces

to activate the interface.

Configuring Routing Protocol On Client Routers.

In order to maintain connectivity between remote networks, EIGRP was configured to route packets

between all networks in the diagram. All connected subnets were added into the EIGRP autonomous

system on every router. The command:

Router eigrp 1

Network 10.0.0.0

Network 12.0.0.0

Network 192.168.0.0

The command router eigrp 1 enables and activates Enhanced Interior Gateway Routing Protocol (eigrp)

under one (1)Autonomous System on router 1, the command network 10.0.0.0,12.0.0.0.192.168.0.0

advertises the network which is directly connected torouter 1, to the ISP1 network.

The command router eigrp1

Network 12.0.0.0

Network 2.0.0.0

Network 192.168.0.0

The command router eigrp 1 enables and activates Enhances Interior Gateway Routing Protocol under

one (1) Autonomous System on router 2, the command network 12.0.0.0, 2.0.0.0 , 192.168.0.0 advertises

the network which is directly connected to router 2, to the ISP2 network. Configuring autonomous

system enables EIGRP to be under one administrative control.

Configuring Routing Protocol On ISP Routers.

The simulated network has two routers which establish connectivity to both clients (router 1 and router

2). Routing Information Protocol version 2 (RIP,v2) was configured on the ISPs routers. This enables the

ISP router receives network advertisement from router 1 and router 2 network.ISP1 router has two main




interfaces, interface fast ethernet 0/0 and interface serial 0/1.Interface fast ethernet 0/0 is directly

connected to router 1and interface serial 0/1 connected to ISP2 network. ISP 1 router was configured

with the command;

Router rip version 2

Network 200.1.1.0

Network 200.11.22.0

ISP 2 router has two main interfaces, interface fastethernet0/0 and serial 0/1.Interface fast ethernet 0/0

is connects router 2 and interface serial 0/1 connects to ISP 2 network.

ISP 2 router was configured with the command;

Router rip version 2

Network 200.1.2.0

Network 200.11.22.0

Networks advertised on ISPs router are networks which are connected to interface fastethernet 0/0to

router 1 and interface serial 0/0 to ISP2 interface. Networks advertised on ISP2 router are networks

which connected to interface fast ethernet 0/0 to router 2 and interface serial 0/0 to ISP1.

A ping command was issued from router 1 to the various configured interface to verify that connectivity

across local subnets using the ping command was reachable. All ping commands sent were all successful.

Step one (1) to step three (3) are the processes used to simulate the GRE tunnel from router 1 through

the ISPs network to router 2.

XII. SECURING GENERIC ROUTING ENCAPSULATION (GRE) TUNNEL WITH IPSEC

Configuring IKE Policies

There are two central configuration elements to the implementation of an IPSec:

1. Implement Internet Key Exchange (IKE) parameters

2. Implement IPSec parameters

The exchange method employed by IKE is first used to pass and validate IKE policies between peers.

Then, the peers exchange and match IPSec policies for the authentication and encryption of data traffic.

The IKE policy controls the authentication, encryption algorithm, and key exchange method used for IKE

proposals that are sent and received by the IPSec endpoints. The IPSec policy is used to encrypt data

traffic sent through the VPN tunnel. Internet Security Association Key Management Protocol (ISAKMP)

was used to enable IKE on the client router (router 1).

The exchange method employed by IKE is first used to pass and validate IKE policies between peers.

Then, the peers exchange and match IPSEC policies for the authentication and encryption of data traffic.

The IKE policy controls the authentication, encryption algorithm, and key exchange method that is used




by IKE proposals that are sent and received by the IPSEC endpoints. The IPSEC policy is used to encrypt

data traffic that is sent through the GRE tunnel.

To allow IKE Phase 1 negotiation, an Internet Security Association and Key Management Protocol

(ISAKMP) policy was created and a peer association involving that ISAKMP policy was also configured.

An ISAKMP policy defines the authentication and encryption algorithms and hash function used to send

control traffic between the two VPN endpoints. When an ISAKMP security association has been accepted

by the IKE peers, IKE Phase 1 has been completed. The command configured on router 1 must match the

command configured on router 2. Router 1 and router 2were configured with the commands:

R1(config)# crypto isakmp policy 5

R1(config-isakmp)# authentication pre-share

R1(config-isakmp)# encryption aes 256

R1(config-isakmp)# hash sha

R1(config-isakmp)# group 5

R1(config-isakmp)# lifetime 3600

R2(config)# crypto isakmp policy 10

R2(config-isakmp)# authentication pre-share

R2(config-isakmp)# encryption aes 256

R2(config-isakmp)# hash sha

R2(config-isakmp)# group 5

R2(config-isakmp)# lifetime 3600

The different priority numbers refer to how secure a policy is. The lower the policy number is, the more

secure a policy is. Routers will check to verify which security policies are compatible with their peer,

starting with the lowest numbered (most secure) policies.

Configuration of Router Pre-Share Keys

Since I chose pre-shared keys as our authentication method in the IKE policy, I configure a key on each

router corresponding to the other VPN endpoint. These keys must match up for authentication to be

successful and for the IKE peering to be completed. For simplicity Iused the key MYKEY. Router 1 and

router 3 were configured with the command:

R1(config)# crypto isakmp key MYKEY address 200.1.2.2

R2(config)# crypto isakmp key MYKEY address 200.1.1.1

Configuration of Router IKE Phase two (2)

Router 1 and router 2 was configured with the command:

R1(config)# crypto ipsec transform-set LABesp-aes 256 esp-sha-hmac ah-sha-hmac

R2(config)# crypto ipsec transform-set LABesp-aes 256 esp-sha-hmac ah-sha-hmac.

R1(config-crypto-map)# match address KNUST




IKE phase 2 is configured using the IPSec transform set. TheIPSec transform set is another crypto

configuration parameter that routers negotiate to form a security association. Routers will compare their

transform sets to the remote peer until they find a transform set that matches exactly.

Configuration of the Interesting Traffic

Now that most of the encryption settings are configured, extended access was defined lists to tell the

router which traffic to encrypt. Like other access lists used to define interesting traffic rather than

packet filtering, permit and deny do not have the usual meaning of a filtering access list. A packet which is

permitted by an access list used for defining IPSec traffic will get encrypted if the IPSec session is

configured correctly. A packet that is denied by one of these access lists will not be dropped; it will be

sent unencrypted. Also, like any other access list, there is an implicit denialat the end, which in this case

means the default action is not to encrypt traffic. If there is no IPsec security association correctly

configured, then no traffic will be encrypted, but traffic will be forwarded as unencrypted traffic. Router 1

and router 2 were configured with the following command:

R1(config)# ip access-list extended KNUST

R1(config)# permit ip 12.12.0.0 0.0.255.255 12.12.0.0 0.0.255.255

R1(config)# ip access-list extended KNUST

R1(config)# permit ip 12.12.0.0 0.0.255.255 12.12.0.0 0.0.255.255

In this configuration, the traffic l want to be encrypted is the GRE tunnel traffic which was configured

with the IP address 12.12.12.0/24.The access-list was configured with a name KNUST to only allow traffic

going through the GRE tunnel 0 encrypted with IPSec.

Configuration And Application of Crypto Map

Router 1 and router 2 were configured with the following commands:

R1(config)#crypto map VPN_MAP 15 ipsec-isakmp

R1(config-crypto-map)# set peer 200.1.2.2

R1(config-crypto-map)# set transform set LAB

R1(config-crypto-map)# lifetime 900

R2(config)#crypto map VPN_MAP 15 ipsec-isakmp

R2(config-crypto-map)# set peer 200.1.1.1

R2(config-crypto-map)# match address KNUST

R2(config-crypto-map)# set transform set LAB

R2(config-crypto-map)# lifetime 900

A crypto map is a mapping that associates traffic matching an access list (like the one I created earlier) to

a peer and various IKE and IPsec settings. Crypto maps can have multiple map statements, so you can

have traffic that matches a certain access list being encrypted and sent to one IPsec peer, and have other

traffic that matches a different access list being encrypted towards a different peer. After a crypto map is

created, it can be applied to one or more interfaces. The interface(s) that it is applied to should be the




one(s) facing the IPSec peer.The name of the configured crypto map is known as VPN_MAP. This name

will be applied to the interface to secure VPN traffic.

Applying Cryptographic Map To An Interface

The interface that need to be secured is the GRE tunnel interface. The cryptographic map was applied to

the tunnel (tunnel 0) interface to secure traffic from router 1through ISPs network to router 2. Router 1

and 2 were configured with the following commands:

R1(config)# interface tunnel 0

R1(config)#crypto map VPN_MAP

R2(config)# interface tunnel 0

R2(config)#crypto map VPN_MAP

XIII. RESULT AND ANALYSIS

Verification Of Internet Protocol (IP) VPN Tunnel Interfaces

The command show ip interface brief was issued on router one (1) to verify IP address configuration

parameters and interface status, figure 8 depict the output of the command.

Figure 3 depicts the connectivity between router one (1) and the ISPs network. Fastethernet 0/0 with an

IP address 200.1.1.2 connects to the ISP two (ISP 1) network which shows that the interconnectivity

between the client router and the service provider is active (up) whiles the protocol supporting the

interface is also active (up).Interface tunnel 0 configured for Generic Routing Encapsulation (GRE) over

Internet Protocol Security Virtual Private Network (GRE/IPSec-VPN) is also active (up).Clients connected

to router one (1) can tunnel through (tunnel 0) the ISPs network to router two (2).Hence the tunnel

connectivity between router one (1) and router two (2) has being established through the tunnel

interfaces.

Figure 3: Simulated GRE tunnel interface verification

XIV. SECURED GRE OVER IPSEC TUNNEL OPERATIONS STATUS




A continuous Internet Service Control Messaging Protocol (ICMP), service command ping 12.12.12.2

was executed on a laptop with an IP address 19.168.1.2 attached to the Local Area Network connected to

router 1, through the ISP network over to the destination tunnel network on router 2.

A web server hosted on router 2 was also accessed by the laptop with an IP address 192.168.1.2

connected to the simulated network. All Hypertext Transmission Protocol (HTTP) traffic were sent over

the VPN tunnel (tunnel 0).A Network Protocol Analyzer software (wireshark) was used to capture

packets moving through the ISP network to router 2. Figure 4 displays the outcome of the output

command from router 1 through the ISP network to router 2.

Wireshark was used to capture traffic between the clients connected to router one (1) through the ISPs

network. The highlighted session in green depicts packet sent from a source tunnel network with an IP

address 200.1.2.2 to a destination network 200.1.1.1 has being secured by the Encapsulation Security

Protocol (ESP).The highlighted session in red is the interior routing protocol configured on the ISP

network to exchange hello packets among the router for a best path selection. Any conversation

between the two routers through the tunnel network traversing over the ISPs network cannot be seen or

intercepted by a third party.ESP protocol are the only packets being exchanged on the ISPs network.ESP

encapsulates all TCP packets before transporting the packets through the tunnel network (tunnel 0)

Figure 4: Captured GRE over IPSec-VPN Packets using Wireshark

Figure 5 illustrates the analysis of packet captured over the ISP network. Traffic sent over the VPN

tunnel includes web traffic (HTTP:80), IP traffic, User Datagram Protocol (UDP),Transmission Control

Protocol (TCP) and Ethernet broadcast address (ffffffffff).




Graph 1 has the color black which has an IP filter witha styleline, Graph 2 has the color red which has a

TCP session filter with a style Fbar,graph 3 has the color green which has an HTTP filter with a style

impulse, graph 4 has the color blue which has a User Datagram Protocol (UDP) filter with a style Fbar,

and graph 5 has the pink color which has a broadcast IP (ffffffff) with a style dot.

The output of figure 10 indicates that only IP and UDP traffic traversed over the VPN tunnel.TCP and

HTTP traffic were not captured within the tunnel.This analysis prove that all HTTP requests and TCP

sessions were all encapsulated by the IPSec protocol (ESP) within the IP(Internet Protocol) header,which

means efforts to capture any TCP or HTTP traffics will prove futile because TCP packets have being

encapsulated within the tunnel by Encapsulated Security Payload (ESP), hence TCP traffics cannot be

captured over the tunnel network.

Figure 5: Simulated IPSEC-VPN Input/output (I/O) graph

XV. CONCLUSION

The use of GRE over IPSec VPN technology can further be used to establish Network connectivity instead

of establishing Wide Area Connection through satellite medium or outsourced to service providers.

Internet Protocol Security (IPSec) VPN(Virtual Private Network) mainly supports unicast traffic but a

simulated study on this paper revealed that multicast traffic can operate securely over the Generic

Routing Encapsulation (GRE) tunnel network when secured with Internet Protocol Security (IPSec).HTTP

and any other TCP packets can securely be sent through a secured VPN tunnel without the Service

provider knowing the type of packets being sent across their network because the service provider only

see Encapsulated Security Payload (ESP) packets on their network but not the content of the ESP packets

traversing over their network.




XVI. FUTURE WORK

The future work will involve the detection of penetration attempts to private and public network

infrastructure and the prescription of solutions on how to prevent such attacks.

XVII. REFERENCES

[1] Hanks S., Li, T., Farinaci,P. Traina, D Generic Routing Encapsulation over IPv4 networks,Cisco

Systems, October 1994,rfc1702

[2] Hanks S., Li, Farinaci,P. Traina, D Generic Routing Encapsulation over IPv4 networks Juniper

Networks,March 2000.rfc2784

[3] Farinacci, D., Traina, P., Hanks, S., & Li, T. (1994).Generic routing encapsulation (GRE).retrieved

from http://xml2rfc.tools.ietf.org/html/rfc1701.

[4] Christian, P. Generic Routing Encapsulation over CLNS Networks.RFC-3147,July 2001.retrieved

from http://www.hjp.at/doc/rfc/rfc3147.html.

[5] Kent, S., & Atkinson, R. (1998). Security architecture for the internet protocol retrieved from

http://www.hjp.at/doc/rfc/rfc2401.html.

[6] Thayer, R., Doraswamy,Glenn, R IP Security Roadmap Network Working Group,

November,1998 ,rfc2411

[7] Madson, C., & Glenn, R. (1998) The use of HMAC-MD5-96 within ESP and AH,1998 retrieved

from http://tools.ietf.org/html/rfc2403.

[8] Karn, P., Simpson, W. A., & Metzger, P.). The esp des-cbc transform 1995. retrieved from

http://tools.ietf.org/html/rfc1829.

[9] Cisco System, Cisco Annual Security Report, 2014,page 68, retrieved from

https://www.cisco.com/web/offer/gist_ty2_asset/Cisco_2014_ASR.pdf.

[10] Prafullchandra, H., &Schaad, J. (2000). Diffie-Hellman proof-of-possession algorithms).

[11] Atkinson, R., & Kent, S. (1998). IP authentication header,retrieved from

http://xml2rfc.tools.ietf.org/html/rfc2402.

[12] Atkinson, R., & Kent, S. (1998). IP encapsulating security payload (ESP),retrieved from

http://tools.ietf.org/html/rfc2406

[13] Harkins, D., & Carrel, D. (1998). The internet key exchange (IKE). RFC 2409, november.ISO/IEC

17799, (2005) Information technology -- Security techniques -- Code of practice for information

security management.

[14] Yang, W., Li, C. D., Chang, G. R., Yao, Y., &Shen, X. M. (2011). The Effect of P 2 P - Based Work

Propagation in an IPv6 Internet. Procedia Engineering, 15, 3637-3641.

[15] Simpson, W. A. (1999). IKE/ISAKMP considered harmful. USENIX; login, 24(6).

[16] Matthews, G. A., & Feinstein, B. S. (2007). The Intrusion Detection Exchange Protocol

(IDXP).retrieved from http://tools.ietf.org/html/rfc4767.




[17] Orman, H., The OAKLEY Key Determination Protocol Department of Computer Science.

university of Arizona,Novemeber,1998,(rfc2412).

Securing Generic Routing Encapsulation With Internet Protocol Security (IPSec) For Institutional Wide Area Networks

Documents