May 2015 – SWITCH Security-Blog

IPv6 address provisioning: theory and practice

Everybody who starts (consciously) integrating IPv6 in their network has to decide how to provision IPv6 addresses, default routes and recursive DNS server (RDNSS) information to all clients.

To make this simple and automated, IPv6 includes SLAAC (StateLess Address Auto Configuration). This is a good thing, but it’s stateless, so you no longer manage your IP address provisioning centrally (as you did with DHCP in IPv4) and thus lose traceability (i.e. which node has which IP at any given time). Moreover, SLAAC supports provisioning of RDNSS information only since RFC 6106 (November 2010), and not everybody supports this. For example, Microsoft doesn’t, and it doesn’t seem to have any intention of changing this.

Many believe this is reason enough to forget about SLAAC – or at least try to – and use DHCP just like in the good old IPv4-only days. Indeed, there is such a thing as DHCPv6, but unfortunately it doesn’t provision default router information, and, once again, not everybody supports it. For example, Android doesn’t, and it doesn’t seem to have any intention of changing this.

This means most of us will end up with a mixture of SLAAC and DHCPv6 (either the stateless or stateful variant), which is not a problem in theory because IPv6 Router Advertisements (the ICMPv6 message type used for SLAAC) have flags for that.

ICMPv6 Type 134 (Router Advertisement) flags:

M – Managed Address Configuration. DHCPv6 is available for IPv6 address allocation.
O – Other Configuration. Other configuration information is available through DHCPv6 (e.g. the RDNSS).

Flags in prefix information option:

A – Address Configuration flag. The prefix can be used for stateless address configuration (SLAAC).
L – On-Link flag. The prefix can be used for on-link determination (other IPv6 addresses with the same prefix are on the same L2 subnet).

But how do implementations behave if the information provided by Router Advertisement conflicts with that from DHCPv6 due to human error, conflicting default settings or an attacker? And how do such conflicts affect network stability and security?

This is what the talk from Enno Rey at the last Tech Talk of the Swiss IPv6 Council in Zurich was about. Enno presented the results of the research he and his team conducted in their IPv6 lab at ERNW in Heidelberg.

Some examples of the findings:

Windows 8.1 configures IPv6 address from DHCPv6, despite the fact that the Management flag (M) in the Router Advertisement is not set.
If both SLAAC and DHCPv6 provide RDNSS information and M/A/O flags are set, Fedora, Centos and OS X configure RDNSS information from both sources, Ubuntu only from the RAs, and Windows only from DHCPv6.
If two routers send RAs with conflicting M/O flags, basically all operating systems behave differently.

Continue reading “IPv6 address provisioning: theory and practice”

The May 2015 issue of our SWITCH Security Report is available!

Dear Reader!

A new issue of our monthly SWITCH Security Report has just been released.

The topics covered in this report are:

«Massive snooping attack» or successfully treading the fine line between security and freedom? On the reform of Switzerland’s intelligence services legislation
Barbie turns Bond girl – toy manufacturers spying on children’s bedrooms
Only those who get involved get hurt – latest e-banking Trojans harness social engineering
E-health made in Switzerland – electronic patient records
Fear of flying 2.0 – US authorities warn of in-flight hacking
The Clipboard: Interesting Presentations, Articles and Videos

The Security Report is available in both english and german language.

»» Download the english report. »» Download the german report.

Did you miss our previous Security Report? Click here to go to the archive.

Protect your network with DNS Firewall

If you run your own mail server, you will quickly find out that 90% of the e-mails you receive are spam. The solution to this problem is e-mail filtering, which rejects or deletes unwanted spam. This solution is generally well accepted, and most users would not want the old days back when your inbox was filled with scams. Those people who want spam can also work around it by disabling spam filtering for their e-mail address or opting to run their own mail server.

Spam, scammers and other malicious abuse are not unique to e-mail. One possible approach is to invent a filtering technology for every protocol or service and allow the service owners to block misuse according to their policy. On the other hand, most services on the Internet make use of the Domain Name System (DNS). If you control DNS name resolution for your organisation, you can filter out the bad stuff the same way you filter out spam on e-mail. The difference and the advantage of DNS is that DNS filtering is independent of the service you use.

Back in 2010, ISC and Paul Vixie invented a technology called Response Policy Zones (RPZ) (See CircleID Post Taking back the DNS). While it has always been possible to block certain domain names from being resolved on your DNS resolver, adding host names manually as an authoritative zone does not scale.