System and Method for Traffic Interception by a Third Party Network Entity using Address Resolution Protocol
Publication Date: 2012-Aug-20
The IP.com Prior Art Database
AbstractPresented a method to force IP traffic inside the same ethernet broadcast domain to pass through a 3d party entity using Address Resolution Protocol (ARP) spoffing technique. The method forces any given pair of nodes to communicate via a third node by intercepting ARP requests and faking ARP replies.
Page 01 of 3
Ȉ ˇ ˄ ˙ ˝ ˛ ˚ ~˙ ~
What is the problem solved by your invention?
Forcing IP traffic inside the same ethernet broadcast domain to pass through a 3d party entity. Connecting two [virtual] computers using [virtual] ethernet adapters attached to the same [virtual] broadcast domain yields the base network performance. At the same time it is sometimes beneficial to force their traffic pass
through a 3d party entity, e.g. a network intrusion detector, in the bump-in-the-wire-appliance (BIWA) fashion.
Describe known solutions to this problem (if any).
Problem can be solved using separate virtual broadcast domains or in the physical
world by actually bumping an appliance in the wire.
What are the drawbacks of such known solutions, or why is an > additional solution required?
In the virtual case, using single broadcast domain yields better performance. More resources are needed in order to manage multiple broadcast domains. In the physical case, the wire can only be cut in one point, thus dividing the broadcast domain into two parts.
Briefly describe the core idea of your invention (saving the details for question #3 below).
When the nodes initiate communication they use Address Resolution Protocol (ARP) to locate each other. Provided support from the [virtual] switch hardware, we
propose using selective Media Access Control address (MAC) spoofing technique by the 3d party entity (e.g., BIWA), connected to the same broadcast domain, allowing to force any given pair of nodes to communicate via a third node by intercepting
ARP requests and faking ARP replies.
Describe the advantage(s) of using your invention instead of the known solutions described above.
The communicating nodes can remain on the same broadcast domain thus achieving best performance when no 3d party entity (e.g., BIWA) intervention is required.
Network topology/administration complexity is also preserved.
In the normal flow of destination MAC address resolution every node connected to the broadcast domain receives the ARP request, matches the destination IP with its own, and if the match is found, returns ARP reply with its MAC as the source MAC address.
In this disclosure we propose intervening in the ARP protocol by the 3d party entity (e.g. BIWA) with the help of the [virtual] switch in the following way:
When configured in a certain way, [virtual] switch will forward all ARP packets to
a designated 3rd party entity (e.g., BIWA) instead of forwarding them to every node on the broadcast domain.
When an ARP request arrives to the 3rd party entity (e.g., BIWA):
It will look up the requested destination MAC address (rDST) in its
configuration (see note #1 below).
It will check if the source MAC address (rSRC) and rDST are allowed to
If so, it will send ARP reply with rTRG as the source MAC address (i.e.,
rSRC) thus allowing direct communication.
Page 02 of 3
Otherwise, it will send ARP reply with its own MAC address as the sou...