Location

Cryptography is hard. It usually takes many years of study before it is possible to make any serious contribution to the field; and even expert cryptographers often have flaws discovered in their work.

However, merely using cryptography requires far less expertise. In this talk, I will cover everything most software developers will ever need to know about cryptography -- starting from the very beginning -- along with (time allowing) some of the reasons behind the recommendations I provide.

Specific topics covered will include symmetric vs. asymmetric encryption; symmetric vs. asymmetric signatures; block ciphers; block cipher modes; key lengths; message authentication codes; hash algorithms; password handling; padding for asymmetric encryption; padding for asymmetric signing; Diffie-Hellman groups; and side channel attacks. Specific attacks will be discussed only to the extent of mentioning that they exist and explaining how cryptography-using systems should be designed to thwart them.

Location

Fernando Gont will discuss some of the results of a Security Assessment of the Internet Protocol version 6 (IPv6) carried out on behalf of the UK CPNI (United Kingdom's Centre for the Protection of National Infrastructure). He will explain some of the security implications arising from the protocol specifications themselves, and from a number of implementation strategies followed by some of the most popular IPv6 implementations (including KAME). He will describe ongoing efforts to mitigate the aforementioned issues, and will explain the different system knobs that are available in the different BSD-flavours to control different aspects of the IPv6 stack.

The IPv6 protocol suite was designed to accommodate the present and future growth of the Internet, by providing a much larger address space than that of its IPv4 counterpart, and is expected to be the successor of the original IPv4 protocol suite. It has already been deployed in a number of production environments, and many organizations have already scheduled or planned its deployment in the next few years.

There are a number of factors that make the IPv6 protocol suite interesting from a security standpoint. Firstly, being a new technology, technical personnel has much less confidence with the IPv6 protocols than with their IPv4 counterpart, and thus it is more likely that the security implications of the protocols be overlooked when they are deployed. Secondly, IPv6 implementations are much less mature than their IPv4 counterparts, and thus it is very likely that a number of vulnerabilities will be discovered in them before their robustness can be compared to that of the existing IPv4 implementations. Thirdly, there is much less implementation experience with the IPv6 protocols than with their IPv4 counterpart, and “best current practices” for their implementation are not available. Fourthly, security products such as firewalls and NIDS’s (Network Intrusion Detection Systems) usually have less support for the IPv6 protocols than for their IPv4 counterparts.

While a number of papers have been published on the security aspects of the IPv6 protocol suite, they usually provide general discussion on the security implications of IPv6, but do not delve into much detail regarding the security implications of each of the mechanisms, header fields, and options of all the involved protocols.

There is a clear need to raise awareness about the security aspects and implications of the IPv6 protocol suite, to improve the confidence of both IPv6 implementers and the personnel working on the deployment of IPv6 in production environments.

Location

Historically, FreeBSD has had two packet scheduling options: AltQ, which can do output scheduling using the network card as a transmission clock, and "dummynet", which was born as a link emulator but also included one scheduling algorithm.

We have recently made an almost complete rewrite of dummynet to support multiple scheduling algorithms, so that users can pick the ones that fit best their needs. In the process, we also performed a thorough performance analysis of the tool, so now users can make more informed choices on how to configure their packet scheduling/shaping architecture and on which tradeoffs are involved.

In this talk we will make the following contributions:

   1. describe the internal architecture of the new version of "dummynet", and the API used by the loadable packet schedulers;
   2. give a "user view" of the new features made available by this updated version of dummynet;
   3. briefly discuss the theory behind packet scheduling, and show how different solutions expose different tradeoffs betweeen service properties, guarantees and run-time complexity;
   4. show a number of examples and experiments, running real code from the SVN tree, to demonstrate that the (apparently dry) theory discussed in #3 has actual implications in practice.