rfc1919.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,451 行 · 第 1/5 页

         Second possibility: they merge the two numbers by renumbering
         partially on each side to remove conflicts (actually harder to
         do, but has the political advantage that both sides have to do
         some work)

         Third possibility: they communicate through chained classical
         proxies:


            +--------+     +--------+   +--------+     +--------+
           /  Org. 1  \    | Proxy  |   | Proxy  |    /  Org. 2  \
          +  dmn1.com  +---+ system +---+ system +---+  dmn2.com  +
           \  net 10  /    |    1   |   |   2    |    \  net 10  /
            +--------+     +--------+   +--------+     +--------+


         Both proxy 1 and 2 are standard systems running normal TCP/IP
         software stacks. Their configuration is not typical, however:





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


             a) The link between proxy 1 and proxy 2 may use any IP
                network number that is not used (or not needed) on
                either side. Nothing on Org.1 and Org.2's networks
                need to have an IP route to this network.

             b) Proxy 1 has an IP route for network 10 that points to
                Organization 1's network, and does DNS resolution
                (if required) using dmn1.com's name servers.

             c) Proxy 2 has an IP route for network 10 that points to
                Organization 2's network, and does DNS resolution
                (if required) using dmn2.com's name servers.

             d) Proxy 1 and proxy 2 only require a host IP route to
                each other for communication.

             e) For this to be convenient, the classical proxy
                applications must support the automatic selection of
                a destination based on the client IP address.

             f) On proxy system 1, the proxy software treats incoming
                sessions from proxy system 2 in the normal way: the
                "client" (proxy system 2) will be prompted in an
                application-specific way for the final destination.
                However, incoming sessions from Org.1 addresses are
                immediately and automatically forwarded to proxy
                system 2.

                Proxy system 2 is configured similarly (that is,
                connections coming from proxy 1 are prompted for a
                target server name, connections from Org.2 addresses
                are immediately and automatically forwarded to
                proxy 1.

         From a user's point of view, the behavior of such a chained
         proxy system is not very different from a single classical
         application proxy:

             a) A user on a client system with address 10.1.2.3
                on Org.1's network wishes to do an anonymous FTP to
                "server.dmn2.com".

             b) The user starts an FTP towards proxy 1. Proxy 1 sees
                an incoming connection from an address in network 10,
                so it immediately relays the connection to proxy 2.

             c) Proxy 2 sees a connection coming from proxy 1, so it
                prompts the client. The user sees the username prompt



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


                and types (assuming FTP proxies that behave like TIS's
                ftp-gw):

                     [e-mail]

                This will be resolved IN THE CONTEXT OF Org. 2'S
                NETWORK. The user can then complete the dialog and
                use the FTP connection.

             d) Note that this setup will work even if the client and
                server have the EXACT SAME IP ADDRESS (10.1.2.3 in
                our example).

             If the proxy applications support selecting another
             proxy based on the destination supplied by the client,
             and if DNS domains are unique, more than two conflicting
             IP networks can be linked in this way! Here is an
             example configuration:

             a) Four IP networks that all use network 10 are linked
                by four proxy systems. The four proxy systems share a
                common, private IP network number and physical link
                (LAN or WAN).

             b) A user on organization 1's network wishes to access
                a server on network 3. The user connects to its local
                proxy (proxy 1) and supplies that target system name.

             c) Proxy 1 determines, based on a configuration rule,
                that the target system name is reachable by using
                proxy 3. So it connects to proxy 3 and passes the
                target system name.

             d) Proxy 3 determines that the target system name is
                local (to itself) and connects to it directly.


             Security Implications of chained proxies

             Obviously, when such "chained" configurations are built,
             access control rules and logging based on a
             final-client/final-server combination are difficult to
             enforce, since the first proxy in the chain sees a
             final-client/proxy relationship and the last proxy in
             the chain sees a proxy/final-server relationship.

             Doing better than this requires that the proxies be
             capable of passing the "original-client" and



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


             "final-destination" information back and forth in the
             proxy chain for access control and/or logging purposes.
             This requires the proxies to trust each other, and
             requires the network path to be trusted (forging this
             information becomes an excellent attack).

             Even if these problems were to be solved reliably, the
             original goal of the proxy chains was to solve an IP
             and possibly a DNS conflict. The "original-client" and
             "final-destination" values may not have the same
             meaning everywhere in the overall setup. Tagging the
             information with a "universe-name" may help, assuming
             it is possible to define unique universe names in the
             first place. Obviously this topic requires more study.

4. Transparent application proxies

   The most visible problem of classical application proxies is the need
   for proxy-capable client programs and/or user education so that users
   know how to use the proxies.

   When somebody thought of modifying proxies in such a way that normal
   user procedures and normal client applications would still be able to
   take advantage of the proxies, the transparent proxy was born.

   A transparent application proxy is often described as a system that
   appears like a packet filter to clients, and like a classical proxy
   to servers. Apart from this important concept, transparent and
   classical proxies can do similar access control checks and can offer
   an equivalent level of security/robustness/performance, at least as
   far as the proxy itself is concerned.

   The following information will make it clear that small organizations
   that wish to use proxy technology for protection, that wish to rely
   entirely on one proxy system for network perimeter security, that
   want a minimal (or zero) impact on user procedures, and that do not
   wish to bother with proxy-capable clients will tend to prefer
   transparent proxy technology.

   Organizations with one or more of the following characteristics may
   prefer deploying classical proxy technology:

   a) own a substantial internal IP router network, and wish to
      avoid adding "external" routes on the network
   b) wish to deploy "defence in depth", such as internal firewalls,
      packet filtering on the internal network
   c) wish to keep their DNS environment fully isolated from the
      "other side" of their proxy system, or that fear that their



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


      internal DNS servers may be vulnerable to data-driven attacks
   d) use some IP networks that are in conflict with the "other side"
      of their proxy system
   e) wish to use proxy applications that are easily portable
      to different operating system types and/or versions
   f) wish to deploy multiple proxy systems interconnecting them
      to the SAME remote network without introducing dynamic
      routing for external routes on the internal network

   4.1 Transparent proxy connection example

      Let us go through an FTP sesssion again, through a "transparent"
      proxy this time. We assume that the proxy system has two IP
      addresses, two network interfaces, and two DNS names.

      The proxy system is running a special program which knows how to
      behave like an FTP client on one side, and like an FTP server on
      the other side. This program is what people call the "proxy". This
      program, being a transparent proxy, also has a very special
      relationship with the TCP/IP implementation of the proxy system.
      This relationship may be built in several ways, we will describe
      only one such possible way.

      We will assume that the proxy program is listening to incoming
      requests on the standard FTP control port (21/tcp), although this
      is not always the case in practice.


       +---------------+      +----------+
       |               |     /    IP      \
       |  c.dmn1.com   |----+  network(s)  +----------+
       | (c1.c2.c3.c4) |     \            /           |
       +---------------+      +----------+    +-----------------+
                                              | (p1.p2.p3.p4)   |
                                              | proxy1.dmn3.com |
                                              |                 |
                                              | proxy2.dmn4.com |
                                              | (p5.p6.p7.p8)   |
       +---------------+      +----------+    +-----------------+
       |               |     /    IP      \           |
       |  s.dmn2.com   |----+  network(s)  +----------+
       | (s1.s2.s3.s4) |     \            /
       +---------------+      +----------+








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


      The user starts an instance of an FTP client program on the client
      system "c.dmn1.com", and specifies a destination of "s.dmn2.com",
      just like if it was reachable directly.  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 proxy 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 intermediate name server). Ultimately, the client
          system obtains a valid IP address for s.dmn2.com.