Re: pcapng options

[Guy Harris <guy () alum mit edu>]

On Nov 1, 2012, at 7:45 PM, Richard Sharpe <realrichardsharpe () gmail com> wrote:

> I think editcap is correct. The options are listed as optional. Thus,
> in processing the block, if the block-length tells you that there
> cannot be any options, then you do not need to even process them.

Yes.

> However, the opt_endofopt option makes it easy when processing
> options. Of course it would be possible to keep track of the block
> total length and how much you have already processed, so in that sense
> it is redundant.

And, in fact, given that running past the end a block when processing it is a Very Bad Idea, it is not only *possible* 
to keep track of the block total length and how much you have already processed, it's *necessary* to keep track of the 
block total length and how much you have already processed if you don't want your code potentially pwned by a 
deliberately malformed pcap-ng file (or even just screwed up by an unintentionally malformed pcap-ng file).

> I guess the real question is:
>
> Is it legal to have a pcap-ng file that contains a block with options
> that does not contain an opt_endofopt option?

My inclination would be to say "yes", to indicate that option processing must stop when you reach the end of the block 
even if no opt_endofopt option is seen, but also indicate that option processing should stop when an opt_endofopt block 
is seen, even if there is more data remaining in the block.  So my inclination would be to say:

        option processing MUST stop when you run out of data in the block;

        option processing MUST stop when you see an opt_endofopt block;

        option lists that contain at least one non-opt_endofopt option SHOULD also have an opt_endofopt option at the 
end;

and possibly change the last SHOULD to MUST in order not to upset code that *doesn't* check for the end of the block, 
even if that code is insecure.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe