A Working Model of the Pre-Authentication Gap

The ideas established so far—pre-authentication reachability, ASN.1 structure, semantic constraints, authentication state, and UE implementation state—become useful when they are treated as one diagnostic model. This checkpoint connects those ideas and asks what a reader should be able to judge before accepting a crash, rejection, or successful attachment as meaningful evidence. The result is a disciplined way to read the 5G UE problem: not as one question called “is the message valid?”, but as several linked questions with different owners and evidence.

A model is valuable only if it changes how we interpret an event. If a UE rejects a malformed bitstream, that says something about parsing. If it accepts a well-formed RRC object and then fails while applying its configuration, that points to a different boundary. If the same object is delivered before or after a security context exists, the protection question changes again. The distinction is not academic bookkeeping; it determines what can be fixed, what can be claimed, and what still needs testing.

One input, several gates—not one verdict

Start with reachability. In the paper's threat model, a nearby rogue gNodeB can deliver downlink RRC input during the early connection procedure. The important property is that the UE may process this input before the integrity protection associated with later authentication is active. Reachability does not mean that the message will be accepted, only that it can arrive at the implementation boundary where acceptance or rejection is decided.

The next question is encodability. RRC's ASN.1 and Packed Encoding Rules describe how a message is structured and which values belong to declared domains. A message that cannot be decoded is stopped at the representation boundary. That is a legitimate and necessary failure, but it is not the failure surface examined by semantic testing. The relevant case is a message that remains sufficiently well-formed to become a structured object in the UE.

Then comes semantic consistency. Does the object satisfy the relationships that give its fields meaning? An individual field may be inside its declared range while conflicting with a companion value. An optional field may be absent even though its need-code semantics require a previous value to be maintained or removed in a particular way. A reference may point across information elements, but the object being referenced may not match the identifier that the rest of the configuration assumes. These checks concern the interpretation of the object, not its ability to be represented.

Authentication and integrity form another gate, but they answer a different question. The NIST description of the initial NAS message shows that some bootstrap information must be available before the core can establish or locate a security context. The first NAS portion can therefore be cleartext and limited, while the complete message is later repeated inside a protected container. When a context already exists, the protected path may be available earlier; when it does not, the security procedure creates it. Neither branch changes the time at which an earlier RRC message was processed.

Finally, the UE must handle the resulting state safely. A semantic rule can be violated deliberately or accidentally, but a robust implementation should not turn that violation into an uncontrolled modem failure.