Archive 23 June 2007 #60
LIGHT AT THE START OF THE TUNNEL
by William Flanagan, Publisher
Last time, we covered virtual circuits in packet networks. This edition brings the concept of "tunnels" into the exploration of packet forwarding. As with packet routing, there's less than perfect clarity in the industry about what a tunnel is, exactly. We'll throw some light on tunnels before you get into your next one.
Perhaps the problem is that the term "tunnel" has no one (exact) meaning. As with the related concept of Virtual Private Network (VPN), there are several common forms of a network tunnel. The following describes some of them, very briefly:
-- L2TP (Layer 2 Tunneling Protocol, RFC 3931) defines how packets formatted for other protocols are encapsulated in IP, carried across the network, then "popped out" at the delivery point. Other RFCs get specific about ATM, Frame Relay (FR), etc. Use of UDP headers and IPsec are options for L2TP.
-- IP in IP allows multiple users to share a connection (a TCP session for example) to save memory and processing power.
-- Encrypted Tunnels, such as IPsec, may cloak only the payload (using the original IP header for routing) or may encrypt the entire IP packet and encapsulate that in another packet, possibly with different addresses. The goal is privacy. Hiding the original addresses can lead to problems with Network Address Translation and firewalls.
-- Pseudowires aim to be transparent to Layer 2 traffic, emulating a wire: bits out = bits in. There are versions for Layer 2 protocols (the first was the Point to Point Protocol, designed to run over dial-up wire). Other versions handle TDM connections (T-1 and DS-3), breaking a constant bit stream into a series of payloads at the origin and reconstructing that stream from concatenated packet contents. To ensure synchronization and prevent T-1 frame slips, the pseudowire can preserve data clocking.
There are two common features of these tunnels:
1. The router and switch nodes in the IP network never see anything but a "normal" IP packet; the path of the tunnel is determined by whatever populates the routing/forwarding tables.
2. Like mountain tunnels, network tunnels have two ends, outside of which the traffic is visible in its native form. (Encrypted multicast may qualify as a tunnel with many "ends".)
This is a basic definition of a tunnel. After reading the previous ViewsLetter on virtual circuits, is shouldn't be a shock to note that a virtual circuit (including an MPLS label switched path) fits the same description. In other words, the VC on a FR or ATM network has privacy similar to an unencrypted IP VPN based on tunneling. That may explain why most users of FR and ATM don't feel a need to encrypt.
However, many people don't agree. A current example of comes from the Federal Government, where the intent is to secure not only national secrets but also unclassified private or confidential information.
The upshot: One authority mandates end-to-end encryption for certain traffic and situations. At the same time, a security group focused on surveillance of information flows prohibits "tunneling" unless it can access the data in the clear at any node in the network.
Irreconcilable differences? Possibly, but it's more likely they are not applying the same definitions to key terms. Specifically, does or does not 'pt-pt encryption' constitute a 'tunnel'? It would be interesting to facilitate a discussion between the parties.
Your discussion is also welcome.
How Can Flanagan Consulting Help You?
We understand not only the technology of networks, but also
the surrounding business processes: procurement, bid
preparation/analysis, statements of work, financial analysis,
consensus building, and more. www.Flanagan-Consulting.com
Your inquiry is welcomed. Ph: +1.703.242.8381
"Flanagan Consulting" and "ViewsLetter" are Service Marks of W. A. Flanagan, Inc.
W. A. Flanagan, Inc.
45472 Holiday Drive, #3
Sterling, VA 20166
|In Converged Networking,
We have the Experience