Module 3 — The Broken Internet: NAT and the Art of Hole Punching

The Module 3 Examination

The two most compelling problems facing the IP Internet are IP address depletion and scaling in routing.— K. Egevang & P. Francis, RFC 1631, 1994

Plan on 90 minutes. Part A is code, graded by the harness with hints disabled and partial credit per assertion; it ends with a live loopback on a real RTCPeerConnection pair that must reach connected through signaling you write yourself. Part B is forensic scenario work on canned artifacts — logs, candidate tables, stats dumps. Part C is concepts and history, and, as every exam from Module 2 onward does, it reaches back with two spaced-review questions from earlier modules. The pass mark is 80 percent; retakes draw variants of these problems, so understanding beats memorizing the answer key.

AThe protocol bench

Three dry-bench problems, then a wet one. First you will script the decisions a controlling ICE agent makes — scheduling ordinary checks, honoring triggered checks, concluding with regular nomination — against four canned network scenarios. The contract below is a deliberately simplified slice of RFC 8445: pairs carry an id, a numeric priority, a state, and a nominated flag, and the agent object holds the checklist and the triggered-check queue.

// Shapes the grader passes to your functions:
//
//   pair  = { id: 'host-host', priority: 100,
//             state: 'waiting', nominated: false }
//   state is one of:
//     'frozen' | 'waiting' | 'in-progress' | 'succeeded' | 'failed'
//
//   agent = { checklist: [pair, ...], triggeredQueue: [pair, ...] }
//
// Contracts:
//   pairPriority(G, D)
//     G = controlling agent's candidate priority, D = controlled's.
//     Return a BigInt per RFC 8445 section 6.1.2.3:
//       2^32 * MIN(G,D)  +  2 * MAX(G,D)  +  (G > D ? 1 : 0)
//
//   nextCheck(agent)
//     Dequeue and return the head of triggeredQueue if non-empty;
//     else the highest-priority pair in state 'waiting';
//     else the highest-priority pair in state 'frozen';
//     else null. Never remove anything from the checklist itself.
//
//   handleBindingRequest(agent, pair)
//     A binding request arrived on this pair (a triggered check):
//     if the pair is 'succeeded', change nothing; otherwise set its
//     state to 'waiting' and enqueue it on triggeredQueue exactly once.
//
//   concludeRegular(agent)
//     Regular nomination: pick the highest-priority 'succeeded' pair,
//     set its nominated flag to true, and return it; return null
//     if no pair has succeeded yet.

Listing E3.1 — the agent contract for Problem 1.

Problem 2 hardens the candidate parser you wrote in § 3.4 against a nastier corpus: the candidate line as it appears in SDP, but now with IPv6 addresses, mDNS .local hostnames, an a= prefix, an uppercase transport token (Firefox emits UDP; Chrome emits udp), and TCP candidates carrying tcptype active on the discard port 9 (RFC 6544, 2012). Problem 3 is a STUN decode variant: raw bytes of binding success responses, in which you must validate the magic cookie 0x2112A442, walk the attribute list — no fixed offsets — and undo the XOR in XOR-MAPPED-ADDRESS. Recall the petty rationale from § 3.2: NAT application-layer gateways rewrote anything in a UDP payload that looked like an IP address, so RFC 5389 hid the address behind an XOR with the cookie: the port with the cookie's top 16 bits, the IPv4 address with all 32.

Part A — Coding, dry benchHints disabled · partial credit per assertion

Script the controlling agent, harden the parser, decode the bytes.

A′The live wire

Everything above is dead reckoning. Problem 4 is navigation: build two peer connections in the same page, wire trickled candidates across the gap yourself — every non-null icecandidate event on one side becomes an addIceCandidate() on the other — run offer/answer, and deliver a pair whose caller reaches iceConnectionState of connected or completed inside ten seconds. Remember § 3.5: the null candidate is the end-of-gathering sentinel, not an error, and must not be forwarded. On a loopback pair there is no NAT between the peers, so the selected pair will be host↔host and connection is fast; the ten-second budget exists to catch signaling wired backwards, not slow networks.

Part A — Coding, liveReal RTCPeerConnection · 10-second budget

Reach connected through trickle signaling you write yourself.

BScenario diagnostics

Three incidents and two judgment calls, all drawn from artifacts of the kind webrtc-internals and getStats put in front of you. Read each artifact before answering; every correct diagnosis is anchored to a specific line. The stats excerpts use the real field names of candidate-pair entries — requestsSent, responsesReceived, requestsReceived, responsesSent — and the counters are cumulative, as § 3.5's survival primer warned.

Artifact B-1 — a call stuck in checking, both peers' gathered candidates and the configuration.

peer A gathered:
  candidate:2880323124 1 udp 2122260223 192.168.1.7 51472 typ host
  (end of candidates)
peer B gathered:
  candidate:1052258767 1 udp 2122260223 10.0.0.23 60111 typ host
  (end of candidates)

iceConnectionState: new -> checking     (t + 0.2 s)
iceConnectionState: checking            (t + 15.0 s, unchanged)

configuration: { iceServers: [] }
signaling log: offer delivered, answer delivered, 2 candidates
               delivered in each direction

Artifact B-2 — the same application, two networks. It works on home Wi-Fi and fails on the corporate LAN.

-- home Wi-Fi (connects) --
  typ host   192.168.1.7
  typ srflx  203.0.113.7  raddr 192.168.1.7   (via stun:stun.example.org:3478)
  selected pair: srflx <-> srflx, state: succeeded

-- office LAN (fails) --
  typ host   10.40.2.19
  stun:stun.example.org:3478                -> timed out
  turn:turn.example.org:3478?transport=udp  -> allocation timed out
  turn:turn.example.org:3478?transport=tcp  -> connection refused
  iceConnectionState: checking -> failed

IT confirms: outbound TCP on 80/443 only, via proxy; all UDP dropped;
             all other outbound ports blocked

Artifact B-3 — candidate-pair stats from a call that connected, but 100 percent over the relay.

candidate-pair #1   local srflx 203.0.113.7:54321
                    remote srflx 198.51.100.9:62044
  state: failed        requestsSent: 47    responsesReceived: 0
                       requestsReceived: 0 responsesSent: 0

candidate-pair #2   local relay 192.0.2.15:49802
                    remote relay 198.51.100.44:52990
  state: succeeded     nominated: true     requestsSent: 9
                       responsesReceived: 9
                       requestsReceived: 8 responsesSent: 8

The last two questions in this part are judgment calls: recovering from a mid-call network migration, and a security review of what a DTLS-SRTP call actually exposes to the relay in the middle.

Part B — ForensicsFive scenarios, canned artifacts

Diagnose from the artifact; every answer is anchored to a line above.

CConcepts, history, and spaced review

Short answers on the ideas that make the machinery legible: the candidate type that is never gathered, the nomination mode that did not survive 2018, the seconds Trickle ICE bought back, and why a TURN-percentage dashboard is a line item in a budget meeting. Then the spaced review reaches back — to Module 1's argument for datagrams and RTP, and to Module 2's offer/answer algebra (RFC 3264, 2002).

Part C — ConceptsPooled bank

Four questions on this module's ideas.

Part C — Spaced reviewModules 1–2

Two questions from earlier modules, as promised.