gregor at icir.org
Thu Jul 28 18:23:22 PDT 2011
> [was used for VLAN]
Hmm. Interesting. In this case I'm surprised it worked because the way I
read the code, it always assumes that there is an IP header. It cast the
pkt pointer into a struct ip* and checks whether the caplen is large
enough to the IP header length from this struct ip* (which should work
often enough because the max header length is 64 bytes) but some short
packets might have been missed by that code.
>> Note, the reason I was looking at this code is that I want to write
>> something that can decapsulate tunneled IPv6 packets (6in4, 6to4, Teredo).
> I have code to do this written for Click! and it's fortunately very easy (I have AYIYA decapsulation code too).
Cool. I've actually never used Click, but yeah, the actual decapsulation
is really quite easy. Deciding what to do with the parent connection
(and how to implement that) is the hard part....
> The problem is that you have two IP layer headers and only the one with your address space makes any sense. It's really confusing to see two non-local networks show up in your conn.log because it was a local host using tunneled address space.
The right way to do that is to pull IP analysis into the analyzer tree
and then do tunnel de-capsulation using the analyzer tree. Then you
could even decapsulate IP-over-HTTP-over-whatever. But that's going to
be a lot of work. My plan was to do a simpler work-around though:
> I think we need the ability in the connection record to specify a parent connection or something. I suppose even just logging the presence of a tunnel may be enough. There are a lot of questions that will need answered once we start decapsulating tunnels.
Yeah. I haven't looked into that too much yet. But I was thinking of
either (or possibly both configureable)
* removing the parent headers completely but generate an event to
associate the child connection with the parent connection (1)
* create a copy for the packet data of the child . Thus Bro would see
both the parent connection and the decapsulated connection. One
would still want an event to link the two and you'll have two
packets with the same timestamp and the total byte counts will be
(1) not that it's not necessarily a connection. 6to4 and 6in4 are
directly on top of IP (using proto 41). So Bro wouldn't even see these
packets because it only handles TCP/UDP/ICMP (you would get a weird though)
<gregor at icir.org> <gregor at icsi.berkeley.edu>
Int. Computer Science Institute (ICSI)
1947 Center St., Ste. 600
Berkeley, CA 94704, USA
More information about the bro-dev