Special Multicast and IPv6 Tunneling (RFC 2473, RFC 3053)
IPv6 over IPv4 tunneling is done via the command sequence iptunnel mode sit under Linux. gif devices under Open/FreeBSD can handle arbitrary IPv4/IPv6 transport and carrier combinations. DVMRP erects IP-IP tunnel for multicast transport over the unicast Internet. Distance-Vector Multicast Routing Protocol (DVMRP) operation and termination affects manually configured IP-IP tunnels. For a more detailed discussion of multicasting concepts and DVMRP tunnels, see Chapter 14, "Multicast Architectures."
Cisco L2F (Layer 2 Forwarding)
L2F was designed by Cisco Systems (RFC 2341) to support the creation of secure VPDNs via tunnels over public infrastructure. The primary goal was (quoted from RFC 2341) "to divorce the location of the initial dial-up server from the location at which the dial-up protocol connection is terminated and access to the network provided."
This is primarily of interest for carriers and service providers with regard to VPDN design, aggregation, and so on. L2F has been superseded by L2TP, does not provide encryption, and is rarely used anymore. It was one of the first scalable approaches to VPDNs. L2F uses port 1701/udp and supports PPP/SLIP as encapsulated payload protocols. For an overview discussion, see the Cisco.com white papers "L2F Case Study Overview" (http://www.cisco.com/en/US/tech/tk801/tk703/technologies_design_guide_chapter09186a00800de9d6.html) and "Understanding VPDN" (http://www.cisco.com/en/US/tech/tk801/tk703/technologies_tech_note09186a0080094586.shtml).
PPTP (Point-to-Point Tunnel Protocol)
PPTP (RFC 2637) has received quite some attention—both praise and flames—because of its integration into the Windows operating system in combination with Microsoft Point-to-Point Encryption (MPPE) to realize on-demand VPN client access. MPPE works as a subfeature of Microsoft Point-to-Point Compression (MPPC) and provides encryption for PPP links.
PPTP itself does not provide encryption. It is used in client/server setups with enterprise remote-access servers (RASs) and was not designed with support for gateway-to-gateway tunnels in mind. MPPE is multiprotocol-capable, uses MS Challenge Handshake Authentication Protocol version 2 (CHAPv2) for authentication, and supports 40-bit and 128-bit encryption based on the RSA RC4 algorithm to provide data confidentiality. PPTP is based on an enhanced GRE approach. It is documented widely, and tons of example setups for Microsoft and UNIX are available. For further information, look at the RFCs relevant to MPPC (RFC 2118) and MPPE (RFC 3078/3079).
PPTP uses TCP/1723 to set up its control channel and IP protocol 47 (GRE) to move data. Enabling PPTP traffic to flow through a firewall requires you to establish bidirectional rules for both sets of traffic.[2]
This book does not provide a thorough discussion of PPTP in practice for several reasons:
- It is not that relevant in non-Microsoft environments. There are far better choices for tunnel setup for UNIX and Cisco integrated architectures.
- PPTP is deprecated, and Microsoft has moved on to L2TP/IPSec as a strategic technology.
- Many documents, recipes, and configurations are available with regard to PPTP setups involving Microsoft clients and RAS servers (and for PPTP configurations in context with DSL setups, which are common in some European countries).
The following list identifies the most mature PPTP implementations for Linux and BSD operating systems:
- UNIX PPTP Client Package— This is the recommended client package for Linux and BSD and integrates well with the PoPToP server. (http://pptpclient.sourceforge.net/)
- PoPToP— An OpenSource PPTP server for Linux and BSD that works perfectly with the PPTP client package. (http://www.poptop.org/)
- MPD— A multilink PPP daemon for FreeBSD. It is a robust and mature implementation based on the FreeBSD Netgraph facility. (http://www.dellroad.org/mpd/index)
- PPTP-Proxy— A useful daemon that forwards a PPTP VPN connection through a Linux firewall. (http://www.mgix.com/pptpproxy/)
- The MPPE/MPPC kernel module for Linux— This is an alternative to user-space approaches. It requires patching pppd and the kernel sources. It works with the current 2.4 Linux kernel. (http://www.polbox.com/h/hs001)
Exercise 11-2: PPTP on UNIX
Use PPTP Client and PoPToP to familiarize yourself with the UNIX implementation. For example, you can set up DSL access or provide RAS services to Microsoft roaming users.
L2TP (Layer 2 Tunnel Protocol)
L2TP (RFC 2661, RFC 2888) unites the best features and approaches of L2F and PPTP. This reflects the name, too. L2TP is the preferred choice to realize state-of-the-art protocol-independent VPDNs and is a replacement for PPTP and L2F. L2TP uses port 1701/udp and protocol number 115; adjust possible security filters accordingly.
Securing L2TP Using IPSec (RFC 3193)
Although L2TP supports tunnel endpoint authentication, it lacks a tunnel-protection mechanism. However, because it encapsulates PPP, it inherits PPP authentication and the PPP Encryption/Compression Control Protocol (ECP/CCP). The IPSec protocol suite provides features such as tunnel authentication, privacy protection, integrity checking, and replay protection at the network layer for IP networks.
L2TP Operation
L2TP offers the capability to separate the actual call termination of Layer 2 connections such as plain old telephone service (POTS), Integrated Services Digital Network (ISDN), or Digital Subscriber Line (DSL) from the transport of the associated PPP session. This means that the terminating device (modem line card, DSLAM) can reside geographically and logically separated from the network access server (NAS). The PPP sessions are tunneled from the concentrator/aggregator device to the NAS architecture, and the PPP call is terminated there. Therefore, L2TP is a logical extension of PPP over a packet-switched (IP) infrastructure.
Modern DSL metro architectures consisting of DSLAMs, aggregator devices, and service-selection gateways facilitating L2TP tunnels to transport large quantities of PPP sessions represent good examples of L2TP deployment. L2TP is downward compatible with L2F and works with NAT. The latest-and-greatest gadgets and gizmos are included in the L2TPv3 standards.
L2TP also offers a potential solution to the multilink-multichassis hunt-group problem: The strict requirement that all channels composing a multilink bundle must reside on the same NAS can be circumvented.
L2TPv3 and Related "Work in Progress"
L2TP's evolution is determined largely by its usefulness for Internet service providers (ISPs), with occasional features finding their way into enterprise networking (such as IPSec). To sum it up, L2TPv3 offers the following:
- A clearer separation from PPP
- Extended address-value pairs (AVPs)
- 32-bit session ID and control connection ID
- Pseudo wire extensions for High-Level Data Link Control (HDLC) and Frame Relay transport
- Transport of Ethernet and VLAN frames over L2TP pseudo wires
- Header compression
- Multicast extensions
L2TPd for UNIX: A Project in Transition
This package (http://www.l2tpd.org) is not considered production grade, but it is reported to work with Cisco L2TP setups, the Microsoft implementation, and L2TP/IPSec combinations. It is the only implementation for UNIX I am aware of. If you encounter problems, try the previous package at http://sourceforge.net/projects/rp-l2tp.
Form your own opinion as to whether L2TPd for UNIX is stable enough for your purposes. If you have questions, consult the mailing list at http://www.l2tpd.org and be sure you have a good foundation in PPP debugging. The terms LNS and LAC are IETF lingo and mean L2TP network server and L2TP access concentrator, respectively.
Figure 11-3 presents a standard L2TP architecture useful for most applications
Mobile IP
Mobile IP is both part of IPv4 and IPv6 (RFC 3344, RFC 2004) and enables a host device to roam different networks regardless of the access technology identified by a single fixed IP address, without the need for user intervention. Mobile IP uses protocol number 55, which is supported by the gre pseudo-device on OpenBSD. The implications are vast and the applications obvious—from cell phones over PDAs or handhelds to notebooks accessing the Internet via 802.11 Wi-Fi, GPRS, UMTS, Bluetooth, or other emerging access technologies. The challenge essentially is to provide routing reachability for roaming users/devices in combination with adequate security measures.
RFC 2002 introduces the concept of "mobile nodes" identified by care-of address, home agents, and foreign agents. The connection between a foreign and a home agent occurs via a virtual secure point-to-point tunnel of some sort (IP-IP or GRE). The mobile IP connection setup includes agent discovery (foreign and home) by the mobile user device, registration (with the foreign and the home agent), and the actual reverse tunneling from the home agent to the foreign agent. Both agents advertise their service via an extended version of the Internet Router Discovery Protocol (IRDP) to potential roaming customers. As in plain IRDP operation, the mobile node can send out agent solicitations and trigger agent advertisements. RFC 3519, "Mobile IP Traversal of Network Address Translation (NAT) Devices," covers this subject in detail.
If You Enjoyed This Post Please Take a Second To Share It.
You Might Also Like
Stay Connected With Free Updates
 |
 |
 |
|
Subscribe via Email
|
