Open Student Projects / Internships
NLnet Labs offers internships for master (MSc.) and bachelor (BSc.) students. Enthusiast students are invited to contact us at firstname.lastname@example.org.
Master projects typically have a duration of 6 months (36 ECTS) and bachelor projects run for 3-5 months (18 ECTS). Interested students can apply for one of the projects below, or propose interesting project topics related with Internet technology and open standards.
The DNS Security Extensions (DNSSEC) provide data integrity and data origin authentication to the DNS. This requires DNS zones to be signed and recursive name servers to validate DNS responses (validator). Registries have started incentive programs, causing to boost the deployment of DNSSEC at the authoritative side. Unfortunately, there are zones that become bogus over time, for example due to signature expiration or domain transfer. This will cause time outs for the end customer, leading to service providers turning off DNSSEC validation again.
This project focuses more on software development than on research. You will be implementing a validator trust network.
For a validator it is near impossible to determine the reason why a response is Bogus. But if other validators also consider this response to be Bogus, it is less likely to be an attack and more likely to be a operator error. In such a case, a validator may decide to accept the response, despite its security status, and provide the service to the end customer. Security is dismissed for this particular zone, but DNSSEC validation for all other zones is unaffected. It is believed that such a validator trust network will ease and stimulate DNSSEC deployment.
In a paper by Radia Perlman and Charlie Kaufman , a hierarchical model for networks with Byzantine robustness is presented. This model extends previous work on network protocols resilient to Byzantine failures, that guarantee that nodes A and B can communicate, provided that at least one honest path connects them. The hierarchical model scales to large networks and additionally to guaranteed delivery of packets with some fair bandwidth, it also has the ability to limit the number of simultaneous sources it is receiving from and limit receipt of traffic to the rate at which the destination is capable to process.
In the hierarchical network model with Byzantine robustness, management of the switch/router resources is required to provide the guarantees of packet delivery and traffic rate limit on a per-flow basis. This flow resource management is important to achieve both the above defined guarantees and the scalability of the model to large networks.
To assess the scalability behavior, and the packet delivery and rate limiting guarantees, a simulation model of the hierarchical network with Byzantine robustness (HNBR) can be developed. With this simulation model different strategies can be evaluated, for example using metrics like efficiency and effectiveness, the scalability of the approach for different network sizes and topologies (network hierarchies), etc.
In the project we aim for a conference/journal publication in collaboration with Radia Perlman. This of course, given the obtained project results and analysis.
 Radia Perlman and Charlie Kaufman, "Hierarchical Networks with Byzantine Robustness", COMSNETS 2011.
Currently, we are in a situation where the network tries to keep packets in order. Although out-of-order packet receipt shouldn't be a problem for IP layer 3 protocols, e.g., TCP could handle this, bad performance or actually failure (?) can be a result. Still for performance, we want to spread traffic among lots of paths. There are various strategies for keeping packets in order over parallel paths. One of the more successful approaches identifies (TCP) flows and switches forward packets within a flow to the same port interface.
Flow-based forwarding in switches/routers is based on (destination, source, protocol type, TCP ports) tuples in the forwarding table. There is a claim that for better spreading of traffic load, a central entity knows what all the flows are, such that it can carefully place them. However, given the highly dynamic behavior of traffic volumes, it seems that switches are in a better position to load-split traffic than a central fabric manager. The switch can split path based on local queues and congestion, and can rehash the flows to spread the load.
To evaluate, compare, and understand the traffic utilization for different load split strategies, a simulation model and implementation has to be realized. With the simulation, the alternatives of the perfect knowledge central entity, and the various (more) distributed flow load splitting strategies can be evaluated and analyzed. Interesting question is whether local queue information is sufficient, or do we need 1 hop or n hop congestion information? There are costs incurred to find out congestion information n hops away.
For a number of reasons, e.g. not standard compliant or security related, IPv6 Extension Headers (EHs) are filtered by network middleboxes (firewalls). This filtering can break legitimate IPv6 traffic and can also break user expectations of IPv6 stability. As IPv6 is the Internet protocol that enables future growth for the Internet, it is important to get insight into the extent that EHs are filtered and breaking proper IPv6 operation. For measurements, we plan to use the RIPE Atlas measurement infrastructure, which exists of 5000+ probes distributed over Europe (mainly) and other continents. This project is already scheduled to run this Spring, as it is part of a larger international measurement. So jump on the bandwagon!
Security in the BGP routing protocol is until recently almost non-existent. Trust exists outside the BGP protocol, and is based on mutual (business) agreements. Although this worked for many years fairly well as operators knew their peers (e.g. their telephone numbers were in the Rolodex of the network operator), in the current networking practice the lack of a more formal security model is dire. In the recent years, Resource PKI (RPKI) has been proposed in the IETF as a first step in building a more secure BGP routing infrastructure. RPKI standard is published and implementations have been made available by all major router vendors. But actually using RPKI in validating BGP announcements is still at the very beginning. In the project, the effect of different RPKI deployment scenarios are evaluated, and maybe as an outcome of the research project, a (most) optimal deployment scenario can be proposed.
For security and resilience of national critical infrastructures, the physical location of IP resources are important in threat landscape analysis. Current techniques like GeoIP (e.g. from MaxMind) do have limitations, and for critical situations not sufficient. The goal of the project is to improve location "certainty" by using multiple sources with with some confidence percentage.