Re: Proposed new pcap format

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

> -----Original Message-----
> From: tcpdump-workers-owner () lists sandelman ca
> [mailto:tcpdump-workers-owner () lists sandelman ca]On Behalf Of Darren
> Reed
> Sent: mercoledi 14 aprile 2004 0.38
> To: tcpdump-workers () lists sandelman ca
> Cc: tcpdump-workers () tcpdump org
> Subject: Re: [tcpdump-workers] Proposed new pcap format
>
>
> In some email I received from Loris Degioanni, sie wrote:
> > > 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, 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.
>
> 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.

Just because you're increasing the entropy of the system.
If everything is "optional", two compliant implementations cannot exchange
data.
I prefer to define one as "mandatory", and the remaining as "optional".

        fulvio

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