WBMM> RE: Scope and Starting Point

WBMM> RE: Scope and Starting Point

WBMM> RE: Scope and Starting Point

McDonald, Ira imcdonald at sharplabs.com
Sat Feb 22 14:08:24 EST 2003


-----Original Message-----
From: Wagner,William [mailto:WWagner at NetSilicon.com]
Sent: Friday, February 21, 2003 3:28 PM
To: McDonald, Ira; 'Wbmm (E-mail)
Subject: RE: WBMM> RE: Scope and Starting Point

Ira,

I am sorry, I guess my write-up is not clear. The only inbound HTTP path
required is at the "Monitor", which generally is a centralized data
collection site servicing many enterprises. The imaging devices or their
proxies  initiate all connections, which makes the requirements of this
approach very different from internal management schemes. This configuration
is being used by several companies.

<ira> Your model of imaging devices or their proxies initiating all the 
      TCP/HTTP connections works fine of course - my mistake.

...snip...

I respect the IETF ability to suggest guidelines but I do not understand why
they should care or seek to restrict what is sent out by a browser accessing
the internet. That is the model that I am suggesting. Of course, if there is
a valid reason why this configuration is somehow flawed (in a serious enough
way to counter the obvious advantages), then it is desirable to find this
out and seek alternatives.

<ira> The IETF cares about what kind of traffic flows on given ports and
      protocols because the DMTF/IETF/W3C are spending a lot of time on
      their joint CIM (Core Information Model) and what are now called
      PIBs (Policy Info Bases) used for "policy-based" system management.

      If imaging devices (for example) "hide" their WBMM application by
      masquerading as "web browsers on port 80" they defeat assigning
      priority classes to traffic (for routing) and security mechanisms
      (for protecting corporate data from being disseminated outside
      across the firewalls).

      I would urge you not to advocate the use of port 80 by WBMM.  It
      is not "firewall friendly".

Have fun.

Bill Wagner



-----Original Message-----
From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
Sent: Friday, February 21, 2003 3:26 PM
To: Wagner,William; McDonald, Ira; 'Wbmm (E-mail)
Subject: RE: WBMM> RE: Scope and Starting Point


Hi Bill,

In your model, special firewall setup IS necessary!

In-bound HTTP (even on port 80) from the Internet to someone's
desktop computer or printer is exactly what system admins
don't allow across their firewalls.  The inbound HTTP is
allowed ONLY to specific IP addresses (internal Web servers
or FTP servers).

PSI implementations MUST ONLY use the (future) IANA-assigned
PSI "registered port" (a number greater than 1024 for a vendor
defined protocol).

PSI implementations (even by administrator configuration)
MUST NOT ever use port 80.

Firewall friendly (according to the IETF's work-in-progress
guidelines on "firewall friendly") means that applications
never share the same "well-known" (< 1024) or "registered"
port.

The premise that using HTTP transport is "firewall friendly"
is obsolete.  The best document on the topic is Keith Moore's
"On the use of HTTP as a Substrate" (RFC 3205, February 2002)
which is Best Current Practice status.

Cheers
- Ira



-----Original Message-----
From: Wagner,William [mailto:WWagner at NetSilicon.com]
Sent: Friday, February 21, 2003 11:55 AM
To: McDonald, Ira; 'Wbmm (E-mail)
Subject: RE: WBMM> RE: Scope and Starting Point


Ira,

Perhaps that was an unfortunate term to use. I think Axeda uses the term
"firewall friendly (C)". The intent is to provide limited access to imaging
devices without jeopardizing enterprise or network security, but also
without requiring special tunneling in the firewalls beyond what must be
done to provide employee internet access. Indeed, it was my understanding
that this is a basic premise of PSI as well.

If there are firewall application cracking, then we must consideration how
to address that. But, from the perspective of someone involved with
deploying such equipment, the approach become much less viable (read
unacceptable to most customers) if special firewall setup is needed.
. 
Thanks.

Bill Wagner

-----Original Message-----
From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
Sent: Friday, February 21, 2003 12:35 PM
To: Wagner,William; 'Wbmm (E-mail)
Subject: RE: WBMM> RE: Scope and Starting Point


Hi Bill,

I disagree - "finessing firewalls" by using HTTP (presumably
on specifically port 80?) is NOT a valid goal in my opinion.

Neither customers nor vendors should WANT to "finesse"
firewalls.

Cheers,
- Ira McDonald

PS - Note that most new firewalls do application level cracking
of HTTP port 80 traffic, so "finessing" them is not going to be
easy in the future.


-----Original Message-----
From: Wagner,William [mailto:WWagner at NetSilicon.com]
Sent: Thursday, February 20, 2003 4:04 PM
To: 'Wbmm (E-mail)
Subject: RE: WBMM> RE: Scope and Starting Point




Bob Tailor had a very good suggestion.  "..try to identify the issues before
[the conference call]
 so you might ask that everyone post them to WBMM before the meeting. For
"simple" issues, we may be able to knock them off in email, saving our phone
time for the more significant/contentious issues."

I had intended that sort of thing in asking for comments on the write-up (or
any other comments that were felt to be germane). But an explicit request
may be more fruitful.

Please forward your issues to the list!

Lets start with a few that I see.

1. Basic purpose: I have defined it as access by an external agent to
imaging devices on an enterprise network, for the purpose of monitoring
usage and alerts, perhaps for doing maintenance tests and general
configuration, and perhaps for downloading files including executables,
fonts, upgrades, etc.
	a. Do we have agreement on this?
	b. Is there a strong feeing that the scope must be expanded, and if
so, how?

2. Consideration of the approaches in the documents referenced by Ira, Lee
and Don (thank you all). Should we embrace, ignore, or possibly extract some
aspects from which ones?
  My contention is:
	a. as overall approaches, all seem to lack the concept of finessing
firewalls
	b. approaches intended for managing/configuring networks miss the
problems of an external agent trying to manage devices on the network. The
MIS people want some inherent restrictions on what the external site can do,
and in many cases, want to be able to monitor messages being sent out to
make sure that there is nothing untoward.
	c. we may however, want to consider some other aspects of the other
approaches. Perhaps the coding or the notion of XML coded RPCs.

3. Is there general agreement on the use of HTTP clients operating in a
Browser-like mode as the mechanism to finesse firewall?

Please feel free to add issues!

Many thanks,

Bill Wagner/NetSilicon



-----Original Message-----
From: TAYLOR,BOB (HP-Vancouver,ex1) [mailto:bobt at hp.com]
Sent: Thursday, February 20, 2003 3:49 PM
To: Wagner,William
Subject: FW: WBMM> RE: Scope and Starting Point


3/4 4-5 EST works for me.  One suggestion: Given that you only are
allocating one hour, it might be good to try to identify the issues before
then, so you might ask that everyone post them to WBMM before the meeting.
For "simple" issues, we may be able to knock them off in email, saving our
phone time for the more significant/contentious issues.

bt

-----Original Message-----
From: Wagner,William [mailto:WWagner at NetSilicon.com]
Sent: Wednesday, February 19, 2003 6:11 PM
To: wbmm at pwg.org
Subject: WBMM> RE: Scope and Starting Point




Greetings:

I have attached some thoughts on the use cases the WBMM should be
addressing, and taken a cut at defining a starting point.  The document is
posted to:
ftp://ftp.pwg.org/pub/pwg/wbmm/white/wbmm_Scope&Start.pdf

I would appreciate some feedback with the objective of finding common ground
within the working group. Would a conference  call on 4 March, 4-5 PM EST be
agreeable?



Bill Wagner



More information about the Wims mailing list