[Bro-Dev] Decapsulating "payload" tunnels

[Seth Hall]

On Apr 26, 2012, at 10:34 PM, Robin Sommer wrote:

> We create a new class TunnelConnection that encapsulates that all the
> messy stuff. Interface could look something liek this:

I think that makes a lot of sense.

> one option would be internally add an new TUNNEL
> transport-layer besides the standard TCP/UDP/ICMP ones (drawback:
> there are a number of locations that currently expect to not see other
> transport-layers than the current set).

I think we'll need to be doing this before too long for SCTP anyway so becoming familiar with how painful this could be might not even be such a bad thing in the long run.

> The stream-based Analyzer interface doesn't need a packet,
> just data chunks. We might be able to directly feed in there.[1]
> (that's why the method above is called NextStream() :).

Hah!  It's as if someone had been thinking about this eventuality from the beginning. :)

> [1] Without further work this would break signature matching though.


Oh, good point.  We really need signatures so that DPD would work on the proxied data.  Are you thinking that it would mostly break the TCP semantics of the signatures?  I suspect that we'd be able to statically set some flags for "established" and "tcp".

Another approach to consider might be to back away from using ip-proto in signatures.  If SCTP does ever gain traction it would greatly complicate many signatures relying on the specific transport protocol.  We could just indicate connection-oriented or packet-oriented signatures.

  .Seth

--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro-ids.org/