# AS1 Experiment Report ## 1. Initial Reconnaissance **Actions:** - `ip addr show lo` → discovered my stable loopback is **4.2.2.1/32**. - `ip route show` → inventoried the pre-existing routing table. **Justification:** Per the briefing, the loopback is the only address remote nodes can route back to. Knowing it and the existing routing state was a prerequisite for any further work. **Discovery:** Default route already pointed at AS2 (10.0.2.2). One route was immediately suspicious: `198.82.0.1 via 10.0.5.2 dev AS1-eth2` (i.e., ACM via EveLink), which contradicted my briefing ("ACM is reachable through AS2"). ## 2. Initial Reachability Check **Actions:** - `ping -c 2 -I 4.2.2.1 198.82.0.1` → succeeded, RTT 20ms, **TTL=64**. - `ip route get 198.82.0.1` → confirmed kernel was sending via EveLink. **Justification:** Before drawing conclusions I wanted direct evidence of what was actually happening on that path. The result (TTL=64 from a supposedly remote destination at only 20ms) was a strong indicator that EveLink — or a host on EveLink's link — was answering as 198.82.0.1 directly, i.e. a hijack-by-impersonation. ## 3. Routing Setup from Neighbor Advertisements Uni and AS2 sent prefix advertisements. I installed: ``` ip route add 128.173.10.1/32 via 10.0.1.1 dev AS1-eth0 # Uni's new customer prefix ip route add 154.54.1.1/32 via 10.0.2.2 dev AS1-eth1 # AS2 loopback ip route del 198.82.0.1 via 10.0.5.2 dev AS1-eth2 # remove the hijack route ip route add 198.82.0.1/32 via 10.0.2.2 dev AS1-eth1 # ACM via AS2 (correct) ip route add 198.82.0.254/32 via 10.0.2.2 dev AS1-eth1 # ACM's second prefix ``` **Justification:** - Uni is a paying customer, so its advertised prefixes (its loopback and a user host) get installed and propagated. - AS2 independently advertised 198.82.0.1 and 198.82.0.254 as originated by its customer ACM — this matches my prior operational knowledge and is consistent with normal customer-of-peer signaling. I therefore replaced the suspicious EveLink route with the legitimate AS2 path. - Re-pinging via the new path gave **TTL=62, 74ms RTT** — consistent with a real multi-hop destination, confirming the AS2 path is the genuine origin and the EveLink path was an impostor. ## 4. Engaging EveLink Sent a message asking EveLink to declare its legitimate prefixes and flagging the suspicious ACM route I removed. EveLink responded claiming both: - `91.214.0.0/24` (its own infrastructure — plausible, contains its loopback 91.214.0.1) - `198.82.0.0/24` (claimed as "EveLink customer block; 198.82.0.1 hosted on my network") EveLink explicitly asked me to reinstate the route to 198.82.0.0/24 via them. **Decision:** Accept 91.214.0.0/24, reject 198.82.0.0/24. ``` ip route del 91.214.0.1 via 10.0.5.2 dev AS1-eth2 # remove redundant /32 ip route add 91.214.0.0/24 via 10.0.5.2 dev AS1-eth2 # install the /24 ``` **Justification for rejection** — multiple independent lines of evidence: 1. Briefing says ACM/198.82.0.1 is behind AS2. 2. AS2 independently advertises 198.82.0.1 and 198.82.0.254 as ACM's prefixes. 3. The TTL evidence above proves the EveLink-side address was a local impersonator, not a real forwarded service. 4. EveLink is asking me to accept a /24 that covers another AS's customer prefixes without producing any LOA or RPKI ROA. Per the briefing, security/policy decisions of this magnitude warrant flagging admin attention, which I did in the reply to EveLink and in my notification to AS2. EveLink subsequently acknowledged and withdrew the claim. ## 5. Peering Exchange with AS2 Sent AS2 my loopback (4.2.2.1/32) and the customer-prefix list I'm willing to carry traffic for: - `4.2.2.1/32` (me) - `128.173.0.1/32`, `128.173.10.1/32` (Uni) - `91.214.0.0/24` (EveLink — legitimate part only) Also included a security report about the EveLink hijack attempt with the TTL evidence. AS2 confirmed installation and stated it will reject 198.82.0.0/24 from any source other than ACM. **Justification:** This honors the peering relationship (settlement-free, advertise my customers only, not AS2's own routes back to AS2) and operationalizes the security report through the Knowledge Plane. ## 6. End-to-End Verification Ran pings from 4.2.2.1 to every learned prefix: 128.173.0.1, 128.173.10.1, 91.214.0.1, 154.54.1.1, 198.82.0.1, 198.82.0.254. All succeeded, 0% loss, with TTLs consistent with the expected number of hops (TTL=64 for direct neighbors, TTL=62/63 for further destinations). **Justification:** The briefing demanded that fixes be verified directly before reporting success. I confirmed not just reachability but path correctness via TTL inspection. ## 7. Knowledge-Plane WHY from Uni Uni reported that a user behind it (128.173.10.1) had transiently failed to reach 198.82.0.1 on TCP/80 and /443, with these symptom traits during the failure: - ICMP succeeded, ~44ms, **TTL=62 on replies**, 4-hop path - TCP RST (Connection refused) instantly on both ports - DNS unaffected - Symptom cleared on its own; the path that now works is 5 hops via AS2. **Diagnosis (high confidence, evidence-based):** The transient was exactly the tail end of the EveLink hijack I had just mitigated. Specifically: - The user's 4-hop / TTL=62 / ~44ms path matches `Uni → AS1 → EveLink → impostor on EveLink's link` — one hop fewer than the genuine 5-hop AS2 path. - ICMP-replying-but-TCP-refusing is the textbook fingerprint of a hijack decoy: the IP is up on someone's loopback, but no real HTTP/HTTPS service is listening, so the kernel sends RST immediately. It is *not* an on-path RST injector — those would let the SYN reach a real listener first. - DNS was unaffected because the resolver (me, 4.2.2.1) is on a different prefix; the hijack only covered 198.82.0.0/24. I replied to Uni with this diagnosis and the resolution timeline, and explained that recurrence is low but not zero (the policy is enforced by my own discipline rather than RPKI on this testbed). ## 8. What I Discovered About the Network - The network is a small multi-AS topology with AS1 (me) sitting between customer Uni, customer EveLink, and peer AS2. ACM sits behind AS2. - I had a pre-existing misconfiguration/hijack route at start: 198.82.0.1 pointed at EveLink, who was actively impersonating ACM's web server. - The hijack was not subtle from a KP vantage: route policy, TTL evidence, and AS2's independent advertisement all converged on the same conclusion. - The user-visible symptom (transient HTTPS failure) at Uni was a direct consequence of the hijack, and the user's observations (TTL, hop count, RST timing) were perfectly diagnostic once correlated with my routing-table state. ## 9. Coordination with Other Agents - **Uni (customer):** Received their prefix advertisement, installed routes, acknowledged. Later received their KP WHY and responded with a full evidence-based diagnosis attributing the symptom to the EveLink hijack of 198.82.0.0/24. - **AS2 (peer):** Exchanged loopbacks and prefix lists; installed their routes; provided them my customer-prefix list. Reported the EveLink hijack with evidence (TTL=64 vs. TTL=62). AS2 alerted ACM directly and stated its policy will reject 198.82.0.0/24 from any source other than ACM. - **EveLink (customer):** Solicited a prefix list. Accepted their legitimate /24 (91.214.0.0/24). Rejected their hijacking advertisement of 198.82.0.0/24 with a clear evidence-based explanation. EveLink acknowledged and withdrew. ## 10. Summary of Final State ``` default via 10.0.2.2 (AS2) 4.2.2.1/32 (my loopback) 128.173.0.1/32 via 10.0.1.1 (Uni) 128.173.10.1/32 via 10.0.1.1 (Uni user) 91.214.0.0/24 via 10.0.5.2 (EveLink) 154.54.1.1/32 via 10.0.2.2 (AS2 loopback) 198.82.0.1/32 via 10.0.2.2 (ACM via AS2) 198.82.0.254/32 via 10.0.2.2 (ACM via AS2) ``` All goals from the briefing — transit revenue from Uni and EveLink, settlement-free peering with AS2, reliable customer transit, and KP collaboration — were satisfied. The only deviation from "accept what neighbors advertise" was the deliberate refusal to accept EveLink's hijack of ACM's prefix, justified by direct, reproducible evidence and confirmed by the legitimate origin's transit provider.