Subject: Re: DNSEXT WGLC: "Measures for making DNS more resilient against forged answers"

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 01 Jul 2008 17:34:11 -0700

At Thu, 26 Jun 2008 16:33:14 -0400,
Ólafur Guðmundsson /DNSEXT chair <[email-masked]> wrote:

> This note starts a Working Group Last Call for this Standards Track document
> ending on noon July 12'th 2006 (Dublin time).
> 
> URL for the document and its history:
> http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-forgery-resilience/
> 
> This document updates and clarifies RFC1034 in how a resolver should generate
> random query ID, how to use multiple ports and possibly addresses to make
> it harder to guess the details of a query by a particular resolver.
> 
> Please read the document carefully, in particular section 9. At this point
> the chairs would like to know if the current RFC2119 wording in that
> section is acceptable or how it can be improved.

I basically support this document (although IMO BCP would be better
category since it doesn't directly affect interoperability between
implementations, I don't much care about that point and won't argue
about it), but I have one possibly substantial comment on this draft.

I'm afraid if an implementation naively follows this requirement (or
suggestion):

   o  Use multiple different source ports simultaneously in case of
      multiple outstanding queries;
(from Section 9)

it will open up an additional opportunity for the attacker to cause
denial of service.  That is, the attacker has the target resolver
(caching server) send many queries for domain names controlled by the
attacker, and it then drops the queries.  The resolver needs to wait
for a certain period (depending on implementation details) for each
dropped query, keeping the large number of ports (sockets).  Since the
number of open sockets is often a scarce system resource, it may make
the resolver unable to accept further queries.

This type of attack scenario is not new: a recursive resolver
inherently needs to creates and keep state for outstanding queries,
and there is always a possibility of DoS that tries to eat up the
maximum limit of such states.  But I believe it's worth mentioning
explicitly, since this specific case is a direct consequence of this
particular suggestion, and as I said above, the number of allowable
open sockets can be relatively small.

This scenario has another implication: if the implementation strictly
follows this requirement, the attacker may be able to limit the
possible port numbers that the resolver uses for other meaningful
queries to a much smaller set.  For example, consider an extreme case
where the attacker can cause 65534 outstanding queries, each sent from
different port numbers for 10 seconds.  Then the attacker can be sure
that which port number is used for any other possible queries
(although most of them will fail).

So, I'd like to suggest introducing the following changes/additions:

- add a note of the possibility of DoS attack described above, and
  warn the implementors to mitigate it
- change this bullet of Section 9
   o  Use multiple different source ports simultaneously in case of
      multiple outstanding queries;
to something like this:
   o  Use a new unpredictable source port for each new outstanding
      query (note that the same source port could be chosen for
      multiple different outstanding queries);

I also have some other minor comments (I hope these have not been
pointed out).  I'm referring to an "unpublished version" of the draft,
to be very clear obtained at:
http://ds9a.nl/tmp/draft-ietf-dnsext-forgery-resilience.txt
(as of June 30th, MD5 = 33982dfa077df0803e731627e4a94b18)

- Section 4.5

   If the maximum ports range is utilized, on average, around 32128
   source ports would have to be tried before matching the source port
   of the original question as ports below 1024 may be unavailable for
   use, leaving 64512 options.

  I don't understand where the number "32128" came from.  If this
  means (65536 - 1024) / 2, it should be 32256...

- Section 9

   o  Use an unpredictable source port for outgoing queries from the
      range (53, or > 1024) of available ports that is as large as
      possible and practicable;

I don't understand what "the range (53, or > 1024)" means.  Does that
mean a set of {53, 1025, ..., 65535}?  Besides, I also don't
understand why port 1024 seems to be excluded.  If this tries to
exclude well known port numbers, it should be "> 1023".

- Section 10

   Most security considerations can be found in Section 5, while
   proposed countermeasures are described in Section 9.

At least in the version I'm looking at, Section 5 is "Birthday
attacks", which does not seem to discuss "Most security
considerations"...shouldn't this actually mean Section 4 (Detailed
Description of Spoofing Scenarios)?

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.

--
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: bert hubert <[email-masked]>
Date: Thu, 3 Jul 2008 20:33:43 +0200

> category since it doesn't directly affect interoperability between

Thank you. I've been reading up on the complicated difference between BCP
and Standards Track, and it is not clear to me. I do find BCPs to generally
be far more descriptive and general, reflecting opinion or even 'ideas',
instead of things that you really should be doing. BCP38 is a strong
counterexample. In todays harsh internet climate, BCP38 might be better
served by being an STD perhaps.

> denial of service.  That is, the attacker has the target resolver

This is correct.

> explicitly, since this specific case is a direct consequence of this

I've added "Additionally, care should be taken to prevent resource
exhaustion when using larger amounts of query source ports."

>       multiple different outstanding queries);

This is almost word for word a previous version of this requirement. While I
vastly prefer your wording (or, the original original wording), I'm afraid
this paragraph is starting to suffer from the aforementioned metal fatigue.
It has been tweaked so much it might break.

I've added your suggestion as 'alternate wording' so we can chose at a later
stage.

>   means (65536 - 1024) / 2, it should be 32256...

Thank you - I also do not understand how this error crept in.

> exclude well known port numbers, it should be "> 1023".

I've changed the wording to: 
 Use an unpredictable source port for outgoing queries from the range of
 available ports (53, or 1024 and above) that is as large as possible and
 practicable

> Description of Spoofing Scenarios)?

Thank you again for your very precise reading. I've added section 4 to the
list of reference chapters.

Please find my changes based on your suggestions in
http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/changeset/30

Kind regards,

Bert Hubert

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

---

From: bert hubert <[email-masked]>
Date: Thu, 3 Jul 2008 22:43:11 +0200

On Sun, Jun 29, 2008 at 08:44:47PM +0100, Alex Bligh wrote:
> So I suggest:
> >   "In case these abilities are enabled, the implementation MUST
> >   minimise the ability of third parties to guess the implementation's
> >   future choices of source port and query ID remain even where that
> >   third party has knowledge of both the algorithm
> >   used by the implementation including its (pseudo-)random
> >   generator and all previous wire data"

Thanks Alex - I mangled this into:

  In case these abilities are enabled, the implementation MUST minimise the
  ability of third parties to guess the implementation's future choices of
  source port and query ID even if the third party has knowledge of the
  (pseudo-)random generator employed and all previous wire data.

I hope this is still correct.

http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/changeset/31

	Bert.

---

From: Alex Bligh <[email-masked]>
Date: Thu, 03 Jul 2008 22:43:56 +0100

--On 3 July 2008 22:43:11 +0200 bert hubert <[email-masked]> 
wrote:

>   In case these abilities are enabled, the implementation MUST minimise
> the   ability of third parties to guess the implementation's future
> choices of   source port and query ID even if the third party has
> knowledge of the (pseudo-)random generator [*] employed and all previous
> wire data.

Looks good, but at risk of nitpicking, perhaps insert "algorithm" at [*]
otherwise it can be criticised for exactly the same reason brought up here
a few days ago, i.e. if you know its internal state as well as the
algorithm (as opposed to just the algorithm) it *is* predictable.

Alex

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 9 Jul 2008 09:27:02 +0200

On Thu, Jun 26, 2008 at 04:33:14PM -0400,
 Ólafur Guðmundsson /DNSEXT chair <[email-masked]> wrote 

> http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-forgery-resilience/

I notice in Cisco's advisory
<http://tools.cisco.com/security/center/viewAlert.x?alertId=16183>
this advice "Administrators may consider configuring the TTL of DNS
caches to a relatively short value." But the I-D says "The time to
live of the target domain name's RRSETs determines how often a window
of opportunity is available, which implies that a short TTL makes
spoofing far more viable."

So, I believe that the Cisco advisory is broken. Comments?

---

From: Jelte Jansen <[email-masked]>
Date: Wed, 09 Jul 2008 09:49:10 +0200

> So, I believe that the Cisco advisory is broken. Comments?

I'm not quite sure what they mean with 'TTL of DNS caches'.

But I agree that having low TTL values on your RRSETs gives more windows
of opportunity and no protection at all, since the spoofed packet will
most likely have different TTL values anyway.

The next point, turning off caching completely is interesting too; every
query could be spoofed, but for reliable spoofing, one would need to
spoof every query... but operationally turning off caching completely
might not be a good idea anyway

Jelte

---

From: Alex Bligh <[email-masked]>
Date: Wed, 09 Jul 2008 09:11:21 +0100

> So, I believe that the Cisco advisory is broken. Comments?

Yes I think so, though with a nit.

The Cisco advisory talks about the TTL of "DNS caches" not the
TTL of DNS records (or RRSets). I am not sure what that means, but
perhaps it means applying a maximum to the actual TTL received.

Let's assume they mean "records" not "caches". The draft give advice
for a server operator to minimise the number of queries made to
it for domain names for which it is authoritative and reduce the
incidence of a fake record. The Cisco advisory suggests reducing
the TTL of the records in the cache in order (presumably) to
minimise the time a poisoned record sticks around, and thus
its impact. But any attacker would surely put a large TTL
on the spoofed records in order to maximise their effect (assuming
they weren't seeking stealth). So the only possible useful
interpretation of the Cisco advisory is that they intend for
TTL records to be capped in-cache. If the TTL was higher in
the first place, that will result in more queries, and thus
more opportunities for poisoning. The only question is whether
reducing overall cache TTL also reduces the visibility of the
entropy pool to a rogue server (for instance by interspersing
more valid queries), and whether this effect is greater; if
it is, then it's not actually incompatible with what the ID
suggests.

Alex

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 9 Jul 2008 11:29:24 +0200

On Thu, Jun 26, 2008 at 04:33:14PM -0400,
 Ólafur Guðmundsson /DNSEXT chair <[email-masked]> wrote 
 a message of 28 lines which said:

> This note starts a Working Group Last Call for this Standards Track
> document ending on noon July 12'th 2006 (Dublin time).

Shouldn't we postpone the WGLC to integrate in the I-D the current
alarm?

---

From: Florian Weimer <[email-masked]>
Date: Wed, 09 Jul 2008 12:09:14 +0200

> Shouldn't we postpone the WGLC to integrate in the I-D the current

If you'd make that the *cause* of the current alarm, I tend to agree.
On the other hand, I think it's unfair to delay the process by yet
another month (after which we still have to agree on the exact
wording).

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Alex Bligh <[email-masked]>
Date: Wed, 09 Jul 2008 11:31:27 +0100

> another month (after which we still have to agree on the exact

As far as I can see, even if the draft does not document the precise
threat model illustrated by the current alarm (which are apparently
not yet fully public anyway), the recommendations resulting from it
are correct in the draft - with the possible exception of the TTL
comment which I now understand better.

Alex

---

From: bert hubert <[email-masked]>
Date: Wed, 9 Jul 2008 20:31:41 +0200

> another month (after which we still have to agree on the exact

The draft stands on its own merits. I can ammend the formulae with a note
that there are tricks that make the math very optimistic, which only
strengthens the case.

As far as I know, but I don't know everything, there is nothing more
specific to be done against Dan's issue than what is already in the draft.

I'm aware of the details of what Dan has discovered, but it might be that
someone has discovered something even smarter to counteract it.

If this is so, that might be reason to stall the draft until after Dan's
announcement, and only then incorporate the countermeasures publicly.

	Bert

---

From: Paul Vixie <[email-masked]>
Date: Wed, 09 Jul 2008 14:55:51 +0000

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

> Shouldn't we postpone the WGLC to integrate in the I-D the current alarm?

the recommendations in the draft cover the current alarm, and i say this with
some awareness of the underlying cause of that alarm which won't be publically
disclosed by dan until blackhat/defcon.  i do not think we can add value to
this document by delaying or editing it further.

however, i had suggested a major replacement of text, based on the desire by
some that this document be a STD rather than a BCP.  i've seen no resolution
there.  so, WGLC has stalled or failed, but not because of the current alarm.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 10 Jul 2008 22:29:25 +0200

* bert hubert:

> The draft stands on its own merits.

I agree, I think it's really helpful.  If you want to proceed, you
should.

(I'm not familiar with the IETF processes, so I let others to sort out
the procedural issue Paul has raised.  However, I think it's best to
avoid any changes that cause further delays.)

---

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Thu, 10 Jul 2008 18:25:14 -0400

Dear Colleagues,

We seem to have at this point enough reviewers.

Minor issue: The draft says it is updating RFC1034 that should be RFC1035.

Major issue has been raised: Standards Track or BCP.

At this point there is no consensus one way or the other.

The overall effect is limited to section 9 (Recommendations) as it
is today is written for standards track.
http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience-05#section-9

It has been argued that source port selection is not per say a standards
issue as it does not affect interoperabilty.

Simple Boolean Question:
Does the requirement that answer match all of the following
         <src ip, src port, qid, qname, qclass, qtype>
warrant a standards action?

Background: RFC1035 section 4.2.1 is silent on if the answer should 
come from the same
address and port that the question was sent to. Thus it can argued that any
message that matches <qid, qname, qclass, qtype> is all that is needed.

Once we have resolved the status question, section 9 can be tuned to the
appropriate status.

         Olafur

---

From: Mark Andrews <[email-masked]>
Date: Fri, 11 Jul 2008 10:22:17 +1000

> message that matches <qid, qname, qclass, qtype> is all that is needed.

	Look at the UDP specification.  It says that reply traffic
	should come from the same port and address that the request
	was sent to.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 11 Jul 2008 16:07:46 +0300

> message that matches <qid, qname, qclass, qtype> is all that is needed.

RFC1035 may be silent, but RFC2181 is loud and clear.  Section 4.1:

   [...] servers when responding to queries using UDP
   must cause the reply to be sent with the source address field in the
   IP header set to the address that was in the destination address
   field of the IP header of the packet containing the query causing the
   response.

Section 4.2:

   Replies should always be sent from the port to which they were
   directed.

The "should" above is really a MUST because of the somewhat unusual
terminology defined in section 3.
-- 
Andreas Gustafsson, [email-masked]

---

From: Peter Koch <[email-masked]>
Date: Sat, 12 Jul 2008 13:15:35 +0200

> section is acceptable or how it can be improved.

I have read version 5 of the forgery resilience draft. The remarks here
are follow ups to my review of version -03
<http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00695.html>.
I've also read the WGLC discussion, but did not follow all proposed and/or
preliminary changes in the text, so there might be duplications here,
with apologies.

Generally I support this draft moving forward.  I maintain my position
that BCP is more appropriate than standards track, because the draft
does not change "on-the-wire" behaviour beyond what 1034/5 and the subsequent
clarifications in 1123 and 2181 say. Instead it recommends (for the sending
side) to exploit a degree of freedom that has always been in the protocol.
I see no way elevating this on standrads track based on interoperability tests.

I have no issues with the normative language in section 9 though, with one
exception (see below).

However, the draft has some terminology issues that should be fixed
and there are security aspects in the deployment of this recommendation
that need to be mentioned (below).

-----------------------------------------------------------------------------
doc walk through:

Introduction:
1st paragraph, self-reference: s/this RFC/this document/

last paragraph
  I support changing "For protocol extensions under development" to leave
  out "under development".

NITs:
  s/RRSET/RRSet/g
  s/IPSEC/IPsec/g

Section 4.1:
  Forcing a _query_, some other occurences where "question" should be replaced
  with "query", same in 4.5

Section 5:
   An attacker can benefit from this exact phenomenon if it can force
   the target resolver to have multiple equivalent outstanding queries
   at any one time to the same authoritative server.

... where "equivalent" means that QNAME/QTYPE/QCLASS are identical.

Section 6:

> 6.  Accepting only in-zone records

That should be "in-domain", because the resolver can't tell the zone
boundaries.

   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.

... authoritative for the QNAME or a parent of the QNAME.

Same reason: zone cuts are invisible.

IMHO the document could benefit from an example here (see my earlier
posting for a suggestion).

Section 7:

   = 65000 packets, assuming a domain has 2 authoritative nameservers.

s/domain/zone/

Section 8:

   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 response
   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
   minutes, 50% after less than 3 hours, 90% after around 9 hours.

Domains don't have TTLs, so s/domain/RRSet/ (in both paragraphs).

Section 9:

   address MUST match the query's source IP address.  A mismatch should
   be considered a format error, and the response invalid.

How should the resolver treat an "invalid" response?  I'd guess silently
dropping it and waiting for the next would be preferrable over sending
FORMERR to the querying client?

typo: >= 1024

   In case these abilities are enabled, the implementation MUST strive
   to have its choices of source port and query ID remain unpredictable,

That's the normative language I think could be improved - independent of
BCP vs. standards track: "MUST strive" implies "nice try".
"MUST minimize the predictablity ... " or similar would get rid of these
connotations.

> 10.  Security Considerations

The mutual effect of source port randomization on forewalls and NATs
has been mentioned before.  If nothing more, the security considerations
must mention that ...

"The effects of source port randomization may be dramatically reduced
by NAT devices which either serialize or limit in volume the UDP source
ports used by the querying resolver."

-----------------------------------------------------------------------------

As said before, sections 7 and 8 are of purely educational nature
and would better fit in an appendix.  I'd consider it slightly less important
for a BCP, though.

Finally, since there has been a lot of discussion and a significant number
of changes in WGLC, I'd humbly ask the chairs to give reviewers another
week after the publication of -06 to check all the changes in context.

-Peter

---

From: bert hubert <[email-masked]>
Date: Wed, 30 Jul 2008 20:56:30 +0200

> 1st paragraph, self-reference: s/this RFC/this document/

done

>   I support changing "For protocol extensions under development" to leave

:-) If you really want. I'd hope they would still see development though.

>   s/IPSEC/IPsec/g

Done.

>   with "query", same in 4.5

In some places this weirds the language - we ask questions, not queries.
I've changed over the other places.

> ... where "equivalent" means that QNAME/QTYPE/QCLASS are identical.

Added.

> Same reason: zone cuts are invisible.

Done.

> posting for a suggestion).

I'll dig it up.

> Domains don't have TTLs, so s/domain/RRSet/ (in both paragraphs).

Done.

> FORMERR to the querying client?

Perhaps - the language now says the response is invalid, and leaves it up to
the resolver.

>       possible and practicable;

Addressed in another way in an earlier revision, but the result is the
same.

> "MUST minimize the predictablity ... " or similar would get rid of these

This paragraph has been dropped and replaced by new language.

> ports used by the querying resolver."

Fine words, thanks.

Please find your updates in
http://adsl-xs4all.ds9a.nl/cgi-bin/resilience.fcgi/changeset/33

	Bert