[Bro] TCP normalization and reassembly decision
haoscs at gmail.com
Mon Nov 13 21:10:35 PST 2017
Thanks for your sharing the example code, Christian!
It also explains that at least the rule 3 in Vern's paper cannot be
implemented since it has to be operated in in-line mode. But how the first
For rule 1 (limit the buffer of per-connection), is the rule implemented in
current Bro and does the 100KB buffer of per-connection hold?
For rule 2 (randomly evict connections), given we typically have
capture_loss and dropped_packets which reflect Bro's behavior, is there any
rule on the connection-level when Bro evicts connections?
On Mon, Nov 13, 2017 at 8:44 PM, Christian Kreibich <christian at corelight.com
> Hi Shuai,
> On 11/13/2017 02:30 PM, Shuai Hao wrote:
>> In /src/analyzer/protocol/tcp/tcp.cc, I find a comment "we could be
>> by an inconsistent SYN retransmission. Where is a normalizer". So I assume
>> Bro doesn't come with a TCP normalizer. What is the consideration for such
>> decision? It will be not necessary, or it will be implemented in future?
> A TCP normalizer, in the sense referred to here, is a middlebox that
> removes ambiguities in the traffic by actually modifying the packet flow
> and payloads in-path, to simplify the job of subsequent network monitors.
> So in order to implement this Bro would need to support in-path deployment,
> which isn't a priority for us.
> There's old (entirely unsupported) code for such a normalizer available
> here, if you'd like to experiment:
> There are also commercial products in this space that support varying
> extents of traffic normalization.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bro