TOC 
DNS Extensions Working GroupW. Wijngaards
Internet-DraftNLnet Labs
Intended status: InformationalAugust 25, 2008
Expires: February 26, 2009 


Resolver side mitigations
draft-wijngaards-dnsext-resolver-side-mitigation-00

Status of This Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 February 26, 2009.

Abstract

Describes a set of mitigations that stop the known Kaminsky variations, for which only resolver side deployment is necessary.



Table of Contents

1.  Introduction

2.  Criteria

3.  Mitigations
    3.1.  Add Entropy
    3.2.  Use Care with the Cache
    3.3.  Obtain Authoritative Data
    3.4.  Detection

4.  Variants to Protect against

5.  Security Considerations

6.  IANA Considerations

7.  Acknowledgments

8.  Informative References




 TOC 

1.  Introduction

[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 these are not all implemented, some of these are under consideration. 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, and implementing, the [forgery-resilience] 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.



 TOC 

2.  Criteria

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.



 TOC 

3.  Mitigations

Below, the resolver side mitigations are described.



 TOC 

3.1.  Add Entropy

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] 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.



 TOC 

3.2.  Use Care with the Cache



 TOC 

3.3.  Obtain Authoritative Data

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.



 TOC 

3.4.  Detection



 TOC 

4.  Variants to Protect against

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
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
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 hiherto 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.



 TOC 

5.  Security Considerations

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.



 TOC 

6.  IANA Considerations

None.



 TOC 

7.  Acknowledgments

Thanks to Nicholas Weaver (ICSI Berkeley) and Olaf Kolkman (NLnet Labs).



 TOC 

8. Informative References

[RFC2181] Elz, R. and R. Bush, “Clarifications to the DNS Specification,” RFC 2181, July 1997 (TXT, HTML, XML).


 TOC 

Author's Address

  Wouter Wijngaards
  NLnet Labs
  Kruislaan 419
  Amsterdam 1098 VA
  The Netherlands
Phone:  +31-20-888-4551
EMail:  wouter@nlnetlabs.nl


 TOC 

Full Copyright Statement

Intellectual Property