Tunnelling:
GRE
tunnels, as mentioned previously, are generally configured between a source
(ingress) router and a destination (egress) router, such that packets
designated to be forwarded across the tunnel (already formatted with an
encapsulation of the data with the “normal” protocol-defined packet header) are
further encapsulated with a new header (the GRE header), and placed into the
tunnel with a destination address of the tunnel end-point (the new next-hop).
When the packet reaches the tunnel endpoint, the GRE header is stripped away, and
the packet continues to be forwarded to the destination as designated in the
original IP packet header
GRE
tunnels, as mentioned previously, are generally configured between a source
(ingress) router and a destination (egress) router, such that packets
designated to be forwarded across the tunnel (already formatted with an
encapsulation of the data with the “normal” protocol-defined packet header) are
further encapsulated with a new header (the GRE header), and placed into the
tunnel with a destination address of the tunnel end-point (the new next-hop).
When the packet reaches the tunnel endpoint, the GRE header is stripped away, and
the packet continues to be forwarded to the destination as designated in the
original IP packet header
Virtual
Private Dial Networks (VPDN’s)
While
there are several technologies (vendor-proprietary mechanisms as well as open,
standards-based mechanisms) available for constructing a virtual private dial
network (VPDN), there are two principal methods of implementing a VPDN which
appear to be increasing in popularity – L2TP and PPTP tunnels. From an
historical perspective, L2TP is the technical convergence of the earlier L2F
protocol specification and the PPTP protocol.
Link-Layer
VPN’s
One
of the most straightforward methods of constructing VPN’s is to use the
transmission systems and networking platforms for the physical and link-layer connectivity,
yet still be able to build discrete networks at the network layer. A link-layer
VPN is intended to be a close (or preferably exact) functional analogy to a
conventional private data network.
ATM
and Frame Relay Virtual Connections
A
conventional private data network uses a combination of dedicated circuits from
a public carrier, together with an additional private communications
infrastructure, to construct a network which is completely self-contained.
Where the private data network exists within private premises, the network
generally uses a dedicated private wiring plant to carry the VPN. Where the
private data network extends outside the private boundary the dedicated
circuits, it is typically provisioned for a larger public communications
infrastructure using some form of time-division and/or frequency-division
multiplexing to create the dedicated circuit. The essential characteristic of
such circuits is the synchronization of the data clock, such that the sender
and receiver pass data at a clocking rate which is fixed by the capacity of the
dedicated circuit
MPOA
(Multi-Protocol Over ATM)
Multi-Protocol
Over ATM, which uses RFC1483 encapsulation
This
VPN approach is similar to other “cut-through” mechanisms where a particular
switched link-layer is used to enable all “Layer 3” egress points to be only a
single hop away from one another.
Multi-Protocol
Label Switching
One
method of addressing these scaling issues is to use VPN labels within a single
routing environment, in the same way that packet labels are necessary to
activate the correct per-VPN routing table. If local label switching is used,
then this is effectively the architecture of an MPLS VPN. It is perhaps no
surprise that when presented with two basic approaches to the architecture of
the VPN – that of the use of network layer routing structures and per-packet
switching, and the use of link-layer circuits and per-flow switching – that the
industry would devise a hybrid architecture which attempts to combine aspects
of these two approaches. This hybrid architecture is
referred
to as Multi-Protocol Label Switching
Link-Layer
Encryption
As
mentioned previously, encryption technologies are extremely effective in
providing the segmentation and virtualization required for
VPN
connectivity, and can be deployed at almost any layer of the protocol stack.
There are no industry standards, per se, for link-layer
encryption,
thus all link-layer encryption solutions are generally vendor specific and
require special encryption hardware.
Transport
and Application Layer VPN’s
While
VPN’s can certainly be implemented at the transport and application layers of
the protocol stack, it is not very common. The most
prevalent
method of providing virtualization at these layers is to use encryption services
at either layer. For example, encrypted e-mail
transactions,
or perhaps authenticated DNS (Domain Name System) zone transfers between
different administrative name servers, as
described
in DNSSec (Domain Name System Security)
Non-IP
VPN’s
While
this paper has focused on TCP/IP and VPN’s, it is recognized that multiprotocol
networks may also have requirements for VPN’s.
Most
of the same techniques previously discussed here can also be applied to
multiprotocol networks, with a couple of obvious exceptions – a number of the
techniques described here are solely and specifically tailored for TCP/IP
protocols.
Quality
of Service Considerations
As
well as creating a segregated address environment to allow private
communications, there is also the expectation that the VPN environment will be
in a position to support a set of service levels. Such per-VPN service levels
may be specified either in terms of a defined service level that the VPN can
rely upon at all times, or in terms of a level of differentiation that the VPN
can draw upon the
common
platform resource with some level of priority of resource allocation.
Tunnelling
requires three different protocols:
•
Carrier protocol - The protocol used by the network that the information
is traveling over
•
Encapsulating protocol - The protocol (GRE, IPsec, L2F, PPTP, L2TP) that
is wrapped around the original data
•
Passenger protocol - The original data (IPX, NetBeui, IP) being carried
Tunnelling
has implications for VPNs. we can place a packet that uses a protocol not
supported on the Internet (such as NetBeui) inside an IP packet and send it
safely
over
the Internet. Or you could put a packet that uses a private (non-routable) IP
address inside a packet that uses a globally unique IP address to extend a
private network over the Internet.
In
a remote-access VPN, tunnelling normally takes place using PPP. Part of the
TCP/IP stack, PPP is the carrier for other IP protocols when communicating over
the network between the host computer and a remote system. Remote-access VPN
tunnelling relies on PPP.
•
L2F (Layer 2 Forwarding) - Developed by Cisco, L2F will use any
authentication scheme supported by PPP.
•
L2TP (Layer 2 Tunnelling Protocol) - L2TP is the product of a
partnership between the members of the PPTP Forum, Cisco and the IETF (Internet
Engineering Task Force).
Combining
features of both PPTP and L2F, L2TP also fully supports IPsec.
L2TP
can be used as a tunnelling protocol for site-to-site VPNs as well as
remote-access VPNs.
L2TP can create a tunnel between:
• Client and router
• NAS and router
• Router and router
