An inline IPS blocks intruder traffic into a plant zone - how do silent drop and reject differ for a device that never retries?

## Two ways to say no When an inline sensor decides a flow may not pass, it has two families of action. **Drop** discards the packet silently. Nothing is emitted toward either endpoint. From the sender's point of view the network simply lost the packet, which is a normal event that the sender's transport is expected to handle. **Reject** answers actively. For TCP that means a reset; for other traffic it usually means an ICMP destination-unreachable, of which the administratively-prohibited flavour is the honest one. The endpoint gets an immediate, explicit refusal. On a general-purpose network the choice is close to cosmetic, because clients retry and stacks surface errors. On a plant floor or a ward it is not, because a large part of the population does neither. ## What each does to equipment that never retries A lot of embedded equipment opens a connection once at start-up, or sends into a session it assumes stays up, and has no recovery path beyond a power cycle or an engineer walking to it. - **Under drop**, that device waits. Depending on the stack it blocks for a retransmission sequence measured in tens of seconds, or waits forever. The application above it reports nothing useful - at best a timeout with no cause. The operator sees the line, the study transfer or the monitoring feed stop, and nothing on the device points at a security control. The mean time to diagnose is the real bill, and it is usually paid by people who do not know the control exists. - **Under reject**, the device gets a reset or an unreachable immediately. If its stack honours it, the failure is fast and specific and can surface as a connection-refused rather than a hang, which is a much cheaper failure to chase. If its stack ignores ICMP - very common - the reject was a drop all along. This is the asymmetry worth carrying into an interview: reject is kinder to *diagnosis*, and it is only kinder to the *device* if the device listens. ## What each tells the adversary A reset or an administratively-prohibited message is a positive statement that a control exists, and often where in the path it sits. Someone probing a boundary can map exactly which protocols, ports and directions are filtered, cheaply, without succeeding once. A drop leaks less, though not nothing - the timing difference between a drop and an unreachable host is itself observable. The honest formulation: drop buys quiet against a probing adversary and pays for it in operational opacity; reject buys legibility for your own operators and pays for it in reconnaissance value handed away. ## Details that separate a middle from a junior answer - **Both ends, or half-open state.** Terminating an established TCP session from a device in the middle requires resetting toward both endpoints. Reset one side only and the other holds state until its own timeout, which reproduces exactly the hang you were trying to avoid. - **Packet versus flow.** Some engines drop only the matched packet and let the rest of the session through; others tear the flow down. On a protocol carrying a multi-part command this is the difference between a clean failure and a half-applied instruction, which on a physical process is the worse of the two. - **Mid-transfer.** A reset in the middle of a long transfer - a study, a batch of recipe data - usually means the whole transfer restarts rather than resumes. The correct claim is that the transfer fails and must be repeated, not that the equipment stops doing its bedside or on-line job; most such devices keep performing their local function and what you actually severed was reporting, monitoring or transfer. - **No reject for UDP-based control traffic in practice.** Where the protocol is UDP and the stack ignores ICMP, there is no polite failure available at all, and the design question becomes whether that flow should ever be in the enforced rule class. ## The judgment There is no universal answer, and an interviewer is listening for whether you pick per population rather than globally. A common resolution is reject toward flows whose endpoints are your own managed systems and whose operators need a legible failure, and drop toward the segment where an adversary probes and where the equipment ignores your courtesy anyway - with the choice recorded, because the next person to debug a hung controller needs to know which of the two they are living with.