Security of Dynamic and Multipoint Virtual Private Network

8 downloads 545 Views 943KB Size Report
sites, securely. Dynamic and Multipoint Virtual Private Network, stands for ..... SPOKE routers [fig.4], the subnet address of DMVPN cloud is. 172.16.1.0/24 the ...
International Journal of Computer Science and Information Security (IJCSIS), Vol. 14, No. 7, July 2016

Security of Dynamic and Multipoint Virtual Private Network Ayoub BAHNASSE, Najib EL KAMOUN

DMVPN technology deals with this issues by using: mGRE protocol, considered as an extension of GRE protocol, which allows the creation of multiple tunnels between routers using a single tunnel interface. NHRP protocol [6], this protocol allows to translate a logical address (IP address of tunnel interface) to an associated public IP address. Dynamic routing protocols such as RIP [7], EIGRP [8], OSPF [9] or others allows the establishment of tunnels and the routing of users data. To rely on various protocols is an important point, because the independence of these latters ensures a very high of modularity level, for example the three phases of NHRP protocol [10] through which the design of DMVPN architecture can take several forms; HUB to SPOKE, basic SPOKE to SPOKE or extended SPOKE to SPOKE connections, other protocols remains relatively intact. Although multiple protocols exploitation ensures a high level of modularity and flexibility, on the other hand, as a balance, increases vulnerabilities of the whole network, obviously, vulnerabilities of each DMVPN protocol, these vulnerability can allow to perform several attacks: • Aiming to prevent communication between DMVPN network equipment; • Aiming to re-route all communications to hacker computer; • Aiming to harm servers of network by a falsified or burst records; • Allowing the hacker to infiltrate on corporate network as a legitimate equipment and access to confidential resources; • Allowing the decrypt of a part of messages supposed to be protected by encryption mechanisms.

Abstract—Nowadays, the solutions of virtualizing network infrastructure have become one of the most preoccupations of small, medium and large enterprises. These solutions make the extension of companies’ sites possible and easier with a transparent and flexible manner. these solutions allow also the remote access to personal data, stored on several distributed sites, securely. Dynamic and Multipoint Virtual Private Network, stands for DMVPN, is considered as a main component of these solutions, this technology involves a suite of protocols for a smooth functioning, such as : IPsec, mGRE and NHRP. Nonetheless, even the considerable security and modularity level of DMVPN solution, this latter suffers from several security issues linked to each components’ protocol, which might threaten availability, confidentiality, authentication and integrity of communications. In this article, we will discuss the key vulnerabilities related to DMVPN technology and the possible countermeasures. Index Terms— DMVPN, Security, Vulnerability, IPsec, NHRP, mGRE.

I. INTRODUCTION

D

MVPN technology [1] is considered as one of the better solutions that an enterprise can deploy to fully connect their several sites taking into account the need to ensure confidentiality, authentication and the integrity of exchanges. For these reason, companies tends to use IPsec standard [2], which, among others, ensures the confidentiality, integrity and authentication of data between two sites in depending on the used protocol : ESP [3] or AHp [4]. Via IPsec tunnels, only IP unicast packets will allowed and secured. To compensate for this shortcoming, the GRE protocol [5] can be deployed as the first encapsulating protocol, this latter supports unicast, multicast and broadcast messages in addition to IP, IPX and AppleTalk protocols, but doesn’t ensure any security fundament, for this reason companies can protect GRE packet with IPsec protocol. Unfortunately GRE allows the deployment of site to site tunnels, which implies a daunting task, if not impossible, to interconnect a high numbers of sites, having dynamic assigned IP addresses.

In this article, we will discuss the vulnerabilities of the DMVPN network allowing to perform above attacks by exploiting the weakness of each protocol component (IPsec, mGRE and NHRP). In the second section we will study some IPsec vulnerability and possible security measures to prevent against them, in third and fourth sections, we will do the same, respectively for mGRE and NHRP protocols.

II. LIMITATIONS OF IPSEC PROTOCOL IPsec, defined on RFC 2401, is protocol of network layer of OSI model, a complement not a successor of IP protocol, it was originally developed as part of the future IPv4 protocol (IPv6).

This paper was submitted to review on 2 July 2016. Ayoub BAHNASSE is with the Faculty of Sciences, University Chouaib DOUKALI, El Jadida, Morocco (e-mail: [email protected]). Najib EL KAMOUN is with the Faculty of Sciences, University Chouaib DOUKALI, El Jadida, Morocco (e-mail: [email protected]).

100

https://sites.google.com/site/ijcsis/ ISSN 1947-5500

International Journal of Computer Science and Information Security (IJCSIS), Vol. 14, No. 7, July 2016

IPsec is a tunneling protocol, allows companies to protect against several attacks by offering different level of security such as: confidentiality, integrity, authentication and antireplay attacks. IPsec constitutes a main protocol of DMVPN technology, despite its high security level, it remains vulnerable to certain types of attacks aiming to compromise the availability of DMVPN tunnels and to provide additional latencies that can make some transported flows unusable.

notification errors messages and management messages. The ICMP protocol can be used as an attack vector against IPsec threatening: • The performance of the entire network by reducing or increasing the path MTU; • The response delay of some applications. Before proceeding to the delivery of the frames, equipment should detect the PMTU (MTU size of the smallest route to take) this detection can be done by two different mechanisms PMTUD [23] and PLPMTUd [24]. In order to detect PMTU using PMTUD mechanism, source machine create a message and set the DF bit at 1, if the message is too big, intermediate router will reject it and send back an ICMP message Type 4 code 3 to the source machine, the transmitter can then correct the size of the packet and resend it again till no error message is received, further frames will respect this corrected size. Among the major limitations of this mechanism is that some routers filters by default ICMP which sometimes makes useless the mechanism. PLPMTUd allows to detect PMTU by using probes principle, source machine create a personalized probe and send it forward to the destination, the correct PMTU is determined once the acknowledgment is received, it is important to know that these probes and their acknowledgments vary according to the application or protocol used for probing, by default TCP protocol is used given its ACK bit and its accuracy compared to other protocols. By exploiting these mechanisms an attacker can conducts a denial of service attack or reduce throughput between DMVPN equipment.

A. Monotonous data Despite its robustness in terms of encryption, IPsec can be easily exploited to decrypt certain messages supposed to be protected by the ESP, this is a challenging task but it’s also doable by repetitive messages, in fact some protocols and applications generate the same data, an example is the announcements « Router Advertisement » [11] of IPv6 protocol, the Hamming distance, in other words, the number of different bits between packets is small or null, especially for applications based on UDP or IP protocols. This similarity between packets may threaten the confidentiality of secured data by the ESP, moreover the cryptanalysis relies on this method to break the encryption key especially for conventional encryption protocols on Z/pZ these are protocols in which the discrete logarithm problem is easy to solve. If we consider two packages of which the Hamming distance is insignificant or null and given that the values of the initialization vector "IV" are explicit and the padding’s construction rules are known, the only unknown information for the attacker are key to the session and the plaintext. The Hamming distance between messages is low, several attack methods can be performed. We mentions as an example, the attack by forced sequences or attack by differential analysis [12], on Cypher Bloc Chaining “CBC” [13] mode, a low distance between IV or a predictable IV also makes communications vulnerable to be decrypted [14]–[16]. Some measures can be taken to complicate the task for attackers, other than decreasing the lifetime of security policy, highlights among them the data compression, this method can be used to hide the message redundancy, it serves to increase the Hamming distance between two clear messages [17]. This method introduced also for IP protocol [18, Sec. 3.1] [19], has shown its efficiency in terms of performances in addition to complicate the task for the pirate, which, in addition to breaking the encryption key will have to find the decompression methods.

C. Denial of Service of IPsec tunnels Let’s take an example of a network as illustrated on Fig.1, an IPsec tunnel is established between both gateways UCDGW1 and UCD-GW2, used protocol and mode are respectively ESP and tunnel.

B. Exploitation of ICMP protocol Internet Control Message Protocol (ICMP) is a signaling protocol for IP network, knowing that IP is an unreliable and non-oriented connection protocol, i.e. it doesn’t ensure any acknowledgment for transmitted data, it’s important to ensure a smooth functioning of the network and to notify equipment in case of delivery failures. ICMP performs these tasks, there are currently two versions of ICMP, for IPv4 [20], [21] and IPv6 [22], ICMP messages are classified on two categories,

Fig. 1. Denial of service of IPsec exploiting PMTUd

101

https://sites.google.com/site/ijcsis/ ISSN 1947-5500

International Journal of Computer Science and Information Security (IJCSIS), Vol. 14, No. 7, July 2016

To conduct a denial of service against IPsec using PMTUd as a vector of attack, hacker can follow these steps: The hacker forge a legitimate ICMP packet Type 3 code 4 “Destination unreachable (need fragmentation)” pretending to be a legitimate IPsec gateway. The detection of exchanged messages between two gateways, can be performed by several methods among them we cite: the alteration of the routing table of the intermediate routers or both IPsec gateways if they run dynamic routing protocols or by the passive listening if the intermediate network is wireless. This forged ICMP packet will be destined to the IPsec gateway UCD_GW1 which will record the new value of PMTU on the tunnel interface. The recorded value will be the maximum between the value of the received ICMP packet and the default value is 576 bytes (552 on IP level), for each sent packet that exceed 575 bytes, UCDGW1 will reject it and will inform back the user. If both machines UCD-Source and UCD-Destination will exchange files using FTP protocol, a connection must be established, this connection will succeed because three way handshake messages size is less than 576 bytes, as a reminder, the TCP protocol set the DF bit to 1. However, once the communication is established, UCD-Source packets will be rejected because their sizes exceed 576 bytes, therefor UCDGW1 will send a notification message indicating that the MTU must be 514 bytes (576 – IP + IPsec+ESP headers length). In return, the UCD-Source change its MTU value to 552 byte, since the minimum value of the MTU is 576 bytes including the IP headers. Such manipulation result in a denial of service and prevent the two machines to communicate.

As in the previous scenario, the attacker sends an ICMP packet type 3 code 4, to reduce the PMTU of the router. In order to send 900 bytes of FTP data, client UCD-Source must create two packets of 552 and 428 bytes each one, because the MSS size is 512 bytes and TCP (without options) plus IP headers consumes 40 bytes. FTP is an oriented-connection protocol, it uses three way handshake process to establish the connection, the first three packets will be forwarded correctly because their size is often less than the PMTU of the UCD-GW1 gateway, Instead, the first fragment of 552 bytes exceeds the PMTU stored in security association database, so the UCD-GW1 rejects it and sends an ICMP type 3 code 4 message to the UCD-Source to decrease its PMTU. UCD-Source will always ignore the ICMP error message because it is based on the acknowledgment of the sent probes to determine the optimum packet size, on its part UCD-GW1 will always reject the packets and return the ICMP error message. After a certain period of time UCD-Source will be forced to reduce its MSS to 256 bytes, and from that moment UCD-GW1 will deliver his packets. As it can be seen clearly, the PLPMTUD mechanism offers some protection against denial of service but obliges end devices to reduce the rate of data transmission. E. Countermeasures As preventive measures we recommend: • To integrate PLPMTUD on UCD-GW1 and UCDGW2 gateways [25, Sec. 5]. • To force the router to set the DF bit to zero before IPsec encapsulation, in order to allow TCP fragmentation on both gateways [Fig.3].

D. Reduction of throughput In the previous section we demonstrated that PMTUD mechanism may contribute to an IPsec denial of service, in this section we will detail how a hacker can reduce the throughput by exploiting the second mechanism PLPMTUD. Please refer to the following figure.

Fig. 3. Countermeasure against ICMP Attack– Initialization of DF bit

III.

MGRE LIMITATIONS

GRE is a tunneling protocol that allow the encapsulation of several messages as unicast, multicast and broadcast message of different protocols IP, IPX and AppleTalk into IP packet. Although it is widely deployed today thanks to its efficiency and simplicity in terms of deployment, it suffers from the

Fig. 2. Denial of service of IPsec exploiting PLPMTUd

102

https://sites.google.com/site/ijcsis/ ISSN 1947-5500

International Journal of Computer Science and Information Security (IJCSIS), Vol. 14, No. 7, July 2016

same limitations as the IP protocol in terms of security, such as confidentiality, integrity and authentication. GRE deploys an authentication mechanism, but this mechanism remains too weak against dictionary or brute force attacks. The GRE tunnel is a key component in the terminology of DMVPN network, it can be either point to point or point to multi point, in the first case the addresses of gateways must be statically assigned, in the second case, multi point to point, IP addresses can be dynamically, their detection is performed by the NHRP protocol. The lack of the confidentiality and the integrity calculation mechanisms represents an opportunity for hackers to divert established tunnels, forge packets and inject them as legitimate packets or prevent communications between stations belonging to different sites or even within the same site. In this section we will present some of the GRE protocol limitations by exploiting IP options such as "Strict Source List" or "Loose Source List" to prevent or to reset communications between two legitimate machines located behind an mGRE tunnel.

B. Attack Scenario

A. Strict and loose source routing strict source routing is used to define all the gateways to use in order to reach a specific destination, this technique assumes that the user masters the topology because if a gateway listed is not reachable the packet will be rejected, by the cons loose routing is also based on a predefined list of routes to use, but it may use other intermediate paths to reach the next hop of the list, in both cases hacker can exploit them to access a private network from the internet. This technique was developed primarily for the following reasons: 1. Network troubleshooting: In case of failure to access to a particular destination, the administrator can record the used routes leading to failures and specify the correct path; 2. Optimizing network performance: It is advisable to forward Best Effort packets by average quality paths and reserve other routes for critical applications. Most engineers are unaware of the severity of the source list options, and believe they are safe by deploying VPN tunnels between their remote sites, thinking that with the deployment of VPN tunnels private machines can be accessed only by legitimate and preconfigured ones of other side of the tunnel, but this assumption is false, in this section we will prove it in a DMVPN network, by: 1. Leading to a denial or degradation of service of private machines. 2. Preventing current connections between communicating machines.

Fig. 4. Exploitation scenario of mGRE tunnels

A DMVPN network is deployed between the HUB and SPOKE routers [fig.4], the subnet address of DMVPN cloud is 172.16.1.0/24 the SPOKE router has the first address, the second address was assigned to the HUB router. Machines are also configured by the second assignable address of each private subnet. The pirate named BAHNASSE tries to simultaneously flood the remote machines, bypassing authentication, and spoofing its identity. Step 1: To achieve this objective BAHNASSE created a forged IP packet with the following characteristics: • Source IP: 192.168.2.2 (Files Server address) • Final destination: 192.168.2.2 (Client_1 address) • Source List: 192.168.3.1, 3.3.3.2, 2.2.2.1, 172.16.1.1, 192.168.2.2. Step 2: Normally the packet will be delivered to the ISP, which in its turn consults the next hop (2.2.2.1) and delivers it to the HUB. Once the packet received at the HUB, it consults the destination of the packet which will require the creation of the tunnel because the destination has the address 172.16.1.1. Step 3: A tunnel will then be created automatically, without the obligation that the hacker knowing any information about security parameters of the tunnel, the NHRP IDs and passwords. Step 4.

103

https://sites.google.com/site/ijcsis/ ISSN 1947-5500

International Journal of Computer Science and Information Security (IJCSIS), Vol. 14, No. 7, July 2016

due to a load balancing effect, however, if the deployed DMVPN network is a dual cloud or dual HUB architectures, the loose URPF mode will be recommended because packets may arrive from several interfaces. 2. Filtering of IP option field Access control lists technology allows to filter, i.e. permit or deny a packet based on its attributes, those latters vary from one layer to another. In our scenario, we must reject any packet setting the option field to 131 and 137 respectively representing the loose source routing and strict source routing. Cisco command lines, addressing this need are: ip access-list extended UCD_TRANSIT_IN deny ip any any option ssr deny ip any any option lsr permit ip any any ! interface Serial 0/0 ip access-group UCD-TRANSIT-IN in

IV. NHRP LIMITATIONS The NHRP protocol defined by the ROLC workgroup acronym of Routing Over Large Clouds, is a protocol designed primarily for resolving ATM IP addresses to make connections beyond the IP, it was introduced by Cisco for DMVPN to translate a tunnel IP address into a public IP address, this resolution occurs mainly between NHC client and NHS server. As the ARP protocol, NHRP protocol is based on a cache to store the mappings of tunnel addresses and their associated public addresses of each equipment belonging to the same DMVPN cloud, which means that this protocol is vulnerable primarily for two types of attacks: denial service and the poisoning of the NHRP cache.

Fig. 5. Exploitation of DMVPN network- Forged IP packet arrived to the SPOKE router

Fig.5 illustrates the packet received at the SPOKE router, this latter will forward it to the machine 192.168.2.2, even with the presence of access control lists the packet will be accepted because this source IP address is allowed. Step 5: The Client_1 machine will then respond with an echo-reply to HUB Site Files Server. Once the hacker have access to private machines, several attacks may be executed to deny or to prevent communications, in this scenario, BAHNASSE performed a set of attack: Ping of death, UDP flooding and reset TCP connections.

A. NHRP Denial of service According to [27, Sec. 5.3.4.4] all NHS are vulnerable to denial of service attacks, leading to an overload of the cache, preventing legitimate requests to be handled properly, this attack may prove difficult to perform because the attacker must know the identifier of the cloud and the authentication keys of NHRP and mGRE protocols, however hacker can proceed differently by performing a buffer overflow attack through which the process NHRP overwrites memory adjacent to a buffer that should not have been modified intentionally or unintentionally, according to Cisco Bug ID CSCin95836 [28] after this attack router's behavior becomes unpredictable, some versions of the operating systems of Cisco routers can restart or allow the attacker to execute arbitrary malicious code on the router.

C. Countermeasures To fix related vulnerabilities of mGRE protocol, we can rely on two techniques: Unicast Reverse Path Forwarding (uRPF) to prevent the usurpation of IP address and the access control lists to verify the presence of the strict or loose source route options. 1. Unicast Reverse Path Forwarding : In order to forward a packet, routers checks routing table to ensure that the destination is reachable, URPF technology allows to check also the source IP address, ensuring that packets come through the interface representing the best route back to the source. For this URPF performs a search in the CEF table [26], the packet will be destroyed if the packet comes with a different interface from that indicated in the FIB. In our scenario, we will deploy strict mode of URPF technique, just because our architecture does not use multiple WAN or tunnel interfaces on which packets can arrive divided

B. NHRP cache poisoning NHRP cache poisoning consists of changing dynamic records or adding new ones in the resolver caches, either on the NHC or NHS, this attack is commonly used to divert 104

https://sites.google.com/site/ijcsis/ ISSN 1947-5500

International Journal of Computer Science and Information Security (IJCSIS), Vol. 14, No. 7, July 2016

traffic from one site to another intermediary, often the hacker site, in order to succeed this attack hacker must know the ID of NHRP cloud and used authentication strings of the tunnel. Unfortunately the latter are vulnerable to a brute force and dictionary attacks, in fact the length of the NHRP authentication key can’t exceed 8 characters, this make task easier for the hacker who can lead a distributed attack to break the authentication strings quickly. There are two main categories of attacks that a hacker can lead:

The mGRE protocol vulnerabilities have been detailed in the third section, through which we have illustrated the severity of strict and loose source route options, through these two options the hacker can penetrate the legitimate tunnels without having to authenticate and can therefore perform several attacks on private sites, as security measures we recommended the use of ACLs to filter the IP option fields, and the use of URPF technology to protect against IP spoofing. In the last section, we discussed the vulnerabilities related to NHRP protocol, including cache poisoning and buffer overflow attack. These limits can be remedied by using the anti-spoofing mechanisms namely extended access control lists, strengthened by URPF technology.

1. Poisoning NHRP cache of both NHC and NHS by false NBMA addresses, this manipulation can stop all current communications or reroute them to a tierce site who might not belong to the DMVPN network. 2. Man in the middle between two sites, by sending to NHC source and NHC destination false NHRP updates having as NBMA address the pirate address. These victims will always pass through the hacker to communicate each other, this latter can read, write and delete data if no security protocols are deployed.

REFERENCES [1] M. L. (CCIE.), “Scaling and optimizing IPsec VPNs,” in Comparing, Designing, and Deploying VPNs, Adobe Press, 2006, p. 523. [2] S. Kent and R. Atkinson, “Security Architecture for the Internet Protocol,” RFC Editor, RFC2401, Nov. 1998. [3] S. Kent, “IP Encapsulating Security Payload (ESP),” RFC Editor, RFC4303, Dec. 2005. [4] S. Kent, “IP Authentication Header,” RFC Editor, RFC4302, Dec. 2005. [5] D. Farinacci, T. Li, S. Hanks, D. Meyer, and P. Traina, “Generic Routing Encapsulation (GRE),” RFC Editor, RFC2784, Mar. 2000. [6] J. Luciani, D. Katz, D. Piscitello, B. Cole, and N. Doraswamy, “NBMA Next Hop Resolution Protocol (NHRP),” RFC Editor, RFC2332, Apr. 1998. [7] C. L. Hedrick, “Routing Information Protocol,” RFC Editor, RFC1058, Jun. 1988. [8] R. White, J. Ng, D. Slice, S. Moore, and others, “Enhanced Interior Gateway Routing Protocol,” 2014. [9] J. Moy, “OSPF Version 2,” RFC Editor, RFC2328, Apr. 1998. [10] Cisco Systems, “Developmental Phases of DMVPN and NHRP,” in NHRP, Cisco Press, 2007, pp. 6–8. [11] T. Narten, E. Nordmark, W. Simpson, and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6),” RFC Editor, RFC4861, Sep. 2007. [12] S. Aumont, R. Dirlewanger, and O. Porte, “L’accès sécurisé aux données,” 3ème journée des réseaux - JRES 99, Montpelier, p. 16, Nov-1999. [13] R. Pereira and R. Adams, “The ESP CBC-Mode Cipher Algorithms,” RFC Editor, RFC2451, Nov. 1998. [14] P. Karn, P. Metzger, and W. Simpson, “The ESP DES-CBC Transform,” RFC Editor, RFC1829, Aug. 1995. [15] C. Madson and N. Doraswamy, “The ESP DES-CBC Cipher Algorithm With Explicit IV,” RFC Editor, RFC2405, Nov. 1998. [16] S. Vaarala, A. Nuopponen, and T. Virtanen, “Attacking predictable IPsec ESP initialization vectors,” in Information and Communications Security, Springer, 2002, pp. 160–172. [17] D. A. Wagner and S. M. Bellovin, “A programmable plaintext recognizer,” 1994. [18] “hjp: doc: RFC 4301: Security Architecture for the Internet Protocol.” [Online]. Available: http://www.hjp.at/doc/rfc/rfc4301.html#sec_3.1. [Accessed: 15-Mar-2016]. [19] “hjp: doc: RFC 3173: IP Payload Compression Protocol (IPComp).” [Online]. Available: http://www.hjp.at/doc/rfc/rfc3173.html. [Accessed: 15Mar-2016]. [20] F. Gont and C. Pignataro, “Formally Deprecating Some ICMPv4 Message Types,” RFC Editor, RFC6918, Apr. 2013. [21] J. Postel, “Internet Control Message Protocol,” RFC Editor, RFC0777, Apr. 1981. [22] A. Conta, S. Deering, and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” RFC Editor, RFC4443, Mar. 2006. [23] J. C. Mogul and S. E. Deering, “Path MTU discovery.” [Online]. Available: https://tools.ietf.org/html/rfc1191. [Accessed: 25-Feb-2016]. [24] J. W. Heffner and M. Mathis, “Packetization Layer Path MTU Discovery.” [Online]. Available: https://tools.ietf.org/html/rfc4821. [Accessed: 25-Feb-2016]. [25] L. Jacquin, V. Roca, and J.-L. Roch, “ICMP: an Attack Vector against IPsec Gateways,” HAL, 2013.

C. Countermeasures In the user side, three countermeasures are possible: 1. Although it is quite difficult to block traffic transiting the network, the use of extended access control list can be useful to permit only NHRP replies coming from the legitimate DMVPN network, using the following command lines: ip access-list extended NHRP_PROTECT permit 54 host [Trusted Net] [Wildcard mask] any permit 47 host [Trusted Net] [Wildcard mask] any deny 54 any any deny 47 any any interface tunnel 1 ip access-group NHRP_PROTECT in

2. The above solution remains weak against spoofing attacks, It is for this reason that it is important to reinforce it by filtering options field and the use of URPF technology detailed on sections Error! Reference source not found. and 2 3. Upgrade the IOS with the last patched version. V. CONCLUSION Through this paper, we presented the vulnerabilities related to DMVPN technology, mainly those related to DMVPN protocols such as IPsec, mGRE and NHRP. We showed that a hacker can exploit them to compromise the availability, performance, confidentiality and the integrity of the whole DMVPN network. Concerning IPsec vulnerabilities, we presented those that can threaten the availability, reliability and confidentiality of the data encapsulated in an IPsec tunnel by exploiting ICMP variants and monotonous data, to workarounds these attacks several measures can be taken, such as the use of PLPMTUD mechanism instead of PMTUD and use data compression before encryption. 105

https://sites.google.com/site/ijcsis/ ISSN 1947-5500

International Journal of Computer Science and Information Security (IJCSIS), Vol. 14, No. 7, July 2016 [26] N. Stringfield, R. White, and S. McKee, Cisco Express Forwarding. Pearson Education, 2007. [27] J. Luciani, D. Katz, D. Piscitello, B. Cole, and N. Doraswamy, “NBMA Next Hop Resolution Protocol (NHRP),” RFC Editor, RFC2332, Apr. 1998. [28] Cisco Systems, “Cisco IOS Next Hop Resolution Protocol Vulnerability,” NHRP Vulnerability. [Online]. Available: http://cisco.com/c/en/us/support/docs/csa/cisco-sa-20070808-nhrp.html.

106

https://sites.google.com/site/ijcsis/ ISSN 1947-5500