Ian Darwin,
Secure Internet Firewalls With OpenBSD (tutorial)

This half-day talk will cover the details of setting up a secure firewall using OpenBSD. After an overview of OpenBSD installation and administration and why it's considered secure, the presenter will cover standard services, network security, firewall configuration, packet filtering, routing, bridging, Kerberos, SSH, VPN using manual and automatic keying, address hiding with NAT, logging, intrustion detection, and ongoing maintainance. OpenBSD has its own packet filtering with many features including packet sanitization, which will be covered in depth.
The talk is aimed at people with any UNIX/Linux (not necessarily BSD) administration experience, and who are e.g., comfortable with vi/emacs for editing config files, not dependant upon some window-based tool :-). The details of the presentation will be adjusted to the audience in attendance, not vice versa.

Hans van de Looy and Brenda Langedijk,
Using the FreeBSD ports collection to perform network forensic analysis (tutorial)

This tutorial will be a real hands-on interactive do-it-yourself session. So those of you who do not want to really participate and train your skills, stay at home or (better still) join another tutorial.

Poul-Henning Kamp,
FreeBSD GEOM (tutorial)

The new DARPA sponsored GEOM subsystem adds pluggability and modularity to disk I/O manipulations. This for the first time provides an UNIX operation system with an modular and extensible facility for manipulating disk-access requests. Amongst the things which can be seamlessly integrated using GEOM are disk-partitioning, RAID facilities, cryptographic protection. This tutorial will provide an overview of the architecture and implementation, as well as the tradeoffs and choices made.

Paul Richards,
Device Drivers (tutorial)

No abstract submitted.

Mike Karels,
keynote speaker

BSD: Past, Present and Future

Eilko Bos,
Virtual Private Networks using FreeBSD - a casestudy

People want to, for more than one reason, work at home, sharing information from the corporate network. Companies want to link their networks together over the internet. But nobody wants their private traffic to be readable on the internet. Various solutions have been made, and one of them is IPSec. IPSec stands for 'IP Security'. It provides authentication and encryption of networktraffic. But there's more to secure your data. It makes no sense to encrypt your data and have your endpoint compromised. Thus a firewall is needed as well. On both ends. And some more issues to cover.

This little piece of paper shows us how FreeBSD can help us with this. All- though there are some differences between the various BSD's, it will reasonly apply to Open- and NetBSD as well.

Philipp Bühler and Henning Brauer,
Running and tuning of OpenBSD network servers in a production environment

Heavily loaded network servers can experience resource exhaustion. At best, resource exhaustion will slow server response, but left uncorrected, it can result in a crash of the server.
In order to understand and prevent such situations, a knowledge of the internal operation of the operating system is required, especially how memory management works.
This paper will provide an understanding of the memory management of OpenBSD, how to monitor the current status of the system, why crashes occur and how to prevent them.

Audience:
Experienced network administrators and interested kernel hackers.

Required Skills:
Good knowledge in the TCP/IP suite, basic understandig of memory management under UNIX and basic understandig of an UNIX kernel.

Pim Buurman,
Xperteyes - keeping your system under control

How would life change if you had every morning some lists of points where your computers would fail the criteria set by the system administrators, their boss, the EDP-auditor and the software manufacturers. So if you had yesterday installed a powerful tool for managing your network, today you would notice that the install log (owned by root) has mode 07777. Or if a user leaves the company, a check is performed that his account is also removed from the database, and his name is removed from the cron users.

With this new tool, xperteyes, this is easily possible. In some minutes all relevant properties of many objects are read and stored. In a separate step (which may be performed on another machine) all these properties can be checked through a configuration script, which will take also a few minutes. Naturally, a graphical interface is available for viewing the properties, the checks and the results. The results can also be viewed in HTML. For the more daring system administrators it is possible to (automatically) repair some of the properties.

The tool is currently running on Mac OS X, Linux and Windows, implemented in Python with some extensions in C. The main object's properties that are collected are:

• the properties of files, directories and other objects in the file system
• /etc/passwd, /etc/group, etc.
• the windows registry and the windows user/group/machine database
• the Mac OS netinfo tree

But, if you want to check later on e.g. file magic, such extensions can be implemented in less than one hour, depending on the amount of code that can be reused.

The checks that may be performed are partly predefined. These are simple checks like checking that a single property has a predefined value, or its value belongs to some range. More complex checks, like is_hardlink or uid_valid are also available. And comparing objects collected at different times or from different systems is possible. But it is likely that these checks are not enough. If you add the file magic to your object's properties, you want to check it. Well, you can easily define new checks yourself, once you have formulated them (that's the difficult part).

Some areas where this tool can be deployed are:

• Checking, initially and daily, the configuration of one system
• Checking the effect of (un)installing some packages
• Keeping two systems "identical" (clustering)

Alistair Crooks,
Package views - a more flexible infrastructure for third-party software

Firstly, conventional systems for installation of third party software, including FreeBSD's ports system, NetBSD's pkgsrc, and OpenBSD's ports system, are analysed and compared. In addition, other approaches and infrastructure layouts within the industry are examined.

One of the main problems faced by users of the various systems is the means by which multiple versions of a package, or packages which "conflict" with each other, can be installed at the same time.

Following that, a new system is proposed, which has been implemented in NetBSD's pkgsrc implementation:

• to allow any number of different versions of packages to co-exist at any one time
• to provide support for dynamic packing lists
• to allow the testing of different versions of packages on a single machine at any one time
• to allow more dynamic conflict detection at install time
• whilst continuing to use the existing pkg_install(1) tools

The new system is laid out in detail, including the practical aspects of managing a large number of third party packages across a number of different Operating Systems, all within the same pkgsrc framework.

The advantages and disadvantages of the new infrastructure are discussed, as are the lessons learned from its deployment.

Hubert Feyrer,
Clustering NetBSD

In last year's Regensburg city marathon, each of the 5000+ runners was able to view a personal video of him/herself reaching the goal. A cluster of 45 machines running the NetBSD operating system turned 5 hours of video material into single mpeg snippets.

Topics discussed in the presentation are:

• deployment of the operating system and applicationi software on the cluster machines
• details on the tasks performed by the cluster - decomposing the input mpeg stream(s), reassembling images for each runner based on the time he went through the goal
• experiences gained during the cluster project - application based, plus lots of graphsand images from monitoring the cluster
• facts & numbers - lots of them :)

Before describing how NetBSD uses cross compilers to build the system, I will discuss more traditional users of cross compilers, which largely is the embedded software group (I will focus mainly on the ports of the FSF tools.) NetBSD is changing, or perhaps only adding to this, as a significant portion of commercial NetBSD users are using embedded configurations.

A large majority of NetBSD 1.6 snapshots and releases will be built via cross compiled methods, theoretically buildable on nearly any modern platform, using a simple-to-use cross-build system, nominally called "./build.sh", that has been developed by the NetBSD project, to make it possible to build NetBSD releases with a single, simple command. I will discuss the pros and cons of this approach, many of which are true of every cross compile environment. I will compare the NetBSD 1.5 and NetBSD 1.6 release processes, explaining the autobuild process used by the 1.6 release team to build virtually daily snapshots of all cross buildable ports.

Alan Horn,
Monitoring the world with NetBSD

There are many papers and publications on monitoring your network and systems. Most of the time they fail to present a monitoring strategy that is both practical and general. Whilst I don't wish to restate what is already generally known, I do feel that most sites are lacking in a really solid monitoring framework.

At my current site and at previous locations, I have used NetBSD along with a range of free tools to build a customized system for proactive notifications and failure management. I would like to talk about the evolution of this system over the years, the decisions I took and why I took them, ending with a look at the current deployment and some thoughts for the future.

My aim is to try and present advice that folks can take back and drop into place at their sites with a very minimum implementation time and be getting a meaningful return very quickly. I want to distill a lot of different documentation into a set of notes that people can use almost as a set of design philisophies along with the practicum.

Poul-Henning Kamp,
Timecounters: Efficient and precise timekeeping in SMP kernels

The FreeBSD timecounters are an architecture-independt implementation of a binary timescale using whatever hardware support is at hand. The timecounter timescale converts to other time representations using cheap multiply and shift operations and provides for sufficient precision and resolution to cater for all future needs.. The math and implementation will be described, including the features which support NTP PLL/FLL time synchronization, lockless multi-cpu operation and on-the-fly change in hardware support.

Brad Knowles,
MTA Performance on *BSD: Sendmail, Postfix and Exim on (Free|Net)BSD and MacOS X

Three popular SMTP Message Transfer Agents (MTAs) will be tested on three different implementations of BSD Unix. Standard performance tuning enhancements will be made and benchmarked for comparison on all three platforms. Details regarding hardware, OS, software, and testing configurations will be provided, including selections of configuration files, selections from sample test runs, etc....

The MTAs to be tested are sendmail (open source, see <http://www.sendmail.org/>), postfix (see <http://www.postfix.org/>), and Exim (see <http://www.exim.org/>). The OS platforms to be tested are FreeBSD (see <http://www.freebsd.org/>), NetBSD (see <http://www.netbsd.org/>), and MacOS X (see <http://www.apple.com/macosx/>). The testing tools will most likely include SPECmail2001 (see <http://www.spec.org/osg/mail2001/>), Postal (see <http://www.coker.com.au/postal/>), mstone (see <http://www.mozilla.org/projects/mstone/>), and smtpsink/smtpstone (from postfix, see <http://www.postfix.org/>).

Complete charts and graphs will be generated, and conclusions regarding the relative performance of each MTA relative to each OS will be presented. Directions for future testing will also be presented. Note that no testing of anti-spam or anti-virus features will be attempted.

Also note that different machines will be used for each OS, and therefore test results across OSes are not likely to be comparable.

Finally, note that OpenBSD is not being tested, partly for reasons of expediency and partly because the author believes that it is not likely to perform radically different than NetBSD in this application.

Albert Mietus,
Securing syslogd on FreeBSD

For its complete life span, FreeBSD, it has used the de-facto standard of Logging: syslog. The syslog concept is clear, flexible and sound. And, as I may say, FreeBSD implementation is old, but alive. Recently however, the syslog-protocol is formally defined in RF3164. An IETF has done so, to be able to define some security extensions on top of it. Two extensions exist, on paper: syslog-sign and syslog-reliable. To update FreeBSD implementation to this standard, and to implement the security extensions is work in progress.

Although the FreeBSD implementation of syslog(d) has more security-options then most commercial counterparts, faking syslog, as it is based on UDP, is simple. Several kind of attacks are know; e.g. replaying normal system messages, after it is taken down by a hacker. With syslog-sign, a digital signature is calculated of each message. And by sending a set of those signatures as one normal syslog message afterwards, syslog-sign can detect and signal most attacks. Even when somebody does change the logfiles on disk it is impossible to change them unnoticed, as the signatues befome false. Furthermore, I would like to emphasise the possibility of intermixing it with other/historical syslog implementations! And, as FreeBSD has always been a secure platform which can bridge with other systems, implementing syslog-sign will keep FreeBSD on the leading edge.

The author has used FreeBSD's implementation of syslog, to assure the standard indeed describes "the actual average protocol on all NIX'en". And has started a project to updating FreeBSD implementation, to make a 100% match possible. Based on that, several security enhancements will be implemented soon. The design and implementation of syslog-sign will be presented. As are others extensions, like a kerberos'ed version of syslog which is under study.

By implementing security-enhancements that are based on standards, instead of just changing the code, will improve the functionally of syslog and make it secure. But it also helps FreeBSD to continue the history of BSD-Unix. It does follow the standard, or it makes it. When FreeBSD adopts the security-enhanced syslog protocols quickly, it's implementation of syslog will continue BSD's preferred method of logging for another decade, or more.

Marco Molteni,
Using SCTP with Partial Reliability for MPEG-4 Multimedia Streaming

SCTP (Stream Control Transmission Protocol) [1,2], is a new IP transport protocol. It is reliable and connection-oriented as TCP, but has a set of new features that make it well suited for a wide class of applications, among them multimedia streaming. SCTP is record-oriented, providing built-in framing capabilities, and can multiplex multiple data streams into one connection, thus avoiding head-of-line blocking and providing a natural framework for multi-streamed systems like MPEG-4. It can provide ordered or unordered delivery. Further, a sender that implements Partial Reliability SCTP (PR-SCTP) can optionally choose the retransmission behavior on a per packet basis, in a continuos spectrum from TCP-like reliability with multiple retransmissions to UDP-like unreliability with no retransmission at all. In any case PR-SCTP retains all the benefits of SCTP: TCP-friendly congestion control and congestion avoidance, plus multi-homing fail-over capabilities.

The MPEG-4 standard is becoming a popular format for streaming multimedia on the Internet. MPEG-4 encodes the bitstream in groups of different frame types (I, P and B-frames), where the I-frame is independent, while the P and B-frames depend on the I-frame in the group. This means that loosing an I-frame (for example due to network congestion) forces the player to skip to the next frame group, with a noticeable worsening of the video quality. The transport protocol utilized by MPEG is RTP, which in turn is layered on top of UDP. RTP, being concerned with real-time traffic like multimedia streaming, does not provide reliable delivery.

Lately an implementation of SCTP has been imported in the IPv6/IPsec stack developed by KAME, providing kernel-level SCTP for all *BSD flavours [4].

This paper describes our work on FreeBSD to modify the open source MPEG-4 streamer and player found in MPEG4IP [5] to utilize PR-SCTP as transport instead of RTP/UDP, enforcing differentiated Partial Reliability per frame type. Various congestion scenarios show the improved playout quality of the client player, due to the increment of the number of I-frames that PR-SCTP allows to salvage from congestion.

[1] RFC 2960.
[2] draft-stewart-tsvwg-prsctp-00.txt
[3] http://www.sctp.org/
[4] http://www.mpeg4ip.net/

Bram Moolenaar,
All For One Port, One Port For All

The BSD systems each offer a different ports system. FreeBSD has the largest number of ports, OpenBSD ports provide a few extra features and NetBSD uses pkgsrc. Even though these ports systems originate from the same root, enough changes have been included to make them incompatible. The result is that a port has to be written and maintained for each BSD variant. The number of ports available greatly depends on the willingness of someone to create and maintain a port while a lot of work is repeated over and over again by the different maintainers. Obviously this is an unwanted situation.

One serious attempt has been made to reunite the ports systems: OpenPackages. Unfortunately, this project has stalled. There are several reasons why this route is very unlikely to succeed. The main one is that none of the BSD distributions wants to switch to a different system that suddenly makes all their existing ports unusable. Political and personal preferences add enough controversy to make any attempt at merging fail.

An alternative is to introduce a new system that exists next to the traditional ports systems. This provides the possibility for a gradual shift towards a better solution. One by one the ports can be transferred to this new system. There is no risc of making existing ports obsolete. Each maintainer is free to stick with the traditional system or choose to start using the new one, with the advantage of providing the port for all BSD systems at once.

The A-A-P project is providing this solution. A-A-P uses a recipe that is similar to the structure of a makefile, but much more powerful and flexible. A recipe is easier to understand than the tricks a port includes to use "make" for something it wasn't designed for. One of the strong advantages of A-A-P is that it handles the details of the packaging system. This is important, because many developers have expressed they are struggling with packaging their application. A-A-P takes care of downloading required files and tools, thereby avoiding the need to edit a script and run "cvsup". This is quicker and more reliable. Many ports done with A-A-P will also work on Linux and other Unix-like systems. Further advantages of using A-A-P for ports will be explained, while the disadvantages and potholes will not be concealed.

www.a-a-p.org

Riccardo Scandariato,
Advanced VPN support on FreeBSD systems

Currently, the VPN support offered by FreeBSD is quite limited: it provides a way to establish tunnels but it does not consider the problems of multiple VPNs concurrently deployed on the same machine. Our implementation enables the provisioning of VPN services on FreeBSD by extending its routing capabilities. Primarily, our implementation provides support for multiple IP routing tables (one for each VPN) in order to avoid conflicts between overlapping address spaces of different VPNs.
User-space programs (route, zebra, etc) can select the proper instance when accessing/updating a routing table through a modified routing sockets interface. At the kernel level, the different VPN flows are identified on per-interface basis. Once a packet is recognized as belonging to a given VPN, the forwarding routine selects the proper routing table to look up. We also modified several user-level applications to allow the exploitation of the new routing infrastructure, such as "route", "netstat", "zebra", and "ifconfig".

Dag-Erling Smørgrav,
Authentication in FreeBSD 5.0

Over the past year, support for advanced user authentication in FreeBSD has grown considerably through the systematic integration of PAM in almost all authentication-related utilities. Administrators can now choose from a wide variety of both software- and hardware- based authentication methods for both local and remote access. In the course of this presentation, we will discuss and demonstrate a selection of these methods and the ways in which they can be put to fruitful use.

Ignatios Souvatzis,
A shared write-protected NFS root file system for a cluster of diskless machines

Managing three diskless network clients can be done manually. Manually managing ten is still possible, but tedious. Manually managing hundreds is close to impossible.

When we got ten disk- (and head-)less network computers of a new type that we wanted to use as computing nodes for a parallel virtual machine for a practical course, I decided to set them up with a shared root file system.

However, a BSD root file system has to be unique and writable for every client machine for a couple of reasons (for example to write log files, create communication sockets for some daemons, set device node ownership at login and logout and change timestamps), so that a single writable shared root file system does not work.

As an alternate solution, I placed most writable directories onto (virtual) memory file systems. The program area and configuration files need only to be exported by the server for read only access. This way, the system programs, system libraries, and the configuration are protected against malicious users, even if they should gain root privileges on the client machine.

This presentation elaborates on the problems I encountered and the solutions I implemented, using stock NetBSD 1.5 as the client operating system, with just a small script and a few configuration lines added.

Finally, I compare my solution to different possibility, namely using a kernel embedded root file system.

David Sugar,
Using BSD for current and next generation voice telephonyservices

This presentation will cover how to use GNU Bayonne with BSD related operating systems, including particularly FreeBSD and NetBSD, which are what I am most familiar with. A presentation of issues related to telephony drivers and voice telephony hardware support for BSD and what is needed to make voice telephony services work under BSD will be provided.

During this presentation I will introduce the telephony application server of the GNU Project, "GNU Bayonne". This presentation will cover what GNU Bayonne is and how it fits into the overall strategy of enterprise and carrier class telephony solutions for current and next generation IP based telephone networks using free software running on free operating systems, such as xBSD systems, GNU/Linux, etc.

GNU Bayonne is composed of three servers and each of these (Bayonne, Olorin, and Babylon) will be discussed in detail, including their architecture and how to configure, operate, and create applications for GNU Bayonne servers to produce real-world telephony solutions for xBSD operating systems. The scripting language of GNU Bayonne will be covered, as well as how to integrate GNU Bayonne servers with traditional scripting languages such as tcl, Perl, Python, and Guile.

GNU Bayonne will also be demonstrated live running under FreeBSD (4.5) as part of this presentation. Examples and scripted applications used for real world applications people can deploy using GNU Bayonne under xBSD, such as voice mail and debit calling, will also be demonstrated.

Valeriy Ushakov,
Porting NetBSD to JavaStation-NC

This paper summarizes experience in porting NetBSD to JavaStation-NC, a network computer class machine built on the microSPARC-IIep processor. microSPARC-IIep is a sun4m with an integrated PCI controller. This makes it unique amongst sparc32 systems as other sun4c and sun4m models are SBus based. It is sufficiently similar to sun4m to reuse a lot of the existing code and sufficiently different to require a non-trivial porting effort. Generic and flexible machine-independent infrastructure and drivers provided by NetBSD were crucial to completing the port in short time despite the author's lack of any previous experience with NetBSD kernel internals.

Low-level support for CPU timers, interrupt related code and the like was implemented. Existing memory management code for sun4m was directly applicable. OpenFirmware support in the kernel and the boot loader, already borrowed from the sparc64 port but never tested, was completed. After machine-dependent parts of PCI framework were implemented, the driver for Happy Meal Ethernet was available for free. EBus support was borrowed from the sparc64 port, though differences in OpenFirmware prevented sharing of the EBus driver proper, but sparc and sparc64 can share drivers' EBus attachment code. The driver for CS4231 audio was reworked to support EBus attachment and is shared with sparc64.

Existing sparc framebuffer, keyboard and mouse drivers don't support the NetBSD machine-independent Workstation Console subsystem yet, but for the JavaStation-NC with its PS/2 keyboard and mouse using Workstation Console code was a natural choice, only the framebuffer driver had to be written. A simple driver for the InteGraphics Systems IGA1682 video card was developed and the plan is to support the CyberPro2010 card in this driver as well, thus providing a framebuffer driver for NetBSD/netwinder.

More work on the IGS driver is required to support acceleration and other models of InteGraphics cards. The Xigs server from XFree86 that currently supports only CyberPro 5050 seems like an ideal starting point for X support, though no work has been done yet.

Support for other microSPARC-IIep based systems would be nice, but requires access to the hardware. Besides several esoteric JavaStation prototypes the other widely available machine based on this processor is the CP1200 Compact PCI board. The same processor is also used in the SunRay appliance, though feasibility of SunRay support is questionable due to firmware issues and extremely small memory.

Gerald Wilson,
MacOS X on a budget

Many BSD users may have an interest in Mac OS X, but cannot justify buying a new Macintosh computer. They need a solution for a tight budget.

The presenter has previously demonstrated Mac OS X running on a home-built system, constructed mostly from old parts, with a total parts cost of EUR 600. The presenter has built several such systems, including a server which cost EUR 300 in parts. While it is not difficult to create a Mac OS X installation on a system not supported by Apple, there are numerous traps and gotchas to avoid.

This session describes the process of creating a Mac OS X system on a budget:

• What processors and motherboards are supported?
• What disk configurations are needed?
• Which peripherals work and which don't?
• What software is needed for unsupported systems?
• How much will it cost?
• Which second-hand systems give best results?

... and so on.

Marko Zec,
FreeBSD Network stack virtualization

General-purpose operating systems, such as UNIX variants and clones, traditionally maintain a single instance of each supported network protocol family within the kernel network stack. However, the capability of simultaneously supporting multiple independent instances of network stack or protocol suite can be highly desirable in many applications, such as VPN provisioning, virtual hosting or network simulation.

This session will provide an overview of design, implementation and performance aspects of an experimental framework for FreeBSD network stack virtualization. It will be explained how various parts of existing kernel code were extended to support grouping of network interfaces and user processes in isolated entities called virtual images. Further, it will be described how basic CPU resource usage scheduling and accounting on per virtual image basis was implemented, and finally, the methods for managing and monitoring the virtualized kernel infrastructure will be presented.

As the virtualization framework was implemented entirely within the kernel while retaining the complete API/ABI compatibility with the existing userland binaries, this session will be especially interesting for kernel hackers. However, system administrators will also have the opportunity to learn about a new approach for partitioning system resources, particularly on the network layer.