Subject: Re: deprecating dangerous bit patterns and non-TC non-AXFR

From: Paul Vixie <[email-masked]>
Date: Wed, 20 Aug 2008 15:27:03 +0000

i started a thread on dnsop that really belongs on namedroppers.  moving it.

florian weimer wrote, quoting paul vixie:

> [QTYPE=ANY deprecation]
> 
> > so, can you explain what you mean by "breaks", both for sendmail and
> > qmail?
> 
> I thought deprecation means that responders (especially resolvers) are
> free to discard such queries.  At least that's how the binary label
> deprecation was interpreted by some folks.  I don't see how this would
> be different, at least for resolvers.

i propose that an empty answer be sent, so that anyone waiting on it
would know to move on to their next state.

> [QCLASS != IN deprecation]
> 
> > i don't think we should foreclose the possibility that QCLASS != IN
> > will be useful to somebody some day.  do you know a specific risk
> > for QCLASS != IN?
> 
> Reducing the arbitrariness of the DNS header reduces the risk that you
> run into a query/response loop with some other service (like chargen
> or time).

that's not a specific enough risk to warrant outlawing a bit pattern, imho.

> >> > 	RA=1 AND RD=0
> >> 
> >> By the responder or the initiator?
> >
> > nonrecursive queries of recursive servers [snip]
> 
> Ahem, my concern was that the RA bit is set by the responder, while
> the RD bit is set by the initiator.  RA=1 *queries* don't make much
> sense, no matter what the RD bit is.  As Peter Koch noted, RA=1, RD=0
> responses occur in the wild.  So I was confused.

so you're OK with my proposal that if a responder has no authority data
matching the question and RD=0 that it should send back an empty answer?

> [DNS over TCP deprecation]
> 
> >> I strongly oppose this approach.  Unsolicited TCP has its place.
> >
> > are you strongly in favour of amending RFC 1035 4.2.2 to say that
> > responders initiate close, or that timeouts of less than two minutes
> > are allowed?
> 
> No need to update RFC 1035, RFC 1123 already did that: "A name server
> MAY limit the resources it devotes to TCP queries" (section 6.1.3.2).

its justification for this is the 512 octet barrier then in force, and so
i can see that this text should have been explicitly modified by RFC 2671
since there is now a well defined non-TCP method of crossing that barrier.

however, that section also begins as follows:

         6.1.3.2  Transport Protocols

            DNS resolvers and recursive servers MUST support UDP, and
            SHOULD support TCP, for sending (non-zone-transfer) queries.

so, TCP/53 is already optional, which explains why so many people treat
it as optional.  word on the street is, if you're not answering AXFR and
you never set the TC bit in UDP/53, you don't have to implement TCP/53.
what i didn't realize until you referenced RFC 1123 6.1.3.2, is that this
isn't just the word on the street, it's well supported in the scriptures.

anyone who proposes TCP/53 as a fallback during keyhole attacks, take note:
it's not required; and if implemented, it's incredibly vulnerable to attack;
and in any case it will not scale.

> > did RDP (RFC 908, RFC 1151) ever achieve critical mass?
> 
> Not likely, given that the acronym has been reused for something totally
> different.  I think for reliable datagram transport with some deployment,
> you need to use SCTP.  I've never seen this RDP in the wild.

ok, same question then.  is SCTP something we should consider as a way out
of our bad choice between IP fragmentation and TCP for messages larger than
the MTU?  <http://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol>
makes it sound safe and wonderful.  "man 4 sctp" on FreeBSD looks healthy.

as always, my big concern is "what will the middleboxes do?"

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

--
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: Florian Weimer <[email-masked]>
Date: Wed, 20 Aug 2008 18:54:20 +0200

* Paul Vixie:

> i propose that an empty answer be sent

What can stand as an empty answer?  REFUSED?

As a general rule, I think we shouldn't generate new cases where we
don't echo back the question section.

> so you're OK with my proposal that if a responder has no authority
> data matching the question and RD=0 that it should send back an
> empty answer?

I think this was previously discussed on namedroppers, and there
wasn't any consensus back then.  (Another option besides REFUSED is
referral to the root.)

[DNS over TCP]

> it as optional. 

According to the quoted sentence, is optional on the initiator, not on
the responder.  However, operators treat it as if it were optional on
the responder.

> word on the street is, if you're not answering AXFR and you never
> set the TC bit in UDP/53, you don't have to implement TCP/53.

Yes, but I think this is wrong.  Read on:

  A name server [...] SHOULD NOT refuse to service a TCP query just
  because it would have succeeded with UDP.

Generally filtering TCP queries is against that recommendation.

> what i didn't realize until you referenced RFC 1123 6.1.3.2, is that
> this isn't just the word on the street, it's well supported in the
> scriptures.

I've been beating this drum for years, but there's this bizarre
assumption that RFC 1123 is not as normative as RFC 1035. 8-/

> is SCTP something we should consider as a way out

No, it's not.

-- 
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: Mohsen Souissi <[email-masked]>
Date: Wed, 20 Aug 2008 19:28:00 +0200

Paul,

Please let me comment on the way your note below:

 On 20 Aug, Paul Vixie wrote:
[...]

 | 
 | > [DNS over TCP deprecation]
 | > 
 | > >> I strongly oppose this approach.  Unsolicited TCP has its place.
 | > >
 | > > are you strongly in favour of amending RFC 1035 4.2.2 to say that
 | > > responders initiate close, or that timeouts of less than two minutes
 | > > are allowed?
 | > 
 | > No need to update RFC 1035, RFC 1123 already did that: "A name server
 | > MAY limit the resources it devotes to TCP queries" (section 6.1.3.2).
 | 
 | its justification for this is the 512 octet barrier then in force, and so
 | i can see that this text should have been explicitly modified by RFC 2671
 | since there is now a well defined non-TCP method of crossing that barrier.
 | 
 | however, that section also begins as follows:
 | 
 |          6.1.3.2  Transport Protocols
 | 
 |             DNS resolvers and recursive servers MUST support UDP, and
 |             SHOULD support TCP, for sending (non-zone-transfer) queries.
 | 
 | so, TCP/53 is already optional, which explains why so many people treat
 | it as optional.  word on the street is, if you're not answering AXFR and
 | you never set the TC bit in UDP/53, you don't have to implement TCP/53.
 | what i didn't realize until you referenced RFC 1123 6.1.3.2, is that this
 | isn't just the word on the street, it's well supported in the scriptures.
 | 
 | anyone who proposes TCP/53 as a fallback during keyhole attacks, take note:
                                                                    ^^^^^^^^^
 | it's not required; and if implemented, it's incredibly vulnerable to attack;
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 | and in any case it will not scale.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I agree with you that supporting EDNS0 (RFC 2671) is far much better
and scalable than TCP fallback in case od DNS response size exceeding
512 octets.

Note that same section 6.1.3.2 says:

"However, it is also clear that some new DNS record types defined in
the future will contain information exceeding the 512 byte limit that
applies to UDP, and hence will require TCP.  Thus, resolvers and name
                               ^^^^^^^^^^^
servers should implement TCP services as a backup to UDP today, with
the knowledge that they will require the TCP service in the future."
                             ^^^^^^^

As RFC 2671 could have made EDNS0 a MUST and TCP fallback simply
deprecated when EDNS0 has taken over (but it actually didn't), I think
we have reached today that "future" with IPv6 and DNSSEC each alone
or combined (worse!).

So unless, all intermediate entities from the stub-resolver to the
ADNS are EDNS0-capable, TCP fallback stays the only possible solution
to get a valid (complete) DNS response back to the stub-resolver *if*
the response size exceeds 512 octets.

Shouldn't your warning above at least equally stress the importance of
EDNS0 being deployed throughout the DNS resolution chain (including
middle-systems like NATs/firewall et al.)?

Hence, does this re-wording proposal make sense?

"You MUST support EDNS0 on all your DNS components. 

- If/when you have done it, then you MAY (SHOULD?) stop supporting TCP
  for non XFR activity (still MUST for XFR),

- If you don't support it (for whatever reason), then you SHOULD
  (MUST?) support TCP as a fallback facility for resolution activity
  (still MUST for XFR)."

So why am I bringing this?

1) I'm simply afraid that some ISPs or other vendors who will read you
and who will not support EDNS0 (for whatever reason), will also
(continue to) block TCP fallback, thus denying DNS service to their
customers should the response size exceed 512 octets.

2) It is directly related to the discussion which took place on dnsext ml
while editing dns-protocol-profile:
http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00037.html
(see section 4.2.2).

The I-D expired on Jul 22nd, a copy is available here:
http://ietfreport.isoc.org/idref/draft-ietf-dnsext-dns-protocol-profile/

This I-D should be recycled in the near future as I understood from
last dnsext session @ IETF. And then, the result of the current debate
may be helpful for people in charge of editing next version dns-protocol-profile...

Mohsen.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 20 Aug 2008 18:24:15 +0000

> What can stand as an empty answer?  REFUSED?

ANCOUNT=0

> don't echo back the question section.

the question section MUST be present or the answer won't be recognized.

> the responder.  However, operators treat it as if it were optional on

it says "and servers" and means it.  there's a restatement later on:

            DNS servers MUST be able to service UDP queries and SHOULD
            be able to service TCP queries.

i think the authors showed in this sentence that they knew the difference
between SHOULD and MUST, and chose with their eyes wide open.  not that we
have to grant these authors omniscience, but these are the unambiguous words
that have guided the installed base.

> Generally filtering TCP queries is against that recommendation.

while it strongly implies that one's intention to never truncate is not
grounds in and of itself to not implement TCP, it still says SHOULD not
MUST, leaving it up to the implementors or operators of responders (or
their firewalls) to leave out TCP and still be completely compliant with
RFC 1123.

> > is SCTP something we should consider as a way out

can you say more?

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 20 Aug 2008 16:05:11 -0400

<no-hat>
> > What can stand as an empty answer?  REFUSED?

RCODE=REFUSED seems to me to be a cleaner solution and as nameserver
are allowed to send that back any time it likes, this is not even a
hit of protocol change.
Someone can just write a short document
"QTYPE=ANY considered harmful, just REFUSE them"  :-)
to document the practice and point the people at that complain.

Root referral is UGLY and misleading.
> > > is SCTP something we should consider as a way out

After looking at using SCTP for DNS,
I kind of agree with Florian but it would be nice if someone that understands
the details of the different transport protocols would tell us why.

         Olafur

---

From: [email-masked]
Date: Wed, 20 Aug 2008 22:52:29 +0100

> middle-systems like NATs/firewall et al.)?

Many SOHO NATs are somewhat broken with respect to EDNS0, at least 
whenever their built-in ALGs are used (as is normally the case according 
to default DHCP settings).

I'm going to be offline for the next week, but very shortly thereafter the 
report on DNSSEC compatibility in SOHO CPE that I and another researcher 
have been working on will be published with all the gory details.  I'll 
also be presenting this at the OARC Workshop on September 24th.

Another consideration is that both Bind and Unbound cap their UDP TX 
packet size to 4096 bytes, regardless of how high the client's OPT RR 
receive packet size is.  That, at least, is easily fixed.

Ray

-- 
Ray Bellis, MA(Oxon)
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Aug 2008 09:44:19 +1000

> their firewalls) to leave out TCP and still be completely compliant with

I seriously doubt that most firewall admins that turn off DNS/TCP
have put the requisite thought into the process to meet the
requirements levels to break a SHOULD.

The number of times that it is justified by "TCP is only used for
AXFR" make it clear that the care and thought that should have been
applied wasn't.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Aug 2008 10:20:03 +1000

> to document the practice and point the people at that complain.

	We have load balancers that send REFUSED rather than NOERROR
	for AAAA queries today.  These cause operational problems.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Aug 2008 17:32:19 +0200

I kind of agree with Florian but it would be nice if someone that
   understands the details of the different transport protocols would
   tell us why.
   
=> IMHO DCCP is a better candidate but what we need is a transaction
oriented transport... As far as I know the last proposal was T/TCP
and nothing serious emerged after even there is a "market" for this.

A workshop at the next IETF?

Regards

[email-masked]

PS: for SCTP none of the nice features of SCTP has an interest for the
common DNS (i.e., the part which uses UDP when the payload is not over
sized, not AXFR where SCTP makes sense). As these features are not
always for free SCTP has no definitive advantage over TCP and clearly
can't take the place of UDP (for DNS).

---

From: Paul Vixie <[email-masked]>
Date: Thu, 21 Aug 2008 16:32:06 +0000

Francis Dupont <[email-masked]>:

> Olafur Gudmundsson <[email-masked]>:
> 

here are two articles on dnsop by bill fumerola in response to this thread
there.  since sctp is slightly older and is used in ip telephony and is
implemented on more systems and allows data transfer on the second round
trip (packets 3 and 4), i'm more hopeful for it than i am for DCCP.

> A workshop at the next IETF?

i'd like to make significant progress by e-mail, open workshops, and
concalls, rather than gating progress to thrice-yearly IETF meetings.  i
know i said that in the MODA proceedings, but i've since then been proved
right, but now we've seen a 10-hour attack against the only mitigation
we've got.  we won't have MODA but we can gather interested parties and get
significant work done in between IETF meetings now that we're all motivated.

> can't take the place of UDP (for DNS).

i see five reasons why SCTP is worth looking at as a primary transport with
UDP as its fallback.  first, data transfer can take place in the second
round trip (packets 3 and 4).  second, it has 32-bit ID fields so we could
go back to fixed port numbers perhaps even fixed+increment on TXID's.
third, we could mandate EDNS, and with it, we could mandate PING.  fourth,
SCTP has the idea of "passive" sockets which mean nonquadratic socket pool
sizes.  fifth, association timeout is handled in the stack not the app.

i see two gigantic challenges for ANY non-UDP transport: installed base of
DNS protocol agents; installed base of firewalls and NATs and middleboxes.

here's bill fumerola's text from dnsop.  two messages attached:

Subject: tcpm's SADATA
From: bill fumerola <[email-masked]>
To: Paul Vixie <[email-masked]>
Cc: [email-masked]
Date: Wed, 20 Aug 2008 12:20:21 -0700

On Wed, Aug 20, 2008 at 02:41:41PM +0000, Paul Vixie wrote:
> with rich stevens gone and nobody to complete or champion T/TCP, we're left
> with several bad multipacket protocols including IP fragmentation and TCP for
> handling data larger than the MTU.  i don't know how to make TCP scale for
> this, it's not like TCP/80 where server operators who want to handle a million
> simultaneous queries know that they'll need a lot of silicon+power to do it.

http://tools.ietf.org/html/draft-agl-tcpm-sadata-01
https://datatracker.ietf.org/drafts/draft-agl-tcpm-sadata/

i'm not advocating for or against this I-D or willing to predict its
success, but in the tcpm WG there are discussions about an extension for
including a small amount of data in the SYN+ACK payload. there is no
payload in the SYN packet, which makes it differ from T/TCP significantly
in both opportunities for optimizations and also possibilities for abuse.

this could be used to setup elliptic curve cryptography in a DNS exchange
quicker than the standard 3-way handshake would allow. it could be used
to send a previously established, cached cookie between servers such
that only the first connection in a given window incurs the time required
by a full handshake (where the 4th packet [<- ACK+data] contains the
cookie & and response from the request in the 3rd packet [-> ACK+data]).

i haven't given much thought to this, so this is not a formal proposal
to go down this road nor have i completely thought out how this could
be used to DNS's advantage. it's just food for thought since you brought
up T/TCP. it'd be better if the requester would be the one to include a
payload earlier, but T/TCP proved the problems within.

-- bill
[ not speaking for my employer, all just random thoughts ]

Subject: DNS over SCTP
From: bill fumerola <[email-masked]>
To: Paul Vixie <[email-masked]>
Cc: [email-masked]
Date: Wed, 20 Aug 2008 12:21:32 -0700

> did RDP (RFC 908, RFC 1151) ever achieve critical mass?

using another transport layer altogether is also a possibility, as you
hint, i don't believe RDP ever had much traction. however, SCTP could
be used to setup a multiplexed connection such that control messages
(broadly defined for now) are sent down through one stream and other
streams could be used for queries/responses. the advantages of UDP's
unordered delivery and message boundaries still can be realized while
gaining the advantage's of TCP's reliability, path MTU, and congestion
control.

additionally, SCTP has multi-homing support (almost SHIM6-like if i
understand both correctly) which could address the "tcp anycast is broken"
argument by allowing for PA space in addition to PI space to be used to
provide reliability in the face of multihomed servers.

finally, SCTP already contains methods for authenticating chunks on
selected streams using information derived during the setup which can
be based on pre-shared keys - possibly by publishing them in the DNS
tree itself (TKEY or similar).

i don't claim to be an expert on DNS, SCTP, or cryptography. however,
from what i read, SCTP certainly fits the bill for the requirements i've
seen floating around. stub resolvers could remain as-is and SCTP could
be used as transport soley between recursive and authoritative.  this
work would be the long view while EDNS PING, DNSSEC, and other
countermeasures to the problems at hand are deployed.

disadvantages to SCTP could include: lack of hardware accelleration in
network cards for the transport, the virgin territory of SCTP
implementations deployed, the existing problems of using a transport
with more state than UDP, lack of familiarity amongst operators of SCTP,
and a lack of widespread support for SCTP in both host and routing
operating systems.

-- bill
[ not speaking for my employer, all just random thoughts ]

---

From: bert hubert <[email-masked]>
Date: Thu, 21 Aug 2008 19:05:45 +0200

On Thu, Aug 21, 2008 at 04:32:06PM +0000, Paul Vixie wrote:
> we've got. 

It is not the only mitigation.

Even very simple countermeasures foil the '10 hour attack' and turn it into
a '100 year attack' (on average), or perhaps even a '500 year attack'.

It turns out that detecting a spoofing attempt in progress is easy, and that
simple agile behaviour makes attacks infeasible or at least very uninteresting.

It is not cool and revolutionary though.. But the upside is that it does not
require deprecating DNS over TCP, nor does it require moving DNS to SCTP or
DCCP other exciting new protocols.

	Bert

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

---

From: Mohsen Souissi <[email-masked]>
Date: Thu, 21 Aug 2008 19:16:19 +0200

| i worry about
 | <http://tools.ietf.org/html/draft-heffner-frag-harmful-02> and
 | <http://tools.ietf.org/html/rfc4963>.  i mention the
 | earlier-than-final draft because its title was "Fragmentation
 | Considered Very Harmful" which was a play on WRL-87-3
 | "Fragmentation Considered Harmful" (Kent and Mogul, DECWRL 1987).
 | BIND has had to implement all kinds of fallbacks in its EDNS0
 | support due to firewalls that don't allow fragments or which do the
 | wrong thing with them.  i am therefore not as convinced today as i
 | was in RFC 2671 that fragmentation is a reasonable way to expand
 | the DNS message size beyond 512 octets.

==> Hmm, I can see. Otoh, nobody could imagine at that time (and even
10 years ago) how the network-layer would become complex and its
components (often) misbehaving (magic combination of NATs, Firewalls, Load
Balancers...). So don't blame yourself ;-)

[...]

 | there is work going on in this WG to make EDNS0 mandatory.  that will have
 | an impact far broader than what we say to eachother in the forum itself.
 | as you yourself point out:
 | 
 | > 2) It is directly related to the discussion which took place on dnsext ml
 | > while editing dns-protocol-profile:
 | > http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg00037.html
 | > (see section 4.2.2).
 | > 
 | > The I-D expired on Jul 22nd, a copy is available here:
 | > http://ietfreport.isoc.org/idref/draft-ietf-dnsext-dns-protocol-profile/
 | > 
 | > This I-D should be recycled in the near future as I understood from last
 | > dnsext session @ IETF. And then, the result of the current debate may be
 | > helpful for people in charge of editing next version
 | > dns-protocol-profile...
 | > 
 | > Mohsen.
 | 
 | it's possible that you (mohsen) should volunteer to the WG chairs to help
 | edit that document, since i believe its current authors are overcommitted.

==> During IETF@Dublin, Ólafur discussed that matter with the editors
(and maybe others). Stéphane Bortzmeyer (a colleague of mine) was
among them and committed with some others to taking again that task
before next IETF. Hope it will efficiently move forward by then.

Mohsen.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 21 Aug 2008 17:30:36 +0000

> It is not the only mitigation.

nominum, powerdns, and unbound are probably doing more than port
randomization.  perhaps you can all three explain what you're doing, in
detail, so that the WG can decide whether those are reasonable things to
recommend to the rest of the community.

(for BIND, ISC explicitly decided not to implement anything experimental,
not even dns-0x20, during the six month period during which patches had to
be prepared in secrecy.  we'd like to do more, but we don't want to get too
far ahead of the WG's thinking on this.)

> It is not cool and revolutionary though.. But the upside is that it does
> not require deprecating DNS over TCP, nor does it require moving DNS to
> SCTP or DCCP other exciting new protocols.

do tell.

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 21 Aug 2008 12:47:55 -0700

> recommend to the rest of the community.

Note, I'm not a DNS developer.  However, I have been looking at these  
from the IDS viewpoint and attacker viewpoint, and also been  
corresponding with one of the Unbound developers (so a lot of what I'm  
going to say is influenced by that discussion as well, full acks in my  
previous mail).

But I believe there are several mitigations, all of them which are  
very powerful, beyond just increasing entropy, that should at least be  
considered.

So how do you think about mitigating things when you think like the  
IDS crowd does?

First, develop a taxonomy of various properties of attacks.

Blind vs Aware attacks:  Does the attacker have to guess any entropy  
or is it known to the attacker?

Transparent vs Blocking attacks:  Is the attacker unable to squelch  
the legitimate response or will the legitimate response be blocked?

Direct Record vs Glue: The resolver's query is in the form "X is ?".   
Is the attacker's desire to get "X is EVIL", or is the attacker's  
desire to get "SOMETHING_ELSE is EVIL" to be accepted (where  
SOMETHING_EVIL is ANYTHING beyond the direct answer of "X is Y", it  
could be an additional record, an authority record, something like "X  
CNAME TARGET,TARGET A EVIL")?

Transaction vs Cache:  Does the attacker desire that the eventual  
victim act on the transaction, or is it necessary for the victim's  
resolver to cache the response?

Then look at how attackers fit in the taxonomy.  A packet injector is  
"Aware and transparent", while a MitM is "Aware and blocking".  "Aware  
+ blocking" == game over short of crypto.  But you know that.

In particular, Yahoo cookie hijacking (as described in a previous  
message) is a blind, direct record, transaction attack, that  
nonetheless has a "race until win" property, although it takes  
advantage of interlocking weaknesses (when the browser sends cookies,  
how Yahoo handles cookies) in order to gain "Run until win".

Kaminski attacks are blind, glue, cache attacks:  The actual response  
is meaningless, and it is that they are a glue attack is what enables  
it to be "Run until Win" rather than "Run every TTL until Win" which  
doesn't reduce the packet count required but does greatly reduce the  
time involved.

(is there ANY kaminski variant that has "X is Y" as the only response  
the attacker wants to cache?  I don't believe so, because that's old- 
school cache poisoning.)

Blind attacks like this MAY be transparent, or they MAY be enough of a  
DOS to be blocking.  It depends on how much hostility you want to  
direct at your victim's network.

This taxonomy can then guide defenses:

Entropy increases (per previous post) (port randomization, dns-0x20,  
randomly selecting authority (per unbound)) protects against blind  
attacks with probabilistic bounds.  40 bits of entropy gives you good  
comfort, even when paranoid like me.

Duplication acts to increase entropy for the cache by nearly 2x, but  
either:
a) Decreases it for transactions (by 1 bit) while still resolving  
anomalous servers
b) Increases it for transactions (by nearly 2x) while preventing  
anomalous servers from resolving.

So pick your tradeoff if you need to duplicate to add entropy: do you  
want to allow blind transactional attacks and anomalous servers, or  
block blind transaction attacks and anomalous servers.

Yet entropy is also a "bear race": bots are valuable resources, so you  
don't need 100% protection, just enough protection that an attack is  
economically unfeasible.  40 bits and even paranoid me is happy.

Blind attacks can also be trivially detected, both by the IDS and by  
the DNS resolver: they generate responses that don't match requests,  
so you can say "I KNOW I am under attack" and "do something", which I  
BELIEVE allows you to say "the probability of their being one or more  
poisoned entries in my cache is less than P" by voiding the cache  
completely when it is greater than P (see the previous discussion on  
why you should be able to set P really low and not have this enable a  
DOS if you have sufficient entropy)

Transparent attacks can be detected as well.  They generate two or  
more responses for the SAME request but with different values, within  
the same timeout.  A preliminary IDS based study shows that this is  
VERY rare (1 server seen at ICSI, 30 seen at Ohio State, under a week+  
of traffic), so it is a very low false-positive situation.

The stateholding to detect such an attack is reasonable but not  
trivial.  Assume 100k active outbound requests/second.  With 1KB/ 
record stateholding, and a 3 second timeout, this is 300MB of  
stateholding to detect transparent attacks at a massively busy resolver.

Transparent transaction attacks can be detected in this manner.  And  
the detection of the attack could be forwarded to the client as well:  
take the second result, set the TTL to 1s, and forward it to the  
client to indicate a mismatch, allowing the client to detect the same  
thing the resolver did (plus packet injectors on the local network).

Transparent cache attacks can be mitigated, not just detected.  When a  
transparent attack is detected, either UNDO or INVALIDATE any cache  
changes caused by the first response.  It gets to be a maze of  
pointers, but I THINK this can be done "cleanly" (constant time/ 
request for all work).

Thus someone able to directly observe all the DNS traffic from the  
resolver and inject packets is both detectible (transparent  
transaction attacks are detected) and can only affect the results  
while in-path (transparent cache attacks are mitigated).

Likewise, unless a blind attack generates enough traffic that the  
legitimate response is blocked, the blind attack can't affect the  
cache, and is detected for the transaction.

The effect on anomalous servers which trigger this (which, as I  
mentioned, are few) is

a:  Their results are NEVER cached.
b:  If the eventual client software is suitably paranoid, transactions  
won't be conducted.

"blind direct cache" attacks (old school cache poisoning) have a "Run  
every TTL until Win" property, which is good.  You make the  
probability of winning low (through entropy), AND you make it so you  
can't run often, and you are happy.  Lets keep it that way.

The only case where a "blind direct cache" attack on a single name is  
"run until win" is if the legitimate response either doesn't return or  
returns an error.

Thus a question:  Should error lookups for name X also have an  
implicit TTL (of say, 1 minute?) in the resolver.

And there APPEARS to be policies on glue which mitigate the glue  
portion of a "blind glue cache" attack, without increasing the power  
of an "aware glue cache" attack.  (Glue is somewhat "out of bailywick"  
for me, pun intended, but...)

The blind glue attacks gain much of its power from "Run until Win" on  
the race condition, rather than "Run every TTL until Win".  Run until  
win does not reduce the number of packets required, but greatly  
reduces the amount of TIME required.

If the policy on all the additional garbage (INCLUDING the information  
about the authoritative nameservers, what all the CNAMEs point to, etc  
etc etc etc etc.  Yes, I mean EVERYTHING other than 'X is Y'!) is to  
"Never cache, only use for the current transaction.  PERIOD.", this  
completely blocks the "aware glue cache" attacks as far as I know, as  
I have yet to see a kaminski variant which is:

"Cause server to request X, response with 'X is Y'"

Simply because the race for any given X can only be run once every TTL  
(excluding failures, as mentioned previously), so you're back to the  
defender's happy place of "run every TTL until win".

Of course, such a glue policy would cause a huge efficiency hit, as  
certain things (like who's the authoritative server for .com) never  
get cached.  OOps.

However, if the resolver takes all the additional garbage it would  
have cached and does separate background lookups to validate each  
piece thats not in the cache "(authority for .com is?  A record for  
a.gtld-servers.net is?, A record for b.gtld-servers.net is? ...)", now  
all the subsequent lookups will run exactly as we would have expected  
without this policy change, including cache behavior.

Yet at the same time, it should defang all "blind glue cache" attacks,  
because instead of being "run until win", 'win' becomes simply the  
start of ANOTHER race that both has an unpredictable start AND can  
only be "run every TTL until win", because the result gets cached.

I also THINK this subsumes all the bailywick checking business which  
just gives me a headache.

And it doesn't increase the power of "aware glue cache" attacks, it  
just means the attacker must send a few more packets.

This should have two effects beyond the attacker.  If the authority is  
b0rken, and doesn't return things like the ns query, it will not be  
cached but will still be reachable.  (ALL the crud is still respected  
within the context of the current transaction only.  It will just  
never be cached).

And it increases overall load on the DNS authorities, by an "I'm not  
sure how much" level (remember, the stuff being asked for should cache  
really well).  It should be possible, however, to "given a trace piped  
through Bro, estimate the # of additional queries which would be  
generated if the authoritative servers aren't b0rken" if those on the  
list would think it valuable.

And there are also projects to revalidate caches as well, eg http://www.onzra.com/cacheaudit.html 
, which attempts to mitigate the duration of all cache attacks where  
the auditor is not under the same attack path as the resolver.

Thus also, layers of defenses are important.

Entropy mitigates blind attacks.

Mismatch detection detects (on transaction)/mitigates (on cache) aware  
attacks, even against packet injectors.

"Cache nothing I did not actually ask for, period" looks like it  
mitigates blind-glue attacks on the cache.

Auditing can detect cache attacks.

This is why this IDS person believes there are many options for  
mitigation, far more than just port randomization and 0x20, and they  
all should at least be considered and understood.

---

From: bert hubert <[email-masked]>
Date: Thu, 21 Aug 2008 22:12:46 +0200

> recommend to the rest of the community.

That sounds like a very fine initiative. I've been holding back because
'thinking out loud' between implementors might not be DNSEXT-material.
Perhaps it is also something that might benefit from some privacy.

The basic ideas are probably good to get out in the open, if only to create
some documented prior art. I'd hate for someone to patent an effective
countermeasure. Note well indeed.

The basic premise is that it is easy to detect any targeted attack, even a
'kaminsky-style' attack, as outlined in
http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01213.html

The referenced post is light on what to do if an attack on a zone apex is
detected. (forgive me my weak DNS terminology, the post outlines what I
mean)

Some ideas below - these are the things I've researched enough to make
statements about, some other ideas are still cooking.

A number of things appear to work some of the time:

1) open up a semi-persistent TCP channel and funnel all subsequent queries
for that zone apex and that server over it. This incurs syn, synack, ack,
fin, finack ack, but as we're on the receiving end of thousands of queries
by that time, this overhead is not significant. Keep the channel alive until
the responder disconnects, and reopen it. Fails on hosts which don't do TCP.
If attempts to outlaw DNS over TCP succeed, this percentage might rise.

Conversely, if we reaffirm TCP's first class citizen status for DNS, and
"clarify" the timout rules, this option becomes more succesful.

2) Repeat queries n times (fails on a number of important content
distribution networks, am in talks with those)

3) DNS-0x20 - although that doesn't protect the vital and scary . and COM
records from numerical kaminsky attacks.

What always works is:

4) Stop accepting new data for the attacked zone apex and everything beneath
it. 

This has the downside that over time, the TTL of the bonafide data expires,
turning a spoof into a DoS.

A more advanced way is:

5) Stop accepting new data below the attacked apex, but also stop expiring
it.

This last option opens up a subtle and expensive DoS opportunity to keep old
data alive, and to prevent new data from entering the cache. 

Some unexpected things that work:

6) Keep track of unresponsive servers, and stop sending them queries. It
turns out to be very hard to dose a DoS such that you overwhelm the correct
answers, but still allow most of them to get through.

My own implementation is lucky in this respect - I never intended this as an
anti-spoofing measure, but in my own experiments it is very hard not to
trigger this protection, and still maintain adequate spoofing bandwidth.

7) Don't have too much effective bandwidth. It turns out that it does not
really matter how much bandwidth an attacker can generate. What matters is
how much a receiving nameserver can process. This is limited by its incoming
bandwidth, plus the performance of its implementation.

What might work in the nearish future:

8) EDNS PING. Currently supported by 2 (two) hosts on the internet. David
Ulevitch and I will be releasing patches for BIND 9, NSD and DJBDNS, plus
PowerDNS will of course support it.

It turns out that you discover the things that work and that don't work by
actually implementing the countermeasures and seeing what happens. The naive
'drop back to TCP' for example proved to be an instant DoS on the authentic
authoritative servers.

>From this came the 'semi-persistent TCP channel', which works very well.

The discovery that keeping track of servers that generate timeouts is an
effective protection also came out of attempts to spoof PowerDNS.

I'm pretty sure that we'll discover ever better techniques as time
progresses.

For now the best recipe appears to be a mix of 1, 2, 3 and 8 and use 5 if
those fail.

The best an attacker can then do is keep a limited number of domains (that
don't do TCP and that fail the 'try n times'-test) from receiving new data.

I realise the agile techniques mentioned above are not very 'clean'. But in
the end, it is results that matter. The challenge is to have these
countermeasures not turn into new DoS-vectors (as noted by David Conrad),
but otherwise all real world engineering has its dirty spots.

	Bert

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 21 Aug 2008 14:28:34 -0700

At Thu, 21 Aug 2008 22:12:46 +0200,

> records from numerical kaminsky attacks.

This is probably an off-topic for this thread and in any case is
minor, but it's something I've always been wondering, so please let me
ask: how specifically would you spoof . by a "Kaminsky attack"?

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 Aug 2008 14:33:53 -0700

> 'thinking out loud' between implementors might not be DNSEXT-material.

I think it's namedroppers material, whether or not it's DNSEXT material.

> Perhaps it is also something that might benefit from some privacy.

If your countermeasures depend on people not knowing how they work,  
then they don't work.

---

From: bert hubert <[email-masked]>
Date: Thu, 21 Aug 2008 23:35:12 +0200

> ask: how specifically would you spoof . by a "Kaminsky attack"?

Jinmei,

Perhaps I'm very mistaken. I think I know more about implementing than I
know about DNS theory.

But this is how I think it works:

Send queries for '1.', '2.', '3.', '4.' etc to a resolver. In the meantime,
blast it with answers for '1.', '2.' etc with new NS records of your choosing
for '.'. Be sure to pick the source address of the nearest root-server.

I don't think . is special in any way in this respect.

	Bert

---

From: bert hubert <[email-masked]>
Date: Thu, 21 Aug 2008 23:52:43 +0200

> If your countermeasures depend on people not knowing how they work,  

Well - I was basically saying this on behalf of companies that might have a
hard time disclosing their (internal) deliberations, or perhaps intellectual
property.

It is not about keeping things ultimately secret.

I wouldn't be able to anyhow - "the source is out there".

	Bert

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 21 Aug 2008 14:55:11 -0700

At Thu, 21 Aug 2008 23:35:12 +0200,

> for '.'. Be sure to pick the source address of the nearest root-server.

So, do you mean something like this?

- the attacker (somehow) force the recursive server to send a query
  for (e.g.) '1. IN AAAA'
- then the attacker sends a forged response as follows:
  question: 1. IN AAAA
  authority: . IN NS evil.example.
  additional: evil.example. AAAA 2001:db8::1
- the recursive server replaces the forged NS RRset with the
  legitimate one:
  . IN NS [a-m].root-servers.net.

---
JINMEI, Tatuya

---

From: bert hubert <[email-masked]>
Date: Fri, 22 Aug 2008 00:04:38 +0200

>   . IN NS [a-m].root-servers.net.

Well, you could do that - hardcode the list of root-servers. Is that what
people do?

	Bert

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 21 Aug 2008 15:12:07 -0700

At Fri, 22 Aug 2008 00:04:38 +0200,

> Well, you could do that - hardcode the list of root-servers. Is that what

Oops, I meant:

- the recursive server replaces the legitimate NS RRset for .
  (which is normally) . IN NS [a-m].root-servers.net.
  with the forged NS RRset

Is this what you had in your mind?

---
JINMEI, Tatuya

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 21 Aug 2008 15:16:33 -0700

> ask: how specifically would you spoof . by a "Kaminsky attack"?

A:  Its not off topic.

B:  Its actually fun to explain.  So here goes:

When a DNS resolver asks for a mapping of the form "X is WHAT?" and  
gets a reply back from the authoritative server that "X is SOMETHING",  
there is a lot of other information returned by the authoritative  
server, including things like "Y is Z" and "Authorities for mydomain  
are R, S, T at these IP addreses" and "Oh by the way,  
adds.mydomain.com is this IP address".

These records are all potentially needed to complete the current  
transaction, but effectively all DNS resolvers will, under some  
conditions, cache this additional data, so subsequently the resolver  
will not have to ask, but can just check out what it has already for  
various purposes.  (This is the whole "Bailywick" checking business).

This interacts, umm, badly, with the "blind" attack.

The classic blind attack is: I cause the DNS resolver to request 'X is  
WHAT?', and send a bunch of forged replies that look like they are  
coming from the legitimate authority in the form 'X is MY_EVIL_RESULT'.

If I get lucky (and select the same transaction ID, port number, etc),  
the DNS server caches my response and for now until my TTL expires,  
the DNS resolver will always believe that "X is MY_EVIL_RESULT", and  
anyone else who asks it will get 'X is MY_EVIL_RESULT'

And its pretty easy to get lucky unless there are randomized ports or  
other entropy sources, because the transaction ID is 16 bits.  Thus  
for just a single try, if I try 1000 responses, the odds of success  
are roughly 1.5%.  Decent but not great odds.

However, if I failed, the DNS resolver got back 'X is GOOD' from the  
real authority, and will not do another request until the TTL expires,  
which can be hours (or days).  This makes the attacker unhappy.

The kaminski attack is a surprisingly minor variant.  The attacker  
causes the DNS resolver to request 'SOMETHING_I_DONT_CARE is WHAT?",  
and sends a bunch of replies in the form of 'SOMETHING_I_DONT_CARE is  
WHATEVER, oh, and by the way, X is MY_EVIL_RESULT'.  Or any one of a  
bazillion variants of this form.

If the attacker gets lucky, the name server now believes 'X is  
MY_EVIL_RESULT'

Now the attacker, if he fails, can try again immediately by asking for  
'SOMETHING_ELSE_I_DONT_CARE_ABOUT', because thats not in the cache and  
causes the DNS resolver to try again.

Thus it changes the threat model from "Try once every X hours" to  
"Just keep trying until I succeed".  So something that might have  
required days of waiting and 20,000 packets now requires just 20,000  
packets, no waiting!

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 Aug 2008 15:18:29 -0700

> hard time disclosing their (internal) deliberations, or perhaps  

Understood.   But in fact it's probably better that discussions like  
that not percolate out into the greater IETF community, since they  
might affect determinations about prior art (speaking as one who has  
been burned, albeit mildly, by this in the past).

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 21 Aug 2008 15:19:03 -0700

> B:  Its actually fun to explain.  So here goes:

Err, me bad, missed the fundimental addition of how you spoof .

You make your requests for

B123.com
B124.com
B125.com

And in the authority field, you give a new authority for .com

Now you only have 4 bits of entropy for 0x20.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 21 Aug 2008 15:26:44 -0700

At Thu, 21 Aug 2008 15:16:33 -0700,

> B:  Its actually fun to explain.  So here goes:

Thanks for the lecture, but I believe I'm one of the people in the
world who know how the Kaminsky attack generally works very well:-)

My question was how specifically it works for ".".  I'd like to see a
specific sequence of question, forged response, resulting poisoned
cache entry for this specific target.

---
JINMEI, Tatuya

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 21 Aug 2008 15:40:56 -0700

Again, apologies for my previously stupid reply.

However, it makes me wonder:

What are the conditions where various DNS resolver implementations  
will REPLACE a cache entry vs ADD a cache entry based on the reply.

EG, the cache has the RRset
.com NS is {a-m}.gtld-servers.net

living in the cache effectively forever.

What conditions in an authoritative reply will cause this to be  
evicted/replaced with new information?

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 21 Aug 2008 15:46:45 -0700

At Thu, 21 Aug 2008 15:19:03 -0700,

> Now you only have 4 bits of entropy for 0x20.

I know this works (btw the attacker would even omit 'B', which should
also work).  I didn't ask that.   My question was very specifically
about ".".

Speaking about "com", I think "doesn't protect" in the following
sentence

: 3) DNS-0x20 - although that doesn't protect the vital and scary . and COM
: records from numerical kaminsky attacks.

is not very accurate.  0x20 does provide protection for COM, but only
with a small bit of entropy (3 bits).  It's of course not sufficient,
but my understanding is that 0x20 is not intended to be a single
complete counter measure in the first place (i.e. it's expected to be
used with other source of entropy), so I'd say even additional 3 bits
are a plus if its cost is reasonable (which I also believe is the
case).

---
JINMEI, Tatuya

---

From: Michael Renner <[email-masked]>
Date: Fri, 22 Aug 2008 01:00:44 +0200

> sizes.  fifth, association timeout is handled in the stack not the app.

All the things you talk about are engineering problems which are already 
solved this day.

It's no big issue these days to serve thousands of clients, be it TCP or 
UDP. See [1] for common solutions to the problems, and [2] for 
benchmarks in this area. Nowadays the amount of clients you can serve in 
parallel are only limited by the amount of memory you've got for the 
respective data structures and the performance of the operations which 
are needed to traverse said data structures. RAM is cheap to come by, 
and at least since fefe has pointed out outstanding issues in 
implementations, every major OS should scale fine.

If your application isn't designed for such a task it takes a bit of 
refactoring and a few hours back at the architecture board, but it is 
feasible. Please do not try to design the protocols around your current 
implementation but around current engineering standards.

There's no need to go back to static source ports, the implementations 
which are out there work quite fine. You could also mandate (or 
"SHOULD", in RFC-speak) PING by now with the current UDP/TCP 
infrastructure, it just needs a common vision and a common goal. If you 
get the few major DNS vendors out there to support your cause, 
everything should be fine (tm) in a few years worth (and much earlier 
for those installations were people actually care about DNS).

> DNS protocol agents; installed base of firewalls and NATs and middleboxes.

Whereas changes in the TCP direction are much easier to come by than 
SCTP/DCCP or any different "newfangled" protocol which installed base is 
tremendeously exceeded by the amount of IPv6 production hosts ;).

Michael

[1] http://www.kegel.com/c10k.html
[2] http://bulk.fefe.de/scalability/

---

From: Douglas Otis <[email-masked]>
Date: Thu, 21 Aug 2008 16:42:19 -0700

On Aug 21, 2008, at 9:32 AM, Paul Vixie wrote:

>> PS: for SCTP none of the nice features of SCTP has an interest for  
>> the common DNS (i.e., the part which uses UDP when the payload is  
>> not over sized, not AXFR where SCTP makes sense). As these features  
>> are not always for free SCTP has no definitive advantage over TCP  
>> and clearly can't take the place of UDP (for DNS).
>
> i see five reasons why SCTP is worth looking at as a primary  
> transport with UDP as its fallback.  first, data transfer can take  
> place in the second round trip (packets 3 and 4).  second, it has 32- 
> bit ID fields so we could go back to fixed port numbers perhaps even  
> fixed+increment on TXID's. third, we could mandate EDNS, and with  
> it, we could mandate PING.  fourth, SCTP has the idea of "passive"  
> sockets which mean nonquadratic socket pool sizes.  fifth,  
> association timeout is handled in the stack not the app.
>
> i see two gigantic challenges for ANY non-UDP transport: installed  
> base of DNS protocol agents; installed base of firewalls and NATs  
> and middleboxes.

Agreed.  However, there is a fairly sizable install base for SCTP  
since it handles phone switching traffic (SS7), Diameter, respool, and  
MEGACO.  Both Cisco and Juniper support SCTP, and offer SCTP specific  
firewall solutions.  The CRC32c used by SCTP is the same polynomial  
used by iSCSI.  This polynomial has an increased Hamming distance and  
provides about the same error detection rate for Jumbo frames (the  
9000 byte frames desired by JET which includes Abilene (Internet2),  
DREN (DOD), ESnet (DOE), NREN (NASA), as does the IEEE 802.3 CRC for  
its 1518-byte maximum packet size (1500 payload).

SCTP also allows faster setup than TCP, and is fairly immune from  
packet spoofing.  A cookie echo in the handshake holds resource state  
returned by the client attempting to connect.  This approach mitigates  
packet spoofing and is more robust than TCP in dealing with DDoS  
attack.  At some point people will want greater security and  
reliability, and SCTP offers a solution that also avoids the head of  
queue blocking and allows zero copy data placement needed with higher  
bandwidths.  Perhaps just rumors of a new DNS on SCTP would help  
ensure home router vendors update their offering to handle this 8 year  
old IETF IP protocol.  Overcoming the lack of low-end commodity router  
support seems to be a barrier holding back progress.  If not Redmond,  
perhaps Redwood City?

-Doug

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 22 Aug 2008 09:56:06 +0900

Mohsen Souissi wrote:

>  | <http://tools.ietf.org/html/rfc4963>.

An inappropriate assumption in them is reassembly timeout of 15 second.

> Balancers...). So don't blame yourself ;-)

More than 20 years ago when IPv4 was designed, it was considered that
packet transit time can be as long as several or tens of seconds. For
example, TTL of IPv4 is a transit time upper limit measured in seconds.

Then, 15 seconds of reassembly timeout was reasonable.

Today, though TTL could be more than 1 second, which is already
quite unlikely, jitter of packet transit time is a lot less than
1 second that 0.4~0.2 second of reassembly timeout is enough,
which requires several lines of kernel modification.

It solves the reassembly problem, at least for the time being.

						Masataka Ohta

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 Aug 2008 18:23:17 -0700

On Aug 21, 2008, at 5:56 PM, Masataka Ohta wrote:
> quite unlikely,

I measured ping times to my home server at as much as 40 seconds  
during the most recent IETF meeting.   Arguably, we could describe  
this as an outage.  But unfortunately, there exist networks where  
routers are configured with excessive buffering, or where the layer  
two erroneously provides reliability.   On such networks, when there  
is congestion, long round trip times are actually quite common.

---

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

> is congestion, long round trip times are actually quite common.

	As are the inter arrival times for fragments.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 22 Aug 2008 11:32:20 +0900

> 	As are the inter arrival times for fragments.

That they are not even covered by the default reassembly timeout
means that we don't have to consider cases with wrongly large
buffers.

						Masataka Ohta

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 Aug 2008 20:13:09 -0700

> means that we don't have to consider cases with wrongly large

I think here we are speculating from nonexistent or anecdotal data.    
My general experience has been that where the network is basically  
working, but somewhat misconfigured, delays of up to 10 seconds are  
not uncommon.   The IETF network in Dublin is the first one I've been  
on where I've seen a response after 40 seconds.   I was quite  
astonished.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Aug 2008 15:52:19 +1000

> implementations, every major OS should scale fine.

	The problem is not so much the server side.  It's the client
	side of the recursive nameserver.  You have to deal with
	running out of local ports especially when you need to lock
	down the source address.  Plain bind() + connect() won't
	scale.

	I suppose one could choose a single local source port then
	set SO_REUSEADDR before binding to the local address and
	port but then you can only have one socket in this state
	until you call connect.

	If you have multiple queries to the same server you have to
	do one or both of:
	* choose a new local port that is not being used to talk to
	  the remote server
	* or multiplex your queries down the one socket

---

From: bert hubert <[email-masked]>
Date: Fri, 22 Aug 2008 08:57:04 +0200

> 	down the source address.  Plain bind() + connect() won't

Fwiw, both dnscache (djbdns) and powerdns have been working with bound() and
connect()ed udp sockets for many years now.

So this problem does not appear to be an issue in the real world.

	Bert

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Aug 2008 18:23:22 +1000

> So this problem does not appear to be an issue in the real world.

	I've been told unbound only has a maximum of 1000 active
	sockets and if you get more than that many outstanding
	recursive queries it stalls the new queries.

	I havn't looked at how djbdns deals with lots of simultanous
	queries.

	Mark

---

From: Wouter Wijngaards <[email-masked]>
Date: Fri, 22 Aug 2008 12:52:56 +0200

> recommend to the rest of the community.

I am going to document the countermeasures I envision (in addition to
DNSSEC) for Unbound in a draft (as the wg chairs ask).

Best regards,
   Wouter

---

From: Paul Vixie <[email-masked]>
Date: Fri, 22 Aug 2008 16:09:32 +0000

> DNSSEC) for Unbound in a draft (as the wg chairs ask).

that would be great.

it's my view that while implementors should of course innovate, there has to
be a documented standard, which is testable for both interoperability and
correctness, and which represents an adequate implementation level for what
we used to call "forgery resilience".  so while i'll be happy to see 
descriptions of what each implementor is doing, and i agree with ted lemon
that any form of "not wanting to discuss it in public" is counterproductive,
the end result has to be guidance to future implementors.  in that sense, we
know that randomizing the DNS-TXID and UDP-SRCPORT isn't good enough, and so
we have work to do.

beginning that work with a survey of methods now in practice would be good,
but the end result has to be a description of either a set of methods which
are considered adequate, or a set of attacks which a conformant
implementation must be able to resist, or both.

it's in that sense that i consider DNSSEC the final solution (since it
handles end-to-end attacks whether on- or off-path), and in which i would
consider PING, TCP, or SCTP partial solutions (since they only handle
off-path attacks).  whereas a laundry list of small things which implementors
could do and which some implementors are doing, is not a testable standard
for new implementors.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Aug 2008 11:14:21 -0700

>> DNSSEC) for Unbound in a draft (as the wg chairs ask).

Dan raised the point on his blog recently that active countermeasures  
have the problem that they make a great avenue for denial-of-service  
attacks.   Seems like something worth keeping in mind.

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 22 Aug 2008 11:23:09 -0700

At Thu, 21 Aug 2008 15:12:07 -0700,

> Is this what you had in your mind?

I've been hoping someone enlightens me, but there seems to be no luck.
So I'll continue speculating...

I've missed "answers" in the example given before:

: Send queries for '1.', '2.', '3.', '4.' etc to a resolver. In the meantime,
: blast it with answers for '1.', '2.' etc with new NS records of your choosing
: for '.'. Be sure to pick the source address of the nearest root-server.

so the intent is perhaps this one:

- the attacker (somehow) force the recursive server to send a query
  for (e.g.) '1. IN AAAA'
- then the attacker sends a forged response as follows:
  question: 1. IN AAAA
  answer 1. IN AAAA 2001:db8::1234
  authority: . IN NS evil.example.
  additional: evil.example. AAAA 2001:db8::1
- the recursive server replaces the legitimate NS RRset for .
  (which is normally) . IN NS [a-m].root-servers.net.
  with the forged NS RRset, possibly with the additional AAAA RRset

(Un)fortunately, this attack succeeds only in a very limited situation
as long as the recursive server performs "priming" (as described in
draft-koch-dnsop-resolver-priming-00) and follows the data ranking
concept described in Section 5.4.1 of RFC2181: the recursive server
should have a cached entry of "./NS" at the data rank of "The
authoritative data included in the answer section of an authoritative
reply" as a result of priming, while the rank of the forged authority
section is "Data from the authority section of an authoritative
answer".  So, the forged response cannot unconditionally replace the
existing cache.  This is one major difference for "."  from any other
domains.

The attacker could wait for the expiration of the high-rank cache;
however, the first query (which may or may not be caused by the
attacker) after the expiration will immediately trigger the next
priming and the high-rank data is soon cached again, so the possible
attackable window is very limited.  This is another major difference
for "." (+ the notion of priming) from any other names in the context
of Kaminsky's attack.

Of course, this defense depends on whether implementation diligently
performs priming and follows the data ranking rule of RFC2181.  One
implementation that I know very well behaves that way (I've actually
confirmed that by "attacking it" based on the above scenario); as far
as I can confirm, that's the only implementation that meets this
requirement, though.

In any event, this is probably a different attack scenario from what
you were thinking when you said this:

I'm very much interested in knowing that (if it's not secret:-).

---
JINMEI, Tatuya

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 22 Aug 2008 11:42:08 -0700

On Aug 22, 2008, at 11:14 AM, Ted Lemon wrote:

> Dan raised the point on his blog recently that active  
> countermeasures have the problem that they make a great avenue for  
> denial-of-service attacks.   Seems like something worth keeping in  
> mind.

You can and should bound these.  EG, if your active countermeasure is  
draconian (flush or revalidate the cache) when the attacker has a . 
001% chance of putting in one or more bad entries in a blind manner,  
by maintaning a simple count:

For 32b entropy for cached transactions, it doesn't work.  With a  
relatively small number of packets (less than 10,000), you'd cause a  
cache flush/revalidate.  Owch.

For 40b entropy for cached transactions, it can work fine.  Now the  
attacker needs 10M packets.  If your cache has only 1M entries active  
that you reload, this hardly seems economical as a DOS attack.

---

From: bert hubert <[email-masked]>
Date: Sat, 23 Aug 2008 10:30:09 +0200

> 5) Stop accepting new data below the attacked apex, but also stop expiring

Ok, I've been pondering another one, and I wonder if it will work. 

While under attack, 

5a) become ultra-paranoid and don't accept any data except the first answer
    record. Ignore new NS records, CNAME chains, additional records etc.

    This would make the NSSet of the attacked domain expire, but it would be
    refreshed from the parent zone when that happens.

    While the attacker could try to target that event as well, it too would
    be detected.

An attacker can then still take over xaaaaaaaaa.ietf.org, but he won't be
able to spread this to the NS records.

	Bert

---

From: Paul Vixie <[email-masked]>
Date: Sat, 23 Aug 2008 15:18:04 +0000

> ...
> ...

for the sake of future implementors whom this WG must guide via documents
produced in this early part of the kaminsky era, i am still hoping for a
non-modal solution.  this is because conformance and interoperability
testing of protocol implementations is already quite hard, and if we have
to test "does it go into the attack mode under the right conditions" as
well as "can it in that mode resist the attacks we know of" then it makes
a test cost multiplicative that could otherwise have been additive.

thus PING, 0x20, DNSSEC, SCTP loom larger for me than detecting attacks
and behaving differently during attacks.  nick weaver and masataka ohta
have each made some non-modal proposals about noncaching of data, and i
think the WG should seriously investigate, and prefer, non-modal proposals.
if in the end we can't find a solution that doesn't involve adding IDS to
DNS, then so be it.  but the main thrust of our effort should be non-modal.

---

From: bert hubert <[email-masked]>
Date: Sat, 23 Aug 2008 17:24:57 +0200

> DNS, then so be it.  but the main thrust of our effort should be non-modal.

If we can find such a solution, it would be wonderful. 

I've been working on a paranoid rrset acceptance mode today, perhaps it will
prove possible to fine-tune it such that it won't hurt (too much) and can be
left on all the time.

At the expense of some extra queries perhaps.

	Bert

---

From: Paul Vixie <[email-masked]>
Date: Sat, 23 Aug 2008 15:30:44 +0000

> > ... the WG should seriously investigate, and prefer, non-modal proposals.

are we *all* agreed on this, then?

> At the expense of some extra queries perhaps.

that's the area nick weaver's also working in.  for many values of "some" that
don't involve "too much" new state (storage or maintainance) this sounds good
to me.

---

From: Francis Dupont <[email-masked]>
Date: Sun, 24 Aug 2008 16:17:17 +0200

there.

=> this shows the fall of T/TCP has left a hole...

   since sctp is slightly older and is used in ip telephony and is
   implemented on more systems and allows data transfer on the second round
   trip (packets 3 and 4), i'm more hopeful for it than i am for DCCP.
   
=> what we want is data transfer on the first round (packets 1 and 2)
but it opens the door to fake source (in packet 1) attacks...
DCCP is younger but its "market" is far larger. My concern is no
new transport can really replace UDP and as a DNS fallback TCP.

=> IMHO this only shows SCTP has the pros and cons of a new transport.

Thanks

---

From: Paul Vixie <[email-masked]>
Date: Sun, 24 Aug 2008 15:41:26 +0000

> but it opens the door to fake source (in packet 1) attacks...

yes, but to get data transfer in the first round trip, requires DNSSEC or
PING.  so i'm considering the impact of leaving SCTP associations open for
some period of time (there's an automatic association timeout handled in
the stack rather than in the application).  this would allow a "working set"
of associations who had already been through their first round trip.  it's
important to distinguish this from the TCP case where each session requires
its own socket descriptor on every stack now known to exist, thus placing a
giant burden on the application to do session management.  an SCTP app could
have tens or hundreds of thousands of associations open on a single "socket".

i see that neither DCCP nor SCTP transfers user data in its first round trip.
both offer message semantics (like UDP does), so the receiver can know the
size of the message without having to encode it into the stream as we do in
TCP/53.  DCCP relies on ip fragmentation to send messages larger than PMTU,
whereas SCTP is like TCP in that it can segment messages into IP packets that
are not larger than PMTU.  DCCP has no concept of "associations" like SCTP's
and cannot multiplex many pseudosessions across a single "socket" or whatever
the local stack calls its network endpoints.

> DCCP is younger but its "market" is far larger.

by "larger" do you mean "number of flows now using it" or something else?
the wikipedia pages for DCCP and SCTP show many more implementations of
SCTP.  

> My concern is no new transport can really replace UDP and as a DNS
> fallback TCP.

this is my concern also.  however, speaking from the point of view of RFC
2671, ip fragmentation is a disaster and anything that depends on it will
be very difficult to deploy.  if the DNS engineering community seriously
believes that DNS messages larger than PMTU must become commonplace some
day, then we have millions of firewalls and middleboxes and even routers
and switches to upgrade or replace.  

the truth of <http://www.ietf.org/proceedings/06jul/slides/tsvarea-1.pdf>
had not dawned on me at the time RFC 2671 was being prepared, though it's
all blazingly clearly true after N years of trying to get RFC 2671 deployed.
it's my opinion that the title of the RFC that resulted from this (RFC 4963)
does not do justice to the content.  ipv6 fragmentation doesn't have these
problems, so perhaps if we look to the future we can forget how terrible
ipv4 fragmentation really is.

>    i see five reasons why SCTP is worth looking at as a primary transport
>    with UDP as its fallback.  first, ....  second, ....  third, ....
>    fourth, SCTP has the idea of "passive" sockets which mean nonquadratic
>    socket pool sizes.  fifth, association timeout is handled in the stack
>    not the app.
>    

compared to UDP, TCP, or DCCP, reasons four and five (left intact above) are
unique to SCTP.  but the fundamental premise that it's likely impossible to
insert a new primary transport ahead of UDP/53 is one we all agree with.  if
i could be sure there would be reliable and instantanenous signalling of the
absence or failure of a new transport, and that we would not have to wait
for some kind of timeout to tell us that it wasn't going to work, i'd say we
should opportunistically deploy.  alas, RFC 2671 deployment experience shows
that a vast number of failures are inferrable only by timeouts.  middleboxes
(NATs, ALGs, firewalls) are exactly the bane the end-to-end crowd said they'd
be, and now we're hamstrung.

HTTP/1.1 with an XML schema for DNS messages would be more likely to succeed,
especially if we used TCP/80 and a RESTful API.  the internet isn't the web,
but enough endpoints are confused about the differences that deployability is
now generally higher for new web apps than it is for new internet apps.  sad.

---

From: Brian Dickson <[email-masked]>
Date: Sun, 24 Aug 2008 18:55:28 -0400

Paul Vixie wrote:
>
>   nick weaver and masataka ohta

I've been giving some thought to some of the underlying vulnerabilities, 
where the following intersect:
- the protocols involved
- the strategies of resolvers
- the data in the root and TLD *zones* (emphasis on zone vs domain)

At the root of the Kaminsky vulnerability is the ability to feed data 
into a cache, where the data in question
is provided in the "Additional" section.

If we ignore, for the moment, when/whether/what referrals are provided 
by servers in "Authority" sections,
and consider only the case of "if there *is* an authority section", then:

The Question:
When is it strictly necessary that Additional section data be provided 
*and* used (cached)?

(Undoubtedly there are cases where it is absolutely necessary, to bridge 
the gap at a zone cut.
If you have "example.com    NS    ns1.example.com", the only possible 
way for an empty cache to resolve the address of ns1.example.com, is via 
glue A/AAAA RR's.)

But first, a quick sidebar...

Sidebar: namespace congruity and phantom namespace

The main axiom of "the Domain Name System", is the "the".  (At least, 
for the public DNS sanctioned by ICANN et al.) There is only one.
The name space is hierarchical, and delegations occur at zone cuts.
Any legitimate, actual leaf in the name space must be reachable by 
starting at the root, and possibly crossing one or more zone cuts, 
reaching a terminal node in the label space of some leaf zone.

Depending on the domain names of NS RR's used in delegations (at zone 
cuts), with attendant glue A/AAAA records, it may be possible to 
establish "phantom leaf" labels in the name space which are not 
reachable via top-down tree walking, because one or more parent domains 
of the NS RR's do not exist.

If there were, for example, "example.com     NS    example.bar" with 
"example.bar    A    10.1.2.3", if the caching resolver accepted that 
delegation, a new, non-existent TLD, "bar." with one leaf entry, 
"example.bar", would suddenly exist in the resolver's cache.

Obviously, this is not something intentional, nor is it something that 
should generally be considered acceptable practice.

(end of sidebar)

If we exclude, axiomatically, the legitimacy of such "phantom" namespace 
elements, then we can then say the following are true:
- every leaf entry in the public DNS exists (and is served 
authoritatively) in one zone only
- every legitimate zone is delegated from its parent zone at a zone cut 
boundary
- every legitimate zone is served by one or more name servers, who serve 
that zone authoritatively
- every legitimate zone is anchored directly or indirectly at the root 
"." of the public DNS

Taking the above together, then, it would be sufficient for resolving 
anything legitimate in the public DNS, for glue A/AAAA RR's to exist 
only in the immediate parent's zone.
(I can elaborate on this if anyone wants, but I'm trying to keep this 
short).

Thus, The Answer:
If the *actual* glue A/AAAA RR's in (at a minimum) the root and all TLD 
zones met this condition, then the only time a resolver would ever 
*need* to accept "Additional" data would be in those exact cases, where 
the "Additional" data were given in the answer to a query for an A/AAAA 
RR, where the "Question" was for the RHS of a delegation, which was 
subordinate to (i.e. a child of) the LHS of the delegation.

What this means:
That the "Additional" section could be ignored in all other cases.

And I *think* this would, in turn, result in the "birthday attack" race 
only being run when the TTL of glue A/AAAA RR's expires.

Note also, that there will generally be orders of magnitude more NS 
entries pointing to the same RHS, and thus many fewer such races being 
run generally.

As a data point, I examined a pretty big TLD (org), and verified that no 
out-of-zone glue A/AAAA RR's exist - only subordinate A/AAAA glue RR's 
exist.
(If other TLD operators wouldn't mind checking this, and providing 
similar data points, I think we could possibly consider standardizing 
the non-use of Additional data.)

Brian Dickson

P.S. There is an important Corollary to the above:
There is nothing in the naming of nameservers (in NS records) that 
restricts the levels of indirection that can occur, between the names of 
zones served, and the names of the nameservers serving those zones.
As a practical matter, operators of nameservers *SHOULD* make reasonable 
efforts to limit the actual levels of indirection.
And, ideally, nameservers *should*, if possible and practical, be 
authoritative for their own names. If I have ns1.foo.example.com, and 
ask it for the A RR for ns1.foo.example.com, life is easier if it gives 
the answer, and does so authoritatively, *and* is itself listed in the 
NS RR set for the domain foo.example.com.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 25 Aug 2008 02:15:17 +0000

> From: Brian Dickson <[email-masked]>
> CC: bert hubert <[email-masked]>, [email-masked], 
>  [email-masked]

plz don't ever crosspost between namedroppers and dnsops.  no possible
article is of interest to both audiences.  i'm removing dnsops, as well
as bert and brian since i know they are on namedroppers.

> into a cache, where the data in question is provided in the "Additional"
> section.

no.  the root of the kaminsky vulnerability is the ability to run a race
more than once and with a head start.  actual pollution can come in the
answer section (cname chains passing through or ending in names one wishes
to pollute), the authority section (replacement NS RRs for the baliwick
apex, or new subdomains of the baliwick), or the additional section (after
kashpureff resistance has been applied there are still many forms of evil
given the ability to arbitrarily populate the answer and authority sections.)

it's a mistake to focus on any one section or any one form of pollution.
the reason i'm enamored (in general, though there are many problems left
to solve in the proposals) of the approaches advocated by masataka ohta
and nick weaver is that they start from the question, what of all this do
we HAVE to believe, and why, and what's the cost of disbelief, and what
are our alternative means of acquiring the data, and what are the costs of
those alternatives, and furthermore, what does "belief" really mean?  in
other words, how can we "fail closed".

note that there may be other ways to achieve the "kaminsky effect" that do
not involve misdirection.  if an RDNS fails to implement birthday protection
(sends multiple simultaneous upstream queries for a given q-tuple), or fails
to cache the result (an rrset, or an nxdomain, or a nodata condition) for a
given q-tuple, or if an ADNS deterministically never answers some kinds of
questions (like undefined qtypes), or if a middlebox deterministically drops
some kinds of questions or some kinds of answers (like qtypes unknown to it)
then the "kaminsky effect" might be produced without the "sibling name trick"
and in those cases the answer matching the q-type could also be poisonous.

so even while my own toy RDNS now refuses to replace NS RRsets, and does not
cache any answer RRsets other than the one matching the q-tuple, and fully
implements RFC 2181's rrset credibility logic, and fully implements dns-0x20,
i do not feel "safe" yet.  when i can successfully reason from the starting
point "what should i use or keep?" rather than "what shouldn't i use or keep?"
then i'll be on a path that could lead to feeling safe.

---

From: Florian Weimer <[email-masked]>
Date: Mon, 25 Aug 2008 13:38:30 +0200

> are we *all* agreed on this, then?

I'm not sure---"does not support 0x20" or "does not support PING" as
an additional upstream attribute is kind of modal, too.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 27 Aug 2008 19:04:51 +0200

=> the potential market: SCTP was designed for SS7 and should replace TCP
extremely slowly, DCCP is for VoIP & co.

Regards

PS: note I have been a fan of SCTP for many years. I am just old enough
to understand SCTP adoption should take at least a decade.

---

From: Danny Mayer <[email-masked]>
Date: Sun, 31 Aug 2008 21:30:33 -0400

> 	for AAAA queries today.  These cause operational problems.

It seems to me that we have the classic problem of responses written for 
servers based on certain conditions leaving the clients to try and 
figure out what that response really meant. What is really needed is a 
document that says the response X will happen under the following list 
of circumstances, and response Y will happen under these other 
circumstances. Then it becomes easy to figure out what is the most 
appropriate response based on some new circumstances. Clients need to 
understand the meaning of the response within the context of the query.

Danny