Tyr

Following the earlier post I will now explain a bit this new small project of mine, Tyr, which should be completed fairly soon (at least in its first version)

Tyr is basically a transparent, opportunistic error-correcting tunnel.

The name, Tyr

First of all, why the name? I am obviously continuing the theme of the Northern Gods with this, and if you know a bit about their legends, Tyr is god whose hand was bitten off by Fenrir.

As the legend goes, the Gods wanted to bound Fenrir and they tried with multiple chains, which Fenrir broke, and then tried with a magical ribbon. Fenrir sensed the deceit and agreed to the test of strength only with a god’s hand in his mouth as a pledge of good faith.
Of course there was no such good faith and Tyr lost his hand.

As you will understand soon, to me Tyr is a good step in the wrong direction. It might conflicts a bit with the Fenrir project by introducing features that would be otherwise unique to Fenrir, but I think it is still needed, and it is not yet Fenrir’s time.

What is Tyr

Tyr is a transparent error correcting tunnel designed to work with any protocol, implementing both standard error correction and forward error correction through libRaptorQ. It is a mighty project that should help a lot wireless, lossy connections.

It is a good step in current protocol handling because we will override old error correcting codes with newer, more efficient ones. We will introduce forward error correction and we will try to do it all in an adaptive way, while remaining compatible with today protocols.

It is also a step in the wrong direction. Basically we are continuing to patch the current internet instead of trying to design things correctly from the beginning.

A good, secure design is Fenrir’s goal. Tyr’s goal will be to have the latest error correction on any current protocol, now.

Fenrir’s development is going a bit slow (mainly because I am not paid for this) but Tyr is a much simpler protocol, so it should be available sooner.

Tyr details

Tyr’s design is to use the tun driver and raw sockets to read all incoming and outgoing packets.
At that point when any connection is made, a parallel UDP connection will be created between the two endpoints.
Once that connection has been set up, the main connection will be hijacked and tunneled with added error correction and recovery.

This does not seem a particularly new idea, and if we were to design this as a normal VPN all nodes would need to support the Tyr protocol.

The new idea is instead to track all connections and automatically try to create a tunnel between any two enpoints. While there is no tunnel we can simply forward the packets as they are, without any change. But if we have established the tunnel, the data will automatically be error protected.

Tyr will NOT handle any kind of security except from being designed against amplification attacks. The reasons for this coiche are multiple:

• Encryption requires a decision on trust management. Certificates, web of trust or something else entirely. The setup would be cumbersome and we would need to provide signed certificates to any client, which is a bit too much.
• Fenrir focus is security, by adding security to Tyr I would end up designing Fenrir again.
• Tyr should be ready much sooner than Fenrir
• Tyr is designed with compatibility in mind. It is an opportunistic tunnel. This means that the first packets are forwarded in cleartext, and error correcting is done later. If we try to encrypt your data, we can not guarantee the safety in three cases:
  • one of the endpoints does not use Tyr
  • the first packets are not protected
  • downgrade attacks (deny Tyr connections) will leave everything cleartext

Expected results

Endpoints which do not support the Tyr protocols will not receive additional error correction, but should not incur into measurable added latency, as the packets are merely forwarded.

Connections that are error protected instead will receive a minimum header for error detection and correction in the packet, and might receive an additional FEC header ro recover lost packets.

The amount of error correction will be adaptive with the rate of errors and packets lost.

In a lossy connection we might even see higher bandwidth usage, since TCP suffers greatly from delay, but even worse from packet loss.

CPU usage however should be higher, which means that we will have to thread a fine line between increasing the error correction range and consuming power.

Current state

Currently there are just over 3.5k lines of code, the tunnel and connection tracking is in place. There is still a lot to do. Optimizations are in place for IPV4, TCP and UDP to strip their checksums and regain a bit of space (checksums do not make sense if we are doing that by our own anyway).

The RaptorQ library is now really stable, so that is a good coiche for the FEC algorithm. The RAW API we are using is also much easier to use than the RFC.

The general Error correcting algorithm has not been identified yet, but it should be something more robust than the usual CRC. For now we are using a non-cryptographic hash as an error-detection. It should be much better at detecting errors, ut without the ability to correct any. But packets with wrong CRC are usually just discarded, so it really does not make much of a difference.

More testing will be needed to understand how to tune the packet recovery for TCP connections. Any connection which has an ACK mecanism will ask the old packet again after a timeout. But we might recover the packet after the timeout is reached and the old packet is resent twice. While this should not impact TCP, other protocols should be checked, and we might want to drop the recovery of old packets ater a certain timeout, to free memory.

Challenges

We will have to do a bit of firewall punching due to NAT, since we will not require additional servers for STUN-like protocols.

The big challenge of this project will be to adapt correctly to the amount of error in the channel, which can change fairly quickly. Not to mention adapting things so that we do not draw too much power from the device.

Timeline

That is a good question. I hope to have a demo in the shortest time possible. Then maybe a kickstarter or indiegogo campaign will start to help me focus on this. But unless I manage to get enough money (hint, hint), it’s done when it’s done.

-Luker