[pcap-ng-format] TODO in pcap-ng specifications

[Jasper Bongertz]

On 25.07.2012 03:50, Richard Sharpe wrote:

> However, I think that the document should state that there must be
> one and only one opt_endofopt at the end of a set options,
> otherwise it is not clear when the set of options ends. That is a
> difference from you say "only once, if at all."

My comment was based on the discussion that the "opt_endofopt" is kind
of unnecessary, because it can be deducted from the rest of the block
that there are options (or not). That is why I said "once" (if we want
that option to be available at all) or none.

> Secondly, I think that we have to make sure that the reference 
> implementation parses a pcap-ng file correctly that has multiple 
> instances of an option, and gives an error if an option that can
> only appear once appears more than once.

agreed.

> Unfortunately, we have to allow the existing implementations to 
> continue to work, so we might have to say that for 1.0, an 
> implementation is free to ignore all but the first or last instance
> of an option that has multiple instances in an options list. I
> THINK THIS ISSUE REQUIRES MORE DISCUSSION.

I'd go for the first, but right now I doubt there are many
implementations that use multiple instances anyway. pcap-ng is pretty
fresh and AFAIK no tool except now Wireshark (and the Hone project)
even used it so far.

> 2.6 Data Format
> 
> WRT the layout of 64-bit, 128-bit etc, I agree, however, I think
> there is a problem in the SHB in that the Block Total Length is
> not specified unambiguously, unless I have missed something. Since
> it is key to parsing the whole file, I think we should specify that
> these are in LE format. All other lengths must be in the format
> stipulated by the Byte-Order Magic, but in order to quickly make
> sense of a pcap-ng file, the endianness of the Block Total Length
> must be specified, unless we want people to use heuristics to
> figure out what the byte order of that field should be, or to read
> in the first twelve bytes, look at bytes 8 through 11 and figure
> out byte order from them, and then interpret the field correctly.
> However, if we want people to do that then we better say so and
> provide an outline of the steps.

I see the problem. We have a Block Total Length value that is read
before the Byte-Order magic is. I'm not sure how much trouble it is to
require a read of the Byte-Order magic first before interpreting the
Block Total Length. My implementation basically puts a record
structure over the Block, so I can easily read the Byte-Order magic
before interpreting Block Total Length. I'd like the specs to stay
consistent as much as possible, so in this case I lean towards having
people read the Byte-Order magic first indeed.

> 3.2. Interface Description Block.
> 
> SnapLen: Doesn't a value of 0 signal no limit? A capture where
> each record contains 0 bytes is not very useful ...

Yes, I think you're right, we could use 0. Any objections?

> Time Zone: We should check if there are standards around the 
> specification of time zones. The problem is that politicians keep 
> changing when DST starts and stops, so we need a correct
> mechanism.
> 
> WRT: UTC. I agree that it should be specified that times should be
> in UTC and that we need to add that.
> 
> QUESTION: What happens if a capture spans the change to or from
> DST? Is there a way to insert a record saying that the local time
> is now DST and it is offset by +-X minutes from the local
> timezone.

That is a topic that can induce bad headaches :-) I have no idea.

> The filter: Hmmm, being able to say, by the way, it was my special
> XYZ filter syntax that generated this capture might be useful for
> various people. However, I suggest leaving this topic for Version
> 2.0.
> 
> How about we add a section at the end that lists all the neat
> things that, in the interests of getting a spec finalized, were
> left until a later version.

Good idea. We should do that.

> if_tsoffset_low: I don't understand. At most, timezones are offset 
> from UTC/GMT by about 15-minute increments (although Iran seems to
> be different, but even then, is only minutes.) More than that, even
> if we allow for an offset down to seconds, there are about 86,400
> seconds in a day. I do not think anyone, even on the moon or out
> near Jupiter is going to be interested in nanosecond offsets,
> surely.

Maybe I misunderstood this option; I thought it is something to adjust
frame time stamps in case the capture system was slightly off, without
having to modify the original timestamp. Is this something that has to
do with time zones as well? If so, what is it good for? The
description text is not clear here - what does "obtain the absolute
timestamp" mean?

> 3.3 Enhanced Packet Block
> 
> First TODO (first bit vs first byte) Eliminate the TODO.

I think it is still in there, Guy spotted it while apparently we both
didn't. It is in the end of the second sentence, and I'll replace it
with "byte".

> C. I do not understand how a name resolution can be valid for a
> subset of the interfaces and not others.

Me neither. Maybe this idea of linking records to interfaces is a case
of uber-designing it a little :-)

> Remaining TODOs:
> 
> 4.3. Let's leave Encryption blocks to a future version.

Agree. Should be moved to the "things for later" section, just like
the compression block.

> 6. How to add Vendor/Domain Specific extensions.
> 
> I think we need to specify a mechanism for this in 1.0, or at the 
> latest in 1.1 so that we do not have too many incompatible
> versions out there. What do other people feel.

Yes, agreed, there needs some sort of procedure or mechanism for it.
We need to make sure that extensions make sense and do not clutter the
specs.

> Appendix D. Link Layer Headers.
> 
> I think we can fill this in easily ... perhaps.

If you could do it, be my guest :-)

> Thanks for going through this and pointing all of these out. It
> gives us something concrete to do for 1.0 and during the review
> process (for the changes) we might find other ambiguities.

Sure, no problem.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4484 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.winpcap.org/pipermail/pcap-ng-format/attachments/20120725/cc1dc0bd/attachment.bin>