Computer network technologies and services/VPN

A company that wants to build a corporate private network for its remote terminals (single users, data-centers, branches) can adopt two different approaches:

• the company can build its own dedicated infrastructure (leased line, dial-up connection);
• the company can adopt a VPN solution.

A Virtual Private Network (VPN) allows a company to deploy connectivity to multiple users over a public shared infrastructure (the Internet or an Internet Service Provider's network) enforcing its own policies (such as security, quality of service, private addressing) as if it was its own private network.

The advantages of a VPN solution are:

• cheapness: expensive physical connections up to the remote users have not to be built anymore, but the VPN solution exploits a pre-existing infrastructure so that the cost is shared;
• selectivity: thanks to a firewall only the users having the rights can access → greater security;
• flexibility: allowed users can easily be added, and users can easily move.

A VPN is made up of some main components:

• data are delivered through tunnels, so they are separated by other data moving around over the shared infrastructure, by using protocols such as GRE, L2TP, MPLS, PPTP and IPsec;
• data are encrypted for a greater security, by using protocols such as IPsec and MPPE;
• data are checked for integrity, so they can not be tampered, thanks to TCP checksum or AH in IPsec;
• before a tunnel is set up, the identity of who is on the other side of the tunnel is checked through authentication mechanisms (for example by using digital certificates).

Classification

VPN solutions can be classified according to:

• deployment: access or site-to-site (intranet/extranet);
• internet access: centralized or distributed;
• model: overlay or peer;
• provision: customer or provider;
• layer: layer 2, layer 3 or layer 4;
• virtual topology: hub and spoke or mesh.

	overlay	peer
access	L2TP, PPTP
site-to-site	IPsec, GRE	MPLS

Deployment scenarios

VPNs can be deployed in two main scenarios:

• access VPN (also called 'remote VPN' or 'virtual dial in'): it virtualizes dial-up connection and connects a single user to a corporate network through ISDN, PSTN, cable modem, wireless LAN by using protocols such as PPTP and L2TP;
• site-to-site VPN: it virtualizes leased line and connects multiple remote networks one to each other by using protocols such as IPsec, GRE and MPLS.

Site-to-site VPNs can be deployed in two ways:

• intranet VPN: all the interconnected networks belong to the same company;
• extranet VPN: the interconnected networks belong to multiple companies.

VPN features must meet some requirements:

• security: a firewall can restrict access to network resources;
• data encryption: in order to protect information transmitted over the shared infrastructure;
• reliability: mission critical traffic has to be guaranteed to arrive at the destination;
• scalability: the solution must work for both small and large networks;
• incremental deployment: the solution keeps working as the network grows;
• additional requirements for access VPNs:
  • strong authentication: in order to verify mobile users' identities (e.g. a personal notebook may be stolen);
  • centralized management of users and their accounts;
• additional requirements for site-to-site extranet VPNs:
  • selected access: each company can give other companies the access to some services but prevent the access to other services of its private network;
  • address clash management: a private address may belong to two different private networks → a NAT is required;
  • use of an open, standard-based solution: different companies need to be able to share the same VPN solution;
  • traffic control: each company needs to control the amount of traffic coming in from the other company networks and to eliminate bottlenecks at network access points.

Internet access

A remote terminal connected to a VPN can access the public Internet in two ways:

• centralized internet access: all the traffic towards and from the Internet always passes through the headquarters VPN gateway;
• distributed internet access: the traffic towards and from the Internet does not involve the VPN, which is deployed only for corporate traffic.

Centralized internet access

Advantages

• centralized policy management: a company can set its own policies for internet access (e.g. forbidding employees to access certain websites while they are working) once for all the connected remote terminals;
• security benefit: the corporate firewall can protect hosts against malicious packets coming from the Internet.

Disadvantages

• lower speed at remote terminals: the packets towards and from the Internet have to travel for a higher number of hops because they always have to pass through the headquarters VPN gateway instead of heading directly towards the destination;
• higher bandwidth required at headquarters;
• compulsory connection: the VPN must be always active, that is the user must not be able to temporarily disable the VPN and surf the Internet without the corporate firewall protection, otherwise if he gets infected when he goes back to the VPN he will infect the corporate network because the traffic coming from him is not firewalled.

Distributed internet access

Advantages

• higher speed at remote terminals: the packets always head directly towards the Internet destination;
• voluntary connection: the user can disable the VPN any time without additional security threats.

Disadvantages

• distributed policy management: the company needs to configure multiple routers at the remote terminals in order to set its own policies;
• security threat: the corporate firewall protection is missing.

Models

• 
  Overlay model.
• 
  Peer model.

VPNs can be split into two models according to the role of the shared infrastructure:

• overlay model: the infrastructure is unaware of the VPN solution and offers just the IP connectivity service: it just carries packets, without knowing that they are VPN packets, between VPN gateways that don't interact with the infrastructure → good for data privacy: the manager of the infrastructure can not look at private data or he can not leverage routing information;
• peer model: the gateways inside the infrastructure participate to the creation of the VPN and interact among themselves → better routing, more scalability.

Non-MPLS-based peer-model VPNs can be:

• dedicated router: the manager of the infrastructure dedicates some routers altogether to a customer, some other ones altogether to another customer, and so on;
• shared router: each router in the infrastructure is shared among multiple customers → lower cost.

Provision

• 
  Provider provision.
• 
  Customer provision.

VPNs can be customer or provider provisioned:

• customer provision: the user creates and manages the VPN by himself, and tunnels are set up between Customer Edges (CE);
• provider provision: the VPN is provided and managed altogether by the provider of internet connectivity, and tunnels are set up between Provider Edges (PE).

The customer provisioned VPNs can not be peer-model because the provider can not be aware of a VPN self-created by the customer.

Layers

VPN connectivity can be at different layers:

• layer 2: Ethernet frames are exchanged in the VPN:
  • Virtual Private LAN Service (VPLS): it virtualizes a LAN: terminals are connected as if they were in the same LAN → broadcast packets are allowed;
  • Virtual Private Wire Service (VPWS): it virtualizes a leased line (over a packet-switching network);
  • IP-only LAN-like Service (IPLS): it virtualizes an IP network, but only IP (ICMP and ARP) packets are allowed;
• layer 3: IP packets are exchanged in the VPN;
• layer 4: TCP connections (possibly with SSL for security) are set up in the VPN.

Virtual topologies

VPNs can be split into two categories according to their virtual topology:

• hub and spoke: each pair of terminals can communicate to each other only by going through the headquarters → a bottleneck may occur at the headquarters due to the higher traffic;
• mesh: each pair of terminals can communicate to each other directly without going through the headquarters → routing is better, but the number of tunnels is higher.

Protocols

PPP

Point-to-Point Protocol (PPP) is a layer 2 protocol used in point-to-point connections (dial-up, ISDN) to encapsulate any protocol at upper layers. It is an extension to HDLC.

A PPP packet has the following format:

1 byte	1 byte	1 byte	1 or 2 bytes		2 or 4 bytes	1 byte
01111110 (flag)	Address	Control	Protocol	Data	CRC	01111110 (flag)

where the most significant fields are:

• leading and trailing flags: they are required for data framing;
• Address and Control fields: they are inherited from HDLC but they are completely meaningless in point-to-point connections; they were kept to make it simple to upgrade the processing algorithms in HDLC devices;
• Protocol field: it specifies the protocol at upper layer for the encapsulated packet.

'01111110' is the sequence delimiting the frame, but in order to send that sequence as data some stuffing rules are required. In PPP stuffing is at byte level: the escape sequence '01111101' is inserted both when a byte equal to the delimiting byte appears in the data, and when a byte equal to the escape byte itself appears:

Link Control Protocol (LCP) has the task of opening and closing PPP connections, negotiating some options (such as frame maximum length, authentication protocol).

GRE

An IP packet can not encapsulate directly a protocol at layer 3 or lower, because the 'Protocol' field in the IPv4 header can specify only protocols at upper layers (such as TCP, UDP, ICMP).

Generic Routing Encapsulation (GRE) is a protocol to encapsulate any protocol (including IP and other protocols at lower layers) into IP: the GRE header is inserted between the encapsulating IP header and the encapsulated packet, and the 'Protocol' field in the encapsulating IP header is set to 47.

The GRE header has the following format:

				5	8	13	16	32
C	R	K	S	s	Recur	Flags	Version (0)	Protocol type
Checksum (optional)								Offset (optional)
Key (optional)
Sequence number (optional)
Routing (optional) :::

where the most significant fields are:

• C, R, K, S flags (1 bit each one): they indicate the presence/absence of optional fields;
• strict source routing (s) flag (1 bit): if set to 1, the packet is dropped if, when the source route list ('Routing' field) ends, the destination has not been reached yet (similar to TTL);
• Recur field (3 bits): it specifies the allowed maximum number of additional encapsulations (currently not supported);
• Version field (3 bits): it specifies the version of the GRE protocol (0 in this case);
• Protocol type field (16 bits): it specifies the protocol of the encapsulated packet;
• Routing field: it specifies a sequence of IP addresses corresponding to the intermediate routers the packet should go through (source routing).

The 'Routing' field is in turn made up of some fields (besides the list of IP addresses), including:

• Address family field: it specifies the kind of addresses in the list (IP in this case);
• SRE Offset field: it is a pointer to the list item containing the IP address of the current next hop, updated on each source route hop;
• SRE Length field: it specifies the length of the list (in bytes).

Enhanced GRE

The format of the Enhanced GRE header introduces the new 'Acknowledgment number' field:

				5	8		13	16	32
C	R	K	S	s	Recur	A	Flags	Version (1)	Protocol type
Key (payload length)									Key (call ID)
Sequence number (optional)
Acknowledgment number (optional)

where the most significant fields are:

• Key field (32 bits):
  • payload length (16 bits): it specifies the packet length excluding the GRE header (in bytes);
  • call ID (16 bits): it specifies the session ID for the packet;
• Acknowledgment number field (32 bits): the sender puts in the packet the last packet sequence number it has received from the destination (cumulative ACK).

The new 'Acknowledgment number' field, in combination with the 'Sequence number' field, allows some additional mechanisms:

• flow control: sliding windows avoid destination flooding, and they are moved when ACK packets are received;
• out-of-order packet detection: Enhanced GRE was designed for PPP encapsulation, and PPP is a protocol for point-to-point connections where it is not expected packets arrive out-of-order → out-of-order packets are always discarded;
• lost packet detection: when a timeout expires, that is no ACKs have been received, the packet is detected as lost, but the detected lost packets are not re-transmitted;
• congestion control: when too many timeouts are detected, the packet transmission is slowed down not to congest the network.

L2TP

L2TP original reference scenario: provider provisioned deployment mode.

Layer 2 Tunneling Protocol (L2TP) is a protocol to tunnel any layer 2 protocol (PPP in this discussion) into IP. L2TP was originally designed for provider provisioned access VPNs and it was standardized by IETF; later it was extended to customer provisioned access VPNs by simply implementing the LAC functionality into the user machine.

In the L2TP original reference scenario, a remote user wants to send a packet through a point-to-point (PPP) connection to an internal server inside the corporate network. An L2TP tunnel to the target L2TP Network Server (LNS) and an L2TP session inside the tunnel are required to emulate the PPP connection over the service provider network.

When the PPP frame arrives at the L2TP Access Concentrator (LAC), if an L2TP tunnel has not been established yet to the LNS, before opening an L2TP session the LAC has to establish a tunnel to the LNS: the LNS authenticates itself to the LAC by using a challenge-based mechanism similar to Challenge Handshake Authentication Protocol (CHAP), and a new control connection is created.

Each L2TP session uses two channels inside the tunnel:

• data channel: to carry data messages, that is the PPP frames;
• control channel: to exchange control messages, aimed to manage the communication (such as verifying that packets arrive, retransmitting lost packets, checking the right order of packets).

In contrast to data messages, control messages are exchanged in a reliable way: lost control messages are always retransmitted.

Multiple sessions may coexist within the same tunnel, sharing the same control connection, to distinguish multiple flows of PPP frames from multiple remote users: each tunnel is identified by a tunnel ID, each session is identified by a session ID.

Security

Besides the authentication ensured during the tunnel establishing step, L2TP does not provide any security mechanism by itself: in fact it does not make sense to use mechanisms like encryption for L2TP packets travelling along the tunnel, because the service provider's LAC still can look at the layer 2 frames → any security mechanism has to be implemented end-to-end, that is between the user and the final destination inside the corporate network.
Optionally it is possible to use IPsec through the tunnel: it provides a strong security, but it is complicated to be implemented.

A packet inside the L2TP tunnel includes several encapsulated headers:

MAC header

IP header

UDP header

L2TP header

PPP header

PPP payload

PPP header

It identifies the point-to-point connection between the remote user and the internal server inside the corporate network.

L2TP header

It identifies the L2TP tunnel:

						8		16	32
T	L	0	S	0	O	P	0	Version (2)	Length
Tunnel ID									Session ID
Ns									Nr
Offset size									Offset pad :::

where the most significant fields are:

• T flag (1 bit): if set to 0 the packet is a data message, if set to 1 it is a control message;
• Tunnel ID field (16 bits): it identifies the L2TP tunnel;
• Session ID field (16 bits): it identifies the L2TP session, that is the data channel in the tunnel;
• Ns field (16 bits): it contains the sequence number of the data/control message;
• Nr field (16 bits): it contains the sequence number of the next control message to be received for a reliable control connection.

UDP header

Why is a layer 4 protocol such as UDP used to move layer 2 frames? This can be explained by considering firewalls over a general network: if a packet does not contain a layer 4 encapsulation, it is easier to get discarded by firewalls.
Another possible reason is that layer 4 can be accessed through sockets, while the operating system is in charge of layer 3. Since L2TP wants to be a solution against PPTP (proposed by operating system vendors), L2TP designers wanted to make it accessible to the applications and not to be tight to the will of the operating system vendors.
It is also possible to use a different layer 4 protocol (such as ATM, Frame Relay).

IP header

It contains the IP addresses of the tunnel endpoints.
In the original reference scenario, the IP addresses correspond to the LAC and the LNS.

PPTP

PPTP original reference scenario: customer provisioned deployment mode.

Point-to-Point Tunneling Protocol (PPTP) is a protocol to tunnel the PPP protocol into IP. PPTP was originally designed for customer provisioned access VPNs and it was developed by major operating system vendors; later it was extended to provider provisioned access VPNs by introducing a PPTP Access Concentrator (PAC) with functionality similar to the LAC one.

The PPTP original reference scenario differentiates itself from the L2TP one for the fact that the PPTP tunnel is established between the remote user itself and the PPTP Network Server (PNS).

In contrast to L2TP, PPTP provides weak (optional) security mechanisms: the standard covers the usage of specific Microsoft-proprietary security protocols such as MPPE for encryption and MS CHAP for authentication, so there is not any negotiation of protocols.

Data channel

The encapsulated PPP frames go through the data channel:

IP header

GRE header

PPP header

PPP payload

PPTP uses the Enhanced GRE protocol to encapsulate the PPP frames into IP. The PPP payload can be optionally encrypted by MPPE.

Control channel

The PPTP control messages go through the control channel:

IP header

TCP header

PPTP control message

Control messages are required for tunnel data session setup, management and tear-down, and they are sent to the well-known TCP port 1723 of the PNS.

IPsec

The functionality of the Internet Protocol Security (IPsec) protocol suite in IPv4 is very similar to the one in IPv6: Computer network technologies and services/IPv6#IPsec.

The main difference is that in IPv6 IPsec is an extension header included in the standard, while in IPv4 it is a new additional protocol encapsulated into IP (for AH the 'Protocol' field is set to 51, for ESP it is set to 50):

Authentication Header (AH).

IPv4 header	AH header	TCP/UDP header	payload
authenticated data

Encapsulating Security Payload (ESP).

IPv4 header	ESP header (for encryption)	TCP/UDP header	payload	ESP header
		encrypted data
	authenticated data

SSL

Secure Sockets Layer (SSL), today called Transport Layer Security (TLS), is a cryptographic protocol which is designed to provide communication security between a client and a server:

1. the client opens a TCP connection on port 443 with the server, and sends a challenge for server authentication;
2. the server sends to the client a Hello message containing its certificate and the response to the challenge encrypted by the server's private key;
3. the client verifies the certificate by looking into a list of certificates given by a trusty certification authority, then it decrypts the response to the challenge by using the server's public key;
4. the client decides a private key for the secure communication and sends it to the server by encrypting it through the server's public key → from this point on all record messages will be encrypted by using that private key (which should be periodically renegotiated);
5. often the server asks the user to type its username and password on a web page for client authentication (at application layer).

Access VPNs

Dial-up connection scenario

Basically a remote user, typically an employee of a company, wants to contact a server going through the corporate network. He can establish a dial-up point-to-point connection to the corporate gateway using PPP to encapsulate the IP packets:

• through Link Control Protocol (LCP) he can negotiate the layer 2 parameters (such as the authentication protocol);
• through Network Control Protocol (NCP) he can negotiate the layer 3 parameters (such as the private IP address within the corporate network, the DNS).

Before accepting the dial-up connection, the corporate gateway checks the user by contacting the corporate security server through the Remote Authentication Dial In User Service (RADIUS) protocol. The corporate security server is a centralized AAA server:

• Authentication: identifying the user (e.g. through user name and password);
• Authorization: checking which services the user can access and which ones are restricted to the user;
• Accounting: keeping track of the user activity (e.g. for billing).

Access VPNs can virtualize dial-up connections between a remote user and the corporate network over the service provider shared infrastructure to reduce costs. PPP protocol will keep being used encapsulated in VPN tunnels, avoiding to change too much the corporate gateway.

Customer provision

Access VPN deployed as customer provision.

In customer provisioned access VPNs, the tunnel is established between the remote user and the corporate gateway:

1. the user requests to establish a PPP dial-up connection to the service provider NAS, asking for negotiating the configuration parameters for the connection through LCP and NCP;
2. the NAS checks the user identity through the provider security server by using the RADIUS protocol;
3. the NAS provides the user with the configuration parameters for the PPP dial-up connection, in particular the public IP address;
4. the user requests to open a VPN tunnel with the corporate gateway, by sending a PPP frame containing an IP packet whose destination IP address is the public IP address of the corporate gateway;
5. the NAS forwards the request over the service provider network to the corporate gateway;
6. the corporate gateway checks the user identity through the corporate security server by using the RADIUS protocol;
7. the corporate gateway provides the user with the configuration parameters for the VPN tunnel, in particular the private IP address within the corporate network;
8. the NAS forwards the corporate gateway reply to the remote user.

Once the VPN is set up, the user has got two IP addresses: a public one for the service provider NAS and a corporate one for the corporate gateway. The PPP frames the user can send through the tunnel have the following format:

PPP header	IP header		PPP header	IP header		IP payload
	src:	public IP address of the user		src:	corporate IP address of the user
	dst:	public IP address of the corporate gateway		dst:	corporate/public IP address of the final destination

Advantage

The user is independent of the service provider: the latter in fact provides the user with just the internet connection to the corporate gateway.

Disadvantage

The user may temporarily disable the VPN connection and connect to an external server over the Internet → if he gets a malware, when he goes back to the VPN he will infect the corporate network.

Provider provision

Access VPN deployed as provider provision.

In provider provisioned access VPNs, the tunnel is established between the service provider NAS and the corporate gateway:

1. the user requests to establish a PPP dial-up connection to the corporate gateway, asking for negotiating the configuration parameters for the connection through LCP and NCP;
2. the NAS checks the user identity through the provider security server by using the RADIUS protocol, in particular identifying the user as a VPN user;
3. the NAS requests to open a VPN tunnel, related to the user, with the corporate gateway, by sending an IP packet whose destination IP address is the public IP address of the corporate gateway;
4. the corporate gateway checks the user identity through the corporate security server by using the RADIUS protocol;
5. the corporate gateway provides the NAS with the configuration parameters for the VPN tunnel;
6. the NAS optionally logs the acceptance and/or the traffic to charge the company for the service;
7. the corporate gateway provides the user with the configuration parameters for the PPP connection (dial-up is virtualized), in particular the private IP address within the corporate network;
8. the NAS forwards the corporate gateway reply to the remote user.

Once the VPN is set up, the user has got only the corporate IP address, unaware of the tunnel between the service provider NAS and the corporate gateway. The IP packets the NAS can send through the tunnel have the following format:

IP header		PPP header	IP header		IP payload
src:	public IP address of the service provider NAS		src:	corporate IP address of the user
dst:	public IP address of the corporate gateway		dst:	corporate/public IP address of the final destination

Advantage

The user can not access the Internet without going through the corporate gateway (centralized access) → greater security.

Disadvantage

The user is not independent of the service provider: in fact if he changes service provider the VPN connection will not work anymore.

Site-to-site VPNs

IPsec-based VPNs

In IPsec-based VPNs, IPsec is used in tunnel mode between the VPN gateways: the IP packet between two hosts is encapsulated into an IP packet, having the ESP header (and optionally the AH header), between the two VPN gateways, so that also the IP addresses of the two hosts can be encrypted by ESP.

The private intranet can be protected by:

• a firewall: it filters the traffic according to the corporate policies about for example the allowed IP addresses, and it can be put at different locations in relation to the VPN gateway:
  • before the VPN gateway: the VPN gateway is protected, but the firewall can not filter the VPN traffic because it is encrypted;
  • after the VPN gateway: the firewall can filter the decrypted VPN traffic, but the VPN gateway is not protected;
  • in parallel with the VPN gateway: the packets go through the firewall both before and after the VPN gateway, so the VPN gateway is protected and the VPN traffic is filtered, but the workload for the firewall is higher;
  • integrated into the VPN gateway: both the functionalities of VPN gateway and firewall are integrated into a single device → maximum flexibility;
• an Intrusion Detection System (IDS): it observes the traffic trying to detect whether there are attacks going on, and two IDS probes are put in parallel with the VPN gateway:
  • the probe before the VPN gateway observes the traffic coming from the tunnel and protects from attacks coming from the shared infrastructure;
  • the probe after the VPN gateway observes the VPN traffic and protects from attacks coming from the corporate network (e.g. malware installed on employee PCs, attacks from another company if the site-to-site VPN is extranet).

The presence of NATs may cause problems with IPsec:

• AH authenticates the whole packet, so it also covers the IP header → NATs need to change IP addresses, so authentication will no longer work;
• ESP encrypts the payload, so NATs located along the tunnel will not be able to see encrypted IP addresses and TCP/UDP ports to deal with different VPN sites.

MPLS-based VPNs

Layer 2: PWE3

Example of MPLS-based layer 2 site-to-site VPN.

The Pseudo Wire Emulation End-to-End (PWE3) standard allows to emulate wires over an MPLS network to exchange Ethernet frames between layer 2 terminals such as Ethernet switches or phone switches. This type of connection requires some requirements in terms of constant delays of Ethernet frames like they traveled over a physical wire.

Traffic is carried through an LSP, then it needs to be able to go to one of multiple sites connected to different interfaces of the ingress/egress LSR:

• external label: it identifies the LSP between two ingress/egress LSRs, and it is followed by one of multiple internal labels;
• internal label: it identifies the VPN tunnel for a company, and the ingress/egress LSR uses it to send the frame out of one of its interfaces towards the site of the company.

MPLS-based layer 2 VPNs do not take advantage of all MPLS benefits, because routing protocols for traffic engineering work very well with IP → usually LSPs are configured manually.

Layer 3: BGP

Example of MPLS/BGP layer 3 site-to-site VPN.

Border Gateway Protocol (BGP) was extended to internal BGP and external BGP to support the deployment of VPNs over MPLS, for example for company A's site 1:

1. company A's CE1 advertises to PE1 the destinations within the site 1, that is it tells PE1 all the IP addresses that can be reached within the site 1, through the internal BGP;
2. PE1 assigns a label to each IP address from CE1 and it records the mapping into a VPN Routing and Forwarding (VRF) table specific for its port towards CE1;
3. PE1 advertises the chosen labels to the other PEs through the external BGP by sending packets containing each one an IP address plus a route distinguisher identifying the address family, that actually is the port towards the company A's site, useful in case there are two identical private addresses in two different corporate networks.
   This step needs to be performed manually: the system administrator has to open a peering session between PE1 and each one of the other PEs in the MPLS network;
4. the other PEs can either process the advertisement messages or ignore them:
   • each other PE which one of company A's sites is connected to (in the picture PE3) records into its VRF table the advertisement information from PE1, that is the chosen label for each IP destination within the site 1, in other words IP addresses associated to the site 1's address family, plus PE1's IP address;
   • each other PE which no company A's sites are connected to (in the picture PE2) just ignores the advertisement information from PE1;

Once the IP destinations have been advertised among the PEs, VPN data can begin to be sent along the MPLS LSPs, for instance from company A's CE3 to company A's CE1:

1. PE3, that is the ingress LSR, pushes two labels into the label stack:
   • internal label: the one previously advertised by PE1;
   • external label: the one decided by LSRs through MPLS label binding, distribution and mapping protocols for the LSP from PE3 to PE1;
2. intermediate LSRs do not care about the internal label, but they operate just on the external label along the LSP;
3. the last LSR just before PE1 strips off the external label (penultimate label popping) and it sends the packet to PE1;
4. PE1, that is the egress LSR, searches its VRF tables for the internal label and it finds the port where to send the packet out, then it strips off also the internal label and it sends the packet to CE1.

Advantage

This solution is very scalable:

• each intermediate LSR has to deal with as many LSPs as PEs are, not as many LSPs as IP destinations are;
• each PE has to deal with as many VRF tables as the sites connected to it are.

Disadvantage

The peering sessions between the PEs are to be configured manually.

This solution does not provide any cryptography because it is provider provisioned and the company needs to trust the service provider.

Layer 3: virtual router

Example of MPLS/virtual router layer 3 site-to-site VPN.

In MPLS-based VPNs with virtual routers, each PE runs a (virtual) router instance for each company which is connected to it, so that every instance has to deal with just one corporate network → the protocol is simpler because it has to deal with just one VPN at a time, but scalability is lower because the router instances need to be configured manually.

SSL (pseudo)VPNs

SSL can be used to create site-to-site and access VPNs, but it is mostly used in SSL (pseudo)VPNs to grant a secure access to services (such as web service, e-mail) through TCP/UDP-based tunneling. The main advantage for SSL (pseudo)VPNs is that they have a good chance of working on any network scenario, without any problems in traversing NATs, firewalls or routers, and SSL services can also be accessed by web browsers through HTTPS.

Comparison to alternative solutions

Comparison to IPsec

Advantages

SSL is more convenient than IPsec in terms of:

• usage: IPsec has too many options to be configured and administered, while SSL just requires to compile the application along a library implementing SSL;
• security: it works at application layer → an attack to SSL just involves the application and not the whole operating system;
• maturity: it has been used for a lot of years over a lot of versions → few bugs in code;
• compatibility with NAT traversal:
  • no authentication of IP header because SSL is on top of the transport layer;
  • no encryption of ports as with IPsec ESP.

Disadvantage

SSL is critical with DoS attacks: packets always need to be processed up to transport layer, while in IPsec they are dropped already at network layer.

Comparison to PPTP

SSL overcomes some PPTP issues:

• poor interoperability with non-Microsoft platforms;
• some network administrators may configure their routers to block GRE, on which PPTP is based, due to the fact that they do not like source routing feature.

SSL (pseudo)VPN flavors

Web proxying

The web server does not support HTTPS → a 'VPN gateway', at the edge of the corporate network, downloads web pages from the web server through HTTP, and ships them to the user, outside the corporate network, through HTTPS.

Port forwarding

The client runs an application supporting an application protocol (such as FTP, SMTP, POP3) → a port forwarder installed on the client converts packets, sent to a specific port, from the application protocol into HTTPS packets sending them from another port, and vice versa.

Application translation

The web server is an application server (e.g. mail server) supporting an application protocol (such as FTP, SMTP, POP3) → the 'VPN gateway' converts HTTPS into the application protocol and vice versa through a port forwarding mechanism implemented inside the 'VPN gateway'.

SSL'ed protocols

Some application protocols can natively integrate SSL into themselves (e.g. SMTP-over-SSL, POP-over-SSL) → client and web server can directly communicate in a secure way without the need for translation by a 'VPN gateway'.

Application proxying

The client uses a SSL'ed protocol, but the web server does not support it → a 'VPN gateway' is still required with port forwarding mechanism.

Network extension

Both the client and the web server do not support SSL → two 'VPN gateways' are required, one at the user side and the other one at the web server side, so the SSL tunnel is created between the two 'VPN gateways'.