Send in your ideas. Deadline December 1, 2024
logo

Last update: 2021-01-13

Annual Report 2003 Stichting NLnet Labs

Independent lab for Internet infrastructure development

[PDF version of this report]

1. Introduction
2. Activities of Stichting NLnet Labs in 2003
2.1 Staff
2.2 The main projects
2.3 TestLab
2.4 Other projects
2.5 Collaboration with other organisations
2.6 Plans for 2004
2.7 Workshops, presentations and publications
2.8 More information
3. Organisation
4. Finances
4.1 Fiscal status
4.2 Administration
4.3 Income in 2003
4.4 Expenditure in 2003
4.5 Budget for 2004
Office: Kruislaan 419
1098 VA Amsterdam
The Netherlands
e-mail: info@nlnetlabs.nl
web: http://www.nlnetlabs.nl
KvK: Chamber of Commerce Amsterdam, nr 34126276

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.

2. Activities of Stichting NLnet Labs in 2003

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.

2.1 Staff

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.

2.2 The main projects

NLnet Labs focussed in 2003 on DNSSEC, NSD, IPv6, Fonkey, and the TestLab.

2.2.1 DNSSEC

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.

2.2.2 NSD

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.

2.2.3 IPv6

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.

2.3 TestLab

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.

2.4 Other projects

2.4.1 Fonkey

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.

2.4.2 A-A-P

A-A-P is a project by Bram Molenaar. A-A-P makes it easy to locate, download, build and install software.

This project was finalised (as an NLnet Labs project) in October 2003; in July 2003 version 1.0.0 was released. The project continues as an Open Source project.

For more information on A-A-P see http://www.a-a-p.org/

2.4.3 Atom-Based Routing

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.

For more information see http://www.caida.org/projects/routing/atoms/

2.5 Collaboration with other organisations

2.5.1 SIDN and CENtr

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.
  • TechSec - Discuss the technical aspects of Internet security technology.

2.6 Plans for 2004

2.6.1 DNSSEC

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.

2.6.2 NSD

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.

2.6.3 The IPv6 project

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.

2.6.4 Fonkey

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.

2.6.5 TestLab

With the availability of the TestLab together with a competent staff, it is expected that we will be doing more important testwork in 2004.

2.6.6 Software testing for other NLnet projects

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.

2.7 Workshops, presentations and publications

The following presentations, workshops and/or publications were given/produced by NLnet Labs in 2003:

Work in progress:

  • IETF Internet Draft: Unmanaged Networks IPv6 Transition Scenarios
    draft-ietf-v6ops-unman-scenarios-03.txt
  • IETF Internet Draft: Evaluation of Transition Mechanisms for Unmanaged Networks
    draft-ietf-v6ops-unmaneval-01.txt
  • IETF Internet Draft: Considerations for IPv6 Tunneling Solutions in Small End Sites
    draft-chown-v6ops-unmanaged-connectivity-00.txt
  • IETF Internet Draft: DNSSEC Resolver Interface to Applications
    draft-ietf-dnsop-resolver-application-interface-00.txt
  • IETF Internet Draft: DNSSEC operational Practices
    draft-ietf-dnsop-dnssec-operational-practices-00.txt
  • RFC 2535bis:
    • DNS Security Introduction and Requirements
    • Resource Records for DNS Security Extensions
    • Protocol Modifications for the DNS Security Extensions

2.8 More information

More information on past, current and planned projects can be found at: http://www.nlnetlabs.nl

3. Organisation

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.

4. Finances

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.

4.1 Fiscal status

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 (departmentRegistratie 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 (vennootschapsbelastingin 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).

4.2 Administration

The books of Stichting NLnet Labs are kept by the treasurer.

The salary administration has been contracted out to the Financial Management Solutions group of PricewaterhouseCoopers in Amsterdam. This group also prepares the salary tax forms.

PricewaterhouseCoopers Accountants has been charged with compiling and auditing Stichting NLnet Labs's Annual Accounts 2003. The accountancy report is a separate document with this Annual Report.

4.3 Income in 2003

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.

Summarizing the 2003 income:


 2003
actual
 2002
actual
Donations general 325.000 316.000
Donations for Fonkey 35.000 -
Donations for A-A-P project 49.409 52.247
Donations for Atom-Based Routing project 50.051 15.533
Consultancy income 41.648 10.496
Interest income 1.555
 1.400
Total 502.664 395.676

4.4 Expenditure in 2003

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


 2003
actual
 2002
actual
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.

4.5 Budget for 2004

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


 2004
budget
 2003
actual
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.

Project NLnet Labs

Navigate projects

Search