[Bro] Fragmentation and TCP overlapping Issues

[Veronica Estrada]

8. By the way, before sending you the trace we did more research and
we suspect that the problem is generated by the machine used for the
capture. So we are going to check with the vendor. Thanks for the
help.

On Mon, Dec 6, 2010 at 2:38 PM, Vern Paxson <vern at icir.org> wrote:
>> 1. Although I am loading "frag", I am not receiving any event related with
>> fragmentation.
>>
>> What could be wrong? libpcap library? my BRO version?
>
> As usual, it helps a great deal if you include a trace and the command
> line you're using.
>
> One possibility is that you're trying to analyze UDP fragments, since the
> filter included by frag.bro only analyzes TCP fragments (to avoid heavy
> load from NFS traffic; this is vestigial, and makes sense to remove).
>
>> 2. What are the possible events triggered by weird analyzer related with tc=
>> p
>> overlapping?
>
> The analyzer doesn't look for overlap per se (which is not a TCP spec
> violation, and occurs for benign reasons; see our IEEE S&P 2008 paper).
> It looks for inconsistent TCP byte streams.  For those, it doesn't use the
> "weird" interface but generates a distinct event, rexmit_inconsistency.
>
>> (because I am not getting any of them although I think I should
>> see them on my trace)
>
> Again, including a trace and the command line you're using to analyze
> it is far and away the best way to get help for problems like this.
>
>> 3. TCP overlapping problems may generate "partial_ftp_request",
>
> No.  In this case, "partial" means that the connection was torn down
> in the middle of a request.  It doesn't have anything to do with TCP
> overlap.
>
>> 4. How does BRO perform TCP reassembly? I mean, is the traffic on ALL ports
>> reassembled?
>
> Traffic to ports for which there's an analyzer that uses the byte stream.
> You  can also contro lthis using tcp_reassembler_ports_orig and
> tcp_reassembler_ports_resp.
>
>> Is there any way to apply a default policy for doing TCP
>> reassembly? Like Policy First or Last or Unix
>
> No, this is not supported.
>
>> 5. There is an "active mapping" function to improve TCP reassembly. Can we
>> define the host profile database without this active function?
>
> No, that's the only way; and it is no longer supported.
>
>> 6. Can we configure the size of the reassembly buffer? I read in historical
>> msg (from 2006) there wasn't such config and BRO presented a vulnerability
>> against an adversary trying to exhaust memory, is this a current
>> possibility?
>
> See bro.init for the comments discussing tcp_max_above_hole_without_any_acks
> and tcp_excessive_data_without_further_acks.
>
>> 7. By doing offline analysis, I understood that BRO will analyze all the
>> packets without loss even if the CPU is running at 100%. Still, I need
>> information about dropping packets for other reasons. For example, if BRO
>> encounters TCP overlapping, Does it drop all the packets?
>
> No.  It always delivers the byte stream as soon as it is in sequence.
> Subsequent overlapping-but-inconsistent packets generate the event
> mentioned above.
>
>> Choose some of
>> them?
>
> Always the first seen.
>
>> Are these actions log somewhere?
>
> I'm not sure what there is to log.  Overlapping that's consistent is not
> any sort of necessarily peculiar phenomenon.  Inconsistent overlapping leads
> to events.
>
>> The same with fragmentations issues.
>> Where can I check the portion of fragments that where reassembled?
>
> No, this isn't instrumented.
>
>> how many
>> frames discarded, etc?
>
> I don't know what you mean by discarded here.
>
>> 8. I am not seeing any difference in bro logs when I analyze 2 pcap files.
>
> Again, you need to send along traces and command lines.
>
>                Vern
>