guyharris
commented
5 years ago Fixed-length options whose length isn't the length specified in the spec are invalid.
For variable-length options, we should specify a minimum length, which could be zero, but which might be non-zero for some non-string option types, such as if_filter, where the minimum length is 1, not 0, as the filter type must be included. Options less than the minimum length are invalid.
We should, however, indicate how a zero-length string or a minimum-length option should be interpreted.
For example, if shb_os isn't present, the file doesn't say what OS the machine was running, but if it's zero-length, whatever program wrote the file chose, for better or worse, to say the OS is "" - content-free, but specified.
For strings in NRB nrb_record_ipv4 or nrb_record_ipv6 records, we could either declare empty strings as invalid or as not to be included as a name for the address (so that, for example if you have only an empty string, you have no translation for the name, and if you have a non-empty string and an empty string, the only translation is the non-empty string).
Those could, perhaps, be used to indicate that the information was censored (unless "this information was present at one point, but it's been censored" would constitute a covert channel or some other way in which information that shouldn't be available is leaked).
I'll update the spec to include minimum lengths for variable-length options, and specify that a fixed-length option with a length not equal to the specified length, or a variable-length option with a length less than the minimum length, is invalid.
[from an issue raised inside the doc by me:]
For example just a zero byte for the nrb_record_ipv4/v6 name string portions; or not even a zero byte for something like opt_comment or if_description.
I would argue they are valid. Certainly pcapng readers should gracefully handle the case, but I think it is even legitimate for pcapng writers to generate it.