One document matched: draft-lear-foglamps-00.txt

IETF                                                    E. Lear
Internet Draft                                          Cisco Systems, Inc.
October 1999


            NAT and other Network "Intelligence": Clearing
           Architectural Haze through the use of Fog Lamps
                        <draft-lear-foglamps-00.txt>

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