[Olsr-dev] ARP prevention!

Andrea Di Pasquale (spam-protected)
Thu Aug 18 13:37:01 CEST 2011

There are three types of solutions:

1) Authentication
See the Cisco Security ARP, it uses DHCP server to authenticate hosts and is a centralized solution.

2) Reactive
See XArp, Arpwatch. They detect the MAC spoofing during the attack but without blocking.

3) Proactive
ArpON defines the rules of language between hosts on preventing these attacks. ArpON is a protocol that allows you to work safely without any ARP authentication. Why no authentication? Why it don't use encryption or external server, is based on the rules of language that all hosts Arpon must respect. These rules of language allow exactly total protection by ARP spoofing & co for all hosts that speak the language of ArpON.

To understand these rules and this language, the documentation is more than excellent. The final algorithm is HARPI:


HARPI is like a puzzle. To understand you need to understand the pieces of SARPI and DARPI:


Finally, HARPI combine SARPI and DARPI in an one protocol solution.

I do not want to do a plugin for olsrd.
I believe that ARP poisoning is a problem for all of L3 protocols.
I want to suggest that used ArpON + OLSRd together increases protection for those who use this network stack.



Il giorno 18/ago/2011, alle ore 13:17, Ferry Huberts ha scritto:

> I think Henning asked the right questions:
> - how is the MAC address authenticated?
> - what measures are taken to detect MAC spoofing.
> these are base questions because a MAC address is trivial to spoof
> please explain (at least) these issues so that we do not need to read
> all of the arpon docs
> I still think this is a layer 1.5 issue and of no concern to olsr
> On 08/18/2011 12:59 PM, Andrea Di Pasquale wrote:
>> Il giorno 18/ago/2011, alle ore 12:42, Henning Rogge ha scritto:
>>> On Thu, 18 Aug 2011 11:50:57 Andrea Di Pasquale wrote:
>>>> ArpON does what you're asking with the cooperation of all nodes. :)
>>>> Read please these links:
>>>> http://arpon.sourceforge.net/
>>>> http://arpon.sourceforge.net/documentation.html
>>>> http://arpon.sourceforge.net/algorithms.html
>>> From what I read ARPon does work if the attacker cannot spoof its MAC address 
>>> Spoofing the MAC address is trivial in wireless networks.
>>>> In ARP, you solve the problem with authenticating each host and ArpON does
>>>> it.
>>> No, it does not.
>>> ARPon verifies that the MAC address of a communication partner belongs to the 
>>> verified node, nothing more.
>> ArpON is a proactive solution o proactive protocol because it works with cooperative node. 
>> You can to see ArpON as an evolution of ARP protocol.
>> ArpON doesn't authenticate the host as Cisco DAI to do with DHCP server.
>> See here:
>> http://arpon.sourceforge.net/img/algo/HARPI.jpg
>> These algorithms don't implements an authenticate solution.
>> ArpON sets precise policies for ARP. Thus, ARP works in secure mode without cryptography.
>>> Imagine the following scenario.
>>> We have two verified users Alice (A) and Bob (B), which cannot directly hear 
>>> each other in the mesh.
>>> The attacker Mallory sets up two nodes, one near Alice (MA) and one near Bob 
>>> (MB) which are connected by a hidden channel (a cable for example).
>>> Mallory now begins to replay the traffic he hears on each node on the other 
>>> side, including MAC addresses.
>>> A --- MA --- MB --- B
>>> The OLSR instance of Alice will hear OLSR HELLO messages from Bob, which will 
>>> form a link between the two.
>>> When an unicast packet has to travel from Alice to Bob, Alice sends an ARP 
>>> challenge to Bob.
>>> MA will hear the ARP request and replay it on MB, where it will be heard by 
>>> Bob.
>>> Bob will reply with a cryptographically signed ARP response, which will be 
>>> transmitted by MB to MA and then to Alice.
>>> Alice is now sure that she knows the MAC-Address of Bob (which is true).
>>> But she still communicates with Bob through the cable between MA and MB, which 
>>> is controlled by Mallory.
>> This is a problem of OLSRd, it isn't problem of ARP protocol.
>> Andrea
> -- 
> Ferry Huberts

More information about the Olsr-dev mailing list