rfc1919.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                          M. Chatel
Request for Comments: 1919                                    Consultant
Category: Informational                                       March 1996


                Classical versus Transparent IP Proxies

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   Many modern IP security systems (also called "firewalls" in the
   trade) make use of proxy technology to achieve access control.  This
   document explains "classical" and "transparent" proxy techniques and
   attempts to provide rules to help determine when each proxy system
   may be used without causing problems.

Table of Contents

   1.  Background . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Direct communication (without a proxy) . . . . . . . . . . . 3
   2.1.  Direct connection example  . . . . . . . . . . . . . . . . 3
   2.2.  Requirements of direct communication . . . . . . . . . . . 5
   3.    Classical application proxies  . . . . . . . . . . . . . . 5
   3.1.  Classical proxy session example  . . . . . . . . . . . . . 6
   3.2.  Characteristics of classical proxy configurations  . . .  12
   3.2.1.  IP addressing and routing requirements . . . . . . . .  12
   3.2.2.  IP address hiding  . . . . . . . . . . . . . . . . . .  14
   3.2.3.  DNS requirements . . . . . . . . . . . . . . . . . . .  14
   3.2.4.  Software requirements  . . . . . . . . . . . . . . . .  15
   3.2.5.  Impact of a classical proxy on packet filtering  . . .  15
   3.2.6.  Interconnection of conflicting IP networks . . . . . .  16
   4.  Transparent application proxies  . . . . . . . . . . . . .  19
   4.1.  Transparent proxy connection example . . . . . . . . . .  20
   4.2.  Characteristics of transparent proxy configurations  . .  26
   4.2.1.  IP addressing and routing requirements . . . . . . . .  26
   4.2.2.  IP address hiding  . . . . . . . . . . . . . . . . . .  28
   4.2.3.  DNS requirements . . . . . . . . . . . . . . . . . . .  28
   4.2.4.  Software requirements  . . . . . . . . . . . . . . . .  29
   4.2.5.  Impact of a transparent proxy on packet filtering  . .  30
   4.2.6.  Interconnection of conflicting IP networks . . . . . .  31
   5.  Comparison chart of classical and transparent proxies  . .  31
   6.  Improving transparent proxies  . . . . . . . . . . . . . .  32
   7.  Security Considerations  . . . . . . . . . . . . . . . . .  34



Chatel                       Informational                      [Page 1]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . .  34
   9.  References . . . . . . . . . . . . . . . . . . . . . . . .  35

1. Background

   An increasing number of organizations use IP security systems to
   provide specific access control when crossing network security
   perimeters. These systems are often deployed at the network boundary
   between two organizations (which may be part of the same "official"
   entity), or between an organization's network and a large public
   internetwork such as the Internet.

   Some people believe that IP firewalls will become commodity products.
   Others believe that the introduction of IPv6 and of its improved
   security capabilities will gradually make firewalls look like stopgap
   solutions, and therefore irrelevant to the computer networking scene.
   In any case, it is currently important to examine the impact of
   inserting (and removing) a firewall at a network boundary, and to
   verify whether specific types of firewall technologies may have
   different effects on typical small and large IP networks.

   Current firewall designs usually rely on packet filtering, proxy
   technology, or a combination of both. Packet filtering (although hard
   to configure correctly in a security sense) is now a well documented
   technology whose strengths and weaknesses are reasonably understood.
   Proxy technology, on the other hand, has been deployed a lot but
   studied little. Furthermore, many recent firewall products support a
   capability called "transparent proxying". This type of feature has
   been subject to much more marketing attention than actual technical
   analysis by the networking community.

   It must be remembered that the Internet's growth and success is
   strongly related to its "open" nature. An Internet which would have
   been segmented from the start with firewalls, packet filters, and
   proxies may not have become what it is today. This type of discussion
   is, however, outside the scope of this document, which just attempts
   to provide an understandable description of what are network proxies,
   and of what are the differences, strengths, and weaknesses of
   "classical" and "transparent" network proxies.  Within the context of
   this document, a "classical" proxy is the older (some would say old-
   fashioned) type of proxy of the two.

   Also note that in this document, the word "connection" is used for an
   application session that uses TCP, while the word "session" refers to
   an application dialog that may use UDP or TCP.






Chatel                       Informational                      [Page 2]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


2. Direct communication (without a proxy)

   In the "normal" Internet world, systems do not use proxies and simply
   use normal TCP/IP to communicate with each other. It is important
   (for readers who may not be familiar with this) to take a quick look
   at the operations involved, in order to better understand what is the
   exact use of a proxy.

   2.1 Direct connection example

      Let's take a familiar network session and describe some details of
      its operation. We will look at what happens when a user on a
      client system "c.dmn1.com" sets up an FTP connection to the server
      system "s.dmn2.com". The client system's IP address is
      c1.c2.c3.c4, the server's IP address is s1.s2.s3.s4.

       +---------------+      +----------+      +---------------+
       |               |     /    IP      \     |               |
       |  c.dmn1.com   |----+  network(s)  +----|  s.dmn2.com   |
       | (c1.c2.c3.c4) |     \            /     | (s1.s2.s3.s4) |
       +---------------+      +----------+      +---------------+


      The user starts an instance of an FTP client program on the client
      system "c.dmn1.com", and specifies that the target system is
      "s.dmn2.com". On command-line systems, the user typically types:

          ftp s.dmn2.com

      The client system needs to convert the server's name to an IP
      address (if the user directly specified the server by address,
      this step is not needed).

      Converting the server name to an IP address requires work to be
      performed which ranges between two extremes:

       a) the client system has this name in its hosts file, or has
          local DNS caching capability and successfully retrieves the
          name of the server system in its cache. No network activity
          is performed to convert the name to an IP address.

       b) the client system, in combination with DNS name servers,
          generate DNS queries that eventually propagate close to the
          root of the DNS tree and back down the server's DNS branch.
          Eventually, a DNS server which is authoritative for the
          server system's domain is queried and returns the IP
          address associated with "s.dmn2.com" (depending on the case,
          it may return this to the client system directly or to an



Chatel                       Informational                      [Page 3]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


          intermediate name server). Ultimately, the client system
          obtains a valid IP address for s.dmn2.com. For simplicity,
          we assume the server has only one IP address.

       +---------------+     +--------+     +---------------+
       |               |    /   IP     \    |               |
       |  c.dmn1.com   |---+ network(s) +---|  s.dmn2.com   |
       | (c1.c2.c3.c4) |    \          /    | (s1.s2.s3.s4) |
       +---------------+     +--------+     +---------------+
          A  |                /          \
          |  | address for   /            \
          |  | s.dmn2.com?  /              \
          |  |             /                \
          |  |            /                  \
          |  |     +--------+ s.dmn2.com?  +--------+
          |  +---->|  DNS   |------------->|  DNS   |
          |        | server |              | server |
          +--------|   X    |<-------------|   Y    |
       s1.s2.s3.s4 +--------+  s1.s2.s3.s4 +--------+

      Once the client system knows the IP address of the server system,
      it attempts to establish a connection to the standard FTP
      "control" TCP port on the server (port 21). For this to work, the
      client system must have a valid route to the server's IP address,
      and the server system must have a valid route to the client's IP
      address. All intermediate devices that behave like IP gateways
      must have valid routes for both the client and the server. If
      these devices perform packet filtering, they must ALL allow the
      specific type of traffic required between C and S for this
      specific application.

       +---------------+                    +---------------+
       |  c.dmn1.com   |                    |  s.dmn2.com   |
       | (c1.c2.c3.c4) |                    | (s1.s2.s3.s4) |
       +---------------+                    +---------------+
         | |                                    |   |
         | | route to S              route to C |   |
         | V                                    V   |
         |                                          |
         | A                                        | A
         | | route to C                             | | route to S
         | |                                        | |
         | |      C          S                 C    | |
       +----+    <-- +----+ -->    +----+     <-- +----+
       | G1 |--------| Gx |--------| Gy |---------| Gn |
       +----+ -->    +----+    <-- +----+ -->     +----+
               S                C          S




Chatel                       Informational                      [Page 4]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


      The actual application work for the FTP session between the client
      and server is done with a bidirectional flow of TCP packets
      between the client's and server's IP addresses.

      The FTP protocol uses a slightly complex protocol and TCP
      connection model which is, luckily, not important to the present
      discussion. This allows slightly shortening this document...

   2.2 Requirements of direct communication

      Based on the preceding discussion, it is possible to say that the
      following is required for a direct session between a client and
      server to be successful:

       a) If the client uses the NAME of the server to reference it,
          the client must either have a hardcoded name-to-address
          binding for the server, or it must be able to resolve the
          server name (typically using DNS). In the case of DNS, this
          implies that the client and server must be part of the same
          DNS architecture or tree.

       b) The client and server must be part of the same internetwork:
          the client must have a valid IP route towards the server,
          the server must have a valid IP route towards the client,
          and all intermediate IP gateways must have valid routes
          towards the client and server ("IP gateway" is the RFC
          standard terminology; people often use the term "IP router"
          in computer rooms).

       c) If there are devices on the path between the client and
          server that perform packet filtering, all these devices must
          permit the forwarding of packets between the IP address of
          the client and the IP address of the server, at least for
          packets that fit the protocol model of the FTP application
          (TCP ports used, etc.).

3. Classical application proxies

   A classical application proxy is a special program that knows one (or
   more) specific application protocols. Most application protocols are
   not symetric; one end is considered to be a "client", one end is a
   "server".

   A classical application proxy implements both the "client" and
   "server" parts of an application protocol. In practice, it only needs
   to implement enough of the client and server protocols to accomplish
   the following:




Chatel                       Informational                      [Page 5]

RFC 1919        Classical versus Transparent IP Proxies       March 1996


   a) accept client sessions and appear to them as a server;

   b) receive from a client the name or address of the final target
      server (this needs to be passed over the "client-proxy" session
      in a way that is application-specific);

   c) setup a session to the final server and appear to be a client
      from the server's point of view;

   d) relay requests, responses, and data between the client and
      server;