Re: Proposed new pcap format

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

Hi.

> -----Original Message-----
> From: tcpdump-workers-owner () lists sandelman ca
> [mailto:tcpdump-workers-owner () lists sandelman ca]On Behalf Of Loris
> Degioanni
> Sent: martedì 13 aprile 2004 20.23
> To: tcpdump-workers () tcpdump org
> Subject: Re: [tcpdump-workers] Proposed new pcap format
>
>
> Hi,
>
>
> > In some email I received from Loris Degioanni, sie wrote:
> > [ Charset ISO-8859-1 unsupported, converting... ]
> > > Ok, I'm going to add a 8-byte hash option for the packet block. Can
> anybody
> > > suggest the hashing algorithm?
> >
> > You obviously sent this before reading another email I sent on this.
> >
> > Today, some people might want MD-5, others SHA-1 and in the future,
> > there may be other hashing algorithms that are better to use.  And
> > there are times when we might want it off (algorithm 0, for example.)
> >
> > As such, I believe this option should be a (type,value) pair, if we
> > can agree that the hash value in the option header is a hash over the
> > entire record returned by the kernel (with the value of the hash set
> > to 0.)  And yes, the kernel computes the hash.
>
> I agree, but since we a are trying to define a standard,

I don't think the IETF is willing to define a standard for this.
I feel better to say "we would like to document the new file format used by
libpcap".
There are already examples of this in the IETF (e.g. RFC 1761 "Snoop Version
2 Packet Capture File Format").


> we
> probably want to
> define a default hashing method. The main reason is that I don't
> think we'll
> be able to include in libpcap (and possibly the capture drivers)
> the support
> for 6 or 7 different methods, so maybe we could choose one.

In IETF usuully there is an option which is "mandatory" (often the simplest
one), while the remaining are "optional".

        fulvio

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