Re: Proposed new pcap format

[Michael Richardson <mcr () sandelman ottawa on ca>]

-----BEGIN PGP SIGNED MESSAGE-----


> > > > > "Darren" == Darren Reed <darrenr () reed wattle id au> writes:
    Darren> In some email I received from Guy Harris, sie wrote:
    >> On Apr 13, 2004, at 3:38 PM, Darren Reed wrote: > 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.
    >> 
    >> If the hash value is generated by the application, that's the
    >> case.
    >> 
    >> If it's generated by the kernel or libpcap, then the end user
    >> might not have much of a choice - they're stuck with what the
    >> kernel or libpcap provide.

    Darren> I'm thinking, here, that when the user turns this on via an
    Darren> ioctl, they can request which hash algorithm to use.  The
    Darren> worst that can happen is the kernel says "sorry, don't
    Darren> support that algorithM" and the user tries again with
    Darren> another.  Similarly, the user should be able to query this
    Darren> setting.

  Darren, I'm still not sure that I understand why the kernel should do
this. I thought at first it was because you wanted a hash of the entire
packet, rather than just the snaplen.
  (To me, this made a LOT of sense, so I don't understand why you
wouldn't want the kernel to hash the entire packet)
  
  Now I don't understand - why should the kernel do this? On a
uniprocessor the effort is the same, except that the real-time
latency will go up if the kernel isn't pre-emptive. (*BSD isn't,
2.4 Linux isn't, etc..). On a multiprocessor, it seems that having the
kernel do the work is a further loss vs having a possibly-thread-safe
libpcap do the work. 
  The only benefit that I can see is if you have hardware that can do it
(vs special instructions in your CPU). I'm not aware of any MACs that do
this kind of thing, although I imagine a number of them have upgradable
(by the manufacturer) firmware. It doesn't seem worth the PCI
transactions to have a hardware crypto chip do the work either.

  Instead, it seems to me that this is something which can even be done
offline in non-real time.

    >> I think Loris is saying that, for hashes generated by the kernel
    >> or libpcap we probably aren't going to provide the full panoply
    >> of hashes

    Darren> Does this mean they don't get enumerated or just not coded ?

  In the context of this meta-data container, we/you can enumerate as
many as you like.

    Darren> In terms of code, I think I'd like to see three available:
    Darren> none, a weak/cheap one and a cryptographically secure one.

  okay.

    >> That might not require us to choose a default, however, as long
    >> as the kernel can tell libpcap which hash value it's providing
    >> (if any).  It might, however, mean that we should choose a hash
    >> value that, for kernel hashing, is considered "adequate", and
    >> recommend that capture mechanisms implement it.

    Darren> Yes, I like that approach.  My objection is to their being a
    Darren> "default" (aside from not having one) that everyone is
    Darren> expected to use/support, regardless of others.

  Since the file could be re-processed, I'm not sure if we need a default.

- --
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] mcr () xelerance com      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBQH/sDYqHRg3pndX9AQH9zgQAmYKLSX4ALrsfU1ShMRIRdapI/JHgjpNj
cwnPB37fZGTGeHtr6d+gpyMVUMJHReePQhIixAAE/y9K/Pzyjze3Qr1tgjF0WLzC
SuqxC+aX//Bb90G+L6JRzU+8C6Vi0pXGGoe8tKw3U2yi8mgskmxZlHLWpGajHtY7
GLHE8uIst4o=
=tdH7
-----END PGP SIGNATURE-----
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.