Application proxy

To understand the application proxy, consider this scenario where you needed to deliver your neat little package of network data. With application-level proxies, the scenario is similar, but now you need to rely on someone else to deliver the package for you. Hence the term proxy illustrates this new scenario. The same rules apply as they do for packet filtering, except that you don’t get to deliver your package past the gate. Someone will do it for you, but that agent needs to look inside the package first to confirm its contents. If the agent has permission to deliver the contents of the package for you, he will.

Most commercial routers do not have proxy capabilities today, although I believe that proxy technology will be integrated with router code in the future. Until then, you need to rely on a standalone system that can support application-level proxy services.

Since an application proxy needs to communicate on behalf of the sender, it needs to understand the specific language or protocols associated with a particular application. Take as an example the widely used HTTP (Hypertext Transfer Protocol) proxy. If you are using a browser on your network, it is highly likely that your IS group has an HTTP proxy configured to allow you to access the Web via a central server. That single machine understands HTTP conversations and can speak on behalf of the requesting client. This is application level proxying.

Of course, security and encryption also come into play, since the proxy must be able to open the “package” to look at it or decode its contents. These are important issues obviously, but to do them justice would require another article.