Why is a source-IP allowlist on a UDP control service not an authentication control?

## The wrong answer this question exists to catch A competent senior engineer, asked whether an internal service is exposed, will often say: *it only accepts traffic from the application subnet, so it is fine.* The sentence sounds like an access-control statement. It is not. It is a statement about a field that the sender fills in. Spell the mechanism out. The service receives a datagram, reads the source address out of the header, compares it to a configured range, and if it matches, processes the payload. The attacker also fills in the source address in the header. They are being asked to supply the credential and then being checked against the credential they supplied. The only thing standing between a forger and the service is whether their originating network will forward a packet bearing somebody else's address — a property of a network the target does not control and cannot see. ## Why connectionless makes it total Over a connection-oriented transport there is at least a round trip, and an off-path forger cannot survive it. Over a connectionless one there is nothing. The datagram's effect is complete on arrival: the setting is changed, the entry appended, the operation triggered. Any answer the service generates is addressed to the value in the source field, so it travels to the real owner of that address, which drops it as unsolicited. The attacker does not need it and never wanted it. This is the pure one-way case — no session, no foothold, no account, just an effect they caused and cannot observe. So when someone says the service is protected because it is UDP and internal, they have named the two conditions that make the protection weakest, not strongest. ## The TCP nuance, which is worth getting right In front of a TCP service, a source allowlist does raise the bar: to complete the handshake the peer must receive the server's SYN-ACK, so an off-path attacker cannot get in. Do not overclaim from that. What has been demonstrated is that the peer can receive traffic at the allowed address — which is satisfied by anyone on-path, by any compromised host inside the allowed range, and by anything that can influence where that address's traffic goes. It is a reachability proof, not an identity proof, and it has no message integrity attached: it says nothing about whether the payload was tampered with, and gives no basis for attributing a command to a particular caller afterwards. ## The population problem An allowlisted address is rarely one machine. If it is a shared egress address — a translation gateway, a proxy, an outbound cluster — the entry vouches for every host behind it. The real subject of the control is a population, and the population grows without anyone revisiting the allowlist. This is the failure that shows up in review as *we restricted it to the office range* on a range that includes several hundred laptops. ## Say what it is, then add what is missing | The check establishes | The check does not establish | | --- | --- | | The packet carried an allowed value | That the sender holds any secret | | Casual traffic is filtered out | That the payload was not altered | | Exposure is narrowed | Who issued the command | The honest replacement, when the service cannot move to an authenticated transport, is a per-message authenticator: a keyed code computed over the message body with a nonce or timestamp so replays are rejected, using a key each legitimate caller holds and the header does not carry. Where the transport can be changed, a mutually authenticated one gives the same property plus confidentiality and ordering. In either case the allowlist stays — as an outer filter that shrinks exposure and keeps noise off the service — but it stops being the thing that decides who may issue a command. ## How to answer this in an interview The strongest version of the answer does three things: it identifies the field as attacker-supplied input; it explains why the connectionless case removes even the accidental protection a handshake would have provided; and it re-labels the control rather than simply condemning it. Engineers who only say *IP allowlists are bad* tend to lose the argument with the team that built the service, because the allowlist really is doing something useful. Engineers who say *this is exposure reduction, and here is what we still need for authentication* tend to get the change made.