IETF E. Lear Internet Draft Cisco Systems, Inc. April 2000 Expires: November, 2000 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 diametrically opposed 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. This model shifts complexity Lear [Page 1] from routers to end nodes, providing for development of new services based on the capabilities of individual hosts. The only function left to the network is to route data between two end points based on their end point addresses. 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 it was 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 intermediate devices that make such changes, and therefore signal the application with necessary information. An example of such a requirement comes from the telephony community, where both SIP and H.323 make use of ports that are not well known. 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 and the integrated service model, 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 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 Lear [Page 2] existence of a NAT between it and the other end point might allow for the establishment of alternative arrangements, such as RSIP, transport layer security, 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 provides end hosts the opportunity to mitigate any damage caused by lack of end to end transparency, and therefore leads to a more adaptive network model. As another example of host/network cooperation, as a matter of policy a network manager may wish for endpoints using IPSEC to use RSIP controlled tunnels to the Internet, such that the tunnels themselves are encrypted, thus obscuring the actual end point from either side of the communication. A signaling mechanism would be necessary for the hosts to know that they must employ RSIP. Thus the network devices would signal such requirements to the host. 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. Host Vendor Participation Some of the mechanisms that provide visibility may require changes to the host platform. One reason we are drawn to making changes in the network devices alone is that the host vendors have historically been slow to adopt advances in the state of the art. While we note the sizably huge installed base of end hosts, there will be no benefit to anyone should a network device signal back to a host that does not understand the response. Security Considerations This document recommends no solution, but requests that people explore the notion of visibility. There are benefits of being able to see NAT devices, such as recognizing points at which IPSEC will fail or require some sort of tunneling mechanism [10,11]. Lear [Page 3] 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. The possibility of exploitation is always opened whenever more signaling is added to the network. Therefore, it should only be done with great care. 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 networking deserve more serious consideration. Acknowledgements Chris Lonvick provided very constructive feedback and suggestions for this document. Erik Fair raised issues of the lack of host vendor participation. Bob Braden attempted to clear some fog in the draft surrounding intserv and RSVP. References [1] Carpenter, B., "Internet Transparency", RFC 2775, February, 2000. [2] Holdrege, M., Srisuresh, P., "Protocol Complications with the IP Network Address Translator (NAT)", draft-ietf-nat-protocol-complications-02.txt (work in progress), March, 2000. [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. Lear [Page 4] [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-04.txt (work in progress), March, 2000. [12] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March, 1997. [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-05.txt (work in progress), April, 2000. 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 Expires November, 2000 [Page 5]