A Scalable and Secure VPLS Architecture for Provider Provisioned ...

14 downloads 130 Views 714KB Size Report
Email: [madhusanka, gurtov]@ee.oulu.fi. Abstract—Virtual Private LAN Service (VPLS) is a Layer 2. Virtual Private Network (VPN) service. ... we focus on VPLS which is one of the most popular provider provisioned Layer 2 VPN (L2VPN) ...
A Scalable and Secure VPLS Architecture for Provider Provisioned Networks Madhusanka Liyanage, Andrei Gurtov Centre for Wireless Communications University of Oulu, P.O. Box 4500, FI-90014 Oulu, Finland Email: [madhusanka, gurtov]@ee.oulu.fi

Abstract—Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private Network (VPN) service. Internet Engineering Task Force (IETF) defined the essential system requirements of a VPLS network. Among them, Security is a key requirement as a VPLS delivers the customer data frames via untrusted public networks. However, the existing secure VPLS architectures are suffering from scalability issues and they are infeasible to implement in large scale networks. In this paper, we propose a novel VPLS architecture based on Host Identity Protocol (HIP). It includes a new session key based security mechanism which provides the scalability both in forwarding and security planes. Initial simulations verify that the proposed architecture reduces the key storage in a VPLS node, the total key storage in the network and the number of encryption per broadcast frame than other secure VPLS architectures. Additionally, our proposal provides an efficient broadcast mechanism and comparably higher degree of security features than other existing VPLS proposals.

I. I NTRODUCTION Virtual private networks (VPNs) are popular in the wide area Internet to extend the private network domain to geographical distributed locations via insecure public network. In this paper, we focus on VPLS which is one of the most popular provider provisioned Layer 2 VPN (L2VPN) services. The general requirements of a provider provisioned L2VPNs are specified by IETF [1]. These requirements are topology generation, control signaling, control and data plane security, membership discovery, redundancy and failure recovery. On the other hand, VPLS emulates a LAN which requires full mesh connectivity between Provider Edge Equipments (PEs). Initially, IETF proposed two methods to developing a full mesh establishment by using Border Gateway Protocol (BGP) [2] and Label Distribution Protocol (LDP) [3]. Thereafter, several VPLS architectures are proposed to enhance the service quality of these LDP and BGP based VPLS architectures [4] [5]. However, none of these proposals are able to fulfill the security requirements other than the HIPLS [6] architecture. Security is a key requirement of a VPLS network as it delivers the private frames via untrusted public network. Henderson et al. proposed a secure VPLS architecture which is named HIP based Virtual Private LAN Service (HIPLS) [6]. To the best of our knowledge, this is the first and only secure VPLS proposal which is proposed yet. It inherits the strong security properties found in HIP [7]. However, HIPLS encounters several issues; mainly it lacks the scalability due

to massive key storage requirement and inefficient broadcast mechanism. In this paper, we propose a novel scalable VPLS architecture. We introduce a session key based secure communication mechanism by customizing the Host Identity Protocol (HIP). It has better performance than HIPLS in terms of security and scalability. The proposed architecture supports all security features which are provided by HIPLS; Such as, data encapsulations, mutual authentication, secure address learning and robustness to several known attacks. In addition to the above features, it provides some level of robustness to misfeasor attacks which are originated from the legitimate users. On the other hand, our proposal provides security plane scalability by significantly reducing the key storage complexity at a VPLS node and the whole network. Furthermore, it offers forwarding plane scalability by providing an efficient broadcast mechanism which is able to process broadcast frames efficiently and rapidly at the entry PE. The rest of the paper is organized as follows. A description of VPLS, HIP and HIPLS contain in Section II. The proposed VPLS architecture is described in Section III. We discuss our simulation model and the numerical results in Section IV. Section V and VI respectively contain the discussion and the conclusion of the research. II. BACKGROUND A. Virtual Private LAN Service (VPLS) VPLS is a provider provisioned layer 2 VPN service. It provides Ethernet based multipoint to multipoint communication overlaid on top of a provider network. VPLS services are becoming popular among the entrepreneurs as it offers a successful solution to many problems such as high-speed connectivity, any-to-any forwarding at Layer 2 and makes their work much easier as it supports many applications like IP Telephony, Ethernet Multipoint Services (EMS). A VPLS network consists of three main segments, namely Customer Edge Equipments (CEs), Provider Edge Equipments (PEs) and a core network. The CE device is a host equipment or a router or a switch which is located at the customers premises. It might be a legacy equipment which is transparent to upper-layer protocols (e.g. IP). The PE device is the place where all the VPN intelligence resides and these PE equipments are belonging to the service providers. The core network is the provider network which interconnects these

PEs. This core network can be operated based on several network protocols, such as IPv4, IPv6, MPLS (Multiprotocol Label Switching).

middle can eavesdrop and/or able to inject packets into the data stream. If control packets are maliciously and undetectably altered while in flight, DoS attacks or alteration of the expected QoS level may result. Hence, it is important to provide a sufficient level of security features for a VPLS network for a proper VPLS operation. B. Host Identity Protocol (HIP)

Fig. 1: A simple VPLS network The definition of a provider provisioned VPN is different for a general customer VPN. A large scale service provider has thousands of PEs and provides service for thousands of customer VPNs. Hence, it is not economical for a service provider to maintain and monitor each customer VPN individually. Therefore, they offer different VPN classes for the customers based on different service factors such as data rates and QoS class. A customer subscribes to a VPN class which matches his requirements. Thereafter, providers aggregate these CE VPNs according to the above mentioned VPN classes. These aggregated VPNs of a particular VPN class is considered as a single provider VPN [8]. For example, LTE backhaul defined 5 VPNs. Thus, the number of VPNs in a provider network (M= 3-10) is significantly lower than the number of PE is in the network (N= 100-1000) for the large scale networks [8] [9]. 1) Security Considerations of the VPLS: A VPLS network is vulnerable to a number of security breaches. These breaches can strain network resources such as memory space, forwarding information tables, bandwidth, and CPU processing [1] [10]. Each PE should be authenticated with other peer PEs by using some sort of cryptographic authentication procedure during the auto discovery and data exchange procedures. Otherwise, L2VPN traffic may direct to a wrong location or a malicious user can mount attacks, such as perform Denial of Service (DoS) attacks. Furthermore, the control protocol which is used to set up pseudowires (PWs) should be secured from knows attacks.If the control protocol uses TCP/UDP messages, it is advisable to have some protection against UDP/TCP based attacks (e.g UDP DoS, TCP reset, TCP DoS etc). If a PE is unable to handle high volumes of multicast or broadcast traffic efficiently for a sustained period, then it is possible to launch a DoS attack by sending a large amount of broadcast/multicast frames to a PE. Then, PE will not be able to process all these bogus frames and ultimately it will be unable to serve legitimate frames as well. If VPLS data packets are transmitted in the clear (unencrypted) form via untrusted public network, then a man-in-the-

The Host Identity Protocol (HIP) is a new security and mobility protocol which was approved by IETF [7] [11]. In other terms, it is a novel host identification technology for use in IP networks, such as the Internet. In the Internet, IP addresses are used for a dual role as the host identifiers and the location identifiers. HIP introduces a new layer to TCP/IP layered model in between the transport layer and the internetworking layer and it separates the dual roles of IP addresses. HIP provides a Host Identity (HI) name space based on a public key security infrastructure and these HIs use as the end-point (host) identifiers. 128-bit hash of HI is called Host Identity Tag (HIT) and HIT is used by the upper layer applications. Hence, all occurrences of IP addresses in upper layer applications are eliminated and replaced with these cryptographic host identifiers which provided by HIP [11]. HIP nodes use IP Security (IPsec) Encapsulating Security Payload (ESP) protocol on BEET (Bound End to End Tunnel) mode tunnels to communicate each other. Hence, the HIP based traffic is always encrypted. Further, Security Associations (SAs) for the IPsec tunnels are exchanged by using HIP Base Exchange (BEX). HIP BEX is a four-way an initial handshake procedure between two users which not only establishes the SAs but also mutual authenticates the users. C. HIP based Virtual Private LAN Service (HIPLS) HIPLS [6] is proposed to provide a secure VPLS architecture. Basically, HIP is used here to create a VPLS overlay on top of a standard IPv4 and/or IPv6 provider network. HIP signaling between PE devices works as the control protocol of the VPLS which is used to establish and maintain HIP tunnels between PEs. This application of HIP for the HIPLS differs from the traditional implementation. There are two main differences. First, HIP is implemented within the middle boxes as a ”bumpin-the-wire” implementation not within the end hosts. Second, the payloads of the ESP-encrypted datagrams are layer-2 frames instead of transport Protocol Data Units (PDUs) [6]. 1) The issues related to HIPLS: Although HIPLS provides a secure VPLS, several issues can be identified. First, it has a massive key storage complexity. Every PE equipment has to store O(N ) keys where N is the number of PE equipment. As a result, the whole network has to store O(N (N + 1)) keys. This is a serious issue as it reduces the available memory of a PE for other important functions such as routing tables. Furthermore, the extensive key searches need extra processing power at the PE and increase the packet transmission delay.

Second, HIPLS has an inefficient broadcast mechanism. It performs O(N ) encryptions per broadcast frame at entry PE by using O(N ) different keys. Hence, it requires extensive processing at PEs and vulnerable to broadcast based DoS attacks. Third, it is not possible to integrate the distribution of multicast or broadcast frames of HIPLS architecture with the packet distribution mechanisms such as spanning trees or multicast trees of the underlay network. Hence, the routing of these multicast and broadcast frames may not be optimal and it expenses network bandwidth inefficiently. Due to the above stated three reasons, HIPLS is lacking of both security and forwarding planes scalability to implement in large scale networks. III. P ROPOSED S ECURE VPLS A RCHITECTURE We propose a novel secure VPLS architecture based on HIP. The main idea behind our proposal is to use a new session key mechanism for a customized version of HIP. Hence, we call our architecture as Session key based HIPLS (S-HIPLS). Our architecture uses two types of keys as Content Encryption Key (CEK) and Key Encryption Key (KEK). CEK is a symmetric key which is used to encrypt and decrypt all packets belong to a single VPN. Every PE has a unique KEK which is used to encrypt and decrypt the corresponding CEKs. There is a Key Distribution Center (KDC) which is the responsible entity for distributing the encrypted CEKs among PEs. Furthermore, this KDC also works as the Authentication Server (AS) which maintains the Access Control Lists (ACL) of each VPN. Our VPLS architecture can divide into four sub sections as PE registration and deletion, data communication, control protocol and key management A. PE Registration and Deletion PE registration is the initial procedure for a new PE who wishes to join for the VPLS. The potential PE requests access to VPNs from the KDC. Hence, user has to establish a HIP tunnel with the KDC and this tunnel establishment follows a HIP BEX. During this HIP BEX, new PE is authenticated by using a public key infrastructure (PKI) mechanism and authorized according to ACLs. Few modifications are proposed to the original HIP BEX proposed in [7]. Figure 2 illustrates the modified BEX.

Diffie–Hellman (D-H) key exchange uses as the KEK for the user. The identity of the initiator is verified after the arrival of the I2 message. Then KDC checks the ACL. If the user is a legitimate user, KDC sends a certificate in R2 message.This certificate contains important information, such as the authorized VPNs, QoS policies and other VPN management details. This certificate is also important to avoid the misfeasor attacks which originate from legitimate CEs and PEs. The removal of inactive PEs is also an important procedure for the security. When a PE leaves or becomes inactive, KDC removes the KEK of that PE. Then, the KDC no longer provides CEKs for that PE. An inactive user can be identified by using either active notification or passive notification. The PEs actively notify their departure to the KDC before they leave or failure to acknowledge for the periodic CSK will passively notify the in-activeness. B. Data Communication The proposed VPLS architecture establishes the HIP tunnels between PEs before any kind of communication. HIP uses IPsec tunnels and all the frames are encrypted to avoid eavesdropping by the unauthorized party. The source PE encrypts the Layer 2 (L2) frame by using the corresponding CEK of the VPN. Then it wraps within the ESP payload, fragments it if necessary, and sends to the remote PE. The remote PE detunnels it and places on the remote access network segment again as a L2 frame. C. Control Protocol Control protocol is responsible for three main functions, namely tunnel establishment, address learning and key distribution. 1) Tunnel Establishment: A HIP tunnel establishment between two users is mandatory before any type of communication. The HIP tunnel establishment follows a HIP BEX and it mutually authenticates the users. This HIP BEX is slightly different from the original HIP BEX [7]. As we use CSKs for data encryption, D-H key exchange is omitted here. Hence, modified HIP BEX is bit faster and needs less processing than the original HIP BEX. Figure 3 illustrates the modified BEX for the tunnel establishment phase.

Fig. 3: Modified HIP BEX for tunnel establishment Fig. 2: Modified HIP BEX for PE registration First three message exchanges are similar to the original HIP BEX proposed in [7]. The symmetric key which is shared by

2) Address Learning: VPLS is a layer 2 VPN solution and frames are delivered based on MAC address. Hence, PEs should learn the MAC addresses of remote CEs and the network address of the PE which is responsible for each CE.

Hence, each PE maintains a dynamic MAC-PE mapping table and addresses learning procedure conducts as follow. When a PE receives a frame from the CE access network, PE learns that it is the responsible PE device for the source MAC address of the frame and records the entry in MACPE mapping table. If the PE does not have the destination MAC address of the frame on its MAC-PE mapping table, it broadcasts a encrypted address request frame to all PE which belongs to the same VPN. Then the responsible PE sends an unicast frame as a reply and both PEs update their MAC-PE mapping tables. 3) Key Distribution: Key distribution is the most important process for a secure VPLS architecture. We propose a secure key distribution to deliver the keys only to authorized PEs and we describe it under the key management section.

A. Security Plane Scalability The number of keys use in the security mechanism is a major factor to measure the efficiency and the scalability of the security plane. If the number of keys is high, then the encryption process will be complex and it needs more extensive key searching procedures. On the other hand, it will consume the available memory for other important services such as routing tables. 1) Key Storage at a PE: Figure 4 illustrates the key storage complexity at a PE against the number of PEs in the provider network. We use the number of VPNs as M=5 (which is within the general number of VPNs in a LTE backhaul network [8] [9]) and change the PEs from 1 to 100. 100

IV. N UMERICAL RESULTS Several VPLS architectures are proposed to provide an efficient VPLS networks. However, HIPLS [6] is the first and only secure VPLS scheme which is proposed to use a public key authentication structure and a data traffic encryption mechanism. We simulate the proposed architecture and HIPLS on MATLab environment. We consider a VPLS network which has 100 PEs and a bandwidth of 100 Mbps. The following section contains a comparison of performance of the security and broadcast mechanisms between the HIPLS and our architecture.

HIPLS Our Proposal

90 80

Number of keys

70 60 50 40 30 20 10 0

0

20

40 60 Number of PEs

80

100

Fig. 4: The key storage complexity at a PE The simulation result in the Figure 4 indicates a linear increment of the number of keys at a PE for the HIPLS scheme while it remains constant for the proposed architecture. Thus, the number of keys store at a PE in the proposed scheme is significantly reduced. The complexity of HIPLS is O(N ) where N is the number of PEs and the complexity of our model is O(M + 1) where M is the number of VPNs and it is independent of the number of PEs in the provider network. This numerical analysis confirms the simulation results. 2) Key Storage in the Authentication Server/Key Distribution Center: Figure 5 illustrates the key storage complexity at the AS/KDC against the number of PEs. We use the number of VPNs as M=5 and change the PEs from 1 to 100. 120 HIPLS Our Proposal 100

Number of keys

D. Key Management The key management procedure of our VPLS architecture has three sections as KEK distribution, CEK distribution and KDC architecture. 1) KEK distribution: Each PE shares an unique symmetric key with the KDC which is used as the KEK for that PE. This KEK is shared by using the D-H key exchange during the PE registration process. It is used by the KDC to send the encrypted CEKs, certificates and any other control information to the PE. There are periodic HIP BEX events between each PE and KDC to renew this KEK. This process is called the rekeying process and it is recommended by the HIP architecture [7]. 2) CEK distribution: KDC is the responsible entity for the CEK distribution. The KDC sends CEKs to every PE. These CEKs are encrypted by using the KEK of each PE. KDC periodically generates new CEKs to secure the VPLS communication sessions. Even if an intruder is able to capture a CEK somehow, it will not be valid after the rekeying time out. 3) KDC architecture: The KDC is the heart of the key distribution mechanism. KDC plays a dual role as a key distributor and an authentication server. It is responsible for PE registration, PE deletion, CEK generation and distribution. We propose to use a distributed KDC structure which is preferred for large networks. A distributed KDC architecture delivers several benefits such as a reduction of the work load and the key storage requirement at a single KDC and avoidance of a single point of failure.

80

60

40

20

0

0

20

40 60 Number of PEs

80

100

Fig. 5: The key storage complexity at the AS/KDC The simulation result in the Figure 5 indicates a linear increment of the number of keys at the AS for the HIPLS scheme. we see an almost similar gradual increment of the

12000 HIPLS Our Proposal

Number of keys

10000

8000

100 HIPLS Our Proposal

90 80 Number of encryptions

number of keys at a KDC for our scheme as well. However, the number of keys store at a KDC in the proposed scheme is slightly higher than HIPLS. This is due to the fact that the number of keys store at a KDC in the proposed scheme is dependent on both the number of PEs and VPNs, whereas it depends only on the number of PEs in the HIPLS model. However, N >>> M for the most of the real world use cases (M= 3-10 and N= 100-1000) [8] [9] and the difference is less significant for large scale networks. The numerical analysis shows that the complexity of HIPLS is O(N ) and the complexity of our model is O(N + M ). This further verifies the simulation results. 3) Total Key Storage in the Network: Figure 6 illustrates the total key storage complexity of the VPLS network against the number of PEs. We use the number of VPNs as M=5 and change the PEs from 1 to 100.

70 60 50 40 30 20 10 0

0

20

40 60 Number of PEs

80

100

Fig. 7: The number of encryption per broadcast frame

at value 1 for the proposed architecture. Thus, the number of encryptions per broadcast frame at a PE in the proposed scheme is significantly reduced. The complexity of HIPLS is O(N ) and the complexity of our model is O(1) and it further confirms the validity of the simulation result. The above experiment clearly shows that broadcast related work load on a PE is independent of the number of PEs in the network. Hence, this verifies the forwarding plane scalability.

6000

V. D ISCUSSION

4000

A. Security Features

2000

0

0

20

40 60 Number of PEs

80

100

Fig. 6: Total key storage complexity of the VPLS network The simulation result in the Figure 6 indicates an exponential increment of the total number of keys store in the network for the HIPLS scheme while it has a linear increment for the proposed architecture. Thus, the total number of keys store in the network is significantly reduced in the proposed scheme. The complexity of HIPLS is O(N (N +1)) and the complexity of our model is O(N (M + 2) + M ). It further confirms the validity of the simulation results. The above three experiments clearly show that security related work load on a PE is independent of the number of PEs in the network and verified the security plane scalability. On other word, operators can extend the network without addition addition work load on top of a PE but in the ASs. Hence, if it is needed, operators have an option to use resourceful and/or distributed AS systems to compensate this additional workload. B. Forwarding Plane Scalability The performance of the frame broadcasting mechanism is the major factor to measure the forwarding plane scalability of a L2VPN network. Hence, the performance of the broadcast mechanism of our model is compared with different schemes. Figure 7 illustrates the number of encryption per broadcast frame at the entry PE of the provider network. The simulation result in the Figure 7 indicates a linear increment of the number of encryptions per broadcast frame at a PE for the HIPLS scheme while it remains constant

Our VPLS architecture provides a wide range of security features to a VPLS network, namely mutual authentication, PE authorization, payload encryption, privacy protection, secure address learning and control protocol, robustness to the several attacks. 1) Mutual Authentication: The identities of the PEs are verified by using a public key authentication during the HIP BEX. A HIP BEX instance is mandatory at a PE registration and prior to any data exchange between two PEs. It provides the mutual authentication between PEs and prevent outside breaches to the VPN. 2) Payload Encryption: The proposed VPLS scheme uses the IPsec ESP mode. Hence, payload is always encrypted by using the CEK of the particular VPN. 3) Privacy Protection: Our proposal provides the privacy protection of both CEs and PEs. All the frames are encrypted and wrap in IPsec ESP packets. Hence, the source and destination MAC address of CEs are encrypted and protected. As long as HI is exposed to the outside world, the original IP addresses of the PEs are also encrypted during the communication. It secures the privacy of the PEs. 4) Secure Control Protocol: The proposed architecture uses the IPsec ESP mode to transmit address learning and control frames. Also remote PEs are mutually authenticated before the communication. Hence, fault address advertisements and eavesdropping of addresses are restricted in the VPLS. Furthermore, the control protocol uses the HIP signaling though HIP tunnels which are protected from IP/TCP based attacks. For instance, the most popular VPLS architectures are based on LDP [3] and BGP [2] protocols. They use TCP sessions for control protocol and these TCP sessions are vulnerable to

IP/TCP based attacks such as TCP SYN flooding, TCP reset attacks [10]. In [12], authors verified the protection provided by HIP tunnels against TCP SYN flooding and TCP reset attacks. 5) Robustness to the Known Attacks: Secure address learning and mutual authentication avoid the delivery of L2VPN traffic to the wrong destinations and the access of the malicious user to the network. Secure control protocol prevents the several types of DoS attacks and unauthorized alteration of the QoS levels of VPNs. Furthermore, our proposal for efficient broadcast frame processing mechanism at PEs prevents some level of broadcast frame based DoS attacks. Payload encryption secures the VPLS traffic from unauthorized manin-the-middle eavesdropping attacks and in flight alterations. B. Comparison of proposed Architecture and HIPLS Both HIPLS and proposed architecture provide a secure VPLS architecture on top of a provider network. However, our proposal outruns the HIPLS due to scalability and additional security features. Our proposal significantly reduces the complexity of the key storage at a VPLS node from O(N ) to O(M ) and the total key storage of the network from O(N (N + 1)) to O(N (M + 2) + M ) where N >>> M [8] [9]. Hence, it directly reduces the storage requirements and memory usage at PEs. Furthermore, it decreases the frame processing delay at PE by eliminating extensive key searches and encryptions. Our architecture provides an efficient broadcast/multicast frame processing mechanism which reduces the complexity of the number of encryption per a broadcast frame from O(N ) to O(1) at a PE. As a result, broadcast/multicast frame processing delay at a PE is reduced and our proposal offers some level of robustness to broadcast/multicast frame based DoS attacks. Furthermore, it needs to generate only one broadcast frame at the entry PE and it can be replicated at the immediate nodes according to the Spanning Tree Protocol (STP) or the multicast tree. Therefore, our VPLS scenario saves the network bandwidth and reduces the transmission delay compare to HIPLS. Also, our architecture relaxes the constrain of using HIPLS only for unicast-only IPLS (IP only LAN like Service) networks. The proposed architecture provides faster and low processing tunnel establishment phase than HIPLS, because we omit the extensive D-H key exchange in HIP BEX. TABLE I: The properties comparison of different VPLS architectures LDP/BGP Based VPLS

HIPLS

Proposed S-HIPLS

High

Low

High

-

Low

High

Data Traffic Encryption

No

Yes

Yes

IP Attack Protection

No

Yes

Yes

Control Protocol Protection

No

Yes

Yes

Broadcast Support

Yes

No

Yes

Scalability of Forwarding Plane Scalability of Security Plane

The only drawback of our proposal compared with HIPLS is the additional key storage requirement at the KDC (see Fig 5). However, it is less significant as long as the number of PEs is considerably large than the number of VPNs. Moreover, a distributed KDC architecture can solve this issue by decentralizing key storage requirement to several KDCs. VI. C ONCLUSION In this paper, we propose a novel Host Identity Protocol (HIP) based VPLS architecture to provide a secured VPLS network. Our VPLS architecture provides a range of security features such as mutual authentication, PE Authorization, data and control frame encryption, privacy protection, secure control protocol and robustness to the known attacks. Hence, it provides a higher degree of security features than any other secure VPLS architecture. On the other hand, the simulation results verified the outrun of our architecture than other secure VPLS solutions by significantly reducing the complexity of the key storage at a VPLS node, the total key storage of the network and the number of encryption per broadcast frame. Hence the proposed VPLS architecture provides both security and forwarding plane scalability compared to other secure VPLS models. Future works focus on extending our architecture for a secure hierarchical VPLS networks and provide secure Virtual Private Multicast Services (VPMS). ACKNOWLEDGMENT This work has been performed in the framework of the CELTIC project CP7-011 MEVICO. The authors would like to acknowledge the contributions of their colleagues. R EFERENCES [1] W. Augustyn and Y. Serbest, “Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks,” RFC 4665, IETF, September 2006. [2] K. Kompella and Y. Rekhter, “Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling,” RFC 4761, IETF, January 2007. [3] M. Lasserre and V. Kompella, “Virtual private LAN service (VPLS) using label distribution protocol (LDP) signaling,” RFC 4762, IETF, January 2007. [4] R. Gu, J. Dong, M. Chen, Q. Zeng, and Z. Liu, “Analysis of Virtual Private LAN Service (VPLS) Deployment,” Internet Draft, IETF, September 2011. [5] E. R. H. Shah and G. Heron, “IP-Only LAN Service (IPLS),” Internet Draft, IETF, February 2007. [6] T. Henderson, S. Venema, and D. Mattes, “HIP-based Virtual Private LAN Service (HIPLS),” Internet Draft, IETF, September 2011. [7] R. Moskowitz, P. Nikander, and P. Jokela, “Host Identity Protocol,” RFC 5201, IETF, April 2008. [8] “Architectural Considerations for Backhaul of 2G/3G and Long Term Evolution Networks,” CISCO Cooperation, Tech. Rep., 2010. [9] M. A. Alvarez, F. Jounay, T. Major, and P. Volpato, “LTE backhauling deployment scenarios,” Next Generation Mobile Networks Alliancen, Tech. Rep., 2011. [10] L. Andersson and E. Rosen, “Framework for Layer 2 Virtual Private Networks (L2VPNs),” RFC 4664, IETF, September 2006. [11] A. Gurtov, Host Identity Protocol (HIP): Towards the Secure Mobile Internet. Wiley, 2008. [12] M. Liyanage and A. Gurtov, “Secured VPN Models for LTE Backhaul Networks,” in Proc. of 76th Vehicular Technology Conference (VTC2012-Fall). IEEE, 2012.