Using RDF for Home Network ConfigurationNine by Nine14 Chambrai CloseApplefordAbingdonOxonOX14 4NTUK+44 1235 848491+44 1235 848562GK-SWAD-E@ninebynine.orghttp://www.ninebynine.net/Network configurationRDFXMLSemantic webAuthorizationStandardsIETFW3CThis memo describes the use of RDF metadata in configuring
Internet access from a home network.
Its goal is to demonstrate the practical applicability of
common semantic web technologies in a simple real-world
based scenario.
The work has been inspired in part by an architectural proposal
for XML network configuration submitted to the IETF.This memo has been prepared for the
SWAD-Europe project,
as a strand of
CLRC/RAL participation.This memo describes the use of RDF metadata in configuring
Internet access from a home network.
Its goal is to illustrate the practical applicability of
common semantic web technologies in a simple real-world
based scenario.The work has been inspired in part by an architectural proposal
for XML network configuration submitted to the IETF.
It has also been undertaken as an experiment in manipulating
access control data represented using RDF, as a continuation
of some survey work described in a previous memo,
Framework for Security and Trust Standards.
This document is organized as follows:Section 2 introduces the scenario addressed by this demonstration.Sections 3-5 introduce the RDF vocabulary used to describe the
scenario and the results obtained.Section 6 discusses the inference process used to create RDF
data that closely matches the resulting configuration files.Section 7 describes the software used to generate the required
configuration data from RDF.The remaining sections discuss some implications of this work.The files used by this demonstration can be found by following the
links from
.
In particular, the RDF/N3 (Notation3) source files used are:
Network and access policy description:
Access policy transformation rules:
Configuration files generation template:
The background scenario for this example use of RDF metadata
is a home business network connected to the Internet by a Cisco
dial-on-demand ISDN router.This illustration is also available in
PDF format.Network access is provided by an ISP dial-up account that
provides unmetered access up to a specified weekly limit.The network users are two parents who use the Internet for business,
and two children who use it for play and social purposes.
The working adults require occasional access at any time.
The children's access has to be restricted, otherwise they would
quickly exceed the total connect time allowed by the ISP.The Cisco ISDN router runs Cisco's proprietary IOS software, which
has a system of IP-addressed based filters that are quite capable of
restricting access at different times based on the IP address of
the internal host. Creating the correct IOS configuration files
for this kind of selective filtering is quite a tricky task.
The router can accept an externally defined configuration via the
TFTP protocol.Within the local network, machines are assigned IP addresses using DHCP.
The DHCP service is provided by a Linux host running DHCPD and
a local DNS service.Given all this, the goal is to use RDF to specify the access
policy and device configuration requirements, and use some
available RDF tools to generate the desired configuration files
for the Cisco ISDN router and the Linux-based services.The general idea is illustrated thus:
This illustration is also available in
PDF format.This section presents the metadata used to describe the network users
and access policies.Vocabularies used:
RDF core vocabulary:
essential RDF terms.
Namespace .
RDF schema:
RDF schema (vocabulary description) terms.
Namespace .
friend-of-a-friend:
for describing basic information about people.
Namespace .
RDF schema for iCalendar:
for describing Internet access schedules.
Namespace .
iCalendar ancillary terms:
Some additional vocabulary defining for use in conjunction with
some of the ical: terms. There are two namespace URIs in circulation.
Namespace
or .
The demonstration code described here uses the former value.
a new vocabulary for describing network user characteristics.
Namespace .
a new namespace for components and devices on the
local network that is the target of this demonstration.
Namespace .
Describing network users and access policies:
Describes a network user with the following properties:
Name of user.
Email address of user (mailto: URI).
A user:HostSystem resource that corresponds to a network host
that is commonly used by this person.
The user's access rights are applied to this host.
This property may be repeated if the person described commonly
uses more than one network host.
A user:AccessPolicy resource that represents the person's
access rights.
Describes a network host system with the following properties:
A brief descriptive label for this machine.
A description of this machine.
Local name of machine (prepend to network domain to get FQDN).
A user:LocalNetwork resource that represents the local network,
and to which network-wide information is attached.
IP address of this machine on local network, as "x.x.x.x",
where each x is a 0-255 numeral.
MAC (Ethernet) hardware address of this machine,
as "hh:hh:hh:hh:hh:hh", where each hh is a 2-digit
hexadecimal numeral.
A foaf:Person resource that indicates the person who is
generally responsible for administration of this system.
A user:AccessPolicy resource that represents the access
rights to be allowed for this host. This may be specified
directly, or inferred from properties of any declared user.
A foaf:Person resource that represents a person who generally
uses this host, and whose access permissions should be applied
to this host. This may be specified directly, or inferred.
The name (i.e. foaf:name property) of a person who
generally uses this host (cf. user:usedBy).
Describes network-wide characteristics of the local network,
with the following properties:
A brief descriptive label for this network.
A description of this network.
Local name of machine that provides DHCP and other host
configuration services for this network (prepend to network
domain to get FQDN).
Local name of machine that provides netbios name services
for this network (prepend to network domain to get FQDN).
The DNS domain name for this network, without leading or
trailing '.' characters.
The IP subnet address for this network, as "x.x.x.x".
The IP subnet mask for this network, as "x.x.x.x".
The IP local net broadcast address for this network,
as "x.x.x.x".
A user:HostSystem resource that represents the
default gateway (IP router) for the current network.
A list of IP addresses of DNS servers that are available to
hosts on the current network.
The first IP address in the pool of addresses allocated by
DHCP for hosts on this network, as "x.x.x.x".
The first IP address in the pool of addresses allocated by
DHCP for hosts on this network, as "x.x.x.x".
The range of IP addresses allocated by
DHCP for hosts on this network, as "x.x.x.x y.y.y.y".
(This information duplicates user:dhcpPoolStart and
user:dhcpPoolEnd, and should be eliminated, but has
been defined here to simplify some internal processing.
There is a general issue here that address values are
not easily manipulated by general RDF tools like cwm,
so additional inputs may be provided as a way to avoid
having to define difficult and complex inference rules.)
A user:AccessPolicy resource that represents the access
rights to be allowed for hosts that do not otherwise have
any access rights defined. (This is not currently used, as
it represents a kind of default reasoning that doesn't sit
comfortably in RDF.)
Describes an access policy that may be applied to a network user or host.
Ultimately it is enforced on a per-host basis.
An access policy is described using the following properties:
Display name for this access policy.
A description of this access policy.
references a user:AccessRule resource describing a network
access permission. This property may appear several times
to specify multiple access permissions, all of which are
granted.
Describes an access rule that may be applied. The rule controls
protocols that may be used (by IP protocol and port number) and the
times at which access may be granted.
An access rule permits access if the user:accessTimes and
user:accessServices properties are satisfied.
An access rule is described using the following properties:
ical:VCALENDAR resource describing allowed access times.
To be specified exactly once.
references a user:ServiceGroup resource describing the
external services that may be accessed.
To be specified exactly once.
Describes a group of services that are associated with an
access rule:
references a user:ServiceProtocol resources, which
describes a collection of permitted services associated
with a specified IP protocol.
This property may be repeated to specify additional
permitted services.
Describes a collection of services that are associated
with a specified IP protocol.
Specifies an IP protocol number of name
ICMP(1), IGMP(2), TCP(6), UDP(17), SCTP(132), etc.
May be specified as numeric values or protocol names.
Normally, this should be specified exactly once.
in some cases, it might make sense to specify more than once;
e.g. specify both UDP and TCP for a collection of service
protocols that are all made available via both TCP and UDP
on the same port numbers.
Specifies a list of port numbers to which access is not
to be permitted. Access to all ports other than those
specified in the list is permitted.
Should be specified at most once, and not when
user:includePort is used on the same subject.
Specifies a port number to which access is permitted.
May be specified multiple times to permit access to
multiple ports.
Should not be specified when user:excludePorts is used.
Each occurrence of user:includePorts and user:excludePorts
used specifies a port or ports to which access is permitted.
All of the ports thus specified are permitted for access.
The recommendations given above concerning use of multiple
properties are not absolute requirements, but are suggested
to avoid unexpected results. E.g., the result of two
user:excludePorts properties each specifying a different
port number is that access is permitted for all port numbers.
Describes a schedule of times at which access may be
permitted. Most of the properties used are defined by the
RDF schema for iCalendar,
which itself is derived quite closely from the
iCalendar core object specification.
Some additional properties are used:
A display name for this time range value.
Specifies a unique alphanumeric name for this time range that
can be used when generating configuration data.
In addition to the network, users, hosts and access policy definitions
described above, the input data also contains some hints that are used
to guide the creation of Cisco IOS configuration files. Ideally, these
hints would not be required, and with sufficient effort some logic
processing code could be developed to deduce the detailed information
provided by the hints. But the object of this exercise was an experiment
to generate configuration data with some available tools.
The hints are provided by two additional resources:
provides hints for generating an IOS access list to be used
for dial-on-demand Internet connection. Certain protocols
are blocked to prevent normal network activity from creating
unneeded network connections.
provides hints for generating an IOS access list to be used
for determining what packets from the local network are to be
allowed through the IOS router.
Each of these resources is a list of RDF resources, each of which
is used in turn to control the generation of some IOS access list
statements. In this list, order is significant. The properties
for generating access list statements are:
Generates an access list entry that permits all traffic that
is local to the current network (i.e. that is both from and
to the local network).
Generates an access list entry that blocks all traffic that
originates from the local network DHCP address pool.
where the value is a user:ServiceItem resource.
Generates an access list entry that blocks access
for the specified IP protocol to any port excluded
by the user:ServiceItem value.
where the value is a user:AccessRule resource.
Generates an access list entry that permits
access for all network hosts to the indicated
service at the indicated times.
where the value is a user:HostSystem resource.
Generates an access list entry that permits
access for the specified host at all times.
where the value is a foaf:Person resource.
Generates an access list entry that permits
access for all hosts used by the specified user
at all times.
The RDF description of access policies takes the form of access
permission, all of which are taken to be granted.
This is consistent with the formal semantics of RDF, in which
asserting an RDF graph means that all of the statements it
contains are true.
A consequence of the RDF formal semantics is that any graph
entails any of its subgraphs. That is, if a given RDF graph is
presumed to be true, then any other RDF that contains some subset
of the statements of the first graph is also true under the same
circumstances. So, if we have an RDF graph that asserts some
set of permissions, and remove some statements from that graph,
the resulting graph must not describe any more permissions
than the original.
However, confusion can arise when considering the conditions
under which access may be granted. Rather than requiring all
of the stated access conditions to hold, in general only some
of them are required. This may seem to be logically at odds
with the conjunctive semantics of access permissions described
above.
But determining whether some particular access is to be granted
is a different process than describing the available access
permissions: technically, it can be regarded as a query against
some database of access permissions.
A query against a database succeeds when the database contains
some information that satisfies the query, and does not require
that all such information does so.
Thus, there is no conflict.
Finally, it is a conscious design decision for the purposes
of continuing experimentation that the logic of access
permissions described here is based solely on granting access.
Many real-world access control systems
(e.g. XACML)
use a combination of access permissions and denials.
This sometimes makes it easier to define access policy starting
from some broad principles which can be successively refined
by exception, but also makes the logic of access control more
complicated to analyze.
The successive refinement approach also sits less comfortably
with RDF's strictly monotonic logical semantics.
It would be possible to use RDF to define both permissions and
denials, but then some additional issues must be considered:
A given access may evaluate as both permitted and denied.
How is this to be treated? It may be regarded as an
inconsistency in the access rules, or some other form of
resolution be adopted.
Some access may evaluate as neither permitted nor denied.
How are these cases to be treated?
This vocabulary is used to generate DNS and DHCP data to be served by the
Linux network server.Vocabularies used:
a new vocabulary for describing network user characteristics.
Namespace .
new vocabulary for describing DNS address records.
Namespace .
new vocabulary for describing DHCP configuration,
to associate known IP addresses with hardware MAC addresses.
Namespace .
Describing DNS address records:
Describes a DNS host address record.
Domain name of host.
An IP address,
or list of IP addresses if the host is multi-homed.
Describing DHCP configuration:
DHCP parameters relating the local network rather
than any specific host.
(See previous section.)
(See previous section.)
(See previous section.)
(See previous section.)
(See previous section.)
(See previous section.)
(See previous section.)
(See previous section.)
Default lease for DHCP-granted addresses.
Maximum lease for DHCP-granted addresses.
Fully qualified domain name of DHCP server for this network.
Dynamic DNS update style for this network.
DHCP parameters relating a specific host.
These are used to generate fixed IP addresses for hosts
identified by their MAC (Ethernet) address.
Access rules are then enforced on the IP address.
Local name of the host (see previous section).
Fully qualified domain name of the host.
A host MAC (Ethernet hardware) address for the given host.
This section introduces a vocabulary for describing network device configuration.
The terms presented here are oriented toward Cisco IOS configuration file commands.
Additional terms may be introduced for different network devices.The original intent of this demonstration was to infer a range of RDF statements
that correspond closely to the required output, and then generate the configuration
files in a simple syntactic transformation process with minimal logic. In the
present implementation, there is less inference and more logic used in the output
generation phase than was intended. As a consequence, the network device
configuration vocabulary actually used is quite limited.
(I still think that the original design approach is preferable, but to realize that,
greater inferential power needs to be brought to bear on the problem.)
Vocabularies used:
a new vocabulary for describing network user characteristics.
Namespace .
RDF schema for iCalendar:
for describing Internet access schedules.
Namespace .
a new vocabulary for describing network device characteristics.
Describing network devices:
Specifies a time schedule for an access rule.
Specifies an alphanumeric name for the time range
that can be used as an identifier in generated
configuration data.
Specifies a REC-VEVENT resource that describes a time
interval that is included in the schedule specified by
the current VCALENDAR value.
Specify a recurring time interval.
Day(s) of week for which this interval applies. One of:
"Sunday", "Monday", "Tuesday", "Wednesday", "Thursday",
"Friday", "Saturday", "weekday", "weekend".
Time for start of interval, as hh:mm, 24-hour clock.
Time for end of interval, as hh:mm, 24-hour clock.
Note: in accordance with cwm name-munging algorithms,
hyphens contained in identifiers are coded as
double underbars ("__") in Notation3 data.
These rules are evaluated using Tim Berners-Lee's
cwm program.
It may also be possible to evaluate these using Jos De Roo's faster
RDF rule engine, Euler.The rules are intended to take the input network and access policy
description and generate additional facts closely corresponding to the
network configuration data that is used by the network configuration
and access control mechanisms. The idea is that the resulting facts
are simply converted to the appropriate format for use by the network
systems. (In practice, to get an initial demonstration prepared quickly,
this goal is only partially realized.)
The rules are coded in Notation3 in the format recognized by
cwm.
Running cwm with the following files as input:
and
yields this output file:
Roughly, the rules perform the following functions:
Construct a full domain name for each host.Apply some default DHCP parameter values.Construct DNS configuration values for each host,
combining network-wide and host-specific information.[[[TODO: Process access policy descriptions to a set of
statements corresponding closely to the various
configuration files to be generated.
This will involve reformulating the given access
policies in a logical form that maps directly to
the configuration file formats.]]]Process time interval data to a form that corresponds
closely to the required access configuration data
format.The final creation of configuration files from RDF configuration data is
performed using my Semafor RDF-driven query and report generation
software , and in particular the Python
program N3GenReport.py.
This software is described in
RDF for little languages.
The output files generation template is coded in Notation3 in
a format recognized by the N3GenReport.py program.
Running N3GenReport.py with the following files as input:
yields these output files:
which are the required configuration data for DHCP, DNS and the IOS firewall
router respectively.
The results from this exercise have not been exactly as expected,
though the deviations from expectations have not been so great as
to invalidate the goals.
It was expected that this simple access control scenario was
well within the capabilities of current RDF tools to process with
very little difficulty.
In practice, the inference needed to map between the logic of
different access control schemes has not been so easy.
The first implemented design
suffered a flaw with
respect to RDF formal semantics because of some confusion
between describing access permissions and determining whether
a given access is permitted. This has resulted in addition
of the material in section .
It has been expected that this project would demonstrate the
following features of using RDF in this way:
RDF would provide a common metadata format to support
heterogeneous devices and systems.
Benefits would accrue from leveraging existing ontology and
standards work (foaf, calendar).
Free extension of existing data schemas would allow specific
requirements to be handled.
Use of "off-the-shelf" (or "off-the-net") applications would
make the demonstration quick and easy to implement.
By doing most of the processing in the form of RDF inference,
semantic transformations would be separated from syntactic
transformations, and the syntactic transformations would be very
easy to apply.
A common input syntax for all aspects of the process would simplify
the creation and acquisition of various kinds of input data.
Extension to more demanding scenarios would be easily achieved
because of easy extensibility of RDF metadata.
To a fair extent, these expected results have been achieved, but
the work proved more difficult than expected because some of the
required logic was not easily coded as cwm inference rules.
More work is needed to determine if this is due to fundamental
limitations of cwm rules, or lack of skill in applying them.
Items 1-3 above were fully realized. RDF's model allowing free
extensibility proved to be very valuable, by making it easy to
build on existing data definitions.
Items 4-6 were realized to some extent, but the complexity of
logic required to get the desired results meant that:
It may be that "off-the-shelf" (or "off-the-net") software
is helpful only so far as the required task is within its
capabilities. That RDF is a very general purpose language
for representation of information does not necessarily mean
that any RDF inference engine is an equally general-purpose
tool for processing that information.
Despite this, the demonstration was still constructed quite
quickly using existing software, though the result was less
functional than expected.
The separation of semantic and syntactic transformation was
reduced by difficulties in achieving the desired semantic
transformations. I remain convinced that a sufficiently
powerful inference system, capable of dealing with inferences
over complex information, would allow this goal to be
largely realized. I feel that formal structures for
representing disjunction as well as conjunction are needed to
support sufficiently powerful inference processes. Such
structures can be simulated within a closed environment
(such as cwm). Maybe the existing tools will yield
better results on further exploration.
Use of a common syntax certainly has many advantages: it avoids
the need to write new parsing software (an activity that XML
alone does not completely eliminate), but it does mean that some
of the input data must be prepared in a format that is sometimes
obscure to read. There has been discussion of tools to map
expressions in some defined syntax directly into RDF. My report
generation software could well benefit from such a transformation.
With respect to item 7, extensibility of the final result is not as
easy as hoped. I think this is due to the cumulative effect of the
shortcomings noted above, and that easy extensibility would follow
from a cleaner separation between semantic and syntactic transformations.
The following lessons were noted concerning some practical aspects
of writing inference rules for this demonstration:
Rule debugging can be tricky and tedious.
It's not always obvious why a rule is not matched.
Rules are more compact than many other forms of programming,
but not always easier to write.
It is questionable if simple rules are indeed the most useful
form of expression of some application logic.
Rule design: use smaller rules, generate intermediate values.
I don't know if this is a useful heuristic, but many of the
difficulties encountered would have been easier to spot if
simpler rules and more of them had been used.
Could possible use more powerful inference capabilities.
This idea is picked up in the next subsection.
Notation3 makes a very convenient configuration file format.
Whatever its faults may be for expressing complex logic,
it is very easy to code the information contained in
a wide variety of application configuration file
formats directly in Notation3.
This section explores some ideas for improved inference capabilities,
noting that many of the shortcomings noted previously seem to stem
from limitations in this area.
In trying to write the inference rules for this demonstration,
it was felt that some or all of the following capabilities may have
been useful:
Ability to decompose and get at parts of string expressions.
(e.g. decomposition of IP address literals.)
Logical functions on numbers.
(e.g. to allow calculation of IP local net broadcast address.)
Capability to generate new unique symbols, as required.
(For example, when generating Cisco IOS access-lists,
arbitrary numbers are used to reference them.)
List decomposition, honouring RDF semantics.
Currently, to get at the members of a list I have tried
flattening the list, which loses some of the information
encoded there. (Maybe adding sentinel values to the list
elements would be more effective here?)
List comprehension or building mechanisms. (e.g. is it possible
to do an "obvious" task like constructing the reverse of a list
using cwm inference rules?)
The above discussion of list decomposition and building functions
is motivated in part by a desire to infer new facts from some
ordered information in a way that preserves the original ordering
in the new facts.
Some kinds of rule seem to be repeated for different types of
information with similar structure. Is there value in having
a rule-schema (or parameterized rule) mechanism?
Mapping between different logical frameworks. (E.g. is it
possible using simple inference rules to map a conjunctive normal
form to disjunctive normal form, and vice versa? I see this as
a step on the path to optimizing logical expressions, so that
given some expression with a given logical outcome to recreate
that expression using a minimum number of some different set of
primitives. This seems to be at the heart of many of the problems
of access rule transformation.)
It may be that all of these facilities can be simulated using simple
cwm style rules. If so, it's not obvious how. Also, there's a question
of efficiency: even for rules that can be expressed in cwm, they may
be slow to execute, and general performance benefits may accrue from
having them available as efficiently implemented built-in functions.
With respect to the target application of this demonstration,
many areas for possible further work are suggested:
Change the access control descriptions and rules to use the
new iCalendar-based schema proposed by the SWAD-E calendaring
workshop .
A seed version of this new schema is at
or
.
Fix up some problems with the IOS configuration file format.
Extend the configuration data to create a full IOS
configuration file, rather than just the access control
elements.
Automatically generate a SOA sequence number for DNS
configuration data.
Enhance the rules to handle multi-homed hosts.
Pick up other DNS parameters from RDF input data.
(Notation3 makes a very convenient file format
for arbitrary configuration data.)
Consider how to take advantage of web-based knowledge.
For example, is there an easy way to take advantage of
information published by device manufacturers?
Rules, coded in RDF, for transformation from a common
configuration database might be an example of this.
Common abstraction for all network devices.
The current work concentrates on mapping a given access
policy to device-dependent information using device-specific
rules. Is it possible to define a common information format
(possibly with redundant information) that is directly
transformable to a range of different devices. Then, just
one set of transformation rules would serve for all devices.
(By different devices, for the purposes of the immediate
demonstration I mean devices with different access control
models.)
Generation of IPChains firewall configuration files.
The work to map access control policy to access rules might be
usefully applied to reliable configuration of freely available
firewall software, such as IPChains on Linux. Configuring
firewall software tends to be difficult and complicated:
could semantic web tools simplify this process?
User interface. The current work is completely lacking any
form of friendly user interface, depending as it does on
hand-edited text files for its input.
Extension to other kinds of device.
Automatic resource allocation.
In its present form, the rules require that resource allocation
(e.g. IP addresses) is defined in the input policy description.
Could the work be generalized to allow some resources to be
allocated automatically from some pool. A further step would
be dynamic allocation, but that would require a run-time version
of the RDF rule processing software.
This work has been conducted with support from the
SWAD-E project,
as a strand of participation by
Rutherford Appleton Laboratory.
Central to this work has been Tim Berners-Lee's program
Cwm,
which has been used to perform all the RDF inference.This document has been authored in XML using the format described
in RFC 2629 , and converted to HTML using
the XML2RFC utility developed by Marshall Rose
().
European Semantic Web Advanced DevelopmentW3C/ILRTILRTRutherford Appleton LaboratoryCLRC/RALFriend-of-a-friend (FOAF) RDF vocabulary.W3CILRTiCalendar (ICAL) RDF vocabularyILRTUCSCSWAD-Europe: Developer Workshop Report 2 - Semantic Web calendaringILRTCwm (closed world machine)W3CEuler proof mechanismAgfaNotation3 query processor and report generator softwareNine by NineRDF for little languagesNine by NineFramework for Security and Trust StandardsNine by NineUsing RDF for Home Network Configuration
(flawed version of 15-Dec-2002)Nine by NineDocument initially created.
Initial sketch of RDF vocabularies to use.
Revise vocabulary descriptions based on running code.
Add descriptions of rules and output file generation template.
Add initial draft of conclusions and lessons learned.
Noted logical problem with vocabulary definition.
This document revision will be preserved as:
.
Reworked vocabulary to be consistent with RDF formal semantics,
in particular the subgraph inference rule.
Add a note about logic of access control descriptions.
Make note to adopt new iCalendar-based RDF schema proposed
by the SWAD-E calendaring workshop.
Added CCLRC copyright notice.
Spell-check content.
Add diagram of process and files used.
Explore ways of using CWM rules to manipulate access policies
into different forms of expression
(see ).