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

[Gianluca Varenni]

----- Original Message ----- 
From: "Fulvio Risso" <fulvio.risso at polito.it>
To: <ntar-workers at winpcap.org>
Sent: Thursday, May 11, 2006 10:19 AM
Subject: Re: [ntar-workers] Use of the application-specific blocks in 
thepcap-ng file specification


> Guy Harris 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.
>
> This was exactly my intention when we defined application-specific blocks.
> Probably this kind of blocks might be renamed in "private blocks" or 
> something like that. They should be used when someone needs to define a 
> new block that will never go public, hence it needs an (hopefully) unique 
> code for identifying the new block. If your application goes public and it 
> needs to define a block for its purposes, it should ask for a new "public" 
> block code.

I think that renaming the app-specific blocks to private blocks makes sense. 
Moreover, I would add a big note clearly stating that choosing a private 
block (instead of requesting a public block type code) can be potentially 
dangerous, and it should be done *only* if you are 100% sure that those 
blocks should never be read by another pcap-ng aware application (i.e. if 
you use a private block, you might easily incur into interoperability 
issues, be warned).

Have a nice day
GV




>
> By the way, this is how local MAC addresses work.
>
> Cheers,
>
> fulvio
>
>
>
>
> _______________________________________________
> ntar-workers mailing list
> ntar-workers at winpcap.org
> https://www.winpcap.org/mailman/listinfo/ntar-workers