I agree with Tony, cannot add more and well stated. /jim > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] 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 protected] > https://www1.ietf.org/mailman/listinfo/int-area >
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
