Use a host-based IDS. We can eliminate ambiguities in the traffic stream by running the intrusion detection system (IDS) on all of the end-system hosts rather than by (or in addition to) passively monitoring network links. As the host IDS has access to the protocol state above the IP and transport stacks, it has unambiguous information as to how the host processes the packet stream. However, this approach is tantamount to giving up on network intrusion detection, as it loses the great advantage of being able to provide monitoring for an entire site cheaply, by deploying only a few monitors to watch key network links. Host-based systems also potentially face major deployment and management difficulties. In this work, we are concerned with the question of whether purely network-based IDS's can remain viable, so we do not consider this solution further.
Understand the details of the intranet. In principle, a NIDS can eliminate much of the ambiguity if it has access to a sufficiently rich database cataloging the particulars of all of the end-system protocol implementations and the network topology. A major challenge with this approach is whether we can indeed construct such a database, particularly for a large site. Perhaps adding an active probing element to a NIDS can do so, and there has been some initial work in this regard [9]. However, another difficulty is that the NIDS would need to know how to make use of the database--it would require a model of every variant of every OS and application running within the site, potentially an immense task.
Bifurcating analysis. Finally, in some cases the NIDS can employ bifurcating analysis [12]: if the NIDS does not know which of two possible interpretations the end-system may apply to incoming packets, then it splits its analysis context for that connection into multiple threads, one for each possible interpretation, and analyzes each context separately from then onwards.
Bifurcating analysis works well when there are only a small number of possible interpretations no matter how many packets are sent. An example would be in the interpretation of the BACKSPACE vs. DELETE character during the authentication dialog at the beginning of a Telnet connection (before the user has an opportunity to remap the meaning of the characters): generally, either one or the other will delete the character of text most recently typed by the user. The NIDS can form two contexts, one interpreting DELETE as the deletion character, and the other interpreting BACKSPACE as the deletion character. Since the end-system will be in one state or the other, one of the analysis contexts will be correct at the NIDS no matter how many packets are sent.
However, bifurcating analysis will not be suitable if each arriving
ambiguous packet requires an additional bifurcation, as in this case an
attacker (or an inadvertent spate of ``crud'') can send a stream of packets
such that the number of analysis contexts explodes exponentially,
rapidly overwhelming the resources of the NIDS. Consider, for example,
the attack shown in Figure 1.
If the NIDS bifurcates its analysis on receipt of each potentially
ambiguous packet, it will rapidly require a great deal of state
and many analysis threads.
Once it has seen the eight packets
shown, it will need threads for the possible text root, nice,
rice, noot, niot, roce, roct, etc. 