3 ms·

> 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 precede

by cesarb 3y ago

> 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.)

Arnavion 3y ago
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.
- raggi 3y ago
  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.
  - ikiris 3y ago
    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.
- egberts1 3y ago
  Case in point, MS Windows does it one way, UNIX does it another way.
  - ikiris 3y ago
    You're missing the point of because of packet reordering, any order can and should be valid.

by cesarb 3y ago

Arnavion 3y ago

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.

raggi 3y ago
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.
- ikiris 3y ago
  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.
egberts1 3y ago
Case in point, MS Windows does it one way, UNIX does it another way.
- ikiris 3y ago
  You're missing the point of because of packet reordering, any order can and should be valid.