As per Relevance of the word internal, we have this rfc below:
Network Working Group M.
Request for Comments: 1919
Category: Informational March 1996
Classical versus Transparent IP
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
Many modern IP security systems (also called "firewalls" in
trade) make use of proxy technology to achieve access control.
document explains "classical" and "transparent" proxy techniques
attempts to provide rules to help determine when each proxy
may be used without causing problems
Table of
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.
An increasing number of organizations use IP security systems
provide specific access control when crossing network
perimeters. These systems are often deployed at the network
between two organizations (which may be part of the same "official
entity), or between an organization's network and a large
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
security capabilities will gradually make firewalls look like
solutions, and therefore irrelevant to the computer networking scene
In any case, it is currently important to examine the impact
inserting (and removing) a firewall at a network boundary, and
verify whether specific types of firewall technologies may
different effects on typical small and large IP networks
Current firewall designs usually rely on packet filtering,
technology, or a combination of both. Packet filtering (although
to configure correctly in a security sense) is now a well
technology whose strengths and weaknesses are reasonably understood
Proxy technology, on the other hand, has been deployed a lot
studied little. Furthermore, many recent firewall products support
capability called "transparent proxying". This type of feature
been subject to much more marketing attention than actual
analysis by the networking community
It must be remembered that the Internet's growth and success
strongly related to its "open" nature. An Internet which would
been segmented from the start with firewalls, packet filters,
proxies may not have become what it is today. This type of
is, however, outside the scope of this document, which just
to provide an understandable description of what are network proxies
and of what are the differences, strengths, and weaknesses
"classical" and "transparent" network proxies. Within the context
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
application session that uses TCP, while the word "session" refers
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
use normal TCP/IP to communicate with each other. It is
(for readers who may not be familiar with this) to take a quick
at the operations involved, in order to better understand what is
exact use of a proxy
2.1 Direct connection
Let's take a familiar network session and describe some details
its operation. We will look at what happens when a user on
client system "c.dmn1.com" sets up an FTP connection to the
system "s.dmn2.com". The client system's IP address
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
system "c.dmn1.com", and specifies that the target system
"s.dmn2.com". On command-line systems, the user typically types
ftp s.dmn2.
The client system needs to convert the server's name to an
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
performed which ranges between two extremes
a) the client system has this name in its hosts file, or
local DNS caching capability and successfully retrieves
name of the server system in its cache. No network
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
root of the DNS tree and back down the server's DNS branch
Eventually, a DNS server which is authoritative for
server system's domain is queried and returns the
address associated with "s.dmn2.com" (depending on the case
it may return this to the client system directly or to
Chatel Informational [Page 3]
RFC 1919 Classical versus Transparent IP Proxies March 1996
intermediate name server). Ultimately, the client
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
"control" TCP port on the server (port 21). For this to work,
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
address. All intermediate devices that behave like IP
must have valid routes for both the client and the server.
these devices perform packet filtering, they must ALL allow
specific type of traffic required between C and S for
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 |
| | route to C | | route to
| | | |
| | C S C | |
+----+ <-- +----+ --> +----+ <-- +----+
| G1 |--------| Gx |--------| Gy |---------| Gn |
+----+ --> +----+ <-- +----+ --> +----+
S C
Chatel Informational [Page 4]
RFC 1919 Classical versus Transparent IP Proxies March 1996
The actual application work for the FTP session between the
and server is done with a bidirectional flow of TCP
between the client's and server's IP addresses
The FTP protocol uses a slightly complex protocol and
connection model which is, luckily, not important to the
discussion. This allows slightly shortening this document...
2.2 Requirements of direct
Based on the preceding discussion, it is possible to say that
following is required for a direct session between a client
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-
binding for the server, or it must be able to resolve
server name (typically using DNS). In the case of DNS,
implies that the client and server must be part of the
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
towards the client and server ("IP gateway" is the
standard terminology; people often use the term "IP router
in computer rooms).
c) If there are devices on the path between the client
server that perform packet filtering, all these devices
permit the forwarding of packets between the IP address
the client and the IP address of the server, at least
packets that fit the protocol model of the FTP
(TCP ports used, etc.).
3. Classical application
A classical application proxy is a special program that knows one (
more) specific application protocols. Most application protocols
not symetric; one end is considered to be a "client", one end is
"server".
A classical application proxy implements both the "client"
"server" parts of an application protocol. In practice, it only
to implement enough of the client and server protocols to
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
server (this needs to be passed over the "client-proxy"
in a way that is application-specific);
c) setup a session to the final server and appear to be a
from the server's point of view
d) relay requests, responses, and data between the client
server
e) perform access controls according to the proxy's
criteria (the main goal of the proxy, after all).
The functional goal of the proxy is to relay application data
clients and servers that may not have direct IP connectivity.
security goal of the proxy is to do checks and types of
controls that typical client and server software do not support
implement
The following information will make it clear that classical
can offer many hidden benefits to the security-conscious
designer, at the cost of deploying client software with
capabilities or of educating the users on proxy use
Client software issues are now easier to handle, given the
number of popular client applications (for Web, FTP, etc.) that
proxy support. Designers developing new protocols are also
likely to plan proxy capability from the outset, to ensure
protocols can cross the many existing large corporate firewalls
are based at least in part on classical proxy technology
3.1 Classical proxy session
We will repeat our little analysis of an FTP session. This time
the FTP session is passing through a "classical" application
system. As is often the case (although not required), we
assume that the proxy system has two IP addresses, two
interfaces, and two DNS names
The proxy system is running a special program which knows how
behave like an FTP client on one side, and like an FTP server
the other side. This program is what people call the "proxy".
will assume that the proxy program is listening to
requests on the standard FTP control port (21/tcp), although
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
system "c.dmn1.com", and MUST specify that the target system
"proxy1.dmn3.com". On command-line systems, the user
types
ftp proxy1.dmn3.
The client system needs to convert the proxy's name to an
address (if the user directly specified the proxy by address,
step is not needed).
Converting the proxy name to an IP address requires work to
performed which ranges between two extremes
a) the client system has this name in its hosts file, or
local DNS caching capability and successfully retrieves
name of the proxy system in its cache. No network
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
root of the DNS tree and back down the proxy's DNS branch
Eventually, a DNS server which is authoritative for
proxy system's domain is queried and returns the
address associated with "proxy1.dmn3.com" (depending on
case, it may return this to the client system directly
to an intermediate name server). Ultimately, the
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
"control" TCP port on the proxy (port 21). For this to work,
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
address. All intermediate devices that behave like IP
must have valid routes to both the client and the proxy. If
devices perform packet filtering, they must ALL allow the
type of traffic required between C and P1 for this
application (FTP).
Finally, the proxy system must accept this incoming connection
based on the client's IP address (the purpose of the proxy
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 |
| | route to C | | route to P
| | | |
| | C P1 C | |
+----+ <-- +----+ --> +----+ <-- +----+
| G1 |--------| Gx |--------| Gy |---------| Gn |
+----+ --> +----+ <-- +----+ --> +----+
P1 C P
Chatel Informational [Page 8]
RFC 1919 Classical versus Transparent IP Proxies March 1996
The actual application work for the FTP session between the
and proxy is done with a bidirectional flow of TCP packets
the client's and proxy's IP addresses
For this to work, the proxy FTP application MUST fully support
FTP protocol and look identical to an FTP server from the client'
point of view
Once the client<->proxy session is established, the final
server name must be passed to the proxy, since, when using
"classical" application proxy, a way MUST be defined for the
to determine the final target system. This can be achieved
three ways
a) The client system supplies the name or address of the
target system to the proxy in a method that is
with the specific application protocol being used (in
example, FTP). This is generally considered to be the
problem with classical proxies, since for each
being proxied, a method must be defined for passing
name or address of the final target system. This
must be compatible with every variant of client
that implements the protocol (i.e. the target-
method must fit within the MINIMUM functionalities
by the specific application protocol).
For the FTP protocol, the generally popular method
passing the final server name to the proxy is as follows
When the proxy prompts the FTP client for a username,
client specifies a string of the form
target_username@target_system_
target_username@target_ip_
The proxy will then know what is the final target system
The target_username (and the password supplied by
client) will be forwarded "as is" by the proxy to the
target system
A well-known example of an FTP proxy that behaves in this
is the "ftp-gw" program which is part of the
Information System's firewall toolkit, available by
FTP at ftp.tis.com. Several commercial firewalls also
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
may be configured to know this destination in advance
Since the IP address of the client system is known when
proxy must make this decision, the proxy can (if required
select a different destination based on the IP address
the client
c) The client software may also support capabilities that
it to present to the user the illusion of a direct
(the user just specifies the final target system, and
client software automatically handles the problem
reaching to the proxy system and passing the name or
of the final target system in whatever mutually-
form).
A well-known example of a system that provides
client software, proxy software, and that provides
illusion of transparency is NEC's SOCKS system, available
anonymous FTP at ftp.nec.com
Alternatively, several FTP client applications support
"username@destination_host" de-facto standard
(for example) by the "ftp-gw" proxy application
Once the FTP proxy application knows the name or IP address of
target system, it can choose to do two things
a) Setup a session to the final target system, the
frequent case
b) Decide (based on some internal configuration data) that
cannot reach the final target system directly, but must
through another proxy. This is rare today, but may
temporarily common due to the current shortage of
network numbers which encourages organizations to
"hidden" network numbers which are already
elsewhere. Sessions between systems which have the
IP network number but which belong to different
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
the target system name into an IP address. If this
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
"control" TCP port on the server (port 21). For this to work,
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
the proxy's IP address. All intermediate devices that behave
IP gateways must have valid routes to both the proxy and
server. If these devices perform packet filtering, they must
allow the specific type of traffic required between the proxy
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 |
| | route to P2 | | route to
| | | |
| | P2 S P2 | |
+----+ <-- +----+ --> +----+ <-- +----+
| G1 |--------| Gx |--------| Gy |---------| Gn |
+----+ --> +----+ <-- +----+ --> +----+
S P2
The actual FTP application work between the proxy and server
done with a bidirectional flow of TCP packets between the proxy'
and server's IP addresses
What actually happens BETWEEN THE CLIENT AND SERVER? They
send replies and responses to the proxy, which forwards data
the "other" end. When one party opens a data connection and
a PORT command to the proxy, the proxy allocates its own
connection and sends its PORT command to the "other" end.
proxy also copies data across the connections created in this way
3.2 Characteristics of classical proxy
Several IP internetworks may be linked using only classical
technology. It is currently popular to link two specific
internetworks in this way: the Internet and some organization'
"private" IP network. Such a proxy-based link is often the
component of a firewall
When this is done, several benefits and problems are
for network administrators and users
3.2.1 IP addressing and routing requirements
The proxy system must be able to address all client and
systems to which it may provide service. It must also
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
system, and must know a valid IP route to the proxy system.
the proxy system has several IP addresses (and often,
physical network interfaces), the client and server
need only to be able to access ONE of the proxy system's
addresses
Note that client and server systems that use the proxy
communication DO NOT NEED valid IP addressing or
information for systems that they reach through the proxy
In this sense, it can be said that systems separated by
classical proxy are isolated from each other in an
addressing sense and in an IP routing sense
On the other hand, the classical proxy system (if running
standard TCP/IP software stack) needs to have a single
view of IP addressing and routing. If such a proxy
interconnects two IP networks and two systems use the same
network/subnetwork number (one system on each network),
proxy will only be able to address one of the systems
This restriction can be removed by chaining classical
(this is described later in section 3.2.6, "Interconnection
conflicting IP networks").
Using a classical proxy for interconnection of
internetworks, it is also possible, with care, to achieve
desirable "fail-safe" feature: no valid routing entries need
exist for an internetwork which should be reached only
the proxy (routing updates that could add such entries shout
BLOCKED). If the proxy suddenly starts to behave like an
router, only one-way attacks become possible
In other words, assume an attacker has control of the
internetwork and has found a way to cause the proxy to route
packets, or has found a way to physically bypass the proxy
The attacker may inject packets, but the attacked
systems will be unable to reply to those packets.
certainly does not make attacks infeasible (as exemplified
certain holiday-period events in recent years), but it
makes attacks more difficult
Chatel Informational [Page 13]
RFC 1919 Classical versus Transparent IP Proxies March 1996
3.2.2 IP address
Application "sessions" that go through a classical proxy
actually made of two complete sessions
a) a session between the client and the
b) a session between the proxy and the
A device on the path sees only the client<->proxy traffic
the proxy<->server traffic, depending where it is located.
the two sessions actually pass through the same
network, a device on that network may see both traffics,
may have difficulty establishing the relationship between
two sessions (depending on the specific application
activity level of the network).
A by-product of a classical proxy's behavior is commonly
as "address hiding". Equipments on some side of a
proxy cannot easily determine what are the IP addresses used
another side of the proxy
Address hiding is generally viewed as a Good Thing, since
of the purposes of deploying proxies is to disclose as
information about an internetwork as possible
People who are in charge of gathering network statistics,
who do not have access to the proxy system's reports (if any
may consider address hiding to be a Bad Thing, since the
obscures the actual client/server relationships where the
was inserted. All IP activity originates and terminates on
proxy itself (or appears to do so).
In the same way, server software that accepts connections
have gone through a classical proxy do not see the IP
of the incoming client, unless this information is included
the application protocol (and even if it is, in many cases,
proxy will replace this information with its own address
the protocol to be consistent). This makes server
control unusable if it is based on client IP address checks
3.2.3 DNS
In most classical-proxy configurations, client systems pass
desired server name (or address) to the proxy system
INTERPRETING IT. Because of this, the client system DOES
REQUIRE to be able to resolve the name of the server system
order to access it through a classical proxy. It only needs
be able to resolve the name of the proxy (if referencing
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
can offer DNS isolation. If two IP internetworks use
separate DNS trees (each with their own DNS root servers),
client software in one IP internetwork may still reference
server name in the other IP internetwork by passing its name
the classical proxy
The classical proxy itself will not be able alone to
DNS names in both environments (if running standard
resolution software), since it will need to point to one or
other of the two DNS "universes".
A well-known technique called "split-brain DNS" can be used
relax this restriction somewhat, but such a
ultimately involves prioritizing one DNS environment
another. If a DNS query can return a valid answer in
environments, only one of the answers will be found by
proxy
3.2.4 Software
A classical proxy application is a fairly simple piece
software, often simpler than either a real
implementation or a real server implementation. Such a
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
software; the proxy looks like a normal client in most
except for its IP address and its "group" nature.
connections from the network on the other side of the
appear to come from the proxy, which poses problems if
control by client system is desired
Normal client software may access a classical proxy if the
is willing or able to go through the extra steps necessary
indicate the final server to the proxy (whatever they are).
Alternatively, modified (or newer) client software may be
that knows how to negotiate transparently with the proxy
3.2.5 Impact of a classical proxy on packet
If packet filtering is needed around a classical proxy,
packet filtering rules tend to be simplified, since the
traffic needed and allowed will originate from or terminate
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
physically bypassed, such filtering rules, if
generally within an IP internetwork, will tend to prevent
direct traffic flow between the "internal" internetwork
"external" internetworks that are supposed to be only
through the application proxy
3.2.6 Interconnection of conflicting IP
By chaining classical proxies, it is possible to achieve
interconnection of IP networks that have a high level
conflict. In practice, this type of setup resolves
addressing conflicts much better than DNS conflicts. But
conflicts are currently less of a problem because the
"address space" is almost infinitely large (has
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
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
as people think if properly planned, but this still
some work
Second possibility: they merge the two numbers by
partially on each side to remove conflicts (actually harder
do, but has the political advantage that both sides have to
some work
Third possibility: they communicate through chained
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/
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
network number that is not used (or not needed)
either side. Nothing on Org.1 and Org.2's
need to have an IP route to this network
b) Proxy 1 has an IP route for network 10 that points
Organization 1's network, and does DNS
(if required) using dmn1.com's name servers
c) Proxy 2 has an IP route for network 10 that points
Organization 2's network, and does DNS
(if required) using dmn2.com's name servers
d) Proxy 1 and proxy 2 only require a host IP route
each other for communication
e) For this to be convenient, the classical
applications must support the automatic selection
a destination based on the client IP address
f) On proxy system 1, the proxy software treats
sessions from proxy system 2 in the normal way:
"client" (proxy system 2) will be prompted in
application-specific way for the final destination
However, incoming sessions from Org.1 addresses
immediately and automatically forwarded to
system 2.
Proxy system 2 is configured similarly (that is
connections coming from proxy 1 are prompted for
target server name, connections from Org.2
are immediately and automatically forwarded
proxy 1.
From a user's point of view, the behavior of such a
proxy system is not very different from a single
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
"server.dmn2.com".
b) The user starts an FTP towards proxy 1. Proxy 1
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
prompts the client. The user sees the username
Chatel Informational [Page 17]
RFC 1919 Classical versus Transparent IP Proxies March 1996
and types (assuming FTP proxies that behave like TIS'
ftp-gw):
anonymous@server.dmn2.
This will be resolved IN THE CONTEXT OF Org. 2'
NETWORK. The user can then complete the dialog
use the FTP connection
d) Note that this setup will work even if the client
server have the EXACT SAME IP ADDRESS (10.1.2.3
our example).
If the proxy applications support selecting
proxy based on the destination supplied by the client
and if DNS domains are unique, more than two
IP networks can be linked in this way! Here is
example configuration
a) Four IP networks that all use network 10 are
by four proxy systems. The four proxy systems share
common, private IP network number and physical
(LAN or WAN).
b) A user on organization 1's network wishes to
a server on network 3. The user connects to its
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
proxy 3. So it connects to proxy 3 and passes
target system name
d) Proxy 3 determines that the target system name
local (to itself) and connects to it directly
Security Implications of chained
Obviously, when such "chained" configurations are built
access control rules and logging based on
final-client/final-server combination are difficult
enforce, since the first proxy in the chain sees
final-client/proxy relationship and the last proxy
the chain sees a proxy/final-server relationship
Doing better than this requires that the proxies
capable of passing the "original-client"
Chatel Informational [Page 18]
RFC 1919 Classical versus Transparent IP Proxies March 1996
"final-destination" information back and forth in
proxy chain for access control and/or logging purposes
This requires the proxies to trust each other,
requires the network path to be trusted (forging
information becomes an excellent attack).
Even if these problems were to be solved reliably,
original goal of the proxy chains was to solve an
and possibly a DNS conflict. The "original-client"
"final-destination" values may not have the
meaning everywhere in the overall setup. Tagging
information with a "universe-name" may help,
it is possible to define unique universe names in
first place. Obviously this topic requires more study
4. Transparent application
The most visible problem of classical application proxies is the
for proxy-capable client programs and/or user education so that
know how to use the proxies
When somebody thought of modifying proxies in such a way that
user procedures and normal client applications would still be able
take advantage of the proxies, the transparent proxy was born
A transparent application proxy is often described as a system
appears like a packet filter to clients, and like a classical
to servers. Apart from this important concept, transparent
classical proxies can do similar access control checks and can
an equivalent level of security/robustness/performance, at least
far as the proxy itself is concerned
The following information will make it clear that small
that wish to use proxy technology for protection, that wish to
entirely on one proxy system for network perimeter security,
want a minimal (or zero) impact on user procedures, and that do
wish to bother with proxy-capable clients will tend to
transparent proxy technology
Organizations with one or more of the following characteristics
prefer deploying classical proxy technology
a) own a substantial internal IP router network, and wish
avoid adding "external" routes on the
b) wish to deploy "defence in depth", such as internal firewalls
packet filtering on the internal
c) wish to keep their DNS environment fully isolated from
"other side" of their proxy system, or that fear that
Chatel Informational [Page 19]
RFC 1919 Classical versus Transparent IP Proxies March 1996
internal DNS servers may be vulnerable to data-driven
d) use some IP networks that are in conflict with the "other side
of their proxy
e) wish to use proxy applications that are easily
to different operating system types and/or
f) wish to deploy multiple proxy systems interconnecting
to the SAME remote network without introducing
routing for external routes on the internal
4.1 Transparent proxy connection
Let us go through an FTP sesssion again, through a "transparent
proxy this time. We assume that the proxy system has two
addresses, two network interfaces, and two DNS names
The proxy system is running a special program which knows how
behave like an FTP client on one side, and like an FTP server
the other side. This program is what people call the "proxy".
program, being a transparent proxy, also has a very
relationship with the TCP/IP implementation of the proxy system
This relationship may be built in several ways, we will
only one such possible way
We will assume that the proxy program is listening to
requests on the standard FTP control port (21/tcp), although
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
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.
The client system needs to convert the server's name to an
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
performed which ranges between two extremes
a) the client system has this name in its hosts file, or
local DNS caching capability and successfully retrieves
name of the proxy system in its cache. No network
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
root of the DNS tree and back down the server's DNS branch
Eventually, a DNS server which is authoritative for
server system's domain is queried and returns the
address associated with "s.dmn2.com" (depending on
case, it may return this to the client system directly
to an intermediate name server). Ultimately, the
system obtains a valid IP address for s.dmn2.com
Chatel Informational [Page 21]
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 / +-----+ | 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
s.dmn2.com are highly likely to be located on the
side of the proxy system. This means that DNS
from the inside to the outside MUST be able to cross
proxy system. If the proxy system wishes to
"address hiding", it must make these DNS
(originating from the inside) appear to come from
proxy itself. This can be achieved by using a BIND-
DNS server (which has some proxy capabilities) or
simpler DNS proxy program. For full RFC compliance
the proxy system must be able to relay TCP-based
just like UDP-based queries, since some client
are rumored to ONLY use TCP for DNS queries
The proxy system must be able to detect and block
classes of attacks based on DNS which (if nothing else
may cause denial of service
a) attempts from the outside to return corrupt
entries to an internal DNS
b) attempts to return DNS bindings which have
relationship to the actual DNS query (some
servers are vulnerable to this). The attacker's
may be to prime the cache of internal DNS servers
Chatel Informational [Page 22]
RFC 1919 Classical versus Transparent IP Proxies March 1996
interesting entries, including entries for
DNS names that point to external IP addresses...
c) data-driven stuff similar in style to the "
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
"control" TCP port on the server (port 21). For this to work,
client system must have a valid route for the server's IP
THAT LEADS TO THE PROXY SYSTEM, and the proxy system must have
valid route for the client's IP address and the server's
address. All intermediate devices that behave like IP
must have valid routes for the client, the server, and usually
proxy. If these devices perform packet filtering, they must
allow the specific type of traffic required between C and S
this specific application
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 |
| | route to C | | route to
| | | |
| | C S C | |
+----+ <-- +----+ --> +----+ <-- +----+
| G1 |--------| Gx |--------| Gy |---------| Gn |
+----+ --> +----+ <-- +----+ --> +----+
S C
At the start of the FTP session, a TCP packet with a
address of C and a destination address of S travels to the
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 (
subsequent ones) for a destination address that is NOT one of
own addresses. Based on some criteria (a configuration file,
Chatel Informational [Page 23]
RFC 1919 Classical versus Transparent IP Proxies March 1996
example), it decides NOT to forward or drop the packet (which
the only two choices an RFC-standard TCP/IP implementation
have). The proxy system accepts the packet as if it was
to one of its own IP addresses
In our example, the incoming packet is a TCP packet.
standard TCP/IP stacks store both a LOCAL and REMOTE IP
field for each TCP connection, the transparent proxy may set
LOCAL IP address field to the IP address that the client wants
reach (s1.s2.s3.s4 in our example). The standard TCP/IP
probably needs to be modified to do this. UDP examples,
not connection-based, could be handled in similar ways
Once this is done, the actual FTP proxy application is
since an incoming connection to TCP port 21 has occurred. It
determine what is the final target destination instantly,
the LOCAL IP address field of the connection contains the
server's IP address. There is no need for the proxy
to ask the client what is the final target system
Since the FTP proxy application knows the IP address of the
system, it can choose to do two things
a) Setup a session to the final target system, the
frequent case
b) Decide (based on some internal configuration data) that
cannot reach the final target system directly, but must
through a "classical" proxy. This seems
feasible, although no real transparent proxy system
known to offer this capability. The actual value of
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
reverse lookup on the target IP address to obtain a target
name (possibly needed for access control). If this
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
attempts to establish a connection to the standard FTP "control
TCP port on the target server (port 21), using a
identical to a "classical" proxy. For this to work, the
system must have a valid route to the server's IP address, and
server system must have a valid route to at least one of
proxy's IP address. All intermediate devices that behave like
gateways must have valid routes to both the proxy and the server
If these devices perform packet filtering, they must ALL allow
specific type of traffic required between the proxy and S for
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 |
| | route to P2 | | route to
| | | |
| | P2 S P2 | |
+----+ <-- +----+ --> +----+ <-- +----+
| G1 |--------| Gx |--------| Gy |---------| Gn |
+----+ --> +----+ <-- +----+ --> +----+
S P2
The rest of the transparent proxy's operation is very similar
what would happen with a classical proxy
4.2 Characteristics of transparent proxy
Transparent proxy technology can be used to build the
component of a "firewall", in a way quite similar to the
classical proxy technology may be used. Several important
of the architecture must be different, however
4.2.1 IP addressing and routing
The transparent proxy system must be able to address all
and server systems to which it may provide service. It
also know valid IP routes to all these client and
systems
Server systems must be able to address the proxy system,
must know a valid IP route to the proxy system. If the
system has several IP addresses (and often, several
network interfaces), the server systems need only to be able
access ONE of the proxy system's IP addresses
Client systems MUST HAVE valid IP addressing and
information for systems that they reach through the proxy.
example, in the common case where a transparent proxy is
used to interconnect a private network and the Internet,
Chatel Informational [Page 26]
RFC 1919 Classical versus Transparent IP Proxies March 1996
private network will effectively need to use a default
that points to the transparent proxy system. This is a
need of transparent proxy configurations
Interconnecting two internetworks with multiple
proxies (for load sharing or fail-over) can be accomplished
using different techniques from what would be done
classical proxies
a) with multiple classical proxies to the same
network, clients can be configured to access
proxies manually, or DNS-based techniques, such
DNS load-balancing may be used to make
access a different proxy at different times
b) with multiple transparent proxies to the same
network, the internal network must be able to
dynamic routing towards the proxies (routing
may need to be supplied by the proxies themselves).
Client systems (depending on topology) may not
to see the route changes, but internal
routers probably do
It is clear that internetworks linked by a transparent
cannot be fully isolated from each other in an IP
and routing sense. The network on which client systems
located must have effective valid routing entries to the
internetwork; these routing entries must point to the proxy
The transparent proxy system (if running a vaguely
TCP/IP software stack) needs to have a single coherent view
IP addressing and routing. If a proxy system interconnects
IP networks and two systems use the same IP network/
number (one system on each internetwork), the proxy will
be able to address one of the systems. Even if the proxy
able to manage multiple conflicting IP universes (if,
example, one instance of a complete TCP/IP stack and its
structures is bound to each of the proxy network interfaces),
the client systems will still have a problem: Why should
send packets with this network number to the proxy since
network number exists also on the internal internetwork
Chaining transparent proxies does not seem at first glance
solve IP conflicts like it does for classical proxies
From a "security" fail-safe point of view, the
proxy has an undesirable characteristic: the network
protected must have valid routing entries to the
Chatel Informational [Page 27]
RFC 1919 Classical versus Transparent IP Proxies March 1996
network(s). If the proxy fails (starts behaving like a non
filtering IP router) or is physically bypassed, it is
that the internal network will be immediately able to reply
"attacker" packets. The attacker does not need to
routing tables or to spoof internal IP addresses
This is important for organizations that do not wish to
ALL their confidence and protection into a proxy system (
whatever reason).
4.2.2 IP address
Application "sessions" that go through a transparent proxy
actually made of two complete sessions
a) a session between the client and the address of
server, the session being "intercepted" by the
b) a session between the proxy and the
A device on the path sees either the client<->server traffic
the proxy<->server traffic, depending where it is located.
client<-"server" traffic is actually generated by
transparent proxy. The two sessions SHOULD NEVER pass
the same physical network, since in that case (due to
routing requirements) a total bypass of the proxy at the
routing level may easily occur without being detectable
Like classical proxies, transparent proxies accomplish a
of IP address hiding. Client IP addresses are hidden from
servers, since the servers see a session being initiated by
proxy. Server IP addresses are NOT hidden from the
however, so that the illusion of transparency may
maintained
This difference implies that internal (client-side)
statistics at the IP level will accurately reflect what
destinations are being accessed. This can be useful
analyzing traffic patterns
4.2.3 DNS
In transparent proxy configurations, client systems MUST
able to resolve server names belonging to remote networks.
is critical since the proxy will determine the target
from the destination IP address of the packets arriving
the client. Because of this, the "client" internetwork needs
have some form of DNS interconnection to the remote network.
internal client and name server IP addresses must be
Chatel Informational [Page 28]
RFC 1919 Classical versus Transparent IP Proxies March 1996
from the outside, these DNS queries must also be proxied
Of course, remote host name/address relationships may be
locally on the client systems, but it is well known that
an approach does not scale...
Because of this, it can be said that a transparent proxy
cannot offer DNS isolation. If two IP internetworks
completely separate DNS trees (each with their own DNS
servers), client software in one IP internetwork will not
a way of finding name/address relationships in the "other"
tree, and this information must be obtained in order to
the desired address to the transparent proxy
The classical proxy itself (if running standard DNS
software) will not be able alone to resolve DNS names in
environments, since it will need to point to one or the
of the two DNS "universes". Running multiple instances of
resolution software can allow the proxy to do this, however
Because of the requirement placed on some form of
communication through the proxy, it is critical for the
to be able to protect ITSELF, internal clients, and
name servers from data-driven attacks at the DNS level
4.2.4 Software
The big advantage of transparent proxies is that normal
software may access remote servers with no modifications and
changes to user procedures
The transparent proxy application itself may not need to
more complicated than a classical proxy application
However, the proxy TCP/IP software stack cannot be a fully
standard (well, today's standard at least) TCP/IP stack,
requires specific extensions
a) the ability to specify ranges of IP addresses
do not belong to the proxy itself, but for
"intercept" processing will occur: if packets
at the proxy with a destination IP address in
ranges, the IP stack will not forward or drop
packets; it will pass them up to application layers
b) This mechanism requires that applications may
both the IP address from which the packets come,
the address to which the packets were going.
Chatel Informational [Page 29]
RFC 1919 Classical versus Transparent IP Proxies March 1996
IP stacks should already have the fields
to store the info; it is a matter of updating
properly for these "intercepted" packets
c) In the case of "intercepted" TCP packets, the
stack must support establishing TCP
where the "local" IP address is not one of
proxy's IP address
Any TCP/IP software implementation should be modifiable
perform these tasks. If a standard API becomes widely
to drive these extensions, and if this API is
implemented, transparent proxies may become "portable
applications
Until this occurs, it must be assumed that implementors
chosen different ways of accomplishing these functions, so
today's transparent proxy applications cannot be
portable. It also remains to be seen how much work is needed
propagate these "extensions" to IPV6 software stacks
4.2.5 Impact of a transparent proxy on packet
The nature of a transparent proxy's functionality makes
difficult to deploy good packet filtering on the "inside" (
client-side) of the proxy. The proxy will "masquerade" as
the external systems. Because of this, internal packet
WILL TYPICALLY NEED TO ALLOW IP traffic between internal
external IP addresses
Depending on the actual security policy of the network, it
be possible to do filtering based on protocol type and/or
TCP bits (to filter based on connection setup direction),
filtering that blocks external IP addresses CANNOT be deployed
If the proxy starts behaving like an IP router, or
physically bypassed, the practical limitations imposed
internal packet filtering imply that a lot of direct
between the inside and outside network will be allowed to flow
Furthermore, as we have seen previously, the internal
will have valid routing entries for external network
that point to the proxy. If multiple proxies have
deployed, the internal network may even HAVE TO TRUST
updates generated by the proxy
In general, if an internal network wishes to communicate
an external network through a transparent proxy, it MUST
FUNDAMENTALLY DESIGNED TO COMMUNICATE DIRECTLY with
Chatel Informational [Page 30]
RFC 1919 Classical versus Transparent IP Proxies March 1996
external network. This is true at the IP addressing level,
the IP routing level, and at the DNS level. A proxy
failure in this type of environment is likely to result
immediate, total, and undetected accessibility of the
network by the external network
4.2.6 Interconnection of conflicting IP
Unlike classical proxies, transparent proxies do not
seem useful in solving IP addressing conflicts
If two internetworks use the same network number(s),
and routers in each internetwork will have valid routes
these network numbers. If these routes are changed to point
a transparent proxy, traffic that is meant to stay within
same internetwork would start to flow towards the proxy.
proxy will not be able to distinguish reliably between
between systems of the same internetwork, and traffic which
meant to cross the proxy
A possible solution to this problem is described in section 6
of this document, "Improving transparent proxies".
5. Comparison chart of classical and transparent
For those who do not like longish discussions of technical details
here is a one-page summary of the strengths/weaknesses/differences
classical and transparent proxies
-----------------------------------------------------------------
| Issue | Classical Proxy | Transparent Proxy |
|-------------------+---------------------+----------------------|
| IP addressing | systems/gateways on | systems/gateways on |
| | each network need | the "client" network |
| | to address the proxy| need to address the |
| | | remote networks |
| | | |
| IP routing | systems/gateways on | systems/gateways on |
| | each network need a | the "client" network |
| | valid routing entry | also need routing |
| | for the proxy | entries for remote |
| | | entries |
| | | |
| IP address hiding | systems on each side| systems on the |
| | of the proxy are | "client" side are |
| | hidden from each | hidden from the |
| | other | other sides |
