Re: RFC 3205 background (HTTPSubstrate-16)

> On Tuesday, April 2, 2002, at 12:05  PM, Keith Moore wrote:
> >
> > The intended audience for the document was IETF working groups, and
> > more generally, other groups or individuals defining protocol standards.
> > The emphasis here is on *standards*, implying that there's an 
> > expectation
> > that the protocol will be widely implemented and widely used.  The
> > prohibitions aren't intended to apply to private networks,
> > enterprise-specific applications, or to bilateral agreeements between
> > consenting parties.  So by extension I would say that the prohibitions
> > weren't intended to apply to most of the things called "web services",
> > though in the case of a particular web service that became so popular
> > that nearly every site or host were expected to provide it - under
> > those circumstances the prohibitions, and the logic behind them, would
> > be more applicable.
> 
> That's very helpful. Unfortunately, people are interpreting the document 
> in a number of ways. Perhaps a reasonable outcome would be for the TAG 
> to generate a short statement to this effect to clarify their 
> understanding of 3205, as it relates to work in the W3C (current and 
> future)?

Perhaps.  Eventually I'd like to see either a revision of 3205 or a 
joint statement between IESG and the appropriate part of W3C.  I 
really don't think we have conflicting interests here.
 
> > As for use of port 80: Traffic monitoring by port # is useful, even
> > if it's imperfect.  The same can be said of firewalls that filter 
> > traffic
> > based on port #.  I like to say that firewalls don't actually provide
> > any security assurance by themselves but they can dramatically reduce
> > the # of applications that you have to analyze in order to have some
> > assurance of security.  If a wide variety of applications use port 80,
> > the analysis becomes more difficult - a network admin can no longer
> > ask him/herself "which machines are allowed to run web servers?" but
> > instead has to allow for the possibility that each machine can run one
> > *or more* services over port 80 - each of which needs to be analyzed
> > separately.  Granted that there aren't enough port #s available to
> > assign one to every single application, but there are plenty of port
> > #s to assign one to each standard or widely-used service.  I fully
> > agree (and so would everyone on IESG) that sites should not rely on
> > port filtering to provide security, but there's a difference between
> > relying on port filtering and using port + address filtering as a way
> > to restrict the number of application servers which are capable of
> > accepting input.
> 
> The problem, of course, is that each URI endpoint on a HTTP server is 
> potentially a new application, with or without SOAP. 

True.  But sites can and do set policies that restrict the kinds of
applications that can be run on web servers, and those sites use
firewalls to restrict traffic to the set of web servers that are
known to adhere to those policies.  Running several different servers
over port 80 makes it more difficult for a site to enforce different
policies for different services - either they have to assign
different IP addresses for each service, or they have to insist that
the request-URIs for those services use explicit port #s.

(more sophisticated firewalls are also possible, but there's an
alarming tendency for smart firewalls to break applications.
I think folks will eventually learn that the more things in the
signal path, the greater the chance that the signal will be 
corrupted, and it's no easier to verify correct operation of a
firewall than it is to verify correct operation of an application.)

I don't think we should treat port 80 as a battleground.
Nobody is claiming that every single application (in the sense 
that every URI is potentially a different application) needs a 
new port, only that there are disadvantages to running multiple
applications over the same port if those applications differ in 
ways that are significant to a network administrator.  

> > I admit that "traditional use of HTTP" is imprecise language, and I
> > want to clarify that it wasn't intended to mean that HTTP or its
> > uses should not evolve.  The net, and most of its protocols, have
> > been evolving continuously for the past 20+ years, and I don't
> > see why HTTP should be an exception.  By "traditional use" I was
> > trying to anticipate the needs of network admins who would want
> > to distinguish a new protocol from HTTP (as they understood it)
> > for the purpose of filtering and traffic analysis.  If HTTP over
> > port 80 came to be used in so many different ways that a network
> > administrator couldn't make any assumptions at all about the nature
> > of the traffic - not even coarse assumptions - then this would be
> > unfortunate, and IETF doesn't want to encourage things to evolve
> > in that way.  On numerous occaions it's been useful to be able to
> > make some coarse differentiation of traffic by looking at port #s,
> > and we don't want to see this functionality lost.
> 
> The relationship between ports, protocols and services is fuzzy at best. 

Indeed.  Which is why I had trouble coming up with precise rules,
and had to resort to language like "traditional use of HTTP".
Not only is it imprecise, it's also somewhat inaccurate.

I'm sorry that the document didn't include more context.
Although frankly when people interpret the document as saying 
"don't use HTTP" I don't think that's the document's fault -
that's not what the document says.  "think before using HTTP"
is a lot closer to the intent - and I don't see anything wrong 
with asking protocol designers to think about the consequences 
of their design choices.

my guess is that it's probably feasible to revise the document 
to make such clarifications, especially if w3c folks tell
IESG that they like the revision.  

Keith

Received on Friday, 5 April 2002 11:07:16 UTC