Chapter 8 — Identity, host and network failure modes

Chapter 8 — Identity, host and network failure modes

Lesson map

Lesson 08 published. Map, example, EX029.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["8.1 Name the failure layer and the user outcome"]
  N2["8.2 Normalize clocks without pretending to order eve"]
  N3["8.3 Competing hypotheses and discriminators"]
  N4["8.4 A two-step supervised troubleshooting lab"]
  N5["Subject synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX029"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["8.1 Name the failure layer and the user outcome"]
  N2["8.2 Normalize clocks without pretending to order eve"]
  N3["8.3 Competing hypotheses and discriminators"]
  N4["8.4 A two-step supervised troubleshooting lab"]
  N5["Subject synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX029"]

[Learning outcomes and connection]
    |
    v
[8.1 Name the failure layer and the user outcome]
    |
    v
[8.2 Normalize clocks without pretending to order eve]
    |
    v
[8.3 Competing hypotheses and discriminators]
    |
    v
[8.4 A two-step supervised troubleshooting lab]
    |
    v
[Subject synthesis]
    |
    v
[Worked example] --> [Exercise EX029]

Learning outcomes and connection

The learner will distinguish authentication, authorization, host and network symptoms; correct reported times under an explicit clock-offset model; and request observations that discriminate competing explanations. Chapter 7 established which sources could answer a question and which might be incomplete. Chapter 8 applies that discipline to a mixed-symptom packet. The lab is L8, a separate fictional branch. It is not a later discovery about N01–N06, I01–I02, H01 or A01. RFC 9110 supplies general HTTP status semantics; the L8 labels, clocks and diagnoses are original teaching fixtures.

8.1 Name the failure layer and the user outcome

An authentication error concerns establishing the claimed identity; an authorization error concerns whether an established principal may perform an action. A service may report HTTP 401 for an authentication challenge, 403 for a refusal and 503 for temporary service unavailability under appropriate HTTP semantics. Those codes are observations from a particular component, not diagnoses of the whole path. A gateway can produce 503 because an upstream call timed out, while the underlying cause is DNS, routing, queue pressure, an application dependency, a database delay or a deliberate maintenance action. An IdP denial does not prove a malicious user: expired credentials, clock skew, policy rollout and client configuration are possible. A host restart does not prove compromise: patching, crash recovery and operator action are possibilities.

LLR's user outcome remains a correct, authorized room reservation with an audit trail. L8 instead supplies a bounded symptom packet for a teaching variant at approximately 12:00 UTC:

This packet includes one IdP timeout, not an authentication rejection. Do not label it 401, 403 or “credentials stolen.” The edge's 503 says what the client got. The calendar is a planned change, not an execution receipt. The changed boot ID supports the hypothesis that the host restarted; it does not identify why. An API sample with no literal r-401 may be missing a mapped request ID. The packet gives enough to form testable hypotheses, not enough to select a single root cause.

8.2 Normalize clocks without pretending to order every event

For a source whose clock is ahead of UTC by two seconds, subtract two seconds from its reported time. For a source behind UTC by one second, add one second. The formula is corrected UTC = source-reported time − measured source offset. That correction should carry the offset measurement time and uncertainty; clocks can drift. Run the following code offline to reproduce the two stated estimates.

from datetime import datetime, timedelta

def corrected(raw, offset_seconds):
    reported = datetime.fromisoformat(raw.replace("Z", "+00:00"))
    return (reported - timedelta(seconds=offset_seconds)).strftime(
        "%H:%M:%S"
    )

print("F81 corrected:", corrected("2026-10-11T12:00:03Z", 2))
print("F82 corrected:", corrected("2026-10-11T12:00:00Z", -1))

The expected output is F81 corrected: 12:00:01 and F82 corrected: 12:00:01. The matching second does not establish which event came first or whether they share a transaction. F83's ±3-second uncertainty overlaps both estimates, and F84 has no execution timestamp. A proper technical timeline keeps raw time, correction rule, measurement uncertainty, producer and collection time in separate columns. It can state “temporally compatible” while refusing to draw a causal arrow. If an offset measurement is stale, record that as a limitation rather than fabricating subsecond precision.

8.3 Competing hypotheses and discriminators

Build a decision table instead of choosing the most vivid story. For each hypothesis, state what the packet supports, what remains unknown, a least-invasive owner-approved observation and a result that would weaken it.

The “weakening” column does not mechanically disprove a hypothesis. A query can be incomplete, and a path can fail intermittently. The responder should update confidence only within the tested interval and source coverage. A scheduled maintenance record may explain timing but not prove execution; an execution receipt plus a path-specific metric is stronger. Even then, attribution of a human or intent requires separate evidence. These distinctions matter because premature principal revocation or service restart can destroy useful volatile state and affect approved reservation work.

8.4 A two-step supervised troubleshooting lab

Step one is a paper request, not live access. Ask the network and application custodians for a 11:59:55–12:00:10 UTC window, including offset measurement, upstream mapping of r-401, timeout class, interface/path metrics, collection receipt and limits. Ask the change owner for a versioned maintenance execution record; a calendar entry alone is insufficient. Simultaneously ask the identity custodian whether the F82 timeout is one request or part of a broader pattern, with privacy-limited fields. The incident lead should approve the source scope, and each custodian should confirm query coverage.

Step two is a conditional interpretation. If a complete gateway-to-API trace maps r-401 to an API request that reached the database after the gateway deadline, API/database latency becomes more plausible; the IdP timeout may be separate. If the trace shows a drop on the API-to-IdP path concurrent with an approved switch change, network maintenance gains support. If the sources cannot be collected, retain multiple hypotheses and record the evidence gap. Do not choose a winner from a missing row. A useful handoff says which user outcomes are impaired, which claims are source-bounded, what authority is pending and what next observation would change the action.

A negative-control variant V8 changes only F82: the IdP custodian now supplies a validated successful response for the same mapped API request. That weakens a complete IdP outage for this transaction but does not prove that the edge's 503 was unrelated to identity for every request, or that the network was healthy everywhere. Keep the original and variant separate. The lab's purpose is to practice revising a hypothesis when better evidence arrives, not to issue a final diagnosis.

Common errors and limits

• Reading one 503 as proof of a cyberattack or one IdP timeout as a credential failure.
• Calling a scheduled maintenance window an executed change.
• Ordering two corrected one-second timestamps despite overlapping clock uncertainty.
• Treating a changed boot ID as a human attribution.
• Using a successful control on one route to claim every route was healthy.

Exercises — subject 8

EX029 — Symptom separation. Objective: keep layers distinct. For F81–F85, list producer, observed field, affected user outcome, one plausible failure layer and one unsupported inference. Explain why F82 is a timeout rather than an authentication denial. Evidence: five-row Markdown table. Rubric: 2 = all five with source limits; 1 = one conflation; 0 = declares stolen credentials or completed maintenance.

EX030 — Clock transcript. Objective: reproduce §8.2 and preserve uncertainty. Report both exact output lines, the correction formula, F83's uncertainty and why matching corrected seconds cannot order F81/F82. Evidence: raw/corrected timeline. Rubric: 2 = both outputs plus uncertainty; 1 = arithmetic only; 0 = asserts causality from time coincidence.

EX031 — Discriminator matrix. Objective: compare explanations without a premature action. For network, IdP/policy, host, API/DB and unauthorized-activity hypotheses, provide one supporting row, a custodian, an approved observation and a weakening result. Mark authorization status pending. Evidence: five-row table. Rubric: 2 = source-specific and falsifiable; 1 = generic “check logs”; 0 = orders a live restart or principal revocation.

EX032 — Variant handoff. Objective: update a conclusion with a negative control. Write a 160–220-word handoff contrasting original F82 with V8's validated success. Include the corrected clock, remaining r-401 mapping gap, maintenance execution question, service risk of a broad control and next owner. Evidence: versioned note, not final diagnosis. Rubric: 2 = variant kept separate and bounded next request; 1 = notes success but overstates scope; 0 = announces universal recovery or actor.

Subject synthesis

The packet supports several explanations, each with a different discriminator. Technical response requires source-specific, time-bounded and authorized tests; no code output, status code or calendar entry by itself assigns cause or actor. Chapter 9 starts a separate linked K workshop to practice evidence collection before any change proposal.

Continue studying — chapter 08 of 18

← Chapter 07 · Course chapter index · Chapter 09 →

Continue to the next authored lesson.