An egress ACL at your internet edge permits only your own source prefixes: what does it stop, and who benefits?
answer
- filter what you send, not what you receive
- the SOURCE field, not the destination
- BCP 38 applied at the customer edge
- the victim is somebody else entirely
- a stale prefix list drops real traffic
basics
~20 sIt stops hosts inside your network from putting forged source addresses onto the internet. The victim of that spoofing is almost always another network, so the filter mostly protects strangers while you pay to keep the prefix list accurate.
solid answer
~50 sAn egress ACL that permits only your allocated prefixes as a source address is the customer-edge form of BCP 38 source-address validation (RFC 2827). Traffic leaving toward the transit provider is matched on its SOURCE, not its destination: anything sourced outside the blocks you actually hold is dropped. The adversary it aims at sits inside your own estate - a compromised server, an infected laptop, a rented instance - emitting packets with a forged source so that replies, or a reflected flood, land on a third party. The uncomfortable part is the economics. Almost nothing it drops was ever going to hurt you, and the cost is entirely yours: a list somebody must update whenever you receive new address space or start carrying a partner prefix, plus a failure mode where a legitimate flow dies silently because that list went stale.
go deeper
Be ready to say which field the rule matches (the source address) and which direction it applies to (traffic leaving toward the provider), and to name who the beneficiary is: other networks, not yours.
Explain why forged source addresses are useful to an attacker at all - replies go to the forged address, and attribution is destroyed - and name the limit that a source inside your own prefixes passes the filter untouched.
Expect to be asked how the prefix list stays correct in a real estate: who owns it, how a new allocation or an acquired company's space reaches the edge before the traffic does, and how you find the flow that a stale entry silently killed.
Be ready to argue the control on grounds other than self-interest, since the benefit is external: reputational and contractual expectations from transit providers and peers, and the cost of being the network a stranger's flood was sourced from.
## The direction nobody watches Most people, asked about a firewall at the internet edge, describe what it refuses to let IN. Source-address validation is the other direction and the other field. It is a rule applied to traffic leaving your border toward your transit provider, and it matches on the SOURCE address of each packet: if the source is inside one of the prefixes your organisation actually holds, permit; otherwise drop. That single rule is the customer-edge expression of BCP 38 (RFC 2827, *Network Ingress Filtering*). The document is written from the provider's point of view - the provider filters what arrives from each customer - but the same list can be, and usually should be, enforced by the customer on the way out. Whoever applies it, the check is the same: does this packet claim to come from where it actually comes from? ## Who it is aimed at The adversary is on your side of the wire. A compromised server, a laptop with an implant, a rented instance in a subnet somebody forgot about - anything that can craft raw packets - sets a source address that is not its own. Two things become possible once it can do that. First, replies are redirected. A request the host sends is answered to the forged address, not back to the host. That is the basis of reflection: a small forged request to a service that answers with a much larger response, repeated, so that the answers pile onto the victim whose address was forged. The forging host never receives the reply and does not care. Second, attribution is destroyed. A flood arriving at somebody else's network carries source addresses that lead nowhere useful. Their operators chase an address that is not yours, and nothing in their logs points back at the host you actually own. ## What the filter is worth to YOU Honestly: very little, directly. The packets it drops were leaving. They were not going to exhaust your link, break your services, or steal your data. The victim of the traffic is somebody else's network entirely - a company you have never heard of, a game server, a hosting provider. This is the defining property of the control and the reason it is chronically under-deployed across the internet: the benefit is external and the bill is internal. The bill is not large but it is real and it is permanent: | What you pay | Why | | --- | --- | | Maintenance of the prefix list | Every new allocation, acquisition, or partner prefix you transit must be added, by hand, before the traffic appears | | Silent-drop risk | A stale list drops legitimate traffic with no error message; the symptom is a flow that just stops working | | A change process | The list lives on edge devices, so touching it is a change with a window, an approver and a back-out | | Someone to own it | An unowned list is a stale list within a year | Interviewers probe this because a candidate who has only ever thought about inbound protection will describe the rule as something that protects their own network. It does not. Saying so plainly - *this one is for other people, and here is what it costs me* - is the answer that lands. ## What it does NOT stop Three limits matter and a good candidate names them unprompted. 1. **Forgery inside your own space.** A host that forges an address belonging to another of YOUR prefixes passes the filter, because the source is legitimately yours. That is still enough to attack other hosts on your own networks and enough to redirect replies inside the estate. Catching it requires validation much closer to the host, at the access layer where the address assignment is actually known. 2. **Exits you did not filter.** The rule protects one path. A branch office with its own local internet breakout, a second transit edge inherited from an acquisition, a tunnel that leaves through a cloud account - each is an unfiltered door, and packets take whichever door their route says. 3. **Anything about the destination or the content.** Source validation says nothing about where a flow is going or what it carries. That is a different control with a different cost. ## The related rule pointing the other way There is a mirror-image filter that DOES protect you: on traffic arriving from the internet, drop anything whose source claims to be one of your own internal prefixes. Nothing legitimate arrives from outside claiming to be inside. It is cheap, it never breaks anything, and it is worth mentioning as the inbound counterpart - but it is a different rule in a different direction, and confusing the two is the classic junior slip.
- Does this ACL protect you from spoofed traffic arriving from the internet?No. It matches the source of traffic leaving you, so it says nothing about what arrives. The inbound protection worth having is the mirror rule: drop packets arriving from outside whose source claims to be one of your own internal prefixes, since nothing legitimate does that. Beyond that, filtering spoofed inbound traffic is mostly your provider's job, on their side of the link.
- An internal host forges a source address taken from another of your own prefixes. Does the ACL catch it?No, and this is the honest limit of the control. The source sits inside a permitted block, so the packet leaves. That is still enough to redirect replies to another host inside your estate, or to attack a neighbour on your own networks. Catching it needs validation at the access layer, where the actual address assignment for that port or segment is known.
- Why is maintaining the prefix list harder than it sounds?Because the list is a business fact, not a network fact. New allocations, an acquired company's address space, prefixes you have agreed to transit for a partner, a lab range someone stood up - each must reach the edge device before the traffic does. Nobody notices an over-broad list; a missing entry shows up as a flow that silently stops, often days later and reported as something else.
It is like a postal depot refusing to accept letters with a return address that is not on its own street. The depot gains nothing; the people who would have received the angry replies do.
saying these in an interview costs you the question
- Thinks an outbound source filter protects your own network from spoofing
- Matches on destination addresses and calls it source validation
- Claims it stops all spoofing, including forged addresses inside your own range
- Assumes the prefix list stays correct without an owner or a change process
- Cannot say who actually benefits from the control