IETF E. Lear Internet Draft Cisco Systems, Inc. October 1999 NAT and other Network "Intelligence": Clearing Architectural Haze through the use of Fog Lamps Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract In [CARPENTER] the IAB once again sets forth its opinion on the use and impact of NAT devices, along with the complications of private network address space. Therein they discuss the notion of "transparency". In this brief document we offer an alternative idea, and suggest its further study: device visibility. Introduction There are two classic operating models for intelligence within networks. The first is that end devices have no intelligence, and that the devices to which they connect provide all network services. The telephone system is just such a network. The nearly complete absence of intelligence in end devices makes them very cheap to manufacture and administer. The cost is that every new service requires lengthy and expensive upgrades of complex telephone switches. Those switches are traditionally expensive to maintain. Lear [Page 1] The opposite model is the end-to-end model [Saltzer]. The end to end model reduces the complexity at the center of the network in favor of intelligence within the end nodes. Although this model shifts complexity from routers to end nodes, it provides for development of new services based on the capabilities of individual hosts. Another benefit of the end-to-end model is congestion control that can be managed between endpoints [TCP, SLOSTART], thus not requiring that state be kept in devices other than the end points. In the earlier days of the Internet this it extremely important keep memory and processing requirements of routers to a minimum. There are numerous reasons why NATs, web caches, and firewalls are with us to stay, only some of which are discussed in [CARPENTER]. Rather than debate the benefit of each such device or their legitimacy within the network, we accept the notion that such devices are here to stay, and that the end to end model, as we knew it, will not be re-established through requirements of their non-existence. We accept this notion with the reservation, however, that the points raised in [CARPENTER] about the problems introduced by such devices are legitimate, and therefore require redress: the end to end model is broken and needs repair. Visibility The notion of transparency demands that devices between two end points not modify information within the packet above layer 2, except under very specific well defined circumstances (i.e., decrement the TTL or record route). Changing of IP addresses is not viewed as acceptable, nor is any change to layer 4 and above. The problem is that it is often impossible to detect such devices, and there is now guidance within the IETF on how to build such devices [NAT]. Furthermore, as we expand the use of the Internet to more applications with tighter constraints on network behavior it becomes necessary to provide different classes of service based on the type of communications [INTSERV, DIFFSERV]. In the case of mechanisms such as RSVP, the host signals to the network the level of service it requires, whereas with differentiated services the network prioritizes traffic with or without the host's knowledge or consent. If we consider a voice, the question boils down to whether the application will be able to detect when it must provide a busy signal rather than degraded service. By providing the end host with visibility into network conditions both end point and network devices cooperate to provide enhanced service. This same notion can be extended to other mechanisms, such as NAT. As was pointed out in [CARPENTER] NAT inhibits the use of mechanisms such as [IPSEC]. However, a host's knowledge of the existence of a NAT between it and the other end point might allow for the establishment of alternative arrangements, such as RSIP or SSH tunnels. Given the ability to discover NATs it would be possible for hosts to once again offer services while still safely using private addresses. The illumination of such devices, therefore, provides Lear [Page 2] the opportunity to mitigate any damage caused by their lack of transparency, and also leads to the possibility of improved network service safety. Suppose two devices wish to have a conversation where at any one point someone eavesdropping on the link can only determine one of the true end points. One could create a tunnel to a server that sits on or near a firewall. Then one could run encrypt the communication within the tunnel so that the tunnel terminus is kept from monitoring. Another popular theme of research, today, is that of active networking [ACTIV97]. Active networking ranges from packets programming routers to routers making pre-programmed decisions based on packet content. While some researchers have attacked the notion as not scalable and destabilizing, it is premature to make such determinations. Here again the question of whether the hosts actively participate in the "intelligent network" is one that deserves further exploration, at least in terms of performance and security. Of interest to the author is multimedia flow management based on both network and host load factors. There are now at least two commercial implementations that use DNS to distribute load based on configurable factors, and there is at least one product that accomplishes the same task using application level redirects. Here again is an opportunity for hosts and routers to exchange information relating their various states. There are clearly pitfalls in doing so, as network state itself is a nebulous concept. Security Considerations This document recommends no solution, but requests that people explore the notion of visibility. There are potential benefits with being able to see systems such as NATs, as was discussed earlier. There are also potential drawbacks, since additional diagnostic information may be made available to interloping devices. Once again, further exploration needs to be done in this area. Conclusion The notion of transparency is an ideal whose time it has come to review. On the Internet it is largely impossible to attain, and it is not clear that it is even the right goal for today's network requirements. Alternate views, such as visibility and active networking deserve a more serious review. References [Saltzer] End-To-End Arguments in System Design, J.H. Saltzer, D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4, November 1984, pp 277-288. [BCP 5] Address Allocation for Private Internets. Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot & E. Lear, RFC 1918, 1996. Lear [Page 3] [NAT-ARCH] Architectural Implications of NAT, T. Hain, draft-iab- nat-implications-04.txt (work in progress). [NAT-PROT] Protocol Complications with the IP Network Address Translator (NAT), M. Holdrege, P. Srisuresh, draft-ietf-nat- protocol-complications-01.txt (work in progress). Author's Address Eliot Lear Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Phone: +1 (408) 527 4020 Email: lear@cisco.com