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.comTitle: 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.