rfc1919.txt

中、英文RFC文档大全打包下载完全版 .

   e) perform access controls according to the proxy's design
      criteria (the main goal of the proxy, after all).

   The functional goal of the proxy is to relay application data between
   clients and servers that may not have direct IP connectivity. The
   security goal of the proxy is to do checks and types of access
   controls that typical client and server software do not support or
   implement.

   The following information will make it clear that classical proxies
   can offer many hidden benefits to the security-conscious network
   designer, at the cost of deploying client software with proxy
   capabilities or of educating the users on proxy use.

   Client software issues are now easier to handle, given the increasing
   number of popular client applications (for Web, FTP, etc.) that offer
   proxy support. Designers developing new protocols are also more
   likely to plan proxy capability from the outset, to ensure their
   protocols can cross the many existing large corporate firewalls that
   are based at least in part on classical proxy technology.

   3.1 Classical proxy session example

      We will repeat our little analysis of an FTP session. This time,
      the FTP session is passing through a "classical" application proxy
      system. As is often the case (although not required), we will
      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". 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.




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


       +---------------+      +----------+
       |               |     /    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) |     \            /
       +---------------+      +----------+


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

          ftp proxy1.dmn3.com

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

      Converting the proxy 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 proxy's DNS branch.
          Eventually, a DNS server which is authoritative for the
          proxy system's domain is queried and returns the IP
          address associated with "proxy1.dmn3.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 proxy1.dmn3.com.






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


       +---------------+          +--------+
       |               |         /   IP     \
       |  c.dmn1.com   |--------+ network(s) +------------+
       | (c1.c2.c3.c4) |         \          /             |
       +---------------+          +--------+      +-----------------+
        A  |                     /          \     | (p1.p2.p3.p4)   |
        |  | address for        /            \    | proxy1.dmn3.com |
        |  | proxy1.dmn3.com?  /              \   |    ...          |
        |  |                  /                \  +-----------------+
        |  |                 /                  \
        |  |                /                    \
        |  |         +--------+ proxy1.dmn3.com?  +--------+
        |  +-------->|  DNS   |------------------>|  DNS   |
        |            | server |                   | server |
        +------------|   X    |<------------------|   Y    |
         p1.p2.p3.p4 +--------+    p1.p2.p3.p4    +--------+

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

      Finally, the proxy system must accept this incoming connection,
      based on the client's IP address (the purpose of the proxy is
      generally to do access control, after all).

       +---------------+                   |      ...        |
       |  c.dmn1.com   |                   | proxy1.dmn3.com |
       | (c1.c2.c3.c4) |                   |  (p1.p2.p3.p4)  |
       +---------------+                   +-----------------+
         | |                                    |   |
         | | route to P1             route to C |   |
         | V                                    V   |
         |                                          |
         | A                                        | A
         | | route to C                             | | route to P1
         | |                                        | |
         | |      C          P1                C    | |
       +----+    <-- +----+ -->    +----+     <-- +----+
       | G1 |--------| Gx |--------| Gy |---------| Gn |
       +----+ -->    +----+    <-- +----+ -->     +----+
               P1               C          P1



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


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

      For this to work, the proxy FTP application MUST fully support the
      FTP protocol and look identical to an FTP server from the client's
      point of view.

      Once the client<->proxy session is established, the final target
      server name must be passed to the proxy, since, when using a
      "classical" application proxy, a way MUST be defined for the proxy
      to determine the final target system. This can be achieved in
      three ways:

       a) The client system supplies the name or address of the final
          target system to the proxy in a method that is compatible
          with the specific application protocol being used (in our
          example, FTP). This is generally considered to be the main
          problem with classical proxies, since for each application
          being proxied, a method must be defined for passing the
          name or address of the final target system. This method
          must be compatible with every variant of client application
          that implements the protocol (i.e. the target-passing
          method must fit within the MINIMUM functionalities required
          by the specific application protocol).

          For the FTP protocol, the generally popular method for
          passing the final server name to the proxy is as follows:

          When the proxy prompts the FTP client for a username, the
          client specifies a string of the form:

                target_username@target_system_name
                or
                target_username@target_ip_address

          The proxy will then know what is the final target system.
          The target_username (and the password supplied by the
          client) will be forwarded "as is" by the proxy to the final
          target system.

          A well-known example of an FTP proxy that behaves in this way
          is the "ftp-gw" program which is part of the Trusted
          Information System's firewall toolkit, available by anonymous
          FTP at ftp.tis.com. Several commercial firewalls also support
          this de-facto standard.





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


       b) If there is only one possible final destination, the proxy
          may be configured to know this destination in advance.
          Since the IP address of the client system is known when the
          proxy must make this decision, the proxy can (if required)
          select a different destination based on the IP address of
          the client.

       c) The client software may also support capabilities that allow
          it to present to the user the illusion of a direct session
          (the user just specifies the final target system, and the
          client software automatically handles the problem of
          reaching to the proxy system and passing the name or address
          of the final target system in whatever mutually-acceptable
          form).

          A well-known example of a system that provides modified
          client software, proxy software, and that provides the
          illusion of transparency is NEC's SOCKS system, available by
          anonymous FTP at ftp.nec.com.

          Alternatively, several FTP client applications support the
          "username@destination_host" de-facto standard implemented
          (for example) by the "ftp-gw" proxy application.

      Once the FTP proxy application knows the name or IP address of the
      target system, it can choose to do two things:

       a) Setup a session to the final target system, the more
          frequent case.

       b) Decide (based on some internal configuration data) that it
          cannot reach the final target system directly, but must go
          through another proxy. This is rare today, but may become
          temporarily common due to the current shortage of IP
          network numbers which encourages organizations to deploy
          "hidden" network numbers which are already assigned
          elsewhere. Sessions between systems which have the same
          IP network number but which belong to different actual
          networks may require going through two proxy systems.
          This is discussed in more detail in section 3.2.6,
          "Interconnection of conflicting IP networks".

      If the FTP proxy decides to connect directly to the target system,
      and what it has is the target system name, it will need to convert
      the target system name into an IP address. If this process
      involves DNS resolution, something like the following will happen:





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


       +-----------------+
       | proxy1.dmn3.com |
       |  (p1.p2.p3.p4)  |          +--------+
       |                 |         /   IP     \
       | proxy2.dmn4.com |--------+ network(s) +------------+
       |  (p5.p6.p7.p8)  |         \          /             |
       +-----------------+          +--------+      +---------------+
        A  |                     /          \       | (s1.s2.s3.s4) |
        |  | address for        /            \      | s.dmn2.com    |
        |  | s.dmn2.com?       /              \     |               |
        |  |                  /                \    +---------------+
        |  |                 /                  \
        |  |                /                    \
        |  |         +--------+   s.dmn2.com?     +--------+
        |  +-------->|  DNS   |------------------>|  DNS   |
        |            | server |                   | server |
        +------------|   X    |<------------------|   Y    |
         s1.s2.s3.s4 +--------+    s1.s2.s3.s4    +--------+

      Once the proxy 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
      proxy system must have a valid route to the server's IP address,
      and the server system must have a valid route to at least one of
      the proxy's IP address. All intermediate devices that behave like
      IP gateways must have valid routes to both the proxy and the
      server. If these devices perform packet filtering, they must ALL
      allow the specific type of traffic required between the proxy and