[pcap-ng-format] "Hardware, OS, User application" - separate options for "what did the capture?" and "what's processed the file"?

[Jasper Bongertz]

Hi,

>> If a capture is done, it might be useful to record, for the machine to which the physical interface on which the capture was done is attached:
>> 
>>       the hardware of that machine;
>> 
>>       the OS that machine is running;
>> 
>>       the application that did the capturing;
>> 
>> if they are available.

I agree.

> Given the existence of tools that merge capture files, no guarantee
> can be made that any option in the Section Header Block will reflect
> "the machine on which the capture was done", so:

>         1) programs shouldn't report the shb_hardware, shb_os, or
> shb_userappl options as pertaining to the machine on which the
> capture was done (yes, Wireshark does that, and, yes, it should stop doing so);

Make sense to me; this is a change that requires increasing the minor
version number I guess. Minor, because it's just in the options, which
shouldn't break any reading process. But significant enough to
indicate a difference to 1.0.

>         2) we should have IDB options for both the machine on which
> the capturing application was run and the machine to which the
> interfaces on which the captures were done was attached - the latter
> should probably be omitted if the interface is local;

I think adding if_remote_* should be done only if it is in fact a
remote capture.

>         3) programs that merge captures should probably only copy
> over shb_hardware, shb_os, and shb_userappl options from the input
> files if the values are the same in all files - and that raises
> questions about merging multi-section files.

Multi-section is always a problem, but at this moment I have only ever
heard of one use case for them, and that was with identical SHBs as
far as I remember. So we can probably ignore this for now.

> So I'd vote for adding to the IDB:

>         if_hardware - the hardware on the machine doing the
> capturing and writing the capture file;

>         if_userappl - the application running on that machine;

> with if_os specified as being the OS running on that machine, and also adding

>         if_remote_hardware - the hardware on the machine to which the interface is attached;

>         if_remote_os - the OS running on that machine (if any);

>         if_remote_userappl - the capturing from that interface and
> sending packets over the wire (e.g., rpcapd);

> along with

>         if_interface_hw - a hardware-level description of the
> adapter on which the capture is being done (local adapter for a
> local machine, remote adapter for a remote machine).

Sounds good to me - we should try to have a unique identifier per
interface (the MAC/hardware address?) so that merge routines can have
a chance to know that two interfaces in two different files/sections are
actually (or at least "most likely") one and the same. Otherwise we'll
end up with merged files containing sometimes hundreds of IDBs.

> The current description of the SHB options in question speaks of
> them as being for the {hardware,OS,application} "used to create the
> section", which, arguably, means that, in a merged capture, it
> should refer to the hardware and OS on which the merging program was
> run and the merging application itself.

> Whether editing a capture, by removing packets,
> adding/removing/changing comments, etc. should result in the SHB
> options being removed or changed is another question; my inclination is "no".

I agree, they shouldn't change the SHB except it is intended to do
just that. Normal packet/comment editing shouldn't touch it.

Cheers,
Jasper
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3283 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.winpcap.org/pipermail/pcap-ng-format/attachments/20160601/974c8be5/attachment.bin>