[Bro] ssl binpac analyzer -- patches

Ruoming Pang rpang at cs.princeton.edu
Fri Jun 1 16:02:26 PDT 2007


> > The way I imagine doing this is to consider RPC on TCP a trivial
> > lower-level protocol than RPC on UDP. For each RPC-on-TCP message, the
> > analyzer calls the datagram mode RPC analyzer's NewData() routine.
> > What do you think?
>
> I think the problem is not that simple.

Hi, Jimmy,

Maybe I wasn't clear enough, but I don't understand the problems you
raised below.

What I mean by a "RPC-on-TCP" message is a complete RPC message,
rather than a fragment. Maybe that's where the confusion is. In any
case, I think the thin RPC-over-TCP layer can be fully isolated from
the datagram-mode RPC analyzer, as long as the RPC analyzer receives
only complete RPC messages. The reassembly has to be done in C++, but
it's relatively trivial.

> First let's look at the case of RPC/UDP, it is possible that a RPC message
> is transmitted in multiple IP packets due to IP fragmentation. Either the
> lower layer should reassemble the entire RPC message from IP fragments, or
> just it sends the fragment pieces to the RPC decoder in order.

binpac analyzers do not see IP fragments. They should all be
reassembled at lower level, as in Bro. It's the same story at TCP
level and at RPC-over-TCP level.

Ruoming

> In the case of RPC/TCP, the first four bytes specifies the length of a RPC
> record (not necessarily be a complete RPC message from my understanding of
> the RPC RFC). It is called Record Marker. Because of the stream nature of
> TCP, the RPC record may be transmitted in multiple TCP packets. Although
> from some traces, I see that a TCP packet always contains the four bytes
> and the complete RPC message. I do not think we can make a safe assumption
> that this is always true. In addition, if a RPC record is not a complete
> RPC message, this introduces another problem to the RPC decoder. A complete
> RPC message may be transmitted in two records, and each record is prepended
> with a Record Marker. The position to split the two records can be arbitrary!
> I do not see a solution in the current binpac language to handle this kind
> of cases.
>
> Best wishes,
>
> Jimmy
>
> ____________________________________________________________
> The future is not set.  There is no fate but what we make
> for ourselves.             - Terminator II, Judgment Day
> ------------------------------------------------------------
>



More information about the Bro mailing list