Categories
Deploy360 DNS Privacy Domain Name System (DNS) Improving Technical Security Security

DNS Privacy Frequently Asked Questions (FAQ)

We previously posted about how the DNS does not inherently employ any mechanisms to provide confidentiality for DNS transactions, and mentioned some of the protocols that have been recently developed to improve user privacy.

To complement this, we are publishing our DNS Privacy Frequently Asked Questions (FAQ). This highlights and provides answers to the most important aspects of DNS privacy.

Please also check our DNS Privacy page for more information!

Further Information

Categories
Deploy360 DNS Privacy Improving Technical Security

Introduction to DNS Privacy

Almost every time we use an Internet application, it starts with a DNS (Domain Name System) transaction to map a human-friendly domain name to a set of IP addresses that can be used to deliver packets over the Internet. DNS transactions can therefore be correlated to the applications we use, the websites we visit, and sometimes even the people we communicate with.

While the domain name information itself is public, the transactions performed by the hosts are not. Unfortunately, the DNS does not inherently employ any mechanisms to provide confidentiality for these transactions, and the corresponding information can therefore easily be logged by the operators of DNS resolvers and name servers, as well as be eavesdropped by others.

So we are publishing our Introduction to DNS Privacy to raise awareness of the privacy implications of the DNS, and the mechanisms that have been recently developed to improve user privacy.

Please also check our DNS Privacy page for more information!

Further Information

Categories
Deploy360 Improving Technical Security IPv6 Security Security

IPv6 Security for IPv4 Engineers

It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a different protocol! But we think years of IPv4 operational experience should be leveraged as much as possible.

So we are publishing IPv6 Security for IPv4 Engineers as a roadmap to IPv6 security that is specifically aimed at IPv4 engineers and operators.

Rather than describing IPv6 in an isolated manner, it aims to re-use as much of the existing IPv4 knowledge and experience as possible, by highlighting the security issues that affect both protocols in the same manner, and those that are new or different for the IPv6 protocol suite. Additionally, it discusses the security implications arising from the co-existence of the IPv6 and IPv4 protocols.

Be sure also to check our IPv6 Security page as well!

Further Information

Categories
Deploy360 Improving Technical Security IPv6

IPv6 Security Frequently Asked Questions (FAQ)

The Internet Society recognises that global deployment of the IPv6 protocol is paramount to accommodating the growth of the Internet. Given the scale at which IPv6 must be deployed, it is also important that the possible security implications of IPv6 are well understood and considered during the design and deployment of IPv6 networks, rather than as an afterthought.

We are therefore publishing our IPv6 Security Frequently Asked Questions (FAQ), which highlights and provides answers to the most important aspects of IPv6 security.

Be sure also to check our IPv6 Security page as well!

Further Information

Categories
Deploy360 IETF IPv6

How IPv6 SLAAC Responds to Renumbering Events

If you follow the IPv6 Maintenance (6man) Working Group of the Internet Engineering Task Force (IETF), you may have noticed the 300+ message email thread on an Internet Draft that was recently published on the “Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering Events”. This was prompted by the experiences of developing Best Current Operational Practice on IPv6 prefix assignment for end-users, an activity led by ISOC’s Jan Žorž and published as ripe-690.

SLAAC is used to automatically assign an IPv6 address to a host, but there are a number of scenario where hosts may end up using stale configuration information and thereby leading to interoperability problems.

For example, a typical IPv6 deployment scenario is when a CPE (Customer Premises Equipment) router requests an IPv6 prefix to an ISP via DHCPv6-PD, and advertises a sub-prefix of the leased prefix on the LAN-side via SLAAC.

In such scenarios, if the CPE router crashes and reboots, it may lose all information about the previously leased prefix. Upon reboot, the CPE router may be leased a new prefix that will result in a new sub-prefix being advertised on the LAN-side of the CPE router. As a result, hosts will normally configure addresses for the newly-advertised prefix, but will normally also keep (and use) the previously-configured (and now stale!) IPv6 addresses, leading to interoperability problems.

ripe-690 had tried to address this problem by recommending that operators lease stable IPv6 prefixes to CPE routers, but for various reasons, ISP may not be able or willing to do this, and may instead lease dynamic prefixes. In fact, a recent survey of ISPs indicates that 37% of the surveyed ISPs lease dynamic IPv6 prefixes to their customers, as opposed to the stable prefixes recommended by ripe-690.

Most of the input on the 6man mailing list fell into one of the following camps:

  • “ISPs should be leasing stable prefixes — if they don’t, they are asking for trouble!”
  • “CPE routers should record leased prefixes on stable storage, such that they can deprecate such prefixes upon restart — if they don’t, they are asking for trouble!”
  • “No matter whose fault is this (if there is any single party to blame in the first place), we should improve the robustness of IPv6 deployments”

This Internet Draft therefore tries to improve the current state of affairs through the following improvements:

  • Allow hosts to gracefully recover from stale network configuration information — i.e. detect and discard stale network configuration information.
  • Have SLAAC routers employ more appropriate timers, such that information is phased-out in a timelier manner; unless it is actively refreshed by Router Advertisement messages.
  • Specify the interaction between DHCPv6-PD and SLAAC — which was rather under-specified.
  • Require CPE routers to store leased prefixes on stable storage, and deprecate stale prefixes (if necessary) upon restart.

Based on the mailing list discussions, there would seem to be consensus this is a problem that needs to be addressed by the 6man Working Group.

The topic is therefore likely to be on the working group agenda at the IETF 104 Meeting at the end of this month in Prague, Czech Republic. So if you’re a network operator, vendor or otherwise have operational experience of this issue, you’re strongly encouraged to contribute to the discussion.

Further Information