[pcap-ng-format] Proposal for new "custom" option codes

[Guy Harris]

On Jul 22, 2015, at 6:54 AM, Hadriel Kaplan <the.real.hadriel at gmail.com> wrote:

> I'd like to propose a couple new option codes be allocated for a
> "Custom String Option" and "Custom Binary Option", and the format be
> specified/added to the draft.

And the rationale for this is?

Is the idea that this would be the right way for a vendor to implement vendor-specific options, rather than picking a random option number with the MSB set (which means there's a risk of collision between vendor-specific options) or requesting that the pcap-ng maintainers allocate an option for them (which means more process to go through)?

If so, that sounds reasonable, for the reasons given in the parenthetical notes in the previous paragraph, and because, at least for text options, your proposal at least allows the text to be displayed, even if the program displaying it doesn't know its significance.

One problem with binary options, however, is that, if it contains values where byte order matters (integral or floating-point values larger than one byte), and a file written by a machine with one byte order is read, processed, and written by a machine with the opposite byte order (we ignore the PDP-11 here, which we can probably safely do :-)), unless the program writing it understands the binary option in question (either with built-in code or plugins), it can't write the option in question out and have it be properly interpreted by some other program, as the byte order of the data in the option will no longer match the byte order specified by the SHB of the section containing it.

This is not, of course, only a problem with the proposed Custom Binary Option.  Presumably we should just say in the spec that a program that's reading a pcap file and writing it out should *not* write out any block types or options that it does not understand (it *could* understand a Custom String Option, to the extent that it can display it as a string, so that can be written out) - that does mean information is lost, but, until x86 and ARM have crushed all other architectures and seen them driven before them, it gets lost *anyway* in the preceding scenario, as the binary data will be in the wrong byte order and will be misinterpreted.