>From ipp-owner at pwg.org Fri Jul 31 02:01:46 1998
Received: from mailhub.btwebworld.com [193.113.211.246]
by praseodumium.btinternet.com with smtp (Exim 1.70 #1)
id 0z23Zq-0001Rn-00; Fri, 31 Jul 1998 02:01:46 +0100
Received: from mail.btwebworld.com by mailhub.btwebworld.com (SMI-8.6/SMI-SVR4)
id CAA13249; Fri, 31 Jul 1998 02:04:31 +0100
Received: by mail.btwebworld.com (SMI-8.6/SMI-SVR4)
id CAA01270; Fri, 31 Jul 1998 02:03:14 +0100
Received: from lists.underscore.com (actually host uscore-1.mv.com) by mail.btwebworld.com with SMTP (Messageware MTA (NEXOR)) with ESMTP; Thu, 30 Jul 1998 01:03:12 -2400
Received: from localhost (daemon at localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA14762 for <C.Lacey at datatrade.co.uk>; Thu, 30 Jul 1998 21:04:13 -0400 (EDT)
Received: by pwg.org (bulk_mailer v1.5); Thu, 30 Jul 1998 21:03:55 -0400
Received: (from daemon at localhost) by lists.underscore.com (8.7.5/8.7.3) id UAA14713 for ipp-outgoing; Thu, 30 Jul 1998 20:59:38 -0400 (EDT)
Message-Id: <3.0.5.32.19980730175909.009d3ea0 at garfield>
X-Sender: cmanros at garfield
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Thu, 30 Jul 1998 17:59:09 PDT
To: ipp at pwg.org
From: Carl-Uno Manros <manros at cp10.es.xerox.com>
Subject: IPP> SEC - How could IPP work over firewalls?
Mime-Version: 1.0
Content-Type: text/enriched; charset="us-ascii"
Sender: owner-ipp at pwg.org
<fontfamily><param>Times New Roman</param><bigger>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
</bigger></fontfamily>
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 at cp10.es.xerox.com