How can a forged IPv4 ICMP Redirect (type 5) divert a host's traffic, and why do hardened hosts ignore Redirects?
answer
- router advice to on-link hosts
- the Gateway Internet Address field
- checks compare addresses, prove nothing
- attacker names itself as next hop
- router still forwarded the packet
basics
~20 sAn ICMP Redirect tells a host to use another next hop for a destination. Its checks only compare addresses, so an attacker on the same subnet can forge one naming itself as gateway; ignoring Redirects costs at most an extra hop.
solid answer
~50 sA router sends a type 5 Redirect when it forwards a packet back out the interface it arrived on and the sender is on the same subnet as the better next hop (RFC 1812 §5.2.7.2). RFC 1122 says a host MUST update its route for the destination, and SHOULD discard a Redirect only if the new gateway is not on the same subnet or the Redirect's source is not its current first-hop gateway. Those checks compare addresses, and IPv4 source addresses are not authenticated, so an attacker on the link can forge a Redirect that appears to come from the gateway and name its own address as the new next hop, putting itself in the middle; an unused address black-holes the traffic instead. Hardened hosts ignore Redirects because the router that sent one also forwarded the packet, so ignoring it costs only a slightly longer path.
go deeper
Recall that a Redirect is a router's message to a host on the same link suggesting a better next hop, and that attackers can forge it.
Explain when a router sends type 5, what the Gateway Internet Address field does, and which RFC 1122 checks a host applies and why they do not prove authenticity.
Show the hardening judgment: disable Redirect acceptance on servers with designed routing, drop inbound Redirects at the edge, and explain why the cost is one extra hop rather than an outage.
Weigh convenience against trust: Redirects optimise flat multi-router subnets but grant every on-link node routing influence; argue for designs where hosts never need them.
## What a legitimate Redirect does An **ICMP Redirect** (type 5, RFC 792) is a router's advice to a host on the same link: "for this destination, send to that other router instead." A worked trace, using documentation addresses: 1. Host `192.0.2.10` has default gateway **R1** at `192.0.2.1`. A second router, **R2** at `192.0.2.2`, on the same subnet, is the better path to `198.51.100.0/24`. 2. The host sends a datagram for `198.51.100.7` to R1. 3. R1 looks up its routing table: next hop R2, out the **same interface** the datagram arrived on, and the sender is on R2's subnet. 4. R1 **forwards the datagram to R2 anyway** (RFC 792: the gateway forwards the original datagram's data) and sends the host a Redirect, code 1 (redirect for host), whose **Gateway Internet Address** field is `192.0.2.2`. 5. The host installs a route for `198.51.100.7` via `192.0.2.2`; later datagrams skip R1. ## The rules around the message | Rule | Source | |---|---| | Codes: 0 network, 1 host, 2 type of service and network, 3 type of service and host | RFC 792 | | Routers MUST NOT send codes 0 and 2, because subnetting and CIDR make the mask of a network Redirect ambiguous | RFC 1812 §5.2.7.2 | | A router sends a Redirect only if the packet leaves by the interface it arrived on, the source is on the same subnet as the next hop, and there is no source-route option | RFC 1812 §5.2.7.2 | | A host SHOULD NOT send Redirects; a host receiving one MUST update its routing | RFC 1122 §3.2.2.2 | | A host SHOULD silently discard a Redirect if the new gateway is not on the same connected subnet, or if its source is not the current first-hop gateway for that destination | RFC 1122 §3.2.2.2 | | A router running a routing protocol MUST NOT use paths learned from Redirects | RFC 1812 §5.2.7.2 | The message itself carries the type, code, checksum, the new gateway's address, and the original datagram's IP header plus its first 64 bits of payload. The host uses the destination in that quoted header to decide which route to change. ## How the forgery works Nothing in the message proves which router built it. The ICMP checksum detects corruption, not authorship, and the IPv4 source address can be written by anyone who can put a packet on the link. An attacker at `192.0.2.66` on the same subnet: 1. learns the victim's gateway (it is usually obvious from the subnet's addressing or from traffic on the link) and picks a destination the victim talks to, such as its DNS resolver; 2. forges a Redirect with **IP source `192.0.2.1`** (the real gateway), code 1, **Gateway Internet Address `192.0.2.66`**, and a quoted header for a datagram from the victim to that destination; 3. the victim's checks pass: the source matches its current first hop, and the new gateway is on its own subnet; 4. the victim now sends that destination's traffic to `192.0.2.66`, which can read or alter it and pass it on to the real gateway: a **man-in-the-middle**. Naming an unused address instead makes the traffic vanish: a **black hole**. RFC 1122 does not require the host to check that the quoted datagram is one it really sent, so the attacker does not need to observe the victim's traffic to build one. ## Why hardened hosts ignore Redirects - **The cost of ignoring them is small.** R1 forwarded the original datagram and keeps forwarding later ones; the host's traffic still arrives, just via one extra hop across the same link. - **Many hosts gain nothing from them.** A server with a single gateway, or a pair of routers sharing one virtual gateway address, never needs a better next hop. - **Routers already distrust them.** RFC 1812 forbids a router running a routing protocol from acting on Redirects, because believing one that contradicts its routing information could create loops. - **It is a deliberate departure.** RFC 1122 says a host MUST update its routing on a Redirect; turning acceptance off is an implementation and operations choice that knowingly sets that rule aside. - **At an edge it is simpler still:** a genuine Redirect only ever comes from an on-link router, so one arriving from the Internet is forged and the firewall should drop it. ## The IPv6 counterpart IPv6 moved Redirect into Neighbor Discovery (ICMPv6 type 137). RFC 4861 requires a link-local source address and a hop limit of 255, which proves the message was not forwarded by a router, so an off-link sender cannot forge one; an attacker on the link still can. RFC 4890 asks administrators to take an explicit policy decision about it. ## Common misconceptions - That Redirects are authenticated or come only from real routers. - That a host must reject a new gateway on its own subnet; the rule is the opposite. - That ignoring Redirects breaks reachability; it only lengthens the path.
- If an IPv4 host ignores a legitimate ICMP Redirect, does its traffic to that destination fail?No. The router that sent the Redirect also forwarded the original datagram, as RFC 792 describes, and it keeps forwarding later ones. Each packet simply crosses the link twice, host to R1 and R1 to R2, adding one hop and some load on R1. The router may keep sending Redirects, which RFC 1812 says it SHOULD be able to rate-limit.
- Why do IPv4 routers no longer send network Redirects (codes 0 and 2)?RFC 1812 forbids them. A network Redirect names a destination network without a mask, and with subnetting and CIDR the receiving host cannot know which mask applies, so the advice is ambiguous. Routers must send only host Redirects (code 1) or host-and-type-of-service Redirects (code 3). RFC 1122 still requires hosts to accept both kinds.
saying these in an interview costs you the question
- Redirects are authenticated, so only the real gateway can send one.
- A host must reject any Redirect whose new gateway is on its own subnet.
- Ignoring Redirects breaks connectivity to the redirected destination.
- Routers should update their routing tables from Redirects they receive.
- A forged Redirect from anywhere online can steer a host to an off-link gateway.