Proxy Servers vs IP Masquerade

[mcmanus at AppliedTheory.com (Patrick McManus)]

:: >... 
:: > a more interesting question in my mind is why would you want
:: > transparent servicing/redirection of any kind of protocol? I can only
:: > think of one answer: automatic client configuration. Frankly there are
:: > much better ways to do service discovery and I certainly hope that it
:: > becomes the norm for this class of problem.
:: 
:: I'm not sure I follow your argument.  IP masquerading (the Linux-ish term
:: for NAT, which is now appearing in a wide range of commercial products) is
:: obviously a kludge grafted on top of IP4 in ways the original designers
:: would never have imagined.

we're talking about two different (but related) things.

I'm talking about transparent caching devices that grab traffic that
isn't addressed to them.. products from cacheflow, and infolibria are
examples.

I think (and correct me if I'm wrong) you're talking about using NAT
(via chains/masquerade)  to connect a non-Internet block to the network
at large.

They are tied together by the fact that people often use
ipchains/masquerade on linux to hijack network traffic that's already
on routable blocks and send it to traditional caches (like
squid).. cisco does the same thing with it's 'redirector'.. there are
numerous other examples.

:: 
:: But the concept is sound:  why assign every IP-addressable device on
:: the planet its own externally-reachable "phone number" given the constraints
:: of routing table size and address length?
:: 

end-to-end as it's known is cortically important... NAT (which crushes
e2e) helps alleviate a couple things that you mention, but it
introduces a whole heck of a lot of problems. but this has little to
do with the 'transparent proxying' I was getting at.. indeed there are
times when NAT is a necessary evil but hopefully we can leave it all
behind with IPv6 which addresses both of your concerns nicely.

let me elaborate a little on some of the potential problems with NAT in
general as I see it:

IPSec: packet level security clearly cannot allow packet header
contents to be re-written.. NAT just breaks this entirely. Security
would have to be done NAT to NAT, not host to host and that's really
not sufficient for most people.

diverse routing: NAT has suddenly introduced state into the
network. All outbound connections must return via the same path in
order to have their address swapped back in. This removes any
possibility for a-symmetrically routing your site. 

bottlenecks: remember that NAT is stateful so it must keep a mapping
for every connection that is running through it. In the case of UDP
connections this mapping has to timeout (as there is no EO-Connection
marker).. lots of sessions from even medium sized networks can easily
overwhelm a NAT.. and you can't dynamically divide the traffic
probabilistically because it's stateful!

lack of accountability: translation of address space makes it
difficult to track down what host/stack is responsible for strange
traffic.. be it things that violate SLA's or just buggy stack
implementations, when 250 sources are all attributed to 1 IP, it's not
possible to know what to look at.

no unique address space: by removing any kind of unique identifier for
the end host, you've inhibited it's ability to effectively come up
with globally unique identifiers for application layer issues. Things
that generate  email and news message ID's tend to be able to
guarantee that a particular ID number has never been created on that
system before, and by concatenating it with an interface IP suddenly
make it globally unique.. if there are 10's of thousands of
192.168.1.1's out there, that doesn't work.

application level design: a number of services that don't support a
proxy concept at the application level quite rightly assume that the
IP of the connected client is the host initiating the
connection. Therefore they try and connect back to do 'application
level things'.. for FTP that's establishing a data channel, for irc
that's often checking userid via IDENTd.. NAT breaks all of these and
needs special stream inspection modules to deal with it.. that's
un-scalable both for large traffic flows and for protocol
evolution.. again state has been introduced into the network so that
progress and development of end user applications is no longer the
balliwick of programs on each end, it requires cooperation for admins
and ISPs.. if you've got a security need, that's fine, but otherwise
it's just creating needless steps in the chain.

But again, for the reasons you're referring to, NAT at this time is
somewhat of a necessary evil (though I think it's probably over-used),
indeed I use chains for my LAN on a cable modem but hardly a day goes
by that I don't swear at it for some reason. However the use of it for
performing *transparent* proxying, where *explicit* proxying is
available is where I have the biggest concern.

This is where systems pickup traffic not destined for themselves and
map the destination address to be a different system; basically
hijacking the connection. The new destination system is usually a
proxy cache of some kind used to conserve bandwidth and improve
latency, sometimes it's a different origin server for the purposes of
load balancing.. it's not for the purposes of connecting
networks.. The use of proxies for load balancing, bw conservation, and
improved response time are all laudable goals but you don't have to
hijack the traffic to do it. IPchains/masq on linux is often used to
do this.

In addition to the problems mentioned above, doing this with HTTP has
a few specific pitfalls.

I mentioned the problem of extensible methods and proxies. An
application that addressed it's request to a proxy and found that the
proxy did not understand the method (there's a special response for
this) could make a judgment as to how to perceive. Perhaps it's got
another smarter, though otherwise less desirable, proxy available to
it.. perhaps it can just address the request directly to the origin
server, bypassing the proxy for this single request. But if the
transparent cache has grabbed everything on port 80, the client has no
options left.. it has no way of contacting the origin server even if
they're both on publicly routable blocks with no firewall
restrictions. It's just plain stuck.


:: Patrick--how did service discovery come into the equation?  I think
:: I must've missed a point made earlier.

the service in question, at least in my scenario, is that of the
proxy. Just about the only reason transparent proxying is attractive
to folks is that it doesn't require client configuration.

-Patrick
-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).