References

• Discussion list topic "ONAP Support for Secure Communication"
  • https://lists.onap.org/g/onap-discuss/topic/27369768
  • https://lists.onap.org/g/onap-discuss/message/13141
• Discussion list topic "[aai] Support for 2-way SSL?"
  • https://lists.onap.org/g/onap-discuss/topic/28503357
• ONAP security Recomendation Development
  • Secure communication recomendation when ISTIO is used
  • Secure Communication to Network Functions
  • Pluggable Security
• Platform Maturity Requirements (S3P)
• R2 proposals for Non-functional requirements

Survey of Options

• https://www.tinc-vpn.org/
  • https://www.tinc-vpn.org/vpnlinks/
• https://www.zerotier.com/
  
  • https://blog.ecapuano.com/build-a-private-mesh-network-for-free/
• https://www.wireguard.com/
• https://github.com/dswd/vpncloud.rs
  
  • https://medium.com/@matteocontrini/how-to-setup-a-peer-to-peer-fully-meshed-vpn-between-servers-249a9071e714
• https://serverfault.com/questions/685820/are-there-any-distributed-mesh-like-p2p-vpns
• https://peervpn.net/
• https://github.com/heyaaron/openmesher/

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

Threat Models

1. External attacker analyzes the captured traffic among services to steal secrets such as passwords and certificates
2. Internal attacker analyzes the captured traffic among services to steal secrets such as passwords and certificates
3. External attacker bombards the container services with new connections, leading to large number forked processes and threads leading to resource issues on other workloads (containers) in the system
4. Internal attacker bombards the container services with new connections, leading to large number forked processes and threads leading to resource issues on other workloads (containers) in the system
5. External attacker exploits downloads of containers from repositories to tamper with them and inject malicious code
6. Internal attacker exploits downloads of containers from repositories to tamper with them and inject malicious code
7. External attacker introduces malicious VM into ONAP environment to steal data and subvert operations
8. Internal attacker introduces malicious VM into ONAP environment to steal data and subvert operations
9. External attacker introduces malicious pod into ONAP environment to steal data and subvert operations
10. Internal attacker introduces malicious pod into ONAP environment to steal data and subvert operations
11. External attacker introduces malicious microservice into ONAP environment to steal data and subvert operations
12. Internal attacker introduces malicious microservice into ONAP environment to steal data and subvert operations
13. External attacker introduces malicious external-system into ONAP environment to steal data and subvert operations
14. Internal attacker introduces malicious external-system into ONAP environment to steal data and subvert operations

Discussion

• There has already been discussion and recommendation for using Istio https://istio.io/
• This page is gathering thoughts for alternative solutions

Discussion of Istio

• tbc

Discussion of Tinc VPN

• VPN appears to the IP level network code as a normal network device
• Automatic full mesh routing. Regardless of how you set up the tinc daemons to connect to each other, VPN traffic is always (if possible) sent directly to the destination, without going through intermediate hops.
• Easily expand your VPN. When you want to add nodes to your VPN, all you have to do is add an extra configuration file, there is no need to start new daemons or create and configure new devices or network interfaces
• Ability to bridge ethernet segmentsYou can link multiple ethernet segments together to work like a single segment, allowing you to run applications and games that normally only work on a LAN over the Internet.
• Runs on many operating systems and supports IPv6. Currently Linux, FreeBSD, OpenBSD, NetBSD, OS X, Solaris, Windows 2000, XP, Vista and Windows 7 and 8 platforms are supported. tinc has also full support for IPv6.

From https://www.tinc-vpn.org/pipermail/tinc/2017-May/004864.html:

In general however, I would advise against trusting other nodes, even with
StrictSubnets=yes. tinc is not currently designed to provide strong
protection against insider attacks - for the most part it assumes that
every node inside the metaconnection graph can be trusted. In my opinion
tinc will do poorly in a scenario where a "compromised node" is part of
your threat model.

Discussion of ZeroTier

• 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.
• 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.

Discussion of WireGuard

• tbc

Discussion of vpncloud.rs

• tbc

Discussion of PeerVpn

• tbc

Discussion of OpenVpn

• tbc