Annual Report 2003 Stichting NLnet Labs

1. Introduction2. Activities of Stichting NLnet Labs in 20032.1 Staff2.2 The main projects2.3 TestLab2.4 Other projects2.5 Collaboration with other organisations2.6 Plans for 20042.7 Workshops, presentations and publications2.8 More information3. Organisation4. Finances4.1 Fiscal status4.2 Administration4.3 Income in 20034.4 Expenditure in 20034.5 Budget for 2004

1. Introduction

NLnet Labs was founded in 1999 by Stichting NLnet to develop,
implement, evaluate and promote new protocols and applications
for the Internet.

The NLnet Labs offices are located in the Amsterdam Science Park
(ASP) where traditionally most Internet development in The Netherlands
has taken place. The ASP is still very important for the Internet,
as it is the location of the Amsterdam Internet Exchange (AMS-IX),
in which vicinity many Internet companies can be found.

The goal of NLnet Labs is to contribute knowledge to the Internet.
This can be achieved by software development, but also by educating
people to develop software elsewhere. NLnet Labs' staff therefore
not only focuses on software development defined in projects,
but also on collaboration with other organisations. The budget
of NLnet labs is based on long term (15 years) investment for
development with a staff of five to six people.

Staff, projects and collaboration are the topics addressed in
this section.

NLnet Labs employed six people in 2003: Alexis Yushin (until
30 november), Miek Gieben, Erik Rozendaal, Ronald van der Pol,
Yuri Demchenko (from 1 March until 30 September), and Ted Lindgreen
(director) to work on the projects described in the next section.

The DNSSEC project started in 2000 with a study of the scaling
issues involved in deploying DNSSEC for large domains. This study
proved that DNSSEC scaled better (i.e. less loss of performance)
than previously feared by many. This resulted in a renewed interest
in DNSSEC.

In 2001 the focus was on deployment at TLDs, and a testbed where
DNSSEC was implemented in a secure shadow tree of .nl, called
.nl.nl, was set up. This work revealed a new scaling issue, namely
with respect to the administration of keys at registries. A new
record type "DS" (Delegation Signer) was proposed to
solve this issue.

In 2001 also another change to RFC 2535 was proposed: OptIn. This
proposal fundamentally changes the way DNSSEC will be used, as
it introduces partial security within a zone. This proposal did
not meet consensus in the IETF dnsext working group until mid
2003. At the 57th IETF (Vienna, July 13-18, 2003) it became clear
that OptIn would become either informational or experimental.
It was also clear that there was consensus to standardize the
DS proposal and some other minor issues in a new RFC with working
title RFC2535bis. We expect that the new RFC will be ready in
Q1 2004.

In 2003, NLnet Labs worked on two issues for DNSSEC:

2.2.1.1 A shadow .nl registry

After the .nl.nl experiment was completed in mid 2002, a new
experiment was started in collaboration with SIDN to gain hands-on
experience with running a real secure registry. In October 2003
a fully secure shadow registry for .nl was taken into production.
This registry ran completely synchronously with the real .nl registry,
with the only difference that it is fully secured and contains
DS records for the secured delegations. There are three nameservers,
one at SIDN, one at NLnet Labs, and one at the Swedish registry.
The .se registry is doing a similar experiment for which NLnet
Labs also runs a secondary.

The .nl experiment was closed on 28 December 2003, after we concluded
that there were no more showstoppers found in the proposal for
RFC2535bis. One of the main results of this experiment was that
a Registry must define a new contact person, the "zone-contact",
i.e. one or more people who manage and maintain the contents of
the zone file. Up to now most registries have three contacts:
the admin-c or the legal holder of the domainname, the tech-c
or the people who maintain the nameservers for a domain, and the
registrar, who intermediates between the registry and registrant.
With DNSSEC it is important to have a solid definition of who
keeps the zone-key to sign the zonefile. Since in practice this
can be anyone from the current admin-c, tech-c, or registrar,
an unambiguous, thus new contact is needed.

In order to achive the necessary cooperation with SIDN, which
is vital to keep both versions of the registry in sync, SIDN has
hired one NLnet developer (Miek Gieben) as a consultant for one
day per week. This started in September 2002 and ran until the
end of 2003.

2.2.1.2 A secure aware resolver

A secure aware resolver, capable of understanding the new
DS-record, is badly needed. In 2003 a perl version was made, but
this is not enough.

NSD is nameserver software aimed at usage on large and/or
important authoritative nameservers, such as the root nameservers
and TLDs. The idea to write this software came up at the RIPE
40 meeting in October 2001 in Prague, Czech Republic.

It was observed that all rootservers and most TLDs were converging
to use exactly the same software: the latest version of the BIND-8
software. This because the development of BIND-8 has stopped,
and both its successor, BIND-9, and all other alternatives are
not, or at least not yet, suitable for these nameservers. It was
generally felt that all rootservers using the same software was
an unacceptable risk.

During 2002, and until April 2003, Alexis Yushin wrote most of
the code of the initial versions. From May, Erik Rozendaal took
over the development. A rewrite of large portions of the code
was needed to implement DNSSEC in a clean way. This rewrite was
completed in 2003, and we are ready to release a stable DNSSEC
capable version of NSD as soon as RFC 2535bis becomes official.

During 2002, NSD was installed on one of the root nameservers
(k.root-servers.net). Later, it was also installed on h.root-servers.net,
so now two of the thirteen root nameservers run NSD. NSD runs
on a number of TLD nameservers as well, for instance on .nl and
.fr.

Three case studies of IPv6 enabled home networks were published
on the web site. They describe what was done to support IPv6 in
those networks.

A report about introducing IPv6 glue in the root zone was published
on the web site. This report was also presented at RIPE 46 in
Amsterdam. Furthermore, the report was used as input for advise
to ICANN about IPv6 support in the root zone.

An Internet Draft about IPv6 tunneling techniques in unmanaged
networks was written. This Draft served as input for general discussions
about tunneling within the V6OPS Working Group.

An Internet Draft about the problems of translation between IPv6
and IPv4 was written. This Draft was left to expire later in favour
of another Draft.

The long term analysis of the 6bone routing table was continued
in 2003. Graphs showing the number of IPv6 enabled ASNs, the number
of IPv6 routes and the IPv6 BGP announcements and withdraws are
published on the web site. The data presented is over the last
five years.

The work on two Internet Drafts for IPv6 in unmanaged networks
continued and these are close to becoming Informational or BCP
RFCs.

The collaboration with SURFnet on IPv6-enabled SOHO routers died
down because of a reorganisation within SURFnet.

In 2003 we installed the RIPE-NCC "DISTEL" testlab
at NLnet Labs. This testlab was designed by Daniel Karrenberg.
The current TestLab consists of 3 Athlon and one Alpha system.
They are connected both on a private network and on the Labs-LAN.
The TestLab was initially used to test NSD, but later also for
root server tests. These root server tests have played a large
role in the decision to provide IPv6 glue in the root zone.

The Fonkey project, which was previously called Donkey, aims
at setting up a KEY infrastructure apart from DNSSEC. Many projects
are waiting on DNSSEC to provide public keys but sofar DNSSEC
is stalling.

In 2003 the Fonkey prototype was further developed. In late 2003
Fonkey was partly integrated with a new AgentScape prototype from
the Vrije Universiteit/NLnet's IIDS group for use as a Location
Service, but this work has not been completed yet. Furthermore
a paper was written on the design of this integration. This paper
was submitted for AIMS'04 but was not complete enough to be accepted.

We employed Yuri Demchenko to explore other projects where Fonkey
could be deployed, and document the requirements. One of these
projects came from RIPE-NCC, and was in fact the trigger to start
with Fonkey. Unfortunately RIPE's needs were very specific, while
Fonkey aimed to be of much broader usability, and RIPE lost interest.
Also little interest was found at other project groups. Because
of this we now only focus on the VU collaboration with Fonkey.

The Atom-Based Routing project is carried out at CAIDA in
San Diego, under direction of k claffy, and in cooperation
with RIPE NCC and NLnet Labs. NLnet Labs sponsors RIPE NCC to
employ Patrick Verkaik for this work. This project tries to find
an answer to the ever increasing number of BGP route-prefixes.

This project was finalised in October 2003 as an NLnet Labs project,
but the final report was not available at that time yet. We expect
this report to be published in Q1 2004.

NLnet Labs has been co-operating with SIDN and CENtr on DNSSEC
since the very start of the project in early 2000. It is planned
that this co-operation will continue in 2004, and further until
DNSSEC is implemented under .nl and other ccTLDs.

NLnet Labs works together with RIPE-NCC on the DNSSEC and the
NSD projects. Ted Lindgreen chairs a RIPE working group (the TechSec
group).

The IPv6 SOHO router has lead to collaboration with SURFnet. However,
SURFnet lost interest due to internal reorganisations during 2003.

The Atom-Based Routing project was a collaboration with RIPE-NCC
and CAIDA.

In 2002 NLnet Labs started collaboration with NLnet's IIDS Research
Group at the VU. The focus of this collaboration is on scalability
issues for directory services and security/trust in large scale
systems. One NLnet employee, Erik, works one day a week at the
VU. The main topic of his work is to use Fonkey to implement a
location server in Agent Scape.

Furthermore NLnet Labs actively participates in the following
IETF working groups:

dnsext - DNS Extensions

ipv6 - IP Version 6 Working Group

v6ops - IPv6 Operations

zeroconf - Zero Configuration Networking

dsnop - Domain Name System Operations

rtgarea - routing area

And in the following RIPE working groups:

D N S - Domain Name System questions and issues.

I P v 6 - IP version 6 related issues and questions.

Routing - Issues dealing with routing architecture for the
European Internet.

In 2004 the focus for DNSSEC will be on two subjects: the
resolver and the signing procedure.

For the work on the aware resolver we plan to add manpower to
this subject. The problem will be attacked in three steps, because
the one-step designs so far have failed to produce anything usable.

First a basic recursive resolver plus an independent validator
will be written. The aim is to produce a working prototype of
a validator, using its own recursive resolver. With that we expect
to encounter lots of problems with the various existing DNS server
implementations (secure aware or not). Hopefully we can then find
a way to deal correctly with RFC-compliant DNS servers, without
breaking too much backwards compatibility with other existing
DNS servers.

The next step will be to combine and optimise (read: add caching
and such) the validator and the resolver.

The third step will be to produce a library as a plug-in replacement
for the standard libc routines "getaddrinfo" and friends.
This way we can easily add secure namelookup to many applications.

We plan to investigate whether crypto-tokens (a USB key containing
a crypto chip) can be used in the signing procedure of DNSSEC
zones. This will ease the problem of key handling, especially
at medium to large organisations.

Early 2004, NSD with DNSSEC-RFC 2535bis support will be released.
NLnet Labs has organised a workshop with ISC and RIPE in January
to check the compatibility of both 2535bis-aware pre-releases
of NSD2 and BIND9. Further work on NSD will be primarily maintenance.

There is a renewed interest within the IETF on separating
the identifier from the locator (usually called identifier/locator
separation). Today nodes on the internet work with IPv4 and IPv6
addresses. These addresses have two functions. One function is
to identify another node. Applications use the address to identify
another application running on another node. The other function
of a traditional address is the location in the network topology.
The routing system uses the address to route a packet to the destination.

Many think that it is better to separate these two functions.
Applications should use one stable identifier to communicate with
each other. Each node should additionally have one or more (in
the case of multihoming) locators. These locators may change frequently
in the case of e.g. mobility, but the identifier always stays
the same.

The multi6 (multihoming in IPv6) IETF working group is looking
at this identifier/locator split and has produced a couple of
drafts with proposals. Once one of the proposals is chosen and
is being standardized, NLnet Labs will most likely write one of
the reference implementations.

Work on Fonkey will focus on two areas. The first is to complete
the paper on the design of Fonkey as a Location Service. This
will require developing a simulation to test the scalability of
the design. The second area is to develop a new, complete implementation
based on a peer-to-peer distributed hash tables and integrate
this in AgentScape.

On request of the the NLnet foundation, NLnet Labs will test
released and pre-released software from other NLnet projects,
provided that NLnet Labs has the necessary skills and knowledge
in house. It is expected that the necessary manpower can be scheduled
on an ad-hoc basis.

Stichting NLnet Labs was founded on December 28, 1999 by Stichting
NLnet. Its Board consists of three members and has remained unchanged
in 2003:

name

function

Teus Hagen

chairman

Frances Brazier

secretary

Wytze van der Raay

treasurer

Six Board meetings took place in the year 2003:

date

place

January 22, 2003

Amerongen

March 26, 2003

Amerongen

May 7, 2003

Amerongen

July 3, 2003

Amsterdam

October 1, 2003

Amerongen

November 26, 2003

Amerongen

Ted Lindgreen is the managing director of Stichting NLnet Labs.
He continues to be responsible for the daily management of all
activities of the Open Source network software development laboratory,
including development of strategies and plans for new activities.

Five staff members worked for NLnet Labs in 2003:

Miek Gieben, from June 1, 2000 (still employed)

Alexis Yushin, from April 16, 2001 until December 1, 2003

Erik Rozendaal, from February 15, 2002 (still employed)

Ronald van der Pol, from June 1, 2002 (still employed)

Yuri Demchenko, from March 1, 2003 until October 1, 2003

In addition, Bram Moolenaar was employed for the duration of the
A-A-P project (March 1, 2002 to September 30, 2003).

NLnet Labs sponsored RIPE NCC to employ Patrick Verkaik. Patrick
worked at CAIDA in San Diego on the Atom-Based Routing project,
which started in September 2002 and was finalised in November
2003.

NLnet Labs rents office space in the Matrix I building in the
Amsterdam Science Park in Amsterdam, very close to one of the
most important internet interconnection centres in Europe.

Stichting NLnet Labs primarily finances its projects and activities
from grants obtained from its parent organisation Stichting NLnet.
In addition, income may be obtained by providing Open Source internet
based consultancy and/or programming services to third parties.
A contract for the support of DNSSEC at SIDN, the Dutch top-level
domain registry, was a source of additional income in the latter
category.

Stichting NLnet Labs has been set up as a non-profit organisation,
with general benefit objectives. Its request to be classified
as an entity with general benefit objectives within the meaning
of the Successiewet 1956 (article 24 sub 4) has been granted by
the Dutch tax office (department Registratie en Successie)
on February 2, 2000. Due to this status, Stichting NLnet Labs
can receive grants from Stichting NLnet (with the same general
benefit objective classification) without considerable tax consequences.

Because Stichting NLnet Labs may provide consultancy and/or development
services based on its Open Source and internet expertise, to commercial
third parties, it has also applied for registration as a Value
Added Tax-registered entity. This registration has been provisionally
provided by the tax inspection on March 15, 2000.

Based on its non-profit status, Stichting NLnet Labs does not
expect to become subject to company tax (vennootschapsbelasting
in Dutch).

Since Stichting NLnet Labs employs staff, it has been registered
for Social Security insurances with UWV GAK, in the sector commercial
services II (BV 25).

At the end of 2002, a budget was drawn up for the expected
staffing level and activities of NLnet Labs during the year 2003,
with a total of €356.832. Based on this and the expected consultancy
income, a grant was requested from Stichting NLnet for €325.000
during 2003. Stichting NLnet has allocated these funds for 2003,
to be received by NLnet Labs on a quarterly basis, €81.250
per quarter.

This budget did not take into account the additional costs which
would be incurred by embarking on the Fonkey development project.
In February 2003, the go-decision for this project was taken,
and an additional subsidy of €35.000 was requested and obtained
from Stichting NLnet to cover the extra staffing costs.

In March 2002 NLnet Labs agreed to run Stichting NLnet's A-A-P
development project with the understanding that all additional
staff and other costs attributable to A-A-P would be covered by
an additional grant from Stichting NLnet. A total of €49.409
was received in 2003 for this purpose.

In September 2002, NLnet Labs requested an additional grant from
Stichting NLnet for its Atom-Based Routing project, to be performed
in cooperation with RIPE NCC in Amsterdam and CAIDA in San Diego,
between October 2002 and November 2003. A grant for a total of
€50.051 was received in 2003 to cover the additional costs
attributable to Atom-Based Routing in 2003.

The net result of that is that Stichting NLnet Labs received a
total of €459.461 from Stichting NLnet during 2003.

Also, the one-year DNSSEC consulting contract with SIDN which
started in October 2002, was extended with 3 months to the end
of 2003, bringing in a total income of €41.648 in 2003.

The only other source of income during 2003 was interest derived
from a savings account used to deposit funds temporarily. This
amounted to €1.555.

The major expenditure categories of NLnet Labs in 2003 are
summarised below:

2003actual

2002actual

Staff

364.002

300.283

Atom-Based Routing project

50.051

15.533

IODEF project

-

1.452

Housing

20.615

17.213

Depreciation

5.067

6.331

Other costs

36.454

36.520

Total

476.190

377.332

Thus total income in 2003 was slightly larger than expenditure;
the positive result of €26.474 has been used to strengthen
the financial reserve somewhat. As a result, the financial reserve
at the start of 2004 is €54.734.

The provisional budget for 2004 as approved by the Board in
its meeting on January 14, 2004, is as follows:

2004budget

2003actual

Staff

239.400

364.002

Housing

22.800

20.615

Depreciation

5.640

5.067

Other costs

31.500

36.454

Total

299.340

476.190

The 2004 budget looks considerably tighter than the realisation
for 2003. This is because it is based on the current somewhat
reduced staffing level. NLnet Labs intends to expand its staff,
but cannot predict when it will be able to realise this. It has
been agreed with Stichting NLnet that additional funds will be
made available by NLnet when new staff has been contracted.

Since NLnet Labs expects to receive some income from consulting
activities, the projected deficit for 2004 comes down to €274.440.
A request for four quarterly grants of €68.500, thus for a
total of €274.000 in 2003, has been submitted to Stichting
NLnet. Stichting NLnet has approved these grants on January 23,
2004.