Looks good, Matt, and thanks for open source and SaaS flexibility. Can you add to or correct the comparisons to OpenZiti and Wireguard to help us frame the sweet spot for Ockam?
OpenZiti
In common: mTLS w/ built in PKI mgmt; attribute based access control; SDKs to embed in apps.
Different: OpenZiti includes the network overlay as well. Ockam add-ons may target other use cases?
Wireguard
In common: E2E encryption; hosted SaaS avail
Different: UDP hole punching; network-level segmentation; no mTLS; no app embed
I led the design of Ockam. I am somewhat familiar with Wiregaurd and not at all familiar with OpenZiti. All tools that are helping us build application that have much much smaller vulnerability surfaces are awesome!!
Some things that you can do with Ockam:
1. Create Noise based secure channels all sorts of multi-hop, multi-protocol, network topologies - TCP <> TCP, or TCP <> TCP <> TCP, or UDP <> Kafka <> TCP, or BlueTooth <> TCP <> TCP etc.
2. Move end-to-end encrypted data through Kafka, RabbitMQ, and other messaging and streaming systems.
3. Run on small embedded devices (Rust no_std) or run on large servers.
- Examples are focused around TCP inlet to TCP outlet. Any way you can add more complicated examples? I take I can have a TCP inlet and a Worker that would would receive TCP stream wrapped into Routed, then I can unwrap it and work with it kinda as if it was “normal” TCP.
I’m curious about second one because while connecting some clients to legacy is fun, it’s more fun when services connected directly. For example, I want some kind of RPC or database without “external” TCP connection from node to database.
That's close to what I was thinking. I guess a message here could be just a bag of bytes, and then you can plug listener side into `tower` stack.
Can't exactly wrap my head around access control here. In this example, let's assume I'm using a proper policy and not `TrustEveryonePolicy`. What's stopping someone from using this route: route![(TCP, "localhost:3000"), (TCP, "localhost:4000"), "echoer"]; in this example?
I'm just working on something that could use this, but right now, we use wireguard + nftables + convoluted routing policies + TLS. I would go far to not use TLS and manage X.509 infrastructure and hopefully avoid double encryption.
would you like to schedule some time with us to dig into this further. This sounds really interesting and pretty close to things we've seen others do before.
Good question. It's a nested reference. I named the company Ockam as a tribute to a company that a mentor of mine built and ran in the 70's - 2000's. He named his company after Occam's Razor.
If they solved only discovery, handshake and hole-punching problems and made relay optional, it would be more useful. Also, for relay, if they provided store-and-forward and also scatter/gather topologies, it would be more useful.
Key/Route Discovery, Credential Issuance/Presentation, Secure Channel Handshakes and Message Routing that is decoupled from transport protocols have been our main focus.
We chose to build the more reliable e2ee strategy first - Relays.
UDP hole puncturing is in development right now. However there is extensive research that proves it in only successful in making connections in 60 to 80% of real world networks. This is why Signal does relays for example. Relays provide a highly reliable strategy. So we knew we'll want to support both and give devs and option to choose what is right for their application. Or failover from one to the other.
Store and forward as a first class feature is in development.
Scatter/Gather is a much harder problem since it involves group key agreement and challenges that come with doing that safely. This is in our long term roadmap, but we've not done any development for this yet.
