tcpdump mailing list archives
Re: Proposed new pcap format
From: Michael Richardson <mcr () sandelman ottawa on ca>
Date: Tue, 20 Apr 2004 10:02:41 -0400
-----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.
Current thread:
- Re: Proposed new pcap format, (continued)
- Re: Proposed new pcap format Loris Degioanni (Apr 13)
- Re: Proposed new pcap format Fulvio Risso (Apr 13)
- Re: Proposed new pcap format Hannes Gredler (Apr 14)
- Re: Proposed new pcap format Fulvio Risso (Apr 14)
- Re: Proposed new pcap format Ronnie Sahlberg (Apr 11)
- Re: Proposed new pcap format Loris Degioanni (Apr 13)
- Re: Proposed new pcap format Fulvio Risso (Apr 13)
- Re: Proposed new pcap format Michael Richardson (Apr 16)
- Re: Proposed new pcap format Guy Harris (Apr 21)
- Re: Proposed new pcap format Darren Reed (Apr 22)
- Re: Proposed new pcap format Jefferson Ogata (Apr 22)
- Re: Proposed new pcap format Darren Reed (Apr 22)