Re: Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs

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

On Jan 7, 2019, at 10:16 AM, Jaap Keuter <jaap.keuter () xs4all nl> wrote:

> On 6 Jan 2019, at 19:54, Guy Harris <guy () alum mit edu> wrote:
>
> > And not all conversations necessarily have specific endpoints.
>
> You mean, where the wildcards come into play?

That too, but I was thinking of, for example, a "conversation" that includes all packets that were sent on or received 
by "eth0", as per

> Examples are an aggregating tap/monitor port which monitors various VLANs, or an MPLS link. Or even closer to home, a 
> multi port capture in a pcapng file, lets say of two ports of a switch or router. The conversations therein would 
> need to be identified from the capture interface on up.

That's not a conversation between two particular endpoints.  (This is why I don't like the name "conversation", but I'm 
not sure what a better name would be.)

A circuit (in the sense that we used to have, rather than as a type of conversation) usually has endpoints, but they 
don't have IDs.

A TFTP conversation is *mostly* packets going between two specific UDP endpoints, but the first packet is often not 
between those two endpoints.

An NFS conversation includes traffic between the NFS client and server endpoints, but, at least for NFSv2 and NFSv3, it 
also includes traffic between the lock manager client and server endpoints, and perhaps some other protocols such as 
the mount protocol as well.

The base class of "conversation" has no particular notion of what identifies a conversation; it's subclasses that do 
that.  "Endpoints" identifiable from packet traffic aren't a characteristic of conversations in general, they're a 
characteristic of some but not all types of conversations, such as TCP connections.

> > The intent here is to have a general concept of a "conversation", with no specification, at that layer, as to how a 
> > "conversation" is identified - think of it as an abstract base class - with subclasses that use different ways of 
> > identifying whether a packet belongs to a given conversation or not.  Multiple subclasses can share code for 
> > identifying that; TCP and UDP might share the "IP address and port" identification code.
>
> Sure, so the tuple I’ve talked about would be a derived class consisting of all elements within the tuple. That makes 
> sense.

So there would be some conversations, identified by a pair of tuples, where a packet belongs to the conversation if 
each of those tuples correspond to particular fields in the packet.

There would be others where some other criterion is used to determine whether the packet belongs to the conversation or 
not, perhaps based on a *single* tuple corresponding to particular fields in the packet (that would handle circuits and 
"all packets sent on or received by the interface with interface ID *n* and...), and perhaps other more complicated 
criteria.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe