IPP> Notifications

IPP> Notifications

Turner, Randy rturner at sharplabs.com
Thu Feb 5 17:16:18 EST 1998


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



More information about the Ipp mailing list