Multiplex communications – Pathfinding or routing – Switching a message which includes an address header
Reexamination Certificate
1999-12-06
2004-08-03
Pezzlo, John (Department: 2662)
Multiplex communications
Pathfinding or routing
Switching a message which includes an address header
C711S163000, C713S154000
Reexamination Certificate
active
06771649
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a method and apparatus for a middleware approach to asynchronous and backward-compatible detection and prevention of Address Resolution Protocol (ARP) cache poisoning, and more particularly, to a method and apparatus for implementing a cache poisoning checker module, driver and user-level application in a streams-based network subsystem to detect and prevent ARP cache poisoning.
2. Description of the Art
Address Resolution Protocol (ARP) cache poisoning is the act of a malicious host/server in the local area network (LAN), of introducing a spurious (i.e., false) Internet Protocol (IP) and/or Ethernet mapping address in another host's ARP cache. The effect of ARP cache poisoning is that network traffic intended for one host is diverted to a different host or to no host at all. ARP cache poisoning, and thus the diverting of messages from their intended recipients, can be accomplished by ARP “spoofing”, that is attacking at a host/server's ARP cache the assigned addressing routes of the network. Accordingly, ARP spoofing is a serious concern to network managers and participants as ARP spoofing can be used to compromise network security.
There are four ways in which a host's ARP cache can be poisoned based on root address access in the LAN, that is during the processes of: receiving an address request; receiving an address response; sending an address request; and, sending an address response. As the protocol is stateless, that is, there is no built-in tracking or “memory” of address requests and/or responses, a malicious host can attack root addresses by any of these processes.
The first way to poison an ARP cache by spoofing is during the process of the receipt of an address request. As ARP implementations cache entries based on the requests they receive, an attacker only has to pretend to be sending out a legitimate address request to poison the ARP cache of the request host recipient. That is, if malicious host A sends out a broadcast ARP request packet for host B, host C might cache the mapping address information about host A based on the request host A has sent out.
The second way of ARP cache poisoning by spoofing is during the process of receiving an unsolicited address response. That is, an address response that is unsolicited (i.e., not associated with an address request) will be honored by an ARP implementation due to the fact it is stateless. Thus, a malicious host has only to independently send an address response ARP packet on the LAN with a spurious mapping address to poison the ARP cache of the response recipient. This unsolicited address response can be broadcast to poison the ARP cache of every host on the LAN.
Rather than send an unsolicited address response, or a spurious address request, a third way in which a host's ARP cache may be poisoned is by a malicious host waiting until the victim host issues an address request and then responding by sending a spurious address response to that request. In this case, if the host to which the address request was sent (i.e., the legitimate host) responds to that request, there is a race condition that the malicious host may win. In this case, it is the address response that is received later that will supercede the entry in the victim host's cache corresponding to the address response that is received earlier (i.e., it is overwritten).
A fourth way of ARP cache poisoning by spoofing is when a malicious host sends out both a spurious address request and a spurious address response corresponding to that address request. This may be used to poison a victim host's ARP cache in the case where a victim host has a partial solution to the poisoning problem and does in fact “remember” an address request: either it's own request or from another host, and only cache's a response to a “remembered” request.
Thus, as can be seen, ARP cache poisoning by root IP and Ethernet address attacks by spoofing can be done quite simply in a number of ways.
SUMMARY OF THE INVENTION
Accordingly, the present invention allows for a method and apparatus for detecting and preventing Address Resolution Protocol (ARP) cache poisoning having an implementation in middleware, without any access or change to any operating system source code, and which is asynchronous and backward compatible.
To detect and/or prevent ARP cache poisoning, a Cache Poisoning Checker (CPC) module is implemented in a stream stack pertaining to the ARP and is used to intercept messages containing Internet Protocol (IP) and/or Ethernet addresses traveling both upstream and downstream between servers in the network operating system. Furthermore, a CPC stream driver and CPC user-level application are implemented in a separate stream, the CPC driver providing an interface to and between the user-level application and the CPC module. Both the CPC stream module and the CPC user-level application utilize an algorithm in the prevention and detection of ARP poisoning.
In an embodiment, the present invention is disclosed utilizing as an example a Solaris 2.6 network operating system platform for an environment in which any number of hosts in a LAN communicate using a Transmission Control Protocol/Internet Protocol (TCP/IP) suite over a shared Ethernet.
REFERENCES:
patent: 5224166 (1993-06-01), Hartman, Jr.
patent: 5229988 (1993-07-01), Marbaker et al.
patent: 5309437 (1994-05-01), Perlman et al.
patent: 5473771 (1995-12-01), Burd et al.
patent: 5526489 (1996-06-01), Nilakantan et al.
patent: 5668952 (1997-09-01), Slane
patent: 5708654 (1998-01-01), Arndt et al.
patent: 5724510 (1998-03-01), Arndt et al.
patent: 5757924 (1998-05-01), Friedman et al.
patent: 5802285 (1998-09-01), Hirviniemi
patent: 5812767 (1998-09-01), Desai et al.
patent: 5872847 (1999-02-01), Boyle et al.
patent: 5909446 (1999-06-01), Horikawa et al.
patent: 5917900 (1999-06-01), Allison et al.
patent: 5978854 (1999-11-01), Fujimori et al.
patent: 6081533 (2000-06-01), Laubach et al.
patent: 6330615 (2001-12-01), Gioquindo et al.
Dutta Partha
Tripunitara Mahesh V.
AT&T Corp.
Odland David
Pezzlo John
LandOfFree
Middle approach to asynchronous and backward-compatible... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Middle approach to asynchronous and backward-compatible..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Middle approach to asynchronous and backward-compatible... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3273469