[pcap-ng-format] Comments for unknown blocks [was Re: opsarea presentation?]

Michael Tuexen tuexen at wireshark.org
Tue Jul 29 12:29:22 UTC 2014 

On 29 Jul 2014, at 14:18, Anders Broman <anders.broman at ericsson.com> wrote:

> 
> 
> -----Original Message-----
> From: pcap-ng-format-bounces at winpcap.org [mailto:pcap-ng-format-bounces at winpcap.org] On Behalf Of Michael Tuexen
> Sent: den 29 juli 2014 11:52
> To: Pcap-ng file format
> Subject: Re: [pcap-ng-format] Comments for unknown blocks [was Re: opsarea presentation?]
> 
> On 28 Jul 2014, at 21:09, Marc Petit-Huguenin <marc at petit-huguenin.org> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>> 
>> On 07/28/2014 08:08 AM, Fulvio Risso wrote:
>>> Answering to everybody with a single mail.
>>> 
>>> 1) to Michael:
>>>> if a company is not concerned about collisions, they can just use 
>>>> one of the private blocks, if it is, it just gets one from IANA. > 
>>>> This is
>>> very simple and a matter of days normally.
>>> 
>>> Completely agreed.
>>> 
>>> 
>>> 2) To Guy: The OUI proposal was just to avoid that people have to ask 
>>> a code to the pcap-ng folks. As this group is currently run by 
>>> volunteers, we cannot be sure that somebody will still be here in 20 years from now.
>>> Relying on an external (and hopefully, solid) organization makes me 
>>> more confident that the process can continue. However, I was not 
>>> aware of the costs for getting an OUI, actually. Perhaps those are a 
>>> little bit too expensive.
>>> 
>>> 3) To Anders. The proposal to use the enterprise numbers of the IANA 
>>> makes perfectly sense to me. No idea about costs and/or obligations.
>> 
>> I got an enterprise-number (40544), it's free and very easy to get.
> Hmm. This is from MIBs. Does enterprise-number have a fixed length?
> 
> 
> Well it's used in a number of protocols - Diameter is one example.
>> Anders: I don't understand your suggested packet format...
> 
> I was hoping to avoid doing ASCII art... basically it's a new blocktype following the convention of other pcap-ng blocks.
> The aim is to have a Vendor indicator and the vendor data. One option is to have a tag indicating what form the vendor
> Indicator takes like OUI, enterprise-number a plain string or...
OK. I like this idea. It is pretty generic...

Anyone against adding it?

Best regards
Michael
> 
>      0                            1                           2                             3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> w0:|   Block type (To be assigned ) of Private block
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> w1:|   Block total length
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> w2:|   Vendor indication type ( 1 = OUI, 2 = enterprise Id, 3 = Text string , ....    
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> w3:|   Vendor indication length       
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> w4:/  Vendor ID padded to 32 bit boundary
>      /
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |   Vendor data length
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      /   Vendor data
>      /
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      /                      Options
>      /
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                 Block total length
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> All: The simplest way would be just to open the registry of the block type an a first come, first get policy. Since we have 32 bit, I think that is doable. This also would not require using MIB registries...
> 
> Best regards
> Michael
>> 
>>> Not sure I've understood your proposal for the bits splitting, though 
>>> :-(
>>> 
>>> fulvio
>>> 
>>> 
>>> 
>>> On 28/07/2014 12:59, Anders Broman wrote:
>>>> Hi, For Vendor specific blocks why not use 
>>>> http://www.iana.org/assignments/enterprise-numbers or our own 
>>>> registry or a name string/magic number Or allow more than one option 
>>>> by assigning different tags.
>>>> 
>>>> Something like 0 -31 0 | Block Type = TBD ( Private block type ID ) 
>>>> 4 | Block total lenghth 8 | Vendor ID Type TAG
>>>> /* OUI/enterprise Id/String/../ */ 12| Vendor ID Type TAG length 16|
>>>> Vendor data Length 20| Vendor data (Opaque) X   | pcap-ng specified
>>>> options X+m | Block total lenght
>>>> 
>>>> Perhaps two vendor/private blocks one per file and one intermingled 
>>>> with packet blocks ?
>>>> 
>>>> Just my 2 c Regards Anders -----Original Message----- From:
>>>> pcap-ng-format-bounces at winpcap.org
>>>> [mailto:pcap-ng-format-bounces at winpcap.org] On Behalf Of Guy Harris Sent:
>>>> den 28 juli 2014 11:52 To: Pcap-ng file format Subject: Re:
>>>> [pcap-ng-format] Comments for unknown blocks [was Re: opsarea 
>>>> presentation?]
>>>> 
>>>> 
>>>> On Jul 28, 2014, at 2:35 AM, Michael Tuexen <tuexen at wireshark.org>
>>>> wrote:
>>>> 
>>>>>> This raises in fact another question: it may be useful, in unknown 
>>>>>> blocks, to reserve some space for something like a company ID, 
>>>>>> more or less the same way used to define the Ethertype in Ethernet 
>>>>>> LLC/SNAP (you have to specify the company OUI, which gives you the 
>>>>>> meaning of the ethertype field). For me, given that we have 32 
>>>>>> bits for the block ID, we can reserve 24 for the company OUI, 
>>>>>> leaving 7 bits for custom-made fields (the last is used to say 
>>>>>> that this is a private block).
>>>>> 
>>>>> That requires that the company has an OUI...
>>>> 
>>>> And the organization might not be a company.
>>>> 
>>>> And an OUI is cheap at, err, umm, 1/100 of the price:
>>>> 
>>>> http://standards.ieee.org/develop/regauth/oui/index.html
>>>> 
>>>> "This product was previously referred to as an OUI (Organizationally 
>>>> Unique Identifier) and is still referred to as such in many standards.
>>>> OUI is an IEEE Registration Authority (RA) specific term that is 
>>>> referred to in various standards and may be used to identify 
>>>> companies on the IEEE Public Listing. A MA-L assignment includes an 
>>>> OUI and the right to generate various extended identifiers based on 
>>>> that OUI. It is most often used to create IEEE 802-defined MAC addresses (EUI-48 and EUI-64)."
>>>> 
>>>> And a public MA-L costs USD 2500.  (And that's if you don't want to 
>>>> keep the assignment private; *that* costs an addition USD 2890 *per 
>>>> year*.)
>>>> 
>>>> A "company ID", however, is only USD 625 (plus, if you want it kept 
>>>> private, USD 1015 per year):
>>>> 
>>>> http://standards.ieee.org/develop/regauth/cid/index.html
>>>> 
>>>> They're not exactly heavily used:
>>>> 
>>>> http://standards.ieee.org/develop/regauth/cid/cid.txt
>>>> _______________________________________________ pcap-ng-format 
>>>> mailing list pcap-ng-format at winpcap.org 
>>>> https://www.winpcap.org/mailman/listinfo/pcap-ng-format
>>>> _______________________________________________ pcap-ng-format 
>>>> mailing list pcap-ng-format at winpcap.org 
>>>> https://www.winpcap.org/mailman/listinfo/pcap-ng-format
>>>> 
>>> _______________________________________________ pcap-ng-format 
>>> mailing list pcap-ng-format at winpcap.org 
>>> https://www.winpcap.org/mailman/listinfo/pcap-ng-format
>>> 
>> 
>> 
>> - --
>> Marc Petit-Huguenin
>> Email: marc at petit-huguenin.org
>> Blog: http://blog.marc.petit-huguenin.org
>> Profile: http://www.linkedin.com/in/petithug
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>> 
>> iQIcBAEBCAAGBQJT1p/jAAoJECnERZXWan7EKzsP/0823XmpzaKOhKZWcv3Zg99B
>> Jqp+vW5NUwywwP5FAe+hJYxePJyD9u77gUY/rs6donm8PAdbppiINIzJlkyP9Yf0
>> tiw+vgWyCxrYQVCjSrvNOvD1XCxo9PxNJvcYv4UAgAOOOuGObfv0EFvISLcxEmJh
>> H51/m1Hv3OG/vx63swMCL9OrKb0uj/TVQJQm3JwXkBhqTKg+CdggmV3YXZDj21Mn
>> Z41XozvwuogRA7kOBWgxfWrnqX58ReZpsdv7H1u9VxrvCHnjtBYJYcAKhzbN3/Y9
>> qMCOODBMIxHZUJ+idlpwNNo1V6GTtDCcrUJZa+yjO6O83Ola+UA0zrCLfSF1gk+4
>> 0w+27eTPjTWI+3+Zkq4aROfnJBjP5Ynd2BUnw0GPxxAfEvKfG5dZ4EUos5QFipkm
>> 54Xorxx7hNfJ2RLDNuvX6v9HKCO9PNBBFTDMFxqyUbfdykjrq5YL2QvecPZ3I/gS
>> E/GVpEB1HUSJVCS6IOkf+HsFT6y4y4uJOnX47LuYdJycE0lT8Z3p3U1jR1Fw3QYG
>> pr/BEVA6uUWDTEHufLIidxbqeL8/8LEM7Ee97+JK8C4bbQCxJksmUdxk4MYTFe8i
>> PzhokY0rphB2f76GOOw33N/djaDIgA6Bsx0/SgjqA2nOs17qxNkatmRRA+hToAXm
>> YsKxPb9/YE1S5/PZT94M
>> =D5qF
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> pcap-ng-format mailing list
>> pcap-ng-format at winpcap.org
>> https://www.winpcap.org/mailman/listinfo/pcap-ng-format
>> 
> 
> _______________________________________________
> pcap-ng-format mailing list
> pcap-ng-format at winpcap.org
> https://www.winpcap.org/mailman/listinfo/pcap-ng-format
> _______________________________________________
> pcap-ng-format mailing list
> pcap-ng-format at winpcap.org
> https://www.winpcap.org/mailman/listinfo/pcap-ng-format
>

More information about the pcap-ng-format mailing list