Re: DNS Security

[Jeff Williams <jwkckid1@ix.netcom.com>]

Don,

  Thanks for this post.  I have tried in several instances to point out
that what the draft currently has stated in section 7 or the Draft is
very inadaquate.  I have also pointed out that PGP is not exceptable.
In addition RFC 2065 is the current IETF standard for DNSSEC.  I have
recomended, though not directly to RFC 2065, that IETF standards be
what is implimented.  To no availe I might add.... :(

Donald E. Eastlake 3rd wrote:
> 
> I think discussion of detailed security mechanisms is a bit off the mark
> for this list.  However, if people actually want to know what's going on
> in DNS Security, I suggest looking at (1) RFC 2065 which is the adopted
> IETF Proposed Standard for DNS Security (Proposed is the first of the
> three rungs on the ladder leading to Full Standard status), (2) the
> draft-ietf-dnssec-update-03.txt IETF draft on secure udate, and (3) the
> references from the Trusted Information Systems web page to the Beta
> implementation of DNSSEC which is currently available from TIS
> (<http://www.tis.com/docs/research/network/index.html> is a good place to
> start).  Interestingly enough, their implementation of DNSSEC has been
> approved for export in source code including the cyrpto routine calls but
> not the crypto software itself.  (You need to get RSAREF or EuroREF
> yourself to build it.)
> 
> Donald
> 
> On Sun, 12 Jan 1997, Jeff Williams wrote:
> 
> > Date: Sun, 12 Jan 1997 04:12:37 +0000
> > From: Jeff Williams <jwkckid1@ix.netcom.com>
> > To: Ihac Org <iahc-discuss@iahc.org>
> > Subject: DNS Security
> >
> > All,
> >
> >   Re-opening this thread.  As I have indicated in previous
> > postings, I have trouble with the Dec 19 draft in reguards
> > to security handeling.  Though the particulars may be made
> > the responsibility of CORE (Yet to exist), I think it important
> > to provide guidelines in the draft that are much better that
> > what is currently there.
> >
> >   Attached is an .HTM file that is from some security I did
> > in conjunction UC Davis in this reguard.  It points out
> > some "Holes"  that should be addressed for DNS.  I think
> > it is pretty self explanatory.
> >
> > Regards,
> > --
> > Jeffrey A. Williams
> > DIR. Internet Network Eng/SR. Java Development Eng.
> > Information Eng. Group.
> > Phone :972-447-1878
> > E-Mail jwkckid1@ix.netcom.com
> >
> 
> =====================================================================
> Donald E. Eastlake 3rd     +1 508-287-4877(tel)     dee@cybercash.com
>    318 Acton Street        +1 508-371-7148(fax)     dee@world.std.com
> Carlisle, MA 01741 USA     +1 703-620-4200(main office, Reston, VA)
> http://www.cybercash.com           http://www.eff.org/blueribbon.html
> 
>     ---------------------------------------------------------------
> 
> Intrusion Detection for Domain Name Systems and Routers
> 
> ----------------------------------------------------------------------
> 
> Introduction
> 
> This page describes our intrusion detection work for two main network
> infrastructure components. They are domain name systems and routers.
> 
> A domain name system (DNS) is a network service used to implement a
> large mapping. For instance, DNS maps IP addresses to host names and
> vice versa. Many distributed applications, such as file transfer,
> remote login, electronic mail, and WWW, rely on DNS. Entity
> authentication may fail if host names are used for authentication and
> the mapping is compromised.
> 
> We propose a detection-confirmation strategy to protect DNS. DNS
> traffic is checked against our "specifications" and deviations from
> these specifications are noted as anomalous. By specifications, we
> refer to the expected behaviors of DNS that are security-related. For
> each deviation, the intrusion detection component confirms with a
> server responsible for the corresponding part of the database. If the
> monitored traffic disagrees with the authoritative answer, this event
> is flagged as a possible attack. We have written specifications for
> DNS to catch most of the known attacks. Additional work is required to
> implement our scheme to evaluate its effectiveness and its performance
> overhead, and to investigate its ability to detect unanticipated
> attacks.
> 
> We have worked on a problem in which a router may use control packets
> to redirect network traffic to itself and then remove these transit
> packets. These malicious routers are called blackholes. The blackhole
> attack can cause widespread denial of service.
> 
> We propose a system diagnosis approach to locate blackhole routers. In
> this approach, routers test each other to determine which ones are
> blackhole routers. We have designed protocols to diagnose blackhole
> routers under some conditions, which concern how "smart" the
> blackholes are, the number of blackholes that can occur
> simultaneously, the routing protocols used, and the connectivity of
> the networks. Algorithms have been designed to diagnose blackhole
> routers. Additional work is required to generalize our results by
> relaxing some of the assumptions in our system model. Moreover, we
> will study intrusion detection for other router and routing protocol
> attacks.
> 
> Additional information
> 
>    * S. Cheung, K.N. Levitt, C. Ko, "Intrusion Detection for Network
>      Infrastructures". 1995 IEEE Symposium on Security and Privacy,
>      Oakland, CA, May 1995. [Abstract]
> 
> ----------------------------------------------------------------------

Regards,
-- 
Jeffrey A. Williams
DIR. Internet Network Eng/SR. Java Development Eng.
Information Eng. Group. 
Phone :972-447-1878
E-Mail jwkckid1@ix.netcom.com