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.htmlTitle: Intrusion Detection for Domain Name Systems and Routers
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.