Re: Proposed new pcap format

["Fulvio Risso" <fulvio.risso () polito it>]

Hi Jefferson.

> -----Original Message-----
> From: tcpdump-workers-owner () lists sandelman ca
> [mailto:tcpdump-workers-owner () lists sandelman ca]On Behalf Of Jefferson
> Ogata
> Sent: mercoledi 14 aprile 2004 1.10
> To: tcpdump-workers () lists tcpdump org
> Subject: Re: [tcpdump-workers] Proposed new pcap format
>
>
> Darren Reed wrote:
> > On the contrary, it's a trivial matter, really, to add more.
> >
> > Is there a "default" hashing method for SSL ?
> > Or IPSec ?
> > Or S/MIME ?
> > No.
> >
> > In each case the specification defines support for a number of different
> > hashes, of varying strengths and the choice is left to the end user to
> > decide on what they wish to use.  I don't see why libpcap should be any
> > different.
>
> Something keeps bugging me, and I just want to throw it out there for
> the mad dogs to tear into little bloody pieces:
>
> Given all the desirable options people are looking for in this, and the
> need for future growth, I think we should seriously consider an
> XML-based format. Besides making it easy, format-wise, to include many
> optional features and types of metadata, programs could also embed
> decoded frame and protocol information in appropriate elements, right
> within the capture file.
>
> <capture ...>
>    <!-- a decoded frame -->
>    <frame timestamp='1081896827.110627' length='142' snaplen='70'>
>      <ethernet src='00:03:47:01:02:03' dst='00:03:47:04:05:06'
> type='0x0800'>
>        0003470102030003470405060800
>      </ethernet>
>      <ip vers='4' hlen='20' ... flags='0x04' ... proto='17'>
>        45000080...
>        <udp sport='781' dport='2049' cksum='0xae49'>
>          030d0801...
>          <nfs op='READ' fh='0130493022...' offset='16384'>
>             ...
>          </nfs>
>        </udp>
>      </ip>
>    </frame>
>
>    <!-- an undecoded frame -->
>    <frame timestamp='1081896827.113144' length='80' snaplen='70'>
>      000347010203000347040506080045000080...
>    </frame>
>
>    ...
> </capture>
>
> Yes, fully fledged decoded captures would use a lot of extra disk, but a
> raw no-frills capture could be recorded with maybe only 50% or so
> overhead.
>
> Processors using xslt or custom code could pull out just what they're
> interested in using XPath expressions. Decoders for specific application
> protocols could be written as filters to produce decoded elements in the
> output XML.
>
> And so on... mull it over for a minute before you start shredding.

I agree that this is important (for instance, we're defined the XML format
more than one year ago).
However, I would prefer to keep things simpler: we're going to define a new
binary format.
Let's do that.
Then, we can define / improve / whatever the XML one.

        fulvio

-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.