Subject: Review of draft-ietf-dnsext-forgery-resilience-03.txt

From: Peter Koch <[email-masked]>
Date: Tue, 27 May 2008 11:52:22 +0200

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

Hello,

this is a review of draft-ietf-dnsext-forgery-resilience-03.txt.  I think
this document fulfills a useful purpose, but is not ready yet for WGLC and
does not belong on the standards track.  Find some general remarks after
the walk through.

> DNS Extensions (DNSEXT)                                        A. Hubert
> Internet-Draft                        Netherlabs Computer Consulting BV.
> Updates: 1034 (if approved)                                  R. van Mook

The draft isn't clear where it actually updates 1034 and in fact I believe
it shouldn't even try to.

> Intended status: Standards Track                                   Virtu

The document does not change on the wire behaviour and thus should be aiming
at BCP instad of standards track.  Elevation of this document could not
really be measured based on interoperability.

> 1.  Requirements and definitions
> 
> 1.1.  Definitions
> 
>    This document uses the following definitions:
> 
>       Client: typically a 'stub-resolver' on an end-user's computer
> 
>       Resolver: a nameserver performing recursive service for clients,
>       also known as a caching server

Instead of introducing new definitions and thus contributing to language
confusion, the document could borrow (with references) from earlier
publications.  This beast is either a "resolver" (per RFC 1034), a "full-
service resolver (as per RFC 1123, 6.1.3.1) or a "recursive name server"
(as per RFC 4033).

>       Stub resolver: a very limited Resolver on a client computer, that
>       leaves most of the recursing work to a full resolver

See above. Why only "most of the recursing work"?

>       Question: a question sent out by a resolver, typically in a UDP
>       packet
> 
>       Answer: the answer sent back by an authoritative nameserver,
>       typically in a UDP packet

Again, the usual terminology is "query" and "response", where "question" most
often refers to the actual question section in the packet (see RFC 1034).

>       Third party: any host other than the resolver or the intended
>       recipient of a question.  The third party may have access to an
>       arbitrary authoritative nameserver, but has no access to packets
>       transmitted by the Resolver or authoritative server

The resolver isn't defined as a host but as a piece of software above, so
"third party" is any entity different from the resolver or authoritative
name server.

>       Authentic answer: the answer that would be accepted if no third
>       party interferes

That's true, but kind of a reverse definition. The authentic response 
is the one that originates from the true/real host using the target IP address
of the query.  It should carry authentic data, but that's a subtly different
issue.

>       Target domain: domain for which the attacker wishes to spoof in an
>       answer

This phrase is used only once more in the draft, so it might not even be
necessary.
In any case, since the target is a particular node in the hierarchy rather
than a subtree, I'd use 'target domain name' here.

> 2.  Introduction

>    The words below are aimed at authors of resolvers: it is up to
>    operators to decide which nameserver implementation to use, or which
>    options to enable.  Operational constraints may override the security
>    concerns described below.  However, implementations are expected to
>    allow an operator to enable functionality described in this document.

The operational considerations need to be discussed somewhere!

>    This document expands on some of the risks mentioned in RFC 3833,
>    especially those outlined in the sections on 'ID Guessing and Query
>    Prediction' and 'Name Chaining'.  Furthermore, it emphasises a number
>    of existing rules and guidelines embodied in the relevant STDs and

>    RFCs.  The following also specifies new requirements to make sure the
>    Domain Name System can be relied upon until a more secure protocol
>    has been standardised and deployed.

Since "STDs" are a subset of "RFCs", "relevant DNS protocol specifications"
should suffice, maybe with a list of references already given here.

> 3.  Description of DNS spoofing
> 
>    When certain steps are taken it is feasible to 'spoof' the current
>    deployed majority of caching resolvers with carefully crafted and

"caching resolvers" isn't among the list of defined terms.

>    timed DNS packets.  Once spoofed, a caching server will repeat the
>    data it wrongfully accepted, and make its clients contact the wrong,
>    and possibly malicious, servers.
> 
>    To understand how this process works it is important to know what
>    makes a resolver (and more specifically a caching server) accept an
>    answer.

The definitions section claims that "resolver" and "caching server" are
equivalent.

>    The following sentence in section 5.3.3 of [RFC1034] presaged the
>    present problem:
> 
>      The resolver should be highly paranoid in its parsing of responses.
>      It should also check that the response matches the query it sent
>      using the ID field in the response.
> 
>    DNS data is to be accepted by a resolver if and only if:

Now is this "normative" or the "emphasis" mentioned earlier?

>    1.  The question section of the reply packet is equivalent to that of
>        a question packet currently waiting for an answer
> 
>    2.  The ID field of the reply packet matches that of the question
>        packet

RFC 1034, section 5.3.3

>    3.  The answer comes from the same network address the question was
>        sent to

RFC 2181, section 4. (2181 is missing from the normative references)

>    4.  The answer comes in on the same network address, including port
>        number, as the question was sent from

RFC 2181, section 4.2

>    If a third party succeeds in meeting the four conditions before the
>    answer from the authentic answer does so, it is in a position to feed

"from the authentic _name server_"?

> 4.  Details

I'd suggest a more descriptive headline: "Detailed Description of Spoofing
Scenarios" or something along that line.

> 4.1.  Forcing a question
> 
>    Formally, there is no need for a nameserver to perform service except
>    for its operator, its customers or more generally its users.
>    Recently, open recursing nameservers have been used to amplify denial
>    of service attacks.

A reference to [draft-ietf-dnsop-reflectors-are-evil-05.txt] might help here.

>    In spite of this, many resolvers perform at least partial service for
>    the whole world.  This is partially out of lack of concern, and is
>    reminiscent of the open relay SMTP service the net enjoyed up to the
>    early 1990s.  Some access providers may serve so many subnets that it
>    is hard to enumerate these all in the DNS configuration.
> 
>    Providing full service enables the third party to send the target
>    resolver a question for the domain name it intends to spoof.  On
>    receiving this question, and not finding the answer in its cache, the
>    resolver will transmit questions to relevant authoritative
>    nameservers.  This opens up a window of opportunity for getting fake
>    answer data accepted.

The two preceding paragraphs appear a bit verbose to me without completely
addressing the attack scenarios.  It is important to state that even if
recursive service is restricted to "local" clients, a remote attacker can
induce DNS queries by other levels of indirection, e.g. using SMTP dialogues,
inline images in websites etc.

>    Some operators restrict access by not recursing for unauthorised IP
>    addresses, but only respond with data from the cache.  This makes
>    spoofing harder for a third party as it cannot then force the exact
>    moment a question will be asked.  It is still possible however to
>    determine a time range when this will happen, because nameservers
>    helpfully publish the decreasing TTL of entries in the cache, which
>    indicate from which absolute time onwards a new query could be sent
>    to refresh the expired entry.
> 
>    The time to live of the 'target domain' determines how often a window

"of the target domain name's RRSets"

>    of opportunity is available, which implies that a short TTL makes
>    spoofing far more viable.

> 4.2.  Matching the question section
> 
>    DNS packets, both queries and answers, contain a question section.
>    Incoming answers should be verified to have a question section that
>    is equivalent to that of the outgoing query.

This is what can be read from the examples in RFC 1034, since they all repeat
the original question in the question section.  "Equivalent" obviously means
that there is no bitwise comparison, which I consider a "Good Thing" for
reasons of protocol consistency.

> 4.3.  Matching the ID field
> 
>    The DNS ID field is 16 bits wide, meaning that if full use is made of
>    all these bits, and if their contents are truly random, it will
>    require on average 32768 attempts to guess.  Anecdotal evidence
>    suggests there are implementations utilising only 14 bits, meaning on
>    average 8192 attempts will suffice.

I'd suggest a bit more defensive wording here, since this is but one
implementation:
Weaknesses in implementations might reduce the necessary effort by not
utilizing the full ID space (e.g. only 14 bits, leading to 8192 attempts on
average) or by producing predictable ID sequences.

> 4.4.  Matching the source address of the authentic answer
> 
>    Most domains have two or three authoritative nameservers, which make

s/most domains/many zones/;

>    matching the source address of the authentic answer very likely with
>    even a naive choice having a double digit success rate.

The DNS specification requires at least two name servers per zone and many
zones actually do not extend beyond this number. This makes matching ...

>    It should be noted that meeting this condition entails being able to
>    transmit packets on behalf of the address of the authoritative
>    nameserver.  While two Best Current Practice documents ([RFC2827] and
>    [RFC3013] specifically) direct Internet access providers to prevent
>    their customers from assuming IP addresses that are not assigned to
>    them, these recommendations are not universally (nor even widely)
>    implemented.

This is a basic premise that IMHO should be elevated to the top of this section.
Without being able to spoof the source address, the odds of hitting the right
one are irrelevant.

> 4.5.  Matching the destination address of the authentic answer

This is more about the destination port than the destination address, isn't it?

>    Note that the destination address of the authentic answer is the
>    source address of the original question.
> 
>    The actual address of a recursing nameserver is generally known; the

That's true for the address accepting the stubs' queries, not necessarily for
the address used to generate the resolver's queries. Of course, the latter
can be eaasily determined.

>    If multiple ports are used for sending questions, this enlarges the
>    effective address space by a factor equal to the number of ports
>    used.

s/effective address space/effective ID space/

>    It should be noted that a firewall will not prevent the matching of
>    this address, as it will accept answers that (appear) to come from
>    the correct address, offering no additional security.

This assumes a stateless packet filter?
It might be worth mentioning NAT explicitly here since port rewriting at the
NAT might actually reduce the effect of port randomization (RFC 4787).

> 4.6.  Have the answer arrive before the authentic answer
> 
>    Once any packet has matched the previous four conditions (plus
>    possible additional conditions), no further answers are generally
>    accepted.
> 
>    This means that the third party has a limited time in which to inject
>    its spoofed answer, typically in the order of at most 100ms
>    (depending on the network distance to the authentic authoritative
>    nameserver).

This figure comes out of the blue?

>    This time period can be far longer if the authentic authoritative
>    nameservers are (briefly) overloaded by queries, perhaps by the
>    attacker.

> 5.  Birthday attacks
> 
>    The so called birthday paradox implies that a group of 23 people
>    suffices to have a more than even chance of having two or more
>    members of the group share a birthday.
> 
>    An attacker can benefit from this exact phenomenon if it can force
>    the target resolver to have multiple equivalent outstanding questions
>    at any one time to the same authoritative server.

Only if these queries use different IDs, so "equivalent" needs to be
specified more clearly.

>    Any packet the attacker sends then has a much higher chance of being
>    accepted because it only has to match any of the outstanding queries
>    for that single domain.  Compared to the birthday analogy above, of
>    the group composed of questions and answers, the chance of having any
>    of these share an ID rises quickly.
> 
>    As long as small numbers of questions are sent out, the chance of
>    successfully spoofing an answer rises linearly with the number of
>    outstanding questions for the exact domain and nameserver.
> 
>    For larger numbers this effect is less pronounced.
> 
>    More details are available in US-CERT [vu-457875].

Now, section 5 is only descriptive without any obvious connclusions.
First, I'd rather see this in an appendix and the "thou shalt not have
multiple outstanding queries with QNAME/QTYPE/QCLASS to the same
name server share the query ID or source port number" made explicit.

> 6.  Accepting only in-zone answers

in-domain (see below).

>    Answers from authoritative nameservers often contain information that
>    is not part of the zone for which we deem it authoritative.  As an
>    example, a query for the MX record of a domain might get as its
>    answer a mail exchanger in another domain, and additionally the IP
>    address of this mail exchanger.
> 
>    If accepted uncritically, the resolver stands the chance of accepting
>    data from an untrusted source.  Care must be taken to only accept
>    data if it is known that the originator is authoritative for that
>    data.

Since the resolver doesn't and shouldn't know about zone cuts, you can't
determine this.  So, it's "authoritative for that zone containing the data
or for any parent".

>    One very simple way to achieve this is to only accept data if it is
>    part of the domain we asked the question for.

Correct here.

However, this whole section is independent of the rest, so I'd suggest to
re-order a bit (which will be done by moving 7 and 8 to the appendix,
see below).
Also, this recommendation is the one that aims at "name chaining", so it
might want to explicitly say that.  Also, some example could help here:

;; QUESTION SECTION:
;Example.NET.                                IN      MX

;; ANSWER SECTION:
Example.NET.                 86400   IN      MX      10 mx1.example.org.

;; AUTHORITY SECTION:
Example.NET.                 86400    IN      NS      ns3.example.org.
Example.NET.                 86400    IN      NS      ns2.example.com.
Example.NET.                 86400    IN      NS      ns1.Example.NET.

;; ADDITIONAL SECTION:
mx1.example.org.           86400    IN      A       192.0.2.16
ns1.Example.NET.           86400    IN      A       192.0.2.32
ns2.example.com.           86400    IN      A       192.0.2.64
ns3.example.org.           86400    IN      AAAA    2001:DB8::53

The resolver SHOULD/MAY ignore all RRSets not owned at or below Example.NET.

> 7.  Combined difficulty
> 
>    Given a known or static destination port, matching ID field, source
>    and destination address requires on average in the order of 2 * 2^15
>    = 65000 packets, assuming a domain has 2 authoritative nameservers.

s/domain/zone/

>    If the window of opportunity available is around 100ms, as assumed
>    above, an attacker would need to be able to briefly transmit 650000
>    packets/s to have a 50% chance to get spoofed data accepted on the
>    first attempt.

[...]

This whole section I'd also rather see in an appendix, otherwise it distracts
from the actual recommendations.

> 8.  Discussion
> 
>    The calculations above indicate the relative ease with which DNS data
>    can be spoofed.  For example, using the formula derived earlier on a
>    domain with a 3600 second TTL, an attacker sending 7000 fake answer

s/domain/RRSet/

>    packets/s (a rate of 4.5Mb/s), stands a 10% chance of spoofing a
>    record in the first 24 hours, which rises to 50% after a week.
> 
>    For a domain with a TTL of 60 seconds, the 10% level is hit after 24

s/domain/RRSet/

>    minutes, 50% after less than 3 hours, 90% after around 9 hours.
> 
>    Note that the attacks mentioned above can be detected by watchful
>    server operators - an unexpected incoming stream of 4.5mbit/s of
>    packets might be noticed.
> 
>    An important assumption however in these calculations is a known or
>    static destination port of the authentic answer.
> 
>    If that port number is unknown and needs to be guessed as well, the
>    problem space expands by a factor of 64000, leading the attacker to
>    need in excess of 285Gb/s to achieve similar success rates.
> 
>    Such bandwidth is not generally available, nor expected to be so in
>    the foreseeable future.

This whole section 8 also should go into an appendix, since it is a
calculation example based on figures estimated around tghe time of writing.
While it supports the claim that spoofing is doable, there's no immediate
recommendation following.

>    Note that some firewalls may need reconfiguring if they are currently
>    setup to only allow outgoing queries from a single DNS source port.

This important operational consideration needs to be more prominently
adddressed (see below).

> 9.  Countermeasures

More explicit: "Recommendations" or "Recommended Countermeasures"

>    Given the above, a resolver implementation MUST match answers to the
>    following attributes of the question:
> 
>    o  Remote address
> 
>    o  Local address

More precisely: The response source IP address MUST match the query's
destination IP address and the response destination IP address MUST match
the query's source IP address.

>    o  Query port
	would this include UDP source (whatever that's worth) and destination
	ports?

>    o  Query ID
> 
>    o  Question name (compared case-insensitively)
> 
>    o  Question class and type

Use QNAME, QCLASS and QTYPE here.

>    before applying DNS trustworthiness rules.  A mismatch should be
>    considered a format error, and the answer invalid.

So, instead of ignoring the fake response, will see a FORMERR or a SERVFAIL?

>    Resolver implementations MUST have the ability to:
> 
>    o  Use an unpredictable source port for outgoing queries from a range
>       (53, or > 1024) of ports that is as large as possible and
>       practicable;

Maybe use >= 1024 and give some reasoning for the choice to avoid "privileged"
ports discussion.  Some ports are definitely bad choices (e.g. the "daytime"
port) anyway, so starting at 1024 is OK, but needs and explanation.

>    o  Use multiple different source ports simultaneously in case of
>       multiple outstanding questions;

Shouldn't this be independent of the number of active queries?

>    o  Use an unpredictable query ID for outgoing queries, utilizing the
>       full range available (0-65535);

Mention already here that the port number needs to be "unpredictable".

>    In case these abilities are enabled, the implementation MUST strive
>    to have its choices of source port and question ID remain
>    unpredictable, even if an attacker has knowledge of its
>    (pseudo-)random generator.

"MUST strive to" is a strange use of normative language.

>    If a resolver is multihomed or otherwise has the ability to transmit
>    and receive datagrams using more than one IP source address, then an
>    IP address can be chosen at random in order to increase an attacker's
>    difficulty in guessing what address to flood.

Subject to address selection guidelines at least for IPv6 ...

>    If a resolver sends out multiple equivalent questions to any
>    authoritative server, before receiving an answer, all MUST have
>    identical ID, source address and source port.

See above, "equivalent" is really "identical" here.

>    Resolvers SHOULD favour authoritative nameservers with which a trust
>    relation has been established;

That would need an explanation ...

>    Stub-resolvers SHOULD be able to use

>    TSIG ([RFC2845]) or IPSEC ([RFC2401]) when communicating with their
>    recursive resolver.

This is out of the scope of this document, isn't it?

>    In case a cryptographic verification of answer validity is available,
>    resolver implementations MAY waive above rules, and rely on this
>    guarantee instead.

Why not name "cryptographic verification" DNSSEC? However, "answer validity"
isn't what DNSSEC delivers.

``In case data origin authetication can be assured by means of DNSSEC,
  resolvers MAY waive above rules.''

> 10.  Security Considerations
> 
>    This document provides clarification of the DNS specification to
>    decrease the probability that DNS answers can be successfully forged.
>    Recommendations found above should be considered complementary to
>    possible cryptographical enhancements of the domain name system.

(nit: use caps)

>    A resolver that does not implement the recommendations outlined above
>    can easily be forced to accept spoofed answers, which in turn are
>    passed on to client computers - misdirecting (user) traffic to
>    possibly malicious entities.
> 
>    This document directly impacts the security of the Domain Name
>    System, implementers are urged to follow its recommendations.
> 
>    Most security considerations can be found in Section 5, while
>    proposed countermeasures are described in Section 9.
> 
>    For brevity's sake, in lieu of repeating the security considerations
>    references, the reader is referred to these sections.

delete these 2 lines.

>    Nothing in this document specifies specific algorithms for operators
>    to use; it does specify algorithms implementations SHOULD or MUST
>    support.

Well, the lack of operational considerations is a gap in need of filling.
That said, it's difficult to find these "algorithms" and the wording should
probably not use the 2119 keywords ("specifies mandatory to implement
algorithms").

>    The above notwithstanding, it should be noted that using a low Time
>    To Live for DNS records raises the chances of an attacker spoofing a
>    resolver.

Now, is this an operational recommendation?

> 12.  Normative References
> 
>    [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
>               STD 13, RFC 1034, November 1987.
> 
>    [RFC1035]  Mockapetris, P., "Domain names - implementation and
>               specification", STD 13, RFC 1035, November 1987.
> 
>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>               Requirement Levels", BCP 14, RFC 2119, March 1997.

RFC 2181 missing here as normative reference.

>    [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
>               Internet Protocol", RFC 2401, November 1998.

move to informative, same for probably all of the remaining references

Concluding remarks:

  The document should be more clear who the target audience is (resolver
  vendors and operators) and which recommendation aims at which part of that
  audience.  That is, independent of the required abilities of the resolvers
  we need recommendations for default settings (@vendors) and good
  configurations (@ops).

  The document also needs to address issues that arise from port number
  randomizations, especially in the context of NAT and firewalls/packet
  filters: a wide range of source ports may open up the host to port scanning
  and may need interaction with a packet filter.  NAT boxes may reduce
  the effectiveness of port randomization.  Wide(r) adoption of port
  randomization may increase the number of packet flows for both the
  operators of resolvers _and_ of authoritative servers.

  In general, while the document provides lots of useful information and
  more or less agreed upon advice, it needs more structure to seperate
  the detailed tutorial style information from the actual implementation
  (and configuration) specifications.

  Also, it should be more explicit as to what the actual novelty is, probably
  right away in the Security Considerations:

  ``This document recommends the use of UDP source port number randomization
  to extend the effective DNS transaction ID beyond the available 16 bits.''

-Peter

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 30 May 2008 15:54:47 +0200

On Tue, May 27, 2008 at 11:52:22AM +0200,
 Peter Koch <[email-masked]> wrote 

> So, instead of ignoring the fake response, will see a FORMERR or a

I am not sure I understand the sentence. You mean to send a FORMERR
or SERVFAIL to the original requestor? If that case, it would be easy
to DOS the clients of a recursor just by sending fake answers.

> Now, is this an operational recommendation?

IMHO, no, because there are valid reasons to use low TTL. This
sentence is just to be sure that DNS zone managers are aware of the
consequences.