Chapter 2 — Networks and protocols

Chapter 2 — Networks and protocols

Lesson map

Lesson 02 published. Map, example, EX005.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["2.1 Five questions in one request path"]
  N2["2.2 Synthetic trace with event and collection times"]
  N3["2.3 Choose a capture point by decision value"]
  N4["2.4 Offline lab: classify the supplied chain"]
  N5["2.5 Time and failure-domain caution"]
  N6["2.6 Evaluate evidence across protocol boundaries"]
  N7["2.7 Guided replay: choose a discriminator before a r"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX005"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["2.1 Five questions in one request path"]
  N2["2.2 Synthetic trace with event and collection times"]
  N3["2.3 Choose a capture point by decision value"]
  N4["2.4 Offline lab: classify the supplied chain"]
  N5["2.5 Time and failure-domain caution"]
  N6["2.6 Evaluate evidence across protocol boundaries"]
  N7["2.7 Guided replay: choose a discriminator before a r"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX005"]

[Learning outcomes and connection]
    |
    v
[2.1 Five questions in one request path]
    |
    v
[2.2 Synthetic trace with event and collection times]
    |
    v
[2.3 Choose a capture point by decision value]
    |
    v
[2.4 Offline lab: classify the supplied chain]
    |
    v
[2.5 Time and failure-domain caution]
    |
    v
[2.6 Evaluate evidence across protocol boundaries]
    |
    v
[2.7 Guided replay: choose a discriminator before a r]
    |
    v
[Worked example] --> [Exercise EX005]

Learning outcomes and connection

The learner will trace a reservation request across name lookup, transport, TLS and HTTP, say exactly what each observation establishes, and choose a bounded next evidence source. Chapter 1 supplied the components and trust boundaries; Chapter 2 tests whether a network record can identify the failing segment without overclaiming the responsible system or actor. Chapter 3 will add host processes and identity records. The protocol descriptions use RFC 9110 for HTTP semantics and RFC 8446 for TLS 1.3; LLR's trace and thresholds are invented.

2.1 Five questions in one request path

When a user says “the portal failed,” ask five distinct questions. Name resolution: what address did the client's resolver report and when? Reachability: was a transport connection established to that address? Protected channel: did a TLS handshake complete with the intended peer under the local trust policy? Application request: what method, target, request ID and response did the edge observe? Upstream work: did the API and database actually process the same request? A “yes” to an earlier question does not answer the later ones. A DNS answer can be cached, a TCP handshake can succeed while application data fails, a TLS handshake can complete while the HTTP service returns an error, and a gateway can return a page while an upstream write has failed.

For this offline fixture, portal.example.test is a synthetic label, not a live DNS name. RFC 6761 notes that .test names are special-use and may resolve differently across networks, so the exercise supplies a fabricated DNS result and instructs no lookup. 192.0.2.10 and 198.51.100.20 come from RFC 5737 documentation blocks. A real network capture requires organizational permission and privacy review, because addresses, headers and payloads can be sensitive even if the analyst only wants a status code. This chapter uses a short written trace instead.

TLS 1.3 is designed to protect client-server communication against eavesdropping, tampering and message forgery when correctly deployed. It does not prove that an application's logged user was entitled to reserve a room or that a specific human pressed a button. Conversely, seeing a TLS handshake in an edge log without an independently linked API request does not prove that the API received it. Keep transport identity, application principal and human attribution as separate fields. In the lab, the edge sees a request ID that the API log does not show in the supplied sample; absence from a sample is not proof of absence from the whole system.

2.2 Synthetic trace with event and collection times

All rows below are fictional observations, supplied together at exercise time 12:06 UTC. Event times are source-reported UTC. The limited API log sample covers 12:00:00–12:00:10 and may be incomplete; no packet payload is provided. The trace column contains only classroom labels.

The trace narrows one segment: the client reached an edge that performed TLS and generated an HTTP response. A DNS failure for this particular recorded connection is inconsistent with N02/N03, though N01 alone would not prove browser resolution. N04's 503 means the request did not obtain the expected successful resource response; per RFC 9110, a status code describes the response semantics, not the complete root-cause chain. The edge's upstream_timeout=true is a producer claim to investigate, not independently corroborated evidence that api failed. N05 might result from an API reachability problem, dropped or transformed request ID, log delay, short sample window or incomplete logging. N06's static health check cannot certify /rooms or writes. Do not classify this as an attack solely because an alert fired.

2.3 Choose a capture point by decision value

If the immediate decision is whether to restart the API, the lowest-risk discriminator is often an owner-approved comparison of edge upstream metrics and API request/access logs for r-201 and adjacent requests, including the log pipeline's coverage and time basis. Ask for a narrow 12:00:00–12:00:10 UTC window and the ID semantics: does the edge pass r-201 unchanged? If it does, a validated API log with no matching receipt can strengthen a path-to-API hypothesis; if it generates a new upstream ID, the absence of r-201 is expected and a mapping record is needed. A second bounded check of API-to-database health may be necessary if the API did receive and time out. Only owners can approve those records or any restart.

A packet summary from the client-to-edge link answers transport questions but may add little about the edge-to-API failure. A broad packet capture can create privacy and storage costs without supplying a join key. Prefer the source that can change the decision with the least collection. Record producer, time window, query, custodian, retention, permission, expected discriminator and what a negative result would mean. NIST SP 800-92 provides a high-level log-management foundation; its 2006 technical specifics are not a modern vendor recipe.

2.4 Offline lab: classify the supplied chain

Copy the six rows into a local Markdown file or use the exact dictionary below in Python 3. The script has no imports, files or network calls. It computes only which stages have a supplied positive observation and prints an interpretation boundary. Do not rewrite api_seen=False as “the API received nothing”; it means the supplied sample lacks a row.

trace = {"dns_answer": True, "tcp_to_edge": True,
         "tls_at_edge": True, "edge_http_status": 503,
         "api_sample_has_r201": False, "static_health_status": 200}
print("client-to-edge:", "observed" if trace["tcp_to_edge"] and trace["tls_at_edge"] else "not established")
print("rooms request:", trace["edge_http_status"])
print("API sample contains r-201:", trace["api_sample_has_r201"])
print("static health proves rooms success:", False)

Expected output is client-to-edge: observed, rooms request: 503, API sample contains r-201: False, static health proves rooms success: False on four lines. The negative control is to change tcp_to_edge to False in a copy of the dictionary and observe client-to-edge: not established; that changed fixture cannot be used to reinterpret N02. A technical report should carry the original and variant labels separately, just as incident cards have provenance. The code deliberately does not guess whether the API, database, network or logger caused the 503.

2.5 Time and failure-domain caution

The rows are ordered by source-reported event time, but no clock accuracy measurements are supplied. N01's TTL is a DNS cache parameter, not a guaranteed time during which the browser used that answer. N05's sample window brackets 12:00:03, but an async log could arrive after the interval. N06 is nearly three minutes later and tests a different endpoint. A real comparison would retain event time, collection time, source clock, interval boundaries and known lag. Chapter 3's host and identity records will add another set of time bases; they must be normalized before a causal timeline is asserted.

2.6 Evaluate evidence across protocol boundaries

The useful unit is a claim with a boundary, not a packet count. N02 establishes a client-to-edge TCP observation; N03 reports TLS at that edge; N04 is an HTTP response from the edge; N05 is absence of one ID in a supplied API sample. Each statement stops at a different component. The edge's 503 is positive evidence that it emitted a 503, yet its timeout label is still a producer claim about an upstream condition. RFC 9110 defines response semantics, not how this fictional application implements its timeout.

Before requesting more data, score candidate sources by decision value, collection cost, time sensitivity and privacy scope. A source has high decision value when its possible outcomes change the next safe action. A broad client-side packet capture adds little if the unresolved question is whether a mapped request reached the API; it can expose unrelated traffic. A bounded edge upstream map and API receipt are better first requests, subject to owner approval.

A negative query is conditional on the producer's identifier namespace, source completeness, time basis, delivery lag and filters. If any is unknown, write “no row in the supplied sample.” Save the query and transformation alongside the result; otherwise a reviewer cannot tell a missing source event from a filtering mistake. This practice follows the general log-management concern in NIST SP 800-92, while system-specific retention and export behavior require verification with their owners.

2.7 Guided replay: choose a discriminator before a result

This N2-V replay is separate from N01–N06. On paper, set two hypotheses: H-path, the edge's request was not accepted by the API; H-processing, the API accepted it but later work failed or timed out. Neither is an incident finding. Predict the most discriminating permitted record: a producer-validated edge-to-upstream ID mapping and a coverage-checked API receipt for that mapped ID.

Variant A says a hypothetical complete API source contains that receipt and its handler later records a database timeout under the same validated ID. H-path weakens; H-processing gains support. The handler record still does not prove whether a database operation committed. Variant B says the edge map shows an attempted upstream connection; a complete API source has no receipt for the mapped ID; an edge-to-API transport summary reports connection failure. H-path gains support. These are mutually separate branches. Neither establishes an attacker, and neither may be imported into N01–N06.

Produce a four-line decision note: supplied observation; source/coverage condition; revised hypothesis; next bounded check. A's next check is permitted API-to-DB evidence and business-state verification. B's is an owner-approved edge-to-API path check. Remove the word “complete” from either card and reconsider: a strong negative conclusion must weaken to “not found in this sample.” This negative control tests whether the learner is reasoning from evidence quality rather than only from a result string.

Common errors and limits

• Calling a completed TLS handshake proof that application authorization succeeded. Transport and application rights are separate.
• Treating an edge 503 as proof that the API process crashed. The edge's label and the absent sampled API row need corroboration.
• Using a static 200 health response to close a reservation incident. Test the affected function under approval.
• Turning a log sample's missing row into “nothing happened.” State the sample coverage and pipeline lag first.
• Running a live DNS query or packet capture against invented addresses when the supplied offline data answers the lesson.

Exercises — subject 2

EX005 — Claim ladder. Objective: avoid cross-layer inference. Inputs: N01–N06. In a six-row Markdown table, give one supported claim and one unproven claim per row. Highlight the first stage where the expected /rooms outcome fails. Evidence: table with row IDs. Rubric: 2 = all six and correct boundary at N04; 1 = trace mostly right with one overclaim; 0 = labels TLS or N06 as reservation success.

EX006 — Bounded evidence request. Objective: pick a discriminator. Input: N04/N05 and the Chapter 1 graph. Write a read-only request to the edge/API custodians for a 12:00:00–12:00:10 UTC interval, exact ID semantics, expected fields, permission, retention and two possible outcomes. Evidence: request record, not a claim of collection. Rubric: 2 = scope, owner and both interpretations; 1 = useful source but unbounded or no negative-case meaning; 0 = unauthorized capture/restart.

EX007 — Offline classifier. Objective: reproduce and challenge a tool result. Run §2.4's code or reason by inspection. Give the four exact output lines, then change only tcp_to_edge in a copy and report the changed first line and why that variant cannot negate N02. Evidence: original/variant transcript. Rubric: 2 = exact output and source separation; 1 = output without limitation; 0 = claims a root cause from the printout.

EX008 — Clock and symptom note. Objective: make a cautious handoff. Inputs: N01 12:00:00 with TTL 60, N04 12:00:03 and N06 12:03:00. Write 110–160 words with observation, inference, uncertainty and next owner. Explain why the TTL and static health response do not determine the 12:00 /rooms outcome. Evidence: handoff note. Rubric: 2 = time bases and endpoint difference explicit; 1 = diagnosis plausible but timing vague; 0 = declares DNS compromised or service recovered.

Subject synthesis

The trace tells us where an observed request got, not who caused a failure. By preserving layer, source and time, the responder can request a narrower discriminator than “collect all traffic.” Chapter 3 adds process and identity evidence, where a matching account name can be as misleading as a matching timestamp.

Continue studying — chapter 02 of 18

← Chapter 01 · Course chapter index · Chapter 03 →

Continue to the next authored lesson.