RFC 1919
Classical versus Transparent IP Proxies
RFC 1919: Classical versus Transparent IP Proxies 🎀
Okay bestie, this one is by M. Chatel, a Consultant, and it was published as part of the Network Working Group in March 1996. It's Informational (so it's giving "here's some info," not "you have to do this"). It doesn't obsolete or update anything. The RFC number is 1919. 💅
Status of This Memo
This memo is here to give info to the Internet community 🌈 It does not specify an Internet standard of any kind, and you can share it as much as you want (distribution is unlimited).
Abstract
Lots of modern IP security systems (aka "firewalls," as they're called in the biz) use proxy technology to control who gets access 🔒 This document breaks down "classical" and "transparent" proxy techniques and tries to give you rules for figuring out when each proxy system can be used without causing problems ✨
Table of Contents
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
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 34
9. References . . . . . . . . . . . . . . . . . . . . . . . . 351. Background 🌸
More and more organizations are using IP security systems to get specific access control whenever traffic crosses a network security perimeter 🔒 These systems are usually set up at the boundary between two organizations (which might even be part of the same "official" entity), or between an organization's network and a huge public internetwork like the Internet.
Some people think IP firewalls are going to become commodity products 🛒 Others think IPv6 and its improved security features will gradually make firewalls look like stopgap solutions, and therefore irrelevant to the networking scene. Either way, it's currently important to look at what happens when you add (and remove) a firewall at a network boundary, and to check whether specific firewall technologies have different effects on typical small and large IP networks 🧐
Current firewall designs usually rely on packet filtering, proxy technology, or a combo of both. Packet filtering is a well documented technology (although it's hard to configure correctly in a security sense), and its strengths and weaknesses are reasonably understood 📚 Proxy technology, on the other hand, has been deployed a lot but studied very little 🙈 On top of that, lots of recent firewall products support a feature called "transparent proxying," which has gotten way more marketing attention than actual technical analysis from the networking community 💀
It must be remembered that the Internet's growth and success are strongly tied to its "open" nature 🌈 An Internet that had been segmented from the start with firewalls, packet filters, and proxies might not have become what it is today. This kind of discussion is, however, outside the scope of this document 🙅♀️ This document just tries to explain what network proxies are, and what the differences, strengths, and weaknesses are between "classical" and "transparent" network proxies. In this document, a "classical" proxy is the older (some would say old-fashioned) type of the two 🎀
Also note that in this document, the word "connection" is used for an application session that uses TCP, while the word "session" refers to an application dialog that may use UDP or TCP ✨
2. Direct communication (without a proxy) 🦋
In the "normal" Internet world, systems don't use proxies. They just use normal TCP/IP to talk to each other 💁♀️ If you're not familiar with this, it's important to take a quick look at the operations involved first, so you can really understand what a proxy is actually doing.
2.1. Direct connection example ✨
Let's take a familiar network session and break down what's happening under the hood 👀 We'll look at what happens when a user on a client system "c.dmn1.com" sets up an FTP connection to the server system "s.dmn2.com". The client system's IP address is c1.c2.c3.c4, and 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 FTP client program on the client system "c.dmn1.com" and says the target is "s.dmn2.com". On command-line systems, the user usually types:
ftp s.dmn2.comThe client system has to turn the server's name into an IP address (if the user already gave the server by address, this step isn't needed 🙌).
Turning the server name into an IP address can take anywhere from zero work to a whole journey, and it sits between two extremes 🗺️
a) the client system has this name in its hosts file, or has local DNS caching and successfully pulls the name of the server system out of its cache. No network activity is performed to convert the name to an IP address.
b) the client system, working together with DNS name servers, generates DNS queries that eventually travel close to the root of the DNS tree and then back down the server's DNS branch 🌳 Eventually, a DNS server that is authoritative for the server system's domain gets queried and returns the IP address associated with "s.dmn2.com" (depending on the case, it may send this back to the client system directly or to an intermediate name server). In the end, the client system gets 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 server's IP address, it tries to set up 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 to the server's IP address, and the server system must have a valid route to the client's IP address. All intermediate devices that act like IP gateways must have valid routes for both the client and the server. If these devices do packet filtering, they must ALL allow the specific type of traffic required between C and S for this 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 | A
| | route to C | | route to S
| | | |
| | C S C | |
+----+ <-- +----+ --> +----+ <-- +----+
| G1 |--------| Gx |--------| Gy |---------| Gn |
+----+ --> +----+ <-- +----+ --> +----+
S C SThe actual application work for the FTP session between the client and server happens through a two-way flow of TCP packets between the client's and server's IP addresses 🔁
The FTP protocol uses a slightly complex protocol and TCP connection model, but luckily it isn't important to the current discussion. That lets us shorten this document a bit...
2.2. Requirements of direct communication 💖
Based on everything we just covered, a direct session between a client and server only works out if all of the following are true 💅
a) If the client uses the NAME of the server to reference it, the client must either have a hardcoded name-to-address binding for the server, or it must be able to resolve the server name (typically using DNS). With DNS, this means the client and server must be part of the same 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 routes towards the client and server ("IP gateway" is the RFC standard terminology; people often say "IP router" in computer rooms 🖥️).
c) If there are devices on the path between the client and server that do packet filtering, all of these devices must permit the forwarding of packets between the IP address of the client and the IP address of the server, at least for packets that fit the protocol model of the FTP application (TCP ports used, etc.) 🛡️
3. Classical application proxies 👑
The classical application proxy is a special program that knows one (or more) specific application protocols 💅 Most application protocols aren't symmetric, so one end is the "client" and the other end is the "server" 🫶
A classical application proxy implements both the "client" and "server" parts of an application protocol 🎀 In practice, though, it only needs enough of each side to do the following:
a) accept client sessions and appear to them as a server ✨
b) receive from a client the name or address of the final target server (this needs to be passed over the "client-proxy" session in a way that is application-specific) 💌
c) set up a session to the final server and appear to be a client from the server's point of view 🦋
d) relay requests, responses, and data between the client and server 🔁
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 is to run the checks and access controls that typical client and server software doesn't support or implement 🔒
Here's the lowkey big deal: classical proxies offer a ton of hidden benefits for security-minded network designers 🤫 The tradeoff is that you have to deploy client software with proxy capabilities, or educate users on how to use the proxy 📚
Client software issues are way easier to handle now, since so many popular client apps (for Web, FTP, etc.) offer proxy support 🌈 New protocol designers are also more likely to plan for proxy capability from the start, so their protocols can get through the many big corporate firewalls that are based at least partly on classical proxy technology 🏢✨
3.1 Classical proxy session example
Okay, let's run our little FTP session analysis again, but this time the FTP session goes through a "classical" application proxy system 🧚 As is often the case (though not required), we'll assume the proxy system has two IP addresses, two network interfaces, and two DNS names 🍓
The proxy system runs a special program that acts like an FTP client on one side and an FTP server on the other 💖 That program is what people call the "proxy" ✨ We'll assume the proxy program listens for incoming requests on the standard FTP control port (21/tcp), though that isn't 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) | \ /
+---------------+ +----------+The user starts 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.comThe client system needs to convert the proxy's name to an IP address (if the user specified the proxy by address directly, this step isn't needed) 🔍
Converting the proxy name to an IP address can take work that ranges between two extremes 😭
a) the client system has this name in its hosts file, or has local DNS caching and successfully retrieves the name of the proxy system from its cache. No network activity is performed to convert the name to an IP address 🥹
b) the client system, together with DNS name servers, generates 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 that is authoritative for the proxy system's domain gets 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). In the end, the client system gets a valid IP address for proxy1.dmn3.com 🌐✨
+---------------+ +--------+
| | / 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 proxy's IP address, it tries to connect 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 🛣️ Every intermediate device that acts like an IP gateway MUST have valid routes to both the client and the proxy 🧭 If these devices do packet filtering, they MUST ALL allow the specific type of traffic needed between C and P1 for this application (FTP) 🙈
Finally, the proxy system has to accept this incoming connection based on the client's IP address (the purpose of the proxy is generally 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 P1The actual application work for the FTP session between the client and proxy happens over 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 up, the final target server name has to get to the proxy 🥺 With a "classical" application proxy, a way MUST be defined for the proxy to figure out the final target system ✨ There are three ways to do this:
a) The client system gives the name or address of the final target system to the proxy using a method that works with the specific application protocol being used (in our example, FTP). This is generally seen as the main problem with classical proxies, because for every proxied application, a method has to be defined for passing the final target's name or address 😩 That method has to work with every variant of client app 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 most popular method for passing the final server name to the proxy goes like this 💅
When the proxy prompts the FTP client for a username, the client sends a string in this form:
target_username@target_system_name
or
target_username@target_ip_addressThe proxy then knows what the final target system is 🎯 The target_username (and the password the client supplied) gets forwarded "as is" by the proxy to the final target system 💖
A well-known example of an FTP proxy that works this way is the "ftp-gw" program, 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 🏰
b) If there is only one possible final destination, the proxy may be configured to know that destination in advance 🌟 Since the proxy knows the client's IP address when it has to make this decision, it can (if required) pick a different destination based on the client's IP address 🦋
c) The client software may also have capabilities that give the user the illusion of a direct session 🪄 (The user just names the final target system, and the client software handles reaching 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 with modified client software and proxy software 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) Set up a session to the final target system, which is the more frequent case 💜
okay so we're picking up mid-FTP example, and it's giving detective work 🕵️♀️✨
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 that are already assigned elsewhere 🙈. Sessions between systems that have the same IP network number but 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 👀:
+-----------------+
| 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 S for this specific application 🛡️.
+-----------------+
| 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 SThe 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.
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 SHOULD be BLOCKED). The original says "shout" here, which is clearly a typo, so we know what they meant 😭. If the proxy suddenly starts to behave like an IP router, only one-way attacks become possible.
🚨 Heads up, this is the part that matters for security. If the proxy suddenly starts routing, the attacker only gets one-way attacks, which is way better than the alternative.
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 🥀.
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 does 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 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 🔐💜.
Okay so normal client software can totally use a classical proxy 💅, as long as the user is willing (or able!) to do the extra steps needed to tell the proxy who the final server is, whatever those steps happen to be 🫶. Or you can use modified (or newer) client software that knows how to negotiate with the proxy transparently ✨.
3.2.5 Impact of a classical proxy on packet filtering 🛡️
If you need packet filtering around a classical proxy, the rules tend to get simpler 🎀. The only traffic that's needed and allowed will start or end on the proxy (in an IP sense), so there's less to juggle 💖.
But if the proxy starts acting like an IP router, or if people physically bypass it, things get messy 😭. If filtering rules like these get deployed across an IP internetwork in general, they'll tend to block any direct traffic between the "internal" internetwork and the "external" internetworks that are supposed to be reachable only through the application proxy 🙈.
3.2.6 Interconnection of conflicting IP networks 🧩
By chaining classical proxies, you can actually interconnect IP networks that are in a really high level of conflict 🔥. In practice, this kind of setup handles IP addressing conflicts way better than DNS conflicts 💜. DNS conflicts are currently less of a problem though, because the DNS "address space" is almost infinitely large 🌌 (has anybody calculated how big it is, based on the RFC-standard maximum host name length? 🤔)
Even though RFC 1597 was never more than an informational RFC, lots of organizations have been quietly following its suggestions 🤫, mostly because there wasn't an easier solution. So say 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 its network number. This is not as hard as people think if it's properly planned, but it still means some work 🛠️.
- Second possibility: they merge the two numbers by renumbering partially on each side to remove the conflicts. This is actually harder to do, but it has the political advantage that both sides have to do some work ⚖️.
- Third possibility: they communicate through chained classical proxies 🦋:
+--------+ +--------+ +--------+ +--------+
/ Org. 1 \ | Proxy | | Proxy | / Org. 2 \
+ dmn1.com +---+ system +---+ system +---+ dmn2.com +
\ net 10 / | 1 | | 2 | \ net 10 /
+--------+ +--------+ +--------+ +--------+Both proxy 1 and proxy 2 are standard systems running normal TCP/IP software stacks 💻. Their configuration isn't typical though, and that's where the magic is ✨:
- a) The link between proxy 1 and proxy 2 may use any IP network number that is not used (or not needed) on either side. Nothing on Org.1 and Org.2's networks needs an IP route to this network.
- b) Proxy 1 has an IP route for network 10 that points to Organization 1's network, and does DNS resolution (if required) using dmn1.com's name servers.
- c) Proxy 2 has an IP route for network 10 that points to Organization 2's network, and does DNS resolution (if required) using dmn2.com's name servers.
- d) Proxy 1 and proxy 2 only need a host IP route to each other for communication.
- e) For this to be convenient, the classical proxy applications must support automatic selection of a destination based on the client IP address 🎯.
- f) On proxy system 1, the proxy software treats incoming sessions from proxy system 2 in the normal way: the "client" (proxy system 2) will be prompted in an application-specific way for the final destination. However, incoming sessions from Org.1 addresses are immediately and automatically forwarded to proxy system 2.
Proxy system 2 is configured similarly. That means connections coming from proxy 1 are prompted for a target server name, and connections from Org.2 addresses are immediately and automatically forwarded to proxy 1 💖.
From a user's point of view, a chained proxy system doesn't feel very different from a single classical application proxy 🥰:
- a) A user on a client system with address
10.1.2.3on Org.1's network wants to do an anonymous FTP toserver.dmn2.com. - b) The user starts an FTP session towards proxy 1. Proxy 1 sees an incoming connection from an address in network 10, so it immediately relays the connection to proxy 2.
- c) Proxy 2 sees a connection coming from proxy 1, so it prompts the client. The user sees the username prompt and types (assuming FTP proxies that behave like TIS's ftp-gw):
anonymous@server.dmn2.comThis will be resolved IN THE CONTEXT OF Org. 2'S NETWORK 👀. The user can then finish the dialog and use the FTP connection 🎉.
- d) Note that this setup works even if the client and server have the EXACT SAME IP ADDRESS (
10.1.2.3in our example) 🤯.
If the proxy applications support selecting another proxy based on the destination the client supplies, and if DNS domains are unique, you can link more than two conflicting IP networks this way! 🌈 Here's an example configuration:
- a) Four IP networks that all use network 10 are linked by four proxy systems. The four proxy systems share a common, private IP network number and physical link (LAN or WAN).
- b) A user on organization 1's network wants to access a server on network 3. The user connects to its local proxy (proxy 1) and supplies that target system name.
- c) Proxy 1 determines, based on a configuration rule, that the target system name is reachable by using proxy 3. So it connects to proxy 3 and passes along the target system name.
- d) Proxy 3 determines that the target system name is local (to itself) and connects to it directly.
Security Implications of chained proxies 🚨
Obviously, when these "chained" configurations are built, access control rules and logging based on a final-client/final-server combination are hard to enforce. The first proxy in the chain only sees a final-client/proxy relationship, and the last proxy in the chain only sees a proxy/final-server relationship. 💀
Doing better than this requires the proxies to be capable of passing the "original-client" and "final-destination" information back and forth along the proxy chain for access control and/or logging purposes. This requires the proxies to trust each other, and requires the network path to be trusted, because forging this information becomes an excellent attack 😈.
Even if these problems could be solved reliably, the original goal of proxy chains was to solve an IP conflict and possibly a DNS conflict. The "original-client" and "final-destination" values may not mean the same thing everywhere in the overall setup 🌀. Tagging the information with a "universe-name" may help, assuming it's possible to define unique universe names in the first place. Obviously this topic needs more study 📚.
4. Transparent application proxies ✨
The most visible problem with classical application proxies is that they need proxy-capable client programs and/or user education, so users know how to use them 😩.
When somebody thought of modifying proxies so that normal user procedures and normal client applications could still take advantage of them, the transparent proxy was born 🦋.
A transparent application proxy is often described as a system that looks like a packet filter to clients, and like a classical proxy to servers 👀. Apart from this important concept, transparent and classical proxies can do similar access control checks, and they can offer an equivalent level of security, robustness, and performance, at least as far as the proxy itself is concerned 💅.
The following information will make it clear why small organizations tend to prefer transparent proxy technology 🎀. These are the ones that want to use proxy technology for protection, want to rely entirely on one proxy system for network perimeter security, want minimal (or zero) impact on user procedures, and don't want to bother with proxy-capable clients 💖.
Organizations with one or more of the following characteristics may prefer deploying classical proxy technology 🧐:
- a) own a substantial internal IP router network, and wish to avoid adding "external" routes on the network
- b) wish to deploy "defence in depth", such as internal firewalls and packet filtering on the internal network
- c) wish to keep their DNS environment fully isolated from the "other side" of their proxy system, or fear that their internal DNS servers may be vulnerable to data-driven attacks
- d) use some IP networks that are in conflict with the "other side" of their proxy system
- e) wish to use proxy applications that are easily portable to different operating system types and/or versions
- f) wish to deploy multiple proxy systems interconnecting them to the SAME remote network without introducing dynamic routing for external routes on the internal network
4.1 Transparent proxy connection example 🎬
Let's go through an FTP session again, this time through a "transparent" proxy 🧚. We assume the proxy system has two IP addresses, two network interfaces, and two DNS names 💜.
The proxy system is running a special program that 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". Being a transparent proxy, it also has a very special relationship with the TCP/IP implementation of the proxy system 🔥. This relationship can be built in several ways, and we'll describe only one possible way 🌸.
We'll assume the proxy program is listening for incoming requests on the standard FTP control port (21/tcp), although this isn't always the case in practice 🍓.
The FTP example picks up right where the transparent proxy starts doing its thing. ✨
+---------------+ +----------+
| | / 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) | \ /
+---------------+ +----------+So the user starts an FTP client on the client system "c.dmn1.com" and types in "s.dmn2.com" like it's directly reachable 💖. On command-line systems, it usually looks like this:
ftp s.dmn2.comThe client system then needs to turn that server name into an IP address 🔍. (If the user already typed in an address, this step is skipped, obviously. 🙄)
Turning the name into an IP address can take anywhere from zero effort to a whole journey, and it sits between two extremes:
- a) The client has the name in its hosts file, or it has local DNS caching and already has the name in its cache. No network activity happens to convert the name to an IP address. Easy mode 🧚
- b) The client, working together with DNS name servers, sends DNS queries that travel up close to the root of the DNS tree and then back down the server's DNS branch 🌳. Eventually a DNS server that's authoritative for the server system's domain gets asked and returns the IP address for "s.dmn2.com". (Depending on the setup, that answer might go straight to the client or to an intermediate name server 📬.) In the end, the client gets a valid IP address for s.dmn2.com 🎀.
+---------------+ +--------+
| | / 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 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. 👀
Also, the proxy system has to be able to detect and block a few classes of DNS-based attacks, because (if nothing else) they can 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 that 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 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 knows the server's IP address, it tries to set up 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. Every intermediate device that acts like an IP gateway must have valid routes for the client, the server, and usually the proxy. If these devices do 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 SAt 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 🚗.
And this is where the transparent proxy shows its magic ✨🪄:
The proxy's TCP/IP software stack sees the incoming packets (and the ones that follow) for a destination address that is NOT one of its own addresses. Based on some criteria (a configuration file, for example), it decides NOT to forward or drop the packet (which are the only two choices a standard RFC TCP/IP implementation would have). Instead, 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. Standard TCP/IP stacks store both a LOCAL and REMOTE IP address field for each TCP connection, so the transparent proxy can set the LOCAL IP address field to the IP address 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, even though they aren't connection-based, could be handled in similar ways 💅.
Once that's done, the actual FTP proxy application gets invoked, since an incoming connection to TCP port 21 has happened 🎉. It knows the final target destination right away, because the LOCAL IP address field of the connection holds the target server's IP address. There's no need for the proxy application to ask the client where it's really trying to go 🙅♀️.
Since the FTP proxy application knows the target system's IP address, it can choose between two things:
- a) Set up a session to the final target system. This is the more frequent case 💖.
- b) Decide (based on some internal configuration data) that it cannot reach the final target system directly, and that it 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 already has that system's IP address. It may choose to do a reverse lookup on the target IP address to get a target system name (which might be needed for access control). If this process involves DNS resolution, something like the following will happen 🔁:
+-----------------+
| 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 that's done, and if the connection is allowed, the proxy tries to connect to the standard FTP "control" TCP port on the target server (port 21) 📞. It does this the same way a "classical" proxy would. 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 addresses. Every intermediate device that acts like an IP gateway must have valid routes to both the proxy and the server. If these devices do packet filtering, they must ALL allow the specific type of traffic required between the proxy and S for this specific application 🫶.
+-----------------+
| 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 SThe rest of the transparent proxy's operation is very similar to what would happen with a classical proxy 💅 so if you already get classical proxies, you're honestly already halfway there bestie 🦋
4.2. Characteristics of transparent proxy configurations 🎀
Okay so transparent proxy tech can be used to build the key component of a "firewall" 🔥, kind of the same way classical proxy tech can be used. BUT several important details of the architecture have to be different, no cap 😭
4.2.1. IP addressing and routing requirements 🗺️
The transparent proxy system must be able to address all client and server systems it might provide service to 💖 It must also know valid IP routes to all of 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 only need 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 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, so it's a whole vibe 👑
Interconnecting two internetworks with multiple transparent proxies (for load sharing or fail-over) can be done with different techniques than what you'd use 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). Client systems (depending on topology) may not need to see the route changes, but internal backbone routers probably do 🧚
It is clear that internetworks linked by a transparent proxy cannot be fully isolated from each other in an IP addressing and routing sense 💀 The network on which client systems are located must have effective valid routing entries to the remote internetwork, and these routing entries must point to the proxy 🌈
The transparent proxy system (if running a vaguely standard TCP/IP software stack) needs to have a single coherent view of IP addressing and routing 🎀 If a proxy system interconnects two IP networks and two systems use the same IP network/subnetwork number (one system on each internetwork), the proxy will only be able to address one of the systems 😭 Even if the proxy is able to manage multiple conflicting IP universes (for example, if one instance of a complete TCP/IP stack and its data structures is bound to each of the proxy network interfaces), the client systems will still have a problem: why should they send packets with this network number to the proxy, since this network number exists also on the internal internetwork? 🤔
Chaining transparent proxies does not seem, at first glance, to solve IP conflicts the way it does for classical proxies 🙃
From a "security" fail-safe point of view, the transparent proxy has an undesirable characteristic: the network being protected must have valid routing entries to the remote network(s). If the proxy fails (starts behaving like a non-filtering IP router) or is physically bypassed, it is likely that the internal network will be immediately able to reply to "attacker" packets. The attacker does not need to modify routing tables or to spoof internal IP addresses 🚨
This is important for organizations that do not wish to place ALL their confidence and protection into a proxy system (for whatever reason) 🔐
4.2.2. IP address hiding 🫣
Application "sessions" that go through a transparent proxy are actually made of two complete sessions 🧩
a) A session between the client and the address of the server, the session being "intercepted" by the proxy 🦋
b) A session between the proxy and the server 🦋
A device on the path sees either the client<->server traffic or the proxy<->server traffic, depending on where it is located. The client<-"server" traffic is actually generated by the transparent proxy 🪄 The two sessions SHOULD NEVER pass through the same physical network, since in that case (due to the routing requirements) a total bypass of the proxy at the IP routing level may easily occur without being detectable 💅
Like classical proxies, transparent proxies accomplish a form of IP address hiding ✨ Client IP addresses are hidden from the servers, since the servers see a session being initiated by the proxy. Server IP addresses are NOT hidden from the clients, however, so that the illusion of transparency may be maintained 🎭
This difference means that internal (client-side) network statistics at the IP level will accurately reflect what outside destinations are being accessed. This can be useful for analyzing traffic patterns 📊
4.2.3. DNS requirements 📇
In transparent proxy configurations, client systems MUST be able to resolve server names belonging to remote networks 🫶 This is critical, since the proxy will determine the target server from the destination IP address of the packets arriving from the client. Because of this, the "client" internetwork needs some form of DNS interconnection to the remote network. If internal client and name server IP addresses must be hidden from the outside, these DNS queries must also be proxied 🙈
Of course, remote host name/address relationships may be stored locally on the client systems, but it is well known that such an approach does not scale... 😵💫
Because of this, it can be said that a transparent proxy system cannot 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 will not have a way of finding name/address relationships in the "other" DNS tree, and this information must be obtained in order to pass the desired address to the transparent proxy 🗝️
The classical proxy itself (if running standard DNS resolution software) will not be able to resolve DNS names in both environments on its own, since it will need to point to one or the other of the two DNS "universes". Running multiple instances of DNS resolution software can allow the proxy to do this, however 🧠
Because of the requirement placed on some form of DNS communication through the proxy, it is critical for the proxy to be able to protect ITSELF, internal clients, and internal name servers from data-driven attacks at the DNS level 🛡️
4.2.4. Software requirements 🛠️
The big advantage of transparent proxies is that normal client software may access remote servers with no modifications and no changes to user procedures 🥰
The transparent proxy application itself may not need to be 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, and it requires specific extensions 😤
a) The ability to specify ranges of IP addresses that do not belong to the proxy itself, but for which "intercept" processing will occur. If packets arrive at the proxy with a destination IP address in those ranges, the IP stack will not forward or drop the packets; it will pass them up to application layers 🎀
b) This mechanism requires that applications may obtain both the IP address from which the packets come, and the address to which the packets were going. Typical IP stacks should already have the fields available to store the info; it is a matter of updating them properly for these "intercepted" packets 📝
c) In the case of "intercepted" TCP packets, the TCP stack must support establishing TCP connections where the "local" IP address is not one of the proxy's IP addresses 🌈
Any TCP/IP software implementation should be modifiable to perform these tasks 🔧 If a standard API becomes widely available to drive these extensions, and if this API is generally implemented, transparent proxies may become "portable" applications 🥹
Until this occurs, it must be assumed that implementors have chosen different ways of accomplishing these functions, so today's transparent proxy applications cannot be fully portable 🙃 It also remains to be seen how much work is needed to propagate these "extensions" to IPV6 software stacks 👀
4.2.5. Impact of a transparent proxy on packet filtering 🚧
The nature of a transparent proxy's functionality makes it difficult to deploy good packet filtering on the "inside" (or client-side) of the proxy 😩 The proxy will "masquerade" as all the external systems. Because of this, internal packet filters WILL TYPICALLY NEED TO ALLOW IP traffic between internal and external IP addresses 🫠
Depending on the actual security policy of the network, it may be possible to do filtering based on protocol type and/or on TCP bits (to filter based on connection setup direction), but filtering that blocks external IP addresses CANNOT be deployed 💅💀
I'm literally obsessed with this part 🧚✨ okay so if the proxy starts acting like an IP router, or somebody just physically bypasses it 💀, the practical limits on internal packet filtering mean a LOT of direct traffic between inside and outside is gonna be allowed to flow 🌊. And remember from earlier, the internal network will have valid routing entries for external network numbers that point at the proxy. If you've got multiple proxies, the internal network might even HAVE TO TRUST routing updates generated by the proxy 🫠
In general, if an internal network wants to talk to an external network through a transparent proxy, it MUST BE FUNDAMENTALLY DESIGNED TO COMMUNICATE DIRECTLY with that external network 🎀 This is true at the IP addressing level, at the IP routing level, and at the DNS level. A proxy security failure in this kind of setup is likely to result in immediate, total, and undetected accessibility of the internal network by the external network 😱 no thoughts, just vibes of total chaos
4.2.6 Interconnection of conflicting IP networks 🦋
Unlike classical proxies, transparent proxies don't really seem useful for solving IP addressing conflicts 🙅♀️
If two internetworks use the same network number(s), systems and routers in each internetwork will have valid routes to these network numbers. If those routes get changed to point at a transparent proxy, traffic that's meant to stay inside the same internetwork would start flowing towards the proxy. The proxy won't be able to reliably tell apart traffic between systems in the same internetwork and traffic that's actually 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 proxies 📊
For those who don't like longish discussions of technical details, here's a one-page summary of the strengths, weaknesses, and differences between 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 |
| | | |
| DNS | full isolation | resolution of outside|
| | possible | names by inside |
| | | systems is required |
| | | |
| Proxy software | runs on standard | requires special |
| requirements | TCP/IP stack; | TCP/IP stack; |
| | can be portable | not 100% portable |
| | | |
| Client software | requires proxy- | nothing more than for|
| requirements | capable software | a direct connection |
| | or user education | |
| | | |
| User requirements | must use proxy- | nothing more than for|
| | capable software or | a direct connection |
| | know how to use the | |
| | proxy | |
| | | |
| Packet filtering | can filter out | cannot filter out |
| | "external" addresses| "external" addresses |
| | | |
| IP address | can be done with | no obvious way to |
| conflict | chained proxies that| get this to work |
| resolution | support auto-connect| |
----------------------------------------------------------------6. Improving transparent proxies 🔮
The main issues with transparent proxies seem to revolve around the need to force "client" systems to directly access external addresses. To some people, this makes a transparent proxy look way too much like a complicated packet filter 🙈 Can this problem be solved?
The first possibility that comes to mind is to use the flexibility of the DNS protocol to build some new tricks 🧠 If we restrict the "internal" clients so that they MUST ALWAYS use DNS to resolve external host names AND THAT THEY MUST NEVER store permanent copies of external host addresses, the following technique would become theoretically possible (this is a very painful restriction, by the way 😭):
a) arrange for all internal queries for external DNS names to go to the transparent proxy system (this can be done in a number of ways).
b) arrange for a routing entry to exist for a class A network number that is not used on the internal network. This IMPLIES that the internal network may not be part of the Internet. This routing entry will point to the transparent proxy system. For the purpose of our discussion, this special network number will be X.0.0.0.
c) when an internal system generates a query for an external address, the query (if no answer is cached on the internal network) will reach the proxy system. Assuming the query is to obtain the IP address corresponding to a domain name, the proxy will go through the following algorithm:
- try to find a valid binding for this external domain name in its local cache
- if not found, it will ITSELF launch an external DNS query for the domain name. When (and if) it receives a valid reply, it creates a local cache entry containing:
Time To Live of the reply
Expiry Time of the cache entry (based on the current time)
External domain name
External IP address
Dynamically allocated IP address of the form X.x1.x2.x3.and returns to the client the dynamically allocated IP address in the range X.0.0.0, NOT THE REAL ONE.
- the client may (or may not) store the IP address returned in its cache, and will then attempt to connect to the dynamically allocated IP address. This traffic will arrive at the proxy because of the routing setup.
- the transparent proxy intercepts the traffic and can identify the actual desired target it should connect to based on the dynamically allocated IP address supplied by the client.
Such an approach, if workable, could improve many characteristics of transparent proxies and may even make transparent proxies capable of handling IP network number conflicts ✨
However, the algorithm above leaves many difficult questions unsolved 🥺 Here is a list (by no means exhaustive) of these questions:
a) What is the percentage of client DNS resolver and DNS server implementations that conform to the RFC specifications in their handling of the Time-To-Live field?
b) How should the proxy handle other types of DNS queries for external domain names (inverse queries, queries for other resource record types)?
c) A client program may perform a DNS query once for an external name and then use the response for a long time (a large file transfer, or a permanent management session, for example). Should the proxy update the Expiry Time of cache entries based on the passing IP traffic, and if so, using what algorithm?
d) What new types of attacks would such a system introduce or make possible?
e) What data structures and resources (memory, disk) would be needed for an efficient implementation if the proxy must sustain a high rate of DNS queries for external names, and where a large number of different external names are referenced? The class A network number is used basically to reference cache entries. Would a 24-bit address space be sufficient for practical use?
f) What happens with the cache (and the functionality) if the proxy crashes or reboots?
Such a system would probably exhibit two types of intermittent failures 🫣
a) a client system is still using the result of an external name query (some X.x1.x2.x3 address dynamically allocated by the proxy), but this binding no longer exists in the proxy's cache. The client attempts a connection to this address, which fails.
b) a client's name cache contains a binding for X.x1.x2.x3, but the proxy has already reused this address for a different external host name. The client attempts a connection to this address, sees no obvious errors, but reaches a different system from the expected one.
If somebody has ever implemented such a scheme, information and live experience in deploying it would be super useful to the IP networking community 🙌
7. Security Considerations 🔐
Most of this document is concerned with the security implications of classical and transparent proxy technology 👀
8. Acknowledgements 🫶
I could not have written this document without the support of Digital Equipment Corporation, for whom I work as a consultant 💜
9. References 📚
[1] Cheswick, W., Bellovin, S., "Firewalls and Internet Security: Repelling the Wily Hacker", Addison-Wesley, 1994.
[2] Chapman, B., Zwicky, E., "Building Internet Firewalls", O'Reilly and Associates, Inc., September 1995.
[3] Comer, D., "Internetworking with TCP/IP volume 1: Principles, Protocols, and Architecture", Prentice-Hall, 1991.
[4] Comer, D., Stevens, D., "Internetworking with TCP/IP volume 2: "Design, Implementation, and Internals", Prentice-Hall, 1991.
[5] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, USC/Information Sciences Institute, October 1985.
[6] Huitema, C., "An experiment in DNS Based IP Routing", RFC 1383, INRIA, December 1992.
[7] Rekhter Y., Moskowitz B., Karrenberg D., de Groot, G., "Address Allocation for Private Internets", RFC 1597, IBM Corp., Chrysler Corp, RIPE NCC, March 1994.
[8] The TIS firewall toolkit's documentation, available on Trusted Information System's anonymous FTP site, ftp.tis.com.
[9] Many discussions in the last 18 months on the firewalls-digest mailing list maintained by Great Circle Associates. The archives of the list are maintained at ftp.greatcircle.com.
Author's Address 💅
Okay bestie, this is where Marc tells you how to reach him 🫶 He's based in Annecy-le-Vieux, France 🇫🇷🧚
Marc Chatel
9, avenue Jean Monnet
74940 ANNECY-LE-VIEUX
FRANCEHis email is mchatel@pax.eunet.ch 💌 He also had an address at Digital Equipment, which was Marc.Chatel@aeo.mts.dec.com 🍓 iykyk that the old DEC addresses are all very 90s internet vibes 🦋
📦 where this page comes from
- ietf: rfc1919 1996-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms