Four Layers of Validity: From ASN.1 Syntax to UE State
This chapter follows the early connection sequence handled by a 5G user equipment (UE) and asks where “validity” changes meaning along the way. The focus is the relationship among the radio link, the initial Non-Access Stratum (NAS) exchange, authentication state, and the UE's own interpretation of Radio Resource Control (RRC) configuration. By the end, the reader should be able to tell whether a message is merely encodable, semantically coherent, protected at the relevant stage, and safe for the implementation to apply.
The distinction is easiest to see as a sequence of state transitions rather than as a checklist of protocol names. A message begins as information carried over a radio link. It becomes a structured object in the UE. Some of its meaning is determined by the fields themselves; some depends on other fields or on what the UE has already configured. Separately, the network may or may not yet have a security context with the device. These transitions interact, but one does not certify the others.
The connection is a chain of owners and state transitions
The 5G architecture divides early connection work between the Radio Access Network (RAN) and the core network. The RAN, represented by a gNodeB in the paper's setting, provides the radio link and carries control traffic. The core network handles authorization, mobility, sessions, and services. The UE baseband sits at the receiving edge of the radio system: it must decode RRC messages and use them to configure the lower layers that make the connection possible.
This division creates two related control-plane paths. The Access Stratum, or AS, contains the radio-specific work. It covers the procedures by which the UE finds a cell, establishes radio resources, and exchanges RRC messages with the RAN. The NAS path is radio-agnostic from the viewpoint of its higher-level purpose. It carries information between the UE and the core, including the first request to register and the exchanges needed to establish a security context.
The boundary is functional, not a clean physical wall. NAS messages travel across the radio link, but their destination is the core. RRC messages are handled by the UE and RAN to establish and configure that link. A UE can therefore receive an RRC configuration before the core has completed the authentication sequence used to protect later NAS signaling. The fact that the same radio connection carries both paths does not mean that they acquire protection at the same instant or that the same component validates their meaning.
In the study, the early RRC phase is especially important because it precedes authentication and integrity protection. The target workload is the connection-establishment path, with RRCSetup as a rich configuration message. It can initialize several lower-layer subsystems, so a field relationship that is not checked may be carried forward into code that assumes the relationship already holds. The danger is not confined to the first decoder. It can appear when a decoded object is handed to MAC, PHY, or another stateful part of the baseband.
The subsequent NAS procedure makes the timing easier to understand. If the UE has no NAS security context, it must initially send a limited set of information in cleartext. The core needs that information to identify the device, understand its security capabilities, and begin authentication. After Authentication and Key Agreement, the UE and core can hold a new security context and use it to protect later messages. The RRC configuration that arrived earlier is not made safe retroactively by this later transition.
If the UE already has a usable context, the initial NAS message can contain both its necessary cleartext information and the complete initial message inside a protected NAS container. When the core can verify the context and the integrity check succeeds, some authentication steps may be omitted. If the check fails—for example, because the core cannot find the referenced context—the network establishes a new one and requests the protected retransmission. In both branches, the security state changes the treatment of NAS. It does not erase the fact that early RRC processing happened at the UE boundary.
The diagram shows two different kinds of transition. The move from NoContext through AKA to ProtectedNAS is a cryptographic and protocol-state transition owned by the UE and core together. The SemanticGate is an implementation responsibility at the point where the UE turns RRC data into configuration. A message can pass one gate and fail another. For example, an RRC object may be structurally acceptable before the UE has a security context, while still violating a relationship that the baseband should check before applying it.
That separation also clarifies what a successful connection means. A UE that reaches a protected NAS exchange has completed one important security transition. It does not follow that every earlier RRC field was semantically validated, nor that every device would react safely to the same early input. Conversely, an RRC semantic check cannot protect the NAS information that remains exposed during bootstrap. The system works only when each owner checks the property that belongs to its boundary.
A parser answers only the first question
RRC messages are specified as ASN.1 structures and encoded with Packed Encoding Rules. ASN.1 gives a parser a formal description of the message: the type of a field, whether a component is present, the domain of an integer or enumerated value, and how nested information elements fit together. These guarantees are necessary. Without them, the UE might not know where one field ends or how to reconstruct the object.
But a parser's success is a statement about representation. It says that the bitstream can be decoded into an object whose values fit the structural grammar. It does not necessarily say that the object represents a configuration permitted by the standard or expected by the next subsystem. A field can have a legal value in isolation while contradicting another field. An optional component can be absent while the intended behavior is to preserve or remove a previously configured value. Two identifiers can each be well-typed while no longer referring to the same object.
The difference resembles the gap between a sentence that follows a grammar and a sentence that makes sense in context. The analogy is limited, because RRC semantics are specified by technical rules rather than ordinary interpretation, but the engineering consequence is concrete: the receiver must enforce conditions that are not encoded in the basic shape of the message.
The paper's taxonomy makes that gap precise. A value-range condition limits a field to a declared numeric or enumerated domain. A presence condition governs what the UE should do when an optional field is absent; the paper discusses need-code behavior that can require retaining a prior value or removing it. An intra-IE dependency relates fields inside one information element. An inter-IE dependency links fields across elements or protocol sublayers. The first two can often be read from the RRC schema. The latter two are frequently described in normative prose elsewhere in the 3GPP specifications.
The important point at this stage is not to memorize the categories. It is to notice how each one can survive ordinary parsing. A field-range violation may be accepted if the decoder or encoder does not enforce the declared bound in the relevant path. A missing optional field may leave a decodable object but create an unexpected state during later processing. A same-element inconsistency can pass because both values are individually legal. A cross-element mismatch can pass because the parser does not know that two names form a reference relationship.
Once the object is decoded, the implementation must decide what to do with it. A defensive path can reject the message, ignore the affected configuration, preserve a safe prior state, or recover without terminating the modem. A fragile path can assume that the specification relationship has already been enforced elsewhere. The latter assumption is especially dangerous when the object crosses an interface from a decoder into a scheduler, power-control routine, PHY procedure, or another subsystem with its own invariants.
This is how a semantic condition becomes an implementation failure. The specification says that two values must align. The decoder produces two valid fields. The downstream routine uses one value to calculate an index, duration, resource, or reference that implicitly depends on the other. If the dependency was never checked, the routine receives an internal state that its normal control flow was not designed to handle. The visible outcome may be an assertion, a null dereference, a crash, a modem restart, or an attachment failure. The exact symptom depends on where the unchecked assumption is consumed.
The paper's evidence is focused on availability, so the cautious interpretation is important. A crash demonstrates that an input reached a failure path in the tested implementation. It does not, by itself, prove code execution, data disclosure, or a network-wide outage. Nor does one device's failure establish that every implementation sharing a chipset family behaves identically. The value of the observation is that it ties an observable failure to a specification-level relationship that the test deliberately challenged.
Security state does not certify semantic state
It is tempting to treat authentication as the point at which the system becomes secure and everything before it as one undifferentiated insecure phase. The actual sequence is more exact. Before a security context exists, some NAS information must be exposed so the core can identify the UE and initiate authentication. The RRC path may also be active before integrity protection. After a context is established, later NAS signaling gains stronger protection, but the implementation still has to process the messages it received earlier and manage the state they created.
The initial NAS design described by NIST shows why this cannot be reduced to “cleartext versus encrypted.” The cleartext portion is deliberately limited, and the complete initial message is later carried in a protected container. The core compares the two portions where appropriate. This addresses tampering of sensitive NAS content during bootstrap, while specialized rules protect or reject particular cleartext claims. It is a carefully designed compromise between the information needed to start the connection and the protection that becomes possible only after keys exist.
RRC semantic validation addresses a different failure mode. It asks whether the UE should accept the meaning of an early control message before the later NAS security procedure can provide its guarantees. A core-network check of a protected NAS copy cannot undo a modem crash caused by an earlier RRC configuration. An RRC check cannot conceal a subscription identifier or protect a NAS field that must be sent before a context exists. The controls complement each other because they sit at different boundaries and have different owners.
Deployment mode adds another condition. NIST states that the comprehensive initial-NAS protection described in its draft is available in 5G Standalone deployments with a 5G core, not in Non-Standalone deployments that use a 4G core. Even within Standalone operation, the treatment of the initial NAS message depends on whether a security context is available. A claim that “the 5G network protects the initial handshake” is therefore incomplete unless it specifies the core deployment, message layer, connection stage, and context state.
For the UE, the practical rule is equally conditional: being able to decode an RRC object is not permission to trust all of its implied relationships. The baseband needs checks at the point where fields become configuration, not only checks at the network boundary after authentication. That is the hidden coupling exposed by the paper. The security procedure belongs to a UE–core lifecycle; semantic consistency must also be maintained within the UE while that lifecycle is still being established.
The resulting four-question model is simple enough to use and strict enough to prevent confusion:
- Can the message be represented? This is the syntax and encoding question.
- Does its content satisfy the applicable relationships? This is the semantic question.
- Is the message protected in the current protocol state? This is the authentication and integrity question.
- Can the implementation apply or reject it safely? This is the robustness question.
A test that answers only the first question can miss the failure surface that matters most. A network assessment that answers only the third can miss a UE-side state transition that occurs before the protected NAS exchange. The next step is to examine where the semantic relationships come from, how they differ in scope, and why their evidence is split across formal schema and normative specification text.