[Commotion-dev] Quick Update

[Michael Rogers]

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.

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.

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.
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
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.

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
over-compensating for spending too much time on research in the last few
years and not enough time on implementation. :-)

Cheers,
Michael