[Owasp-proxy] Defragmenting tcp packets

Rogan Dawes rogan at dawes.za.net
Mon May 23 04:35:18 EDT 2011

On 2011/05/22 9:43 PM, Martin Holst Swende wrote:
> On 05/22/2011 09:10 PM, Rogan Dawes wrote:
>> True, I agree that the typical user would want to see the defragmented
>> stream. But would it not make sense to allow a higher layer to perform
>> the defragmentation if desired, rather than losing that information
>> entirely with no way of getting it back?

> That would definitely be the nicest thing to do. However, when I capture
> some http traffic (for testing) on a
> media rich site, FF opens up ~6 connections and pipelines data over each
> one. All of a sudden, there are 300 hundreds of packets waiting in the
> queue, I'm thinking that keeping that information and performing
> de/re-fragmentation on the fly (maintaining original packets and mapping
> that to a 'merged-packet-queue' all the while more packets may be
> arriving) may be problematic.
> For now, I at least would settle for a tick-the-box: defrag or not;
> which does not work retroactively.

Yes, that would be a good alternative.

> Well, as I said, I don't see that much value in chasing exact packet
> mapping. I don't really see the point, I can't really think of when I
> myself would ever have needed it. But sure, there may be some value in
> that in some cases (but then the destination better be just one hop
> away, otherwise you can't be guaranteed that the packet will traverse
> the network without fragmentation/defragmentation anyway (?))

The only real benefit of packet mapping is that it can help to show the 
boundaries between data being sent. i.e. build a packet, send the packet.

Each packet intercepted is an entity in its own right, and may well be a 
self-contained "thing". If they get coalesced into a single packet in 
the frontend, then the user may get confused.


More information about the Owasp-proxy-project mailing list