What does Fenrir bring to you as a developer?

One library to rule them all

Fenrir alone includes the functionality of:

• TCP
• UDP
• TLS
• DTLS
• OAuth
• Multicast

Plus a lot of other things that these are too limited to implement. There is no retrocompatibility, but the tradeoff in features alone is worth it.

Data transport

Here Fenrir shines like no other. TCP-like? we have it. UDP-like? sure.
But that’s boring. Let have all possible combinations of transports:

	Stream+ Reliable	Stream+ Unreliable	Datagram+ Reliable	Datagram+ Unreliable
Ordered	TCP
Unordered				UDP*

* By”Datagram” we still mean that a single message can span multiple packets, unlike UDP that is limited to the size of a single packet

Everything always encrypted and authenticated of course.
The combination of “Stream+Unreliable+Unordered” will probably make little sense, but it’s easy to implement, so we don’t see a reason to limit your choice.
We have also plans for multicast, and yes, we plan to make all the above transport modes available on multicast, too.

Multihoming is included in every connection, for both user and service, so you can have roaming endpoints and use multiple connections at the same time without problems.

NAT traversal via TURN-like protocol is always included, since all clients and services are required to contact the authentication server, we have an obvious central point where to implement it. Your clients will be able to use this features completely transparently.

But is Fenrir Webscale?

Let’s be honest, the web has scalability issues. That Fenrir resolves, of course.

In legacy applications whenever you connect to a fqdn (like:example.com) your browser or application will resolve the address and get a single IP address. Then you have to do the same for authentication. To scale this you need proxies and redirects.

With Fenrir the dns(sec) will give you a list of all interfaces of the multiple authentication servers that are authorized for that domain. We have both traffic weighting and failover at this very first level, before the initial connection.
After that, the authentication server will point you directly to the server you want. Geolocation, traffic weighting and more can be done if the services give the necessary statistics to the authentication server.

We can make you scale beyond current architectures by avoiding proxies!

Authentication

The current standard for authentication is (unfortunately) OAuth. As a developer you will have to manage different libraries for different providers, handle security tokens securely, implement and track authentication redirects and follow best practices that are not enforced everywhere.
2FA? Add it manually and differently on every service.

In Fenrir, you don’t have to. You get a connection: that connection is either anonymous or comes with the user’s details. DONE.
2FA? Both the service and the client can enforce it. Nothing to do on the application.

Aside from the mess that OAuth pretends hard not to be, and the extra development effort to implement it, your OAuth provider is always able to impersonate its clients, which can not happen in Fenrir.

A new standard, WebAuthN, is slowly getting more usage. Key-based, but without device or login tracking, synchronizations or warnings if your device is hacked and your keys stolen (yes, we can instantly warn you in that case too).

Fenrir’s Theory was finished in 2016. It’s still easily a decade ahead of anything else.

Multi-Device

Fenrir’s feature on multi device are not only thought for the client, but for the services, too.

Need to do different things on different devices? Need to be safe about it?

Fenrir provides you with multiple public/private keys:

• One to identify the user
• One per application
• One per device

This way you can design your applications for the maximum end-to-end safety at every level you wish.

More questions?

Feel free to ask us anything!

---