Re: [Patch, RFC] to TCP Sequence Analysis

[Martin Mathieson <martin.r.mathieson () googlemail com>]

On Sat, Mar 24, 2012 at 3:39 AM, Guy Harris <guy () alum mit edu> wrote:

> On Mar 23, 2012, at 6:11 PM, Martin Mathieson wrote:
>
> > I'm now needing to analyse TCP conversations carried over LTE
> MAC/RLC/PDCP/IP.  So one frame in a log or capture can hold many segments
> of the same TCP conversation.
>
> Presumably because it can hold multiple IP datagrams.
Yes, often one RLC PDU will hold more than one PDCP PDU, which for
user-plane traffic contains an IP frame.


> There are probably many parts of Wireshark that assume that a packet at
> the lowest visible layer will not contain more than one packet from a
> higher layer, so that the frame number can be used to uniquely identify
> packets at all layers.
>
> I suspect LTE is not the only link layer that violates this assumption.

For LTE, I do similar sequence analysis at the RLC and PDCP layers. The
first implementations used only the frame number, which resulted in the
same problem.  I added to those key things specific to those protocols,
i.e. channel-type / channel-number / sequence number to avoid attaching the
analysis to the wrong PDU within the frame.


> (In addition, assuming that a packet at the transport layer will not
> contain more than one packet from a higher layer is also not valid; TCP
> violates that assumption.)
>
> So, in the general case, we'd need more than just the frame number; a
> pairing of {frame number} and {offset, relative to the beginning of the
> frame, of the first byte of the next layer of packet} might suffice,
> although it doubles the space required for the key.
>
> > My change was to expand the key now to include
> frame+sequence-number+ack-number (where the sequence-number and ack-number
> are the raw, rather than relative, values), which works well for me.
>
> That's another possibility, although it's specific to LTE.
In this case, my choosing that key was specific to TCP.  And I liked the
idea that instead of allocating a new entry for every single segment,
repeated ACKs sent within the same frame could share that entry, as their
analysis would (I think) be the same.  Also, I don't like the idea of the
TCP dissector needing to know which segment it is within the frame.  Or
needing to know where its tvb happens within the overall frame.  It may be
reassembled (as RLC does for PDCP), decompressed or deciphered into a
separate tvb with a small offset that may clash with other child tvbs.


> > Is there a more appropriate key for looking up the segment?  I did think
> about adding an index for the segment within the frame, but that would be
> messy, and if you had to segments with the same seq+ack, I think the same
> analysis would always apply.
>
> "Index" meaning "if a given LTE MAC layer frame has more than one
> higher-layer packet in it, use the ordinal number of the packet"?

Yes, although actually you could have multiple RLC PDUs within the same MAC
PDU, or multiple segments within the same RLC PDU (which can be logged
without MAC), so its not clear how/where this would be done.

I think I have talked myself into believing that my patch is the right
thing to do. i.e. that its best to add to the key whatever makes sense for
that protocol.  That is neater than having the protocol need to look for
where it occurs within the frame, or for every possible lower-layer
protocol that could hold it needing to tag it with an index.  And the
worries about child tvbs above.

In fact, a bolder man than me might even be tempted to remove the frame
number from the key for TCP.  It would make the key shorter (8 bytes rather
than 12), and would lead to more sharing of the analysis result entries in
the table.  But I'd be worried about the (very remote) possibility of the
sequence number wrapping and the wrong segment getting tagged with very old
analysis.

I can still rework this if anyone feels strongly about it, otherwise I'll
submit it in a couple days.

Martin


___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe