Perhaps we should just change the default?
Then you would only instantiate on connections with a full handshake.
Right, that was the intent of the original question, wasn't it?
No, it was about the connection established event, IIRC. In case the
conn compressor is disabled, TCP.cc would generate the
connection_established event on a pure SYN/ACK while the conn compressor
would not do this. (If the "connection" has other packets in it, the
conn compressor would instantiate a connection, pass it to TCP and thus
the connection_established event would be generated.)
The tcp_SYN_ack_ok and partial_connection_ok will prevent any connection
without full handshake to be processed by bro. I don't think that we
want this as default. I think that the current default, namely that bro
tries to parse partial connections is better.
option wouldn't necessarily change event generation
either, I think.
I think it would. If there's no connection state, there's no
Actually that's true, if there's no Connection instance, there's no TCP
Analyzer so no event can be genreated.
We just have
to unify the way the connection_established event is
generated in TCP.cc and Connection Compressor.
Note that the CC doesn't generate connection_established itself. It
acts as a filter: once it lets packets through, TCP.cc will generate
Also, I'm thinking there might actually be a bug in the CC here (or
at least semantics not originally intended): it has an option
cc_handle_only_syns that, if on, tells it to take care only of
initial SYN packets and forward everything else (e.g., a stray data
packet) to normal processing. The motivation for this was to have
less difference to normal TCP processing when the cc is on, and it's
per default enabled (bro.init calls this mode "connection compressor
Hmm. My intuition would have been that SYN/ACK also count here...
However, it turns out that a SYN/ACK counts here and
by the CC, rather than being passed on. If we would change that so
only pure SYNs were handled, we shouldn't see a difference between
cc on vs. off anymore in this case.
Correct. However, one can also argue that the "instantiate if we see a
packet from each endpoint" makes sense in order to not instantiate on
scans or floods, but instantiate if we "just" miss part of the handshake.
I guess the questions are:
* what is the semantic of the connection_established even? If we've
defined that, we should unify CC and non-CC behavior.
* what to do with partial connections or connections that start with a
SYN/ACK (and that have further data packets).
* what to do with connections that only have a SYN/ACK.
Gregor Maier gregor(a)icir.org
Int. Computer Science Institute (ICSI) gregor(a)icsi.berkeley.edu
1947 Center St., Ste. 600 http://www.icir.org/gregor/
Berkeley, CA 94704