IPP Mail Archive: Re: IPP> Firewalls etc.

Re: IPP> Firewalls etc.

Harry Lewis (harryl@us.ibm.com)
Thu, 11 Jun 1998 16:59:59 -0400

I agree with Paul. Outbound should work, by default. There are many way=
s to
shuffle confidential information outside a company's firewall, or spend=
their
money foolishly, if someone is into risking their job for excitement. A=
llowing
print jobs by default does not add significantly to this capability.

I think the "Internet PRINT to my office" scenario (analogous to FAX) i=
s a
compelling feature of IPP. Paul is probably right that this will not ha=
ppen
without some SA involvement, but, in my opinion, we need to be sure we =
all
understand how this will be facilitated.

Harry Lewis - IBM Printing Systems

owner-ipp@pwg.org on 06/11/98 02:09:26 PM
Please respond to owner-ipp@pwg.org
To: ipp@pwg.org
cc:
Subject: IPP> Firewalls etc.

It became clear to me during the last tele conf that we need to clearly=

distinguish two cases in this discussion.

1. A user inside a corporation sending print commands out into the inte=
rnet.
This is the one I was always talking about

2. A printer inside a corporation being accessed from outside. It was c=
lear
to me that this is what some others were talking about

I think that these are two very different things and we have not be cle=
ar
about what is desirable, acceptable, etc. in each case. Also I think th=
at
some people have been discussing #1 with people who think that they are=

discussing #2 (I certainly discovered that I was)
-----------------------------------------------------------------------=
-----
---------------------------
Now my views on the two cases.

#1 must work by default. I.e. if somebody on a web site or whatever has=
an
ipp URL then (provided I have the right client s/w installed) I should =
be
able to print to it, in the same way I can send email or browse a web s=
ite.

#2 Must not work by default. I.e. if I install an IPP printer (whether =
s/w
on an NT server or embedded in the device) then somebody outside my com=
pany
should not be able to print to it. .

This is the solution we have today. #1 works provided that the user can=
post
onto the internet (usually true). #2 works because most networks dont a=
llow
arbitrary inbound posts. This is true in routed cases and in proxy case=
s.

The main problem that we seem to have is 'how can an admin allow #2?'. =
For
example PrintShopsRUs want to make their printer(s) available. Second
example is: I want to set up an IPP printer in my office as an 'interne=
t
fax'. How can their admin configure their router/firewall/proxy to only=

allow IPP traffic in? Well today's proxies dont allow inbound HTTP traf=
fic
which rules this scenario out in the vast majority of corporate cases
anyway. For routed/firewall cases it seems that you either allow any PO=
ST to
a given IP address (OK for a real printer but not ok for a server), or =
we
need someway of distinguishing the traffic. If we dont do this then thi=
s
will disable this class of usage scenarios. My view is that this is of
secondary importance - given that #2 will never work for proxied
environments we should focus on #1 scenarios, which do work. For #2 peo=
ple
will have to either a)trust and cross their fingers b) place the printe=
rs
outside the firewall (like their web servers often are).

I can never see the Internet Fax one working in a corporation. I mean
allowing me to setup up a printer in my office and just having it work
without any SA work. Most network admins are fanatical (rightly so) abo=
ut
not allowing inbound connections, each one has has to be approved and h=
and
configured. They dont even allow ping in, so there is no way an admin w=
ould
allow inbound IPP traffic to all IP adresses.

The only issue I see left then is 'how can an admin prevent #1'? My
immediate response is 'why would they want to?'

=