IETF E. Lear Internet Draft Cisco Systems, Inc. December 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 their workshop report 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.[1,2,3] 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. The opposite model is the end-to-end model.[4] 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 Lear [Page 1] 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 [5,6], 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 by the IAB report. 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 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. 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 [7,8]. 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 has been pointed out numerous times, NAT inhibits the use of mechanisms such as ESP.[9] 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 the opportunity to mitigate any damage caused by their lack of Lear [Page 2] 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 a 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 benefits of being able to see systems such as NAT devices, such as recognizing points at which IPSEC will fail or require some sort of tunneling mechanism [10,11]. Use of tunneling mechanisms fundamentally alters the end to end security model by requiring additional trust of the tunnel end point. This change must be viewed in the context of private network addresses, DHCP [12], and DNSSEC [13], where IP addresses themselves are ephemeral. There are also additional potential drawbacks to such device visibility, 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 Lear [Page 3] networking deserve a more serious review. Acknowledgements Chris Lonvick provided very constructive feedback and suggestions for this document. References [1] Carpenter, B., "Internet Transparency", draft-draft-carpenter-transparency-05.txt (work in progress), December, 1999. [2] Holdrege, M., Srisuresh, P., "Protocol Complications with the IP Network Address Translator (NAT)", draft-ietf-nat-protocol-complications-01.txt (work in progress), June, 1999. [3] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [4] 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. [5] Postel, J., "Transmission Control Protocol (TCP) Specification", STD 7, RFC 793, September 1981. [6] V. Jacobson, "Congestion Avoidance and Control", Proceedings of SIGCOMM '88, Stanford, CA, 1988. [7] Braden, R. Ed. et al, "Resource ReserVation Protocol -- Version 1 Functional Specification", RFC 2205, September 1997. [8] Black, D., Blake, S., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [9] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827, NRL, August 1995. [10] S. Hanks, T. Li, D. Farinacci, P. Traina, "Generic Routing Encapsulation", RFC 1701, October, 1994. [11] Borella, M., Lo, J., "Realm Specific IP: Framework", draft-ietf-nat-rsip-framework-02.txt (work in progress), October, 1999. [12] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March, 1997. Lear [Page 4] [13] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March, 1999. [14] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989. [15] Hain, T., "Architectural Implications of NAT", draft-iab-nat-implications-04.txt (work in progress), April, 1999. 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 Lear [Page 5]