Is the client side of Single Packet Authorization in scope for Ockam

[taqtiqa-mark]

The server side I would expect is out of scope, and would remain with the fwknop project.

However, I believe it would be useful, for clients using Ockam, to conveniently send a SPA 'knock' before initiating a connection.

Appreciate any hints or tips if there is a better way to do this than shelling out or kludging some rust api for the fwkop library.

[taqtiqa-mark]

IIUC, the following:

For example, with one simple command an app in your cloud can create an encrypted portal to a micro-service in another cloud. The service doesn’t need to be exposed to the Internet. You don’t have to change anything about the networks or firewalls.

is true only if your micro-service is not running on a server with a firewall in which the...

... method of authorization is based around a default-drop packet filter

Hence the question about the scope of Okam.

[mrinalwadhwa]

@taqtiqa-mark sorry for not responding to this sooner, I missed your post.

We currently don't do any port knocking in Ockam. It could be easily added to a transport, but we haven't encountered a need for it. To traverse NATs and firewalls - we instead rely outgoing TCP connections, originating from inside a network, to a relay or a rendezvous endpoint. This means that a firewall should allow outgoing connections / egress.

More on how that works here: https://docs.ockam.io/how-does-ockam-work

[taqtiqa-mark]

sorry for not responding to this sooner,

No worries.

We currently don't do any port knocking

😱 the SPA fans are sensitive about that framing.... SPA is absolutely not port knocking 😄

To traverse NATs and firewalls - we instead rely outgoing TCP connections

Not sure I understand... that outgoing has to at some point be an incoming connection - it is at this point you're traversing a firewall again. Or do you have two outgoing connections that are paired in some open firewall-free environment.

Looking at https://docs.ockam.io/how-does-ockam-work.
It wasn't clear to me that the Okam orchestrator must be in the open. If so that is a non-starter for certain environments. This raises an different question: Are there plans to allow the OO to run behind a firewall.

Am I correct in understanding that the OO cannot be behind drop everything firewall?

but we haven't encountered a need for it

Yup, I always found setting up the client side a real pain. That was over a decade ago but matters don't appear to have changed too much. Hence the question.

This is also one of the chicken-or-egg first situations: Servers won't be configured in this way until it is trivial for clients to be setup and connect.

It could be easily added to a transport,

Thanks. This is here as a note to future self to look into that.

My take away is: This might be possible, but there are no plans to support this usage pattern/scenario. Correct?