|
|
VPNs can be created using technologies from Layer 2 or Layer 3. Layer 2 technologies are simpler than one of the two Layer 3 technologies. The other Layer 3 approach actually uses the same underlying concept as the various Layer 2 approaches: a logical tunnel for the traffic to hide in. All the Layer 2 technologies, and the Layer 3 tunnel approach, are sometimes described as an "envelope-within-an-envelope" approach: they encapsulate the packet in a tunneling header, which is further encapsulated in the regular Layer 2 or Layer 3 header. The idea is to hide the contents at least a little, inside an extra layer of encapsulation, while preserving a distinct traffic identifier in the additional header. All the Layer 2 or Layer 3 traffic is multiplexed on the same wire but distinguished internally by the extra header.
In classic leased circuits (which VPNs are tending to replace, so this capability is the minimum a customer requires), traffic was segregated by its virtual circuit (VC) number, among the many, many VCs multiplexed on a given pipe. That is, a Frame Relay DLCI or ATM VPI/VCI distinguished this circuit's traffic from all the other circuits' traffic.
Figure 4. Using Layer 2 Header to Distinguish Traffic
In order to use shared connectivity, especially the Internet, we must have some way to likewise distinguish one particular set of traffic from the rest. Tunneling offers us this, with the additional effect of adding another layer of header to encapsulate the interesting traffic (hide it, at least a little), though at a cost of some more overhead. The amount of overhead varies from type to type of Layer 2 tunnel approach. We'll look at four types of Layer 2 tunneling: Generic Routing Encapsulation (GRE), Point-to-Point Tunneling Protocol (PPTP), Layer 2 Forwarding (L2F), and Layer 2 Tunneling Protocol (L2TP). Tunneling really offers limited protection, but sometimes that is all that is required.
Generic Router Encapsulation was originally described in RFC 1701, and is further described in RFC 2784. The former is informational, while the latter is standards track and simplifies the header structure considerably. GRE is intended to be more general-purpose than the specific encapsulations previously offered in other RFCs. It is not limited to carrying just IP traffic; the Layer 3 traffic type is announced in the GRE header (in the Protocol Type field, using the RFC 1700 Ethertypes (listed on page 168 of that RFC). The entire original data packet, known as the payload, is encapsulated into a GRE packet, which is then further encapsulated into another protocol (known as the delivery protocol, essentially the Layer 2 protocol) and forwarded. The resulting packet structure is shown in Figure 5 with the RFC 2784 GRE header (8 bytes) broken out.
Figure 5. GRE Encapsulation
When IPv4 is the payload, the Protocol Type field must be set to 0x800. Forwarding of the decapsulated packet is based on the IPv4 destination, and the TTL in the IP header is decremented (no free rides). Depending on a firewall's implementation (i.e., whether or not it is able to look inside the layered encapsulations to the actual IP packet), it may be necessary to terminate a GRE tunnel at the firewall and create a new one (if necessary) from the firewall to the final destination.
Several GRE sample configurations, most authored by Cisco's TAC, are here. GRE is used in many different topologies, while our other Layer 2 approaches are more often used with dial-up scenarios. GRE is also the basis for a number of other encapsulations, most of which are also performed at Layer 2.
Point-to-Point Tunneling Protocol was developed by Microsoft for remote user tunneling, but Microsoft took a more decoupled approach than Cisco did with its Layer 2 Forwarding (our next topic). PPTP is intended to tunnel PPP through an IP network, using a GRE header. While it technically has been replaced by L2TP, there are still many installations where it is used, especially all-Microsoft networks.
PPTP separates the many functions of the ISP's network access server (NAS) into two groups: one performed by the PPTP access concentrator (PAC), which handles the PPP operations, and one performed by the PPTP network server (PNS), which handles the TCP/IP operations (or, if you prefer, the PAC for Layer 2 operations and the PNS for Layer 3/4 operations). The PAC terminates the user-to-ISP PPP Link Control Protocol session, and provides any required multiprotocol routing and bridging between the NAS's interfaces.
PPTP is a connection-oriented protocol, with the PAC and the PNS maintaining connection states for each attached user. There is a tunnel between the PAC and the PNS that carries session management datagrams using PPP. While many user sessions may be connected through this tunnel, there is a separate control connection operating over TCP within the tunnel to manage the user sessions' establishment, maintenance, and release as well as the tunnel's own operations. The control connection is initiated by either the PAC or the PNS (as needed) over TCP port 1723, and, of course, must be established first. The control connection is maintained by keepalives.
The rest of the data through the tunnel consists of user sessions, which are IP traffic encapsulating GRE header-encapsulated PPP traffic (which probably carries IP traffic inside it).
Figure 6. PPTP Tunneled Packet
PPTP obviously is rather "busy" on the NAS (creating the internal tunnel and maintaining it with keepalives), and it does add significant overhead per packet. However, it's easy for dial-up clients to use if they have a Microsoft OS -- and ease of use for the users likely to be least knowledgeable is often considered a good idea.
PPTP is used by Cisco primarily on VPN Concentrators designed to handle the session management and encapsulation workload; a table of supported client and Cisco hardware/software combinations is at http://www.cisco.com/warp/public/707/cmatrix.shtml. This links to a number of PPTP configuration examples.
Layer 2 Forwarding was developed by Cisco, and is primarily useful for tunneling remote users into the network via an Internet connection. For new applications, it has been replaced by L2TP (our final Layer 2 approach, coming up next). The user sends an IP packet, which is then encapsulated for transport to the ISP in a lower-layer protocol (a Layer 2 protocol appropriate to the connection type). L2F must be available as a protocol on the ISP's aggregation server, but this is not uncommon.
The user is authenticated by the ISP as a subscriber or other valid user (via a hotel, for instance). The ISP's network access server (NAS) then initiates an L2F tunnel to the corporate gateway. The corporate gateway must authenticate the user as a valid account and (if valid) accept the tunnel. The corporate gateway establishes a virtual PPP connection with the user via the ISP. The user's data consists of IP packets encapsulated in PPP for the corporate connection, plus the ISP's appropriate link layer protocol. At the ISP's NAS, the user-to-ISP link layer framing is stripped off and the L2F header is applied. The tunneled data is then sent to the corporate gateway, which strips off the L2F framing and the PPP framing and then proceeds as though this were another IP packet arriving. Traffic from the corporate network to the user follows a reverse path.
Figure 7. L2F Tunnel
L2F is upper-layer protocol independent; however, though it can support carriage of IPX or AppleTalk packets, those are less and less likely to be present. Usefully, though, L2F does support the use of private IP addressing nicely, since the logical connections are between the user and the corporate network. Connections between the user and the ISP, and between the ISP and the corporate gateway, are all conducted at Layer 2, based on physical addresses.
One significant disadvantage is the possibility of cleartext passwords being passed between the user and the ISP. The corporate gateway can be configured to use the ISP's authentication of the user, and that authentication may or may not be encrypted, depending on the security consciousness of the particular ISP. The L2F header is the basis of the L2TP header; a breakout of the latter is shown in Figure 8, below. L2F uses UDP port 1701 to initiate its connections.
While there is no handy set of links to L2F configurations, as there were for our two previous Layer 2 approaches, this link does offer a good example, along with links to other, more in-depth explanatory documents.
Now we had a situation where Microsoft (leaders on the desktop) and Cisco (leaders in the network) had come out with different solutions to the problems presented by establishing a dial-up connection to a corporate network. In the interest of making things work, Cisco and Microsoft combined forces to make such tunneling more manageable; they created Layer 2 Tunneling Protocol, which is described in RFC 2661. Like PPTP, L2TP disaggregates the NAS's functions between two entities: the L2TP access concentrator (LAC), which services the media handling the user side of the traffic, and the L2TP network server (LNS), which manages sessions as the server side of the connection. Again, there is a logical tunnel between these two entities, which carries a control channel and the users' traffic. And once again, the control traffic is in-band.
Figure 8. L2TP Header
Message traffic is distinguished by the Type flag in the L2TP header (0 = data traffic, 1 = control traffic). A priority bit is available among the flags. The control traffic messages must have sequence numbers for delivery assurance (connection-oriented delivery), while the user datagrams may or may not have sequence numbers (user sessions may be connectionless). The L2TP header is larger than the header used in other tunneling protocols; if the optional offset size field is used, the header will total 16 bytes.
Control messages, which include those used to authenticate users as part of session setup, may contain encrypted data in order to hide user passwords (which would otherwise be transmitted in cleartext, like the other tunneling protocols described to this point). Encryption is based on a preexisting shared secret, with a Random Vector message preceding the message in question to establish an initialization vector for the encryption.
Unlike the case with PPTP, in L2TP there may be multiple tunnels between the LAC and the LNS with different QoS values assigned to them. An example would be separate SVCs for each tunnel. Each tunnel may have as few as one user. Another difference from PPTP is that L2TP, like L2F, uses UDP port 1701 to initiate the session between the LAC and the LNS (vs. TCP 1723 in PPTP). The version number in the header is the distinguisher: L2F is version 1 and L2TP is version 2. Yet another improvement is that it is permissible for the peer's IP address or working UDP port to change over the lifetime of an ongoing session (such as in response to a network topology change).
A process similar to that of L2F or PPTP is used to establish the user - corporate server connection. The details are described in [Kaeo 1999]. The complete L2TP packet has grown somewhat compared to our previous forms of tunneling.
Figure 9. L2TP Packet
Another option is to use L2TP in conjunction with IPSec, if you feel a need for the added benefits of IPSec and L2TP for some or all of the link. In one situation, the tunnel between the LNS and the LAC is encrypted with IPSec because the tunnel may go over WAN links you cannot otherwise protect. This is L2TP-in-IPSec; an example configuration for this may be found at http://www.cisco.com/warp/public/707/24.html. If it helps, remember that there is an IPSec connection carrying the L2TP inside it (for L2TP-in-IPSec). Alternatively, you can make the endpoints of the connection -- the two hosts actually communicating -- the peers, and use IPSec between them to protect the entire communications path. Then, in the portion of the path between them that uses L2TP, you have IPSec-in-L2TP. A detailed example of this, complete with debug files, is at http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/vpdnsol/ipsec.htm.
There are variations on the tunnel endpoints vs. the IPSec endpoints; the key to terminology is really which protocol is engaged first and then carried inside the other. You may have IPSec protecting only a portion of the L2TP session (in which case you have L2TP-in-IPSec because the L2TP tunnel was created first, then encapsulated inside the IPSec SA), or you may have the IPSec SA initiated outside L2TP (in which case you have IPSec-in-L2TP because the L2TP will be engaged later to carry the IPSec traffic). Figure 10 shows the tunnel portions of the connections.
Figure 10. L2TP-in-IPSec and IPSec-in-L2TP
For another set of configuration examples, try here.
You may have noticed that, as we have progressed through these different forms of tunneling (in a loose chronological order of their creation), we have seen an increased sophistication in the system used to create the tunnels with a commensurate increase in the overhead required. Layer 3 tunneling, however, breaks with that fine tradition.
[IE-OVPN-WP1-F04]
[2003-07-07-01]
|