UDP packet overlay proxying

Ziti Overlay
1

Hello, I’m giving the NetFoundry service a spin to better understand the SaaS offering, as well as OpenZiti capabilities.

For the advanced service creation in NetFoundry, protocols supported are TCP, UDP and there is an option to “End to End Encryption: Encrypt this service”. This box can be checked for the UDP protocol as well, either as a UDP only service, or in protocol combination as a TCP/UDP service. Does this imply the UDP packets are being tunneled through TCP over the fabric from endpoint to endpoint when this option is selected? Just want to confirm that this setting doesn’t get ignored for UDP leaving UDP unencrypted through the underlay.

Are there any other technical caveats worth mentioning regarding UDP proxying through the OpenZiti overlay? Perhaps some limitation based on TCP tunnel encapsulation when the “Encrypt this service” option is selected?

Also, while searching previous threads for UDP info, I saw mention of a possible upcoming feature of fabric dataplane throughput optimization via UDP transmission with out of band error correction. Assuming dataplane routing through the fabric is still currently TCP, how much of a performance improvement might an approach like this make? Is this feature still in the roadmap?

Thank you!

2
  • Does this imply the UDP packets are being tunneled through TCP: Yes, that is exactly how it is done.
  • Leaving UDP unencrypted through the underlay: Nothing is ever unencrypted. OpenZiti implements m-TLS between every hop in the overlay (red lines in the image below) - i.e., minimum 2 m-TLS connections with edge<>fabric<>edge, if you have more routers as part of the smart routing mesh then many more options too. E2E encryption (yellow line in the image below), from edge to edge, is on-by-default regardless of what you are sending through the tunnel.
  • Any other technical caveats: As you recognise, its UDP over TCP might cause performance degradations vs pure UDP fire and forget if the application prefers this method (e.g., real-time and does not care if packets are lost. We have UDP data plane on the roadmap.
  • Is this feature still in the roadmap: Yes, to be implemented after we have UDP data plane. We did some testing of Transwarp/Dilithium, I believe, without using OpenZiti (due to UDP over TCP issue you mentioned), and it delivered the improvements below (note, the 1st is on a high-performance internet connection while the second while lower latency included sections on more lossy residential internet):
    • AWS US West to AWS US East (70ms) with SCP ~33% improvement (25 vs 15.8-17.1 MB/s)
    • Atlanta to AWS US East (20ms) with SCP ~68-88% improvement (44 vs 5.4-14 MB/s)

image
image2104×1174 405 KB

2 Likes
3

Hello and thank you for the answers Philip! Now I understand the finer point that adding e2e service encryption is actually a second layer of encryption (ChaCha20-Poly1305) in addition to the non-optional base mTLS hop-to-hop encryption.

I just found and watched this video too which is interesting: OpenZiti Superpower - e2e Encryption - YouTube

Much appreciated,
John