rfc1919.txt

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

        |  | address for        /      +-----+    | proxy system    |
        |  | s.dmn2.com?       /      /       \   | (p5.p6.p7.p8)   |
        |  |                  /      /         \  +-----------------+
        |  |                 /      /           \         |
        |  |                /      / s.dmn2.com? |        |
        |  |         +--------+   /              |   +--------+
        |  +-------->|  DNS   |--+   +-------+   |  /   IP     \
        |            | server |     /         \  | + network(s) +
        +------------|   X    |<---+           + |  \          /
         s1.s2.s3.s4 +--------+     s1.s2.s3.s4| |   +--------+
                                               | |        |
                                               | +        |
                                               |  \   +--------+
                                               +   +->|  DNS   |
                                                \     | server |
                                                 +----|   Y    |
                                                      +--------+

       NOTE: In practice, DNS servers that are authoritative for
             s.dmn2.com are highly likely to be located on the OTHER
             side of the proxy system. This means that DNS queries
             from the inside to the outside MUST be able to cross the
             proxy system. If the proxy system wishes to provide
             "address hiding", it must make these DNS queries
             (originating from the inside) appear to come from the
             proxy itself. This can be achieved by using a BIND-based
             DNS server (which has some proxy capabilities) or some
             simpler DNS proxy program.  For full RFC compliance,
             the proxy system must be able to relay TCP-based queries
             just like UDP-based queries, since some client systems
             are rumored to ONLY use TCP for DNS queries.

             The proxy system must be able to detect and block several
             classes of attacks based on DNS which (if nothing else)
             may cause denial of service:

             a) attempts from the outside to return corrupt cache
                entries to an internal DNS server
             b) attempts to return DNS bindings which have no
                relationship to the actual DNS query (some DNS
                servers are vulnerable to this). The attacker's goal
                may be to prime the cache of internal DNS servers with



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


                interesting entries, including entries for internal
                DNS names that point to external IP addresses...
             c) data-driven stuff similar in style to the "syslog
                buffer overrun" type attacks.

      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 for the server's IP address
      THAT LEADS TO THE PROXY SYSTEM, and the proxy system must have a
      valid route for the client's IP address and the server's IP
      address. All intermediate devices that behave like IP gateways
      must have valid routes for the client, the server, and usually the
      proxy. If these devices perform packet filtering, they must ALL
      allow the specific type of traffic required between C and S for
      this specific application.


                                                A
                                    route to S  |
                                                |
                                           +-----------------+
       +---------------+                   |  (p5.p6.p7.p8)  |
       |  c.dmn1.com   |                   | proxy system    |
       | (c1.c2.c3.c4) |                   |  (p1.p2.p3.p4)  |
       +---------------+                   +-----------------+
         | |                                    |   |
         | | 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

      At the start of the FTP session, a TCP packet with a source
      address of C and a destination address of S travels to the proxy
      system, expecting to cross it just like a normal IP gateway.

      This is when the transparent proxy shows its magic:

      The proxy's TCP/IP software stack sees this incoming packets (and
      subsequent ones) for a destination address that is NOT one of its
      own addresses. Based on some criteria (a configuration file, for



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


      example), it decides NOT to forward or drop the packet (which are
      the only two choices an RFC-standard TCP/IP implementation would
      have). The proxy system accepts the packet as if it was directed
      to one of its own IP addresses.

      In our example, the incoming packet is a TCP packet. Since
      standard TCP/IP stacks store both a LOCAL and REMOTE IP address
      field for each TCP connection, the transparent proxy may set the
      LOCAL IP address field to the IP address that the client wants to
      reach (s1.s2.s3.s4 in our example). The standard TCP/IP stack
      probably needs to be modified to do this. UDP examples, although
      not connection-based, could be handled in similar ways.

      Once this is done, the actual FTP proxy application is invoked
      since an incoming connection to TCP port 21 has occurred. It can
      determine what is the final target destination instantly, since
      the LOCAL IP address field of the connection contains the target
      server's IP address.  There is no need for the proxy application
      to ask the client what is the final target system.

      Since the FTP proxy application knows the 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 a "classical" proxy. This seems technically
          feasible, although no real transparent proxy system is
          known to offer this capability. The actual value of such
          a feature (if available) would need to be studied.

      If the FTP proxy decides to connect directly to the target system,
      it has the target system's IP address. It may choose to do a
      reverse lookup on the target IP address to obtain a target system
      name (possibly needed for access control). If this process
      involves DNS resolution, something like the following will happen:













Chatel                       Informational                     [Page 24]

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) |
        |  | name for           /            \      | s.dmn2.com    |
        |  | s1.s2.s3.s4?      /              \     |               |
        |  |                  /                \    +---------------+
        |  |                 /                  \
        |  |                /                    \
        |  |         +--------+   s1.s2.s3.s4?    +--------+
        |  +-------->|  DNS   |------------------>|  DNS   |
        |            | server |                   | server |
        +------------|   X    |<------------------|   Y    |
         s.dmn2.com  +--------+    s.dmn2.com     +--------+


      Once this is done and if the connection is allowed, the proxy
      attempts to establish a connection to the standard FTP "control"
      TCP port on the target server (port 21), using a technique
      identical to a "classical" proxy. 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 S for this
      specific application.




















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


       +-----------------+
       | proxy1.dmn3.com |
       |  (p1.p2.p3.p4)  |
       |                 |                 +----------------+
       | proxy2.dmn4.com |                 |  s.dmn2.com    |
       |  (p5.p6.p7.p8)  |                 | (s1.s2.s3.s4)  |
       +-----------------+                 +----------------+
         | |                                    |   |
         | | route to S             route to P2 |   |
         | V                                    V   |
         |                                          |
         | A                                        | A
         | | route to P2                            | | route to S
         | |                                        | |
         | |      P2         S                 P2   | |
       +----+    <-- +----+ -->    +----+     <-- +----+
       | G1 |--------| Gx |--------| Gy |---------| Gn |
       +----+ -->    +----+    <-- +----+ -->     +----+
               S                P2         S


      The rest of the transparent proxy's operation is very similar to
      what would happen with a classical proxy.

   4.2 Characteristics of transparent proxy configurations

      Transparent proxy technology can be used to build the key
      component of a "firewall", in a way quite similar to the way
      classical proxy technology may be used. Several important details
      of the architecture must be different, however.

      4.2.1 IP addressing and routing requirements

         The transparent proxy system must be able to address all client
         and server systems to which it may provide service. It must
         also know valid IP routes to all these client and server
         systems.

         Server systems must be able to address the proxy system, and
         must know a valid IP route to the proxy system. If the proxy
         system has several IP addresses (and often, several physical
         network interfaces), the server systems need only to be able to
         access ONE of the proxy system's IP addresses.

         Client systems MUST HAVE valid IP addressing and routing
         information for systems that they reach through the proxy. For
         example, in the common case where a transparent proxy is being
         used to interconnect a private network and the Internet, the



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


         private network will effectively need to use a default route
         that points to the transparent proxy system. This is a specific
         need of transparent proxy configurations.

         Interconnecting two internetworks with multiple transparent
         proxies (for load sharing or fail-over) can be accomplished by
         using different techniques from what would be done for
         classical proxies:

             a) with multiple classical proxies to the same remote
                network, clients can be configured to access different
                proxies manually, or DNS-based techniques, such as
                DNS load-balancing may be used to make clients
                access a different proxy at different times.

             b) with multiple transparent proxies to the same remote
                network, the internal network must be able to provide
                dynamic routing towards the proxies (routing updates
                may need to be supplied by the proxies themselves).