[Commotion-discuss] Ad Hoc WiFi MESH networks

Wed Mar 22 21:14:59 UTC 2017

Hi Sritam,

I'll try and answer your questions as best I'm able.

So, one question is why we didn't go with 802.11i or AuthSAE: 

* 802.11i: Now, to clarify, 802.11i actually includes WPA2-PSK, and
that is what we used, albeit the version for ad-hoc networks which is
also called IBSS-RSN. Now if we're talking about 802.11i with
802.1X/EAP, collectively also known as WPA-Enterprise, the reason is
simple. As I mentioned in the previous email, one of the design goals
for Commotion was not to _require_ the use of any centralized service.
All nodes in the network would be setup in a relatively similar fashion
and that process would be as simple as possible. Using 802.1X/EAP would
essentially mean setting up a FreeRADIUS server for every Commotion
network. This introduces a number of problems. One is that now there is
an entirely new and more complicated kind of node you need to
configure, which immediately doubles the setup documentation and makes
the process much more complicated, as well as making the whole network
centralized with a single point of failure. Two, FreeRADIUS is a
relatively complicated piece of software to setup and configure, also
complicating the setup process. Third, there's a much more fundamental
problem in that the Commotion network is an infrastructure network.
Most nodes are only communicating via the Commotion network itself.
That means that they're mostly communicating with the RADIUS server via
the exact same network that they need to authenticate against the
RADIUS server in order to connect to, creating a chicken and egg
problem. All of these properties made it unsuitable for Commotion's
goal of making it easy for communities to set up small infrastructure
networks that were decentralized and not dependent on an internet
connection.

* AuthSAE: The stated primary problem with IBSS-RSN is that it uses the
same shared secret for every node. While this is true, AuthSAE also, to
my knowledge, uses a shared secret that is the same for every node.
Now, it still may be preferable to use AuthSAE over IBSS-RSN. IBSS-RSN, 
much like WPA2-PSK on infrastructure networks, uses separate keys for
each client. However, since these keys are derived from the passphrase
in a relatively simple way, any attacker who observes the
authentication handshake from another client could then decrypt those
frames if they possess the passphrase. If AuthSAE has a more secure
handshake, it could protect against that kind of attack. However, it's
not without downsides. One is that it is not very well documented, so I
can't verify that it actually _is_ more secure in its handshake.
Secondly, it seems barely maintained. We actually talked with Cozybit
(the creators of AuthSAE) when we were assessing security technologies,
and they indicated that they were likely to discontinue it. That was
years ago and it obviously hasn't happened, but it also appears that it
is not very active or widely used. Additionally, as part of the wifi
stack IBSS-RSN is hardware accelerated on most router chipsets and thus
poses a practically negligible overhead compared to most other crypto
when it comes to routers. AuthSAE runs primarily in userspace and uses
its own crypto, so it has more significant overhead.

Basically, even if it wasn't completely secure there were almost no
downsides to enabling IBSS-RSN once we got it to work, but the other
solutions had significant downsides as they stood at the time.

To answer some of your non-security-related questions:

* By default every node provides its own DHCP server. Each node derives
(relatively) unique IPs from a hash of its MAC address, and hands out
addresses in a unique private subnet. This has advantages and
disadvantages, and is not proof against collisions.
* The nodes are capable of either providing an access point or having
an access point provided by a router connected over ethernet. If the
node is providing an access point and has two physical radios, then the
access point can be on a different channel than the backhaul network.
If it only has one radio, then it must be on the same channel, because
that's just how the radios work. The recommended situation for a
permanent network is to give the backhaul exclusive use of the radio
and have a separate access point, but we allow multiple options because
people may have different amounts of available hardware or may be
putting together a small popup or demo network.
* The routing key signs the administrative routing traffic, basically
the traffic that the nodes use to build a map of the network and route
to each other. This is meant to prevent a bad actor node from forcing
all the traffic to be routed through it for eavesdropping purposes.
However it is somewhat unreliable and redundant, and was slated to be
removed even before I embarked on a rewrite.

It's worth noting that this describes how Commotion is now, but not how
I am planning on making it work in the future. If you wish, I can
provide an overview of that, as depending on how quickly I can finish
it and what the scope of your project is I wouldn't want you spending a
lot of time fixing things that become obsolete anyway.

On Fri, 2017-03-17 at 15:09 +0000, Paltasingh, S. wrote:
> Dear Josh,
> 
> Thank you for the detailed explanation. I read the commotion
> construction kit manual completely. 
> I could find the security flaws in the layer 2 (MAC or data link
> layer) communication between routers as follows:
>     1. As the MESH link password is the same across all the links
> between peers in the network, security is vulnerable. 
>        If attacker gets the MESH link password then he can eavesdrop
> messages as well as disrupt the communication between routers.
>      
> This can be solved by having different keys (for data encryption) for
> different links in the MESH network instead of the same shared WPA
> key. 
> This can be done by implementing SAE (simultaneous authentication of
> equals) or 802.1X/EAP security in the router firmware. But I do not
> know 
> how difficult it is and whether it is possible to implement in
> routers or not (as they are resource constrained devices).  
> 
> Is there any reason for NOT implementing better authentication
> mechanisms for commotion router firmware (such as 802.11i).
> I feel there must be some restrictions because of which your team
> implemented shared WPA key mechanism even though better secure
> authentication mechanisms existed, such as 802.11i.
> 
> After completely reading the Commotion Construction Kit, I still have
> the following doubts:
>     1. When 2 commotion routers form the MESH (or a new commotion
> router joins an already existing network) then which commotion router
> assigns the IP address to the newly added nodes. In order words, in
> which commotion router does the DHCP server run ?
> 
>     2. Does the commotion router behave as a router (for the MESH
> network) and access point (for laptops, phones wanting to connect) at
> the same time. If Yes, then does the access point and the router
> operate in the same channel or do they operate on
> different               channels. If NO, then the best solution is to
> connect a conventional router/access point to the commotion router
> through Ethernet. Now the client devices (laptops, phones) can
> connect to this conventional router/AP wirelessly.
> 
>     3. Last time in your reply you mentioned 2 types of keys. First
> is a shared WPA key. Second is a separate (optional) shared key for
> signing management traffic. What does signing management traffic in
> the context of MESH network of routers mean? What purpose does the
> optional second key (which is shared) serve ?
> 
> Please help me in clarifying these doubts as I am trying to
> understand the commotion implementation to the best possible extent
> so as to come up with ideas in order to improvise it.
> 
> Thanks and Regards,
> Sritam Paltasingh.
> ________________________________________
> From: Josh King [jking at chambana.net]
> Sent: 14 March 2017 18:11
> To: Paltasingh, S.; commotion-discuss at lists.chambana.net
> Subject: Re: [Commotion-discuss] Ad Hoc WiFi MESH networks
> 
> Hi Sritam,
> 
> Your understanding is basically correct, the Commotion firmware is
> installed on certain routers
> which then form a mesh network over wifi. Other, non-mesh devices can
> then connect to the network
> via a conventional wireless access point or via ethernet, at which
> point they are able to connect to
> other services and devices that are connected to the network.
> 
> There are innumerable potential security challenges in working with
> multi-hop wireless networks. If
> we're talking about just the challenges in adding new routers to an
> existing network, they can vary
> widely depending on the management model of the network. They include
> but are not limited to:
> 
> * Authenticating a new router to the network. If you want to have a
> network that only allows
> authorized routers to join, then you need a way of making sure that
> only certain routers are
> authorized. This could potentially be accomplished with a PKI, but
> then requires that authentication
> is centralized and also requires managing your own certificate
> authority (complicated). Commotion
> requires by default that every router has a shared WPA key and
> optionally that it has a separate
> shared key for signing management traffic. This has low overhead but
> requires a shared secret
> between every node in the network.
> * Being able to identify bad actor nodes in the network. Right now it
> is not easy to determine that
> a particular router is misbehaving, and to drop them from the
> network. Ideally the authentication
> system would allow for being able to drop routers from the network or
> mitigate their bad behavior
> without rekeying the whole network.
> * Protecting end-to-end network traffic. Traffic in Commotion is
> encrypted over each hop but is not
> encrypted end-to-end. This means a bad actor node could potentially
> eavesdrop on user traffic.
> 
> These problems and others are made more complicated by some pretty
> significant constraints:
> * Commotion at least has a goal of not relying on any centralized
> management platform. Therefore,
> any fundamental security measure must at least be able to operate
> without centralized systems.
> Commotion also must be capable of operating offline without any
> connection to the wider internet.
> * Routers are bad at cryptography. They have extremely limited
> storage and processing power, and
> little entropy. They also have fairly inaccurate clocks.
> * Wifi is vulnerable to interference and jamming, either intentional
> or unintentional. There's
> little that we can do about that.
> * Due to the limited resources on routers, any solution must be
> extremely small (as far as code
> size), efficient, and use as little airtime on the network as
> possible.
> 
> The stuff I'm working on will introduce opportunistic end-to-end
> encryption to much of the network
> at very low overhead, while also pushing as much of the crypto to the
> edges of the network as
> possible. But that's only a partial solution to some of these issues.
> So if you have any thoughts on
> stuff you'd like to work on, I'd be interested to hear it! I hope
> this was helpful.
> 
> On Tue, 2017-03-14 at 13:58 +0000, Paltasingh, S. wrote:
> > Dear Sir,
> > 
> > My master's thesis project is: Secure Commissioning
> > (Forming/Joining) In Ad Hoc WiFi MESH
> > networks.
> > 
> > I read the documentation of commotion and this is what my
> > understanding is:
> > 1. Commotion software platform supports formation of Ad Hoc WiFi
> > MESH network but confined to only
> > routers.
> > 2. In other words Commotion software platform  enables formation of
> > Ad Hoc WiFi MESH network of
> > routers.
> > 3. Laptops (phones, tablets) will behave as legacy WiFi nodes and
> > will connect to one of the
> > commotion routers (in a star topology) which is having MESH
> > connection with other commotion
> > routers. The actual MESH is formed between the routers running the
> > commotion software.
> > 
> > Is my understanding correct as per the documentation provided by
> > commotion wireless project ??
> > 
> > If Yes, then is there any MESH security challenges that needs to be
> > incorporated at the time of
> > joining of a new router (running commotion firmware) to the
> > existing MESH network. I can work on
> > those security challenges and contribute to the commotion community
> > as my master's thesis work is
> > also related to finding solutions to those kind of security
> > challenges.
> > 
> > Looking forward to your valuable comments and suggestions.
> > 
> > Thanks and Regards,
> > Sritam Paltasingh.
> > _______________________________________________
> > Commotion-discuss mailing list
> > Commotion-discuss at lists.chambana.net
> > https://lists.chambana.net/mailman/listinfo/commotion-discuss
> 
> --
> Josh King
> PGP Fingerprint: 8269 ED6F EA3B 7D78 F074 1E99 2FDA 4DA1 69AE 4999
-- 
Josh King
PGP Fingerprint: 8269 ED6F EA3B 7D78 F074 1E99 2FDA 4DA1 69AE 4999