added Cosgrid Vednor to zton.ytml

[jaganath10486]

No description provided.

[netlify]

✅ Deploy Preview for zero-trust-network-access ready!

Name	Link
🔨 Latest commit	11b26dc
🔍 Latest deploy log	https://app.netlify.com/sites/zero-trust-network-access/deploys/64ba368af3512f0008926497
😎 Deploy Preview	https://deploy-preview-69--zero-trust-network-access.netlify.app/
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[enclave-marc-barry]

Thanks for the PR @jaganath10486. Could you share an architecture diagram with us so we can sense check you're placed in the correct list

[jaganath10486]

@enclave-marc-barry Thanks for the response, I forwarded your request to our documentation team. I will get back to you with in next 24 hrs, Thanks you :)

[jaganath10486]

Hiii @enclave-marc-barry
Please Find the attached Architecture diagram

[jaganath10486]

@enclave-marc-barry is there any update from your side?

[jaganath10486]

Hii @enclave-marc-barry
May I know the reason why still the COSGrid is not added to the list? Is there any thing you needed from our side apart from Architecture diagram?

[enclave-marc-barry]

Hi @jaganath10486, sorry for the delay in getting back to you. Just want to double check you're in the right architecture group.

Thanks for sharing that architecture diagram. If I understood it correctly, it looks like there are four major components of the Cosgrid solution:

1. MicroZAccess App (for Windows and MacOS)
2. MicroZAccess App Network Gateway (for IaaS resources)
3. MicroZAccess App SD-WAN Gateway (for Linux?)
4. MicroZAccess App Network Gateway (for containers)

In your solution, do the endpoint devices 1 (i.e. Windows and MacOS) have a virtual network interface added by your product to the OS, which then creates direct peer-to-peer tunnels with other endpoint devices, or are tunnels created by and between middle boxes without extending all the way to the endpoint as appears to be the case in 2, 3 and 4?

The architecture looks like a bit of a mix of SDP and ZTON to me, depending on which platform it's deployed to. Unless I'm missing something, from the architecture diagram it appears that the Cosgrid solution creates connectivity between devices and workloads in different locations/subnets via connector appliances / or that all traffic flows via the MicroZAccess TURN Mediator, in which case is the architecture not an IDN?

[jaganath10486]

Thanks for the reply @enclave-marc-barry.
Yes, @enclave-marc-barry. To summarize the key components of MicroZAccess:

1. Management Plane: Orchestrator ( Multi-tenant SaaS)
2. Control Plane: TURN Mediator ( Shared or Customer Dedicated)
3. Data Plane: App (Components Options below)
   i. Endpoint Agent (Windows / macOS /Linux) - User + Device Authenticated
   ii. Server/ IoT Edge Agent (Windows / Linux) - Device Authenticated
   iii. App Connector Mode (Linux) - Device Authenticated
   iv. SD-WAN Agent - Device Authenticated
   v. Container Side Car - Device Authenticated
   The endpoints (Data plane components listed above) create direct peer-to-peer tunnels with others based on Zero trust tunnels based on Device trust and enhanced identities. No tunnels terminated in the middleboxes.
   As you've rightly indicated, our firm understanding of this architecture is primarily ZTON + SDP. In our architecture, East-West traffic works well and without traffic traversing over MicroZAccess TURN Mediator (Relays). Hence it doesn't belong not IDN.
   Hope our discussion leads to more clarity and better understanding.

[enclave-marc-barry]

Still confused about whether you're placing Cosgrid in the correct category.

The diagram below indicates that you have software running on endpoints (Windows and MacOS) and are also deploying connector appliances in front of IaaS, VMs, Containers, Linux and Windows and other endpoints.

Is this not an architecture in which the clients connect to an edge device (albeit using STUN/TURN)?

The diagram appears to show a conventional SDP architecture -- an "appliance at the edge", as I've highlighted on the diagram below, and not peer-to-peer connectivity between endpoint devices.

I may be miss-understanding, does the Network Connector / App Connect / SD-WAN Gateway run on the endpoint Windows / Linux / MacOS operating systems directly and create a virtual network interface on the device, or is it deployed separately in front of the target endpoint?

e.g. 100 Windows + Linux VMs == 1 network connector, or 100 network connectors?

Please feel free to add further clarification, or update the PR to place the listing into the SDP category.