Network Security and Defense Questions

Direct answer

Anycast scrubbing advertises the same IP prefix from multiple geographically distributed points of presence (POPs) via the Border Gateway Protocol (BGP), so ordinary internet routing automatically steers each client to its topologically nearest POP. That same property is the defense mechanism: an attack's traffic naturally splits across every POP announcing the prefix instead of concentrating on one path, and any POP that becomes overwhelmed can withdraw its announcement so BGP reconverges traffic to the remaining POPs.

Structured elaboration

flowchart TB
    C[Clients worldwide] --> POPA[POP A scrubbing]
    C --> POPB[POP B scrubbing]
    C --> POPC[POP C scrubbing]
    POPA --> ORIGIN[Origin application]
    POPB --> ORIGIN
    POPC --> ORIGIN
    POPB -. overloaded withdraws route .-> C

1. Points of presence and traffic steering. Deploy scrubbing POPs at multiple internet exchange points, each announcing the same anycast prefix. BGP routes each client to the lowest-cost path under normal conditions, minimizing latency for clean traffic, and under attack spreads the attacker's traffic across every announcing POP, since an attacker generally can't choose which POP their own packets land on either.
2. Health checks and failover. Each POP monitors its own scrubbing throughput utilization, upstream link saturation and control-plane responsiveness. When utilization crosses a threshold, the POP withdraws (or de-prefers) its BGP announcement, and convergence redistributes its traffic to neighboring POPs, at the cost of a brief black hole for sessions mid-flight and a step increase in round-trip time for clients remapped to the next-nearest POP. If the design targets a specific availability goal, say 99.99% uptime (about 52 minutes of allowed downtime a year), that number becomes a direct constraint on how fast convergence and headroom need to be, not just a marketing figure: a black hole longer than a few seconds during failover eats into that budget quickly.
3. Capacity scaling. Size each POP for more than its expected steady-state share of the 100 Gbps baseline, plus enough headroom that when a neighboring POP fails over, the remaining POPs absorb the redistributed load without cascading, that is, N+1 redundancy at the POP level, not just within one POP.
4. Integrating the rest of the perimeter. Anycast scrubbing is one layer, not the whole defense. A layered posture keeps a stateful perimeter firewall behind the scrubbing layer for policy enforcement that needs connection state, coordinates with the upstream internet service provider (ISP) for scrubbing that needs to happen before traffic even reaches your POPs (relevant for the largest volumetric floods, where dropping traffic close to its source matters most), and integrates with cloud-edge services such as a CDN or reverse proxy that absorb application-layer load and cache static content so the scrubbing layer only handles what actually needs to reach the origin.
5. Fine-grained mitigation once an attack is identified. Two BGP-based tools sit below POP-level failover, at different granularity. Remotely-triggered black hole (RTBH) routing advertises a narrow prefix for the specific victim address with a community that tells upstream routers to drop all traffic to it; it's coarse, since it takes the destination offline entirely (a controlled denial of service instead of an uncontrolled one), but fast and simple to roll out on any router with standard BGP support. BGP FlowSpec (originally RFC 5575, since obsoleted by RFC 8955) instead distributes a match-and-action rule, for example "drop UDP traffic to this destination on source port 123" to suppress a specific reflection technique, so only the attack's actual signature is dropped while the rest of that destination's traffic keeps flowing. FlowSpec is more surgical but requires FlowSpec support on the routers in the path, which isn't universal, and upstream providers vary in whether they'll accept a customer's FlowSpec rules; it's also slower to design correctly under time pressure than "just black-hole it."
6. Stateful services and latency. Anycast works cleanly for stateless or short-lived request and response traffic, but a long-lived connection, a WebSocket or a persistent API session, can break if BGP reconverges mid-session and the client's packets start arriving at a POP with no record of that connection's state. A design serving stateful traffic either needs session affinity engineered on top of anycast (routing back to the POP holding the session, or replicating session state across POPs) or has to accept that a POP failover drops those specific sessions and the client must reconnect gracefully.

Worked example

Across 5 POPs, a 100 Gbps baseline splits evenly to 20 Gbps per POP. Sizing for N+1 within the group, so that any one POP's traffic can be absorbed by the remaining four, means the 20 Gbps carried by a POP that goes fully dark is what gets redistributed, split evenly across the 4 remaining POPs:

$\frac{20 \text{ Gbps}}{4} = 5 \text{ Gbps extra per remaining POP}$

so each remaining POP then carries its own 20 Gbps share plus 5 Gbps of failover load, or 25 Gbps total (equivalently, the 100 Gbps baseline spread over the 4 remaining POPs is 100 / 4 = 25 Gbps each, which is the total per remaining POP, not the increment). Each POP should therefore be provisioned for roughly 25 Gbps, not just its steady-state 20 Gbps. That 5 Gbps of otherwise-idle headroom per POP is the concrete cost of the redundancy the availability target demands.

Trade-offs and pitfalls

BGP reconvergence is not instantaneous, ranging from sub-second to tens of seconds depending on the path, so a design that assumes zero-impact failover is wrong. RTBH's simplicity comes at the cost of completing the attacker's goal for them, the target genuinely goes offline, just on your terms, so it should trigger escalation to a more surgical mitigation like FlowSpec rather than being left in place. Provisioning every POP for full N+1 headroom against the simultaneous loss of every other POP gets expensive fast as POP count grows; real deployments typically target resilience against losing one POP, not several at once.

Direct answer

A traditional port and protocol firewall rule decides purely on network and transport-layer information, source and destination address, port number, protocol, so a rule like "allow TCP port 443" allows anything that happens to use that port. Application-level matching, the defining feature of a next-generation firewall (NGFW), inspects the actual traffic content and behavior to identify what application is really running, regardless of which port it uses. This matters because modern applications routinely share common ports (nearly everything tunnels over port 443 now) or hop to whatever port happens to be open.

Structured elaboration

How application-aware matching actually works. Instead of trusting the port number, an NGFW performs deep packet inspection and application fingerprinting: looking at things like TLS (Transport Layer Security) handshake metadata such as the Server Name Indication, traffic timing and shape, and known payload signatures to classify what the traffic really is, for example recognizing that traffic on port 443 is really a specific file-sharing client rather than a generic web browse.

When application-level matching is necessary.

• When you need to allow a broad category but block a specific one that shares its port. An organization needs to permit general web browsing on port 443 but wants to block unsanctioned file-sharing tools or unapproved messaging or remote-access applications that also use 443. A port rule cannot express that distinction at all, since blocking port 443 outright would also break normal browsing.
• When detecting a non-standard use of an otherwise-normal port. Malware that tunnels command-and-control traffic over port 80 or 443 to blend in with ordinary web traffic looks, to a port rule, like normal web traffic. An application-aware rule can flag that the payload inside that port does not actually look like real HTTP.

Drawbacks. Application identification is not perfect: fingerprinting can misclassify a newly-updated or lesser-known application, and it can produce nothing useful at all when traffic is heavily encrypted with no distinguishing metadata left. It also costs more processing overhead than a simple port match, since it has to examine payload or metadata rather than a single packet header field, which matters at high traffic volume. Finally, it needs continual updates from the vendor to keep recognizing current application versions, so a rule that correctly classified an application last year can silently stop working correctly after that application changes its own network behavior.

Worked example

A company wants to allow general web browsing (any HTTPS site) but block a specific unsanctioned peer-to-peer file-sharing application whose client happens to negotiate its connection over port 443 specifically to slip past a naive port-based rule. A port and protocol rule can only say "allow or deny port 443," an all-or-nothing choice that cannot separate the two. An application-aware NGFW rule instead says "allow the web-browsing category, deny the peer-to-peer file-sharing category," correctly separating the two despite both using the identical port, because the rule is keyed to what the traffic actually is rather than which door it walked through.

Trade-offs and pitfalls

Application-aware matching does not replace port and protocol rules; coarse port-based filtering is still cheaper and useful as a first-pass default-deny layer underneath it. A real pitfall is over-trusting an application classification when the vendor's own confidence score for that flow is actually low, since many NGFWs expose a confidence level and treating "possibly classified" the same as "confirmed" is a common misconfiguration. Another pitfall is forgetting that heavily encrypted, well-behaved traffic with no distinguishing fingerprint, a well-implemented virtual private network tunnel, for instance, may simply come back as "unknown," and some environments then default-allow unknown traffic, quietly defeating the entire point of application awareness.

Direct answer

The OSI model splits networking into seven conceptual layers; the TCP/IP suite is the four-layer model the real internet runs on, and it condenses OSI's bottom two layers into one "network access" layer and OSI's top three into one "application" layer. Each layer is where a specific class of attack and a specific class of control naturally live, because that is the layer that actually has the information needed to detect or block that class of problem.

Structured elaboration

Worked example

Trace a single attack end to end through this table: an attacker plugs a laptop into an unused conference-room jack. If the physical-layer control (802.1X, disabled unused ports) is missing, the attacker gets link immediately. If it is present but the data-link control is missing, the attacker can still ARP-spoof the gateway and intercept traffic even though they were correctly admitted at layer 1 for some other legitimate reason (a guest VLAN, say). This is why the table is a defense-in-depth chain, not a menu you pick one item from: a gap at any single layer can undo the protection at every layer above it.

Trade-offs and pitfalls

• The TCP/IP model does not actually have separate session and presentation layers; treating them as OSI does is a teaching convenience, and real protocols (TLS, for example) blur session and presentation concerns together.
• A control that is technically correct for its layer can still be misapplied: a WAF (application layer) cannot compensate for an open, unauthenticated switch port (physical/data-link layer), so layer-appropriate controls have to be deployed together, not as substitutes for one another.
• Some technologies genuinely span layers (IPsec can operate in a way that affects both network-layer routing and what looks like transport-layer session state), so treating this table as a strict, non-overlapping partition is itself a simplification worth naming out loud in an interview.

Direct answer

Use Internet Key Exchange version 2 (IKEv2) for the control plane, since it detects network address translation (NAT) automatically and rekeys more cleanly than the alternative, stagger the phase-1 and phase-2 security association (SA) lifetimes so a new SA is negotiated and installed well before the old one expires, and give each site an active/passive concentrator pair with synchronized state so a failover doesn't force every tunnel to renegotiate from scratch.

Structured elaboration

1. IKE version. Prefer IKEv2 over IKEv1. IKEv2's initial exchange includes native NAT-detection payloads that automatically switch to User Datagram Protocol (UDP) encapsulation on port 4500 when a NAT is found in the path, with no separate extension to configure. Its 4-message initial exchange establishes a session faster than IKEv1's 6-message Main Mode, and its CREATE_CHILD_SA exchange for rekeying is simpler and more predictable than IKEv1's separate Quick Mode negotiation, which matters directly for minimizing packet loss during rekey.
2. NAT traversal (NAT-T). Since an intermediate NAT can sit between either datacenter's edge device, enable NAT-T so IKE and IPsec traffic get UDP-encapsulated once NAT detection finds a NAT in the path. This avoids the classic failure where the Encapsulating Security Payload (ESP), the IPsec component that encrypts traffic, has no port number a NAT device can rewrite consistently in its native form.
3. SA lifetimes. Set the IKE (control-channel) SA lifetime longer than the child (data-channel) SA lifetime, a common pattern is many hours for the control channel and an hour or less for the data channel, and renegotiate well before expiry (many implementations default to around 90% of the configured lifetime) so the new SA is fully established while the old one briefly remains valid, rather than the old SA expiring with nowhere for traffic to go until a fresh negotiation finishes.
4. Minimizing packet loss during rekey specifically. Use "make before break" rekeying: the new child SA is negotiated and installed while the old one is still valid, and traffic switches over only once the new SA is confirmed. This is IKEv2's default CREATE_CHILD_SA behavior with overlapping lifetimes, the direct lever for the packet-loss requirement, as opposed to a naive design that tears down the old SA before the new one is ready.
5. High availability. Give each site an active/passive concentrator pair sharing a virtual IP (VIP) for the tunnel endpoint, with state synchronized between the pair, conceptually the same idea as stateful firewall failover: a protocol like Virtual Router Redundancy Protocol (VRRP) manages the VIP, while IPsec SA and sequence-number state is replicated to the standby. Failover without state synchronization still recovers, but every tunnel has to fully renegotiate from IKE phase 1; state-synced failover can preserve tunnels transparently to the traffic riding on them.

Worked example

With a 24-hour IKE SA lifetime and a 1-hour child SA lifetime, renegotiating at roughly 90% of lifetime means the new child SA negotiation starts around

$0.9 \times 60 = 54 \text{ minutes}$

into each hour, leaving a 6-minute window for the new SA to be fully negotiated and installed before the old one would expire. With make-before-break rekeying, traffic keeps flowing over the still-valid old SA throughout that window and switches the moment the new SA is confirmed, so in the ordinary case the rekey is invisible to application traffic rather than a scheduled hourly disruption.

Trade-offs and pitfalls

A shorter child SA lifetime improves cryptographic hygiene (it bounds how much traffic is ever encrypted under one key) but adds rekey-negotiation overhead every cycle, a real security-versus-control-plane-load trade-off, not a free improvement. State-synchronized high availability is more resilient but adds real implementation complexity, and state-sync protocols rarely interoperate across vendors, so both concentrators at a site are usually the same vendor and model. NAT-T's UDP encapsulation adds small per-packet overhead and, on some middleboxes, another layer that an overzealous firewall rule can block; it needs to be verified end to end, not just assumed to work because it's enabled.

Direct answer

Front the design with load balancers spread across two availability zones (AZs) for both scale and failover, put the web and application tier in a subnet per AZ reachable only through the load balancer, keep the database tier in a private subnet per AZ reachable only from the application tier, and size each tier so that losing one entire AZ still leaves enough capacity in the surviving AZ to serve the 10,000-requests-per-second (RPS) target.

Structured elaboration

Tiers and subnets, duplicated per AZ.

• Public subnet: load balancers only, terminating HTTPS/TLS (Transport Layer Security), health-checking the tier behind them.
• Demilitarized zone (DMZ) subnet: web and application servers, reachable from the load balancer on the application port only, never directly reachable from the internet.
• Private subnet: database tier, reachable only from the DMZ subnet's application servers on the database's own port.

flowchart TB
    subgraph AZ1[Availability Zone 1]
        LB1[Load balancer] --> WEB1[Web app tier]
        WEB1 --> DB1[Database tier]
    end
    subgraph AZ2[Availability Zone 2]
        LB2[Load balancer] --> WEB2[Web app tier]
        WEB2 --> DB2[Database tier]
    end
    INET[Internet] --> LB1
    INET --> LB2

Firewall rules between tiers. Load balancer to web/application tier: allow only the application's listening port. Web/application tier to database tier: allow only the database's own port. An explicit deny applies to everything else at each boundary, identically in both AZs, so failover into the surviving AZ does not quietly relax the security posture there.

NAT/load-balancer placement. The load balancer is the only internet-facing component; application servers have no public address at all and are reachable only through the load balancer's private-subnet path. Outbound internet access the application or database tiers might still need, for patching or package repositories, goes through a NAT gateway per AZ rather than a public address on those tiers directly, keeping inbound exposure (nothing but the load balancer) and outbound exposure (routed and still filterable) deliberately asymmetric.

Health checks. The load balancer's health check should exercise a real application endpoint, not just confirm the port is open, and health checks should run per AZ so the load balancer can route traffic away from an unhealthy AZ's instances without waiting for an explicit failover event.

Minimizing attack surface while meeting the scale target. Transport Layer Security terminates at the load balancer, optionally re-encrypting to the backend for defense in depth, so the DMZ subnet and the internet only ever exchange encrypted traffic and certificate management lives in one place rather than scattered across every instance. Only the load balancer ever has a public listener; the web/application and database tiers have zero public addresses; and administrative access to any tier goes through a separate bastion path, not through the same subnets serving customer traffic.

Worked example

Illustrative capacity math, explicitly an assumed input rather than a measured benchmark: suppose each web/application instance can sustain roughly 500 requests per second before its own response-time service-level objective (SLO) degrades. Serving 10,000 RPS from a single AZ then needs about 10,000 divided by 500, which is 20 instances. For the design to survive losing one AZ entirely and still serve the full 10,000 RPS from the surviving AZ alone, that AZ's own capacity needs to already be sized (or able to scale quickly) to roughly 20 instances on its own, meaning close to 40 instances total across both AZs if the organization wants that headroom running in steady state rather than scaling reactively during the failure. That capacity-versus-cost decision has to be made explicit rather than assumed away by simply saying "two AZs."

Trade-offs and pitfalls

Sizing each AZ for only half of the 10,000 RPS target, with no failover headroom, means an AZ failure causes a real capacity shortfall exactly when it can least be afforded, so having two AZs alone does not guarantee availability unless capacity is planned for the failure case specifically. Giving application servers public addresses "just for easier administrative access" defeats the entire point of the DMZ design and is a common shortcut under deadline pressure. Forgetting that the load balancer itself needs to be deployed redundantly across both AZs leaves a single point of failure even when everything behind it is properly duplicated. A health check that only confirms a port is open, rather than real application health, will happily keep routing traffic to a broken instance.