On 3/8/11 10:08 , Seth Hall wrote:
On Mar 8, 2011, at 11:37 AM, Robin Sommer wrote:
I like switching from notice tags to a generic
conn id used
consistently across logs. My only request is that we make sure we can
identify a connection uniqule even across Bro runs. Then one can just
scan a whole log archive for a specific connection without needing to
worry about when Bro started etc.
What do you think about using UUID/GUID? I don't know about the overhead to create
those values and they're probably quite a bit larger than we need (128-bits displayed
as hex), but it would be interesting to be able to have unique values per run and per
instance. It'd end up being globally unique log identifiers. :) The length would be
pretty annoying though.
What sort of uniqueness are we aiming for here? I don't think that was ever very
clearly laid out in the previous thread. With GUID we could do uniqueness for eternity
(or close to it), but if we do something like hash the bytes for the $start_time timestamp
and the 4-tuple that may be unique enough for most cases. I don't know what the
relative overheads would be for generating that hash or the GUID would be either which
could be a concern.
I don't think we have to go that far. However, I think that using
128bits might be helpful. We could then have a 64-bit counter and
generate a 64bit Bro run-ID. We can then concatenate the two 64bit values.
This way there's pretty much no cost to create a new conn-id
Another small advantage is that this way, one could just strip the
run-ID, if one is only searching through the logs of single run. (or
there could be a flag to force the run-ID to be 0 for testing)
To get the run-ID we could use information like hostname, PID,
time-of-day, Bro's host-id-name (for cluster deployments), etc. and hash
them together using md5 or sha1 or something. (Or use GUID/UUID to
generate the runid and then only use the 64bits with most entropy).
just my 2ct
Int. Computer Science Institute (ICSI)
1947 Center St., Ste. 600
Berkeley, CA 94704, USA