ietf
[Top] [All Lists]

RE: SOAP/XML Protocol and filtering, etc.

2001-05-08 07:00:03
A content-filtering firewall depends on the ability to interpret traffic
the same way the receiver would.  If you assume a malicious insider that
will parse something differently then how it is labelled, then they can
always tunnel, encrypt, or obfuscate traffic into something that is
permitted (IP over HTTP, e-mail, covert channels, etc.).  

Note that if the header field is not used to dispatch on the recipient,
and is just a hint to the firewall, then it is trivial to subvert the
firewall and filtering based on that header field is a worthless.

For example, if you have a policy that blocks ActiveX and a firewall that
filters that MIME type, I can always mis-label my ActiveX as a GIF or text
and send it.  But then only a colluding recipient would execute it as
ActiveX.  However, if the receiver doesn't use the MIME type, but handles
the content based on something else like filename suffix, then filtering
on MIME types is pointless.

On Mon, 7 May 2001, Bora Akyol wrote:

Why would a firewall or a firewall admin trust the packet to indicate 
what it really is?

Bora

At 2:50 PM -0700 5/7/01, Henrik Frystyk Nielsen wrote:
The meaning of SOAPAction is not to say that "this is a stockquote
service" but to say that "I am sending you a SOAP message of a type that
is part of a stock quote service".

The difference is that one is a destination which is carried in HTTP by
the request-URI but the other is a hint about what is in the message.
This is why SOAPAction is a separate parameter.

Henrik

 On Sun, May 06, 2001 at 03:12:08PM -0400, Keith Moore wrote:
 > and client APIs.  It also keeps HTTP servers from having to know
 > specifically whether a particular URI corresponds with a SOAP
 > request (in which case it might have to look at the SOAPAction
 > header in order to know how to handle it) or not (in which case the

 > SOAPAction header should be ignored).

 Yep; seems to me that Content-Type ss more appropriate for dispatch,
 if doing it in a header is desireable.
 >
 >ugh.  only if you must.  the URL is *far* better for this purpose.


-- 
Mike Fisk, RADIANT Team, Network Engineering Group, Los Alamos National Lab
See http://home.lanl.gov/mfisk/ for contact information