Re: Reassembly of IP fragments gets confused by multiple packets on different VLANS

[Guy Harris <guy () alum mit edu>]

On Jan 20, 2016, at 8:43 AM, Anders Broman <anders.broman () ericsson com> wrote:

> Trying to summarize…
>  
> captured on the "all" interface of a Linux machine acting as a router, or merged two captures from networks on 
> different sides of a router.
>  
> various sorts of tunneling

Including, for example, MPLS pseudo-wires.

> (or "other sorts of tunneling", if you view VLANs as a form of tunneling)

That might be the best way to think about VLANs - treat them the same way various tunnels, pseudo-wires, etc. are 
treated.

On the other hand, as a comment:

        https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4561#c5

in the bug you're quoting says:

        For VLAN I know cases where UL traffic and DL traffic belong to different VLAN, still to the same flow. Thus a 
differentiation according to VLAN id must be configurable.

so VLANs shouldn't always be treated as tunnels.

I don't know whether that's an issue for to any other form of pseudo-wire or tunnel - or even for physical networks, as 
identified by interface IDs; I could imagine a case where a machine has multiple physical interfaces on the same 
network and different fragments of an IP datagram, or different packets in a given TCP connection, or... might travel 
on different interfaces.

So is this really just a question of

        1) "wires", whether physical or virtual (a VLAN being a "virtual wire") or pseudo-wire or...

and

        2) whether the machine on which the capture is being done routes traffic between "wires" or not?

If the machine has multiple "wires" (or radio channels) and *is* routing between them, a capture that sees traffic from 
multiple "wires" might see multiple copies of network-layer packets on different "wires".

If it's not routing between them, and is, for example, using different "wires" for an uplink and a downlink, or has 
bonded multiple "wires" together and is sending traffic to another machine over multiple different "wires", then 
fragments from a given fragmented IP datagram, or packets on a given TCP connection, or... might appear on different 
"wires".

In the first case, you want to distinguish between "wires" when doing reassembly/TCP analysis and desegmentation/etc..

In the second case, you *don't* want to do that.

Would that be sufficient to handle the two cases?  Or are there cases where the machine might be routing between some 
sets of "wires" and using other sets of "wires" as parallel pipes to and from a given destination host, so that whether 
the "wire" should be taken into account depends on the "wire"?

> The right generalization might be to have some sort of "network tag" which incorporates a network interface ID plus 
> all VLAN tags for the packet ("all VLAN tags" to handle QinQ).
>  
>  
> So if we go for network tag, or key should that be created by
> Outer VLAN tag, Hash of Source MAC, protocol-level, interface index(Pcap-ng)?
>  
> Outer VLAN tag should take care of, VLAN and QinQ, right?
> Source MAC should take care of, “duplicate caused by mirroring” and alike(?)
> Pinfo- curr_layer_num Should take care of tunneling(?)
> Interface index should take care of ANY interface traces(?)
>  
> What size should the key be, is 32bits enough?

If we have a notion of "wire", perhaps we could assign sequential internal numbers to "wires" - just as we do for 
conversations - and use the internal "wire" number.

We could also use that for filtering, e.g. "show me everything on this "wire"".

(And maybe we could have a sidebar in Wireshark, showing all the "wires", conversations, etc. we've seen, and let you 
just click on one to show only the packets on that "wire"/in that conversation/etc..)
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe