[Jasper Bongertz <jasper@xxxxxxxxxxxxxx>]

Hello Guy,

Tuesday, April 19, 2016, 1:04:15 AM, you wrote:

> The underlying issue here is that a capture file can pass through a
> sequence of multiple programs on multiple OSes.  I think a good case
> can be made for an IDB to record the OS - and probably the
> application - used to capture the traffic, with no additions made
> for further processing, so you know what program, on what OS, captured it.

> And, for libpcap/WinPcap-based programs, it might also be useful to
> record the version of libpcap/WinPcap as well.

> For the IDB, I could see three ways of handling this:

>         1) rename if_os to if_software and have it be a
> human-readable string with *all* that information;

>         2) add an if_userappl option and have it hold the
> application *and*, for libpcap/WinPcap-based programs, the libpcap/WinPcap version;

>         3) add an if_userappl option for the application and an
> if_userapplib (or whatever) option for the libpcap/WinPcap version.

Honestly, I like 3) - I think it's always better to have separate
information entries than having to guess/parse parts from a combined
entry.

> Now, the pcapng spec says of if_os "This can be different from the
> same information that can be contained by the Section Header Block
> (Section 4.1) because the capture can have been done on a remote
> machine.", but it could also be different because, for example,
> somebody might have run mergecap and merged captures done on two different OSes.

Merging is always a nightmare on a scale from 1-10 :-)

> The remote capture issue is a *separate* issue, and you might well
> want to know that a given remote capture was done with the remote
> interface on a Fedora 25 server running rpcapd 2.17 using libpcap
> 1.9.1 and the machine doing the capture being a Windows 10 machine
> with dumpcap 2.4.0 and WinPcap 5.0 based on libpcap 1.9.0 - the
> version of libpcap, and the application, on *both* machines
> potentially being relevant if, for example, you're trying to figure
> out a problem with the capture file.  Therefore, we might want to
> have separate local and remote versions of the if_ options in question.

Valid point.

> In *addition*, it might be useful to keep a record of all the
> programs through whose hands the capture has passed; that would mean
> having *multiple* OS and application options, in order.

I like that, too (I know that it also means a PCAPng file can carry a
ton of meta data depending on what happened with it), and I think it
doesn't happen too often that a file is read and written by multiple
programs.

> But, then again, what happens if you do several captures with
> different applications, combine them with mergecap, split the
> resulting capture into multiple captures, process the different
> files with different applications, and then, just for the lulz,
> merge them back again?

I'd say, someone's going to have a major headache in this case :-)

> Is this a sign that we need some scheme to record that level of
> history - which might involve some packets from interface eth0 being
> processed by applications A, B, and C and other packets from the
> same eth0 being processed by applications A, C, and D?

> Or is this a sign that we shouldn't bother recording anything other
> than the software used in the original capture?

Maybe something in between - most PCAPng files are not
edited/split/merged that much, so I don't think going for record level
histories is helping that much. Having good information (and risking
to lose some details on crazy split/merge operations) in the IDB is a
good way to cover most of the cases.

>>  but the capture application is not found anywhere.

> That's because there isn't an if_userappl option yet.

>>  And Wireshark does not show the IDB OS option anymore anywhere (yet?).

> It should.

Okay, I'll file a bug report for it to make sure it's covered.

>>  I have to admit that the latest PCAPng specs are a confusing in this
>>  point though - they state "format as for the EHB" (which is Hi-Lo,
>>  clearly), but the examples for the options mentions "Little Endian"
>>  and is given in Lo-Hi order (which contradicts the EHB order).

> Confusing, perhaps.

> *Ambiguous*, no.  Clearly, if the file is being written on a
> little-endian machine, the time stamp is in *middle-endian* format,
> with the upper 32 bits written out in little-endian fashion followed
> by the lower 32 bits written out in little-endian fashion.  If the
> file is being written on a big-endian machine, the time stamp
> *happens* to be written in big-endian format, but one shouldn't
> assume from that quirk that the value is a 64-bit writing-host-byte-order value.

Right, I didn't realize little-endian applies to the 32-bit parts. My
bad.

>>  But maybe there's a good reason for that kind of change to the
>>  timestamp order I can't see right now?

> If there's a good reason, it's also a reason to change the *major
> version number* of pcapng, with 1.x files having the time stamp
> written as two 32-bit values and 2.x files having it written as a 64-bit value.

Yes, it would be. As you already found out libpcap is writing the
values in the wrong order, so I think we don't need to touch the
PCAPng major version number.

Cheers,
Jasper

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature