Protocol security features (was Re: how bad is soap?)

[Wes Hardaker <wjhns1@hardakers.net>]

>>>>> On Fri, 25 Apr 2003 08:47:14 -0500, "Allen, Keith" <kallen@tri.sbc.com> said:

Keith> The use of WSDL, of course, would not necessarily limit the
Keith> netconf protocol to SOAP and HTTP.

One of the things that needs to be discussed is the issue of how
controllable the netconf configuration traffic is through a firewall.
Many companies today block SNMP at the border to ensure that network
configuration, status, etc isn't retrievable or modifiable beyond the
boundaries of the appropriate network.  This is easily implemented
since SNMP has an assigned port number to block (161).  I assume that
operators would like to continue being able to control where their
management requests came from via the use of firewall controls.

[warning: I'm not an expert on BEEP or on SOAP, but I have no doubt
people will correct me if I state something inaccurately.]  With
xmlconf, the protocol is likely to be BEEP which can run over just
about any mime-compliant protocol (including http, tls, ...).  With
SOAP, the story is similar.  The most common SOAP transport mapping
defined today is over HTTP (though SOAP over BEEP is defined as well,
as has been discussed here).  In fact, MicroSoft's web page describes
SOAP over HTTP as a feature since it can bypass most firewalls since
no one blocks http ports.

The problem, of course, comes when an operator wants to enable netconf
in their network but to block access to it at the border.  Normally,
in the past with just SNMP it was easy:

  rule: port 161 -> DENY

Now, even more secure environments would have a separated management
network and the boxes would be configured to only accept management
traffic over a particular interface which was dedicated to management
network.  This doesn't work, of course, if the boxes themselves are
simple and don't allow this sort of filtering within the box, so
invariably the above rule is still installed at the borders.

With the new solutions being discussed, the above policy becomes
problematic to implement as the rules get worse:

  rule 1: port 80 and sub-type (soap|netconf) -> DENY
  rule 2: port 80                             -> ACCEPT

The problem is that many firewalls don't support the low-level
protocol parsing required by #1 or because even if a firewall did
support it the CPU hit required to do that parsing (especially when
the majority of the traffic was http based) meant that a smaller
bandwidth could pass through the box or that a larger transient delay
would occur.  The rule get even worse when netconf is running over
soap which is running over http and you may want some soap to slip
(sorry, I couldn't help it) through the firewall but not netconf.   Rule
#1 isn't implementable at all for encrypted protocols like tls/ssl.
Maybe operators are happy with this anyway?  IE, as a long as netconf
traffic is encrypted it's allowed to originate beyond the border?

There are obvious solutions to this (eg, assign a new port number for
netconf based protocol operations even if it is to run over a standard
protocol).  I'd like to suggest it as a requirement of the WG that the
results be able to be easily filtered at the border using common
equipment available today.  (I don't even really care what the
solution is, as long as it's possible to implement without a large
degradation in performance).

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>