Re: RFC 3205 background (HTTPSubstrate-16)

> >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 #.  ...
> > 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.
> 
> Can't disagree, and yet the market may blithely ignore the IETF
> and deploy tons of heterogeneous apps over port 80.  Whether they
> do or not, it's pretty clear that given lots of Web Services,
> ordinary everyday security tools are just going to have to
> start looking into the data streams at a level much higher than
> packets and ports.  

This is already happening.  But IMHO it would also be reasonable for sites
that run web services to specify that those services should run on other 
ports than port 80 - to simplify their security setups and increase their
ability to monitor that traffic.

> Given that a large proportion of new stuff
> is going to be based on the exchange of XML-encoded messages,
> peeking inside the information flow is more tractable than it
> once was.

I don't know if it's much more tractable - it's hard to analyze
XML inside TCP streams at the packet level.  I might draw a different 
conclusion - namely, that the new stuff piped over port 80 is going to 
make port 80 less transparent than it once was.  (to some degree this 
is already happening also - a number of interception proxies have 
been observed which alter the HTTP payload)

> I can imagine a security policy setup of the future with
> a ruleset something like this:
> 
> 1. existing kinds of rules based on ports and IP addresses
> 2. Things not specifically allowed and not in XML are blocked
> 3. XML messages containing any elements or attributes from the
>    namespace http://example.com are blocked
> 4. XML messages in a SOAP packet routed to a service we know
>    about on the port we expect it to be listening on are allowed
>    irrespective of content
> 5. XML messages containing only markup from namespace
>    http://example.org are allowed and passed through
>    irrespective of port
> 6. Otherwise block

I guess I see a differently-shaped decision tree - one which
doesn't assume that everything is either "existing" or in XML.
I do agree that firewalls that can intellegently filter XML 
will probably find wide use.

> And sorry Keith, at the moment I'd bet that port number
> becomes increasingly less useful down the road as a basis for
> policy or analysis.  -Tim

Perhaps.  We can't control how people use the net, we can only
make recommendations.  But I'd like to see us avoid making 
recommendations which are detrimental to valuable functionality,
especially when we don't have a good replacement for that 
functionality.  And it's much harder to filter tcp streams based 
on their content than it is to filter packets based on packet headers.

Keith

Received on Tuesday, 2 April 2002 16:43:05 UTC