Wireshark mailing list archives
IETF standard? [was Re: pcapng options]
From: Marc Petit-Huguenin <marc () petit-huguenin org>
Date: Fri, 02 Nov 2012 06:47:30 -0700
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 11/02/2012 06:17 AM, Jasper Bongertz wrote:
On 02.11.2012 04:23, Guy Harris wrote: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.I agree. The opt_endofopt is a nice-to-have in my eyes, because - as Guy said - you need to check that your code is not running past the end of a block anyway, and that requires keeping track of where you are. I think we can go for a "MUST" on the last one as well; code that reads pcap-ng still has to expect that there is no opt_endofopt because of the first rule.
Thanks everybody for your answers, I now know what to do. But I think that this kind of redundancy, that can only create interoperability issues or security vulnerabilities, should not appear in a newly designed file format. Is there a process existing to evolve this format? The spec has been written with IETF tools, but I cannot find a submission for it. I can help navigate the IETF process if there is an interest in pushing this spec as a standard. I think that this is typically the kind of thing that can be improved by the reviews from IETF members, and IANA is a good place for the various registries required. - -- Marc Petit-Huguenin Email: marc () petit-huguenin org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJQk87wAAoJECnERZXWan7EPioQAKfrD5E9A/DLaokPEuqwqSkr EgD9Oq6HgVI+lng07CWyi+Mbvol/xVzyidVmnLW16CPQEmu+zpTJPRIjzphSZ6i3 3jQpzC/5A8gvYRrK4Hss+yYAxynv0dQyM6lXoR7utLIQajusp7oDgjni7BMhX/HF ytiqxmMPH/9naXfk2KVlKp6ICMY34eAIV0ycia9gsDTvkgQeRfzMYBgfhoITf8Fn +SdyumrmXensxSRzpiMsPFrKDaVycbYRFuabz84WkVJpz+CZnwSNA7mRYvFZQXcI aSFuP6FSZobG7QHL8sPJwjVnY20L6yCwYU+JF60ux9LKX6o+kAqRTs2nd0b0eMHs Lnma+wwUydn/AM4rhulazACPB4cX3I/9Ab8rCHYRLLLD7Sf9kkWd+AmqzAgNiSxE aa8ZUBMYcFCRQ3YJHsVwMCfTdvtiT+p+364JFyor5uDtlw5Gs90f3NM/aSt9rBOB IpkVm6TWMllNgOoxqBH0O2QcmSMetSRJVmmMhqwLRO6qxubIm5s6jAArgBaFTUom bybTqIgVv1gKu7gybclAnyAWsyFgIrx0wVH18Al2rAUYzZiPcwJqZEYm6zK/z3Wt lqc0j/MyZ9VxiW6hEJpbvk9nWuMS7ofkG1nIawz2tq+LyVFRKQMrevwiMGI9U1FN 8eqxS5pfUHxNiY6y295r =l5gy -----END PGP SIGNATURE----- ___________________________________________________________________________ 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
Current thread:
- pcapng options Marc Petit-Huguenin (Nov 01)
- Re: pcapng options Richard Sharpe (Nov 01)
- Re: pcapng options Guy Harris (Nov 01)
- Re: pcapng options Jasper Bongertz (Nov 02)
- IETF standard? [was Re: pcapng options] Marc Petit-Huguenin (Nov 02)
- Re: IETF standard? [was Re: pcapng options] Guy Harris (Nov 02)
- Re: IETF standard? [was Re: pcapng options] Marc Petit-Huguenin (Nov 02)
- Re: IETF standard? [was Re: pcapng options] Michael Tuexen (Nov 02)
- Re: pcapng options Guy Harris (Nov 01)
- Re: pcapng options Richard Sharpe (Nov 01)