Document Actions
RELAX NG Schema for Packet Filters
This schema defines a reusable schema for packet filters with a logic similar to Linux netfilter or JUNOS. There is no start element so that it can be included in other schemas. It is work in progress.
Packet filters are configured as a sequence of rules specifying
- Properties of the packet, like incoming/outgoing interface, MAC and IP addresses and values of specific fields and flags in the L2, L3 and L4 headers.
- Action that is to be taken if the packet matches the rule, i.e., satisfies all the specified properties.
If a packet matches multiple rules, the first matching rule is applied. If a packet doesn't match any of the rules, it is discarded.
<grammar
ns="http://www.liberouter.org/ns/netopeer/1.1.13"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"
xmlns:a="http://cesnet.cz/ns/rngrest-annotations/1.0"
xmlns="http://relaxng.org/ns/structure/1.0">
target-content
This attribute and element is attached to elements that are designed to serve as a target for links from other locations of the document. Attribute xml:id implements the semantics defined in xml:id W3C recommendation. Optional name element gives a human-readable representation of the target identifier. If it is not specified, the value of xml:id is used.
The pattern is referenced by:
<define name="target-content">
<attribute name="xml:id">
<data type="ID"/>
</attribute>
<optional>
<element name="name">
<data type="token"/>
</element>
</optional>
</define>
href-attribute
This attribute is used for referring to other elements within the same document that are identified by the xml:id attribute, see target-content.
The pattern is referenced by:
<define name="href-attribute">
<attribute name="href">
<data type="IDREF"/>
</attribute>
</define>
optional-description
Description is used for adding unstructured information to the parent element. It is always optional.
The pattern is referenced by:
<define name="optional-description">
<optional>
<element name="description">
<text/>
</element>
</optional>
</define>
negate-attribute
This attribute, if set to true, indicates negation of a packet property. It matches if and only if the same property with the negate attribute set to false does not match. The default value is false.
The pattern is referenced by:
- match-uint-range-content
- match-list-content
- common-match-ip-content
- match-ipv6-content
- match-tcp-content
- port-range-content
- match-tcp-ecn-content
- match-icmp-content
<define name="negate-attribute">
<optional>
<attribute name="negate">
<data type="boolean"/>
</attribute>
</optional>
</define>
match-bit-content
This pattern enables three-way matching of various flags. The value any means "don't care".
The pattern is referenced by:
<define name="match-bit-content">
<choice>
<value>on</value>
<value>off</value>
<value>any</value>
</choice>
</define>
match-uint-range-content
This pattern is used for matching unsignedInt ranges with limits specified in the min and max elements.
<define name="match-uint-range-content"> <ref name="negate-attribute"/> <interleave> <optional> <element name="min"> <data type="unsignedInt"/> </element> </optional> <optional> <element name="max"> <data type="unsignedInt"/> </element> </optional> </interleave> </define>
ip-address-content
This pattern allows either IPv4 or IPv6 address. The address family must be specified in the af attribute.
The pattern is referenced by:
<define name="ip-address-content">
<choice>
<group>
<attribute name="af">
<value>ipv4</value>
</attribute>
<ref name="ipv4-address-content"/>
</group>
<group>
<attribute name="af">
<value>ipv6</value>
</attribute>
<ref name="ipv6-address-content"/>
</group>
</choice>
</define>
ipv4-address-content
This pattern provides the data type of IPv4 address.
The pattern is referenced by:
<define name="ipv4-address-content">
<data type="token">
<param name="pattern">((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])</param>
</data>
</define>
ipv6-address-content
This pattern provides the data type of IPv6 address.
The pattern is referenced by:
<define name="ipv6-address-content">
<data type="token">
<param name="pattern">([0-9a-fA-F]{0,4}:){0,7}[0-9a-fA-F]{0,4}</param>
<param name="pattern">(([0-9a-fA-F]+:){7}[0-9a-fA-F]+)|(([0-9a-fA-F]+:)*[0-9a-fA-F]+)?::(([0-9a-fA-F]+:)*[0-9a-fA-F]+)?</param>
</data>
</define>
prefix-content
This pattern provides the IP prefix data type consisting of an IP address and optional prefix length in bits. The prefix length defaults to the full length of the address, i.e., 32 for IPv4 and 128 for IPv6.
The pattern is referenced by:
<define name="prefix-content">
<element name="address">
<ref name="ip-address-content"/>
</element>
<optional>
<element name="length">
<data type="nonNegativeInteger"/>
</element>
</optional>
</define>
mac-address-content
This pattern provides the data type of MAC address.
The pattern is referenced by:
<define name="mac-address-content">
<data type="token">
<param name="pattern">([0-9a-fA-F]{2}:){5}[0-9a-fA-F]{2}</param>
</data>
</define>
prefix-lists-element
This element is a wrapper for prefix lists that are used for defining a subset of the IPv4 or IPv6 address space as a union of specified address prefixes.
<define name="prefix-lists-element">
<element name="prefix-lists">
<zeroOrMore>
<element name="prefix-list">
<ref name="prefix-list-content"/>
</element>
</zeroOrMore>
</element>
</define>
prefix-list-content
This pattern defines the content of the prefix-list element. Its main part is the set of prefixes in the match-prefix element. An IP address matches a prefix list if it is contained in at least one of the prefixes.
The pattern is referenced by:
<define name="prefix-list-content">
<interleave>
<ref name="target-content"/>
<ref name="optional-description"/>
<zeroOrMore>
<element name="match-prefix">
<ref name="prefix-content"/>
</element>
</zeroOrMore>
</interleave>
</define>
packet-filter-element
The packet-filter element contains the entire specification of a packet filter.
<define name="packet-filter-element">
<element name="packet-filter">
<ref name="packet-filter-content"/>
</element>
</define>
packet-filter-content
This pattern defines the content of a packet filter. Its design assumes that a packet filter is activated by specifying a link to it from an appropriate location, e.g., network interface configuration.
The pattern is referenced by:
<define name="packet-filter-content">
<interleave>
<ref name="target-content"/>
<ref name="optional-description"/>
<element name="filter-rules">
<zeroOrMore>
<element name="filter-rule">
<ref name="filter-rule-content"/>
</element>
</zeroOrMore>
</element>
</interleave>
</define>
filter-rule-content
A packet filter rule consists of a list of match conditions and an action that is taken if all conditions are satified.
The pattern is referenced by:
<define name="filter-rule-content">
<interleave>
<ref name="optional-description"/>
<element name="match-list">
<ref name="match-list-content"/>
</element>
<element name="action">
<ref name="action-content"/>
</element>
</interleave>
</define>
match-list-content
The match conditions include:
- Network interface where the packet was received or sent. Depending on how the filter is used this condition may or may not be applicable.
- Specific data from L1, L2 and L3 headers.
The pattern is referenced by:
<define name="match-list-content">
<interleave>
<optional>
<element name="interface">
<ref name="negate-attribute"/>
<ref name="href-attribute"/>
</element>
</optional>
<optional>
<element name="mac-address">
<ref name="negate-attribute"/>
<ref name="mac-address-content"/>
</element>
</optional>
<optional>
<element name="ipv4">
<ref name="match-ipv4-content"/>
</element>
</optional>
<optional>
<element name="ipv6">
<ref name="match-ipv6-content"/>
</element>
</optional>
<optional>
<element name="tcp">
<ref name="match-tcp-content"/>
</element>
</optional>
<optional>
<element name="udp">
<ref name="match-udp-content"/>
</element>
</optional>
<optional>
<element name="icmp">
<ref name="match-icmp-content"/>
</element>
</optional>
</interleave>
</define>
common-match-ip-content
This pattern defines conditions for IP header content that apply to both IPv4 and IPv6.
The pattern is referenced by:
<define name="common-match-ip-content">
<optional>
<element name="source-list">
<ref name="negate-attribute"/>
<ref name="href-attribute"/>
</element>
</optional>
<optional>
<element name="destination-list">
<ref name="negate-attribute"/>
<ref name="href-attribute"/>
</element>
</optional>
<optional>
<element name="dscp-field">
<ref name="negate-attribute"/>
<data type="nonNegativeInteger">
<param name="maxInclusive">63</param>
</data>
</element>
</optional>
<optional>
<element name="ecn-field">
<ref name="negate-attribute"/>
<optional>
<element name="ecn-capable">
<ref name="match-bit-content"/>
</element>
</optional>
<optional>
<element name="congestion-experienced">
<ref name="match-bit-content"/>
</element>
</optional>
</element>
</optional>
</define>
match-ipv4-content
The pattern is referenced by:
<define name="match-ipv4-content">
<interleave>
<ref name="common-match-ip-content"/>
</interleave>
</define>
match-ipv6-content
Above the common IP data, the flow label can be matched in IPv6 packets.
The pattern is referenced by:
<define name="match-ipv6-content">
<interleave>
<ref name="common-match-ip-content"/>
<optional>
<element name="flowlabel">
<ref name="negate-attribute"/>
<data type="unsignedInt"/>
</element>
</optional>
</interleave>
</define>
match-tcp-content
The following data can be matched in TCP headers:
- source and destination port ranges
- status of TCP flags
- ECN flags (RFC 3168)
- presence of various TCP options
The pattern is referenced by:
<define name="match-tcp-content">
<interleave>
<optional>
<element name="source-port-range">
<ref name="port-range-content"/>
</element>
</optional>
<optional>
<element name="destination-port-range">
<ref name="port-range-content"/>
</element>
</optional>
<optional>
<element name="tcp-flags">
<ref name="match-tcp-flags-content"/>
</element>
</optional>
<optional>
<element name="tcp-ecn">
<ref name="match-tcp-ecn-content"/>
</element>
</optional>
<optional>
<element name="tcp-options">
<ref name="negate-attribute"/>
<list>
<oneOrMore>
<choice>
<value>cc</value>
<value>ccecho</value>
<value>ccnew</value>
<value>echo</value>
<value>echo_reply</value>
<value>md5</value>
<value>mss</value>
<value>sack</value>
<value>sack_perm</value>
<value>selective ack ok</value>
<value>timestamp</value>
<value>wscale</value>
</choice>
</oneOrMore>
</list>
</element>
</optional>
</interleave>
</define>
port-range-content
Port range is specified by the two limits, from and to, that can be expressed either numerically or using a symbol such as http. The limits always belong to the range.
The pattern is referenced by:
<define name="port-range-content"> <ref name="negate-attribute"/> <interleave> <element name="from"> <choice> <data type="unsignedShort"/> <data type="token"/> </choice> </element> <element name="to"> <choice> <data type="unsignedShort"/> <data type="token"/> </choice> </element> </interleave> </define>
match-tcp-flags-content
A match condition can specify the status of one or more TCP flags: on, off or any. The latter value means that the flag status doesn't matter and is the default if a particular flag element is missing.
The pattern is referenced by:
<define name="match-tcp-flags-content">
<interleave>
<optional>
<element name="syn">
<ref name="match-bit-content"/>
</element>
</optional>
<optional>
<element name="ack">
<ref name="match-bit-content"/>
</element>
</optional>
<optional>
<element name="fin">
<ref name="match-bit-content"/>
</element>
</optional>
<optional>
<element name="rst">
<ref name="match-bit-content"/>
</element>
</optional>
<optional>
<element name="urg">
<ref name="match-bit-content"/>
</element>
</optional>
<optional>
<element name="psh">
<ref name="match-bit-content"/>
</element>
</optional>
</interleave>
</define>
match-tcp-ecn-content
This pattern is used for matching ECN flags in TCP header. Semantics is the same as in match-tcp-flags-content.
The pattern is referenced by:
<define name="match-tcp-ecn-content"> <ref name="negate-attribute"/> <interleave> <optional> <element name="congestion-window-reduced"> <ref name="match-bit-content"/> </element> </optional> <optional> <element name="ecn-echo"> <ref name="match-bit-content"/> </element> </optional> </interleave> </define>
match-udp-content
Source and destination port in the UDP header can be matched against specified ranges.
The pattern is referenced by:
<define name="match-udp-content">
<interleave>
<optional>
<element name="source-port-range">
<ref name="port-range-content"/>
</element>
</optional>
<optional>
<element name="destination-port-range">
<ref name="port-range-content"/>
</element>
</optional>
</interleave>
</define>
match-icmp-content
In ICMP packets, type and code can be matched, both as numeric values.
The pattern is referenced by:
<define name="match-icmp-content">
<interleave>
<ref name="negate-attribute"/>
<optional>
<element name="type">
<data type="nonNegativeInteger"/>
</element>
<optional>
<element name="code">
<data type="nonNegativeInteger"/>
</element>
</optional>
</optional>
</interleave>
</define>
action-content
Each rule must define exactly one action. The choice is:
- accept
- Accept the packet.
- drop
- Discard the packet silently.
- reject
- Discard the packet but send an ICMP message.
- gosub
- Use another packet filter as a "subroutine".
The pattern is referenced by:
<define name="action-content">
<interleave>
<optional>
<element name="action-options">
<ref name="action-options-content"/>
</element>
</optional>
<choice>
<ref name="accept-action-element"/>
<ref name="drop-action-element"/>
<ref name="gosub-action-element"/>
<element name="reject">
<ref name="reject-action-content"/>
</element>
</choice>
</interleave>
</define>
action-options-content
Additional options that can be specified with every action. Only one option is currently defined: if the log element is present, each matching packet will cause a message sent to syslog or other logging subsystem.
The pattern is referenced by:
<define name="action-options-content">
<optional>
<element name="log">
<empty/>
</element>
</optional>
</define>
reject-action-content
This pattern defines the content of the reject action. Type and code of the ICMP message can be specified, by default it is "port unreachable" (type=3 and code=3 for IPv4, or type=1 and code=4 for IPv6).
The pattern is referenced by:
<define name="reject-action-content">
<interleave>
<optional>
<element name="type">
<data type="nonNegativeInteger"/>
</element>
<optional>
<element name="code">
<data type="nonNegativeInteger"/>
</element>
</optional>
</optional>
</interleave>
</define>
accept-action-element
The pattern is referenced by:
<define name="accept-action-element">
<element name="accept">
<empty/>
</element>
</define>
drop-action-element
The pattern is referenced by:
<define name="drop-action-element">
<element name="drop">
<empty/>
</element>
</define>
gosub-action-element
This element means "jump to subroutine". Matching will continue with rules in the packet filter that is referred to by the href attribute. If no rule in the subroutine matches, a return from subroutine occurs – matching continues with the next rule in the original filter.
The pattern is referenced by:
<define name="gosub-action-element">
<element name="gosub">
<ref name="href-attribute"/>
</element>
</define>
Forgot your password?
FlowMon 1.2.0 Released