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

Differences from draft-lear-foglamps-00.txt

            NAT and other Network "Intelligence": Clearing
           Architectural Haze through the use of Fog Lamps
                        <draft-lear-foglamps-01.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 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]