[dns-operations] [Nst] A Case Against DNSSEC (A Matasano Miniseries)

[Rodney Joffe]

On Apr 4, 2007, at 5:06 PM, Andrew Sullivan wrote:

> On Wed, Apr 04, 2007 at 07:49:47PM +0000, Paul Vixie wrote:
>> this is where i think you're missing the point.  the goal of the  
>> dns shield
>> project is to make attacks of this kind economically  
>> unattractive.  if a DDFH
>> can't affect AOL's (to pick an example) resolution success rate  
>> for a victim
>> online casino, then the value of DDFH as an extortion tool  
>> plummets, even if
>> quite a few smaller ISP's see that online casino as "offline"  
>> during attacks.
>
> It seems to me that this approach, while certainly interesting, needs
> to have some things made explicit.
>
> First, for this to be effective, the shield has to be aligned quite
> well in front of the desired users of the to-be-attacked people.  That
> is, if you put the shield on AOL and three other large ISPs, but the
> attack works by targetting a service used only by people not on those
> ISPs, the shield isn't effective.

It is extremely effective for AOL and three other large ISPs. They  
have the philosophical position that I consider "good".
>
> The second thing is that this _does_ create two classes of Internet
> user (I suppose a better analogy is "two classes of Internet
> neighbourhood"): those who get "shielded" and those who don't.

Similar to those who have access to IPv6 and those that don't.
Those that have access to native Multicast and those that don't.
Those that have ISPs that provide spam filtering, and those that don't.
Those whose access/transit is via SONET or redundant paths and those  
that don't.
Those whose providers do useful RPF and end up protecting them from  
attacks, and those that don't.
Etc.
And your point is?

>   I
> don't know whether I think this is good or bad, but it is something
> one had better acknowledge, I think -- and certainly is something one
> oughtn't to deny.  Whether there is a practical effect of that
> two-class arrangement I don't know.
You do. You may just be disingenuous. so I'll help. There are two  
classes. Those whose providers do "the right thing(tm)" and those  
whose providers don't.
>
>
> I'm also wondering about the following.  If the attackers put their
> bots or whatever behind the shield as well as everywhere else, then
> the infrastructure formerly protected by the shield is subject to
> attack, so the shield isn't really going to work in the case where the
> attackers have large numbers of their attack agents inside the
> protected ISP's network.  If I understand that correctly, then it
> almost seems to create a new kind of attack, whereby the attacker can
> _explicitly_ go after (say) "AOL customers" and target them
> effectively by attacking inside the "shielded area".  Is the idea,
> then, that the ISPs have a strong incentive to mitigate such attacks
> quickly, and the data about their network to do it more effectively
> than an authoritative operator does?
>
> If I am right in this last part of my understanding (and my apologies
> to those who are brighter than I am and who are exasperated by my
> foolishness and ignorance), that doesn't mean this approach is
> useless.  But it does seem to mean that very good coverage by shields
> needs to be attained (somewhere over 80% of all ISP recursing
> nameservers, I should think, or the network effects won't be enough to
> blunt the new attack vector) and also that shields can't be the only
> strategy for a given service (so that users behind a shield have an
> alternative way of getting resolution to their queries).  Have I
> missed something obvious?

I can only talk about the NeuStar Ultra Shield nodes. The recommended  
design has the Shield node acl'd so that only the ISP's recursive  
servers see the announcements from the Shield's node. So the ISP's  
users not have access to the shield node. In the case of a Shield ISP  
that also has other networks as downstream customers who do not use  
the ISP's recursive servers, the ISP has the option and ability to  
provide controlled access from the customer's recursive servers to  
the Shield node, and as Paul points out, also has the relationship  
and motive to enforce policy on those customers, should they be the  
willing or unwilling source of an attack.