ONAP-to-Edge Secure site reachability Edge Automation working group Srinivasa Addepalli Ramki Krishnan

Background – Management network ONAP ONAP makes multiple outbound connections to sites. Sites that make multiple inbound connections to ONAP All connections are not HTTP(S) based Some are UDP based (Collectd) Some are SSH (Netconf) based. Kafka based (non-HTTP TCP) New protocols in future Limited number of public IP addresses Terminal proxy Multi-Cloud SDNC APPC DCAE Management Network Cloud-region (e.g Edge) Edge-Cloud (e.g Openstack Edge) Workloads keystone neutron Fabric Cinder Nova Glance NFVI-nodes

Requirements ONAP shall be able to communicate with multiple services in Edges/Sites that have only one public IP address (either static or dynamic) ONAP shall be able to communicate with services running in multiple nodes. ONAP shall be able to communicate with services that are non HTTP/S based. Edges/Sites shall be able to communicate with ONAP To send notifications/statistics via various protocols (UDP/Collectd, SNMP, NTP etc…) Communication between ONAP and Edges/Sites shall be secure. Communication between ONAP and Workloads shall be secure Secure communication entities shall be able to authenticate with each other. No changes to existing ONAP components

Solution overview Connectivity between ONAP & Edges/Sites using private IP addresses. (IPSEC/IKEv2) Certificate based authentication between ONAP and Sites. (X.509v3 certificate based authentication) Authenticated certificate enrolment (Using ISTIO CA) All communication would need to be encrypted/integrity checked (IPSEC/IKEv2, AES-GCM) Support Edges that have overlapping IP addresses (Internal IP address assignment / Static NAT at the ONAP) Similar to 3GPP solution – 32.508

Solution deployment architecture ONAP K8S ISTIO CA Components: IPSEC Gateway as a container Node agent to be part of IPSEC Gateway Reference (jumpstart) software for VNFs/PNFs: IPSEC Client/EM agent & Node agent EM as a container : Which configures IPSEC Gateways/NAT when the edges are onboarded in ONAP Static NAT part of IPSEC GW container DHCP Server and DNS Server as a container. Multi-Cloud SDNC APPC DCAE EM Static NAT DHCP Server DNS Server IPSEC Gateway/Server Management Network Cloud-region (e.g Edge) Edge-Cloud (e.g Openstack Edge) Workloads EM agent, IPSEC Client Node Agent IPSEC Gateway, Node agent, EM Agent keystone neutron Fabric NFVI-nodes Cinder Nova Glance

Edge onboarding – infrastructure VPN 1 Create edge service account (ISTIO CA gets to know it) Add Edge network information (Edge private IP subnet information, FQDN information vs IPs) – Internally allocates unique subnet (ONAP edge IP) EM onfigures static NAT to translate edge IPs to ONAP edge IPs (Ensures all ONAP see is unqiue edge IPs). EM configures DNS Server with local subnet IP addresses EM configures IPSEC Gateway to accept new tunnels IPSEC Gateway is brought up by passing service account created at the ONAP. Also, IPSEC Server/config information is passed. Node agent (using service account) creates CSR and gets the certificate (signed by ISTIO CA). BTW, ISTIO verifies the CSR to ensure that it is giving certificate for the service accounts it knows. IPSEC tunnel gets established. ONAP K8S ISTIO CA Multi-Cloud SDNC APPC DCAE 2 3 3 EM Static NAT DHCP Server DNS Server IPSEC Gateway/Server 4 Management Network 7 6 Cloud-region (e.g Edge) Edge-Cloud (e.g Openstack Edge) Workloads EM agent, IPSEC Client Node Agent 5 IPSEC Gateway, Node agent, EM agent keystone neutron Fabric NFVI-nodes Cinder Nova Glance

Management Network for ONAP to workload communication 3 One time: Admin via EM adds IPSEC Server configuration (to issue IP addresses via local DHCP Server) EM configures DHCP Server and IPSEC Server On per workload basis : Create a service account (mostly it is done as part of VNF onboarding?). ISTIO CA comes to know about it via ISTIO watcher. Workload is brought up (may be via cloud-init or via environment variables) with IPSEC Server information, service account etc… Workload gets the certificate enrolled by ISTIO CA (CSR with service account name). ISTIO CA verifies CSR subject/altname with the service accounts it has, then issues certificate. (over public IP address) Workload establishes IPSEC tunnel and gets the internal IP address from DHCP Server IPSEC communication between workloads and ONAP services. ONAP K8S ISTIO CA Multi-Cloud SDNC APPC DCAE 1 2 EM Static NAT DHCP Server DNS Server IPSEC Gateway/Server 2 5 Management Network 6 7 Cloud-region (e.g Edge) Edge-Cloud (e.g Openstack Edge) Workloads EM agent, IPSEC Client Node Agent 4 IPSEC Gateway, Node agent, EM Agent keystone neutron Fabric NFVI-nodes Cinder Nova Glance

Discussion Any other options? Any missing scenarios? Should we project this as a separate project or make it part of Multi-Cloud project? Contributors? Intel, VMWare, Verizon (showed interest), ??? Need for “Terminal proxy” for devops to SSH into VM via ONAP???