Pekka,
> 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.
I view tunneling as a means of virtualizing topology. In some cases,
this virtualization is both productive and the best possible mechanism
for providing the desired service. In other cases, as with any
technology, tunneling can be thoroughly abused. I think that it's very
important to carefully distinguish these two applications of the general
concept.
I disagree that the application of tunneling necessarily implies a
failure of the architecture. It certainly CAN indicate an architectural
failure, but in other cases, it is merely the manifestation of
virtualization in our particular technology, and thus is fundamentally
part of the architecture itself.
> Case 1: Tunnelling a protocol over itself
> ==========================================
>
> 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
More generally put:
- to create a virtual topology
- to create a virtual address space, for private use
> 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.
In many cases, users wish to have their own private address space that
is wholly independent of the normal Internet address space. While we
are usually focused on the deployment of IP in the Internet, we are also
responsible for the use of IP technology that is not visible from the
Internet. You may well argue that there are questionable security
advantages obtained by not having fully accessible addresses while still
be electrically/optically connected to the Internet, but this is a
capability that many people find to be extremely useful especially when
firewalls are in use. I do not want to reargue the architectural
implications of firewalls with you, I just want to point out that they
do exist, and they are a substantial contributor to this case.
> 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.
Here I have to agree with you, the lack of a separation between locator
and identifier causes us to tunnel to provide an explicit locator. I
think that this feeds into the argument that Geoff Huston was making
directly, and I won't continue it here.
> 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.
I have to ask if security functionality is necessarily a requirement of
the network layer. I can argue this one both ways, but I don't think
that it is at all clear cut. Given that not every single packet needs
to be encrypted, that would seem to imply that encryption is the
exception, not the rule, and thus an intermediate layer between network
and transport for providing security is the correct approach. This is
effectively what we have already with IPsec today, it's just not widely
acknowledged as an architectural component.
Another very useful application of IP over IP tunneling has been the
creation of virtual topology for early deployment and testing of
technology. We have done this to good effect for both BGP and
multicast. Is the fact that we cannot pragmatically enable a protocol
across the full Internet topology an architectural flaw? Or is it
simply a pragmatic compromise?
> 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.
As we have seen with IPv6 and many other network layer protocols (e.g.,
private tunneling of AppleTalk) creating a virtual topology is an
extremely constructive mechanism for using the Internet as a global
transport mechanism. You may well argue that that's an architectural
flaw of the payload protocol, but from an IP perspective, it simply
seems to be another service (and value) that our architecture is
prepared to provide. I'd claim that this case is a clear benefit.
> 3. Tunnelling a *global* protocol over an upper layer protocol
> ==============================================================
>
> 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.
In this case, I will not argue with you at all. These are all clearly
architectural failures. However, they exist and cannot be undone at
this point.
> 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.
That functionality may be something as simple as a different network
layer protocol. It is hardly an architectural failure of the Internet
that we have not absorbed all other applications, much tho we would all
like to.
Regards,
Tony
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
