SEARCH

SEARCH BY CITATION

Keywords:

  • VPN;
  • VPLS;
  • HIP;
  • security;
  • session key

ABSTRACT

  1. Top of page
  2. ABSTRACT
  3. INTRODUCTION
  4. RELATED WORK
  5. BACKGROUND
  6. PROPOSED SECURE VPLS ARCHITECTURE
  7. NUMERICAL RESULTS
  8. DISCUSSION
  9. CONCLUSION
  10. ACKNOWLEDGEMENTS
  11. REFERENCES

Virtual private local area network service (VPLS) is a layer 2 service provider-provisioned virtual private network service. Security is one of the key system requirements of a VPLS because it delivers the frames via an untrusted network. Several VPLS architectures are proposed during the recent years. However, many of them do not provide a sufficient level of security. On the other hand, the existing secure VPLS architectures are also suffering from the scalability issues, and they are infeasible to implement in large scale networks.

Hence, we present a scalable secure VPLS architecture based on host identity protocol (HIP). It includes a new session key-based security mechanism that provides the scalability both in forwarding and security planes. The initial simulations verify that our proposal comparatively reduces the complexity of the key storage at a node, the total key storage of the network, and the number of encryption per a broadcast frame. Additionally, it offers an efficient broadcast mechanism and comparably higher degree of security features than other existing VPLS proposals. The simulation results further confirm that our proposal is able to protect the control protocol of the VPLS from the Internet Protocol (IP)/transmission control protocol-(TCP) based attacks. Copyright © 2013 John Wiley & Sons, Ltd.

INTRODUCTION

  1. Top of page
  2. ABSTRACT
  3. INTRODUCTION
  4. RELATED WORK
  5. BACKGROUND
  6. PROPOSED SECURE VPLS ARCHITECTURE
  7. NUMERICAL RESULTS
  8. DISCUSSION
  9. CONCLUSION
  10. ACKNOWLEDGEMENTS
  11. REFERENCES

Virtual private networks (VPNs) are popular in the wide area Internet to extend the private network domain to geographical distributed locations via an unsecured public network. Several techniques have been defined to provide VPNs at different layers of the open systems interconnection model, for instance, layer 1 (e.g., L1VPN), layer 2 (e.g., virtual local area network (LAN), virtual private LAN service (VPLS), and pseudowire (PW)) layer 3 (e.g., virtual router, multiprotocol label switching (MPLS) VPNs), and layer 4 (e.g., transport layer security (TLS)/secure socket layer VPNs).

We focus on VPLS, which is one of the most popular layer 2 VPN (L2VPN) services on this paper.

The general system requirements of a VPLS are specified by the Internet Engineering Task Force (IETF) [1]. Among them, VPLS security is a key system requirement as a VPLS network delivers the private frames via untrusted public network. Several VPLS architectures were proposed to build a functional VPLS over the provider network by fulfilling some of the VPLS requirements. However, none of these proposals are able to fulfill the security requirements other than host identity protocol (HIP)-based virtual private LAN service (HIPLS) [2].

To the best of our knowledge, HIPLS is the first and only secure VPLS proposal that was proposed until now. HIPLS used HIP protocol to build secure tunnels between the provider edge (PE) equipment, and it inherits the strong security properties found in HIP protocol. However, HIPLS encounters several issues, mainly it is lacking of the scalability because of massive key storage requirement and inefficient broadcast mechanism.

In this paper, we propose a secure and scalable VPLS architecture. We introduce a session key-based secure communication by customizing the HIP. Our architecture has better performance than HIPLS in terms of security, scalability, and the efficiency of the broadcast mechanism. It supports all security features that are provided by HIPLS, such as data encapsulations, user authentication, secure address learning, and robustness to several known attacks. In addition, it provides some level of robustness to misfeasor attacks from customer edge (CE) and PE equipment. A misfeasor is a legitimate user who accesses unauthorized data, programs, or resources. Furthermore, our proposal significantly reduces the key storage complexity at a VPLS node and the whole network than HIPLS. As a result, new architecture has security plane scalability to implement even in large scale provider networks. On the other hand, it provides forwarding plane scalability by proposing an efficient broadcast mechanism that is able to process the broadcast frames efficiently and rapidly at the entry PE.

The rest of the paper is organized as follows. Related work is mentioned in Section 2. A description of VPLS, HIP, and HIPLS contains in Section 3. The proposed VPLS architecture is described in Section 4. We discuss our simulation model and the numerical results in Section 5. Section 6 and 7, respectively, contain the discussion and conclusions of the research.

RELATED WORK

  1. Top of page
  2. ABSTRACT
  3. INTRODUCTION
  4. RELATED WORK
  5. BACKGROUND
  6. PROPOSED SECURE VPLS ARCHITECTURE
  7. NUMERICAL RESULTS
  8. DISCUSSION
  9. CONCLUSION
  10. ACKNOWLEDGEMENTS
  11. REFERENCES

The research on L2VPNs became popular in the recent years. Many scholars paid close attention for L2VPNs, particularly on VPLS networks.

A framework for provider-provisioned L2VPNs is provided in [3]. A provider-provisioned VPN is a VPN where the service provider participates in management and provisioning of the VPN. It discussed a number of different technical approaches to implement L2VPNs, namely virtual private wire service (VPWS), virtual private LAN service (VPLS), and Internet Protocol (IP)-only LAN-like service (IPLS). Furthermore, it revealed the correlation between different approaches and mentioned the issues associated with each approach.

The service requirements for the provider-provisioned L2VPNs are discussed in [1]. Detailed requirements are expressed by both a customer and a service provider perspectives. These system requirements are topology generation, control signaling, control and data plane security, membership discovery, path management, redundancy, and failure recovery.

There are many research studies focused on VPWS. Martini et al. [4] specifies a protocol for establishing and maintaining the PWs by using label distribution protocol (LDP). The encapsulation methods of carrying Ethernet/802.3 protocol data units (PDUs) over MPLS networks is discussed in [5], and the encapsulation methods of carrying point to point protocol or high-level data link control PDUs over an MPLS is presented in [6]. Y. Stein [7] proposed an extension to MPLS PW format called PWsec to enhance PW user plane security.

However, a VPLS is more complex to implement than a VPWS as it provides multipoint to multipoint connectivity. Hence, VPLS emulates a LAN that requires full mesh connectivity between PEs. Initially, the IETF proposed two methods to develop a full mesh establishment for a VPLS by using border gateway protocol (BGP) [8] and LDP [9].

In [8], the authors proposed a VPLS architecture based on BGP. It uses BGP as the control plane protocol to provide the autodiscovery and signaling for PEs. Each PE simultaneously discovers all other PEs in the same VPN through the use of BGP and establishes a full mesh of PWs between these PEs.

A VPLS architecture based on LDP is proposed in [9]. A full mesh of LDP sessions is established between PEs that belong to the same VPN. Thereafter, these LDP sessions are used to establish a full mesh of PWs between the PEs. Furthermore, authors proposed a hierarchical VPLS architecture to reduce the number of LDP sessions in the provider network.

An analysis of LDP-based and BGP-based VPLS solutions is contained in [10]. Further, the authors mentioned the advantages and disadvantages of each VPLS architecture.

A simplified version of VPLS is proposed as IPLS in [11]. IPLS provides a VPLS-like service and uses it exclusively for IP traffic only. Furthermore, the authors explained the possible simplifications to the operation of the general VPLS. However, none of these architectures are able to provide a sufficient level of security features for the VPLS network. Specially, the control protocols of these systems are vulnerable to IP/transmission control protocol (TCP)-based attacks such as denial of service (DoS) and TCP reset attacks.

In [2], Henderson et al. described a use case of the HIP architecture, which is to provide an HIPLS over an untrusted network. They used HIP protocol to build secure tunnels between the PE equipment. It provides a secure VPLS in terms of data encapsulation, strong authentication, secure control protocol, and some level of robustness to the possible known attacks.

The proposed architecture uses a group key-based secure communication by customizing HIP. HIP-based multicast service also uses group key-based communication. Several HIP-based secure multicast models have been proposed during the last few years [12, 13]. However, HIP-based VPLS is exclusively different from HIP-based multicast services. The requirements for a VPLS service are different and more complex than for a multicast service. On the other hand, a VPLS service included an inbuilt multicast/broadcast mechanism. Furthermore, HIP multicast schemes are designed for end systems, whereas VPLS services are designed for PE nodes as a “bump-in-the-wire” architecture. Hence, these existing HIP-based group key-based secure communication architectures cannot be used for a secure VPLS implementation.

BACKGROUND

  1. Top of page
  2. ABSTRACT
  3. INTRODUCTION
  4. RELATED WORK
  5. BACKGROUND
  6. PROPOSED SECURE VPLS ARCHITECTURE
  7. NUMERICAL RESULTS
  8. DISCUSSION
  9. CONCLUSION
  10. ACKNOWLEDGEMENTS
  11. REFERENCES

In this section, we present the background information related to the research and a brief introduction for the used protocols.

Virtual private LAN service

Virtual private LAN service (VPLS) is a provider-provisioned L2VPN service. It provides Ethernet-based multipoint to multipoint communication overlaid on top of a standard IPv4 and/or IPv6 provider network. VPLS services are becoming popular among entrepreneurs and service providers as it offers a successful solution to many problems such as high-speed connectivity and any-to-any forwarding at layer 2 and makes their work much easier as it supports many applications such as IP telephony and Ethernet multipoint services.

A VPLS network consists of three main segments, namely CE equipment, PE equipment, and a core network. The CE device is a host equipment or a router or a switch that is located at the customers' premises. It might be a legacy equipment that is transparent to upper-layer protocols (e.g., IP). The PE device is the place where all the VPN intelligence resides and all the VPLS services originate and terminate. PE equipment belong to the service providers, and they set up tunnels to connect these PEs. The core network is the provider network that interconnects these PEs. It can be operated on the basis of several network protocols, such as IPv4, IPv6, and MPLS.

Figure 1 illustrates a simple VPLS network. It provides the basic idea where these VPLS entities are located.

image

Figure 1. A simple VPLS network.

Download figure to PowerPoint

Furthermore, the definition of a provider-provisioned VPN is different for a general customer VPN. In a VPLS network, the network operator provides VPLS services for the customers by connecting CE network using their provider network. Hence, a large scale service provider (e.g., mobile operator and Internet service provider) has thousands of PEs and provides services 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 on the basis of different service factors such as data rates and quality of service (QoS) classes. A customer can subscribe to a VPN class that matches his or her requirements. Thereafter, providers aggregate these CE VPNs according to the aforementioned VPN classes. These aggregated VPNs of a particular VPN class are considered as a single provider VPN [14].

Apart from these CE VPNs, operators can use a couple of control and housekeeping VPNs for controlling, operations support system traffic, and other services. For example, Long Term Evolution (LTE) backhaul defined five VPNs. Thus, the number of VPNs in a provider network (M = 3–10) is significantly lower than the number of PE in the network (N = 100–1000) for the large scale networks [14, 15, 25].

Security considerations of the VPLS

A VPLS network is vulnerable to a number of security breaches, and they can strain network resources such as memory space, forwarding information tables, bandwidth, and CPU processing [1, 3]. Hence, a VPLS architecture should be supported by a range of security features such as mutual authentication, PE authorization, data and control frame encryption, privacy protection, secure address learning and control protocol, and robustness to the known attacks [3].

Each PE should be authenticated with other peer PEs by using some sort of cryptographic authentication procedure during the autodiscovery procedures and data exchanges. Otherwise, L2VPN traffic may direct to a wrong location, and malicious users can mount attacks, such as perform DoS attacks.

Furthermore, the control protocol that is used for setting up PWs should be secured from knows attacks [1, 3]. If the control protocol uses TCP/user datagram protocol (UDP) messages, it may be advisable to have some sort of protection against TCP/UDP-based attacks (e.g., UDP DoS, TCP reset, and TCP DoS).

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. These frames may have either a multicast address or an unknown media access control (MAC) address in their MAC destination address fields. Then, PE will not be able to process all these bogus frames, and ultimately, it will be unable to serve the legitimate frames as well.

If VPLS data packets are transmitted in the clear (unencrypted) form via untrusted public network, then a man-in-the-middle can eavesdrop and may be 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 operation.

Host identity protocol

The HIP is a new security and mobility protocol by the IETF [16, 17]. 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 dual roles as the host identifiers and as the location identifiers. HIP introduces a new layer to TCP/IP-layered model in between the transport and the internetworking layers. Hence, it separates the dual roles of IP addresses.

The HIP provides a host identity (HI) name space based on a public key security infrastructure, and these HIs are used as the end-point (host) identifiers. A 128-bit hash of HI is called host identity tag (HIT), and it is used by the upper-layer applications. Hence, all occurrences of IP addresses in the upper-layer applications are eliminated and replaced with these cryptographic host identifiers that are provided by HIP [18].

The HIP nodes use IP security (IPsec) encapsulating security payload (ESP) protocol on bound end to end tunnel mode tunnels [19] to communicate each other. Hence, the HIP-based traffic is always encrypted. Further, security associations for the IPsec tunnels are exchanged by using HIP base exchange (BEX). HIP BEX is a four-way initial handshake procedure between two users that not only makes security associations but also mutually authenticates the users.

HIP-based virtual private LAN service

The HIPLS [2] 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 that is used to establish and maintain the HIP tunnels between PEs.

This application of HIP for the HIPLS differs from the traditional implementation of HIP. There are two main differences. First, HIP is implemented within the middle boxes as a “bump-in-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) [2].

The HIPLS inherits the strong security properties found in HIP, including strong authentication mechanism, data packet encapsulation, and some level of robustness from attacks. The strong authentication mechanism and data packet encapsulation solve many of the aforementioned security threats in a VPLS. It provides secure PE registration, secure data/control packet exchange, secure auto discovery mechanism, and secure control protocol and avoids several known attacks (e.g., eavesdropping, spoofing, and DoS attacks).

The issues related to HIPLS

Although HIPLS provides a secure VPLS service, 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 with the packet distribution mechanisms such as spanning trees and 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. Because of the previously stated three reasons, HIPLS is lacking of both security and forwarding plane scalability to implement in large scale networks.

Fourth, HIPLS is vulnerable to misfeasor attacks that originated from CEs and PEs as HIPLS does not specify any mechanism to avoid such attacks.

PROPOSED SECURE VPLS ARCHITECTURE

  1. Top of page
  2. ABSTRACT
  3. INTRODUCTION
  4. RELATED WORK
  5. BACKGROUND
  6. PROPOSED SECURE VPLS ARCHITECTURE
  7. NUMERICAL RESULTS
  8. DISCUSSION
  9. CONCLUSION
  10. ACKNOWLEDGEMENTS
  11. REFERENCES

We propose a novel secure VPLS architecture in this journal. Our architecture is inspired by the HIPLS [2] architecture and uses HIP to create a VPLS overlay on top of a standard IPv4 and/or IPv6 provider network. The main idea behind our proposal is to use a new session key mechanism with a customized version HIP. Hence, we can 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 that is used to encrypt and decrypt all messages in a single VPN. Every PE has a unique KEK that is used to encrypt and decrypt the corresponding CEKs. There is a key distribution center (KDC) that is the responsible entity to distribute CEKs to the PEs. Furthermore, KDC also works as the authentication server (AS) that maintains the access control lists (ACLs) of VPNs. Operators update ACLs according to the CE subscriptions. Thereafter, KDC uses these ACLs to grant the access to new PEs. HIP signaling is used as the control protocol to build and maintain the tunnels between PEs.

Our VPLS architecture can be categorized in to four subsections as PE registration and deletion, data communication, control protocol, and key management.

PE registration and deletion

The PE registration is the initial procedure for a new PE who wishes to join for the VPLS. The potential PE needs to send a request to the KDC to gain access to VPNs. Hence, the new user has to establish an HIP tunnel with the KDC. A mandatory HIP BEX will run between the new PE and the KDC to establish this HIP tunnel. During this HIP BEX, the new PE is authenticated by a public key infrastructure and authorized according to ACLs.

Few modifications are proposed to the original HIP BEX that was proposed in [16]. Figure 2 illustrates the modified BEX.

image

Figure 2. Modified HIP BEX for PE registration.

Download figure to PowerPoint

First three message exchanges are similar to the original HIP BEX. HIT-based authorization is sufficient enough to avoid spoofing attacks. Even if an attacker is able to generate a valid HIT, it would fail to complete the initial BEX because of lack of knowledge of the private key [20]. The symmetric key that is shared by Diffie–Hellman (D–H) key exchange uses as the KEK for this user.

The identity of the initiator is verified after the arrival of the I2 packet. Then, KDC checks the ACL and sends a certificate in R2 encrypted by using the KEK key of the user. 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 that originate from the legitimate CEs and PEs. For instance, a customer may subscribe for a VPLS service to obtain the connectivity among certain sites. However, if the customer tries to direct the traffic to a nonsubscribed site via this VPLS, PEs can discard such traffic on the basis of the information in these certificates.

The removal of inactive PEs is also important for the efficient operation and the security of the VPLS network. When a PE leaves or becomes inactive, KDC removes the KEK of that PE and no longer provides CEKs for that PE. An inactive user can be identified by using either active notification or passive notification. The PEs will actively notify their departure to the KDC before they leave, or failure to acknowledge for the periodic hello messages will passively notify the inactiveness.

Data communication

Our VPLS architecture uses HIP tunnels between PEs to communicate. Hence, the sender PE must build an HIP tunnel to each target PE before any data exchange. HIP uses bound end to end tunnel mode 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, source PE will wrap it within the ESP payload, fragments it if necessary, and sends it to the remote PE. The remote PE detunnels it and places it on the remote access network segment again as an L2 frame.

Control protocol

The control protocol is used to maintain the proper operation of the VPLS network. It is responsible for three main functions, namely tunnel establishment, address learning, and key distribution. Our architecture provides a secure control protocol by using secure HIP signaling.

Tunnel establishment

An HIP tunnel establishment between two users is mandatory before any type of communication in the VPLS. The HIP tunnel establishment follows an HIP BEX, and it mutually authenticates the users. This HIP BEX is slightly different than the original HIP BEX [16]. As we use CSKs for data encryption for ESP, D–H key exchange is omitted here. Hence, modified HIP BEX is slightly faster, and it needs less processing than the original HIP BEX.

Figure 3 illustrates the modified BEX for the tunnel establishment.

image

Figure 3. Modified HIP BEX for tunnel establishment.

Download figure to PowerPoint

Address learning

The VPLS is an L2VPN solution, and frames are delivered on the basis of MAC addresses. Hence, PEs should learn the MAC addresses of remote CEs and the network address of the PE that is responsible for each CE. Hence, each PE maintains a dynamic MAC–PE mapping table. The address-learning procedure can be described as follows.

When a PE receives a frame from costumer access network, PE learns that it is the responsible PE device for the source MAC address of the frame and records the entry in MAC–PE mapping table. If the PE does not have the destination MAC address of the frame on its MAC–PE mapping table, PE has to learn about the responsible PE. Hence, PE broadcasts an encrypted address request frame to all PEs that belongs to the same VPN. Then, the responsible PE sends a unicast frame as a reply, and PE updates its MAC–PE mapping table.

Key distribution

Key distribution is the most important process of our architecture. We present a secure key distribution to deliver the keys only to authorized PEs. Otherwise, fault traffic generation and unauthorized eavesdropping can be possible. Although key distribution is a duty of the control protocol, we describe it under the key management section for the continuation.

Key management

The key management procedure of our VPLS architecture has three sections as KEK distribution, CEK distribution, and KDC architecture.

KEK distribution

Each PE shares a unique symmetric key with the KDC that is used as the KEK for that PE. This KEK is shared using D–H key exchange during the PE registration process. It is used by KDC to send the encrypted CEKs, certificates, and any other control information to the PE. There are periodic HIP BEX instances between each PE and KDC to renew the KEK. This process is called as rekeying, and it is recommended by the HIP architecture [16]. Initially, we define the rekeying timeout as 10 s, and it can be changed according to the requirements of the operator.

CEK distribution

The KDC is the responsible entity for the CEK distribution. It periodically sends the CEK to PEs. These CEKs are encrypted by using the KEK of each PE. Hence, an eavesdropper cannot extract the CEK. There are three instances that a new CEK distribution is triggered.

First, KDC periodically generates new CEKs to secure the VPLS communication session. Although an intruder is able to capture a CEK somehow, it will not be valid after the rekeying time out. As the membership of the VPLS is dynamic, it may need to provide forward and backward confidentiality for the VPLS. Second and third CEK distribution events are used to ensure these optional security features. KDC generates new CEKs after a new PE registration to protect the backward confidentiality. Backward confidentiality means new members cannot access the old data. KDC generates the CEKs of the VPNs that have the new PE as a member. Thereafter, it sends new CEKs to all the corresponding PEs.

The KDC generates new CEKs after a PE deletion to ensure the forward confidentiality. Forward confidentiality defines as an old member cannot access the new data of the VPN. It generates the CEKs of the VPNs that had the inactive PE as a member. Then, KDC sends new CEKs to the corresponding PEs.

KDC architecture

The KDC is the heart of the key distribution mechanism. It plays a dual role as the key distributor and the AS. Hence, it is responsible for PE registration, PE deletion, and CEK generation and distribution. We propose a distributed KDC structure that is preferred for the large scale networks. A distributed KDC architecture provides several benefits such as reducing the work load, distributing the key storage complexity, and avoiding the single point of failure.

We propose two distributed KDC architectures as hierarchical server and mesh server structures.

Hierarchical server structure is suitable for a provider network that has a hierarchical underlay network topology. Figure 4 illustrates a simple hierarchical KDC structure with two tiers.

image

Figure 4. A simple hierarchical KDC structure.

Download figure to PowerPoint

Each tier 2 KDC is responsible for a section of the VPLS. It conducts the PE registration, KEK storage, CEK distribution, and PE deletion functions of the particular section. For instance, B is responsible for PE1 and PE2. In addition, these tier 2 KDCs can operate local VPNs if all the member PEs of the local VPN are resided under that KDC. For example, B can operate a local VPLS only for PE1 and PE2. Tier 1 KDC is responsible for CEK distribution (only VPNs spend at least two tier 2 KDCs) and controls the operation of the tier 2 KDCs. Tier 1 KDC learns the relevant membership alternation from tier 2 KDC advisement. Furthermore, operator changes the ACL only in tier 1 KDC(AS), and it securely broadcasts them to tier 2 KDCs.

Mesh structure is suitable for a provider network that has mesh underlay network. Figure 5 illustrates a simple mesh structure with two KDCs.

image

Figure 5. A simple mesh KDC structure.

Download figure to PowerPoint

Each KDC is responsible for a section of the VPLS, and all KDCs are connected to each other by forming a mesh network. Local VPNs are possible in this scenario as well. If it is necessary, KDC has to notify regional membership changes to other KDCs. If new CSKs are required, responsible KDCs generate the new CEK and securely transfer them to the corresponding PEs via other KDCs. Furthermore, one KDC in the mesh is elected for periodic CEK distribution.

Broadcast mechanism

Broadcast and multicast messages are important for a LAN service. For instance, broadcast messages are used by network protocols such as address resolution protocol (ARP) and dynamic host configuration protocol (DHCP), and multicast messages are used by Ethernet services such as IP telephony and television webcast.

However, HIPLS [2] does not provide an efficient broadcast/multicast mechanism, and HIPLS is useful only for a constrained system such as a unicast-only IPLS VPN. Hence, Henderson et al. [2] proposed to deploy HIPLS only in the systems that neither support multicast or broadcast nor bridge PDUs.

Our architecture provides an efficient broadcast mechanism and relaxes the unicast-only IPLS VPN constrain. We significantly reduce the number of encryptions and packet generation per broadcast frame at the entry PE. Our VPLS solution uses one session key for one VPN. Hence, it needs only one encryption per broadcast frame at the entry PE, and only one encrypted broadcast frame is developed. Therefore, this packet can be replicated at entry PE and/or at the immediate nodes according to the spanning tree protocol or multicast tree. Thus, this broadcast frame distribution is exactly similar to the other nonsecure VPLS architectures [8, 9]. The proposed architecture is capable enough to distribute the broadcast/multicast frames efficiently in the network.

NUMERICAL RESULTS

  1. Top of page
  2. ABSTRACT
  3. INTRODUCTION
  4. RELATED WORK
  5. BACKGROUND
  6. PROPOSED SECURE VPLS ARCHITECTURE
  7. NUMERICAL RESULTS
  8. DISCUSSION
  9. CONCLUSION
  10. ACKNOWLEDGEMENTS
  11. REFERENCES

This section contains the description of the simulation model and its important results.

Security performance

We model and simulate our architecture on MATLAB to compare the performance with other VPLS architectures. Especially, we conduct several extended simulations to study the performance under known attacks.

The control protocol is the vein of the VPLS. It is designed on the basis of the BGP [21] or LDP [22] for most of the existing VPLS solutions (Section 2). LDP-based VPLS architecture proposed a full mesh of LDP sessions as the control protocol. According to the LDP specification [22], the LDP sessions are built by using the TCP protocol. BGP-based VPLS architecture proposed to use BGP as the control plane protocol, and it also uses TCP as its transport protocol [21]. However, these TCP-based control protocols are vulnerable to IP/TCP-based attacks. Therefore, the attackers try to perform TCP-based attacks such as TCP synchronization (SYN) DoS, TCP SYN distributed DoS (DDoS), and TCP reset attacks to turn down the controlling plane of the VPLS network [25].

Hence, we compare the robustness of the control protocol of these solutions with our VPLS architecture under several known attacks, namely TCP reset, TCP SYN DoS, and TCP SYN DDoS attacks. We use LDP-based VPLS model that was presented in [9] and HIPLS [2] as the reference models to compare the performance of the proposed architecture.

Performance under TCP SYN DoS attack

TCP SYN DoS attack is also called TCP SYN flood attack. Basically, an attacker sends a succession of TCP SYN requests to the target system or server. As the server allocates some resources (a TCP port) for each successfully received SYN request, the attacker is able to consume server resources to make the system unresponsive for the legitimate traffic.

Our simulation model contains a VPLS network with 300 nodes. We assume that all the nodes are equivalent and the bandwidth of the network is set to 100 Mbps. There is an attacker that tries to attack a node in the network. Hence, it sends TCP SYN packets to the underattacked node to occupy all the ports and IP address combinations with other nodes in the network. Then, the rest of the nodes in the network will not be able to send any data traffic for the underattacked node as it does not have any port to make a connection. We assume that the attacker also has the same bandwidth, which is 100 Mbps. According to the values that were presented in [23], we use the number of ports per user as 64,000 and the TCP timeout value as 270 s. We run the simulation for 500 s, and the attack is placed between 25 and 75 s time intervals.

Figure 6 illustrates the percentage packet drop at the underattacked user over the simulation time.

image

Figure 6. Impact of TCP SYN DoS attack.

Download figure to PowerPoint

The simulation result clearly indicates that there is no packet drop during the attack period for the HIPLS and our architecture. They have the same performance for both attacking and nonattacking periods. However, LDP architecture has dropped almost all the packets during the DoS attack period, and it requires at least a TCP timeout period, which is 270 s, to fully recover from the attack. Hence, our architecture is capable enough to provide the protection for TCP SYN DoS attack.

Performance under TCP SYN DDoS attack

We further investigate the performance of the proposed architecture under the coordinated DDoS attack scenario. We use the same simulation setup and the attack model that is used for the previous TCP SYN DoS attack scenario. However, we increase the number of attackers and investigate the time required to successfully attack a single user in the VPLS network. We compare the performance with LDP-based VPLS architecture [9].

Figure 7 illustrates the average time required to successfully attack the user.

image

Figure 7. Impact of TCP SYN DDoS attack.

Download figure to PowerPoint

We run the simulation for 500 s and place the attack for the whole duration of the simulation time. We do not see any successful attack for our architecture. Hence, the average time required to successfully attack remains in the initial value, which is zero, at the end of the simulation for our architecture. However, the simulation result verifies that LDP-based architecture is vulnerable for DDoS attack as well. Furthermore, the time required to successfully attack the system is inversely proportional to the numbers of attackers.

Performance under TCP reset attack

The TCP reset attack is a TCP/IP-based attack that is used to terminate an ongoing TCP connection between two users. At first, the attacker has to hijack the connection. In other words, the attacker monitors and learns the TCP header parameters such as IP addresses, port numbers, and sequence numbers of the TCP connection. Secondly, attacker generates fake TCP packets with TCP parameters which are learnt by hijacking the connection and sends these packets with reset flag ON to both users or any one of the user. As the end users do not aware of these fake TCP packets, end users treat these packets as legitimate packets. Therefore, they reset the TCP connection, and communication session between users is terminated.

We compare the performance of the LDP-based VPLS architecture and HIPLS with our architecture under the TCP reset attack scenario. It is assumed that both VPLS users and the attacker have the same bandwidth of 100 Mbps. We calculate the probability of successful attack against the size of the file. In [24], the authors stated that the file sizes in the Internet have a Pareto distribution with the minimum file size of 4.5 kB and the maximum size of 20 MB. Hence, we change the file sizes within this range, and Figure 8 illustrates the simulation results.

image

Figure 8. Impact of TCP reset attack.

Download figure to PowerPoint

The simulation result shows that our architecture has a zero probability of a successful attack. It verifies the protection against the TCP reset attacks. However, we observe some probability of a successful attack for LDP-based VPLS architecture, and it is directly proportional to the file size. Larger files have longer transmission time, and the attacker gets more time to reset the connection.

We further analyze the impact of the TCP reset attack by varying the connection speed of the attacker (Table 1).

Table 1. The impact of TCP reset attack for LDP architecture.
Attacker's connection speed (Mbps)Average time requirement for a successfully attack (s)
1.544 (T1)64.130
6.312 (DS2)13.451
44.736 (DS3)1.855
51.84 (OC1)1.771
155.52 (OC3)0.593

The simulations are conducted for 500 s, and we do not observe any successful attacks for our proposal under any of the connection speeds. However, we obtain some values for the LDP-based VPLS architecture. The experiment result indicates that connection speed of the attacker is inversely propositional to the average time requirement for a successful attack.

Security plane scalability

Several VPLS architectures are proposed to provide an efficient VPLS network. However, HIPLS [2] is the only VPLS scheme that was able to provide a secure VPLS architecture. Furthermore, it is the first and the only scheme that proposed to use a public key authentication structure and the data traffic encryption mechanism in VPLS. We simulate the proposed architecture and HIPLS on MATLAB environment. We consider a VPLS network that has 100 PEs and a bandwidth of 100 Mbps. The following section contains a comparison of performance security mechanisms and broadcast mechanism in the HIPLS and our architecture.

The key storage requirement at each entity of the VPLS network has been compared. It is a major evidence to justify the security plane scalability.

Key storage at a PE

Figure 9 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 used in an LTE backhaul network [14, 15] and change the PEs from 1 to 100.

image

Figure 9. The key storage complexity at a PE.

Download figure to PowerPoint

The simulation result in Figure 9 indicates a linear increment of the number of keys at a PE for the HIPLS scheme, whereas it remains constant for the proposed architecture. Thus, the number of keys stored at a PE in the proposed scheme is significantly reduced. The numerical analysis shows that 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 explains the simulation results.

Figure 10 illustrates the key storage complexity at a PE against the number of VPNs in the provider network. We use the number of PEs as N = 100 and change VPNs from 1 to 100.

image

Figure 10. The key storage complexity at a PE.

Download figure to PowerPoint

The simulation result in Figure 10 indicates a linear increment of the number of keys at a PE for our architecture, whereas it remains constant for the HIPLS architecture. Hence, the number of keys at a PE for HIPLS is independent of the number of VPNs in the provider network. By comparing the HIPLS scheme and the proposed scheme, the number of keys stored at a PE in the proposed scheme is reduced as long as the number of VPNs is less than the number of PEs in the network. Furthermore, we already stated that N > > > M for most of the real-world use cases (Section 3.1).

Key storage in the authentication server/key distribution center

Figure 11 illustrates the key storage complexity at the AS/KDC against the number of PEs. HIPLS uses an AS, and our architecture uses a KDC that provides AS services and additional CEK distribution service. We use the number of VPNs as M = 5 and change the PEs from 1 to 100.

image

Figure 11. The key storage complexity at the AS/KDC.

Download figure to PowerPoint

The simulation result in Figure 11 indicates a linear increment of the number of keys at the AS for the HIPLS scheme. We observe an almost similar gradual increment of the number of keys at a KDC for our scheme as well. However, the number of keys stored at a KDC in the proposed scheme is slightly higher than HIPLS. This is due to the fact that the number of keys stored 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 most of the real-world use cases (M = 3–10 and N = 100–1000) [14, 15], 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). It explains the simulation results.

Figure 12 illustrates the key storage complexity at the AS/KDC against the number of VPNs in the provider network. We use the number of PEs as N = 100 and change the PEs from 1 to 100.

image

Figure 12. The key storage complexity at the AS/KDC.

Download figure to PowerPoint

The simulation result in Figure 12 indicates a linear increment of the number of keys stored at the KDC for our architecture, whereas it remains constant for the HIPLS architecture. Hence, the number of keys at the AS for HIPLS is independent of the number of VPNs in the provider network. By comparing the HIPLS scheme and the proposed scheme, the number of keys stored at the AS/KDC is higher in our scheme. The difference is equal to the number of VPNs in the network, and as long as the numbers of VPNs are limited, difference is less significant. Furthermore, the proposed distributed server systems can significantly reduce the key storage per server.

Total key storage in the network

Figure 13 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 PEs from 1 to 100.

image

Figure 13. Total key storage complexity of the VPLS network.

Download figure to PowerPoint

The simulation result in Figure 13 indicates an exponential increment of the total number of keys stored in the network for the HIPLS scheme, whereas it has a linear increment for the proposed architecture. Thus, the total number of keys stored 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 explains the validity of the simulation results.

Figure 14 illustrates the total key storage complexity in the network against the number of VPNs in the provider network. We use the number of PEs as N = 100 and change PEs from 1 to 100.

image

Figure 14. Total key storage complexity of the VPLS network.

Download figure to PowerPoint

The simulation result in Figure 14 indicates a linear increment of the total number of keys stored in the network for our scheme, whereas it remains constant the HIPLS architecture. Hence, the number of keys at an AS for HIPLS is independent of the number of VPNs in the provider network. By comparing the HIPLS scheme and the proposed scheme, the total number of keys stored in the network is reduced by the proposed scheme as long as the number of VPNs is less than the number of PEs in the network.

The experiment results of this section verify that the proposed architecture significantly reduces the key storage complexities of the PEs and the network. Further, it shows that the security-related work load on a PE is independent of the number of PEs in the network. Hence, our architecture is able to provide the security plane scalability. In other words, operators can extend the network without any additional work load on top of a PE but in the ASs. If it is needed, operators have an option to use resourceful and/or distributed AS systems to compensate this additional workload.

Forwarding plane scalability

An efficient broadcast mechanism is the key indicator to verity the forwarding plane scalability. An efficient broadcast mechanism is mandatory for the proper operation of a layer 2 network because many layer 2 network protocols such as address resolution protocol use Ethernet broadcast messages. If the broadcast mechanism is inefficient, layer 2 nodes are unable to forward frames in larger networks. It causes to decrease the forwarding plane scalability.

Comparison of broadcast mechanism

The performance of the frame broadcasting mechanism in different schemes has been compared in this section.

Figure 15 illustrates the number of encryption per broadcast frame at the entry PE of the provider network.

image

Figure 15. The number of encryption per broadcast frame.

Download figure to PowerPoint

The simulation result in Figure 15 indicates a linear increment of the number of encryptions per broadcast frame at a PE for the HIPLS scheme, whereas it remains constant 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), the complexity of our model is O(1), and it further explains the simulation result.

The experiment clearly shows that the proposed architecture reduces the number of broadcast packet generation complexity at the entry PE from O(N) to O(1). Hence, the broadcast mechanism is almost similar to the broadcast mechanism of other nonsecure VPLS architectures. Hence, it provides the forwarding plane scalability.

DISCUSSION

  1. Top of page
  2. ABSTRACT
  3. INTRODUCTION
  4. RELATED WORK
  5. BACKGROUND
  6. PROPOSED SECURE VPLS ARCHITECTURE
  7. NUMERICAL RESULTS
  8. DISCUSSION
  9. CONCLUSION
  10. ACKNOWLEDGEMENTS
  11. REFERENCES

Security features

Our VPLS architecture is able to provide a wide range of security features to the VPLS network, namely mutual authentication, PE authorization, payload encryption, privacy protection, secure address learning and control protocol, and robustness to known attacks.

Mutual authentication

The identities of the PEs are verified by using a public key authentication during HIP BEX. An 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 prevents outside breaches to the VPN.

PE authorization

The KDC is the responsible entity for PE authorization. It grants the access to PEs according to the ACLs that are provided by the operator. Hence, malicious users (not in the ACL) will not gain access to the VPN, and it also restricts the misbehavior actions of legitimate CEs.

Payload encryption

Our VPLS scheme proposed to use IPsec ESP mode. Hence, payload is always encrypted by using the CEK of the particular VPN.

Privacy protection

Our proposal provides the privacy protection of both CEs and PEs. All the frames are encrypted and wrapped 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.

Protection for the KDC

The KDC is a highly important element in the VPLS network. Especially, intruders try to attack the KDC. However, every user who wishes to communicate with the KDC has to establish an HIP tunnel as the first step. This HIP tunnel establishment phase (HIP BEX) authenticates the users on the basis of public key infrastructure mechanism and authorizes on the basis of ACLs. Hence, intruders will not get the access. Furthermore, HIP BEX has inbuilt mechanisms to prevent DoS and spoofing attacks [16, 17]. Hence, the KDC is well secured for such attacks.

Secure control protocol

Our model use IPsec ESP mode to transmit the 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 that are protected from IP/TCP-based attacks. Further, our simulation results verify the protection for the control protocol.

Robustness to the known attacks

Secure address learning and mutual authentication avoid the delivery of L2VPN traffic to the wrong destinations and access of the malicious user to the network. The 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/multicast frame-processing mechanism at PEs prevents the broadcast frame-based DoS attacks. Payload encryption secures the VPLS traffic from unauthorized man-in-the-middle eavesdropping attacks and in flight alterations.

Comparison of our architecture and HIPLS

Both HIPLS and our VPLS architectures provide a secure VPLS architecture on top of a standard IPv4 and/or IPv6 provider network. Both architectures are based on HIP protocol. Hence, they inherit the strong security properties found in HIP protocol. Both proposals are able to provide strong authentication mechanism, payload encryption, PE authorization, privacy protection, robustness to several known attacks, and secure control protocol. However, our proposal outruns the HIPLS because of scalability and additional security features. These advantages are discussed as follows.

Our VPLS architecture provides an efficient VPLS solution than HIPLS. It 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. Hence, it directly reduces the storage requirements and memory usage at PEs. Furthermore, it indirectly decreases the frame-processing delay at PE by eliminating extensive key searches and encryptions.

Our architecture provides an efficient broadcast/multicast frame-processing mechanism that reduces the complexity of the number of encryption per 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 provides 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 either at entry PE or/and at the immediate nodes according to the spanning tree protocol or the multicast tree. This is a similar scenario that is used by other VPLS architectures [8, 9, 11]. Therefore, our VPLS scenario saves the network bandwidth and reduces the transmission delay than HIPLS. Also, our architecture relaxes the constrain to use HIPLS only for unicast-only IPLS services.

The proposed architecture provides a faster and low processing tunnel generation phase than HIPLS as it omits the extensive D–H key exchange in HIP BEX during the HIP tunnel generation between PEs (Figure 3). The additional certificate (Figure 2) that is sent from KDC to PEs provides some level of robustness to misfeasor attacks from CEs and PEs. Furthermore, our architecture provides the opportunity to operate separate VPNs for user and control plane traffic. Hence, it indirectly provides additional security for important system entity from the attackers. This certificate mechanism and dedicated control VPN instances were not present in HIPLS.

The only drawback of our proposal compared with HIPLS is the additional key storage requirement needed at the KDC (Figure 12). However, it is less significant as long as the number of PEs is significantly higher than the number of VPNs. In addition, a distributed KDC architecture decentralizes key storage requirement and solves this issue.

CONCLUSION

  1. Top of page
  2. ABSTRACT
  3. INTRODUCTION
  4. RELATED WORK
  5. BACKGROUND
  6. PROPOSED SECURE VPLS ARCHITECTURE
  7. NUMERICAL RESULTS
  8. DISCUSSION
  9. CONCLUSION
  10. ACKNOWLEDGEMENTS
  11. REFERENCES

In this paper, we proposed a novel HIP-based VPLS architecture to provide a secure VPLS network. Our VPLS architecture is able to provide a range of security such as mutual authentication, PE authorization, data and control frame encryption, privacy protection, secure control protocol, and robustness to the several attacks. Hence, it provides a higher degree of security features than any other secure VPLS architectures. In addition, our proposal provides scalability both in security and forwarding planes. The numerical analysis verified outrun of our architecture than other secured 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 a broadcast frame. The simulation results further verify the protection against the TCP/IP-based attacks such as TCP DoS, TCP DDoS, and reset attacks. Hence, the proposed VPLS architecture is a scalable secure VPLS architecture.

Future works focus on extending our architecture for secure hierarchical VPLS networks and secure virtual private multicast services. Further, we will study the impact of the mobile nodes on the security of the VPLS network.

ACKNOWLEDGEMENTS

  1. Top of page
  2. ABSTRACT
  3. INTRODUCTION
  4. RELATED WORK
  5. BACKGROUND
  6. PROPOSED SECURE VPLS ARCHITECTURE
  7. NUMERICAL RESULTS
  8. DISCUSSION
  9. CONCLUSION
  10. ACKNOWLEDGEMENTS
  11. REFERENCES

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. This information reflects the consortium's view, but the consortium is not liable for any use that may be made of any of the information contained therein.

REFERENCES

  1. Top of page
  2. ABSTRACT
  3. INTRODUCTION
  4. RELATED WORK
  5. BACKGROUND
  6. PROPOSED SECURE VPLS ARCHITECTURE
  7. NUMERICAL RESULTS
  8. DISCUSSION
  9. CONCLUSION
  10. ACKNOWLEDGEMENTS
  11. REFERENCES
  • 1
    Augustyn W, Serbest Y. Service requirements for layer 2 provider-provisioned virtual private networks. RFC 4665 September 2006.
  • 2
    Henderson T, Venema S, Mattes D. HIP-based virtual private LAN service (HIPLS). Internet Draft September 2011.
  • 3
    Andersson L, Rosen E. Framework for layer 2 virtual private networks (L2VPNs). RFC 4664 September 2006.
  • 4
    Martini L, Rosen E, El-Aawar N, Smith T, Heron G. Pseudowire setup and maintenance using the label distribution protocol (LDP). RFC 4447 April 2006.
  • 5
    Martini L, Rosen E, El-Aawar N, Heron G. Encapsulation methods for transport of Ethernet over MPLS networks. RFC 4448 April 2006.
  • 6
    Martini L, Rosen E, Heron G, Malis A. Encapsulation methods for transport of PPP/high-level data link control (HDLC) over MPLS networks. RFC 4618 September 2006.
  • 7
    Stein Y. Pseudowire security (PWsec). Internet Draft October 2006.
  • 8
    Kompella K, Rekhter Y. Virtual private LAN service (VPLS) using BGP for auto-discovery and signaling. RFC 4761 January 2007.
  • 9
    Lasserre M, Kompella V. Virtual private LAN service (VPLS) using label distribution protocol (LDP) signaling. RFC 4762 January 2007.
  • 10
    Gu R, Dong J, Chen M, Zeng Q, Liu Z. Analysis of virtual private LAN service (VPLS) deployment. Internet Draft September 2011.
  • 11
    Shah H, Rosen E. IP-only LAN service (IPLS). Internet Draft February 2007.
  • 12
    Shields C, Garcia-Luna-Aceves J. The HIP protocol for hierarchical multicast routing. Proc. 17th Annual ACM Symposium on Principles of Distributed Computing, Puerto Vallarta, IEEE, 1998.
  • 13
    Kovacshazi Z, Vida R. Host identity specific multicast. Networking and Services, 2007. ICNS. Third International Conference on, IEEE, 2007; 1–1.
  • 14
    Architectural considerations for backhaul of 2G/3G and long term evolution networks. Technical Report, CISCO Cooperation. 2010.
  • 15
    Alvarez MA, Jounay F, Major T, Volpato P. LTE backhauling deployment scenarios. Technical Report, Next Generation Mobile Networks Alliancen. 2011.
  • 16
    Moskowitz R, Nikander P, Jokela P. Host identity protocol. RFC 5201 April 2008.
  • 17
    Gurtov A. Host Identity Protocol (HIP): Towards the Secure Mobile Internet. Wiley, 2008.
  • 18
    Nikander P, Gurtov A, Henderson T. Host identity protocol (HIP): connectivity, mobility, multi-homing, security, and privacy over IPv4 and IPv6 networks. Communications Surveys & Tutorials, IEEE 2010; 12(2):186204.
  • 19
    Jokela P, Moskowitz R, Nikander P. Using the encapsulating security payload (ESP) transport format with the host identity protocol (HIP). RFC 5202 April 2008.
  • 20
    Kuptsov D, Khurri A, Gurtov A. Distributed user authentication in Wireless LANs. World of Wireless, Mobile and Multimedia Networks & Workshops, IEEE, 2009.
  • 21
    Rekhter Y, Li T, Hares S. A border gateway protocol 4 (BGP-4). RFC 4271 January 2006.
  • 22
    Andersson L, Doolan P, Feldman N, Fredette A, Thomas B. LDP specification. RFC 3036 January 2001.
  • 23
    Eddy W. TCP SYN flooding attacks and common mitigations. RFC 4987 August 2007.
  • 24
    Keller G, Beylot A. Improving flow level fairness and interactivity in WLANs using size-based scheduling policies. The 11th International Symposium on Modeling, Analysis and Simulation of Wireless and Mobile System. 2008.
  • 25
    Liyanage M, Gurtov A. Secured VPN Models for LTE Backhaul Networks , in Proc. of IEEE 76th Vehicular Technology Conference: VTC2012-Fall, Québec City, Canada September 2012.