[Olsr-dev] ARP prevention!

[Andrea Di Pasquale]

Sorry but if you want to route this path:

HostA <=> HostC <=> HostB

indirectly OLSRd uses ARP protocol in kernelspace for understanding who is HostC and HostB. ArpON doesn't use criptography, It only uses policies for make the ARP protocol secure to avoid attacks and in a broadcast domain it is essential.

Each host in the OLSRd network has an association:

MAC - IPv4

in the broadcast domain. If OLSRd choose this path:

HostA <=> HostC <=> HostB

But really the true path is:

HostA <=> HostC <=> HostD <=> HostB

because HostD is poisoning the Arp Cache of HostC and HostB, this Man In The Middle intercepts the multihop traffic in trasparent mode.
Whit this attack, any L3 protocol in point-to-point, point-to-multipoint, multipoint domain of network are subject to this attack in L2 included OLSRd, IPv4 & co routing protocols.

Thanks,


Andrea

Il giorno 17/ago/2011, alle ore 15:56, Jeremy Lakeman ha scritto:

> Adding layer 2 security to a mesh network sounds completely worthless
> to me. We're not worried about preventing attacks that work on layer 2
> ethernet switches because there aren't any switches in a wireless
> mesh.
> 
> Olsrd is layer 3 store and forward routing. In order to participate in
> the mesh, every host must be able to communicate in the clear with
> each other, in exactly the same way your home PC communicates with
> your DSL/Cable modem. Every host on the mesh has the same opportunity
> to sniff traffic as an FBI interception device installed at your ISP.
> 
> You have to treat the mesh as a hostile environment like the internet.
> Without end to end encryption and authentication at an application
> layer, you end up with no security at all.
> 
> HostA <=> hostC <=> HostB
> 
> There's nothing stopping hostC here in your diagram from verifying his
> identity with both hosts A and B via your hypothetical ArpON
> implementation. Yet still having complete control to intercept,
> rewrite or impersonate packets from A <==> B.
> 
> On Wed, Aug 17, 2011 at 10:51 PM, Andrea Di Pasquale
> <(spam-protected)> wrote:
>> Hi,
>> 
>> Because in a local network with IPv4, each host can communicate with other hosts inside the network thanks to ARP. In a multihop network as olsrd, olsrd does its job network layer, but each route for every host works in conjunction with ARP in the Datalink.
>> Example I want to reach node B from A:
>> 
>> HostA <=> hostC <=> HostB
>> 
>> Olsrd will do its work, but will be able to decide the route ACB thanks to the existence of nodes C and B. The existence of each network node is determined by ARP.
>> Consider an additional node, the node D that makes Man In The Middle using ARP Spoofing masquerading as a node B to C and C to B:
>> 
>> HostA <=> hostC <=> hostD <=> HostB
>> 
>> OLSRd will always choose the same route. HostD will be able to intercept all traffic from/to hostA <=> HostB and OLSRd will not be able to avoid similar situations.
>> 
>> That's why I think ArpON is useful and helps to avoid situations like these.
>> 
>> The benefits are lots if we speak of stack of decentralized and cooperative network:
>> 
>> Applications -> All services
>> Transport -> TCP, UDP & co
>> Network -> IPv4 with OLSRd
>> Datalink -> ARP with ArpON
>> 
>> This stack is able to secure all services running at the Application level because the ArpON authenticates each host in the network, OLSRd handles each route for host in the network secure from attacks, TCP and UDP make their work and each services at the top is secure from any attacks.
>> 
>> Thanks,
>> 
>> 
>> Andrea
>> 
>> Il giorno 17/ago/2011, alle ore 10:08, ZioPRoTo (Saverio Proto) ha scritto:
>> 
>>>> I want to do a port of ArpON (www: http://arpon.sourceforge.net) for OLSRd project for securing MAC layer (IPv4 environment) against
>>>> Man In The Middle attacks through ARP Spoofing attack and his derived attacks.
>>> 
>>> Hello,
>>> 
>>> your project looks very interesting. However I don't understand why we
>>> should not just run olsrd and the current implementation of ArpON
>>> separately.
>>> 
>>> olsrd demon never manages data traffic and sent packets are always
>>> broadcast/multicast, so ARP protocol is not involved
>>> 
>>> what is the benefit of running ArpON as a olsrd plugin ? Why it has to
>>> interact with the routing protocol ?
>>> 
>>> thanks
>>> 
>>> Saverio
>> 
>> 
>> --
>> Olsr-dev mailing list
>> (spam-protected)
>> https://lists.olsr.org/mailman/listinfo/olsr-dev
>>