Work package 2 · Requirements and architecture
The 5G architecture: security architecture, strata, and trust model
The 5G architecture described here is a logical and functional structure rather than a deployment diagram: who owns what, which concerns cut across those boundaries, and what has to be trusted for any of it to hold.
- 6strata
- 5security realms
- 5architecture documents
D2.7Shape
What the 5G architecture describes, and what it deliberately leaves out
The final document is explicit about its own scope: it describes a logical and functional architecture and omits most of what belongs to physical deployment. That is a decision with a reason behind it. A 5G network is expected to be built largely from software running on shared, programmable infrastructure, so the perimeter that older designs relied on is not available to lean on, and a diagram of boxes and cables would describe one deployment rather than the system.
What the 5G architecture does instead is partition the problem twice over. The first partition is by domain, which groups things by who controls them: the card in the handset, the handset hardware, the infrastructure provider on one side, and the tenant domains (equipment, subscriber module, identity management, access, serving, home and transport) on the other. The second is by stratum.
4.3Strata
Strata architecture: six groupings of one concern each
The specification this 5G architecture starts from defines a stratum as a grouping of protocols related to one aspect of the services provided by one or several domains, and defines five of them. The strata architecture used here revises that definition in one small but consequential way: a stratum groups protocols, data and functions. The reasoning is that data needs protecting where it is stored and processed, not only while it is in flight between two endpoints.
| Application stratum | The application process delivered to the end user, and the end-to-end functions that consume services from the strata below. |
|---|---|
| Home stratum | Subscription data and home-network services: subscription management, billing and charging, authentication, mobility management while a subscriber is at home. |
| Serving stratum | A sub-stratum of the home stratum. Routing and forwarding between source and destination, whether or not they sit in the same network, and the session management around it. |
| Transport stratum | Carriage of user data and control signalling through the network, down to transmission format, error recovery and resource allocation. |
| Access stratum | A sub-stratum of the transport stratum, between the edge of the serving network and the device. Transmission over the radio interface and the management of that interface. |
| Management stratum | Configuration, software upgrade, account management, log collection, security monitoring, key and certificate management, and the management of virtualisation itself. |
+1Addition
Stratum management: the gap the earlier model left
The sixth entry is what the strata architecture adds, and it is the most-cited part of this work for a reason that is easy to state. Of the five strata carried forward from the earlier specifications, not one covers management. Orchestration, virtualisation control, key and certificate distribution, security monitoring and log analysis all had to live somewhere, and in the inherited model they lived nowhere.
Stratum management is therefore not a filing improvement. Whoever holds the management plane can reconfigure the network, and in a virtualised system that includes creating, moving and destroying the functions that enforce every other control. A model with no management stratum cannot express requirements about the one capability that outranks the rest, and stratum management is where those requirements finally have a home.
The same reasoning produced the security realms, which regroup the system a third time, purely by security need: access network, application, user equipment, network, and infrastructure and virtualisation. The realms exist because the five security feature groups inherited from the earlier specifications do not fit a network with management, monitoring and virtualisation in it, and because visibility, which those groups framed as something offered to a user, matters just as much between network functions that need to know whether the entity they are talking to is properly configured.
D2.5Trust
The trust model underneath the security architecture
None of the partitioning means anything without a statement of what is trusted to do what. The trust model is that statement, and it was written as its own deliverable twice: a draft early enough to inform the architecture, and a final that took the architecture’s results back into account. The dependency runs both ways, which is why the two were developed in parallel, not in sequence.
Its subject is uncomfortable in a virtualised network. A tenant domain runs on infrastructure owned by somebody else; an infrastructure provider hosts functions belonging to parties who do not trust each other and should not be able to reach one another. The trust model names those relationships so that a control can be checked against them, and the infrastructure and virtualisation realm exists precisely to hold the resulting requirements for attestation and isolation.
- D2.7 Security architecture (final)
- D2.4 Security architecture (draft)
- D2.5 Trust model (final)
- D2.2 Trust model (draft)
- D2.3 Risk assessment, mitigation and requirements (draft)
- PDFView on 5G Architecture, the public-consultation version
- PDFSecurity and resilience in 5G: current challenges and future directions
QQuestions
Questions and answers
What is a stratum, and how does it differ from a domain?
A domain is a grouping by ownership or physical boundary: the card in the phone, the handset hardware, the serving network, the infrastructure provider. A stratum is a grouping by concern, cutting across those boundaries. Both partitions are needed: a control can be correct within a domain and still fail because the concern it protects spans several of them.
Why add a management stratum?
Because the five strata inherited from earlier generations have no place to put management. The specification defined them for a network whose configuration changed rarely and by hand. A network assembled from virtualised functions is reconfigured constantly and programmatically, which makes orchestration and security management a first-order concern with its own very stringent requirements, not an operational detail outside the model.
Is this architecture the same as the 3GPP one?
No. It builds on the 3GPP security architecture and extends it, and it says so explicitly. The domains and the original strata come from the existing specifications; the management stratum, the security realms and the revised definitions are the additions, each introduced to cover a gap the earlier structure did not address.
Which document should be read first?
D2.7, the final security architecture, is written to stand on its own and incorporates material from the earlier draft. D2.4 is that draft, and is worth reading only to see how the position changed. The trust model exists as a draft and a final, D2.2 and D2.5, and the risk assessment likewise as D2.3 and D2.6.