Network Protocols Deep Dive — ARP, DHCP, ICMP, DNS, HTTP and the Trust They Assume

Last updated: May 1, 2026

A “protocol” is just an agreed format for messages between two machines. The trouble is that most of the protocols still keeping the Internet running were designed in an era of trust — the campus LAN at MIT in 1982, the early ARPANET, where everyone knew everyone. None of the original specs imagined adversaries. ARP, DHCP, ICMP, DNS, NTP — every one of them has been weaponised, and yet they still run unauthenticated on most networks because the alternative is too disruptive. This module walks through each protocol the way an attacker reads it: what does it assume, where does the trust break, and what does a defender do?

ARP — the protocol that has no security at all

Address Resolution Protocol maps Layer 3 (IP) to Layer 2 (MAC) on a LAN. Host A wants to send to 192.168.1.1; A broadcasts an ARP request “who has 192.168.1.1?”; the holder replies “I do, my MAC is aa:bb:cc:dd:ee:ff.” That reply is unauthenticated, untimestamped, and cached for minutes. ARP poisoning works by simply replying first or replying repeatedly, claiming you are the gateway. The victim now sends all off-LAN traffic to you. Every Layer 2 MITM tool — Ettercap, bettercap, Cain and Abel from the old days — is just an ARP poisoner with a TLS-stripping front-end.

DefencesDynamic ARP Inspection (DAI) on managed switches, Static ARP entries on critical hosts, and 802.1X with MACsec for high-trust environments. Most enterprises run none of these and rely on “the LAN is trusted” — a 1990s assumption that BYOD and IoT devices have made indefensible.

DHCP — discovery on a hostile network

Dynamic Host Configuration Protocol gives you an IP, subnet mask, gateway, and DNS server when you join a network. The exchange (DORA: Discover, Offer, Request, Acknowledge) is broadcast and unauthenticated. A rogue DHCP server can hand out its own gateway and DNS, instantly MITM-ing every new client.

Real attackcorporate guest Wi-Fi often has a printer or test device left on with DHCP-server enabled — every device that joins gets the printer’s gateway.

DefencesDHCP Snooping on switches, only allowing DHCP responses from the trusted server port; DHCP Authentication (RFC 3118) is rarely deployed. Newer protocols (DHCPv6, ND in IPv6) have their own ND-Spoofing and RA-Guard concerns — see Module 7 for the IPv6 angle.

ICMP — the diagnostic that is also a covert channel

ICMP carries ping (Echo Request/Reply, types 8/0), traceroute (TTL exceeded, type 11), unreachable notifications (type 3), and a stack of legacy types nobody uses. Important defensive nuance: do not block ICMP wholesale. Type 3 Code 4 (“fragmentation needed but DF set”) is required for Path MTU Discovery; blocking it causes the famous “VPN works, but large web pages hang” symptom.

Attack usesICMP tunnelling (icmpsh, ptunnel) wraps a TCP shell inside Echo packets — invisible to most port-based firewalls. Smurf attack (broadcast ping amplification) is a 1990s relic but the technique generalises to modern reflection attacks.

Defencesrate-limit ICMP at the perimeter, log Echo Request/Reply pairs and look for unusual payload sizes (normal ping is 64 bytes; a 1400-byte ping is suspicious).

DNS — the most attacked protocol on the Internet

DNS turns names into IPs. It is unauthenticated by default, mostly unencrypted, and rides on UDP/53 (with TCP/53 for large responses). The threat surface is enormous: cache poisoning (Kaminsky, 2008), DNS hijack via registrar compromise (Sea Turtle, DNSpionage), DNS amplification (most large DDoS), DNS tunnelling for C2 (DNScat2, Iodine), and typosquatting.

Modern defencesDNSSEC signs records (low adoption — ~10% globally); DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT) encrypt the transport (now default in major browsers and OSes, though they bypass enterprise DNS filtering); split-horizon DNS for internal vs external resolution.

For SOC defendersa single DNS sensor (Zeek, dnstop, Splunk Stream) catches more lateral movement and exfiltration than three intrusion detection systems combined. Module 9 covers DNS attacks and tunnelling deeply.

NTP — clock skew, amplification, and identity

Network Time Protocol synchronises clocks. Every Kerberos ticket, every TLS certificate, every signed log timestamp depends on accurate time. NTP itself runs on UDP/123 and was historically unauthenticated. Two security concerns:

HTTP — the application protocol you must know cold

HTTP is request/response. Method (GET, POST, PUT, DELETE, PATCH, OPTIONS), URL, headers, optional body. The “complete” HTTP grammar fits on two pages and yet HTTP request smuggling, cache deception, host-header injection, and parser confusion are still finding new variants every year. Modern web traffic is mostly HTTP/2 (binary, multiplexed) or HTTP/3 (over QUIC over UDP). The semantics — methods, headers, status codes — are unchanged; only the framing differs.

Most useful headers for securityHost (the virtual host requested), X-Forwarded-For (proxy chain — never trust without normalising), User-Agent, Authorization, Cookie, Content-Type, Origin (CORS), Strict-Transport-Security (HSTS — defends against TLS downgrade). The Web App track goes deeper; this module just makes sure you can read an HTTP exchange in Wireshark or curl without being lost.

TLS — the only application-layer protocol that defends itself

TLS provides confidentiality, integrity, and authentication on top of TCP. It is the only protocol on this list designed under the assumption of an active attacker. The handshake negotiates a cipher suite, exchanges certificates, and derives a shared secret — Module 10 walks the TLS 1.3 handshake byte by byte. The two facts that matter for this module:

How protocol fuzzing reveals the weak spots

Protocol implementations have hundreds of edge cases — malformed lengths, unexpected option combinations, oversized fields. Fuzzing tools (boofuzz, AFL++, Mutiny) generate millions of slightly-broken inputs and watch for crashes, memory errors, or unexpected responses. Real-world impact: most CVEs in network protocol implementations (DNS resolvers, NTP daemons, SSH parsers) were found by fuzzing. For defenders, the lesson is to treat every protocol parser as untrusted — sandboxing, memory-safe languages (Rust nginx-equivalents, Cloudflare’s pingora), and continuous integration of fuzzing into release pipelines all reduce the blast radius of inevitable bugs. For pentesters, fuzzing internal services (proprietary RPC, custom binary protocols) often finds quick wins where automated scanners give up because they do not understand the protocol grammar. Boofuzz has well-documented templates; tooling is the easy part — knowing what to fuzz comes from reading the protocol RFC carefully.

Protocol design lessons — what good protocols look like

Modern protocol design has converged on a few principles that defenders should recognise as positive signals:

A practical lab for protocol observation

Spend an afternoon with a single Linux VM and you can observe every protocol in this module live. tcpdump -i any -nn -X port 53 shows DNS resolution requests/responses byte by byte. tcpdump -i any -nn arp shows ARP requests on your LAN. tcpdump -i any -nn icmp with concurrent ping shows ICMP types. nmap --packet-trace -p 80 target shows TCP handshake packets being sent. Modify /etc/hosts to MITM a hostname and capture the resulting connection — you will see the unauthenticated trust break in action. Run arping -c 3 192.168.1.1 and watch the broadcast.

The exercisefor each of the seven protocols in this module, capture a real exchange, identify the field that defines its trust model, and articulate what an attacker might do to abuse it. By the time you finish you will have a working understanding deeper than most senior engineers — because most senior engineers never spent an afternoon staring at packets.

Diagrams

Client                                          DHCP server
  | -- DISCOVER (broadcast)  ----------------------> |
  | <- OFFER     (offers 10.0.0.42 / 24, gw, dns) -- |
  | -- REQUEST  (I want 10.0.0.42 from this server) ->|
  | <- ACK      (lease confirmed, 8 hour expiry) -- |

A rogue DHCP server racing the legitimate one with a faster
OFFER replaces gateway/DNS for the new client — instant MITM.

Before:
  Victim ── (ARP cache: GW=mac-real) ──▶ Real Gateway

Attacker sends unsolicited ARP Reply:
  "192.168.1.1 is at mac-attacker"

After:
  Victim ── (ARP cache: GW=mac-attacker) ──▶ Attacker ──▶ Real Gateway

Victim believes it is talking to the gateway.
Attacker forwards traffic, captures plaintext,
strips TLS where possible (sslstrip), tampers responses.

References & deeper reading

• RFC 826 — ARP
• RFC 2131 — DHCP
• RFC 792 — ICMP
• RFC 1035 — Domain Names (DNS)
• RFC 7766 — DNS over TCP best practice
• RFC 9000 — QUIC
• NPL India authenticated NTP
• Cloudflare DNS-over-HTTPS

FAQ

Is ARP poisoning still relevant in 2026?

On managed corporate LANs with DAI and 802.1X — rare. On guest Wi-Fi, untrusted office networks, and most SMB environments — extremely common because the defences require switch capabilities most networks do not enable. Pentesters reach for it on day one of an internal engagement.

Why is DNSSEC adoption so low?

Operational complexity. Key rollovers go wrong; misconfigurations create days-long outages (.gov took down its zone twice). The benefit is invisible (preventing a Kaminsky-style attack you would never detect anyway) so the operations team has no incentive. DoT/DoH solved most of the practical attack surface for users without DNSSEC.

Should we block DoH on our corporate network?

It depends. If you rely on DNS-based filtering (Umbrella, Quad9), you must either block DoH at the perimeter (Cloudflare, Google’s DoH endpoints are well-known) or push browser policy to use your enterprise DoH endpoint. The right answer in 2026 is the latter; outright blocking is increasingly arms-race because every messaging app embeds its own resolver.

Why does ICMP keep showing up in pentest reports?

Because it is a covert channel, a fingerprinting tool, and an information leak all in one. Pingsweeps still find live hosts; ICMP type 13/14 leak system uptime; ICMP fragments leak OS family; tunnelled C2 over ICMP is invisible to many port-based firewalls. Defenders should not block ICMP, but should profile expected ICMP and alert on outliers.

How does HTTP/2 change my visibility?

A lot. Single TCP connection multiplexes many requests; headers are HPACK-compressed; priority and dependencies add complexity. Tools that grep for “GET /admin” in raw bytes break. The good news: Wireshark, Zeek, and modern WAFs all dissect HTTP/2 properly — but middle-boxes that did regex matching on HTTP/1.1 must be upgraded or replaced.

Should I block legacy protocols entirely?

Audit them, then decide. FTP, plain SMTP, plain LDAP usually have authenticated/encrypted alternatives (SFTP, SMTP+STARTTLS, LDAPS). Migrate; once nothing legitimate uses the legacy protocol, block at the perimeter. Blocking before the migration breaks production.

How do I monitor for unauthorised protocols?

Zeek’s protocol detection logs (conn.log + protocol-specific logs) reveal what is actually running. Periodically diff against your “approved protocols” list; investigate every newcomer. This is one of the highest-leverage hunting queries available.

⚖️ Legal: Use any techniques described here only on networks you own or have explicit written authorisation to test. In India, unauthorised access is punishable under IT Act §66 (up to 3 years + fine). Pair offensive testing with a signed Statement of Work / Rules of Engagement; pair forensic activity with §65B-aligned chain of custody.