TOC 
SWAD-Europe projectG. Klyne
 Nine by Nine
 December 15, 2002

Using RDF for Home Network Configuration

Abstract

This 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.

SWAD Europe

This memo has been prepared for the SWAD-Europe project, as a strand of CLRC/RAL participation.

2002-12-15: flawed document version

The current revision of this memo contains some logical problems with the way that RDF vocabulary is defined. The general nature of these problems is discussed in an email to the RDF calendaring mailing list http://lists.w3.org/Archives/Public/www-rdf-calendar/2002Dec/0007.html.


 TOC 

Table of Contents
 TOC 

1. Introduction

This 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 [5] for XML network configuration submitted to the IETF. It has also been undertaken as an experiment in manipulating access control data represented using RDF.

1.1 Structure of this memo

This document is organized as follows:

The files used by this demonstration can be found by following the links from http://www.ninebynine.org/SWAD-E/Intro.html#HomeNetAccessDemo. In particular, the RDF/N3 (Notation3) source files used are:


 TOC 

2. Background

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.

Illustration of home network elements

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 a range of RDF tools to generate the desired configuration files for the Cisco ISDN router and the Linux-based services.


 TOC 

3. Vocabulary for network user access policies

This section presents the metadata used to describe the network users and access policies.

Vocabularies used:

rdf:
RDF core vocabulary[1]: essential RDF terms.
Namespace http://www.w3.org/1999/02/22-rdf-syntax-ns#.
rdfs:
RDF schema[2]: RDF schema (vocabulary description) terms.
Namespace http://www.w3.org/2000/01/rdf-schema#.
foaf:
friend-of-a-friend[8]: for describing basic information about people.
Namespace http://xmlns.com/foaf/0.1/.
ical:
RDF schema for iCalendar[9]: for describing Internet access schedules.
Namespace http://www.ilrt.bris.ac.uk/discovery/2001/06/schemas/ical-full/hybrid.rdf#.
icalutil:
iCalendar ancillary terms[9]: Some additional vocabulary defining for use in conjunction with some of the ical: terms. There are two namespace URIs in circulation.
Namespace http://ilrt.org/discovery/2001/06/schemas/ical-util# or http://ilrt.org/discovery/2001/06/schemas/swws/index.rdf#. The demonstration code described here uses the former value.
user:
a new vocabulary for describing network user characteristics.
Namespace http://id.ninebynine.org/wip/2002/user/.
homenet:
a new namespace for components and devices on the local network that is the target of this demonstration.
Namespace http://id.ninebynine.org/wip/2002/user/.

Describing network users and access policies:

Class foaf:Person
Describes a network user with the following properties:
foaf:name
Name of user.
foaf:mbox
Email address of user (mailto: URI).
user:usesHost
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.
user:accessType
A user:AccessPolicy resource that represents the person's access rights.

Class user:HostSystem
Describes a network host system with the following properties:
rdfs:label
A brief descriptive label for this machine.
rdfs:comment
A description of this machine.
user:hostName
Local name of machine (prepend to network domain to get FQDN).
user:localNet
A user:LocalNetwork resource that represents the local network, and to which network-wide information is attached.
user:hostIP
IP address of this machine on local network, as "x.x.x.x", where each x is a 0-255 numeral.
user:hostMAC
MAC (Ethernet) hardware address of this machine, as "hh:hh:hh:hh:hh:hh", where each hh is a 2-digit hexadecimal numeral.
user:systemAdmin
A foaf:Person resource that indicates the person who is generally responsible for administration of this system.
user:accessType
For hosts that are not generally used by a single person, a user:AccessPolicy resource that represents the access rights to be allowed for this host.

Class user:LocalNetwork
Describes network-wide characteristics of the local network, with the following properties:
rdfs:label
A brief descriptive label for this network.
rdfs:comment
A description of this network.
user:dhcpHostName
Local name of machine that provides DHCP and other host configuration services for this network (prepend to network domain to get FQDN).
user:netbiosServer
Local name of machine that provides netbios name services for this network (prepend to network domain to get FQDN).
user:networkDomain
The DNS domain name for this network, without leading or trailing '.' characters.
user:networkAddr
The IP subnet address for this network, as "x.x.x.x".
user:networkMask
The IP subnet mask for this network, as "x.x.x.x".
user:broadcastAddr
The IP local net broadcast address for this network, as "x.x.x.x".
user:defaultGateway
A user:HostSystem resource that represents the default gateway (IP router) for the current network.
user:defaultDNS
A list of IP addresses of DNS servers that are available to hosts on the current network.
user:dhcpPoolStart
The first IP address in the pool of addresses allocated by DHCP for hosts on this network, as "x.x.x.x".
user:dhcpPoolEnd
The first IP address in the pool of addresses allocated by DHCP for hosts on this network, as "x.x.x.x".
user:addressPool
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.)
user:defaultAccess
A user:AccessPolicy resource that represents the access rights to be allowed for hosts that do not otherwise have any access rights defined. (This isn's currently used, as it represents a kind of default reasoning that doesn't sit comfortably in RDF.)

Class user:AccessPolicy
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:
rdfs:label
Display name for this access policy.
rdfs:comment
A description of this access policy.
user:access
[[[This needs reworking: no list but repeated properties; see note at head of document ]]]. references a userAccessRule resource, or a list of such rules, describing network access policy for user. If a list is given, then access is permitted if any element in the list permits access (i.e. union of permissions in a list). This property may be repeated, in which case the intersection of access thus described is permitted (note that union semantics here would break the RDF interpolation lemma).

Class user:AccessRule
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 all the user:accessTimes and user:accessServices properties are satisfied. An access rule is described using the following properties:
user:accessTimes
ical:VCALENDAR resource describing allowed access times.
user:accessServices
[[[This needs reworking: no user:ServiceGroup but repeated properties; see note at head of document ]]]. references a user:ServiceGroup resource describing the external services that may be accessed.

Class user:ServiceGroup
Describes a group of services that are associated with an access rule:
user:serviceList
[[[This needs reworking: class user:ServiceGroup to be eliminated; see note at head of document]]]. A list of user:ServiceItem resources, each of which describes a collection of services associated with a specified IP protocol. Any service allowed by any of the listed user:ServiceItem values is allowed by the current user:ServiceGroup.

Class user:ServiceItem
[[[This class needs reworking: see note at head of document]]]. Describes a collection of services that are associated with a specified IP protocol.
user:serviceProtocol
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.
user:excludePort
Specifies a port number to which access is not to be permitted.
user:includePorts
Specifies a list of port numbers to which access is permitted. Access to port numbers not in this list is not permitted.

If no user:includePorts or user:excludePort is specified then no port number restructions are imposed. If multiple user:includePorts or user:excludePort properties are specified, they are applied conjunctively; i.e. access is allowed only to ports that are allowed by all such proeprties.

Class ical:VCALENDAR
Describes a schedule of times at which access may be permitted. Most of the properties used are defined by the RDF schema for iCalendar[9], which itself is derived quite closely from the iCalendar core object specification[3]. Some additional properties are used:
rdfs:label
A display name for this time range value.
user:rangeName
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. Idealy, 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:

user:IOS_Dialout_Rules
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.
user:IOS_Recv_Local_Rules
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:

user:permitLocal
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).
user:denyPool
Generates an access list entry that blocks all traffic that originates from the local network DHCP address pool.
user:denyService
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.
user:permitRule
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.
user:permitHost
where the value is a user:HostSystem resource. Generates an access list entry that permits access for the specified host at all times.
user:permitUser
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.


 TOC 

4. Vocabulary for network address configuration

This vocabulary is used to generate DNS and DHCP data to be served by the Linux network server.

Vocabularies used:

user:
a new vocabulary for describing network user characteristics.
Namespace http://id.ninebynine.org/wip/2002/user/.
dnsa:
new vocabulary for describing DNS address records.
Namespace http://id.ninebynine.org/wip/2002/dnsa/.
dhcp:
new vocabulary for describing DHCP configuration, to associate known IP addresses with hardware MAC addresses.
Namespace http://id.ninebynine.org/wip/2002/dhcp/.

Describing DNS address records:

Class user:HostSystem
Describes a DNS host address record.
dnsa:hostDomainName
Domain name of host.
dnsa:hostIPAddress
An IP address, or list of IP addresses if the host is multi-homed.

Describing DHCP configuration:

Class user:LocalNetwork
DHCP parameters relating the the local network rather than any specific host.
user:networkDomain
(See previous section.)
user:networkAddr
(See previous section.)
user:networkMask
(See previous section.)
user:broadcastAddr
(See previous section.)
user:defaultGateway
(See previous section.)
user:defaultDNS
(See previous section.)
user:addressPool
(See previous section.)
user:netbiosServer
(See previous section.)
dhcp:defLease
Default lease for DHCP-granted addresses.
dhcp:maxLease
Maximum lease for DHCP-granted addresses.
dhcp:dhcpHostFQDN
Fully qualified domain name of DHCP server for this network.
dhcp:updateStyle
Dynamic DNS update style for this network.

Class user:HostSystem
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.
user:hostName
Local name of the host (see previous section).
dnsa:hostDomainName
Fully qualified domain name of the host.
dhcp:hostMACAddress
A host MAC (ethernet hardware) address for the gioven host.


 TOC 

5. Vocabulary for network device configuration

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 syntactioc 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:

user:
a new vocabulary for describing network user characteristics.
Namespace http://id.ninebynine.org/wip/2002/user/.
ical:
RDF schema for iCalendar[9]: for describing Internet access schedules.
Namespace http://www.ilrt.bris.ac.uk/discovery/2001/06/schemas/ical-full/hybrid.rdf#.
ndev:
a new vocabulary for describing network device characteristics.

Describing network devices:

Class ical:VCALENDAR
Specifies a time schedule for an access rule.
user:rangeName
Specifies an alphanumeric name for the time range that can be used as an identifier in generated configuration data.
ical:VEVENT-PROP
Specifies a REC-VEVENT resource that describes a time interval that is included in the schedule specified by the current VCALENDAR value.

Class ical:REC-VEVENT
Specify a recurring time interval.
ndev:dayName
Day(s) of week for which this interval applies. One of: "Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "weekday", "weekend".
ndev:timeStart
Time for start of interval, as hh:mm, 24-hour clock.
ndev:timeEnd
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.


 TOC 

6. Rules for creating configuration data

These rules are evaluated using Tim Berners-Lee's cwm program[11]. It may also be possible to evaluate these using Jos De Roo's faster RDF rule engine, Euler[12].

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[11]. Running cwm with the following files as input:

yields this output file:

Roughly, the rules perform the following functions:


 TOC 

7. Templates for creating configuration files

The final creation of configuration files from RDF configuration data is performed using my Semafor RDF-driven query and report generation software [13], and in particular the Python program N3GenReport.py. This software is described in RDF for little languages[14].

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.


 TOC 

8. Conclusions

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.

It has been expected that this project would demonstrate the following features of using RDF in this way:

  1. RDF would provide a common metadata format to support heterogeneous devices and systems.
  2. Benefits would accrue from leveraging existing ontology and standards work (foaf, calendar).
  3. Free extension of existing data schemas would allow specific requirements to be handled.
  4. Use of "off-the-shelf" (or "off-the-net") applications would make the demonstration quick and easy to implement.
  5. 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.
  6. A common input syntax for all aspects of the process would simplify the creation and acquisition of various kinds of input data.
  7. 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:

With respect to item 7, extensibility of the final result is not as easy as hoped. I think this is due to the cummulative effect of the shortcomings noted above, and that easy extensibility would follow from a cleaner separation between semantic and syntactic transformations.

8.1 Some lessons learned

The following lessons were noted concerning some practical aspects of writing inference rules for this demonstration:

8.2 Ideas for better inference capabilities

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:

It may be that all of these facilities can be similated 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.

8.3 Further work

With respect to the target application of this deminstration, many areas for possible further work are suggested:


 TOC 

9. Acknowledgements

This work has been conducted with support from the SWAD-E project[6], as a strand of participation by Rutherford Appleton Laboratory[7].

Central to this work has been Tim Berners-Lee's program Cwm[11], which has been used to perform all the RDF inferencing.

This document has been authored in XML using the format described in RFC 2629 [4], and converted to HTML using the XML2RFC utility developed by Marshall Rose (http://xml.resource.org/).


 TOC 

References

[1] Lassila, O. and R. Swick, "Resource Description Framework (RDF) Model and Syntax Specification", W3C Recommendation rdf-syntax, February 1999.
[2] Brickley, D. and R. Guha, "Resource Description Framework (RDF) Schema Specification 1.0", W3C Candidate Recommendation CR-rdf-schema, March 2000.
[3] Dawson, F. and Stenerson, D., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998 (TXT, HTML, XML).
[4] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999.
[5] Atarashi, R., Shimojo, T., Atarashi, Y., Miyake, S., Kitani, M., Baker, F. and M. Wasserman, "XML Configuration Architecture", draft-atarashi-xmlconf-architecture-00 (work in progress), October 2002.
[6] Brickley, D. and K. Sharp, "European Semantic Web Advanced Development", 2002.
[7] Matthews, B., "Rutherford Appleton Laboratory", June 2002.
[8] Brickley, D. and L. Miller, "Friend-of-a-friend (FOAF) RDF vocabulary.", 2002.
[9] Miller, L. and M. Arick, "iCalendar (ICAL) RDF vocabulary", 2002.
[10] Miller, L., "SWAD-Europe: Developer Workshop Report 2 - Semantic Web calendaring", 2002.
[11] Berners-Lee, T., "Cwm (closed world machine)", September 2002.
[12] De Roo, J., "Euler proof mechanism", December 2002.
[13] Klyne, G., "Notation3 query processor and report generator software", December 2002.
[14] Klyne, G., "RDF for little languages", December 2002.
 TOC 

Author's Address

  Graham Klyne
  Nine by Nine
  14 Chambrai Close
  Appleford
  Abingdon, Oxon OX14 4NT
  UK
Phone:  +44 1235 848491
Fax:  +44 1235 848562
EMail:  GK-SWAD-E@ninebynine.org
URI:  http://www.ninebynine.net/
 TOC 

Appendix A. Revision history

[[[Remove this section on final publication]]]

2002-12-03:
  • Document initially created.

2002-12-04:
  • Initial sketch of RDF vocabularies to use.

2002-12-12:
  • Revise vocabulary descriptions based on running code.
  • Add descriptions of rules and output file generation template.
  • Add initial draft of conclusions and lessons learned.

2002-12-15: