Mesh Security

  This page is monitored by the OLPC team.

Mesh Security Analysis

Introduction

The purpose of the mesh subsystem is to transfer data between mesh points over a partially connected mesh network. This analysis attempts to categorize the threats that would prevent the mesh subsystem from performing this duty.

It is important to keep in mind that mesh networks, due to the lack of underlying infrastructure and the use of a shared medium, are inherently insecure. For instance, there is no possible defense against disruptions of the physical medium with jammers and similar equipment. In the analysis below we focus on the measures that need to be adopted to prevent attacks performed by the xo's themselves, as such attacks would be the easiest to execute.

The mesh subsystem in OLPC does not provide mechanisms to control access to the network nor to ensure confidentiality. Thus this analysis does cover mitigations to common network attacks such as eavesdropping or unauthorized network access. It is assumed that those services will have to be provided by higher network layers.

The threat categorization that follows is based on [1] and [2].

Attacks on Flow of Data Traffic

Resource Depletion

Traffic flooding (overload the medium)

As mentioned in the introduction little can be done against this.

Mitigation: TODO: Can the xo be used to flood the medium and use up all the channel capacity?

Directed traffic flooding (fill up victim's queues)

Mitigation: TODO

Flow Disruption

Node impersonation (MAC address spoofing)

Nothing prevents assigning a different MAC address to the wireless interface. This address will be used until the laptop is rebooted. An attacker can impersonate a victim and prevent her from receiving traffic.

Mitigation: The destination sequence number could be used to detect that there are duplicate MAC addresses within range.

Data tampering by forwarding nodes.

Forwarding nodes could modify data frames so that the frame is considered invalid and dropped at destination.

Mitigation: Forwarding is done at firmware level and users have no access to it. The host cannot modify forwarded traffic.

Nodes behave normally during route discovery but drop data traffic.

Mitigation: Forwarding is done at firmware level and users have no access to it. The host cannot modify forwarded traffic.

Attacks on Flow of Routing Traffic

Modifying the metric in route requests/route replies.

This is perfectly possible using the iwpriv fwt_* interface into the forwarding table.

Mitigation: Disable iwpriv fwt_* commands before release?

Invalidating the route table in other nodes by advertising incorrect paths.

Same as previous.

Refusing to participate in the route discovery process.

Mitigation: A mesh point cannot leech the mesh: in order to send and receive traffic it must also propagate data and route management frames for other nodes.

Generate false route error messages

Route error messages propagate information about invalid routes. False route error messages could cause the deletion of valid routes, which would have to be rediscovered.

Mitigation: Route error messages are generated by the firmware and cannot be forged from the host.

Bibliography

[1] "Techniques for Intrusion-Resistant Ad Hoc Routing Algorithms (TIARA)", Ramanujan R. et al., MILCOM 2000. 21st Century Military Communications Conference Proceedings, 2000

[2] "Intrusion Detection in Wireless Ad-Hoc Networks", Mishra A., Nadkarni K. and Patcha A. IEEE Wireless Communications, February 2004

--Jcardona 15:16, 2 April 2007 (EDT)