Editor’s note: Imported from my old personal blog @ TC with minor edits to improve readability where necessary.
Securing and Trusting Internet Names (SATIN 2012), a conference with the goal of promoting industry and academic attention on the operational security of the Internet’s DNS, recently took place in Teddington, UK at the National Physical Laboratory (NPL). This is the second annual meeting and while DNS is an area I’ve spent a fair amount of time on over the years, I’ve attended neither one since travel to such a remote destination for a relatively modest agenda and limited outreach opportunity is hard to justify. Thankfully, like most conferences the slide decks and accepted papers are freely available so we still get the benefit of at least some of what was discussed, but we miss out on the always valuable hallway discussions. I read and will provide a less than rigorous review and critique of one of the submitted papers that, if for no other reason, has the distinction of having the largest number of co-authors.
Haixin Duan, Nicholas Weaver, Zongxu Zhao, Meng Hu, Jinjin Liang, Jian Jiang, Kang Li and Vern Paxson Hold-On: Protecting Against On-Path DNS Poisoning, SATIN 2012 (Editor’s note: the conference web page shows a slightly different title for the paper, I use the one from the paper itself.)
The authors point out that DNS resolvers are designed to accept and act on the first valid response to a DNS query. Unfortunately it has been demonstrated most recently and with no lack of fanfare by the clever Dan Kaminsky how dangerous this can be in practice. The authors categorize a poisoning attack into three areas: off-path, on-path and in-path, but each amounts to what is essentially known in the Internet security community more generically as an impersonation or spoofing attack.
In this context it is worth considering how other systems and protocols deal with spoofed or even benign duplicate messages. Some, such as source-route bridging, which many of you have probably never seen much less heard of, reacts in a manner similar to a DNS resolver. In source-route bridging, it is normal and expected for multiple route explorer messages to arrive at a destination, each enumerating a unique path between the end hosts. The receiver of these explorer messages simply has to choose one and in practice it is the first one received under the assumption that is usually the correct and simplest choice. We could also look for lessons in TCP, such as when a TCP receiver returns duplicate ACKs or in ICMP, when a group of receivers may respond to an ICMP echo request to a limited local, directed broadcast or multicast address. The authors however do not draw any parallels even if it might have been useful to do so.
The paper proposes a fundamental change to the DNS resolver design and while the authors acknowledge the scope of the change, readers unfamiliar with the architecture are unlikely to realize how truly radical such a proposal is. IETF RFC 1034 - Domain Concepts and Facilities discusses the DNS resolver algorithm in section 5.3.3 by stating four recommended priorities for any DNS resolver. The fourth recommendation says simply “Get the answer as quickly as possible”. The authors argue for the introduction of a “Hold-On” timer. This timer is intended to help the resolver validate an answer by waiting for a valid response if an earlier one evaluates as suspicious. Their proposed hold-on timer may remind of you a hold-down timer in routing protocols and there are similarities, but where a routing protocol uses a hold-down timer to achieve stability in the face of routing changes, the hold-on timer proposed here aims to minimize surreptitious censorship if not outright injection of malicious data.
A common challenge wherever timers are used in protocols is in determining the initial timer value. While a static value is easy to implement, rarely does such a rigid approach come without drawbacks. Timers often adapt to network conditions and the authors propose just such a thing here. They propose using an expected round trip time (RTT) to help filter out responses that arrive too soon. To determine the expected RTT they first conduct a series of queries that would not normally result in spoofed responses. It is worth noting that their proposal only considers the case of protecting a stub resolver or a resolver that simply forwards to another limited set of resolvers, hence a single expected RTT value is used for all returning answers. Otherwise, the expected RTT could vary widely for a large array of Internet authoritative DNS servers. The authors implement the algorithm using what they call a DNS proxy that sits between stub resolvers or forwarders on the one hand and a set of full resolvers on the other. This does make their experiment much simpler to conduct, but seems to suggest little consideration has been given to how this proposal might scale if deployed between large resolvers and the rest of the Internet DNS.
As an additional measure used to validate returned answers, the authors also examine the returned IP TTL of responses and compare this value with an expected value, obtained in a manner similar to the expected RTT. Presuming DNSSEC is not enabled, a reply that evaluates to a valid RTT and IP TTL will be accepted by the resolver. Their initial evaluation of the RTT and IP TTL mechanisms were done using a Bro policy script. Implementation of the DNS proxy demonstrated that the hold-on timer resulted in no noticeable delay.
Spoofing attack mitigation is a serious and interesting problem and this paper contributes favorably to our current thinking about how to address it, especially in the context of censoring systems as the authors are most interested in here. However, I did not find authors' proposal a convincing practical solution. There are a number of issues that don’t seem to be fully addressed. For instance, for an off-path poisoning attack, such as the Kaminsky attack, the RTT validation is easily defeated. Eventually spoofed packets will fall within the validation window. The IP TTL may be harder to overcome, but unless the legitimate resolver initializes it’s IP TTL to 255 and is closer than the attacker to the destination, even this will be relatively easy to defeat. Granted, the authors do note that they limit their proposal to an on-path threat and the paper’s title says as much, but even here their proposal only works based on how censoring networks are operating today. It would be easy for an on-path adversary to send multiple responses, one of which could satisfy the expected IP TTL and RTT values. Furthermore, this proposal appears ill designed for anything but stub or forwarder to resolver validation. Putting it on a large resolver and maintaining one or more RTT timers for what might be hundreds if not thousands of queries per second associated with literally thousands of the Internet’s authoritative DNS servers does not seem likely to gain much acceptance from the DNS operational community. Even if scaling issues are overcome, the system can be easily defeated by the censoring networks. They could limit access to resolvers of their choosing where they might be able to apply censorship directly into the DNS. Ultimately, on-path adversaries could be motivated to migrate to an in-path mode if necessary, rendering these defenses completely ineffective.
Some may say DNSSEC is the answer and that may be partially true, but if overcoming censorship is the goal, which for these authors it appears to be a primary one, encryption, which DNSSEC doesn’t provide, is likely needed. Others will also harangue on at length about IETF BCP 38 - Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing and IETF BCP 84 - Ingress Filtering for Multihomed Networks as if we can cajole all networks to limit IP address spoofing. This would ignore that censors are going to claim operational sovereignty to spoof within their own networks as well as the practical limits to deploying anti-spoofing measures throughout the entire Internet.