[ntar-workers] Use of the application-specific blocks in the pcap-ng file specification

[LEGO]

What about a specific block, like the one for interfaces, to introduce
type block numbers by an with application-specific name?

L

On 5/11/06, Guy Harris <guy at alum.mit.edu> wrote:
>
> On May 10, 2006, at 9:12 PM, Gianluca Varenni wrote:
>
> > We discussed a bit about possible solutions, and basically it seems
> > that the best way to solve this issue is to
> > 1. deprecate the use of app-specific blocks (in the sense that
> > applications should not create their own block type values, if they
> > want to create a portable pcap-ng file)
> > 2. create some sort of unique repository of block type values. If
> > an app needs to define a new block, it just needs to ask a new
> > block code value to the repository. The LINKTYPE/DLT values for
> > libpcap (and the future LINKTYPE values for pcap-ng) work in this
> > same way.
> >
> > This approach seems to be the most straightforward, at the expense
> > (of course) of maintaining a public and centralized repository for
> > the block type codes.
>
> Note that if the developers of an app want to define a proprietary,
> private block type, they could do so, even with a public repository
> for the block type codes.  The repository merely needs to allow app
> developers to request a block type code without specifying anything
> other than, perhaps, their name, and that block type code would be
> marked as "reserved for XXX".  The DNS-SD registry of service types:
>
>         http://www.dns-sd.org/ServiceTypes.html
>
> allows that, as does tcpdump.org's registry of DLT_ types (and the
> latter registry has some private types of that sort registered
> already).  The registry could even, I guess, allow the name of the
> requester to be kept secret, if that's really necessary.
>
> This would make the app-specific block types similar to the DLT_USERn
> types in the tcpdump.org registry - no guarantee can be made that a
> file using an app-specific block type can be read safely and
> correctly by any apps other than apps specifically written to
> interpret that block type in the fashion in which it's used by the
> file, just as no guarantee can be made that a libpcap file using a
> DLT_USERn link-layer type can be read safely and correctly by any
> apps other than apps specifically written (or configured) to
> interpret that DLT_ value in the fashion in which it's used by the file.
>
> In other words, if you want to use app-specific block types
> internally, with some internally-developed tool, and never provide to
> anybody files using them if you don't know whether they'll try to
> read them with their own internally-developed tools (and don't ever
> expect tcpdump, Ethereal, etc. to interpret them in the right fashion
> for your file), you can use them.  Otherwise, request a standard
> block type.
>
> _______________________________________________
> ntar-workers mailing list
> ntar-workers at winpcap.org
> https://www.winpcap.org/mailman/listinfo/ntar-workers
>


-- 
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan