An application-aware firewall re-labels a live flow from permitted web traffic to a tunnel mid-session — what has it already cost you?

## Why a label changes mid-flow Classification is not a one-shot decision taken at the start of a session and then frozen. Evidence keeps arriving, and some evidence only arrives later. A session may begin with an exchange that matches a generic protocol, then negotiate an upgrade, then start carrying something entirely different inside the channel it just established. The classifier is doing exactly what it should when it revises the verdict. There are three broad reasons a label moves: - **Refinement.** The device first knows only that this is an encrypted session, then reads enough handshake metadata to name the service behind it. Generic label, then specific label. - **A genuine protocol shift.** The session negotiates an upgrade or establishes a tunnel over a channel that was itself perfectly ordinary. - **Deliberate shaping.** Traffic built to be classified as a permitted application for as long as possible, then used for something else. This is the adversary this leaf exists for, and note what they are attacking: not the port number, but the *shape* the classifier is matching on. ## What the device does on the re-label Policy is re-evaluated with the new label. The rule that matched before may no longer match; a different rule now decides. If the new decision is deny, the flow is dropped and typically reset. Everything that crossed under the old decision has crossed. This matters for how you *write* the rule base. A flow can be counted against two applications in the same session, so a policy written as though each flow has one immutable label will be surprised: the allow that let the session start is not the rule that finally governed it, and reports built on the final label alone will under-report what the permitted rule actually carried. ## The three prices **Bytes already delivered.** The size of this depends entirely on when the shift happened. A tunnel established at the start of a session is caught quickly. A tunnel established on a session that has been legitimately busy for an hour is caught after that hour of cover. **Teardowns on benign traffic.** This is the cost that separates a filtering control from a monitoring one. A classifier that decides a legitimate internal application looks like a denied class does not generate an alert somebody triages later — it drops a live session in the middle of a transfer. The user experience is a corrupted upload, a stalled backup, a client that reconnects and stalls again. Somebody has to own that outcome, and at a boundary shared by several customers the person who owns it did not choose the rule. **Design pressure on the adversary, and how they answer it.** If re-labelling reliably ends the session, the counter-designs are obvious: stay inside the behaviour of a permitted application so no shift is ever detected; or accept the teardown and keep each session small, opening many, so the amount lost per detection is trivial. Both are cheaper for them than they are for you, and this is why the re-label is best understood as a *signal generator* as much as a block. ## The part worth keeping The transition itself is high-quality evidence. "This flow was labelled an ordinary permitted application and then re-labelled as a tunnel" is a much sharper statement than either label alone, because ordinary sessions do not usually do that. It is worth recording the pair and reporting on it, whether or not the policy allows the second label — including for the flows you decided to permit, where the re-label is the only trace you will keep. ## What to avoid claiming Do not claim the boundary "blocked the tunnel". It blocked the *remainder* of the tunnel. If someone asks how much moved, the answer is in the session's byte counters, and it is never zero.