As indicated in this post, disaggregation of 5G is becoming inevitable. In the case of 5GC, its components (mainly SMF, AMF and UPF) will eventually be deployed across multiple K8s based edges (Could be in thousands too based on the size of the country and population) with other 5GC control plane deployed in tens of K8s based sites.
Note that Edges (whether owned, rented by Telcos) are not as physically secure as major clouds. Hence, there are always lingering security concerns and that might be a delaying factor to true disaggregation & distribution.
But, there are technologies that can address the security concerns. Before going further on the technologies, let us list down a few security concerns. Note that these security concerns are mainly related to disaggregation. Other security concerns are common even if 5GC is centralized and hence those security concerns are not listed here.
Security concerns due to disaggregation and Edge:
- Transactions/Queries among the control plane CNFs/Microservices shall not be in clear. At the same time, Telcos prefer these CNFs to be good at what they do, but not worry about communication security, authentication & authorization aspects. That is, Telcos expect the infrastructure to take care of inter-CNF and inter-microservice communication security. Delegating the security to infrastructure does provide multiple benefits - Uniform security enforcement making it easy for DevSecOps to their jobs and of course less buggy system as one finds that good number of vulnerabilities in the Industry are related to privilege escalations & they can be avoided if CNFs don't have code related to security.
- Transactions/queries between control plane and user plane (data plane) CNFs/Microservices shall not be in clear . This communication may not be HTTP2/TCP based. Between AMF and gNB, it is SCTP based and between SMF and UPF, the communication is based on UDP. Yet, the communication security is to be maintained with respect to on-the-wire encryption, authentication and authorization.
- Data traffic between user plane (data plane) CNFs/Microservices also shall not be in clear. Many times, GTP-U/UDP is used to transport the packets. Since real time characteristics are to be maintained, this communication security has to be on a per packet basis. It is to be noted that the traffic on the wire even within the K8s cluster shall not be in clear. Many 4G/5G deployments assume that the security gateway (IPSEC GW) can be outside of UPF. That is, traffic between IPSEC gateway and UPF is clear. That is not acceptable in Edges due to security concerns.
- Threats are expected to be detected and removed/sanitized as much as possible at the ingress. One needs to assume that there would be compromised UEs (mainly IoT devices). Protection from security threats including DDoS attacks, DoS attacks are protected on the clear traffic right after decrypting the packets before any processing on the inner packets happen. It is to be noted that the threat removal shall not lead to sending the data in clear on the wire. So, many times, it is advised to add threat security mitigation within UPF. Traffic flood protection is advised to happen in the basic networking layers (either in SmartNIC or L2/L3 switches) to avoid overwhelming the UPF running in cores.
- Private keys are expected to be secured well even from the sophisticated attackers that have access to the physical location of the Edge. Private keys are used for authentication. If private keys are compromised, an attacker can impersonate as a genuine user/microservice and access/modify information. Certificate authority private keys are even more important as these are used to provide authentication credentials.
- Secrets are expected to be secured from the sophisticated attackers having access to physical location. Secret resources are used by many CNFs and applications for storing passwords & API keys to various services such as databases. If one gets hold of these, they can read/manipulate the databases and other services. Hence, protection of secrets is needed.
- Memory scraping by attackers/malicious-infra-admins is also a big concern for some. Protecting confidential information in the memory, protecting AI models and even protecting the logic IP of the CNF/Application is important for few use cases.
- Concerns about malicious software being installed and concerns about malicious nodes joining the clusters are few other concerns. By adding malicious software, attackers may even bypass some of the security mechanisms to protect above attacks.
Below picture provides possible attack surfaces with respect to 5G.
In my view, Telcos would be looking for a comprehensive solution to address these security concerns. Following are some of the solution considerations and technologies that can mitigate the security concerns listed above.
- Communication security endpoints have to be in the same POD as the CNF/microservice to ensure that the traffic is never in clear on the wire even within the K8s cluster. Security among the control plane components can be achieved by ISTIO/Envoy or any other service mesh technology. Service meshes introduce sidecar containers in the POD. Security among the control plane and user plane components can be achieved by IPSEC sidecar. Communication security among the user plane CNFs also can be achieved by IPSEC sidecar. OpenWRT/Strongswan is one good candidate to realize IPSEC sidecars.
- Private keys are used by many components in K8s. K8s components themselves use mutual TLS. K8s has its own CA. ISTIO uses CA and ISTIO sidecars (Envoy) use mutual TLS. It is expected that all the private keys are secured with some kind of TEEs. This way, even if one gets access to a hard drive or memory, he/she can't get hold of private keys. SGX based key protection is one such solution that can be adopted to secure the keys.
- Passwords and API keys are used all the time. Securing them with hardware root of trust (TEEs) is needed. Again, SGX can be used to protect secret vaults such as 'hashicorp' vault (a popular secret management service in K8s). Moreover, it is advisable to have one more level of security at the disk level (encrypted disk) to ensure that any other non-secret resources are also secured.
- Secure computing of critical CNFs/PoDs in TEE is important to protect IP, Models and data. TEE (for example SGX) based K8s runtime is one solution that can bring up the entire POD (POD containing multiple containers and each container having multiple processes) in secure enclaves.
- Secure boot and measured boot are two techniques used to ensure that platform software can be trusted either to place workloads or to join the cluster. isecl is one such solution that can be used to address attestation concerns.
- Threat security in my view would need to be part of the sidecars (either as WASM Plugins to allow multi vendor security solutions) or part of the UPF itself to ensure good performance via one-pass security & via avoiding multiple network traversals. We, at Intel, are working on enhancing ISTIO/Envoy and SDWAN solutions with WASM based threat security. Using this framework, any security vendor can add security plugins. Please talk to us if you want to know more.
- Last, but not least is the observability, visibility and auditability of security is needed to give confidence to yourself as well as to identify any potential problems. Ensure that any security solution you get can generate the right metrics and logs that work with cloud native tooling such as Prometheus, fluentD etc..
In summary, disaggregated & distributed 5G leveraging Edge-computing is happening. If security is not thought through from day 1, this could lead to disruptions that can have implications to businesses. This post gave a few security concerns one needs to be aware of and possible solutions to mitigate those security concerns. Do let us know if you like to know more and have any comments.