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

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

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

4. 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 –

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

6. Edge onboarding – infrastructure VPN1
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

7. Management Network for ONAP to workload communication3
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

8. 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???