Does anyone know of work that involves placing hard limits on the amount of time bro is able to spend processing individual packets? Specifically, I'm looking for:
* work toward putting hard limits on the number of cycles Bro is allowed to execute per-packet before injecting a hard stop and forcing the engine to move to the next packet, or
* work toward emulating buffers / drops based on the number of cycles bro spends processing a particular packet in offline / pseudo-realtime mode
* work toward putting hard limits on the number of cycles Bro is allowed
to execute per-packet before injecting a hard stop and forcing the
engine to move to the next packet, or
Unless things have changed, that instead is a global timer which kills Bro
(rather than skipping to the next packet) if that much time has elapsed
and it hasn't gotten past the current packet.. The notion is that Bro has
become wedged and needs a hard recovery.
Aashish: not quite what I'm looking for, but I do appreciate the link! I would be looking for something with higher resolution (usec / msec) that doesn't stop bro when the timer fires.
Vern: yeah, that's still the case as far as I know.
I was thinking one way to gracefully address performance issues might be to say that bro would be allowed to spend X cycles processing a specific packet, where X was a number determined by examining e.g. the current state of the network buffer + the historical packet rate / size. Enforcing a cut-off after X cycles could provide a way to dynamically scale the depth of the analysis to cope with additional load in lieu of completely dropping packets.
Could be that this is a terrible idea, but was just doing some homework / reading and thought I'd ask to see if anyone could point me to work along these lines (or possibly explain why the ideas are not good ones :).
Regardless, thank you for taking the time to follow up!
For performance concerns, it's not clear that individual packets are the
right granularity to examine. For example, if you stop processing one
packet you might be giving up on any subsequent analysis for the remainder
of its flow, which can have a large amplifying effect (or not) depending
on the size of the flow.
Ah! I don't think I've actually read this paper before, but if my quick skim is correct, this paper is where the old load-level.bro script came from, right? I've been wanting to bring that capability back in some form for a long time (and I've even written a couple of draft modules at various points in time).
... but if my quick skim is correct, this paper is where the old
load-level.bro script came from, right?
Yes, basically. That paper documents a bunch of our experiences, including
load-level. I think we wound up being torn between the need for it versus
the notion "if you need it, what you really need is a bigger cluster".
There are tons of incredibly useful features in Bro. Its always interesting to see the research papers those features came from. I’m referring to table expiring attributes in this case.
Its also interesting to read that connection timers are only disabled at connection state removal. Are they periodically removed similar to hash table resizing in figure 3? In any case, it’s smart that their removal comes second to packet processing.
If I recall that correctly, they used to be only disabled, but then
the change was to actually now remove them immediately to avoid
accumulating stale timers in memory. A single removal is pretty fast
due to the underlying data structure, and these operations amortize
over time, with no need for something like the hash table resizing.