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

From: bert hubert <[email-masked]>
Date: Sun, 22 Jun 2008 14:50:09 +0200

Hello Peter,

Many thanks for your long and thoughtful reaction. Please find my reaction
and resulting edits below.

I've left out things on which I consider myself to have no expertise, like
if this document should be BCP or standards track.

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

The definition in 1034 is too short, the one in 1123 is too long and lists
requirements, 4033 does not define a recursive name server. 

I added a reference to 'full service resolver' and 1123:
- <t>Resolver: a nameserver performing recursive service for clients, also known as a caching server</t>
+ <t>Resolver: a nameserver performing recursive service for clients, also known as a caching server, or a full service resolver (<xref
target="RFC1123">, paragraph 6.1.3.1)</t>

> >       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"?

Fixed.

> >       Question: a question sent out by a resolver, typically in a UDP
> 
> Again, the usual terminology is "query" and "response", where "question" most
> often refers to the actual question section in the packet (see RFC 1034).

Fixed.

> >       Third party: any host other than the resolver or the intended
> 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.
Fixed.

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

Fixed, new: <t>Authentic answer: the correct answer that comes from the
right authoritative server</t>

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

Fixed. I've left it in because it helps frame the mindset needed for the
rest of the document.

> >    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!

Well, I'm open to suggestions. Earlier feedback indicated this document
should steer well clear of operational guidelines. I'm more than willing to
include more wording on this subject, or to suggest other places for
discussions.

> >    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
> 
> Since "STDs" are a subset of "RFCs", "relevant DNS protocol specifications"
> should suffice, maybe with a list of references already given here.

Fixed.

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

Fixed.

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

Fixed.

> >    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?

I'm unsure what you mean with this, or the following. Do you want to add
references to each line?

> >    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)

Fixed.

> >    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_"?

Fixed.

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

Fixed.

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

Done.

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

Removed the "In spite of this" paragraph, added:
'	      Questions may however be forced indirectly, for example by
inducing a mail server to perform DNS lookups.'

> >    The time to live of the 'target domain' determines how often a window
> 
> "of the target domain name's RRSets"
Fixed.

> >    Most domains have two or three authoritative nameservers, which make
> s/most domains/many zones/;

Fixed.

> >    nameserver.  While two Best Current Practice documents ([RFC2827] and
> >    [RFC3013] specifically) direct Internet access providers to prevent
> 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.

Done.

> > 4.5.  Matching the destination address of the authentic answer
> 
> This is more about the destination port than the destination address, isn't it?

Added 'and port'. It might also be about the destination *address* since the
local address from which queries are generated might be unknown, and often
is in case of load balanced resolvers.

> >    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/

Done.

> >    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?

Even with a stateful packet filter, it won't help.

> It might be worth mentioning NAT explicitly here since port rewriting at the
> NAT might actually reduce the effect of port randomization (RFC 4787).

Hmm - perhaps. But perhaps not. I'd hate for more discussion to ensue.

> >    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?

Yes - it might be 10ms, it might be 1000ms. Hence 'in the order'.

> > 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"

Done.

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

Done.

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

Yes.

> >    o  Query ID
> >    o  Question name (compared case-insensitively)
> >    o  Question class and type
> 
> Use QNAME, QCLASS and QTYPE here.

Please discuss with Paul - I'm not making further changes on this without
consensus anymore.

> 
> >    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?

The fake response is ignored in the sense that its data is not trusted. Paul
outlined the reasons for this being a format error, but I don't recall the
exact reasons.

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

 "Please note that source ports could be selected from a larger range than
  indicated, but that this range is regarded as safe, with some lower port
  numbers reserved for activities which might conflict with proper DNS
  operation."

> >    o  Use multiple different source ports simultaneously in case of
> >       multiple outstanding questions;
> 
> Shouldn't this be independent of the number of active queries?

It is very hard to use multiple different source ports simultaneosly with
only one outstanding question :-) I don't recall where this specific wording
came from, but it was recommened by someone.

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

The mathematicians and cryptologists didn't like me mandating
unpredictiveness - since this is an impossible goal formally.

> >    Resolvers SHOULD favour authoritative nameservers with which a trust
> >    relation has been established;
> 
> That would need an explanation ...

Came from TSIG proponents.

> >    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?

It does resolve the problem.

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

Secure DNS might be more than DNSSEC one day, hence the broader wording.

> >    For brevity's sake, in lieu of repeating the security considerations
> >    references, the reader is referred to these sections.
> 
> delete these 2 lines.

They were added on specific request because some people, apparently, only
read the 'Security' section.

> >    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?

No - it only notes. I wrote this paragraph for you, feel free to tweak it.
It was felt that it would be useful to make *note* of the impact of a low
TTL, but not proscribe operational behaviour.

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

Added.

> >    [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

Done.

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

Done. Please see your changes on
http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/changeset/21

Thanks!

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

--
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/>