[Commotion-dev] Quick Update

[L. Aaron Kaplan]

Michael, 

your mail inspired me to think more about this topic.

On Apr 7, 2011, at 10:18 AM, Michael Rogers wrote:

> Hi all,
> 
> On 06/04/11 22:38, L. Aaron Kaplan wrote:
>> It would be *great* if the commotion project could make WPA2 work in
>> ad-hoc but even if it can not, we still have a) a way to secure
>> routing messages (i.e. protect the routing layer against malicious
>> insiders) by signing the routing messages [1] or b) we can use Tor ,
>> OpenVPN, IPSec,...or any other end-to-end encryption scheme to
>> protect the data layer.
> [snip]
>> [1] Take a look at the SIDR working group at the IETF:
>> https://datatracker.ietf.org/wg/sidr/charter/ for some inspirations 
>> (though, I don't believe in the central PKI for signing routing
>> messages)
> 
> I have to say I'm skeptical about whether it's possible to secure the
> routing layer against malicious insiders in a mesh scenario.


> 
> The fundamental problem is that in the absence of a trusted identity
> infrastructure, such as a centralised PKI, there's nothing to stop an
> attacker from using an arbitrary number of identities (at layer 2, layer
> 3, or both), which makes it very hard to do things like rate-limiting,
> fault detection, etc. And I agree that a centralised PKI isn't suitable
> for a mesh scenario.

Yes, you have two choices:
a) make it distributed. In this case you need 3*N+1 nodes to detect N "byzantine-liars"
(see http://en.wikipedia.org/wiki/Byzantine_fault_tolerance)
In other words: yes, if it is distributed, you can be corrupted by on third of the 
nodes. Or another way to say it: voting helps in such cases ;-)

b) centralized approach (PKI etc): might just work if you have a situation in which 
a mesh is deployed by a single trusted party (like a single ISP). And if you can sign
every client certificate then it is surely a well known path. I just don't like it
because it sort of contradicts the distributed mesh approach :)
Agreed.

> 
> In the past I've run some simulations of DoS attacks against ad hoc
> routing protocols by malicious insiders. I didn't look at OLSR, but the
> results for on-demand protocols like AODV are extremely bad: a single
> attacker can disable a network of a thousand nodes just by flooding the
> network with route requests. Clearly that specific attack wouldn't apply
> to OLSR, but I'm pretty confident that a malicious insider who can
> change identities at will can mess with the protocol in some way.
Right now, if you don't protect the routing plane, even in OLSR you can 
screw up the whole routing in the network pretty badly. There is an
initial secure plugin in OLSR which signs routing messages. However, I 
am sure it could use some maintainer ;-)

> 
> While end-to-end encryption at a higher layer is certainly a good idea,
> it won't protect against attacks that prevent data from getting through.

Well, DOSing communication is generally pretty easy on Wi-Fi: just jam 
it. Take a microwave oven, connect it to a strong reflector (Sat dish?) and 
direct it at the mesh crowd ;-) Zap!
Very low tech. The obvious counter strategy is to simply be very close together.
Then the jammers signal is weaker than yours. A jammer always has to invest lots of 
energy to jam a large area (signal strength_at_receiver = initial_strength * 1/distance^2)

> So I guess there are two possible approaches to this problem.
> 
> The first approach would be to try to fix the problem, which could mean
> spending years developing a routing protocol that's robust to malicious
> insiders in the absence of a trusted identity infrastructure. (Maybe a
We don't even have that yet with BGP - IMHO the most mature routing protocol.

> solution already exists - but I spent a while researching this topic and
> never found one.)
> 
> The second approach would be to note that there may be a vulnerability
> in the design and carry on.
> 
Well, you can improve minor things:
a) use all encryption layers available (Wi-Fi), secure plugin, VPN for data
b) re-work the secure plugin to make it tolerant to byzantine liars (malicious 
insiders). 
c) give people tools to check if something wrong happened with the routing layer
d) create an IDS (intrusion detection system) for the routing layer and trigger automatic alarms 
e) create a filter system similar to the filters in BGP. You might want to just simply 
 block the announcements of a specific node.

> Personally I think the second approach is better, because a network that
> doesn't resist this particular class of attacks is still way more
> valuable than a pile of research papers and no network. But maybe I'm

agreed!
> over-compensating for spending too much time on research in the last few
> years and not enough time on implementation. :-)

;-)

Thanks for your inspiring mail!
a.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 243 bytes
Desc: This is a digitally signed message part
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20110407/d6c792ef/attachment.sig>