As I have been touting my opinion that tunnelling is an indication of
deficiencies in the architecture, I want to express the reasons why I
believe so. Note that I am _not_ saying that tunnelling is _evil_.
Tunnelling is often fine as a short term solution, and sometimes also
as a longer term solution. However, independent of that, tunnelling
(almost) always indicates that the architecture does not provide
functionality that it should provide.
While there are different reasons for tunnelling, I basically believe
that all of them tend to be indications of faults in the
architecture, or sometimes people failing to understand or appreciate
the architecture. The only potential exception is when you one is
tunnelling a local-use lower-layer protocol, such as Ethernet, over a
wide area global protocol, such as IP, but even that case is
debatable, in my opinion. Also note that when one "tunnels"
something over a lower layer protocol, such as "tunnelling" IP over
MPLS, one is really misusing the terminology. Running a protocol
over a lower layer protocol is not really a case of tunnelling but
exactly the way a layered architecture is supposed to work.
Now, the forms of tunnelling that I consider are the following:
1. Tunnelling over the very same protocol; e.g., IP-over-IP
2. Tunnelling a protocol over one at the same layer;
e.g., IPv6 over IPv4
3. Tunnelling a global lower-layer protocol over a higher layer
protocol; e.g., IP over DNS, IP over UDP, or IP over HTTP
4. Tunnelling a local-scope lower-layer protocol over a global
high layer protocol; e.g. Ethernet over IP
Sure, there may be other cases, ones that I am missing, and my
argumentation may not apply to them.
Case 1: Tunnelling a protocol over itself
==========================================
Examples of this include IPsec in tunnel mode, GTP, and other forms
of IP-over-IP tunnelling. My basic concern with this kind of
tunnelling is that it enforces two different _semantics_ to a single
identifier space, and therefore makes the system more brittle.
Conversely, the architecture should provide functionality so that
such overloaded semantics and brittleness is not needed.
In the case of IPsec, tunnelling seems primarily to be used:
- to separate local, trusted address space from a global,
hostile address space
- to make sure that the local addresses are really
trustworthy, i.e., to prevent others from injecting
addresses with local addresses to the local network
- to hide the details of traffic between the tunnelled sites
However, those are not the root causes. To find the real reasons
behind tunnelling in this case we have to consider why people want to
split the address space in the first place? The reason seems to be
that we have no mechanism in the current architecture to provide
assurance that the source address of a packet really indicates its
real source. In other words, (source) addresses in the wild Internet
are not worth much, and therefore it is preferably to divide the
address space into trustworthy and non-trustworthy ones.
What comes to the desire to hide the details of the traffic, we have
to go somewhat deeper still. The IP architecture does not support IP-
level privacy, and I claim that it should. That is, it is far too
easy to use an IP address to figure out who are the parties
communicating. Adding IP-level privacy to the architecture requires
would require large changes, and therefore people might argue it
being a non-goal. Maybe so, but IMHO the existence of tunnelling,
even here, still indicates a deficiency. [NB: One way to add IP-
level privacy would be to have a separate cryptographically protected
identity layer on the top of IP layer, with build-in address-agility
(mobility) mechanism, and then start changing IP addresses on a
fairly fast cycle.]
Another reason for IP-over-IP tunnelling is mobility, e.g., in GTP
and the proposed NETLMM work. Both of them are, in my opinion,
indications that we are relying too much on IP addresses as
identifiers. Hence, they indicate deficiencies in the architecture
in the sense that locators should not be used for host
identification, thereby removing the need for keeping stable IP
addresses when a host moves to a topologically different location.
There are probably other reasons for tunnelling a protocol over
itself, too, but my gut feeling is that in each case a close analysis
will just reveal that the architecture is either deficient or is
missing some functionality that should be there. For example, I am
pretty confident that similar analysis could be applied to similar
tunnelling on other layers, such as tunnelling TCP with SSH.
So, tunnelling a protocol over itself is typically indication that
either a layer of indirection is missing (as in the case of mobility-
motivated tunnelling) or the layer in question does not provide the
required security functionality.
2. Tunnelling a protocol over a sister protocol at the same layer
=================================================================
In my mind the prime example of same-layer sister-protocol tunnelling
is IPv6-over-IPv4 tunnelling. In this case, what needs to be done is
adding a common layer either below or above the layer in question.
HIP is a good example of this; if HIP is used, no IP-cross-version-
tunnelling is needed since HIP runs equally on both of the two
versions of IP and even hides the difference from upper layer protocols.
3. Tunnelling a *global* protocol over an upper layer protocol
==============================================================
Example cases in this space are IP-over-DNS and the multiple ways of
tunnelling IP and other protocols over HTTP. AFAICT, almost always
the architecture is failing here in two ways simultaneously.
Firstly, people are using tunnelling to overcome what they feel as
overly restrictive security measures. Conversely, the security
methods that the administrators have placed there are failing due to
tunnelling. In my interpretation, these two sides of the coin both
indicate that the architecture is lacking suitable security
functionality.
Other common examples in this space include the various methods for
tunnelling protocols over UDP (and even TCP or not-quite-TCP) due to
NATs. Again, these are indications of a failure of the architecture,
in this case failure to respond to the shortage of addresses and/or
to accommodate NATs into the architecture.
4. Tunnelling a local (link layer) protocol over an upper layer protocol
========================================================================
The prime example in this space is tunnelling Ethernet over IP.
This is the only space where I think that tunnelling is often
appropriate. However, even here I am tempted to consider tunnelling
as a failure of the architecture. Basically, it is an indication
that there is a need to provide functionality that is available over
the local protocol (e.g. Ethernet) over wide area links. The failure
is that the functionality at hand is not available over the wide area
(global) protocol while it should be. However, this is a minor
issue, and more often an implementation issue than really an
architectural issue.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
So, my claim is that tunnelling is (almost) always an indication that
the architecture has one or more of the following deficiencies:
1. A layer (of indirection) is missing
2. Some security functionality is missing
3. The architecture has failed to provide sufficient resources
4. Some functionality is provided at or on-the-top-of a wrong layer
All of the discussion above is really architectural in nature. The
starting point is the layering model, and the discussion is mostly
about how the layering fails and what are the reasons, in each case,
for the failure.
There are also technical reasons to resist tunnelling and try to
pursue people to work on alternative solutions. Pekka Savola
discussed some of these at the INT area meeting on Monday, including
problems with fragmentation and wasting resources. However, I'd
prefer to keep that discussion separate and focus in this thread only
on the architectural issues.
--Pekka
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
