3 ms·

No ports are required to be opened at the edge (i.e., source and destination). The OpenZiti edge makes outbound connections using the strong identity into the f

by PLG88 4y ago

No ports are required to be opened at the edge (i.e., source and destination). The OpenZiti edge makes outbound connections using the strong identity into the fabric mesh network. Therefore its only the fabric dataplane which needs inbound ports but it does not listen to any connections other than those of edge components which are authenticated and authorised. Vs standard MQTT there are several advantages incl. (not limited): - mTLS connections rather than just TLS - least privilege and microsegmentation - outbound only (authenticate and authorise before connect) meaning we can close or deny inbound connections at source and destination - private DNS with unique naming (e.g., instead of xxx.xxx.xx.xx to antoher IP, you could say MQTT client to MQTT server - smart routing on the overlay to reduce latency, increase availability and in general increase visibilty without owning the underlay network

injinj 4y ago
This implies that Ziti layers the stream endpoints on top of a packet switched network, which could mean authentication of each packet and maintaining stream reliability in a different way than TCP does. Is that correct? edit, this is what I'm looking for: https://github.com/openziti/fabric/blob/main/docs/p12_smart_routing.md https://github.com/openziti/fabric/blob/main/docs/p12_smart_...
- dovholuknf 4y ago
  Yes. All connections are synthesized over the same connection to the overlay, making all your traffic look like "port 443" (or whatever port you use for the data plane). Inferring traffic from port number is thus made even harder. OpenZiti is using TCP to deliver packets to the routers, so TCP is still used there for stream reliability. Once delivered to the overlay fabric, the fabric is responsible for delivering the payloads as quickly as possible to the endpoint reliably. It uses TCP currently but we've worked on using other protocols like UDP.
  - injinj 4y ago
    Ok, thanks. The Ziti mesh optimizes for latency. Does it move existing streams around the fabric mesh when it finds a better route or only new streams? Are there plans for multicast?
    - dovholuknf 4y ago
      Yes. If it needs to reroute, it will do so as long as the "terminating" site doesn't go offline. That's the one maintaining the "final" TCP stream so that one can't be rerouted. Multicast support has been discussed, but it's not at the top of the pile of features that are getting worked at this time that I know of. I'm sort of on the other end, closer to the SDKs than the fabric, but I am pretty sure it's not in the immediate priority list as I recall.

by PLG88 4y ago

injinj 4y ago

This implies that Ziti layers the stream endpoints on top of a packet switched network, which could mean authentication of each packet and maintaining stream reliability in a different way than TCP does. Is that correct? edit, this is what I'm looking for: https://github.com/openziti/fabric/blob/main/docs/p12_smart_routing.md https://github.com/openziti/fabric/blob/main/docs/p12_smart_...

dovholuknf 4y ago
Yes. All connections are synthesized over the same connection to the overlay, making all your traffic look like "port 443" (or whatever port you use for the data plane). Inferring traffic from port number is thus made even harder. OpenZiti is using TCP to deliver packets to the routers, so TCP is still used there for stream reliability. Once delivered to the overlay fabric, the fabric is responsible for delivering the payloads as quickly as possible to the endpoint reliably. It uses TCP currently but we've worked on using other protocols like UDP.
- injinj 4y ago
  Ok, thanks. The Ziti mesh optimizes for latency. Does it move existing streams around the fabric mesh when it finds a better route or only new streams? Are there plans for multicast?
  - dovholuknf 4y ago
    Yes. If it needs to reroute, it will do so as long as the "terminating" site doesn't go offline. That's the one maintaining the "final" TCP stream so that one can't be rerouted. Multicast support has been discussed, but it's not at the top of the pile of features that are getting worked at this time that I know of. I'm sort of on the other end, closer to the SDKs than the fabric, but I am pretty sure it's not in the immediate priority list as I recall.