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

[Fulvio Risso]

Gianluca Varenni wrote:
> 
> ----- 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).

I completely agree on the additional statement you're proposing.
Cheers,

	fulvio

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