Network Management Page 3
XMLNetMan examples...

Project Contents

Page 1
The Project and Aims
Conceptual Overview
System Structure

Page 2
Service Constructs
Constructs Libraries
Function Calls

[Page 3]
Rule Specification
Pre-Processor Output
Example Restrictions

Page 4
Limitation Detection

Page 5

 Introduction to Restriction

 Trnaslations Problems

Due to the level of abstraction introduced in describing the behaviour of network services, there is commonly a mismatch between the two levels of configuration. Features supported by the XML description may translate directly into one implementation level service but not another, which implies that the overall behaviour of the system will not be as the user expected.

This section describes a process that enables the user to test whether there will be any problems in the translation process. In addition it reports to the user information on the XML elements of their configuration that are restricted, along with textual reasoning.

Restrictions are described as mapping a combination of XML configuration elements to some text reason explaining why they are not supported. These will be specified by the creator of the translation, and can contain multiple rules that an XML element must match to be declared as a restriction.

 Identifying Restrictions

Restriction calculation is performed using a pre-processing style. The full XML output of the service is fed into the pre-processor, specifying which translation we desire to test for restrictions. The pre-processor itself is in fact a serial processing XML filter, using a set of predefined rules (specified as restrictions) to analyse the stream of XML as it passes. Elements that match the rules will be returned to the user, along with the text reason for that restriction matching.

The restriction filter provides a rich syntax for matching XML configuration element, with the intent of being able to specify any restriction that may occur. The basic element of a restriction maps from the status of an attribute or element to a text reason that gets outputted on the match of such an attribute. However, combinations of these can be made and put into groups forming logical operations such as AND/OR. Further groups can be created consisting of other groups and sub-elements allowing complex node configurations to be matched.

Goto Top

XML Filter

I intend to add support to allow function input to be controlled in the same was as restriction filters.

This would allow fine control over the input fed into function calls.

Slyware Logo

Example Filter

For some more examples of filters, see the translations that come with the prototype.

Also, see some of the input files for the automatic testing, these contain lots of examples.

Other Uses

The XML restriction filter could also be used to locate configuration bad practice.

This could add an extra layer of processing, to allow suggestions to be made for configuration improvements.

I'll think up some examples!

 Restriction Rule Specification

Restriction rules are defined within the main translation XML file, and aim to provide a mapping between combinations of elements to some text string. The following sections detail the various types of rules that can be used, and how they can be linked together into groups for advanced matching.

 Matching Existance/Absence of an Element

The following restriction segment shows matching on the existence of a sub-element of XML. This will therefore match any Rule's that have one or more protocol sub-elements within them, hence the overall path to this element is /Firewall/FirewallConstruct/Rule/protocol. A specific filter syntax is used to address restrictions.

                reason="Matching existence of sub-element"/>

Due to the nature of the processor, absence of elements must be matched using a restriction group, explained below.

 Matching Existance/Absence of an Attribute

The following restriction matches src elements of XML that have an attribute address defined, with or without a specific value. The lower rule matches interface specifications that don't have an attribute via defined.

                reason="Existence of element attribute"/>

                reason="Absence of element attribute"/>

 Matching Attribute with/without Specific Value

The ability to match on attributes with or without a specific value is shown below. The first matches Rule's that have a RuleID attribute set at the value of 1004. The seconds will match all interface elements that have an attribute called direction, whose value does not equal in.

                reason="Existence of an attribute with specific value"/>

                reason="Absence of an attribute with a specific value"/>

 Group Matching

Restriction groups have a different syntax. They can represent some logical operation of other groups and element, be it AND, OR or ANY, specified in the type attribute. When they type ANY is specified it is logically equivalent to OR, but indicates that there is no connection between the rules. Groups match at a defined path within the XML structure, as specified by the matchOn attribute. During pre-processing, this group will become active when we enter this path, and the group will be checked to see if it matched when we leave that path, and hence the group becomes deactivated.

Sub-elements and groups within a restriction group must fall within the path that the group is active for; hence the topmost path should be specified in the outer group. Again, a text description of the restriction is specified to be outputted when a match is found.

Elements within the group are defined as offsets from the matchOn path for that group. In the following example, it will match Rule's that have a RuleID attribute of 1002, 1004 or 1006, as the overall type of the group is OR. A similar syntax to that describes above is used for each restriction element, with the leading path removed.

                reason="Attribute with either one of a range of values">

            <RestrictionElement name="@RuleID=1002"/>
            <RestrictionElement name="@RuleID=1004"/>
            <RestrictionElement name="@RuleID=1006"/>

Due to the nature of the serial pre-processor, to match the absence of an XML element the rule must be enclosed within a restriction group. This is because the processor tests elements and attributes as it meets them on the XML stream, but as the missing attribute would never occur, it needs a position to launch the test to see if it has been found. The following example will match all Rule's that don't have an options sub-element or an interface sub-element. Note that the type of ANY has been used here, and each restriction element within the group has in fact its own reason. This simply means that there is no connection between the two elements within the group, and when a match is found for one its reason should be outputted immediately.


            <RestrictionElement name="/options[!]" reason="No options"/>
            <RestrictionElement name="/interface[!]" reason="No interface"/>

 More Complex Restriction Group Examples

The following restriction group demonstrates a more complex combination of rules. It will match Rule's that have a RuleID attribute, that have a direction of travel as either in or out within the interface sub-element and which also either pass or deny that overall Rule. Also, the Rule must be for a protocol other than all, be from some specific source IP address (hence not any) and destine for a destination not on any specific port number.

                type="AND" matchOn="Firewall::Filter:FirewallConstruct/Rule" 
                reason="Matching some random group of data">

            <RestrictionElement name="@RuleID"/>

                    type="OR" matchOn="Firewall::Filter:FirewallConstruct/Rule">

                <RestrictionElement name="/interface@direction=in"/>
                <RestrictionElement name="/interface@direction=out"/>

                    type="OR" matchOn="Firewall::Filter:FirewallConstruct/Rule/action">

                <RestrictionElement name="@perform=pass"/>
                <RestrictionElement name="@perform=deny"/>

            <RestrictionElement name="/protocol@!type=all"/>
            <RestrictionElement name="/src@type=ip"/>
            <RestrictionElement name="/dst/port-num[!]"/>


The following Rule would indeed match the above restriction group.

	<fw:Rule RuleID="1007">
            <fw:action perform="pass"/>
            <fw:protocol type="other" name="udp"/>
            <fw:src type="ip" mask="" address=""/>
            <fw:dst type="ip" mask="" address=""/>
            <fw:interface direction="out"/>

 Matching on Specific Number of Sub-Elements

In addition to the rule formats mentioned above, an option has been added to allow exact counts of sub-elements to be matched. These apply to all RestrictionElements within RestrictionGroup's, hence can be used to count how many sub-elements match that specific rule construct.

        <RestrictionGroup type="AND" 
               reason="Rules with exactly 4 icmptype sub-elements">

            <RestrictionElement name="/options/icmptype[4]"/>

The basic method shown above allows simple counting of elements for a match to occur. The square brackets at the end of the rule denote such a count, and can take various forms. By default, as when the square brackets are not included, [+] is assumed. This simply means to match that rule where there are one or more occurrences of it within the enclosing group. As seen previously, [!] can be used to specify the absence of a rule match to that element complete. An integer can be placed within the brackets, hence [5] would match when exactly five instances of that rule match within the group. Negation can be used with this, hence [!5] would match where there is anything but 5 exact element matches.

 More or Less than a Specific Number of Sub-Elements

Finally, more than and less than can be represented using the [mX] and [lX] definitions respectively, where X denotes some non-inclusive boundary. With multiple rules such as this, complex situation can be represented allowing finer control of element matches.

The following group will match on whole FirewallConstruct's. To match, the construct must have more than one Rule and one Rule or more must have a destination address of Also, more than two Rule's must define options, and one or more of these options contains icmptype sub-elements.

	<RestrictionGroup type="AND" 
               reason="Combination of expressions">

            <RestrictionElement name="/Rule[m1]"/>
            <RestrictionElement name="/Rule/dst@address=[+]"/>
            <RestrictionElement name="/Rule/options[m2]"/>
            <RestrictionElement name="/Rule/options/icmptype[+]"/>

Goto Top


If you use this software, and develop any new translations, or fix the old ones, please mail me!

This whole approach to service configuration will only be of use if a wide service and translation base can be constructed.

 Pre-Processor XML Output

The aim of the pre-processing stage is not just to identify the existence of possible restrictions, but to also notify the user which parts of their XML service description it is related to. To solve this the package can produce additional information when restrictions are found to help the user identify the location of the problems.

Using the output from the last restriction group details in the previous sections, the following output would be produced by the pre-processor.

	<Restriction line="57" col="18" 
	               reason="Matching some random group of data">

            <fw:Rule RuleID="1007">
                <fw:action perform="pass"/>
                <fw:protocol type="other" name="udp"/>
                <fw:src type="ip" mask="" address=""/>
                <fw:dst type="ip" mask="" address=""/>
                <fw:interface direction="out"/>


In the above example we can conclude that the matched XML element is the seventh Rule, within the first FirewallConstruct all within the first Firewall. As the input XML is just a service, there will be no additional node definitions on the path.

In addition to reporting the path, the package also fetches the actual source XML input, using the reported path, and outputs this within the final restriction report. In effect this can report straight back to the user the source of the restriction, allowing them to make the required changes. To aid interpreting systems using this package, such as GUI's, the restriction report is itself valid XML, hence enabling further processing to be performed.

If the restriction element or group specified the outputXML attribute to equal "no", then only the path and restriction reason details will be generated with no source XML output.

Goto Top

What we Want

The aim is to build a translation that can indicate any know problems prior to implementation.

The user would then be aware of the possibility of any undesired behaviour in the final system.

 Example Translation Restrictions

One of the restrictions of the IPFilter translation is that it does not support the gid and uid attributes of the options element, representing group and user ID respectively. Therefore, the following restriction group will highlight to the user the translation problem if they have these options defined within their XML service specification.

	    reason="UID and GUI are not supported within IPFilter">

            <RestrictionElement name="@uid"/>
	    <RestrictionElement name="@gid"/>

Another restriction that has been identified within IPFilter is with Rule direction. IPFW, along with the abstracted XML firewall description, allows Rule's to be specified without an explicit direction of travel. Within the firewall implementation, these will match rules going in either direction. However, IPFilter requires an explicit direction statement, hence there may be mismatch between the two descriptions. Therefore, a restriction rule was added to the IPFilter translation description, to indicate to the user that such a problem may exist.

The following restriction group represents the match required for identifying XML firewall Rule's without explicit direction definitions. The first restriction element will match Rule's that don't have an interface definition at all, and the second matches Rule's that have an interface definition, but no direction attribute. Finally, the restriction sub-group will match Rule's with a direction attribute not equal to in or out.

	    reason="Rules without set directions will be duplicated">

            <RestrictionElement name="/interface[!]"/>
            <RestrictionElement name="/interface@!direction"/>

                <RestrictionElement name="@!direction=in"/>
                <RestrictionElement name="@!direction=out"/>


Goto Top

Page <<  1  2  3  4  5  >>