Subject: Re: [dnsext] Re: Time-line for forgery resilience phase #2

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Wed, 12 Nov 2008 10:26:08 -0500

Dear colleagues
It has been rather quiet on the mailing list on this topic.
So far only 3 people have volunteered to be on the design team.
         Nicholas Weaver
         Matt Larson
         David Blacka
The chairs are looking for a design team that includes people from
different backgrounds and experiences. In particular we are looking
for volunteers from the ISP and non-TLD authorative server side.
(contact me privately if you want to be included, only vetted volunteers
will get the magic email telling them the location of the design team
gathering).

If you think this effort is important, please volunteer, or say on the
mailing list what your "solution space would look like" as a template for
the design team to look at.

In addition if there are operational practices that we should recommend please
put them forward as well.

         thanks
         Olafur

At 15:24 17/10/2008, Ólafur Guðmundsson /DNSEXT wrote:

>Dear colleagues,
>
>Thank you for taking the suggestions below to heart and following the plan.
>
>At this point we have following drafts submitted:
> 
>http://tools.ietf.org/id/draft-barwood-dnsext-fr-resolver-mitigations-04.txt
>   http://tools.ietf.org/id/draft-reid-dnsext-aleatoric-00.txt
>   http://tools.ietf.org/id/draft-weaver-dnsext-fr-comprehensive-00.txt
> 
>http://tools.ietf.org/id/draft-wijngaards-dnsext-resolver-side-mitigation-00.txt
>   http://tools.ietf.org/html/draft-hubert-ulevitch-edns-ping-00
>   http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00
>
>If we forgot any please reply to this message with the link for the draft.
>
>The forum is now open for discussion.
>We propose that you start a new thread for each subject rather than just reply
>to this message, in the Subject line put
>         FR: Topic
>
>As far as we can tell the ideas contained in the drafts can be summarized into
>following rough categories:
>         Packet acceptance
>         Data admission
>         Data integrity checks
>         Attack detection
>
>Please use these words in your messages to facilitate clearer understanding.
>Feel free to propose new categories.
>
>In Minneapolis the WG is scheduled to meet on Tuesday afternoon.
>The chairs have asked for a small meeting room on Monday (during one
>of the first 2 sessions) and on Tuesday morning for a "design" team to meet.
>If you want to be invited to these meetings send us an e-mail, we want to
>get a broad balance of expertise and experience in that room.
>The "design" team will present the recommendations (if any) at the
>Working Group meeting.
>
>         Olafur and Andrew
>
>At 12:22 04/09/2008, Ólafur Guðmundsson /DNSEXT wrote:
>
>
>>The WG has had 2 months to learn about the issues and kick ideas around.
>>At this point the discussion has reach the point of diminishing returns.
>>The discussion needs to become more focused!
>>
>>The chairs propose following plan to make progress:
>>0. Discussion on namedroppers on ideas without drafts comes to an end.
>>    If you need to ask a clarifying question, please put the tag [CLARIFY] in
>>    your Subject: line.
>>
>>1. By September 30'th  everyone that has ideas they want to share
>>    should have an ID published.
>>    suggested names for drafts: draft-<editor>-dnsext-fr-<name>-xx.txt
>>
>>2. During October the WG will discuss the ideas and recommendations from the
>>    drafts.  Editors are encouraged to update their drafts frequently during
>>    this window based on the discussions.
>>
>>3. During November the WG will select from the ideas on what to recommend as
>>    the extended Forgery Resilience approach.
>>    The chairs plan to have a special session early in the week at the IETF
>>    meeting for interested parties to hash out what makes sense.
>>    Recommendations from that session will be proposed to the WG at
>>    the official WG meeting.
>>
>>4. If the WG does not reach a rough consensus by late November the chairs
>>    may form a design team to come up with a recommendation.
>>
>>5. An official WG document(s) will be submitted no later than early
>>    December.
>>    (we will need editors for this document(s))
>>
>>6. By late January we will have WGLC on the document(s).
>>    The document(s) will be advanced to the IESG by March 1'st.
>>
>>Based on this plan, please stop all Forgery 
>>Resilience (FR) discussion right now.
>>If you are not writing down your FR ideas in a draft,
>>please review and comment on the following WG last calls:
>>
>>http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01190.html
>>http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01430.html
>>
>>         Olafur and Andrew

---

From: bert hubert <[email-masked]>
Date: Thu, 13 Nov 2008 21:47:59 +0100

Ok, this is somewhat of a tricky post since my own draft is among the ones
circulated. Additionally, some of the criticism I voice below applies
to the original forgery-resilience draft as well.

So take the below with more than a single grain of salt.

Sadly it appears we have not found the magic bullet, where magic bullet is
defined as a clear solution that can help us quickly. This rules out
anything that takes a lot of parties and time to deploy, or anything that is
more of a 'strategy' than a clear cut solution.

0x20 is nice, but breaks some stuff. Repeating queries is nice but breaks
some stuff. Determining if we are under attack is nice, but is a DoS vector
in some circumstances. Getting smart with disregarding parts of answers is
nice, but is not a perfect solution, plus might break some stuff. Etc etc.

Summarising, I think the current state of affairs does not allow us to write
a draft that recommends full solutions. Sadly, the best we can do right now
is standardise things that will give implementors the tools to implement
working strategies, strategies which are unkown right now.

There is some room for a concise document outlining simple things that help
a lot though.

>  http://tools.ietf.org/id/draft-barwood-dnsext-fr-resolver-mitigations-04.txt

Describes a number of valuable strategies, and mandates some others.
Unsure if it would reach consensus.

>  http://tools.ietf.org/id/draft-weaver-dnsext-fr-comprehensive-00.txt

Outlines a lot of theory. Reads like an academic paper. Does not mandate
anything, or at least not in capital letters.

>  http://tools.ietf.org/html/draft-hubert-ulevitch-edns-ping-00

Both of these provide a way to add more entropy to a query, making it far
harder to spoof answers. One of these drafts uses a new record type, the
other (mine) a new EDNS0 option. Jim Reid did a great job finding a novel
and very hackish way of stuffing in said entropy.

The interesting thing about the above two drafts is that they only provide a
portal which can be used to develop further spoofing resilience. The
strategy of how to use these methods is left up to the caching nameserver
implementations, and this strategy is therefore free to evolve over time.

>  http://tools.ietf.org/id/draft-wijngaards-dnsext-resolver-side-mitigation-00.txt

I find this draft to be concise, and it provides a nice mix between theory,
recommendations and exhortations. 

>  http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00

0x20 is an impressive hack, but does not provide any protection for
numerical domains like '123.', and only two bits for '123.nl'. In this
sense, it is a very limited measure - as it leaves TLDs especially
vulnerable.

What would be good is to slip in somewhere that all responding
implementations MUST do a bitwise copy of the request name. Implementations
are then free to act on the liberty they've gained to assume that complying
responders will do a proper copy.

Summarising, I'd prefer to focus our attention on: 

	1) Wouter's document, since it is brief and has the potential to reach
	consensus.

	2) One of the two ways to add entropy to queries (aleatoric,
	   edns-ping)

An optimum might be reached if Wouter's document would contain a line like
'responders MUST perform a bitwise copy of the query name'. This would open
the door over time for people to rely on 0x20.

Kind regards,

Bert

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

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 13 Nov 2008 15:35:56 -0800

My kg of salt as well.

On Nov 13, 2008, at 12:47 PM, bert hubert wrote:
> in some circumstances.

Repeating queries does not break anything if the model is "Return the  
results of a THIRD query if no agreement on the first two RRSets or  
all three RRSets" for generating two duplicate requests.

For such cases, if the real authority is NON-volatile and you are  
under attack, the attacker has to win one of two races and then a  
subsequent race:  with K bits of entropy, this ends up being roughly 1  
in 2^(2k-1), which is the entropy increase duplication tries to get you.

If the real authority is nonvolatile, it just resolves fine with two  
parallel queries, so it sees more load but is otherwise unaffected as  
the name resolves correctly in the same amount of time.

IF the real authority is volatile, it sees three queries instead of  
one, so it sees more load but is otherwise unaffected: all names  
resolve correctly, and it sees only one additional RTT to resolve the  
name (as the first two queries can be done in parallel).

> Getting smart with disregarding parts of answers is

If you are referring to the scoping-model of bailywick checking I  
proposed (and Unbound attempts to approximate), it actually does the  
opposite:  it allows you to safely resolve some pathological cases  
which you can not resolve with the current bailywick-acceptance model.

> implementations, and this strategy is therefore free to evolve over  

Any change which requires changes to ALL or a large number of  
authoritative servers should be considered a non-starter.  If you can  
get authorities to change behavior, get them to turn on DNSSEC.

Finally, since there was a complaint on my draft about not including  
CAPS recommendations (when I was drafting it, I was encouraged by a  
colleague NOT to include the caps-words because it can trigger  
needless debate).  But since they are wanted, here they are:

It would be a good idea (slightly less than SHOULD, in the "Useful but  
not critical"):  A recursive resolver should treat a "changed  
duplicate response" (two responses for the same transaction with  
different values) as an attack, void any cache entry associated with  
this, as this gives an out-of-band signal of attack, and as validation  
shows this is very rare.  The stateholding is actually reasonable, but  
there are some objections on that, thus it should only be in the "good  
idea" category.

SHOULD:  A stub resolver SHOULD treat "changed duplicate response" as  
an attack, as the stateholding requirements are trivial at this level  
to do this detection, and this gives an implicit signal that recursive  
resolvers can use to signal problems.

SHOULD:  A recursive resolver SHOULD institute scoping rules or data  
validation:  the cost is reasonably low (verified by trace-based  
analysis), it does not cause errors on resolution, and it enables any  
authority which desires it to gain a far larger protection for its  
names (because TTL becomes meaningful again, even just 60s TTLs  
magnify attacker time by about 100x with reasonable network RTTs).

SHOULD:  A recursive resolver SHOULD detect when it is under blind  
attack and do something (this needs to be discussed in more detail  
monday/tuesday, both Barwood and Kaminski have proposed duplication.   
I've initially resisted this, but the more I think about it, the more  
they may be right.   And I don't think its a succesful DOS vector)

MUST:  A recursive resolver which is attempting to increase entropy  
through various means MUST verify that it is not being stripped out by  
some middlebox by performing queries to a customized authority.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 13 Nov 2008 16:15:07 -0800

On Nov 13, 2008, at 3:35 PM, Nicholas Weaver wrote:

> Repeating queries does not break anything if the model is "Return  
> the results of a THIRD query if no agreement on the first two RRSets  
> or all three RRSets" for generating two duplicate requests.
>
> subsequent race:  with K bits of entropy, this ends up being roughly  
> 1 in 2^(2k-1), which is the entropy increase duplication tries to  
> get you.
>
> parallel queries, so it sees more load but is otherwise unaffected  
> as the name resolves correctly in the same amount of time.
>
> resolve correctly, and it sees only one additional RTT to resolve  
> the name (as the first two queries can be done in parallel).

OOPS. This doesn't work on volatile authorities, never mind.

> authoritative servers should be considered a non-starter.  If you  
> can get authorities to change behavior, get them to turn on DNSSEC.
>
>
>
> It would be a good idea (slightly less than SHOULD, in the "Useful  
> but not critical"):  A recursive resolver should treat a "changed  
> this, as this gives an out-of-band signal of attack, and as  
> validation shows this is very rare.  The stateholding is actually  
> reasonable, but there are some objections on that, thus it should  
> only be in the "good idea" category.
>
>
> SHOULD:  A stub resolver SHOULD treat "changed duplicate response"  
> as an attack, as the stateholding requirements are trivial at this  
> level to do this detection, and this gives an implicit signal that  
> recursive resolvers can use to signal problems.
>
>
> analysis), it does not cause errors on resolution, and it enables  
> any authority which desires it to gain a far larger protection for  
> its names (because TTL becomes meaningful again, even just 60s TTLs  
> monday/tuesday, both Barwood and Kaminski have proposed  
> duplication.  I've initially resisted this, but the more I think  
> about it, the more they may be right.   And I don't think its a  
> succesful DOS vector)
>
>
> through various means MUST verify that it is not being stripped out  
> by some middlebox by performing queries to a customized authority.
>
>
> --

---

From: Otmar Lendl <[email-masked]>
Date: Sun, 16 Nov 2008 23:45:13 +0100

Nicholas Weaver wrote:
>> harder to spoof answers.

> authoritative servers should be considered a non-starter.  

You're right in terms of a resolver-only, short-term fix.

> If you can

This is IMHO wrong.

A patch to implement e.g. edns-ping is a trivial software update which
can be automatically rolled out on a huge number of platforms as
part of an automatic system update. (e.g. a new debian package, or via
windows update) The humans operating the nameserver don't have to think
about this as long as it's turned on by default.

DNSSEC requires a change in not only software (and in some cases, not just
an update, but a product change), but also in procedures, responsibilities,
interfaces to the registrar, perhaps internal interfaces regarding
sub-domains, combined with a host of new pitfalls (key rollover, lost keys,
...)

This so reminds me of Star Trek: They have these nice high-tech
anti-gravity shock absorbers to keep the effects of foreign forces
from reaching the crew. Invariably though, the first foreign photon
torpedo will jolt everybody out of their chairs on the bridge because they
forgot to install such low-tech devices like seat-belts.

According to my latest numbers from Austria, about 90% of the queries
towards the .at nameservers come from nameservers implementing some form
of port randomization. The not quite that trivial upgrade following the
July announcement was thus indeed rolled out on a rather broad scale.
That still is not as good as one might hope (especially when looking at
nameservers, not queries), but it gives reason to believe that a simple
EDNS0 patch has a good change of seeing wide deployment within a year.

DNSSEC uptake is probably by at least an order of magnitude slower.

I strongly recommend we install seat-belt regardless of whether we manage
to get the anti-grav shock absorbers in place.

/ol
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 //

---

From: "Antoin Verschuren" <[email-masked]>
Date: Mon, 17 Nov 2008 12:50:59 +0100

> -----Original Message-----
> From: [email-masked] 
> Subject: Re: [dnsext] Re: Time-line for forgery resilience phase #2
> 

And this is exactly where I have an issue.
Rolling out all these forgery resilience temporary solutions might be trivial, but rolling them back when they are not needed anymore is not. Once the code is out there, we're stuck with it. Even after DNSSEC has been widely deployed, which I believe is coming on steam right now.

One other thing about most forgery resilience solutions like edns-ping is that I don't see any any analysis on what these solutions might do to real live deployed DNS infrastructure. We don't live in an ideal world, and I fear that solutions like this will multiply the bad DNS traffic like dropcatching and MX scanning and any NXdomain queries more than regular traffic that do get an answer out of distributed authoritative servers or caches. The relative cost of answering those bad traffic queries will be mostly laid upon servers closer to the root like TLD servers. In the original design of the DNS and in an ideal world, queries should be distributed over the whole infrastructure, and I fear we might see that the extra traffic burden is focused on some particular points in the infrastructure to a point where we cannot talk about a distributed database anymore. That will harm the robustness of the DNS. We might be on our way to centralized databases instead of DNS. I would like to see that examined before we roll out code.

Antoin Verschuren

Technical Policy Advisor
SIDN
Utrechtseweg 310
PO Box 5022
6802 EA Arnhem
The Netherlands

T +31 26 3525500
F +31 26 3525505
M +31 6 23368970
E [email-masked]
W http://www.sidn.nl/