rfc1919.txt

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

        +------------|   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
      S for this specific application.






















Chatel                       Informational                     [Page 11]

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 actual FTP application work between the proxy and server is
      done with a bidirectional flow of TCP packets between the proxy's
      and server's IP addresses.

      What actually happens BETWEEN THE CLIENT AND SERVER?  They both
      send replies and responses to the proxy, which forwards data to
      the "other" end. When one party opens a data connection and sends
      a PORT command to the proxy, the proxy allocates its own data
      connection and sends its PORT command to the "other" end. The
      proxy also copies data across the connections created in this way.

   3.2 Characteristics of classical proxy configurations

      Several IP internetworks may be linked using only classical proxy
      technology. It is currently popular to link two specific IP
      internetworks in this way: the Internet and some organization's
      "private" IP network. Such a proxy-based link is often the key
      component of a firewall.

      When this is done, several benefits and problems are introduced
      for network administrators and users.

      3.2.1 IP addressing and routing requirements.

         The 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.



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


         Client and 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 client and server systems
         need only to be able to access ONE of the proxy system's IP
         addresses.

         Note that client and server systems that use the proxy for
         communication DO NOT NEED valid IP addressing or routing
         information for systems that they reach through the proxy.

         In this sense, it can be said that systems separated by a
         classical proxy are isolated from each other in an IP
         addressing sense and in an IP routing sense.

         On the other hand, the classical proxy system (if running a
         standard TCP/IP software stack) needs to have a single coherent
         view of IP addressing and routing. If such a proxy system
         interconnects two IP networks and two systems use the same IP
         network/subnetwork number (one system on each network), the
         proxy will only be able to address one of the systems.

         This restriction can be removed by chaining classical proxies
         (this is described later in section 3.2.6, "Interconnection of
         conflicting IP networks").

         Using a classical proxy for interconnection of IP
         internetworks, it is also possible, with care, to achieve a
         desirable "fail-safe" feature: no valid routing entries need to
         exist for an internetwork which should be reached only through
         the proxy (routing updates that could add such entries shout be
         BLOCKED). If the proxy suddenly starts to behave like an IP
         router, only one-way attacks become possible.

         In other words, assume an attacker has control of the remote
         internetwork and has found a way to cause the proxy to route IP
         packets, or has found a way to physically bypass the proxy.

         The attacker may inject packets, but the attacked internal
         systems will be unable to reply to those packets. This
         certainly does not make attacks infeasible (as exemplified by
         certain holiday-period events in recent years), but it still
         makes attacks more difficult.








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


      3.2.2 IP address hiding

         Application "sessions" that go through a classical proxy are
         actually made of two complete sessions:

             a) a session between the client and the proxy
             b) a session between the proxy and the server

         A device on the path sees only the client<->proxy traffic or
         the proxy<->server traffic, depending where it is located. If
         the two sessions actually pass through the same physical
         network, a device on that network may see both traffics, but
         may have difficulty establishing the relationship between the
         two sessions (depending on the specific application and
         activity level of the network).

         A by-product of a classical proxy's behavior is commonly known
         as "address hiding". Equipments on some side of a classical
         proxy cannot easily determine what are the IP addresses used on
         another side of the proxy.

         Address hiding is generally viewed as a Good Thing, since one
         of the purposes of deploying proxies is to disclose as little
         information about an internetwork as possible.

         People who are in charge of gathering network statistics, and
         who do not have access to the proxy system's reports (if any)
         may consider address hiding to be a Bad Thing, since the proxy
         obscures the actual client/server relationships where the proxy
         was inserted.  All IP activity originates and terminates on the
         proxy itself (or appears to do so).

         In the same way, server software that accepts connections that
         have gone through a classical proxy do not see the IP address
         of the incoming client, unless this information is included in
         the application protocol (and even if it is, in many cases, the
         proxy will replace this information with its own address for
         the protocol to be consistent). This makes server access
         control unusable if it is based on client IP address checks.

      3.2.3 DNS requirements

         In most classical-proxy configurations, client systems pass the
         desired server name (or address) to the proxy system WITHOUT
         INTERPRETING IT. Because of this, the client system DOES NOT
         REQUIRE to be able to resolve the name of the server system in
         order to access it through a classical proxy. It only needs to
         be able to resolve the name of the proxy (if referencing the



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


         proxy system by name).

         Because of this, it can be said that a classical proxy system
         can offer DNS isolation. If two IP internetworks use completely
         separate DNS trees (each with their own DNS root servers),
         client software in one IP internetwork may still reference a
         server name in the other IP internetwork by passing its name to
         the classical proxy.

         The classical proxy itself will not be able alone to resolve
         DNS names in both environments (if running standard DNS
         resolution software), since it will need to point to one or the
         other of the two DNS "universes".

         A well-known technique called "split-brain DNS" can be used to
         relax this restriction somewhat, but such a technique
         ultimately involves prioritizing one DNS environment over
         another. If a DNS query can return a valid answer in both
         environments, only one of the answers will be found by the
         proxy.

      3.2.4 Software requirements

         A classical proxy application is a fairly simple piece of
         software, often simpler than either a real client
         implementation or a real server implementation.  Such a program
         may run on any system that supports normal TCP/IP connections,
         and often does not require "system" or "superuser" privilege.

         Classical proxy connections have no impact on normal server
         software; the proxy looks like a normal client in most respects
         except for its IP address and its "group" nature. All
         connections from the network on the other side of the proxy
         appear to come from the proxy, which poses problems if access
         control by client system is desired.

         Normal client software may access a classical proxy if the user
         is willing or able to go through the extra steps necessary to
         indicate the final server to the proxy (whatever they are).
         Alternatively, modified (or newer) client software may be used
         that knows how to negotiate transparently with the proxy.

      3.2.5 Impact of a classical proxy on packet filtering

         If packet filtering is needed around a classical proxy, the
         packet filtering rules tend to be simplified, since the only
         traffic needed and allowed will originate from or terminate on
         the proxy (in an IP sense).



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


         If the proxy starts behaving like an IP router, or if it is
         physically bypassed, such filtering rules, if deployed
         generally within an IP internetwork, will tend to prevent any
         direct traffic flow between the "internal" internetwork and
         "external" internetworks that are supposed to be only reachable
         through the application proxy.

      3.2.6 Interconnection of conflicting IP networks

         By chaining classical proxies, it is possible to achieve some
         interconnection of IP networks that have a high level of
         conflict. In practice, this type of setup resolves IP
         addressing conflicts much better than DNS conflicts. But DNS
         conflicts are currently less of a problem because the DNS
         "address space" is almost infinitely large (has anybody
         calculated the possible DNS address space based on the RFC-
         standard maximum host name length?).

         Even though RFC 1597 was never more than an informational RFC,
         many organizations have been quietly following its suggestions,
         for lack of an easier solution. Now assume two organizations
         each use class A network number 10 on their network. Suddenly,
         they need to interconnect.  What can they do?

         First possibility: one side changes network number (not as hard
         as people think if properly planned, but this still represents
         some work)