MPLS provides the flexibility to link VPN sites in a number of ways. When several VPNs get access to a shared part of network infrastructure, this is called an extranet. Technically, extranets are constructed by using route-targets to determine which routes get included into which VRF. The VPNs export their own routes, or a subset thereof, such that the extranet VRF can import them. The command route-target export in the VRF controls this behavior. The extranet VRF exclusively exports its own routes to both VPNs. This way, both VPNs know the route to the extranet.

The following are additional security considerations for extranet VPN deployment:

1. Strong user authentication mechanisms should be enforced.

2. The VPN entry point should be placed inside a DMZ to prevent partners from accessing the internal network.

3. Access rights should be granted on an as-needed basis. Only necessary resources should be available to external partners. Owners of these resources should review access permissions regularly.

There are typically two types of Extranets that can be defined using the architecture; Central Services Extranet and Distributed Extranet. The Central Services Extranet provides connectivity between spoke VPN sites through a central PE router.  This PE router carries routes for all members of the extranet whereas spoke PE routers carry only local routes, and a route to the central PE router.  To support this type of configuration, the central PE router needs to carry <key, key- identifier> mappings for ALL members of the extranet.  On receiving an incoming update, the central PE is able to identify which key to use on the UPDATE-authenticator attribute by looking at the key- identifier carried within the update. The Distributed Extranet model provides connectivity directly between members of a given VPN.  This means that each PE router that holds members of the extranet is configured to import the relevant “route- target” values used for export by other members of the VPN.  Using the key-identifier, a PE router is able to identify which key to use on an incoming update to verify the source.  This means that each PE router within the extranet MUST carry <key, key-identifier> mappings for all members of the VPN.


The following are general security considerations for VPN users:

1. Strong authentication is required when users are connecting dynamically from disparate, untrusted networks, for example:

a) By means of certificates and/or smart cards, or tokens:A smart card is used to store a user profile, encryption keys and algorithms. A PIN number is usually required to invoke the smart card. A token card provides a one-time password. When the user authenticates correctly on the token by entering the correct PIN number, the card will display a one-time passcode that will allow access to the network.

b) By means of add-on authentication system, like TACACS+, RADIUS.This kind of central authentication system contains a profile of all VPN users, controlling the access to the private network.

2. Personal firewalls should be installed and configured properly on client VPN machines to block unauthorised access to the client, ensuring it is safe from attack. Many of the more recent remote access VPN clients include personal firewalls. Some may also include other configuration checks, such as the client not being able to connect to the network if anti-virus software is not running, or if virus signatures are out of date.

3. The client machine should have anti-virus software installed, with up-to-date signatures, to detect and prevent virus infections.

4. The user should remain aware of the physical security of the machine, in particular when authentication information is stored on the machine.

5. All users should be educated on good Internet security practices. Access from home should be considered an insecure channel, as traffic is routed over the Internet.


The following is general security advice for VPN deployment:

1. VPN connections can be strengthened by the use of firewalls.

2. An IDS / IPS (Intrusion Detection / Prevention System) is recommended in order to monitor attacks more effectively.

3. Anti-virus software should be installed on remote clients and network servers to prevent the spread of any virus / worm if either end is infected.

4. Unsecured or unmanaged systems with simple or no authentication should not be allowed to make VPN connections to the internal network.

5. Logging and auditing functions should be provided to record network connections, especially any unauthorised attempts at access. The log should be reviewed regularly.

6. Training should be given to network/security administrators and supporting staff, as well as to remote users, to ensure that they follow security best practices and policies during the implementation and ongoing use of the VPN.

7. Security policies and guidelines on the appropriate use of VPN and network support should be distributed to responsible parties to control and govern their use of the VPN.

8. Placing the VPN entry point in a Demilitarised Zone (DMZ) is recommended in order to protect the internal network.

9. It is advisable not to use split tunnelling to access the Internet or any other insecure network simultaneously during a VPN connection. If split tunnelling is used, a firewall and IDS should be used to detect and prevent any potential attack coming from insecure networks.

10. Unnecessary access to internal networks should be restricted and controlled.

Security Protocols for Traffic Security

IPsec makes use of the AH and ESP protocols to provide security services:

1. AH (Authentication Header) protocol provides source authentication, and integrity of IP packets, but it does not have encryption. An AH header added to the IP packet contains a hash of the data, a sequence number etc., and information that can be used to verify the sender, ensure data integrity and prevent replay attacks.

2. ESP (Encapsulated Security Payload) protocol provides data confidentiality, in addition to source authentication and integrity. ESP uses symmetric encryption algorithms, such as 3DES, to provide data privacy. The algorithm needs to be the same on both communicating peers. ESP can also support encryption-only or authentication-only configurations. However, research in 2007 showed that any RFC-compliant implementations of IPsec that make use of encryption-only ESP can be broken.

Modes of Operation

Each security protocol supports two modes of operation: a tunnel mode and a transport mode. Tunnel mode encrypts and/or authenticates the header and the data of each packet while transport mode only encrypts and/or authenticates the data itself.

-Tunnel mode (end-to-end)

Here the entire packet is protected. The original IP packet, with original destination address, is inserted into a new IP packet and the AH and ESP are applied to the new packet. The new IP header points to the end point of the tunnel. Upon receipt of the packet, the tunnel end point will decrypt the content and the original packet is further routed to its final destination in the target network.

-Transport mode (host-to-host)

Here the AH and ESP headers are applied to the data of the original IP packet. The mode encrypts and / or authenticates the data but not the IP header. The overhead added is less than that required in tunnel mode. However, the final destination and source addresses could be sniffed. Attackers can perform traffic analysis based on header information in this type of header. It is generally only used for host-to-host connections.

The Virtual Router Approach

A virtual router is a logical router that is associated with a particular geographic area. A virtual router comprises one or more physical mobile nodes currently within a geographical region served by the virtual router. Once within the geographical region of the virtual router, those physical nodes can take turns in forwarding data packets. In this environment, data packets are transmitted from a source node to a destination node over a series of virtual routers.

There can be two virtual router approaches: Static Virtual Router (SVR) and Dynamic Virtual Router (DVR).  A virtual router need not be a separate operating system process (although it could be); it simply has to provide the illusion that a dedicated router is available to satisfy the needs of the network(s) to which it is connected. A virtual router, like its physical counterpart, is an element in a routing domain. The other routers in this domain could be physical or virtual routers themselves. Given that the virtual router connects to a specific (logically discrete) routing domain and that a physical router can support multiple virtual routers, it follows that a physical router supports multiple (logically discreet) routing domains.

From the user (VPN customer) standpoint, it is imperative that the virtual router be as equivalent to a physical router as possible. In other words, with very minor and very few exceptions, the virtual router should appear for all purposes (configuration, management, monitoring and troubleshooting) like a dedicated physical router.

The aspects of a router that a virtual router needs to emulate are:

1. Configuration of any combination of routing protocols

2. Monitoring of the network

3. Troubleshooting

Every VPN has a logically independent routing domain. This enhances the SP’s ability to offer a fully flexible virtual router service that can fully serve the SP’s customer without requiring physical per-VPN routers. This means that the SP’s “hardware” investments, namely routers and links between them, can be re-used by multiple customers. Each Virtual Router is configurable by the PNA as though it were a private physical router. Of course, the SP limits the resources that this Virtual Router may consume on a SPED-by-SPED basis. Each VPN has a number of physical connections (to CPE routers) and a number of logical connections (to the emulated LAN). Each connection is IP- capable and can be configured to utilize any combination of the standard routing protocols and routing policies to achieve specific corporate network goals. The use of standard routing protocols such as OSPF and BGP in their unmodified form means that all the encryption and security methods (such as MD5 authentication of neighbors) are fully available in VRs. Making sure that routes are not accidentally leaked from one VPN to another is an implementation issue. One way to achieve this is to maintain separate routing and forwarding databases. All of the router monitoring features available on a physical router are available on the virtual router. This includes utilities such as “ping” and “traceroute”. In addition, the ability to display private routing tables, link state databases is available. ng.


Network Performance

In most cases, VPNs will perform worse than an identical network without a VPN, because VPNs must encrypt and decrypt the data. When testing your VPN solution, it is a good idea to see how it performs over time. Some VPN technologies give you different choices that might affect performance. You might find that one encryption cipher outperforms others on your hardware. In general, the weaker the encryption, the faster it is. Over time, your VPN performance will change, perhaps because new users are added, network needs are different, or your hardware starts failing. It would behoove you to have an idea of how your VPN performs now and has performed in the past, before your users start complaining. Networking is largely about connecting together devices so that information can be shared between them. Since the idea is to send data from one place to another, a very important characteristic of any network is its speed. This matter of speed turns out to be only one of several issues that determine the overall performance of a network. Not all networks are the same. As data is broken into component parts (often known frames, packets, or segments) for transmission, several factors can affect their delivery.

  • Delay: It can take a long time for a packet to be delivered across intervening networks. In reliable protocols where a receiver acknowledges delivery of each chunk of data, it is possible to measure this as round-trip time.
  • Packet loss: In some cases, intermediate devices in a network will lose packets. This may be due to errors, to overloading of the intermediate network, or to intentional discarding of traffic in order to enforce a particular service level.
  • Retransmission: When packets are lost in a reliable network, they are retransmitted. This incurs two delays: First, the delay from re-sending the data; and second, the delay resulting from waiting until the data is received in the correct order before forwarding it up the protocol stack.
  • Throughput: The amount of traffic a network can carry is measured as throughput, usually in terms such as kilobits per second. Throughput is analogous to the number of lanes on a highway, whereas latency is analogous to its speed limit.

These factors, and others (such as the performance of the network signaling on the end nodes, compressionencryption, concurrency, etc) all affect the effective performance of a network. In some cases, the network may not work at all; in others, it may be slow or unusable. And because applications run over these networks, application performance suffers. Various intelligent solutions are available to ensure that traffic over the network is effectively managed to optimize performance for all users.

Network Layer Security

TCP/IP is widely used throughout the world to provide network communications. TCP/IP communications are composed of four layers that work together.  When a user wants to transfer data across networks, the data is passed from the highest layer through intermediate layers to the lowest layer. The lowest layer sends the accumulated data through the physical network; the data is then passed up through the layers to its destination.  Essentially, the data produced by a layer is encapsulated in a larger container by the layer below it. Security controls exist for network communications at each layer of the TCP/IP model.  Data is passed from the highest to the lowest layer, with each layer adding more information. Because of this, a security control at a higher layer cannot provide full protection for lower layers, because the lower layers perform functions of which the higher layers are not aware.  The following items discuss the security controls that are available at each layer:

Application Layer.  Separate controls must be established for each application. For example, if an application needs to protect sensitive data sent across networks, the application may need to be modified to provide this protection. While this provides a very high degree of control and flexibility over the applications security, it may require a large resource investment to add and configure controls properly for each application. Designing a cryptographically sound application protocol is very difficult, and implementing it properly is even more challenging, so creating new application layer security controls is likely to create vulnerabilities. Also, some applications, particularly off-the-shelf software, may not be capable of providing such protection. While application layer controls can protect application data, they cannot protect TCP/IP information such as IP addresses because this information exists at a lower layer.  Whenever possible, application layer controls for protecting network communications should be standards based solutions that have been in use for some time.

Transport Layer.  Controls at this layer can be used to protect the data in a single communication session between two hosts. Because IP information is added at the network layer, transport layer controls cannot protect it. The most common use for transport layer protocols is securing HTTP traffic; the Transport Layer Security (TLS) protocol is usually used for this.  The use of TLS typically requires each application to support TLS; however, unlike application layer controls, which typically involve extensive customization of the application, transport layer controls such as TLS are much less intrusive because they simply protect network communications and do not need to understand the applications functions or characteristics. Although using TLS may require modifying some applications, TLS is a well-tested protocol that has several implementations that have been added to many applications, so it is a relatively low risk option compared to adding protection at the application layer instead.  One drawback of TLS is that it is only capable of protecting TCP-based communications, as opposed to UDP, because it assumes the network layer protocol is ensuring reliability.

Network Layer.  Controls at this layer apply to all applications and are not application-specific. For example, all network communications between two hosts or networks can be protected at this layer without modifying any applications on the clients or the servers. In many environments, network layer controls such as IPsec provide a much better solution than transport or application layer controls because of the difficulties in adding controls to individual applications. Network layer controls also provide a way for network administrators to enforce certain security policies. Another advantage of network layer controls is that since IP information (e.g., IP addresses) is added at this layer, the controls can protect both the data within the packets and the IP information for each packet.  However, network layer controls provide less control and flexibility for protecting specific applications than transport and application layer controls.

Data Link Layer.  Data link layer controls are applied to all communications on a specific physical link, such as a dedicated circuit between two buildings or a dial-up modem connection to an Internet Service Provider (ISP). Data link layer controls for dedicated circuits are most often provided by specialized hardware devices known as data link encryptions; data link layer controls for other types of connections, such as dial-up modem communications, are usually provided through software. Because the data link layer is below the network layer, controls at this layer can protect both data and IP information.  Compared to controls at the other layers, data link layer controls are relatively simple, which makes them easier to implement; also, they support other network layer protocols besides IP. Because data link layer controls are specific to a particular physical link, they are poorly suited to protecting connections with multiple links, such as establishing a VPN over the Internet. An Internet-based connection is typically composed of several physical links chained together; protecting such a connection with data link layer controls would require deploying a separate control to each link, which is not feasible. Data link layer protocols have been used for many years primarily to provide additional protection for specific physical links that should not be trusted.


Because of its traffic engineering capabilities, MPLS (Multi-Protocol Label Switching) is fast emerging as an attractive option for forwarding IP packets over multi-service backbones in wireline networks. MPLSbased VPNs are relatively easy to implement on GGSN based on routing platforms and, for this reason, are being heavily promoted by traditional router manufacturers (whose products lacking the scaleable support for other types of tunneling) trying to enter the wireless market. MPLS labels include distinct VPN identifiers that associate packets with private routing domains. This maintains both address secrecy, and the ability to handle duplicate or overlapping addresses. MPLS labelset-up protocols such as RSVP (Resource Reservation Protocol) or CR-LDP (Label Distribution Protocol) can communicate dynamic reachability information through the MPLS network. The fundamental building block for SpringTide 7000 Wireless MPLS based VPN is Virtual Router (VR). Virtual routers provide the secure, segregated environments required for delivering business-quality IP services. Each virtual router has its own routing information base (RIB), forwarding information base (FIB) and a separate MPLS data forwarding engine with its own code address space with memory, which prevents any one virtual router from affecting other virtual routers. Within each virtual router, individualized service definitions for bandwidth, priority, and security are retrieved from policy directories and provisioned on either a per-subscriber or per-traffic flow basis. Since virtual router is not run as a separate task in the underlying operating system, CPU resources and memory utilization are independent of other virtual routers in the same system. The performance of one virtual router does not affect other virtual routers in the system.

One method for deploying GPRS VPNs is using a combination of BGP-4 and MPLS protocols defined in RFC 2547. This implementation is relatively straightforward when GGSN supports both BGP-4 and MPLS. GGSNs (or Provider Edge (PE) devices) are tasked with associating Customer Edge (CE) devices into a VPN group by virtue of common MPLS labels that combine the VPN ID with address prefixes used within each private routing domain. The GGSN PE has knowledge of all of the networks to which it is directly connected via CE devices. This includes knowledge of which networks belong to which private domain. Using that information, each GGSN (PE) builds and maintains its forwarding table. The information is then shared with other PE routers by using techniques (attributes, communities, new address “families,”etc.) supported by the BGP-4 standard. With a complete set of reachability information, as well as the knowledge of which networks belong to which VPN, the PE routers can label packets with the information necessary to forward them through the MPLS core over LSPs. Although MPLS can be combined with IPSec for security and with L2TP to utilize the advantages of PPP, this approach can significantly degrade network performance.

Mobile VPNs

The foundation of a successful mobile deployment is a Mobile Virtual Private Network (VPN)—a solution providing mobile workers with secure, reliable, remote access to network resources and information from virtually anywhere. Only a Mobile VPN is designed to deal with the unique challenges associated with mobile computing such as wireless security, performance and roaming. An effective mobile VPN provides continuous service to users and can seamlessly switch across access technologies and multiple public and private networks. The functioning of an effective mobile VPN is transparent to the end user without compromising security or privacy.

A mobile VPN provides the same level of security as the traditional wired VPN solution but it is optimized for the challenges of the wireless world.  It provides session persistence and seamless roaming to create a reliable and seamless user experience when devices switch networks or move out of coverage. Advanced data compression increases the throughput and also provides significantly better performance in wireless networks with small bandwidth compared to a traditional VPN. Additionally, a true mobile VPN has a much smaller memory footprint and uses less processing power than a traditional VPN, enabling applications to run faster while the battery lasts longer.

Mobile IP VPNs use IP tunneling technologies. GPRS and UMTS-based VPNs use a combination of GPRS Tunneling Protocol (GTP) on the dynamic “mobile” tunnel side and IETF-defined tunneling protocols on the “fixed” side. The business benefits of deploying Mobile VPNs (MVPNs) are numerous. MVPNs provide remote workers with constant, media-independent connectivity to corporate sites or to the ISPs and ASPs of their choice. MVPNs also enable businesses and ISPs to outsource mobile remote access — thereby eliminating the costs of purchasing and supporting the infrastructure while maintaining full control over address assignments and user authentication and security. In this way, corporations can leverage the Internet to provide anytime/anywhere, secure connectivity to remote offices, SOHOs, mobile employees, e-commerce and extranet business partners over public network infrastructure. By enabling always on connectivity, there is the potential to enhance relationships with customers, business partners, and suppliers by sharing in real time information.

L2TP based MVPN

Standardized L2TP (RFC 2661) evolved from various proprietary protocols such as layer 2 forwarding (L2F) and point-to-point tunneling protocol (PPTP). It specifies improved interoperability between multivendor tunneling equipment by extending PPP connections over different devices in separate networks, as well as over multiple links and networks. L2TP in and of itself, is not fully secure. Although it can provide secure CHAP-like authentication of the L2TP control connection, the potential for tunnel hijacking by expert hackers remains a possibility. To fully secure L2TP tunnels, service providers can use standard IPSec mechanisms independently developed by IETF. Manually configured static security associations could be part of an SLA between the corporation and the wireless network operator. Or, dynamic negotiation procedures could be used, if a PKI is deployed and trusted by both parties.

L2TP operates in compulsory mode in which tunnels are supported by service provider network equipment. It also can operate in voluntary mode with tunnels initiated by mobile devices. L2TP compulsory service operation is made possible in GRPS and UMTS CN by the R’98 and RR ‘99 standards (PPP-relay case). To support this option, GGSN must support PPP-based PDP contexts on a significant scale. In this case, mobile VPN users access corporate networks by first attaching to the GPRS network and then initiating PPP sessions and specifying Access Point Names (APNs). Once the PDP context is active, control of the communication session is passed to the L2TP Access Concentrator (LAC) supported by GGSN, which triggers the establishment of a L2TP connection to the corporate L2TP Network Server (LNS) and performs GTP-to-L2TP tunnel switching. Newly-attached users can share previously established L2TP tunnels by creating new L2TP sessions within those pre-established tunnels. If the tunnel does not exist, a new tunnel will be created. The GGSN/LAC then uses the L2TP control connection to establish an L2TP call (L2TP tunnel to carry PPP) between the LAC and the LNS. Using the services of the corporate AAA system (e.g. RADIUS), the LNS performs the authentication of the mobile user. Following authentication, an IP address is assigned to the mobile using IPCP or other address assignment mechanisms. For corporate network management purposes, using private corporate intranet IP addresses is preferable. It also saves carrier’s limited number of public Internet addresses. Such communications, like security arrangements, are governed by SLAs or defined between a GGSN/LAC and corporate-based LNS. In compulsory service operations, the wireless operator assigns APN network identifiers to corporations according to certain rules. The APNs are used by the SGSN to select the GGSN to be addressed for a specific group of corporate mobile users. Using data stored locally or IP roaming mechanisms requiring LACs to query AAA subsystems using the mobile user’s Network Access Identifier (NAI), the GGSN determines the IP addresses of the GGSNs/LACs to which mobile users will be attached. L2TP-based GPRS VPNs carry a number of advantages over other MVPN technologies. L2TP also can be used in remote access solutions that allow ISPs and corporations (possessing extensive experience in deploying L2TP based networks) to effectively combine their wireless and wireline access by outsourcing the mobile access to wireless carriers. In addition, value-added services (i.e. load sharing, backup support) will be available from any access server vendor supporting L2TP and corporations with L2TP based VPNs can retain full control over IP address assignments and AAA functions.