[Bro-Dev] connection_established behavior

[Gregor Maier]

>>> 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.

>> Changing this option wouldn't necessarily change event generation
>> either, I think.
> 
> I think it would. If there's no connection state, there's no
> connection_established. 

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
> the event.
> 
> 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
> light").

Hmm. My intuition would have been that SYN/ACK also count here...

> However, it turns out that a SYN/ACK counts here and *is* processed
> 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.


cu
Gregor
-- 
Gregor Maier                                             gregor at icir.org
Int. Computer Science Institute (ICSI)          gregor at icsi.berkeley.edu
1947 Center St., Ste. 600                    http://www.icir.org/gregor/
Berkeley, CA 94704
USA