Category Archives: Uncategorized

Is the future of WebRTC in IoT?

If conference titles are anything to go by IoT and WebRTC are both big things at the moment. If you look at Hackathon output, WebRTC and IoT things seem practically coincident (disclaimer: at my day job, we did a drone WebRTC hack at TadHack London this year). Everyone is talking about WebRTC and IoT in the same sentence, but how relevant is WebRTC to real life IoT applications?

WebRTC is really just a clever collection of on the wire Internet protocols and driver implementations to capture high quality real time media streams and move them between peer devices reliably and securely. It scavenges suitable connectivity by adapting paths to the network environment it finds itself in and does this securely by using mandatory cryptography and consent tokens. WebRTC is also a standardised Javascript API (hence the Web bit), but the wire implementation and web browser interface are separable to the extent that it is possible to fully use WebRTC as a transport with a browser at one end only, or even with no browsers involved at all.

The media part of WebRTC sits behind an API called PeerConnection which can be hooked to local media sources by a browser or application to send things like audio, camera output, screen captures etc to any peer device it can get packets to. Without going into too much boring detail, WebRTC includes lots of smarts to get those media streams as reliably as is currently possible between clients, through Internet roadblocks like NAT, firewalls, limited bandwidth connections etc.

On top of PeerConnection, WebRTC also has DataChannels which can be used to move blobs of data for things like text, binary files etc around using the same “go anywhere connections.

Security is a big part of WebRTC, and as long as the control channel you are using is secure then it is very hard indeed for a third party to snoop either peer to peer media or data.

This thing about control channel is important, WebRTC doesn’t in any way help with how the two peers find each other in the first place, or indeed how they communicate all of the information which allows them to subsequently setup a peerConnection. To do this, a signalling protocol is needed and that is something that WebRTC stays out of. The underlying application architecture has to provide this signalling between the two ends in order to bootstrap the WebRTC connection. Typically this is done by having both parties to a WebRTC session contact a third party server in the first instance to log their connection request and pass parameters between each other via this trusted third party. The signalling protocol and associated servers also typically handle all of the authentication and pass tokens that allow the communicating devices to know they are talking to the right party. Providing a secure signalling protocol is therefore something that is key to the operation of WebRTC. If it isn’t there, PeerConnections can’t be established, and if it is insecure then any security or confidentiality of the subsequent WebRTC conversations is an illusion.

The “NAT busting” features of WebRTC, combined with it’s inherent security may make it a suitable technology for communication between legions of small IoT devices all on diverse scavenged connectivity. WebRTC is clever, if two devices are on the same connectivity it will find the best connection that links them, for example using the local LAN to pass data rather than communicating all the way back to a central server. If devices are behind simple NAT routers then its protocols can find ways of engineering two way direct communication through these and, if all else fails, as a last resort will fall back to centralised relay servers. The latter are expensive to provide at scale and therefore unattractive to application providers but a lot better than no communication in circumstances where this is the only way things will work!

It is however a great big sledgehammer and, because of all the code to do network probing, it’s behaviour is dynamic and adaptive which means it works very well lots of the time, but is really quite hard to debug when it doesn’t. If all you need is a bit of command and control, or a transfer mechanism for any amount of non media data to central servers then it is highly unlikely that WebRTC will add any value to your IoT communication architecture.

Remember that signalling protocol? In order to use WebRTC you need to have established a secure, asynchronous communication mechanism between all of your clients and central servers anyway. In 2015 this is likely to be WebSockets, or perhaps a raw TCP connection or UDP transaction protocol. If your application needs you to pass any amount of data client/server, or small amounts of non-timely client/client data then you don’t actually need the overhead of WebRTC, just send your peer data directly via the signalling server.

The only time that WebRTC starts to earn it lunch is when you need to pass non-trivial amounts of data peer to peer without hitting central servers, or need to pass bandwidth hungry real time media streams across the Internet. IoT devices with video cameras will certainly have a use for WebRTC, but would you incorporate DataChannel just to do command and control when you already need to have a signalling protocol in place in order to bootstrap it? As a party piece at a Hackathon maybe but in real life perhaps not.

Published by:

Kwiizi

Uncategorized
Kwiizi box

Kwiizi box being deployed in Cameroon Schools

I was really interested to come across the Kwiizi project last week. It crosses two of my biggest interests: real time electronic collaboration and education in Africa. Using cheap Raspberry Pi computers and wireless network connectivity, it brings large repositories of electronic information and real time collaboration into High Schools.

Even more awesome is that it is a homegrown solution being developed in Cameroon for Africa! They have lots to do, but I suspect this alone gives them a much better chance of succeeding than something parachuted in from outside the continent, however well meaning.

Their source code is on Github, and they have an Indiegogo page where they are trying to raise just $5000 to deploy into more schools in Cameroon, definitely something worth supporting. It will be fascinating to see how they develop.

 

 

Published by:

IPSecuritas on OS X Yosemite

Uncategorized

I’ve just upgraded my Mac Book to Yosemite and the only casualty I’ve found so far is the IPSecuritas IPSec VPN wrapper application.

Whilst it seems to work and establishes all of the SAs sucessfully via ISAKMP, it doesn’t then move any protected traffic.

Googling around, it seems a few folks have hit this and the perceived wisdom seems to be to turn off NAT traversal on the tunnel options to get things working in Yosemite. I was sceptical about this as having to disable NAT-T is too broken. In any case, even on my tame home network, which shouldn’t need NAT-T it just allowed me to pass traffic for one of the three tunnels at random.

Configuring any new IPSec environment always seems to consume half a day, and I like IPSecuritas so it was worth a bit of effort to get it working. I found this in system.log:

Nov  5 11:49:04 xxxxxxxx com.apple.kextd[22]: ERROR: invalid signature for com.lobotomo.IPSecuritasFilter, will not load

Googling around Yosemite has become more picky about kernel extensions that it will load and now rejects unsigned files (probably quite a good idea, but not good for IPSecuritas). You can revert to the previous behaviour by:

sudo nvram boot-args="kext-dev-mode=1"

And then reboot.

Having done this, I can confirm that IPSecuritas now works fine on Yosemite without having to disable NAT-T!

There is a health warning here though. Apple presumably introduced code signing of kernel plugins for good reasons and, whilst many software vendors who ship older unsigned plugins are referencing the above as a short term fix (google the above command line!), you do this at your own risk. To back it out:

sudo nvram boot-args="kext-dev-mode=0"
Published by: