Subject: RE: [Int-area] Architectural reasons why tunnelling is an indicationof a failure

From: "Bound, Jim" <[email-masked]>
Date: Tue, 2 Aug 2005 09:06:57 -0400

I agree with Tony, cannot add more and well stated.
/jim 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Tony Li
> Sent: Tuesday, August 02, 2005 8:53 AM
> To: Pekka Nikander
> Cc: Internet Area; IAB
> Subject: Re: [Int-area] Architectural reasons why tunnelling 
> is an indicationof a failure
> 
> 
> 
> 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-masked]
> https://www1.ietf.org/mailman/listinfo/int-area
> 

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area