...

• Conventional choices, but considered to be difficult to properly configure and maintain, also slow performance
  • IPSec
  • OpenVPN
• Others
  • PeerVPN
  • Counter-productive to CII Badging criteria, see also https://github.com/coreinfrastructure/best-practices-badge
    • Unmaintained in recent years
    • Vulnerabilities not addressed
    • "Bus factor" too low
    • Number of contributors and reviewers too low

Quick CVE Comparison

• https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=tinc
• https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=zerotier
• https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=wireguard
• https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=vpncloud
• https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ipsec+or+ike
• https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=openvpn

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

...

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

...

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

...