[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Cc: dnsop@cafax.se
From: Edward Lewis <edlewis@arin.net>
Date: Tue, 15 Oct 2002 11:46:01 -0400
In-Reply-To: <200210151505.AAA07561@necom830.hpcl.titech.ac.jp>
Sender: owner-dnsop@cafax.se
Subject: Re: Interim signing of the root zone.

Perhaps the issue here is the expectation of "security."

At 0:04 +0859 10/16/02, Masataka Ohta wrote:
>It's much easier and secure to prevent forged route to the current
>UNICAST root servers and to catch the attacker.

Designing a defense to prevent an attack is not wise.  Designing a 
defense to handle the occurrence of an attack is much better.

>That's why real world credit card companies requires realtime
>verification of credit status.

This isn't exactly true.  The verification by a vendor of the card 
holder's status is for the benefit of the vendor (too).  When a card 
holder receives a bill, the holder has the opportunity to dispute a 
charge.  If the holder is justified, the vendor does not get paid, it 
is the vendor who suffers the loss.  Now, the vendor may be insured 
against this kind of loss, if so, is required to file a police report 
- so now we've involved law enforcement and the insurance industry 
too.

This isn't DNSOP-worthy material on the surface.  But it's an example 
of how multi-dimensional security is.  At the time of the transaction 
some steps are taken.  But as problems escalate, more and more 
back-end activity happens with the power to "restore order."  (We 
bump serious protocol errors up the stack.)

Signing the root zone won't stop someone from attacking DNS, much as 
there are still murders in society in which murder is illegal.  If 
society can't prevent murder, engineers can't prevent attacks on DNS 
- but at least accountants can recover financial losses.  I'm urging 
a more realistic view of what is being accomplished in signing the 
root zone.  We're not stopping anything, we are simply making it 
harder and less damaging (esp. in the long term) when an attack 
happens.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

#----------------------------------------------------------------------
# To unsubscripbe, send a message to <dnsop-request@cafax.se>.

Home | Date list | Subject list