IPP Mail Archive: RE: IPP> Firewalls etc.

IPP Mail Archive: RE: IPP> Firewalls etc.

RE: IPP> Firewalls etc.

Paul Moore (paulmo@microsoft.com)
Thu, 11 Jun 1998 15:38:34 -0700

Let me add 1 qualification to my '#1 must work by default'

If I already have 'normal' (GET, PUT & POST) web access to the Internet from
my desktop then #1 should work by default.

> -----Original Message-----
> From: Harry Lewis [SMTP:harryl@us.ibm.com]
> Sent: Thursday, June 11, 1998 2:00 PM
> To: ipp@pwg.org
> Subject: Re: IPP> Firewalls etc.
>
> I agree with Paul. Outbound should work, by default. There are many ways
> to
> shuffle confidential information outside a company's firewall, or spend
> their
> money foolishly, if someone is into risking their job for excitement.
> Allowing
> print jobs by default does not add significantly to this capability.
>
> I think the "Internet PRINT to my office" scenario (analogous to FAX) is a
> compelling feature of IPP. Paul is probably right that this will not
> happen
> 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
> internet.
> This is the one I was always talking about
>
> 2. A printer inside a corporation being accessed from outside. It was
> clear
> 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 clear
> about what is desirable, acceptable, etc. in each case. Also I think that
> 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
> site.
>
> #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
> company
> 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
> allow
> arbitrary inbound posts. This is true in routed cases and in proxy cases.
>
> 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 'internet
> fax'. How can their admin configure their router/firewall/proxy to only
> allow IPP traffic in? Well today's proxies dont allow inbound HTTP traffic
> which rules this scenario out in the vast majority of corporate cases
> anyway. For routed/firewall cases it seems that you either allow any POST
> 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 this
> 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 people
> will have to either a)trust and cross their fingers b) place the printers
> 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) about
> not allowing inbound connections, each one has has to be approved and hand
> configured. They dont even allow ping in, so there is no way an admin
> would
> 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?'
>
>
>