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

Paul Moore <paulmo@microsoft.com> Fri, 31 July 1998 15:48 UTC

Delivery-Date: Fri, 31 Jul 1998 11:48:50 -0400
Return-Path: ipp-owner@pwg.org
Received: from cnri.reston.va.us (ns [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA22287 for <ietf-archive@ietf.org>; Fri, 31 Jul 1998 11:48:49 -0400 (EDT)
Received: from lists.underscore.com (uscore-1.mv.com [199.125.85.30]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id LAA28565 for <ietf-archive@cnri.reston.va.us>; Fri, 31 Jul 1998 11:48:34 -0400 (EDT)
Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA01513 for <ietf-archive@cnri.reston.va.us>; Fri, 31 Jul 1998 11:48:48 -0400 (EDT)
Received: by pwg.org (bulk_mailer v1.5); Fri, 31 Jul 1998 11:39:06 -0400
Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA00953 for ipp-outgoing; Fri, 31 Jul 1998 11:33:28 -0400 (EDT)
Message-ID: <CB6657D3A5E0D111A97700805FFE6587BF6FA2@red-msg-51.dns.microsoft.com>
From: Paul Moore <paulmo@microsoft.com>
To: 'Carl-Uno Manros' <manros@cp10.es.xerox.com>, ipp@pwg.org
Subject: RE: IPP> SEC - How could IPP work over firewalls?
Date: Fri, 31 Jul 1998 08:33:18 -0700
X-Mailer: Internet Mail Service (5.5.2232.9)
Sender: owner-ipp@pwg.org

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:manros@cp10.es.xerox.com]
> Sent:	Thursday, July 30, 1998 5:59 PM
> To:	ipp@pwg.org
> 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 +1-310-333 8273, Fax +1-310-333 5514 
> Email: manros@cp10.es.xerox.com