The proxy you are talking about is SOCKS-based...ok, I understand how
SOCKS works. That's pretty much all we had until real firewall products
came along, and yes SOCKS-based products might have a problem with UDP.
But I don't think the majority of enterprise firewall solutions are
based on SOCKS, because it is doesn't quite have the flexibility of real
firewall products. SOCKS application gateways require that all
applications be modified to speak SOCKS, and if not the applications,
then the runtime libraries or DLLS or whatever have to modified.
Products like Checkpoint Firewall-1 and other firewall products are much
more transparent with regards to their NAT (network address translation)
capabilities. In my opinion, SOCKS is more of a niche player in the
enterprise firewall world. But this is just my opinion.
I also don't think we are losing anything by defining a notification
method outside of HTTP; in fact, we could define a standards-track
document for IPP async notifications that would be immune to legacy or
other future protocol mapping techniques for IPP job submission. Like
Paul Moore mentioned in an earlier mail message, HTTP wasn't designed
for this type of functionality (async notifications) so I think a
separate out-of-band (to HTTP) method is in order.
Randy
-----Original Message-----
From: Carl Kugler [SMTP:kugler at us.ibm.com]
Sent: Thursday, February 05, 1998 12:49 PM
To: ipp at pwg.org
Subject: RE: IPP> Notifications
Randy-
By "proxy", I mean "proxy server", specifically
"application-level proxy
server" or "gateway": a server that receives requests intended
for another
server and that acts on the client's behalf (as the client's
proxy) to obtain
the requested service. These are high-end firewall devices that
operate at the
upper levels of the protocol stack (i.e., all the way up to the
application
layer), providing the highest level of protection available
today. The proxy
server changes the IP address of the client packets to
essentially hide the
internal client to the Internet, then it acts as a proxy agent
for the client
on the Internet. In some cases (e.g., SGI Guantlet), a proxy
server is required
for each protocol on a gateway. For example, one is required for
HTTP requests,
another for FTP requests, and so on. Circuit-level gateways
(e.g., SOCKS,
rfc1928) provide a controlled network connection between
internal and external
systems. A virtual "circuit" exists between the internal client
and the proxy
server. Internet requests go through this circuit to the proxy
server, and the
proxy server delivers those requests to the Internet after
changing the IP
address. External users only see the IP address of the proxy
server. Responses
are then received by the proxy server and sent back through the
circuit to the
client. While traffic is allowed through, external systems never
see the
internal systems. In general the only packets allowed back
through a proxy
server are those that return responses to requests from inside
the firewall.
I think the type of firewall you're discussing is the router
based packet
filtering type (screening router), which works in the lower
layers of the
network protocol stack. It would be interesting to know the
install base of
the various types of firewalls. I know here at IBM we use proxy
servers (now
mostly SOCKS gateways, formerly mostly application proxies).
If use a protocol other than HTTP as a transport for realtime
asynchronous
notification, won't we lose the advantages that we gained by
chosing HTTP in
the first place?
-Carl
ipp-owner at pwg.org on 02/05/98 10:44:30 AM
Please respond to ipp-owner at pwg.org @ internet
To: ipp at pwg.org @ internet
cc:
Subject: RE: IPP> Notifications
I'm not sure what "proxy" means in this context. I'm assuming
for the
purposes of realtime asynchronous notification that we would not
be
using HTTP as a transport, so any issues surrounding HTTP
proxies would
be moot. Are we talking about some other type of proxy?
In my experience, UDP wasn't the problem with NFS mounts over
the
internet. Rather, its just too easy to hack NFS UID-style
authentication. Especially with SUNOS systems that had the
annoying
habit of including a "nobody" user UID in the default
/etc/passwd file.
This "well-known" UID pair was used by hackers to mount attacks
on the
"/" root partition, retrieving a sites /etc/passwd file, and
then
locally running "crack" on their system until they had the root
password. This problem was exascerbated because administrators
were too
lazy configuring their "exports" file by including the "/"
partition,
and not restricting mounts to this partition to specific hosts
only.
Also, NFS these days uses TCP as well, for both NFSv2 and NFSv3,
at
least on Sun SunOS/Solaris systems.
Randy
-----Original Message-----
From: Carl Kugler [SMTP:kugler at us.ibm.com]
Sent: Thursday, February 05, 1998 8:11 AM
To: ipp at pwg.org
Subject: RE: IPP> Notifications
But... Proxies don't open up TCP or UDP pipes. Proxies pass
nothing through.
Everything gets pulled up to the application level and then
resent. Much more
secure that way.
Also, note that very few corporate firewalls are configured to
let NFS
through. That's partly because NFS is UDP-based and can't be
securely
controlled.
-Carl
ipp-owner at pwg.org on 02/04/98 08:17:53 PM
Please respond to ipp-owner at pwg.org @ internet
To: masinter at parc.xerox.com @ internet
cc: ipp at pwg.org @ internet
Subject: RE: IPP> Notifications
I am speaking about our specific installation of Checkpoint
Firewall-1,
from which Cisco and a number of other vendors have licensed
technology