Versions Compared

Old Version 8

changes.mady.by.user Keong Lim

Saved on

compared with

New Version 9

changes.mady.by.user Keong Lim

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Options Excluded

Expectations

  • Ability to secure the intra-ONAP communications, i.e. between ONAP projects, such as SO-to-AAI, UUI-to-MSB, OOF-to-VID, etc.
  • Ability to secure the ONAP-to-external-system communications, i.e. ONAP-to-database-cluster, ONAP-to-NetworkFunctions, ONAP-to-other-ONAP, etc.
  • Ability to scale with the defined ONAP projects (static per ONAP release)
  • Ability to scale with the number of deployed instances of ONAP VMs (dynamic)
  • Ability to scale with the number of deployed instances of ONAP pods (dynamic)
  • Ability to scale with the number of deployed instances of ONAP microservices (dynamic)
  • Ability to scale with the number of external-system connections (configurable)
  • Ability to work with HEAT-based deployment
  • Ability to work with OOM-based deployment
  • Ability to work with other (non-HEAT, non-OOM) deployment
  • Ability to operate with other layers of security
  • Ability to securely upgrade ONAP in-the-field
  • Ability for resilient and fault-tolerant ONAP communications in-the-field
  • Minimal efforts to implement across all ONAP projects
  • Minimal impact on resource usage and performance across ONAP

...

  • ZeroTier One is a service that can run on laptops, desktops, servers, virtual machines, and containers to provide virtual network connectivity through a virtual network port much like a VPN client. It can also act as a network controller and as a federated root server.

  • After the service is installed and started, networks can be joined using their 16-digit network IDs. Each network appears as a virtual "tap" network port on your system that behaves just like an ordinary Ethernet port.

  • ZeroTier protocol is original, though aspects of it are similar to VXLAN and IPSec. It has two conceptually separate but closely coupled layers in the OSI model sense: VL1 and VL2. VL1 is the underlying peer to peer transport layer, the "virtual wire," while VL2 is an emulated Ethernet layer that provides operating systems and apps with a familiar communication medium.
  • VL1 is designed to be zero-configuration. A user can start a new ZeroTier node without having to write configuration files or provide the IP addresses of other nodes. It's also designed to be fast. Any two devices in the world should be able to locate each other and communicate almost instantly.
  • VL1 is organized like DNS. At the base of the network is a collection of always-present root servers whose role is similar to that of DNS root name servers. Roots run the same software as regular endpoints but reside at fast stable locations on the network and are designated as such by a world definition. World definitions come in two forms: the planet and one or more moons

  • There is only one planet. Earth's root servers are operated by ZeroTier, Inc. as a free service

  • A node can "orbit" any number of moons. A moon is just a convenient way to add user-defined root servers to the pool. Users can create moons to reduce dependency on ZeroTier, Inc. infrastructure or to locate root servers closer for better performance. For on-premise SDN use a cluster of root servers can be located inside a building or data center so that ZeroTier can continue to operate normally if Internet connectivity is lost

  • VL2 is a VXLAN-like network virtualization protocol with SDN management features. It implements secure VLAN boundaries, multicast, rules, capability based security, and certificate based access control. VL2 is built atop and carried by VL1

  • ZeroTier is available as a linkable or loadable library called libzt. What makes this different from the more familiar ZeroTier One service is that it comes bundled with its own network stack: lwIP, and it doesn't require special permissions on the system. You can now link ZeroTier into your application and access it over your virtual network as if it were a device all of its own. For simplicity, we've modeled its API after Berkeley Sockets.

  • Paid service for network controllers or self-hosted network controllers




Discussion of WireGuard

  • WireGuard aims to be as easy to configure and deploy as SSH. A VPN connection is made simply by exchanging very simple public keys – exactly like exchanging SSH keys – and all the rest is transparently handled by WireGuard. It is even capable of roaming between IP addresses, just like Mosh. There is no need to manage connections, be concerned about state, manage daemons, or worry about what's under the hood
  • WireGuard securely encapsulates IP packets over UDP. You add a WireGuard interface, configure it with your private key and your peers' public keys, and then you send packets across it. All issues of key distribution and pushed configurations are out of scope of WireGuard. In contrast, it more mimics the model of SSH and Mosh; both parties have each other's public keys, and then they're simply able to begin exchanging packets through the interface
  • WireGuard works by adding a network interface (or multiple), like eth0 or wlan0, called wg0 (or wg1, wg2, wg3, etc). This network interface can then be configured normally using ifconfig(8) or ip-address(8), with routes for it added and removed using route(8) or ip-route(8), and so on with all the ordinary networking utilities. The specific WireGuard aspects of the interface are configured using the wg(8) tool. This interface acts as a tunnel interface.
  • At the heart of WireGuard is a concept called Cryptokey Routing, which works by associating public keys with a list of tunnel IP addresses that are allowed inside the tunnel. Each network interface has a private key and a list of peers. Each peer has a public key. Public keys are short and simple, and are used by peers to authenticate each other. They can be passed around for use in configuration files by any out-of-band method, similar to how one might send their SSH public key to a friend for access to a shell server
  • The client configuration contains an initial endpoint of its single peer (the server), so that it knows where to send encrypted data before it has received encrypted data. The server configuration doesn't have any initial endpoints of its peers (the clients). This is because the server discovers the endpoint of its peers by examining from where correctly authenticated data originates. If the server itself changes its own endpoint, and sends data to the clients, the clients will discover the new server endpoint and update the configuration just the same. Both client and server send encrypted data to the most recent IP endpoint for which they authentically decrypted data. Thus, there is full IP roaming on both ends
  • WireGuard sends and receives encrypted packets using the network namespace in which the WireGuard interface was originally created. This means that you can create the WireGuard interface in your main network namespace, which has access to the Internet, and then move it into a network namespace belonging to a Docker container as that container's only interface. This ensures that the only possible way that container is able to access the network is through a secure encrypted WireGuard tunnel

  • The most obvious usage of this is to give containers (like Docker containers, for example) a WireGuard interface as its sole interface.

  • A less obvious usage, but extremely powerful nonetheless, is to use this characteristic of WireGuard for redirecting all of your ordinary Internet traffic over WireGuard.

  • It turns out that we can route all Internet traffic via WireGuard using network namespaces, rather than the classic routing table hacks.

...

  • VpnCloud is a simple VPN over UDP. It creates a virtual network interface on the host and forwards all received data via UDP to the destination. VpnCloud establishes a fully-meshed VPN network in a peer-to-peer manner. It can work on TUN devices (IP based) and TAP devices (Ethernet based)
  • Setting up tunnels between two networks via Ethernet (TAP) and IP (TUN)
  • Connecting multiple networks with multiple forwarding behaviors (Hub, Switch, Router)
  • Encrypted connections using libsodium
  • Automatic peer-to-peer meshing, no central servers
  • NAT and (limited) firewall traversal using hole punching
  • Automatic reconnecting when connections are lost
  • Non-native forwarding modes, e.g. IP based learning switch and prefix routed Ethernet networks.
  • High throughput and low additional latency (see performance page)
  • Support for tunneled VLans (TAP device)
  • Option to hide protocol header
  • Automatic port forwarding via UPnP

Discussion of PeerVpn

  • tbc

Discussion of OpenVpn

...