Why can a layer-4 front end drop an attacker's request but never price it, while the service that can price it has already paid?
answer
- two vantages, neither complete
- the five-tuple says nothing about cost
- pricing requires parsing first
- cost is knowable only after work starts
- admission must move where price is visible
basics
~20 sDropping needs only addresses, ports and connection state. Pricing needs the parsed request and often the plan behind it, so by the time the cost is knowable the parse, the worker and possibly the transaction have already been spent.
solid answer
~50 sA layer-4 device decides from the five-tuple and connection state, and can discard a flow before a byte of application work happens - which is precisely why it is cheap and fast. Nothing in that view says whether the request behind the connection is a one-row lookup or a full-table export. Establishing that requires terminating TLS, parsing the request, resolving who is calling and often asking the datastore what the query will touch; by then you have paid the parse, held a worker and perhaps opened the transaction you wanted to avoid. So the estate has two vantages and neither is sufficient alone: the one that can drop cannot price, and the one that can price has already begun paying. Any honest answer moves the admission decision to a component that sees both, and accepts added latency on every ordinary request as the cost.
go deeper
Know what a layer-4 device decides on - addresses, ports, protocol and connection state - and that the request body, and therefore its cost, is not in that view.
Explain the split precisely: what each vantage can observe, and exactly what work has already been spent by the moment the cost becomes knowable.
Argue where you would place the admission decision in a real path, what it adds to every ordinary request, and how you keep the check itself off the shared datastore.
Be ready to say who takes on the new hot-path component and its failure mode once the control leaves the network boundary, and what you accept in exchange for that.
## Two vantages, each missing what the other has Every defence against an expensive-request attack runs into the same structural problem, and it is worth stating as a property of the path rather than as a shortcoming of any particular box. **The cheap vantage.** A layer-4 front end - a load balancer, a connection-terminating appliance, a stateful filter - decides from source and destination address, source and destination port, protocol, and the connection state it is tracking. That is enough to drop a flow before the application ever sees it, which is exactly why the decision costs microseconds and scales to enormous packet rates. It is also the complete list of what that device knows. The bytes after the handshake may be encrypted; even in the clear, this device is not in the business of reassembling and parsing them. **The expensive vantage.** The service knows the request. It knows the path, the parameters, the caller's identity and entitlements, the tenant, the date range being asked for. It can, in principle, estimate what answering will cost. But every one of those facts was produced by doing work: terminating TLS, reading and reassembling the stream, parsing the body, looking up the caller, sometimes asking the datastore for a plan. That work is not free, and on this class of attack it is a meaningful share of the damage. The parse is paid, a worker is occupied for its duration, and if the code opens a transaction or takes a connection from the shared pool before it inspects the request, the scarce resource is already committed. ## Why the cheap discriminators do not separate the traffic The tempting move is to find something the cheap vantage *can* see that correlates with expense. The cheap discriminators are who is asking, where they are asking from, and how often. On this attack none of them correlate: - The attacker's requests can arrive from a residential address range indistinguishable from a customer's. - A legitimate analyst pulling a quarterly export issues exactly the shape of request the attacker uses. - The same authenticated tenant sends both trivial lookups and ruinous reports, minute by minute. The expensive property - what *this particular request* will cost - is not a property of the caller. That is the deeper reason a source-based defence fails here, and it is why the discussion cannot be resolved by getting a better view of the client. ## What pricing actually requires Pricing sits on a spectrum, and the further right you go the more it costs to do and the more accurate it becomes: | Signal | Where it is available | What it costs to obtain | | --- | --- | --- | | Five-tuple, connection state | Layer-4 front end | Almost nothing | | Request shape: size, depth, field count | After parse | A parse, plus buffering | | Declared operation and parameters | After parse and route | Parse plus routing | | Caller entitlements and tenant limits | After authentication | An identity lookup | | Estimated rows or plan cost | After talking to the datastore | A round trip to the resource you are protecting | Notice the last row. The most accurate price comes from the very component you are trying to shield, which is why a naive design that asks the database how expensive a query will be can itself become the attack surface. ## Where the decision actually goes The practical resolution is an admission point that is application-aware but sits *in front of* the expensive downstream call: it parses the request, classifies it into a cost class from its declared shape rather than by asking the datastore, and refuses or defers the classes it will not serve concurrently - before taking a connection from the shared pool. This is not free and the honest answer says so: - Every ordinary request pays a parse, a classification and a policy lookup. - A new component now sits in the hot path, and its failure is an outage. - Somebody must maintain the cost classes as the API changes, or they silently stop matching reality. ## The mistake to avoid saying out loud Two answers mark a candidate down. The first is claiming the layer-4 device can simply be told to inspect deeper - this either changes it into a different class of device with a different cost and failure profile, or is impossible because the payload is encrypted to the service. The second is treating the parse as free, and therefore treating 'reject after parsing' as equivalent to 'never let it in'. On an attack whose damage is measured in work per request, the parse is part of the bill you are trying not to pay, and admitting that is the point of the question.
- Given both vantages are incomplete, where do you actually put the admission decision?At the first component that parses the request and can be told what things cost: an application-aware gateway, or an admission check inside the service before the expensive downstream call. It must be able to reject before taking a connection from the shared datastore, and it must carry an explicit notion of request cost - a bounded parameter set, a declared operation class - rather than inferring cost from who is calling.
- Is estimating a query's cost before running it reliable?Only partly. A planner's estimate is a guess over statistics and can be badly wrong on skewed data, and an attacker who probes will find the inputs where the estimate is low and the reality is not. Worse, obtaining the estimate means a round trip to the resource you are protecting. Use estimates as a coarse class boundary, not as a guarantee.
- What does terminating TLS and parsing earlier in the path cost you?You add a termination, a parse and a policy lookup to every legitimate request, and you move a security-sensitive component into the hot path where its failure becomes your outage. In exchange you gain the one place that can see both identity and request shape, which is what pricing needs. That trade is the actual decision.
A doorman can turn anyone away in a second but cannot tell who will order the twelve-course tasting menu. The kitchen knows the instant the order lands - and by then the ingredients are already out.
saying these in an interview costs you the question
- Believes a layer-4 device can inspect the request body
- Says the front end just needs deeper inspection turned on
- Infers a request's cost from its source address
- Treats parsing and authenticating the request as free