RE: IPP> SEC - How could IPP work over firewalls?

[Josh Cohen <[e-mail]>]

I disagree, there is nothing different in the products
'inbound' or 'outbound' proxy.  The only thing that
makes it inbound or outbound is the access policy set
by the administrator.

Typically, firewalls/proxies are liberal with outbound
and strict with inbound.

HTTP proxies have no problem allowing inbound access.
Other firewalls/proxies are common for SMTP mail,
NNTP news feeds, etc..


> -----Original Message-----
> From: Manros, Carl-Uno B [mailto:[e-mail]]
> Sent: Friday, July 31, 1998 9:17 AM
> To: [e-mail]
> Subject: RE: IPP> SEC - How could IPP work over firewalls?
> 
> 
> Paul,
> 
> You are right. This is a new piece of software that you 
> cannot get from
> stock.
> This is why I stated: "This software will need to be tailored and
> written to handle IPP". 
> 
> Carl-Uno
> 
> > -----Original Message-----
> > From: Paul Moore [mailto:[e-mail]]
> > Sent: Friday, July 31, 1998 8:33 AM
> > To: 'Carl-Uno Manros'; [e-mail]
> > Subject: RE: IPP> SEC - How could IPP work over firewalls?
> > 
> > 
> > Step 2 - Inbound proxies are unusual - I have never heard 
> of one. Does
> > anybody have a product names for one.
> > 
> > > -----Original Message-----
> > > From:	Carl-Uno Manros [SMTP:[e-mail]]
> > > Sent:	Thursday, July 30, 1998 5:59 PM
> > > To:	[e-mail]
> > > Subject:	IPP> SEC - How could IPP work over firewalls?
> > > 
> > > We have held a meeting with some firewall and proxy experts 
> > today to get
> > > their views on how IPP could work over firewalls. Here is a short
> > > description of the scenario that came out of those discussions: 
> > > 
> > > When a print request (or other IPP request) comes in to the 
> > domain, in
> > > which the IPP Printer is located, it goes through the 
> > following steps: 
> > > 
> > > 1) The firewall inspects the request on the TCP layer and 
> > typically checks
> > > the host address and the port number. If it finds that this 
> > matches, it
> > > redirects the request to a particular proxy server. This 
> is standard
> > > firewall software. The proxy server may be dedicated to 
> handle only
> > > HTTP/IPP, or could handle several application level protocols. 
> > > 
> > > 2) The proxy server includes an IPP specific application 
> > process, which
> > > would check that the request is a valid IPP request, e.g. 
> > that it is an
> > > HTTP POST and that it contains the MIME type 
> "application/ipp". This
> > > software will need to be tailored and written to handle IPP. 
> > > 
> > > 3) If TLS  is used, the proxy server can also perform the 
> > authentication
> > > and decryption services. 
> > > 
> > > 4) The proxy server then redirects the request to the IPP 
> > server inside
> > > the domain. Note that the previous steps are performed 
> > before the request
> > > is accepted into the domain. 
> > > 
> > > There are various configuration alternatives, e.g. the 
> > firewall and proxy
> > > server may be integrated in the same box.  
> > > 
> > > A couple of other observations and bits of advice: 
> > > 
> > > - If you want unlimited access to an IPP printer, simply 
> > put it outside
> > > the firewall, or on the domain border, so it can be 
> > accessed from both
> > > outside and inside the domain. 
> > > 
> > > - If you want to let requests come in through your firewall 
> > at all, you
> > > will probably *always* use TLS for requests from outside 
> > the domain. If
> > > you let the proxy server handle authentication and 
> > encryption, there is no
> > > real need to use TLS between the proxy server and the IPP 
> > server. This
> > > means that clients from inside the domain do not need to 
> > use TLS, when
> > > accessing the IPP server. 
> > > 
> > > Comments? 
> > > 
> > > Carl-Uno 
> > > 
> > > Carl-Uno Manros 
> > > Principal Engineer - Advanced Printing Standards - Xerox 
> > Corporation 
> > > 701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231 
> > > Phone [phone], Fax [phone] 
> > > Email: [e-mail]
> > 
>