Carpet bombing, what's it look like now
The single destination case is easy enough. You RTBH the /32, renumber the customer, and move on. Carpet bombing takes that option away, since there's nowhere to move anyone to and nothing crosses a per-host threshold to trigger on in the first place. I'm curious what it actually looks like for those of you dealing with it regularly. Everything I've read says ports and packet sizes are randomized wide enough now that signature matching isn't worth much, though I'd rather hear that from someone watching it happen than from a vendor report. Does destination prefix plus protocol and port still get you something tight enough to act on, and if so, how many rules do you end up carrying mid-attack? Somewhat related, does packet length matching actually work on your hardware? I've been reminded lately that documented and functional aren't always the same thing. What are you feeding detection with, and does it keep up? sFlow, IPFIX, port mirror, something else. With attacks routinely over inside a couple of minutes I'm not convinced sampled telemetry is fast enough to matter, and I'd like to know whether people are installing rules after the thing already ended. If you're sampling, has any ratio worked well enough that the low per-host rates of a carpet bomb still trip an aggregate threshold in time to act? The other half of this is lifecycle. How long do you leave rules installed, and what tells you it's safe to pull them? Pull too early and you re-detect the same attack. Leave them in and you're carrying stale state indefinitely. Once you've got a signature, what do you actually do with it? Drop outright, rate limit, or hand it to a scrubber? I'd expect that to track how confident you are that nothing legitimate matches, but I'm curious where people really draw those lines. Our bar is customers not noticing rather than stopping every packet, and those turn out to be different targets. What's everyone doing for v6? Flowspec support looks thin enough there that a carpet bomb against v6 space puts you back to blackholing hosts one at a time. Separate question: is anyone pairing FastNetMon or similar detection with a self-hosted scrubber like VPP or Gatekeeper, rather than handing the traffic off to a provider? Interested in the outbound direction as well, catching a compromised customer before the traffic leaves. If you do answer, rough network size helps. Forty rules at 10G and forty rules at 1T aren't the same finding. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP
On Fri, 31 Jul 2026 at 21:51, Mike Hammett via NANOG <nanog@lists.nanog.org> wrote:
vendor report. Does destination prefix plus protocol and port still get you something tight enough to act on, and if so, how many rules do you end up carrying mid-attack? Somewhat related, does packet length matching actually work on your hardware? I've been reminded lately that documented and functional aren't always the same thing.
Packet size matching in my experience tends to work on most gear, particularly on gear you'd use on edge. More so, flexible packet matching is increasingly available that allows highly specific pattern matching, if any is available.
What are you feeding detection with, and does it keep up? sFlow, IPFIX,
IPFIX. But sampling rate is making things tricky, as very short term attacks are a thing.
Once you've got a signature, what do you actually do with it? Drop outright, rate limit, or hand it to a scrubber? I'd expect that to
Customers who pay for scrubbers get scrubbers. If there is a specific target, blackholes or ACL. If wide carpet, QoS downgrade, no explicit rate-limit, transport the attack if we have excess capacity to do so.
What's everyone doing for v6? Flowspec support looks thin enough there that a carpet bomb against v6 space puts you back to blackholing hosts one at a time.
Same as v4. -- ++ytti
On 2026-08-01 08:17, Saku Ytti via NANOG wrote:
What are you feeding detection with, and does it keep up? sFlow, IPFIX, IPFIX. But sampling rate is making things tricky, as very short term attacks are a thing.
IPFIX IE 315 fixes this. It also makes it easier to grab any field from the sampled packet headers. The support is still quite young and unfortunately, most vendors leave out any other IEs that could still be useful, like ForwardingStatus or routing-related IEs. This is being fixed for both Juniper and Cisco.
On 2026-08-01 08:17, Saku Ytti via NANOG wrote:
More so, flexible packet matching is increasingly available that allows highly specific pattern matching, if any is available.
On JunOS, there is this: https://community.juniper.net/blogs/nicolas-fevrier/2025/09/26/packet-filter... (I think that's what you had in mind).
On Sat, 1 Aug 2026 at 10:05, Vincent Bernat via NANOG <nanog@lists.nanog.org> wrote:
IPFIX. But sampling rate is making things tricky, as very short term attacks are a thing.
IPFIX IE 315 fixes this. It also makes it easier to grab any field from
How does IE 315 fix sampling issues? You can use 1:1 with or without IE 315? Only thing IE 315 allows you to send sflow style raw frames? My issue with 1:1 isn't that my platform doesn't support it, it's that it increases backend costs in a way that I cannot justify. -- ++ytti
On 2026-08-01 10:06, Saku Ytti wrote:
IPFIX. But sampling rate is making things tricky, as very short term attacks are a thing.
IPFIX IE 315 fixes this. It also makes it easier to grab any field from
How does IE 315 fix sampling issues? You can use 1:1 with or without IE 315? Only thing IE 315 allows you to send sflow style raw frames?
My issue with 1:1 isn't that my platform doesn't support it, it's that it increases backend costs in a way that I cannot justify.
I was focused on the very short attacks. The issue is not sampling, but the flow cache adding some latency, even when tuned down. That's the part IE 315 fixes: there is no cache anymore and the sampled packets are sent directly.
You may use sampled port mirroring for fast attack detection. It works pretty well for very short burst attacks. Em sáb., 1 de ago. de 2026, 08:05, Vincent Bernat via NANOG < nanog@lists.nanog.org> escreveu:
On 2026-08-01 10:06, Saku Ytti wrote:
IPFIX. But sampling rate is making things tricky, as very short term attacks are a thing.
IPFIX IE 315 fixes this. It also makes it easier to grab any field from
How does IE 315 fix sampling issues? You can use 1:1 with or without IE 315? Only thing IE 315 allows you to send sflow style raw frames?
My issue with 1:1 isn't that my platform doesn't support it, it's that it increases backend costs in a way that I cannot justify.
I was focused on the very short attacks. The issue is not sampling, but the flow cache adding some latency, even when tuned down. That's the part IE 315 fixes: there is no cache anymore and the sampled packets are sent directly. _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/TALTTNNV...
On Sat, 1 Aug 2026 at 14:05, Vincent Bernat <bernat@luffy.cx> wrote:
I was focused on the very short attacks. The issue is not sampling, but the flow cache adding some latency, even when tuned down. That's the part IE 315 fixes: there is no cache anymore and the sampled packets are sent directly.
I don't think that's accurate either. There is no reason why you couldn't cache in IE 315, I think. You'd be very unlikely to have a cache line created, then exported, and then be hit again before export. But that's true for caches generally for all typical implementations. People are running 1:10k, 1:5k, 1:1k, 1:500, most of these cache does nothing but delay export, 99.9% entries will never be hit again after creation and before export. But again, this is not IE 315 feature, there is no reason why you must cache in IPFIX, some platforms, like PTX do not cache ever at all, no matter the config. -- ++ytti
On Sat, 1 Aug 2026 at 15:47, Gustavo Santos <gustkiller@gmail.com> wrote:
You may use sampled port mirroring for fast attack detection. It works pretty well for very short burst attacks.
If I don't sample, my cost becomes prohibitive. If I do sample, my probability of detecting attack goes down. The sampled port-mirroring is very much the same proposal as Vincent's IE 315. -- ++ytti
On 2026-08-01 14:59, Saku Ytti wrote:
I was focused on the very short attacks. The issue is not sampling, but the flow cache adding some latency, even when tuned down. That's the part IE 315 fixes: there is no cache anymore and the sampled packets are sent directly.
I don't think that's accurate either.
There is no reason why you couldn't cache in IE 315, I think.
It makes little sense since you need to put the sampled packet header in the flow. You could put several of them or the first one or the last one, but why? AFAIK, all implementations of IE 315 bypass the cache.
On Sat, 1 Aug 2026 at 16:35, Vincent Bernat <bernat@luffy.cx> wrote:
It makes little sense since you need to put the sampled packet header in the flow. You could put several of them or the first one or the last one, but why? AFAIK, all implementations of IE 315 bypass the cache.
I fully agree it makes no sense. But it also makes no sense without IE 315 in most practical scenarios, and people shouldn't cache with or without IE 315 by default, they should have explicit reason to cache. We cache on some platforms, where they support it, and our flow records are almost invariably 1 packet long. That is, we are spending SERDES on the NPU to store the record in off-chip memory, let it sit there, then later spend SERDES to pick it up, and export it out. Lots of complexity, cost, thermal, pin count to gain delay, utter madness. We mostly cache because of decades of habit, because of how it's always been done. Despite the network having so much more flows that statistically we're not hitting the same flow twice anymore almost ever. Only minor thing we gain is that the export packet may contain multiple flow records (each flow record 1 packet deep record). This can help in scale or pricing in some cases, but is a minor thing. And actually non-caching node could push multiple flow records in a single export packet also, just not what PTX does. If you use 305/306, every time you trigger export, you could pull consequent packets off the wire to fill the export packet you're simultaneously serialising out. 0 cache, 0 delay and fully populated export packets. -- ++ytti
participants (4)
-
Gustavo Santos -
Mike Hammett -
Saku Ytti -
Vincent Bernat