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

Differences from draft-lear-foglamps-01.txt

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
                        <draft-lear-foglamps-02.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 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]