Hey all,
I was speaking to someone today who asked technical questions on email related to Ziti (from the perspective of NetFoundry’s implementation of OpenZiti). I thought I would share my responses (and ask if any can be improved. Normal text is the question, italics is my response.
-
While Netfoundry offers it’s own NaaS layer I understand that “private/on-premise” installations are possible as well (i.e. without crossing Netfoundry’s boundaries)? Could a paying customer purchase Netfoundry support for such “private” installations, or support is provided only for the NaaS offering? Best to think of this in 3 dimensions:
Data plane – Today this can be deployed anywhere incl. “private/on-premise” installations using any of the SDKs, tunnelers or Edge Router.
Control plane – Today this can be deployed into any AWS DC. In future we could make others possible.
Mngt & Orchestration Platform – Today this is run in AWS (unless you use purely open source OpenZiti which you are hosting yourself). We have internally discussed the ability to have a deploy anywhere and still consume as SaaS but does not exist yet. -
I understand that end to end encryption can be enforced regardless of whether a zitified app is used or a tunnel method, right? Please comment if otherwise. Yes, see image 1 below. E2E encryption is done from the edge whether its SDKs (inside app), tunnelers (inside host) or Edge Router (inside network).
-
I understand that the zitified-JDBC demo is available for MySQL as well, through the com.mysql.jdbc.Driver driver, right? I understand we today support Postgress and MySQL. I know someone is also working with our Node.JS SDK to do Mongo DB. If you have other requests we can talk with the team or request directly on discourse – https://openziti.discourse.group/
-
Also I understand that all changes are made to the client JDBC driver and not to the DB server itself, correct? Correct, no code needs to be changed in DB server. Only deploy a tunnel on the host or ER in the same network. On the other side (e.g, weblogic, jboss or user client) they just use ZDBC.
-
On a more general note, I understand that the innovation is that incoming open ports are eliminated and all communication happens via outgoing ports, connecting to the NetFoundry Control Plane/NaaS via X509 etc. One question - a prospect customer might ask - is if you feel that any open ports on the Netfoundry control plane becomes a point for an attack. How this is mitigated? All connectivity is using m-TLS in both control and data plane. The edge is outbound only so dark, the fabric must have inbound ports. BUT due to m-TLS it only ‘listens’ for authenticated and authorised connections. i.e., a malicious actor guesses the IP address of fabric control or data plane and shots a packet to try and connect, the packet gets blackholed. The only real attack viable is DDoS BUT we built the dataplane as a mesh so it will avoid any hops which have higher latency (which it would under DDoS) and we are actively developing control plane to be distributed too. Further, fabric is best being hosted in hyperscale cloud where they have strong DDoS defence.
-
I have seen demos with FTP, S3, HTTP etc services. Do you plan for a demo or product that zitifies SSH as well? Would this be possible, or someone could use the tunnel approach and have the same benefits already for that? Yes, we have done it already
Zitifying SSH | Ziti.Dev You could also use a tunnel, zSSH just makes it ‘clientless’ -
With regards to the Postgresql ZDBC demo - one question that might be raised during a Percona Live presentation is whether connecting via “ZDBC” vs JDBC results in any performance overhead or latency. Do you have some insights on that? Encryption tunnels always add overhead but we can mitigate in a few ways. (a) you can turn off E2EE and just use link encryption. (b) smart routing of our fabric means we can potentially reduce latency but at least avoid ‘internet weather’ and variation. (c) we have a capability in beta, will be prod likely later this year which adds a high performance dataplane to ziti by proxying to UDP with out of band error correction to be high throughput while lossless – ziti/transwarp_b1.md at v0.19.8 · openziti/ziti · GitHub. This is particularly useful for long haul or lossy underlying internet.
-
How transparent was zitifying an application or library - e.g.DBC. is this something that should need ongoing maintenance? I don’t know what DBC is
BUT zitfying most things is low overhead as it acts as a wrapper or shim. TBH, if we are going to copy their opensource code and zitify it then most of the burden is on us to maintain it. Ideally we will do zitification and pr back to them to that they just keep our work as a dependency which allows Ziti to be turned on by users as desired.
