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

[Gianluca Varenni]

----- Original Message ----- 
From: "LEGO" <luis.ontanon at gmail.com>
To: <ntar-workers at winpcap.org>
Sent: Thursday, May 11, 2006 10:41 AM
Subject: Re: [ntar-workers] Use of the application-specific blocks in 
thepcap-ng file specification


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

Do you mean something like a block that describes the app-specific block 
type codes used within the file with a name? Something like

APP_SPEC_BLOCKS_DESCRIPTION_BLOCK

Block type code = X  name="This is block with code X created by company Foo"
Block type code = Y  name="This is block with code Y created by the same 
company Foo"
.....

end of APP_SPEC_BLOCKS_DESCRIPTION_BLOCK

???

If so, my first reaction is that it doesn't help too much in solving the 
problem: maybe I'm completely wrong, but it seems to me we are just moving 
the problem from the uniqueness of block codes to the uniqueness of the 
names describing the codes.

In any case, I want to think a bit about this proposal, maybe I'm wrong...

Have a nice day
GV




>
> 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
>
> _______________________________________________
> ntar-workers mailing list
> ntar-workers at winpcap.org
> https://www.winpcap.org/mailman/listinfo/ntar-workers