|Stichting NLnet Labs||Annual Report 2003|
1098 VA Amsterdam
|Chamber of Commerce||Amsterdam, nr 34126276|
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.
NLnet Labs focussed in 2003 on DNSSEC, NSD, IPv6, Fonkey, and the TestLab.
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:
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.
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.
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/
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/
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:
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.
With the availability of the TestLab together with a competent staff, it is expected that we will be doing more important testwork in 2004.
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.
The following presentations, workshops and/or publications were given/produced by NLnet Labs in 2003:
Work in progress:
More information on past, current and planned projects can be found at:
Stichting NLnet Labs was founded on December 28, 1999 by Stichting NLnet. Its Board consists of three members and has remained unchanged in 2003:
|Wytze van der Raay||treasurer|
Six Board meetings took place in the year 2003:
|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:
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).
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.
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 EUR 356.832. Based on this and the expected consultancy income, a grant was requested from Stichting NLnet for EUR 325.000 during 2003. Stichting NLnet has allocated these funds for 2003, to be received by NLnet Labs on a quarterly basis, EUR 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 EUR 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 EUR 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 EUR 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 EUR 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 EUR 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 EUR 1.555.
Summarizing the 2003 income:
|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|
The major expenditure categories of NLnet Labs in 2003 are summarised below:
|Atom-Based Routing project||50.051||15.533|
Thus total income in 2003 was slightly larger than expenditure; the positive result of EUR 26.474 has been used to strengthen the financial reserve somewhat. As a result, the financial reserve at the start of 2004 is EUR 54.734.
The provisional budget for 2004 as approved by the Board in its meeting on January 14, 2004, is as follows:
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 EUR 274.440. A request for four quarterly grants of EUR 68.500, thus for a total of EUR 274.000 in 2003, has been submitted to Stichting NLnet. Stichting NLnet has approved these grants on January 23, 2004.