> That is probably the ONLY beef I have with RFCs covering IP/TCP/UDP: did not detail what to do in event of overlapping packets (first overlapped takes precedence or last overlapped overrides old data?)

For a correctly operating sender, it shouldn't matter, since the data should be identical. It would be the same as asking what should happen if the sender changes the data when retransmitting a packet (the only difference from overlapping fragments is that a retransmitted packet has 100% overlap). It's Undefined Behavior, the receiver is allowed to do anything it wants, and the sender can't complain since it's its own fault.

(Also consider that packets are always allowed to be reordered in transit, so what you thought was the first packet might become the last packet on the next hop; even if the standard constrained the reassembly ordering, you might still not get the result you expected.)

I believe egberts1's point is that leaving it unspecified invites different implementations to implement it differently. Some might choose to use the bytes from the first fragment, others might choose to use the bytes from the newer fragment. You could have a situation where the IDS / firewall / misc security appliance think the packets contain a benign request but the application server interprets them in a malicious way. Things like HTTP request smuggling rely on the same kind of mismatch at the application protocol layer, for example.

The problem is intractable unless you enforce lossless perfect ordering as a strict requirement. There's no way to define "first" as written in the premise without it.

Yeah, when programmers think they understand networking, is like the long rants about their understanding of timezones, and names, and email addresses.

Any order is a valid case that someone got as their "correct" order.

Case in point, MS Windows does it one way, UNIX does it another way.

You're missing the point of because of packet reordering, any order can and should be valid.

5 Gbps is pretty slow. Internet carrier routers typically connect to each other at 100 gbps (or 400 gbps these days) and a single router will have many such connections, so Tbps of bandwidth, often costing about the same as that IPS FPGA hardware (well, the routers go up to rack size in which case you'd probably want to compare to a rack size IPS box cost).

There is a 25Gbps XNS in the work.

With even more live updating of newly added Aho-Corrasick and Regex algorithm into the FPGA.

Oh yeah, things can still scale up but the gap ends up remaining the same as the same scaling drives each. Fortinet does some really insane stuff scaling its custom ASICs (+some FPGA, but it's not fast enough for everything so most is in ASIC instead) on e.g. the FG-7121F chassis to get ~500+ Gbps IPS/NGWF throughput. I haven't had excuse to go past their "smaller" fixed platforms which do 40+ though. Naturally you're paying more for that single 500 Gbps (total), of which elephant flows are limited because that's via parallel flow processing, than you would for something like a Nokia 7750 SR-s with ~500x (216 Tbps) that throughput though but such is life when you need to act as an endpoint instead of a router.

Oops, maybe we can add massively parallel FPGA processors should be in there somewhere before the SSL stage.

Goal is to do proper reduction of each ASIC/FFPA stage without a packet drop.

Meanwhile, your website is dropping SSL connections, zamadatix.

Yes, analyzing hostile traffic is much more expensive than routing.

Well yes, you could gather that, but also highlighting that what inspection boxes do in regards to F&R does not necessarily relate to the problems covered in the article because F&R has to work extremely quickly across the internet, often ruling out anything related how the box in the middle could see it and instead being about what endpoints can do independently via things like DPLPMTUD instead.

The boxes do run into very interesting problems and knowledge space though, just more on the inverse of the problem at hand (how to properly act like a client receiving already fragmented data).

Or properly behave as all-client allowable rather than A client-permitted