Trace a request through two network models, calculate payload budgets, and choose evidence that actually supports a control claim.
45 min 120 XPSkills: Layer mapping, Encapsulation, Network evidence
Brief
At Halcyon Clinics, small portal requests succeed but large uploads stall after a network change. The service owner calls this an application authorization failure because the browser shows an error. The network analyst calls a captured Ethernet frame a TCP packet. Both descriptions skip the boundaries that would make the incident testable.
You will separate the seven-layer OSI reference model from the four-layer TCP/IP model, follow headers across a routed path, and calculate how many TCP data bytes fit into an IP MTU of 1500. Then you will select evidence for availability, segmentation, encryption and authorization controls without claiming that a lower-layer success proves a higher-layer decision.
A successful exchange at one layer is evidence about that layer, not proof that every layer above it is working or secure.
Two models, different boundaries
OSI numbers layers from the medium upward: 1 physical, 2 data link, 3 network, 4 transport, 5 session, 6 presentation and 7 application. Physical concerns signals and link state; data link handles local delivery using frames and link addresses; network handles routed delivery using IP addresses. Transport supplies endpoint ports: TCP adds a reliable ordered byte stream, while UDP carries independent datagrams without TCP's delivery guarantees.
The four-layer TCP/IP model groups OSI 1-2 into link, maps OSI 3 to internet and OSI 4 to transport, and groups OSI 5-7 into application. This is a useful comparison, not a promise that real software has seven separate modules. TLS provides encryption and representation-related functions above transport; it does not have to reside in a standalone OSI presentation component. TCP/IP's application layer includes protocols such as DNS and HTTP as well as functions described as session or presentation in OSI.
For a segmentation control, identify the enforcement mechanism rather than just writing 'network security'. A rule matching IP addresses and TCP ports uses network and transport fields. Its configuration and deny logs can support a segmentation test; they cannot establish that a permitted user was authorized to read a patient record. An auditor should ask which fields the control inspects and which layer's decision the evidence actually records.
The four-layer TCP/IP model combines several OSI responsibilities without removing them.
Encapsulation changes at each boundary
A sender passes application bytes to TCP, which adds a transport header to form a segment. IP adds a network header around that segment to form a packet. Ethernet wraps the IP packet in a link header and frame check sequence trailer to form a frame; the physical layer transmits encoded signals. In this room, segment means a TCP PDU, packet means an IP PDU, and frame means a link-layer PDU. UDP's transport PDU is normally called a datagram, not a TCP segment.
A router receives a local frame, checks and removes its link encapsulation, processes the IP packet and creates a new frame for the next link. Link addresses change at that boundary. Without address translation, source and destination IP addresses normally remain end-to-end, but the IPv4 TTL decreases and the IPv4 header checksum changes. At the receiving host, decapsulation exposes IP, then TCP, then application bytes; TCP reassembles the byte stream, so application messages need not align with segment boundaries.
For incident evidence, capture location matters. A frame observed on the first link does not prove that a router forwarded the packet onto the second. Retain interface, direction, timestamp and collection scope with captures, and correlate both sides when testing a forwarding control. An auditor asking whether prohibited traffic crossed a boundary needs observations at that boundary, not merely an endpoint's successful send call.
Link framing surrounds the IP MTU budget and is rebuilt at a routed hop.
MTU is a budget, not the application payload
An Ethernet IP MTU of 1500 means the link can carry an IP packet of at most 1500 bytes without fragmentation at that size boundary. It does not mean 1500 TCP data bytes. With a 20-byte IPv4 header and a 20-byte TCP header, no options and no tunnel, the TCP data budget is 1500 − 20 − 20 = 1460 bytes. That is the familiar TCP maximum segment size, or MSS, for these assumptions. The ordinary Ethernet header and trailer sit outside this IP MTU calculation.
Header sizes are assumptions to verify. TCP options consume more packet space, so a packet with a 32-byte TCP header and the same IPv4 header has room for only 1448 TCP data bytes at this MTU. IPv6 has a 40-byte base header, yielding 1440 with a basic TCP header and no extension headers. TLS record overhead consumes part of TCP's data budget, leaving fewer bytes for application content. A tunnel also consumes underlay packet space. MSS is advertised in TCP connection setup and is not a measurement proving that every hop supports the same MTU.
An oversized IPv4 packet with Don't Fragment set must be dropped rather than fragmented by a router whose outgoing MTU is too small; an ICMP fragmentation-needed message can inform path MTU discovery. IPv6 routers do not fragment transit packets and use ICMPv6 Packet Too Big messages. Filtering those messages can leave small exchanges working while bulk transfers stall. For availability assurance, retain interface MTUs, header assumptions, relevant ICMP observations and large-transfer test results; ask whether testing exercised more than a tiny probe.
Collect evidence where the decision lives
At OSI 1, link status and physical error measurements support a connectivity investigation. At OSI 2, frame errors, link address tables and local captures illuminate local delivery. At OSI 3, route tables, IP captures and ICMP messages explain reachability and MTU feedback. At OSI 4, TCP flags, sequence numbers, retransmissions and port-filter logs explain connection behavior. A completed three-way handshake establishes transport reachability at that time; it does not establish encryption or an application's access decision.
For OSI 5-7 responsibilities, use session lifecycle records, TLS negotiation or endpoint configuration evidence, and application request and authorization logs. In the four-layer TCP/IP model these fall within application. TLS capture metadata can show a negotiation, but ciphertext alone does not reveal whether a user could access only permitted records. An application log tying subject, resource, action and allow/deny result to a request identifier is stronger evidence for that authorization claim. Protect captures because plaintext traffic and metadata may expose sensitive information.
An auditor should ask: 'Which control assertion does this artifact support, where was it collected, and what does it fail to show?' Correlate UTC timestamps, collection points and request or connection identifiers across layers, documenting clock uncertainty and any translation or proxy boundary. Scope capture filters, restrict access and apply retention limits. A route table supports configured routing; a timestamped test and matching boundary observations are needed to demonstrate operation during the test window.
Tasks
Answers are graded on the server: the answer key never reaches your browser.
Task 1: The seven-layer inventory
Scenario sim+40 XP
Read the brief and answer both questions.
Incident brief
Halcyon's assessor asks for a four-layer TCP/IP diagram. The analyst copies the seven OSI boxes, labels the result TCP/IP, and insists that TCP port filtering belongs to the internet layer. The filter actually matches destination port 443, while a separate rule matches the destination IP address.
Term bank, not all of these are right
47transportinternet
1.1How many layers should the requested TCP/IP diagram contain? (a number)
1.2Which TCP/IP layer owns the destination port field? (one word)
Task 2: The disappearing frame
Scenario sim+40 XP
Read the brief and answer both questions.
Incident brief
A technician says a router forwards the original Ethernet frame unchanged from one routed interface onto another. The capture instead shows a new link header around the forwarded IP unit. No address translation occurs; the IP addresses are unchanged, although TTL has decreased.
Term bank, not all of these are right
framepacketsegmentdatagram
2.1Which PDU names the Ethernet unit replaced at the routed hop? (one word)
2.2Which PDU names the IP unit carried inside that Ethernet unit? (one word)
Task 3: A payload budget is not an access decision
Scenario sim+40 XP
Read the brief and answer both questions.
Incident brief
An engineer proposes 1500 TCP data bytes per packet on a 1500-byte IP MTU path with 20-byte IPv4 and 20-byte TCP headers, no options and no tunnel. She also says a completed TCP handshake proves the application denied an unauthorized record read. The investigator must calculate the actual maximum TCP data size and select the evidence source for the access decision.
Term bank, not all of these are right
14601500application logstransport logs
3.1What is the maximum TCP data size under these assumptions, in bytes? (a number)
3.2Which listed log source should record the record-read authorization result? (two words)
Labs
80 bonus XP
Hands-on work. You edit the artefact, the server runs the checks: the expectations and the reference solution never reach your browser.
Halcyon's upload investigation has a draft claiming that link framing uses the TCP data allowance and that connection establishment proves record authorization. The lead asks you to turn it into a small, machine-checkable diagnostic plan, not to change production networking.
Use the fixture's explicit header assumptions. Complete the model mapping, PDU labels and payload budget, then select a source that records application authorization decisions and reject the handshake-only proof claim. Keep the YAML structure; all blank fields require values.
Upload path and control assertion
model: four-layer TCP/IP
path: client -> router -> service
ip_version: 4
ip_mtu_bytes: 1500
ipv4_header_bytes: 20
tcp_header_bytes: 20
options: none
tunnel: none
control: unauthorized record reads must be denied
available_sources:
- application authorization logs (subject, resource, decision)
- transport connection logs (ports, flags)
draft_claim: handshake success proves record authorization
The incident lead has assembled six statements for an availability and access-control report. She asks you to accept them all because the portal is reachable again. Judge each statement on its technical claim, not on the restored service status.
Reject incorrect statements using exactly one best-fit reason code. The codes distinguish model confusion, a wrong PDU, an incorrect byte budget and an unsupported evidence claim. Accept precise statements even when they describe only limited evidence.
Verdicts are accept or reject. Every rejection needs one reason code from: model-confusion | wrong-pdu | byte-budget | unsupported-claim.
Report statements for review
NM-1: In the four-layer TCP/IP model, OSI session and presentation responsibilities fall within application.
NM-2: TCP ports belong to the TCP/IP internet layer because the connection crosses routers.
NM-3: The Ethernet unit is a TCP segment; the router preserves its original Ethernet header on the next routed link.
NM-4: With MTU 1500, IPv4 header 20 and TCP header 20, no options or tunnel, the maximum TCP data is 1500 bytes.
NM-5: A completed TCP handshake proves the application denied unauthorized record reads.
NM-6: A boundary capture with interface and time can support a forwarding test; it does not by itself prove application authorization.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Checks
Every line in the fixture carries a verdict
Accept and reject land on the right lines
Each rejection cites a valid reason code
Next on your path · Networking Fundamentals
Ethernet, Switching and VLANs
Trace Ethernet forwarding, diagnose ARP deception and loops, and distinguish VLAN separation from enforceable access policy.
