Subject: [DNSOP] updated draft agenda for Prague

From: Peter Koch <[email-masked]>
Date: Wed, 7 Mar 2007 20:54:34 +0100

Dear WG,

to put one draft copy of the agenda into the archives, here is an update.
Further changes might be applied to the online version at

	<http://www3.ietf.org/proceedings/07mar/agenda/dnsop.txt>

Please check your slots and read the drafts.  Presenters are kindly asked
to submit their material by Monday morning, so we can upload it well before
the meeting starts.

-Peter

-----------------------------------------------------------------------------
WG:        DNS Operations (dnsop)
Meeting:   IETF 68, Prague
Location:  Hilton Prague, "Grand Ballroom"
Date:      Monday, 19 March 2007
Time:      17:40 - 19:50 (UTC+1)	(// lemonade, monami6, softwire, netconf, mmusic, emu)
Chairs:	   Rob Austein <[email-masked]>  <[email-masked]>
	   Peter Koch  <[email-masked]>      <[email-masked]>
Jabber:    xmpp:[email-masked]
WG URL:    http://www.dnsop.org
Material:  https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=68
Version:   $Revision: 1.4 $
-----------------------------------------------------------------------------

1) Administrivia
   [chairs][ 5 min][17:40]

   - minutes scribe	{volunteers welcome in advance!}
   - jabber scribe	{volunteers welcome in advance!}
   - blue sheets
   - agenda bashing

2) Status Update
   [chairs][ 5 min][17:45]

   - RFCs published
	-none-

   - Internet-Drafts in RFC Editor Queue
	-none-

   - I-Ds at the IESG
	draft-ietf-dnsop-serverid-08.txt
	(On IESG agenda for 2007-03-08)

   - I-Ds in or past WGLC
	draft-ietf-dnsop-reflectors-are-evil-03.txt	(see below)

	draft-ietf-dnsop-default-local-zones-01.txt	(see below)

3) Active Drafts
   [chairs][50 min][17:50]

   3.1) draft-ietf-dnsop-reflectors-are-evil-03.txt
	[Joao/Fred][10 min][17:50]
	post WGLC discussion -- ready for the IESG?

   3.2) draft-ietf-dnsop-default-local-zones-01.txt
	[Mark Andrews][10 min][18:00]
	post WGLC discussion -- another update needed?

   3.3) draft-ietf-dnsop-respsize-07.txt
	[Paul Vixie][5 min][18:10]
	draft revived -- ready for WGLC?

   3.4) draft-ietf-dnsop-reverse-mapping-considerations-02.txt
	[Andrew Sullivan][15 min][18:15]
	remaining open issues -- ready for WGLC?

   3.5) draft-ietf-dnsop-as112-ops-00.txt
	draft-ietf-dnsop-as112-under-attack-help-help-00.txt
	[Joe Abley][10 min][18:30]
	Open Issue: why not install "defensive delegations"?
		    what shape should the third document have?

4) WG Charter
   [chairs][10 min][18:40]

5) Other (non WG) Internet-Drafts
   [chairs][30 min][18:50]

   5.1) draft-regnauld-ns-communication-00.txt  
	[Stephane Bortzmeyer][15 min][18:50]
        Discuss need/scope of a requirements draft for a name server
	 configuration/communication protocol

   5.2) draft-larson-dnsop-trust-anchor-01.txt
	[Matt/Olafur][10 min][19:05]
	Trust Anchor Priming

   5.3) draft-koch-dnsop-resolver-priming-00.txt
	[Peter Koch][ 5 min][19:15]
	documenting the practice of resolver priming

6) Current & New Topics
   [chairs][10 min][19:20]

   6.1) SRV underscore registry
	[Dave Crocker][ 5 min][19:20]

   6.2) TTL considerations
	[Lixia Zhang][ 5 min][19:25]

7) I/O with other WGs
   [chairs][10 min][19:30]

   7.1) dnsext: anti-spoofing?
   7.2) dnsext: DNS cookies?
   7.3) dnsext: DNAME operational requirements?
   7.4) v6ops: draft-ietf-v6ops-scanning-implications
   7.4) geopriv: draft-schulzrinne-geopriv-relo

8) A.O.B.
   [N.N.][10 min][19:40]
   {please identify issues in advance}

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

_______________________________________________
DNSOP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dnsop

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 8 Mar 2007 14:21:29 +0100

On Wed, Mar 07, 2007 at 08:54:34PM +0100,
 Peter Koch <[email-masked]> wrote 

>    {please identify issues in advance}

draft-weiler-dnssec-dlv-02.txt ? It seems more dnsop than
namedroppers.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 8 Mar 2007 14:21:29 +0100

---

From: Dean Anderson <[email-masked]>
Date: Thu, 8 Mar 2007 13:30:10 -0500 (EST)

>    3.1) draft-ietf-dnsop-reflectors-are-evil-03.txt

Summary:

Because the solution proposed in the draft is as damaging as the attack
itself, and because the attack is merely an example of a broader
category of attacks already addressed elsewhere, and because the draft
contains false statements about the threats to authoritative
nameservers, I strongly object to this draft.

Detail:

> 	post WGLC discussion -- ready for the IESG?

This draft falsely claims that the amplification potential is greatly 
reduced when authoritative servers are used:

   DNS authoritative servers which do not provide recursion to clients
   can also be used as amplifiers; however, the amplification potential
   is greatly reduced when authoritative servers are used. 

The amplification potential to authoritative servers is exactly the same
as for recursive servers, and the attack volume depends only on the
bandwidth available to the nameserver and the number of queries sent.  
No evidence was given to show that there is any difference between
authoritative servers and recursive servers. Scanning the internet for
recursive nameservers is as difficult or more difficult than scanning
for authoritative nameservers for large records.  Further, no scanning
is necessary at all if one uses the root servers to conduct this attack,
since the root servers IP addresses are known, and there is no
mitigation.

Further, when recursion is denied, a referral list of authority servers
is typically sent. This can also amount to a large packet size and
therefore a high volume of traffic.  Denying recursion can be just as
bad as the attack described.  Further, denying recursion can disrupt 
legitimate recursive use by mobile or traveling users, resulting in 
complete disruption of nameservice and internet access for those users.  
No consideration has been given to the effects of disabling recursion.

Second, the attack description is also incomplete:

   1.  The attacker starts by configuring a record (LRECORD) on any zone
       he has access to (AZONE), normally with large RDATA and TTL.

The attacker may start by scanning the authority servers for a large DNS
record, such as large PTR records, or large SPF records, large DNSSEC
records, etc.  This particularly relevant to step 3

   3.  Each ORNS proceeds with the resolution, caches the LRECORD and
       finally sends it to the target.  After this first lookup, access
       to the authoritative nameservers for AZONE is normally no longer
       necessary.  The LRECORD will remain cached for the duration of
       the TTL at the ORNS even if the AZONE is corrected.

It may be impossible to "correct" AZONE, since it may be a legitimately
large authority record.

There is a certain amount of exaggeration for the described attack. A
much simpler, and more devastating attack was reported that uses
authority and root nameservers for which there is no mitigation.  So
far, no attacks have used the authority or root nameserver methods, even
though there is no mitigation for those attacks.

Attacks using recursive nameservers can be mitigated by blocking queries
from the target address temporarily. 

The attacks that have been seen so far, use the method described in the
draft, and have an element of farce to them: Not frequent, not damaging,
and appear only to prove the point that this attack could happen. This
pattern is reminiscent of a similar kind of attack that was conducted on
open SMTP relays by anti-spammers.  Real spammers never conducted such
attacks.  Likewise, in this case it seems that real DOS attackers don't
use the attack described in the draft.  As in the case of open relay
abuse, the abusers are detected and identified by monitoring for
scanning and subsequent abuse.  As with open relays, slowly changing the
IP addresses of servers (and updating the users but not the abusers)
makes it necessary for abusers to keep scanning, easing the detection of
the abusers.

As the draft mentions, these attacks depend on the capability to spoof
the IP address of the target in the source address field of the query,
and so these attacks are really part of a much broader array of attacks
that can be conducted if the source IP address can be spoofed as
described in BCP38.

Last, but not least, there are many positive and beneficial uses for
open recursors.  Besides the obvious purpose of providing service to
mobile users, they enable remote testing and diagnosis of DNS problems.  
They enable testing and detection of Anycast DNS servers.  They enable
performance monitoring of diverse internet links. Etc.

Because the solution proposed in the draft is as damaging as the attack
itself, and because the attack is merely an example of a broader
category of attacks already addressed elsewhere, and because the draft
contains false statements about the threats to authoritative
nameservers, I strongly object to this draft.

Dean Anderson
Av8 Internet, Inc

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Dean Anderson <[email-masked]>
Date: Thu, 8 Mar 2007 13:30:10 -0500 (EST)

Summary:

Detail:

Dean Anderson
Av8 Internet, Inc

---

From: Douglas Otis <[email-masked]>
Date: Sat, 10 Mar 2007 12:39:50 -0800

On Mar 8, 2007, at 10:30 AM, Dean Anderson wrote:

> This draft falsely claims that the amplification potential is  
> greatly reduced when authoritative servers are used:
>
> The amplification potential to authoritative servers is exactly the  
> same as for recursive servers, and the attack volume depends only  
> on the bandwidth available to the nameserver and the number of  
> queries sent.  No evidence was given to show that there is any  
> difference between authoritative servers and recursive servers.  
> Scanning the internet for recursive nameservers is as difficult or  
> more difficult than scanning for authoritative nameservers for  
> large records.  Further, no scanning is necessary at all if one  
> uses the root servers to conduct this attack, since the root  
> servers IP addresses are known, and there is no mitigation.

The higher gain attacks leverage a large RR not normally found in  
most authoritative DNS.  An exception might be wildcard RRs that do  
not accommodate maximal label sizes.  While indeed this may be the  
case for many SPF RRs, the scripts contained in SPF actually  
represent a far greater attack threat.  These attack levels start at  
the highest gain achieved by an open recursive DNS.  SPF scripts  
could be used to reference 10 additional SPF RRs, or hundreds of A  
records when used in conjunction with spamming.  The SPF related  
attack does not not expend additional resources of the attacker  
beyond the initial queries and can target any other victim as well.   
This script may then repeat for every domain being validated, which  
will soon include DKIM domains.  Perhaps another draft should be  
titled, SPF-scripts-are-evil. : o

Recursive servers can be easily located without any scanning and then  
asked to obtain an answer referencing problematic RRs (which may be  
poorly considered SPF RRs).  Your point about scanning is misleading,  
as there are many ways to determine their location.  Preventing  
access to recursive servers significantly reduces the possible  
sources relied upon by a distributed mode of attack.  Most mobile  
users are granted both their IP address and DNS, where limiting  
access will not represent any hardship.  Those working on wireless  
connections in a public setting might even consider tunneling their  
DNS requests and endure added latencies over improved security.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Sat, 10 Mar 2007 12:39:50 -0800

-Doug

---

From: Dean Anderson <[email-masked]>
Date: Tue, 13 Mar 2007 14:00:47 -0400 (EDT)

On Sat, 10 Mar 2007, Douglas Otis wrote:

> most authoritative DNS.  

This assertion isn't true.  Several examples were given of common large 
record types frequently found on authority servers.

> Recursive servers can be easily located without any scanning 

Really? How?

Some millions more authority servers are easily found without scanning.  
Querying them for large records is not suspicious.

By contrast, searching for recursors is (unless you've discovered some
interesting new way of finding them without scanning---I'm very
interested to hear about that) some that can be detected, so that
the abusers can be identified.

> and then asked to obtain an answer referencing problematic RRs(which
> may be poorly considered SPF RRs).

RRs which come from authority servers. If you are the attacker, why not
simply hit the authority servers? Why not use the root servers in the
attack?

> Preventing access to recursive servers significantly reduces the
> possible sources relied upon by a distributed mode of attack.

Your claim here restates your premise without proof. Repeating your
claim does not make it true. I have shown that it is far easier to find
a very large number of authority servers than it is to scan for
recursors.

There are many authority servers with large records, including the root
servers, that have access to very high bandwidth connections, making
them ideal for use in a DOS attack.  

Why would a DOS attacker try to search out recursors, which can be
mitigated, when the attacker could launch a much more devastating attack
with much less work?

Further, 'closing' the recursors creates additional problems, including
opportunity for additional DOS attacks.  You haven't addressed any of
these harms.  As I said, your proposed solution is worse than the
original problem.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Tue, 13 Mar 2007 14:00:47 -0400 (EDT)

Really? How?

		--Dean

---

From: Joe Abley <[email-masked]>
Date: Tue, 13 Mar 2007 14:15:56 -0400

> record types frequently found on authority servers.

I think the point is (again) that the amplification potential is  
reduced if no open recursive servers are involved. This is a re-run  
of an old thread. See, for example:

   http://www1.ietf.org/mail-archive/web/dnsop/current/msg04721.html

Joe

---

From: Joe Abley <[email-masked]>
Date: Tue, 13 Mar 2007 14:15:56 -0400

Joe

---

From: Joe Abley <[email-masked]>
Date: Tue, 13 Mar 2007 14:24:30 -0400

Incidentally,

> the abusers can be identified.

1. Host some popular content somewhere which will be resolved (most  
of the time) using a DNS name whose authority servers you control.

2. Turn on query logging on the authority servers.

3. Wait.

4. Extract list of recursive servers from log.

That finds you a long list of recursive servers. You can then either  
refine the list by probing individual servers to see whether they  
will perform recursive queries for you, or you can assume that enough  
of them will be open that the duds really don't matter.

The more popular the content, the less time will elapse in step 3.

Joe

---

From: Joe Abley <[email-masked]>
Date: Tue, 13 Mar 2007 14:24:30 -0400

Incidentally,

3. Wait.

Joe

---

From: Douglas Otis <[email-masked]>
Date: Wed, 14 Mar 2007 15:18:32 -0700

On Mar 13, 2007, at 11:00 AM, Dean Anderson wrote:

> This assertion isn't true.  Several examples were given of common  
> large record types frequently found on authority servers.

A distributed attack requires some number of servers publishing RRs  
large enough to pose a higher gain threat.  Several servers can be a  
problem, but not at the same level as with tens of thousands.   
Defending against a broadly distributed attack becomes more  
difficult.  Blocking recursive servers also disrupts services for a  
greater number of valid recipients.  Every open recessive server can  
become a proxy for the worst of the worst RR.  One poorly considered  
RR can then be fodder for tens of thousands of open recursive  
servers.  Blocking a problematic authoritative server at least  
directly affects the entity creating the problem.  Perhaps this could  
become a self healing problem.

>> Recursive servers can be easily located without any scanning

Bad actors also run authoritative servers and pay attention. : (

>> and then asked to obtain an answer referencing problematic RRs  
>> (which may be poorly considered SPF RRs).
>
> RRs which come from authority servers. If you are the attacker, why  
> not simply hit the authority servers? Why not use the root servers  
> in the attack?

Once a suitably large RR is found, open recursive servers can become  
tens of thousands of sources for this single RR.

> claim does not make it true. I have shown that it is far easier to  
> find a very large number of authority servers than it is to scan  
> for recursors.

Which is harder?  Finding a distribution of large RRs that greatly  
exceed the MTU, or finding recursive servers?  You contend finding  
recursive servers is harder, but attacks seem to demonstrate otherwise.

> There are many authority servers with large records, including the  
> root servers, that have access to very high bandwidth connections,  
> making them ideal for use in a DOS attack.

An attack may become apparent when the query rate for a specific RR  
greatly exceeds the norms.  Many of the reflected attacks using open  
recursion did not produce any statically significant effect except  
for the victim.  Apparent normality makes devising a defensive  
strategy extremely difficult.

> mitigated, when the attacker could launch a much more devastating  
> attack with much less work?

This has been a concern with Sender-ID of course, but in the case of  
open recursive servers, an attempt to mitigate open recursive attacks  
will also be highly disruptive as well.  You contend that finding  
open recursive DNS is difficult, and that finding an ample  
distribution of large RRs is comparatively easier.  Consider me to be  
skeptical.

> Further, 'closing' the recursors creates additional problems,  
> including opportunity for additional DOS attacks.

Do you mean that when a provider's DNS is taken out of service, then  
finding an alternative will become more difficult?

> You haven't addressed any of these harms.  As I said, your proposed  
> solution is worse than the original problem.

Limiting access to recursive DNS is not my proposed solution.  BCP38  
is another solution that comes to mind, but just as with limiting  
access to recursive DNS, BCP38 represents a type of hygiene that  
works best when everyone is diligent.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Wed, 14 Mar 2007 15:18:32 -0700

-Doug

---

From: Dean Anderson <[email-masked]>
Date: Wed, 14 Mar 2007 20:55:00 -0400 (EDT)

That scheme requires a high traffic site. Obviously, logging requests to
root servers also produces a pretty complete list of recursors after a
time.

However, LittleScriptKiddie (tm) doesn't have those capabilities.

Hopefully, the root operators, and the operators of such high volume
sites aren't script kiddies, and they hire someone responsible and
trustworthy staff.  

If you assume the roots and high volume sites are run by
scriptkiddies/abusers, all kinds of mischief becomes possible: this
would be insignificant in comparison. I don't think anyone considers
that to be a threat case, and I think ICANN and DoC (in the case of the
roots anyway), have an obligation to ensure that it isn't.

Because the root operators and high volume sites hire trustworthy
people, this kind of detection without scanning, isn't a threat.  
Although..... it probably should be considered in the analysis of the
recent actual abuse, which (strangely) did use recursors, a limited
small group of people can get this information effortlessly without
scanning.

Scriptkiddies still have to scan for recursors, and have lists of the
existing domains, which gives them the authority servers, which can be
searched for large records without raising suspicion.

The population that is most likely to conduct a DOS attack, (that is
scriptkiddies, not root server operators)  would be able to abuse
authority servers much more easily than recursors.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Wed, 14 Mar 2007 20:55:00 -0400 (EDT)

--Dean

---

From: Joe Abley <[email-masked]>
Date: Wed, 14 Mar 2007 21:15:42 -0400

On 14-Mar-2007, at 20:55, Dean Anderson wrote:

> That scheme requires a high traffic site.

Certainly, that's one way to do it. About two in five people being  
hammered by legions of slashdot weenies says "yes" when asked "would  
you like me to host that large file for you?" so it's not exactly  
hard to organise.

Other approaches for exercising resolvers are to embark on some other  
exercise which triggers DNS lookups as a side-effect, such as port  
scanning, or sending bulk unsolicited mail (or even just doing a lot  
of SMTP connects and then dumping the connection without sending mail).

> Obviously, logging requests to

That requires access to a root server, though, and it's not clear to  
me that many root server operators would be happy to give that access  
for the purpose of building a list of open recursive nameservers in  
order to provide amplification for a botnet.

> However, LittleScriptKiddie (tm) doesn't have those capabilities.

Whatever you prefer to believe, Dean ;-)

Joe

---

From: Joe Abley <[email-masked]>
Date: Wed, 14 Mar 2007 21:15:42 -0400

Joe

---

From: Dean Anderson <[email-masked]>
Date: Wed, 14 Mar 2007 21:23:32 -0400 (EDT)

On Tue, 13 Mar 2007, Joe Abley wrote:

> > large

That is partly right: Several old threads where your assertion was
previously shown to be false. Further, several times now, your group,
after a hiatus, resumed discussion by repeating your assertion as though
no objections were raised previously. Forthrightness and honesty would
seem to require disclosure that you have no response to the objections.  
Or at least that there are objections. Failure to disclose the
objections is misleading. Even the CIA has to do that.

http://www1.ietf.org/mail-archive/web/dnsop/current/msg04836.html

===================== 
I strongly oppose the draft for the reasons described in:
http://darkwing.uoregon.edu/~llynch/dnsop/msg03891.html
http://darkwing.uoregon.edu/~llynch/dnsop/msg03893.html
http://darkwing.uoregon.edu/~llynch/dnsop/msg03902.html

A great number of issues, logic flaws and false assumptions identified
previously with the document, have not been addressed nor corrected.

During 2 sessions of discussion, the authors made assertions for which
there is no basis in fact.  In the second session, the authors and
proponents simply repeated claims discredited in May, as though those
arguments had no prior opposition whatsoever. They just repeated a
mantra, as if repeating it often and ignoring the contrary evidence
somehow makes the mantra true.
[...]
=====================

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Wed, 14 Mar 2007 21:23:32 -0400 (EDT)

===================== 

		--Dean

---

From: Joe Abley <[email-masked]>
Date: Wed, 14 Mar 2007 21:41:19 -0400

On 14-Mar-2007, at 21:23, Dean Anderson wrote:

> previously shown to be false.

I don't think there's much benefit to the working group to be gained  
by responding to your message in any detail; the technical points  
have all been covered before, and the thinly-veiled inferences about  
my honesty and the alleged conspiracy amongst those in "my group"  
presumably sound about as ridiculous to everybody else as they do to me.

To those who routinely send me private mail asking me to please not  
feed the troll, apologies. I'll try harder.

Joe

---

From: Joe Abley <[email-masked]>
Date: Wed, 14 Mar 2007 21:41:19 -0400

Joe

---

From: Dean Anderson <[email-masked]>
Date: Wed, 14 Mar 2007 22:36:25 -0400 (EDT)

On Wed, 14 Mar 2007, Douglas Otis wrote:

> large enough to pose a higher gain threat.  

No. Just one on a 10GigE is probably just fine.

If that isn't enough, several hundred anycast root servers on high 
bandwidth links at key points in the internet ought to do pretty good.

> Several servers can be a problem, but not at the same level as with
> tens of thousands.

There aren't tens of thousands of domains with large SPF records?  
Really? Some others claim SPF is widely deployed. Some from you company 
I think. Perhaps you should check around the office and get the 'real 
story' about SPF deployment.

There aren't high volume servers with large records?  Really. Thats 
amazing.

> difficult.  

> Blocking recursive servers also disrupts services for a  
> greater number of valid recipients.  

????  This is what I said.  I think you must mean blocking during an
attack, in which case, one blocks queries from the 'target/victim' And
so the answer to that is no: Blocking queries from a 'victim' could harm
only the victim, and only if they are really a user of the recursor. You
don't need to block the recursor from everything.  By contrast, blocking 
the victim from the roots, or a large authority server could be more 
disruptive than the attack.   My customers want to see CNN.  I'm not 
going to block CNN because someone is blasting CNN with forged queries 
from my nameservers.

> Every open recessive server can become a proxy for the worst of the
> worst RR.  One poorly considered RR can then be fodder for tens of
> thousands of open recursive servers.  Blocking a problematic
> authoritative server at least directly affects the entity creating the
> problem.  Perhaps this could become a self healing problem.

This assumes the authority server has no legitimate purpose in creating 
a large DNS record.  Obviously, I think, this assumption is false, and 
you cannot base an argument on a false assumption.

> tens of thousands of sources for this single RR.

You have to find them first. Its much easier to find tens of thousands
of large DNS records, or better, a few records on some very key high
bandwidth servers.  There is a neat list of 13 IP addresses that will
net several hundred high bandwidth servers that 1) have large records,
and 2) can't be easily blocked by the recipient.

> recursive servers is harder, but attacks seem to demonstrate otherwise.

Yes. That is interesting, isn't it.  It's clear now that a certain small
group of people can find recursors more easily than the rest of the
world.  Funny coincidence, isn't it.

> finding an alternative will become more difficult?

I mean that many people have staticly configure DNS addresses, and when 
they travel to starbucks with their laptop, they won't be able to use 
their home servers if everyone follows this proposed draft.  

I mean that when you turn off recursion, you still get a referral to
authority servers, which can be large, especially if the query asked it
to be DNSSEC signed.

Sometimes, as was noted with another previous SPF problem, the 'not
recursing' is worse than the recursion.

> Limiting access to recursive DNS is not my proposed solution.  

This draft proposes limiting public access to recursive DNS. 

> BCP38 is another solution that comes to mind, but just as with
> limiting access to recursive DNS, BCP38 represents a type of hygiene
> that works best when everyone is diligent.

I agree.  

Of course, getting people to follow recommendations requires credibility
that has to be based in rationality, reason, honesty and integrity.  
Irrational and unreasonable demands will be debunked as such, and it
will harm the credibility needed for other recommendations.

Obviously, if I were the victim of such an attack, I would respond in
exactly the same way as with any other forged source IP address attack:  
I would work though my upstreams to filter out this traffic.  If it
comes from random recursors, it would be easier to filter than if it
comes from authority or root servers.  Abused recursors can be blocked
from sending unwanted responses, while permitting the wanted queries,
without serious harm to any party.  [not so with authorities see below].
All responses are unwanted temporarily, but queries are still allowed
because we want them to see our names.

Obviously, the group of abused recursive servers is easily identified,
even if there are tens of thousands, by the mere fact that no queries
were sent to the servers that provided a response. [again, not so with
key authorities, roots]

Then it is a matter of working with some of those to identify where the
forged traffic is coming from.  This identifies the provider of the
botnet/abuser.  Once they are shut, the whole abuse stops.  It is always
a myth that on large distributed attacks one needs to stop tens of
thousands of servers. That's nonsense. One typically needs to find and
stop just one botnet operator.  The more servers they (ab)use, the
easier it is to find someone who will cooperate in finding them.

If this attack became common with recursors, people would change the IP
addresses of their recursors, and then keep track of scanning. Large
sites and root operators would also keep a closer eye on who might be
logging this information and firing/charging those employees when they
are discovered.  If open relay abuse is a guide, then over time, the
chances of detection of scanning increase to close to 100%.

But if this attack became common with authorities or roots, then it
could become quite pernicious, since it would be very difficult to
distinguished the wanted responses from the unwanted responses.  The
better positioned the server is for attack, the harder it is generally
to block. [try blocking CNN or MSN, or the roots---they cannot be
'helpful' by blocking your IP address at their servers]. This is why
mitigation is difficult or impossible.  And the bad guy can do the
scanning without drawing suspicion.

So, you do the game theory: you're the bad guy, which approach do you
choose?

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Wed, 14 Mar 2007 22:36:25 -0400 (EDT)

I agree.  

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Wed, 14 Mar 2007 22:55:04 -0400 (EDT)

> you like me to host that large file for you?" so it's not exactly  

You aren't getting it. Saying "yes", and having the bandwidth to do it
are very different things. I think they have a term for small sites 
hosting (for a short while anyway) a popular file.

However, my point is this:  Those who have the big bandwidth, also have
more oversight. Besides management they have lawyers, contracts, laws,
torts, rules, etc.

> of SMTP connects and then dumping the connection without sending mail).

This exercises resolvers, but doesn't reveal open recursors--they still
need to be tested.  It also requires a great deal of effort. Sending a
lot of bulk email is obviously going to draw some complaints, and port
scanning is also going to draw some unwanted attention.

This is easier than simply scanning domains for large records or abusing
the roots? You are straining pretty hard, now.

> > Obviously, logging requests to root servers also produces a pretty
> > complete list of recursors after a time.
> 

Yes, I agree, one wouldn't think root server operators would do so on
purpose.  But I've previously found ISP admins who performed such
similar abuse.  Its possible that root operators might hire the wrong
kind of person.

> Whatever you prefer to believe, Dean ;-)

I believe you should have to prove your claims are true.  If they are
true, it shouldn't be hard.  What I believe, and what you believe is
mostly irrelevant---Its the truth of your assertions that matters.  And 
so far, you haven't proven them.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Wed, 14 Mar 2007 22:55:04 -0400 (EDT)

--Dean

---

From: Dean Anderson <[email-masked]>
Date: Wed, 14 Mar 2007 23:09:17 -0400 (EDT)

I note that yet _____again_____ you failed to offer any proof of your
assertions, but merely offer ad hominem attack on my criticism of your
repeated failure to provide proof while falsely stating contested
assertions as undisputed fact.

Your performance in this matter is clear for all to see by having done
the same trick now for a third time in a row, just as I cited.

Your childish ad hominem and attempts at ridicule are signs that
indicate an awareness of your own weakness. If you had facts, you would
cite them.  But you don't, so you call names instead.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Wed, 14 Mar 2007 23:09:17 -0400 (EDT)

--Dean

---

From: Douglas Otis <[email-masked]>
Date: Thu, 15 Mar 2007 02:24:28 -0700

> No. Just one on a 10GigE is probably just fine.

This is neglecting the basic concern.  There are large networks
everywhere.  One source of an attack at a lower gain would be a much
easier to squelch.

> story' about SPF deployment.

Sender-ID is not a matter of record deployment, but rather the number
processing the scripts.  BPC38 and ACLs prevent source spoofed reflected
attacks.  However, these precautions will not be effective against
Sender-ID exploits that obtain much higher gain measured against spam
traffic.  Of course they would be spamming anyway.  Sender-ID actually
provides a virtually free method of attack!  

> There aren't high volume servers with large records?  Really. Thats 

A lower level of distribution facilitates squelching a persistent
attack.

> going to block CNN because someone is blasting CNN with forged queries 

Yes. Squelching queries entering a network from resolvers serving a
large population of users increases the number of victims caused by a
DoS attack.  On the other hand, if CNN published a large RR and then
allowed this RR to support a high gain reflected attack, squelching
traffic from this server could help mitigate an attack with less
collateral damage.  

> you cannot base an argument on a false assumption.

There are a number of strategies one might use to squelch a DoS attack,
provided an attack is apparent.  An abnormally high rate of queries for
some large RR provides evidence of an ongoing attack at the server.  

> and 2) can't be easily blocked by the recipient.

What gain is obtain in this scenario?

> world.  Funny coincidence, isn't it.

A recursive server for a large population of users simply stands out by
the level of requests being made.  Examine a DNS log.  It is not a
mystery.

> their home servers if everyone follows this proposed draft.

This would not be a default setting.  They should also know how to
re-adjust the settings.  Tunneling over SSH via port 443 also thwarts
poisoning that might be attempted and this port is never blocked.

> authority servers, which can be large, especially if the query asked it

Some of the reflected attacks used several KB RRs.

> recursing' is worse than the recursion.

I am guessing, but I suspect this depends upon what is being measured.

> If it comes from random recursors, it would be easier to filter than
> if it comes from authority or root servers.

When an attack is coming from thousands of open recursive servers all
attempting to forward some KB fragmented RR, the problem is not easily
squelched.  One might limit which of the roots are allowed transit in
either direction.  That could limit the gain of the attack to nil.

> Abused recursors can be blocked from sending unwanted responses, while
> permitting the wanted queries, without serious harm to any party.
> [not so with authorities see below]. All responses are unwanted
> temporarily, but queries are still allowed because we want them to see
> our names.

When there are so many of them, the attack from each server is in the
noise.  Only the victim clearly sees the attack in progress.  How can
that be stopped?

> were sent to the servers that provided a response. [again, not so with

You mean the victim can see the source of the attack?  When it is coming
from virtually everywhere, the victim is left with few options.

> easier it is to find someone who will cooperate in finding them.

Some C&C sources can be identified, but this game is evolving.  It is
not just one botnet operator.  Few servers are in the same place more
than a few minutes.

> chances of detection of scanning increase to close to 100%.

There is no need to scan for these servers.

> scanning without drawing suspicion.

To squelch an attack, why not block servers permitting a high gain
reflected attack?

> So, you do the game theory: you're the bad guy, which approach do you

Lowering the gain achieved lessens the chance resource will be expended
in perhaps a futile effort.  Not allowing open recursive DNS still
appears to be a good solution at this time.  

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Thu, 15 Mar 2007 02:24:28 -0700

-Doug

---

From: Dean Anderson <[email-masked]>
Date: Thu, 15 Mar 2007 14:13:29 -0400 (EDT)

> everywhere.  One source of an attack at a lower gain would be a much

Sure.  And there are authority servers on those networks with large 
records and large bandwidth.  My point here is that a lot of servers 
aren't necessary for an if you have a few with big bandwidth.  Such an 
attack is easier to conduct because the abuser doesn't have to look very 
far to find the aggregate bandwidth needed.

> processing the scripts.  

Umm, '_a_ problem with sender-id involves the processing of scripts'. 
This isn't the only problem, but the relevant issue here is the size of 
the DNS record.

> BPC38 and ACLs prevent source spoofed reflected attacks.

I agree, this is the solution that best addresses the problem.

> However, these precautions will not be effective against

Agreed. I was against SPF several years ago, too. sigh.

> A lower level of distribution facilitates squelching a persistent

This is true _Only_ if they can be squelched, and only if the
'squelching' isn't worse than the attack. For example, blocking the
victims nameservers from the roots is worse, since now they have no DNS.

> traffic from this server could help mitigate an attack with less

Not if my customers want to get to CNN.  That's worse: thats a total 
outage to CNN.  I don't think you are appreciating the effects of 
mitigation may be worse than the attack itself.

> What gain is obtain in this scenario?

Experiment for yourself: block the root servers. See how well DNS works
afterwards.  How do you find, say, .com without the roots?  Load it into
your cache???  Now do all secondary domains. Suppose the .com servers
are used? Now try all of .com. 

The mitigation is worse than the attack.  For the attacker:
	no searching is necessary, 
	the several hundred root copies have high bandwidth, 
	the mitigation of blocking roots is worse.
	the victim has to sort wanted responses from unwanted responses.

> the level of requests being made.  Examine a DNS log.  It is not a

I understand the 'how' of getting the information. The coincidence is
the point here.  The logs are from authority servers, which get requests
from recursors.  The authority servers that talk to a large number of
recursors are run by large ISPs, root server operators, and secondary
domain operators. Those authority servers are administered by a finite
group of administrators.  These administrators have easy access to the
identification of large numbers of recursors.  The rest of the world
doesn't have this access. For the small group that does have access,
though, abusing recursors is quite easy.  For the rest, its quite hard.

The strange coincidence is that the actual abuse so far has involved
recursors, not authority servers, which suggests the abuser(s) works for
a fairly large ISP or a root server operator, or a secondary level
domain operator or maybe a cctld operator, and has used logs of their
servers to obtain the list of recursors.  While seemingly broad, this
probably represents a small number of administrators---probably no more
than several hundred people.

> This would not be a default setting.  

It is the default if you don't use DHCP.

> They should also know how to re-adjust the settings.  Tunneling over
> SSH via port 443 also thwarts poisoning that might be attempted and
> this port is never blocked.

Most people don't do that.  'Tunneling' as a solution to various
problems, has long be suggested, and long been rejected as a
non-starter.  Only a small percentage of the internet users even know 
what SSH is.

> Some of the reflected attacks used several KB RRs.

So? The math of an attack is not limited to RR size alone.  
  
    Number of Queries times Response Size equals Attack Volume.  

Large Response size is not the only factor.  It has to be large enough,
and also commonly found.  Closed recursors still give an amplied
response, and would still be commonly found.

> I am guessing, but I suspect this depends upon what is being measured.

I'm referring to 
http://www1.ietf.org/mail-archive/web/dnsop/current/msg04978.html
=======================
> Victim servers would each answer that they are non-authoritative but
> would have to include large domain (imagine big.bad.example.com being
> close to maximum DNS label size)

No, only one server would answer.  That server either recurses (remember
the discussion about "reflectors are evil"), with the right answer (from
cache, even), or else it gives a (relatively larger) response containing
authority records directing to the nameservers that are authoritative
for the domain.

[Gee, it looks like reflectors are actually "good". I wish I had put
this in my opposition to draft-ietf-dnsop-reflectors-are-evil-02.txt]
=======================

> either direction.  That could limit the gain of the attack to nil.

Sure it is. They are sending responses. It is easy for upstream to 
filter DNS response packets from a list of recursors. 

> noise.  Only the victim clearly sees the attack in progress.  How can

The victim contacts their upstreams with a list of IPs. It is no
different whatsoever from a smurf attack.

> You mean the victim can see the source of the attack?  

They can clearly see that they are getting responses for which there was 
no query. Just like in a smurf attack.

> When it is coming from virtually everywhere, the victim is left with
> few options.

This claim is nonsense. Years of abuse filtering for various forged
source IP attacks prove otherwise.  I have a great deal of personal
experience with this, having excited a certain group of script kiddies
with botnets over the years.

> Some C&C sources can be identified, but this game is evolving.  

Yes.  But information theory works here, too.

> It is not just one botnet operator.

It often a small I think.  You don't need to get the botnet operator, to
get them to stop. You just need to get close, and kill some of their
bots, and they will stop.

> Few servers are in the same place more than a few minutes.

DNS servers tend to stay put.  Some operators will be helpful in 
tracking down the bots that are spoofing traffic.

> There is no need to scan for these servers.

There is if you aren't one of the people who has privileged access to
this information.

> To squelch an attack, why not block servers permitting a high gain

As I already said: Experiment for yourself; block the root servers, see
how well DNS works after that.

> appears to be a good solution at this time.  

You think blocking the roots is a good solution, too.  I don't think you 
fully appreciate the problem.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Thu, 15 Mar 2007 14:13:29 -0400 (EDT)

I'm referring to 

		--Dean