This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 28, 2009.
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
This document describes a set of mitigations that stop the known variations of the Kaminsky cache poisoning attacks against the DNS system, for which only resolver side deployment is necessary.
3.1. Add Entropy
3.2. Use Care with the Cache
3.3. Obtain Authoritative Data
4. Variants to Protect against
5. Security Considerations
6. IANA Considerations
8. Informative References
[WW: These are the counter measures for the Kaminsky attack scenarios that I envision for the Unbound resolver (http://unbound.net). These are counter measures that require resolver side deployment only. Depending on working group input this document could remain an Unbound specific information document or can be made more generic, and move towards a BCP.]
This document describes the mitigations that a resolver can deploy on its own in the meantime, while a more comprehensive (read: DNSSEC) solution is being rolled out. For counter measures that require changes to authoritative and recursive servers everywhere, DNSSEC provides the most protection, followed by Nonce-based approaches (e.g. EDNS PING), followed by transport protocol games. Because Unbound implements DNSSEC validation already, and DNSSEC provides the most protection (e.g. against new unknown variations and also against full man-in-the-middle attacks), this is a good long term choice.
The solutions covered in this document hope to cover all of the variations in the recent Kaminsky-style attacks. However, it seems likely that other variations besides the ones described in this document are going to be discovered. For that reason a number of generic protections are included, chief amongst those is the use of extra entropy.
Since this document focuses on Unbound it is worth noting that although current versions implement these mitigations, they are not all turned on by default. Unbound should support the mitigations considered 'best' by the community. This means without weird, ill-considered, mitigations of its own. Hence this document.
It is assumed the reader is aware of, and implementing, the forgery-resilience [RFC5452] (Hubert, A. and R. van Mook, “Measures for Making DNS More Resilient against Forged Answers,” January 2009.) recommendations.
In Section 2 the criteria are listed. In Section 3 the various measures that can be used to mitigate threats are described. Section 4 enumerates Kaminsky-style attack variations, and shows what measures provide protection against each one of them. Section 5 discusses consequences caused by the mitigations.
The first and foremost criterium is that these are resolver side solutions, thus only the resolver needs to be redeployed, or the software updated, for this to work. The reason behind this is that a short term deployment is possible. The idea is to provide some (partial) protection on the short term. On the long term it is possible to redeploy both authority and recursors, and the solution space is greatly increased (e.g. options range from EDNS PING, using TCP or SCTP, to DNSSEC deployment).
Many solutions in this document could also be used in stub resolvers. Stub resolvers are not mentioned specifically further on, the main focus is on the caching recursive server.
The solutions have to follow the DNS protocol.
The solutions have to be non disruptive, and non anti-social. Specifically, they must not put the costs of the solution with 3rd parties. For example, large scale fallback to TCP both uses a limited resource (TCP connections to authority servers), and disrupts deployment behind many middle boxes.
Solutions without an 'attack mode' are preferred. An 'attack mode' is a different state of behaviour that the resolver enters into after something anomalous is detected. It may be for only a subset of operations or only a limited time. One reason to avoid such modal design is that paranoia dictates that maximal protection should always be used. A second reason is that if a protection measure cannot be used always, it is likely to be disruptive (see above). Such an 'attack mode' complicates implementation, testing and especially security analysis.
Below, the resolver side mitigations are described.
The mitigations in this section increase the transaction entropy above the 16 bits in the ID number. This is pretty close to the forgery-resilience [RFC5452] (Hubert, A. and R. van Mook, “Measures for Making DNS More Resilient against Forged Answers,” January 2009.) text, differences are in the rtt banding text and 0x20 consideration.
If all the above entropy settings are in use, it is estimated that Unbound can provide about 44 bits of entropy (16 ID, 15.8 port bits, about 8 0x20 bits, about 2 rtt banding + protocol bits and about 2 source address bits). Without user configuration or queries amenable to 0x20, 34 bits of entropy are likely, or even 18 if a NAT box kills the port randomisation. Entropy thus provides only limited protection.
A bonus when using the above methods to obtain authoritative data is that when using DNSSEC, the data can be validated, and thus spoofed infrastructure data can be detected and handled appropriately. This protects DNSSEC, where the referral contains unsigned NS, A and AAAA records from spoofed infrastructure data. Of course, DNSSEC is designed to protect end-user data anyway, whether or not the referral data was poisoned. It simply adds the opportunity to add another layer of defense.
In the descriptions below a short title is given to quickly summarize the exploit. The query 'q:' is what the attacker sends as fake question to the resolver to answer. The answer, authority 'auth:' and additional 'add:' sections list the content that the spoofer provides. The mitigation strategy, and sometimes discussion, is provided in the 'protected:' line.
The real target is example.com or www.example.com or ns1.example.com, which is the real nameserver for example.com here. The domain evil.example.net is under control of the attacker and 192.0.2.66(evil) is an IP address under control of the attacker. The label 'bad123' is used in place of a label that the attacker varies every attempt to obtain new spoofing windows.
Glue with new DNS server q: bad123.example.com. answer: bad123.example.com. A whatever auth: example.com. NS evil.example.com. add: evil.example.com. A 192.0.2.66(evil) protected: 2181 adherence plus NS record pinned by NS query. Also name error or no data answers could be used, instead of this answer section. Glue for DNS server q: bad123.example.com. answer: bad123.example.com. A whatever auth: example.com. NS ns1.example.com. (normal entry) add: ns1.example.com. A 192.0.2.66(evil) protected: 2181 adherence plus NS record pinned by NS query, plus A record pinned by glue query. Also name error or no data answers could be used, instead of this answer section. Glue for Web server q: bad123.example.com. answer: bad123.example.com. A whatever auth: example.com. NS www.example.com. add: www.example.com. A 192.0.2.66(evil) protected: 2181 adherence plus NS record pinned by NS query. Glue smaller q: bad123.example.com. answer: bad123.example.com. A 192.0.2.66(evil) auth: example.com. NS bad123.example.com. protected: 2181 adherence plus NS record pinned by NS query. NS change q: bad123.example.com. answer: bad123.example.com. A whatever auth: example.com. NS evil.example.net. protected: 2181 adherence plus NS record pinned by NS query. NS server migration q: bad123.example.com. answer: bad123.example.com. A whatever auth: example.com. NS ns1.example.com. (normal entry) auth: example.com. NS ns2.example.com.evil.example.net. (evil, looks like typo in server migration) protected: 2181 adherence plus NS record pinned by NS query. CNAME q: bad123.example.com. answer: bad123.example.com. CNAME www.example.com. answer: www.example.com. A 192.0.2.66(evil) protected: CNAME chain cutoff. DNAME one message q: www.bad123.example.com. answer: bad123.example.com. DNAME example.com. answer: www.bad123.example.com. CNAME www.example.com. answer: www.example.com. A 192.0.2.66(evil) protected: DNAME chain cutoff. DNAME whole zone q: bad123.example.com. answer: example.com. DNAME evil.example.net. answer: bad123.example.com. CNAME bad123.evil.example.net. answer: bad123.evil.example.net. A whatever protected: no DNAME from cache. New Delegation - rigged q: bad123.www.example.com. answer: (empty) auth: www.example.com. NS www.example.com. add: www.example.com. A 192.0.2.66(evil) protected: the NS queries that ask referral confirmation together with glue queries. New Delegation - looks normal q: bad123.www.example.com. answer: (empty) auth: www.example.com. NS ns1.evil.example.net. auth: www.example.com. NS ns2.evil.example.net. protected: the NS queries that ask referral confirmation together with glue queries. New Delegation - for glue q: bad123.example.com. answer: (empty) auth: bad123.example.com. NS ns1.example.com. additional: ns1.example.com. A 192.0.2.66(evil) protected: rfc2181 adherence. Another hitherto unknown variation These are a lot of variations and it is very likely that other people can come up with better, different ideas. protected: by entropy measures, by the count-and-wipe measure. Long term solutions (PING, TCP, DNSSEC) also aim to protect against these much more thoroughly.
All of the mitigations aim to provide more security. But, several of these mitigations have adverse effects on performance and bandwith.
The CNAME, DNAME, NS and nameserver address mitigations all require that additional lookups be performed. The CNAME and DNAME target lookups cause the answer to the client to be delayed. The NS set and nameserver address lookups cause a higher load on both authority and resolver servers.
The detection mechanism is susceptible to denial of service attacks. A small, calculated, amount of additional DoS leverage is provided. This changes some spoof attacks into a denial of service.
The NS set and nameserver address lookups cause the NS, A and AAAA RRsets to be pinned in the cache until the TTL expires. This provides cache overwriting protection, but at the cost of not picking up updates to these RRsets in the course of normal resolution. Changes to these RRsets are then no longer seen on the next query, but only after the TTL times out. This adversely affects the coherency of the DNS server infrastructure, as it becomes more likely that resolvers operate using out of date nameserver data.
Thanks to Nicholas Weaver (ICSI Berkeley) and Olaf Kolkman (NLnet Labs).
|[I-D.vixie-dnsext-dns0x20]||Vixie, P. and D. Dagon, “Use of Bit 0x20 in DNS Labels to Improve Transaction Identity,” draft-vixie-dnsext-dns0x20-00 (work in progress), March 2008 (TXT).|
|[RFC2181]||Elz, R. and R. Bush, “Clarifications to the DNS Specification,” RFC 2181, July 1997 (TXT, HTML, XML).|
|[RFC5452]||Hubert, A. and R. van Mook, “Measures for Making DNS More Resilient against Forged Answers,” RFC 5452, January 2009 (TXT).|
|Science Park 140|
|Amsterdam 1098 XG|