Re: RFC 3205 background (HTTPSubstrate-16)

At 03:05 PM 02/04/02 -0500, Keith Moore wrote:
>A couple of people mentioned to me that 3205 was under discussion here;
>I thought I'd send a note to try to give some background and rationale
>and context that might not be clear from the document.

Interesting and very helpful.  I can't see much to disagree
with in here.  The whole port-80 problem is a pointer to a
larger issue and one where we can maybe put an oar in
at low cost for significant benefit.

>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.  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 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

(hm... looking at the above rules I find that they don't
seem to depend on which high-level protocol is being used,
aside from you have to know somehow whether a message 
claims to be in XML.  is that indicative of something?)

The above would cause operational problems in the case
of rules such as 3 and 5 when the messages are large.

I assume some group somewhere in the Web Services galaxy
has started to worry about this kind of stuff?  If not, we 
should at least make a statement about how something 
like the above is architecturally necessary.

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

Received on Tuesday, 2 April 2002 15:53:40 UTC